推理的真正成本：Dan Fu 谈生产优化与开放模型服务的质量边界

一、嘉宾背景

Dan Fu 在本期节目中被介绍为 Together 的研究负责人。嘉宾背景将他的工作与 AI 推理优化联系起来，关注推理延迟、吞吐量，以及满足服务水平要求的有效吞吐量。他的分享沿着一次请求的处理过程展开，解释模型执行如何成为持续运行的服务。

这些讨论来自具体的部署与评估经验。Dan 介绍，团队检查模型前向传播，寻找需要优化的 GPU 内核，同时将真实生产流量、内部试用、历史故障和 agent 任务纳入模型评估。他谈到的自动内核优化项目，尝试让 agent 围绕生产需求反复测量和迭代。量化的检查也因此延伸到工具调用能否继续完成、编码任务能否运行，而不止于参数占用的变化。

这期 YC Paper Club 还包括其他几位讲者的分享。Ollama 的 Jeff 讨论开放模型服务端点的质量，Luminal 联合创始人兼 CEO Joe 介绍编译搜索，SGLang 的 Liangsheng 讲解缓存与内存管理。他们分别从服务提供、服务选择、程序生成和运行时组织切入，补充了 Dan 对推理生命周期的讨论。

二、本期主要内容

节目标题中的“十二倍”，来自 Francois 对特定使用规模的估算。他引用较旧的 DeepSeek 数据：训练消耗约 280 万 H800 小时，推理每天消耗约 43,000 小时。按这一日用量持续一年，推理算力约为训练的六倍；再假设同一套权重使用两年，才得到十二倍。这个估算将关注点从一次训练需要多少资源，转向权重整个使用期内的重复计算需求，但并未确立适用于所有模型的成本比例。

Dan 随后沿请求路径解释推理服务的工作。请求经过 API 与网络入口，被路由到 GPU 副本，完成分词和工具格式处理，再进入排队、批处理与调度，依次经历 prefill 和 decode，最后将 token ID 转回文本并流式返回。工具调用还要与外部执行机制衔接：模型生成调用意图之后，搜索或命令执行仍需相应工具完成。路径中任何一层的格式处理或调度，都可能影响最终体验。

prefill 集中处理提示词，算术强度相对较高；decode 每次生成一个或少量 token，通常更受权重读取和显存带宽约束。调度因此需要在总体吞吐与响应速度之间取舍，决定是同时容纳更多请求，还是让当前请求更快得到响应。Francois 将优化空间分为模型改动、内核与运行时、应用 harness 三层，其中也包括路由、推测解码和上下文管理。推理工程的范围由此延伸到模型执行之外的请求组织方式。

Dan 重点讨论内核、并行与量化。Together 的内部项目 Together Compiler 使用 agent，针对目标模型、硬件和真实流量反复优化；他也明确指出，这个项目实际上不是编译器。量化的部署动机则可以从权重容量看出：一个三万亿参数模型，使用 BF16 存储约需 6 TB，使用 FP4 约需 1.5 TB。容量下降解释了为什么要量化，但模型行为是否保持，还需要另行验证。

其他讲者从不同环节展开了这一问题。Jeff 讨论推理聚合如何利用不同提供商的优势，同时权衡成本、智能、速度、地域与隐私。Joe 介绍如何将约 2,000 种 PyTorch 操作归约为约 14—15 个原语，例如将矩阵乘法表达为广播乘法与求和归约，再搜索适合硬件的实现。Liangsheng 则从共享长前缀、每轮只增加短后缀的 agent 负载出发，介绍 RadixAttention 如何利用 radix tree 复用前缀、淘汰未使用的叶节点，并通过请求排序提高缓存复用率。这些分享共同呈现了推理服务各环节之间的联系。

三、核心观点：推理、例子与边界

推理效率的数字，只有连同工作负载和统计口径一起看才有意义。Francois 引用的 DeepSeek 服务数据包括：输入缓存命中率约为 96%，缓存保留 72 小时；单 GPU 的 prefill 吞吐量在排除缓存命中时约为每秒 60,000 token，计入命中时则约为每秒 150 万 token。后一个数字包含对已完成工作的复用，不能直接视为 GPU 处理新计算的能力。Dan 用连续处理代码库的请求解释了其中的机制：后续请求若被路由到仍保留相关 KV 缓存的副本，就可能省去重新处理整份代码的工作；如果路由只考虑负载，就可能错过这部分复用。

缓存命中率也不能单独代表服务收益。Liangsheng 以命中率从 95% 提升到 99% 说明缓存的价值，直接成立的计算是：未命中比例从 5% 降至 1%。对应的未命中 prefill 工作量降至原来的五分之一，并不意味着排队、decode、数据搬运和总费用也同比下降。节目讨论的 goodput，即满足服务水平要求的有效吞吐量，更接近实际服务目标；评估时还要同时观察首 token 延迟和每个输出 token 的耗时。roofline 模型则以峰值算力和“带宽乘以算术强度”两者中的较小值解释性能上限，帮助判断优化究竟缓解了哪一项约束。

扩大硬件规模也有相应的代价。Dan 解释，更大的高速互联域能够支持专家并行，让分散到更多 GPU 上的专家各自积累更大的 token 批次，从而形成 GPU 擅长处理的大矩阵计算。但如果一个副本横跨 72 张 GPU，在缺少充分恢复机制的情况下，其中一张卡失效就可能使整个副本退出服务。吞吐潜力与故障影响范围一同扩大，可靠性机制因此也是性能设计的一部分。

量化能否投入服务，取决于质量验证。Dan 介绍的检查包括公开基准、逐层激活的 KL 散度、数百个历史故障回归案例、内部使用，以及反复生成 Flappy Bird、优化内核等 agent 任务。这些方法分别检查数值变化、任务表现和实际行为。生成 Flappy Bird 可以让编码能力接受可观察的功能检验，但单个游戏任务无法代表全部业务。Dan 称，Together 的 NVFP4 配方在展示的评估中匹配了 MiniMax 原始 FP8 模型的表现。材料未提供详细分数或实测吞吐增幅，因此这一结论只能用于该次展示范围内的比较。

Jeff 的分享进一步说明，“相同模型”不足以定义一个服务端点。精度、硬件、权重版本、采样方式、工具解析、自定义内核和 KV 缓存精度，乃至模型名称标注错误，都可能造成端点差异；有些差异只有在长上下文中才会暴露。他以一个 15 步任务为例：如果每步都有 10% 的偏离概率，至少发生一次偏离的概率约为 79%。这一计算假设各步独立，并将任意一次偏离都视为任务失败。它不是实测的 agent 失败率，但说明了为什么单次调用中看似有限的偏差，需要放到完整任务链中评估。

自动化优化同样需要明确的正确性边界。Joe 介绍的 e-graph 保存等价表达，从中提取候选程序，再通过硬件实测选择实现；基于 roofline 的剪枝则排除理论上限也不足以达到目标速度的候选。表达是否等价、实机运行是否更快，是两个都要回答的问题。浮点数的树形归约与顺序归约可能产生不同结果，因此重写规则必须明确数值语义，调试时还需要高层元数据和 egglog 重写证明链来追溯问题。这种受预算约束的启发式搜索不保证全局最优。花数小时甚至一天编译，以换取反复运行时的节省，是一项需要核算的取舍；节目没有证明它能带来统一幅度的提速。

SGLang 的重叠调度与 HiCache 则从减少等待和扩大复用入手：CPU 提前准备下一批工作，减少 GPU 等待，前缀缓存分布在 GPU、主机和外部存储层级。Liangsheng 报告了随硬件而异的吞吐改善，以及一项延迟指标下降 56% 的结果。但材料缺少完整测试条件，后一个指标的转写也存在歧义。这些数字应保留为讲者报告的特定结果；将它们用于容量规划之前，还需要在目标环境中验证。

四、学习与应用

准备部署模型的团队，可以先核算模型整个使用期的资源需求：分别记录训练总算力、日常推理需求和预计权重使用期，再比较流量增长或提前更换模型时的变化。节目的十二倍估算提供了一种计算思路，不能作为固定系数直接套用。服务目标也应分别落实到首 token 延迟、后续生成速度，以及满足这些要求的有效吞吐量；总 token 产出增加，并不足以证明用户体验改善。

缓存实验可以从真实会话入手，抽取围绕同一代码库的连续请求，比较普通负载均衡与缓存感知路由，同时记录等待时间和重复 prefill 工作。再调整请求间隔与缓存保留策略，判断复用收益是否足以抵偿资源占用。如果保留前缀的副本已经拥塞，就需要比较省下的计算与新增的排队时间。命中率上升后仍要测量完整请求成本，不能将未命中工作量的下降直接换算为总费用下降。

量化上线需要逐层验证：先比较数值变化与任务基准，再运行历史故障案例、工具调用和完整 agent 任务，最后检查实际部署行为。Dan 的免训练量化方案使用校准数据和 Scale Search。他避免后续训练，是因为团队在缺少完整原始训练集时观察到了遗忘。这项经验有明确条件，不能据此推断所有量化后训练都会失败。对具体应用而言，仅有少数公开基准分数接近，仍不足以认定量化前后的行为等效。

端点评估需要分别回答三个问题：相对过去是否发生变化，相对参考权重是否一致，以及任务能否正确完成。按 Jeff 的介绍，下一 token 的对数概率适合用作成本较低的漂移探针，但前提是 API 提供相应数据，而且基线本身有效；错误基线不会因长期稳定而变得正确。参考输出分布比较需要运行参考模型，对差异原因的解释能力也有限；完整评测检查得更深入，成本则更高。因此，可以持续运行轻量探针，监测工具调用错误率和输出长度，在发现异常后触发定向评测。客户私有任务与逐步加长的上下文测试，有助于发现公开测试未覆盖的退化。更一致的服务栈、官方量化方案和 harness 逻辑，也应纳入端点比较。本地引擎面临相似的质量问题，同样需要这些检查。

排查混合架构的缓存问题时，需要分清匹配语义、容量分配和物理布局。统一的 token-ID radix tree 协调全注意力、窗口和循环状态的缓存匹配，并不意味着这些状态保留相同内容；共享物理内存用于适应不同负载下的容量分配，压实则处理分配与驱逐留下的碎片。Liangsheng 明确更正，压实移动的是物理片段，通过重映射保持虚拟页 ID 稳定。验证时可以检查物理页面移动后的映射和输出，并测量搬运开销，不能只看空闲字节是否增加。

编译搜索的投入也要与预计重复运行次数一并核算。固定目标硬件、典型输入形状、允许误差和搜索预算后，再比较运行时间的节省与编译成本。节目末段还讨论了训练循环中的 rollout 推理，以及生成与训练完全异步执行的方式，但转写中的项目名称不稳定，材料也未提供同步细节或量化收益。在取得具体调度方案和测量结果之前，还不能将“异步”换算为可承诺的利用率提升。

来源

• 原始节目：Why Inference Matters 12x More Than Training | YC Paper Club