五度妙笔
企业透视镜
API商城
数据库Baseten访谈：跑模型不是堆显卡，推理正在变成系统工程
在最新一期 Latent Space 对谈里，主持人 swyx 、 Vibhu 与 Baseten 的 Philip Kiely、Ali Taha 聊了一个很实在的问题：模型发布越来越快，跑分越来越高，但把新模型变成一条稳定、快速、能接住真实流量的生产级 API，中间到底还差多少工程？他们的判断很清晰——差的不止一点，而是一整套系统工程。
整场对话听下来，有几个点让人印象很深：大家都觉得模型能力差不多到头了，但推理优化这一层，20%、100%、200% 的提速还在批量出现；大家都盯着 GPU 算力，但真正的瓶颈正在往网络、缓存、系统协同这些“看不见的地方”转移；更意外的是，模型已经开始参与优化承载自己的系统，训练和推理之间的边界正在变得模糊。换句话说，推理已经不只是“怎么跑起来”，而是正在成为 AI 下一阶段的核心工程战场。
本文编译自Latent Space 最新一期博播客内容，原文链接：https://www.youtube.com/watch?v=7PSXtru6mmY&t=2081s，以下是完整编译。
超长请求进来，系统先找缓存
swyx： 我先抛一个很典型的问题：如果我往 Baseten 的系统里塞一个 20 万 token 的超长请求，中间到底会发生什么？从模型路由到 GPU 调度，实际链路是什么样的？
Philip Kiely： 第一个问题我会先问：你之前是不是发过一模一样的请求？哪怕只是其中一部分也行？希望你发过，因为这样我处理起来快得多，你的账单也会便宜不少。系统要做的第一件事，就是所谓的“缓存感知路由”。我们背后跑着很多实例和副本，都在等着服务你的请求。我们要做的是，把这个请求调度到一台既有空闲算力来做预填充、又刚好缓存了你之前部分输入的那台机器上，这样就能直接跳过那 20 万 token 里至少一部分的计算。像 20 万 token 这种量级的请求，通常是代码生成或者多轮智能体对话，这类场景缓存命中率一般都不错。如果真的没有命中，那就只能让预填充 Worker 从头开始跑了。在我们这边，至少对某些模型来说，预填充和解码是完全拆开的：一组 GPU 专门接输入、算 KV 缓存、产出第一个 token，然后交给另一组 GPU 去做逐 token 的解码生成。再往上，我们可能还会在前面挂一个推测解码器的小模型来帮忙加速。这里我默认你是在写代码，因为编程场景下草稿 token 的接受率通常比较高。要是我猜错了，你其实是想让我逐本总结《哈利·波特》，那速度就会明显慢一截。等输出流式传回给你之后，我们记个账，收你几分钱，再顺带问一句：要不要再来一个？
swyx： 但之前聊的时候我记得一个关键点：那些超高吞吐量的用户，直接按整台机器租反而更划算，因为你要自己想办法把机器跑满。按 token 计费如果量级推到百万级别，反而不如按小时计费来得便宜。
Philip Kiely： 是的。我看到越来越多人对按 token 计费的 API 有需求，因为大家都想先试试各种开源模型。但一旦他们找到一个真正有粘性的应用场景，就会迁移到独享部署上。
swyx： 那什么时候该从共享 API 切到独享部署？有什么判断标准吗？
Philip Kiely： 有几个关键原因。首先是可靠性。比如他们有非常具体的业务场景，想针对自己的流量分布做定制优化，比如训练一个专属于自己的推测解码器。共享端点没法满足这种需求，因为我不清楚你是在做编程、处理法律文书还是写小说。
Ali Taha： 推测解码这块的机制是这样的：你有一个大模型，它每次前向传播只生成一个 token。所以我们在这个大模型上面附着一个很小的“寄生”层，这个层只需要做三次极快的自回归前向传播，预测出三个候选 token，然后你对整个原始大模型做一次前向传播来验证这些预测对不对，对了就接受，错了就拒绝。这个草稿模型是跟具体流量特征高度相关的。比如 Philip 说的，如果你在总结《哈利·波特》，我可以专门用《哈利·波特》的数据来训练这个草稿模型，保证它每次都能把三个 token 全部命中。这样一来解码速度就明显上去了。但在共享端点上我没法给你提供这种定制，因为我根本不知道你是在读哈利·波特、写代码还是处理英文文本。另外，如果客户对某个具体指标有严格的要求，就像书里第四章提到的那些，他们可以自己设定批处理大小、调整并行策略，根据是要优化吞吐量还是延迟来做取舍。他们也可以选择更高的精度，比如 NVFP4 量化如果过不了他们的基准测试，那就换更高精度的版本来跑。还有一大堆其他理由让你想要自己的专用端点。其中最大的一个是：你不想在自己正好服务用户的时候，被别人往共享端点上狂灌一亿 token 的压测流量。
swyx： 那工具调用呢？是不是就只是生成 JSON，还是说里面还有更复杂的门道？
Ali Taha： 我们有些客户有自己的后训练模型，他们需要的工具调用不是那种“解析文件”或者“查个天气”级别的，而是非常垂直的业务逻辑。这需要在模型上做专门的后训练，如果后训练没做好，或者后训练之后为了加速推理做的量化没做好，模型在解析 JSON 和识别工具调用时就会出问题。但它不需要独立的沙箱环境，不是说它会借助工具调用逃逸出去或者需要被隔离，它就是普通的独享部署。
Philip Kiely： 工具调用越来越棘手的地方在于：客户要的是非常特定的工具调用格式，这在训练上是很敏感的事情。你处理的是 JSON 输出，如果模型没有用非常精确的方式把请求收尾，就会出现一种情况：模型已经完成了工具调用和内部“思考”，但因为没有真正拿到工具返回的结果，它就在解码过程中自己凭空“幻觉”出了一个结果。这是目前工具调用里最核心的工程挑战，跟沙箱隔离关系不大。
Ali Taha： 这更多是训练侧要解决的问题。在推理侧，你可以做一些事情来约束输出范围。我们大概两年前发过一篇东西，核心思路就是做一个状态机，用它把输出限定在指定格式内，这就是“结构化输出”要解决的老问题。
Philip Kiely： 更早的时候，OpenAI 就提过一种做法：想约束输出格式就写 BNF 语法。在我们推理系统里，这就是一个“指定输出格式”的机制，能保证输出严格按照那个结构走。把这个机制用在工具调用上，至少能解决输出格式乱掉的问题。当然你还是可能调错工具或者干脆不调工具，但至少 JSON 格式不会出岔子。MCP 本质上只是工具的另一种表达形式，没有什么特殊之处。我一直跟人解释的一点是：LLM 实际上什么都执行不了，它只能做“建议”，只有当这些建议被格式化成特定结构、然后交给一个懂得怎么执行它们的系统，才有实际动作发生。
Ali Taha： 在智能体循环里，如果输出不对，或者说模型在推理状态里已经做了工具调用但格式有问题，它可能会自己说“我不知道该怎么做了，让我再试一次”，反复试几次也许能走通。你刚才提到训练的问题，在小模型上这一点更难，因为从大模型换到小模型时，同样的训练方式输出的质量会有明显落差。
swyx： 我之前以为会有人发明 JSON 的替代品，因为 JSON 流式传输体验很差，它必须完整闭合才能解析，没法边收边解析边校验。所以大家搞了很多替代格式，比如类似 TOML 的、类似 YAML 的。但到现在 JSON 还是绝对主导。而且 JSON 输出通常没那么长，工具调用里的参数偶尔可能很长，但绝大多数工具调用的 token 数都不大，所以推测解码器在处理这种格式化输出时效率应该挺高的，解码步骤会很快。
Ali Taha： 我觉得你还会受到软件本身的限制，因为模型要集成的那些系统，如果它们本来就是用 JSON 来做工具调用的，或者说你的客户说“我们的软件就是这么工作的，工具接口就是基于 JSON 的”，你也不能强迫别人改。当然你可以跟客户说“这个格式对模型更友好，你们改一下”，但训练做得好的话，JSON 带来的差异其实没那么大。另外从商业模式上看，如果模型输出更多 token，可能也更赚钱。
swyx： 这取决于你的商业模式吧。
Philip Kiely： 确实。但我作为一个写过很多东西的人，从文本转到 JSON 文本的时候，JSON 其实很长的，每个字段里都带着大段内容，我是想把它结构化，比如要求模型先做事实陈述、再做观点、再做要点总结、标日期、标实体引用、标来源，所有这些。所以如果你真的深度使用结构化输出，这些细节就很重要。
模型发布只是开始，推理工程才是重头戏
swyx： 开始录之前你提到一件事：每次有新模型发布，背后要做大量的推理工程工作。比如 GLM 5.2、Kimi K3 这些。我以前想当然地以为，如果之前已经支持过 GLM 5.1 了，那 5.2 应该没什么工作量吧？实际上呢？
Philip Kiely： 实际上工作量非常大。
Ali Taha： 是啊。每次有新模型发布，大家都急着在社交平台上说“Hugging Face 支持了，Fireworks 支持了，Baseten 也支持了”。每次我看到这种公告就在想：当然我们说“支持”了，但背后到底经历了什么？我觉得“支持”对终端用户来说价值很大。比如 Kimi K2.5 或者 GLM 5.2 发布的时候，简直就像一场推理竞赛，某家服务商跑到 90 token/秒，第二天另一家就冲到 150。其实最早那波热度是我在 GLM 5.2 上带起来的，我发了条推文说在 Baseten 上跑到第一，大概有 50 万阅读量，然后大家就都开始兴奋了，开始琢磨怎么再往上卷。
Philip Kiely： “支持这个模型”和“能从这个模型生成 token”之间有天壤之别。从“能跑”到“能上线成生产级 API”，中间是一整套系统工程。“能跑”本身其实不算太难，因为像 vLLM、SGLang 这类开源推理引擎的维护者，有时甚至在模型正式发布前就拿到了权重，很多基础兼容工作已经有人做完了。但问题在于，每家推理公司的技术栈都不一样，有些用开源组件，有些是自研运行时，有些是自己的部署和调度逻辑。每出一个新模型，总会有一些新的架构细节需要适配。当然有时候运气好，比如 Kimi K2.5 到 K2.6 变动不大，基本就是持续后训练。但即使这种“小版本更新”，该做的事一件都不能少。你得重新做量化。这些模型发布时通常不会直接给你 NVFP4 格式的版本，但为了在 Blackwell 上达到最优性能我们需要 NVFP4，所以得自己做量化，还要仔细校准，确保模型智能不要因为量化而明显掉线。
Ali Taha： 然后还要训练推测解码器。我们对模型 API 是零数据保留的，所以不知道用户具体在发什么内容，但我们知道大趋势：编程用例很火，智能体用例也很火。所以我们可以从公开数据集里挑代表性的样本，来训练通用的推测解码器。现在训练推测解码器有一个关键点：必须用基座模型本身来跑推理，从它的隐藏状态里提取训练信号。所以你确实需要真实的模型权重才能做这件事。然后还有一整套基础设施的搭建、加载、测试。如果新模型用了新架构，那更麻烦。DeepSeek 系列的模型通常是最有挑战性的，因为它们每次都会带一些很新颖的架构改动，但说实话每个新模型都有自己的“惊喜”。比如 GLM 5.2 从 DeepSeek 引进了 DSA 注意力机制。
*DSA 是 DeepSeek 提出的一种稀疏注意力机制，简单说就是：不让每个 token 去看所有其他 token，而是先快速筛选出最重要的那几个，只跟它们算注意力。这样做长文本推理更快、更省显存，质量基本不掉。
Ali Taha： 我们必须在自己的运行时里把对这个新机制的支持做进去。有意思的是，这些开源实验室之间会互相“借鉴”。比如 GLM 5.2 本身没有视觉能力，但我们团队里的 Harry 把 Kimi 的视觉编码器“嫁接”到了 GLM 5.2 上，我们只训练了一个几百万参数的“投影器”来做连接。最开始他让模型做简单的图像描述训练，比如“这是一张山的照片，描述一下”，那是第一个学习阶段。但这样学得不够深，后来他改成“问答式”训练：对同一张图连续问很多问题，比如“图里有没有白人男性”“右上角有没有鸟”“图里有没有科学家”，模型必须逐个正确回答。通过这种问答式训练，不只是做简单描述，而是不断回答问题，你能看到模型真的在进步。这真的很疯狂：把一个视觉编码器“嫁接”进一个大语言模型，能让它学到这种程度。即使在它表现不太好的图像上，比如给它一张霍金的照片问“这是谁”，它可能答不出霍金，但会说“这是爱因斯坦”，它仍然理解这是一个男性科学家、有重大成就的人。这真的很厉害。
Philip Kiely： 这个方向特别让人兴奋。现在这个模型在 MMLU Pro 上大概 56%，不算最前沿，但关键是你跑这个模型时，GLM 5.2 原来的纯文本质量没有任何损失。如果输入里没有图像，它就跟原来一模一样。在推理代码里，如果没有图像输入，你直接把编码器那部分跳过就行。
Ali Taha： 对整体推理侧影响大吗？加的东西其实不多，视觉编码器通常不到 10 亿参数，在整个系统里占比很小。
Philip Kiely： 不同视觉编码器的标准化程度略低一些，兼容性矩阵可能没那么完整，但总体来说它是整个系统里很轻的一块。最终你做出来的东西是“Kimi 的视觉 + GLM 的权重 + DeepSeek 的注意力”合在一起。这就是开源生态的力量和美妙之处，你可以把不同来源的组件拼成一个系统，比任何一个单独的系统都更强。
swyx： 以前大家也做“弗兰肯斯坦式”的模型合并，从不同模型里各拿几层拼起来。现在还有人这么做吗？
Ali Taha： 你刚才提到支持新模型时需要做的一些工作，有时候你确实需要替换某些层。比如 MiniMax M3 用的是全注意力，全注意力在自回归生成时会造成巨大的瓶颈，因为你要对三个 token 做自回归，KV 缓存会非常大，它不稀疏、不做 top-k 选择，所以内存占用爆炸。我们发现更好的做法是：用另一个模型里更高效的层来替换它，比如换成 GQA 的层，然后通过适当的训练让替换后的层达到同样的接受率。所以从其他模型“移植”层过来是完全可行的，而且有时候非常必要，如果某个层效率太低，你就得换。这时训练本身就成了挑战：你要确保训练方式是对的。这又回到了“训练和推理之间的融合”这个主题，想要做快速的推理，你必须有好的训练方法，这一点越来越明显。
swyx： 在“支持新模型”这件事上，还有什么其他工作要做才能达到“完全生产就绪”的水平？
Philip Kiely： 我们会做相当大规模的测试，但市场不等人，我们需要尽快推出。一旦上线，成千上万的用户用各种奇奇怪怪的输入去测它，你总会发现一些意想不到的问题。比如 GLM 5.2 刚上线时出现过一种情况：在某些 prompt 和某些温度设置下，它会突然“坍缩”，不断重复同一个 token。一旦你把端点暴露给真实世界，输入多样性呈指数级增长，你就能发现各种在内部测试里没见过的 bug，然后一个个修。所以这不是“第零天”做完就完了，接下来一周、一个月，如果模型还很火，你要一边修线上 bug，一边继续压榨性能极限。
swyx： 你们会做“循环检测”吗？比如模型开始输出“sssssss”的时候怎么办？
Ali Taha： 这事儿其实还挺常见的，说实话有点意外。我们在端点里做了保护逻辑：如果连续四次以上输出同一个 token，我们就直接掐断生成，返回一个“抱歉请重试”，或者直接重新处理这个请求。因为我们知道连续四次重复同一个 token，基本就是模型已经“坍缩”了。
swyx： 能选择关掉这个保护吗？万一我真的想要那种输出呢？
Ali Taha： 有些场景比如模型在画表格，需要连续输出十几条横线，那种情况应该能正常工作。我们的保护只针对特定 token，会排除某些特殊字符。而且这个问题有很强的“token 特异性”，“s”是最常见的问题 token，GLM 5.2 经常中招，DeepSeek V4 也有类似问题。
swyx： “s”有什么特别的吗？
Ali Taha： 没什么特别的，就是恰好这个 token 最容易出问题。而且这个问题不只在 temperature=0 时出现，即使 0.9 或者别的温度也会坍缩。说白了这是一个推理侧的软件问题，不是模型本身的问题。有时候 NVIDIA 发布一个新的容器镜像，我们把它合进来，问题就消失了。或者同一个模型在 SGLang 上会坍缩，换到 vLLM 就没事。所以它看起来是一个非常非确定性的软件问题，跟模型权重无关。有人说“是量化的问题，PTQ 做错了”，那个解释说不通，同样的权重换一个推理引擎就不会复现。有些时候问题出在底层 kernel（运行在 GPU 上的核心计算程序），有些 kernel 里有非常微妙的竞态条件。同一个模型放在集群 A 上永远不会出问题，放到集群 B 上就频频复现。原因是集群 B 里节点间的互联速度比集群 A 慢，KV cache 传输过程中暴露了竞态条件，而集群 A 因为更快就没事。所以最终你就只能做这种决定：“这个模型不放在这个集群上，换一个。”然后你就在那琢磨：到底是软件问题、模型权重问题，还是硬件问题？
Philip Kiely： 关于“temperature=0 仍然不保证确定性”这件事，大多数人的解释是硬件导致的。即使在 temperature=0 下跑同一个模型，输出也不是每次都完全一样。
Ali Taha： 我对“竞态条件导致问题”这个事还挺惊讶的，因为我本来觉得 PyTorch（一个开源的深度学习框架）是一个计算图，应该能保证按正确顺序执行。但实际上你可以做某些优化，比如在一个 kernel 结束之前就启动下一个 kernel，只要没有数据依赖，这是你想要做的事情。但如果重叠执行处理得不干净，就可能出问题。更底层地说，kernel 本身可能有竞态条件，比如少了一道同步屏障。写 kernel 的时候为了追求极致速度，如果没有做充分的测试，某些线程可能在别的线程把数据写进去之前就去读了。归根到底，测试本身就是一件非常困难的事情。没有像 Rust 的借用检查器那样能保证内存安全的工具，虽然场景不完全一样，但问题性质是类似的。
swyx： 你是在 CUDA 上工作，跑在 NVIDIA GPU 上，也许需要像 Modular 那样的更高级语言来做这件事？当然我也不确定。
量化不一定是“压缩变差”，误差还能互相抵消
swyx： 咱们聊到了保持模型质量的问题。做了量化、训练了推测解码器、在不同硬件上跑、跟踪了各个服务商的表现，你还亲自点燃了一场推理速度竞赛。那么在“保持质量不变”这件事上，到底要做什么？当然你可以跑一堆基准测试，但你怎么判断量化做到什么程度算“够好”？有没有行业标准？
Philip Kiely： 可以从几个层面来看。大多数推理优化其实是无损的，比如 KV 缓存，本质上是避免重复计算相同的值。推测解码也是无损的，如果草稿 token 错了就直接拒绝，不会污染最终输出。唯一真正“有损”的优化是量化。而量化涉及到几个关键决策：用什么数据类型、选择量化模型的哪些部分、量化哪些层，以及做大量的校准工作来确保那些“异常值”权重被妥善保留。还有一些技巧，比如长上下文场景。最开始你问“20 万 token 请求会发生什么”，长输入序列意味着你需要存储更多信息、处理更多 token。所以即使模型本身宣称支持某个长度的上下文，作为推理服务商，你可能会同时提供“短上下文版”和“全长版”两个 API 端点，因为如果用户不需要百万级上下文，短版能跑得更快。但我不确定这算不算“模型质量”的范畴。我对“质量”的理解是：我们在多大程度上“忠实”地还原了原始模型的行为。如果你想象一个“黄金标准实现”，它完全按照模型设计者预期的方式运行，那“质量”就是我们离那个 100% 保真度有多近。当然你也可以从训练角度谈“质量”，怎么把模型本身做得更好。但从推理优化的角度，“质量”就是跑得更快的同时，尽量贴住那个 100% 的保真度。我们内部的标准很朴素：用户应该看不出我们的 API 输出和官方 API 输出有什么区别。
Ali Taha： Kimi 在这方面做得特别好，他们专门发布了一个“供应商验证工具”，会去测各个服务商是不是真的把模型跑对了。
Philip Kiely： 因为 Kimi 确实公开指责过某些服务商，好像是 Amazon，在它们的基准测试上表现很糟糕。
Ali Taha： Kimi 那边会介意这件事，其实很正常。你想，如果我是普通用户，用某个服务商的 API 跑 Kimi，结果体验很差，我不会去怪服务商，只会觉得“Kimi 这模型不行”。所以 Kimi 会去盯着各家服务商的跑分质量，完全合情合理。
swyx： 我想确认一下：量化有没有可能反而让模型“变好”？量化是不是永远都只会让模型变差？
Philip Kiely： 量化严格来说是有损压缩。速度确实会提升，但从道理上讲，它不会让模型“更聪明”。
Ali Taha： 我在 N Brown 那里学到一件事：有些规律朝一个方向走，但因为模型本身有非确定性，跑基准测试的时候，NVFP4 量化的版本偶尔会比 BF16 版本还高两个基点。
Philip Kiely： 那基本在误差范围内，所以我现在不太说“在误差范围内”这种话了，因为大家会理解成“我们勉强卡在误差线边缘”。但确实有时候量化版本分数会略高一点，不过就像 Ali 说的，那只是噪声。据我所知，量化不会让结果“更好”，你只是在尽量让保真度接近 100%。
Ali Taha： 我们做过相关研究。我们的研究实习生 Joshua 发过一条推文，说我们量化的 GLM 5.2 比 NVIDIA 自己做的版本好 20%。我们做了两个月的研究，核心发现是这样的：量化就是把 16 位的数据压到 4 位，肯定会丢信息，你要做的是把损失最小化。所以“我的工作就是找到哪些层可以量化、哪些层不能量化”。比如在图像模型里，我们不量化调制层，也不量化输出投影层。输出投影是用户看到的最终结果，调制层是模型“看到”或“理解”输入的方式。Joshua 在他的数学证明里展示了一个反直觉的结果：你量化更多层，反而可能表现更好，因为不同层的量化误差会互相抵消。他不是用 benchmark 分数来衡量，而是用 KL 散度来比较量化模型和原始全精度模型的 logit 分布。如果你的概率分布更接近原始模型，那你就更“忠实”。所以以前行业里“量化越多损失越大”的假设，并不总是成立的。
Philip Kiely： 这让我想到剪枝，你可以剪掉某些层还能保持性能，但量化误差抵消这个发现确实很有意思。
Ali Taha： 有个花絮，这篇论文最开始有 72 页，后来我们觉得实在发不了，就砍到了 45 页。
swyx： 你提到速度提升。那篇博客里说“官方 API 70 token/秒，你们推到 90”，这算正常操作吗？推理工程之所以有意思，是因为在那些已经高度优化的领域，比如金融量化，你衡量进步的单位是“基点”，五个基点，也就是 1/120 个百分点，就能算大新闻了，因为所有东西都已经卷到极致了。但推理这边，我们发优化的时候开口就是 20%、100%、200%。所以这路还长得很。你什么时候知道推理“差不多到头了”？应该是当研究者开始发论文说“我们快了 1%”的时候。顺便说一句，我做过金融量化，70 年代那会儿，量化金融研究里的超额收益也是百分之几十的量级，现在微小到几乎测不出来了。
Philip Kiely： 对，推理现在就处于那个“早期”阶段。当然基准测试很难做，谁都会告诉你。测不同服务商的速度尤其难，因为变量太多了：用什么硬件、系统负载多大、prompt 和输出的长度分布怎样。但总的来说，当你把这些改进叠在一起，看到的是倍数级的提升。最常用的指标当然是 TPS，token 每秒，但这个命名其实很糟糕，因为实际上有两个 TPS：一个是吞吐量的“总 token/秒”，另一个是延迟的“逐 token 延迟”。大多数人关心的 TPS 是后者，逐 token 生成速度，其实应该叫 ITL（token 间延迟），但大家已经叫习惯了。
Ali Taha： 你可以想象一个没做什么优化的标准 API，跑万亿参数模型，在正常流量下大概是 30 到 50 token/秒。我们的目标一般是推到 10 倍。不一定第零天就能做到，但通过叠加足够多的优化，比如四个优化各自翻倍，那理论上就是 16 倍。在这个领域我们的目标是做出数量级的提升，而不是从 70 挤到 90。
swyx： 你们真的做到了 10 倍？
Philip Kiely： 如果基线是 30 到 40 token/秒，那确实可以达到 300 到 400。比如 GLM 5.2，如果跑在没量化的 H100 上，用开箱即用的推理引擎，没有推测解码器、没有 KV 路由、没有分离式推理，那大概就是 30 到 40。要跑到 300 到 400，你用上了最好的硬件、优化过的推测解码器、做完了所有量化工作、缓存命中率很高、批处理大小合理、并行配置是针对延迟而非吞吐调优的，这完全可行。你在 Artificial Analysis 或 OpenRouter 上看到的最差服务商和最好服务商之间的差距，经常就能落到这个量级。10 倍当然是比较激进的目标，实际更常见的是 4 到 6 倍，但正是这种数量级的提升让我们兴奋，而不是 70 到 90。
Ali Taha： 也取决于硬件。你在一堆 H100 上跑，换成四台 B200 节点把模型打散，当然会更快。但如果控制变量，同样硬件、同样 GPU 数量，推理优化本身能带来 2 到 4 倍的提升。所以一部分是“换车”，一部分是“换司机”。
swyx： 拆解这 2 到 4 倍的话，比如在单节点 B200 上跑 GLM 5.2，要榨出最后那点性能，成本收益怎么算？普通人应该怎么理解这件事？量化、推测解码、分离式推理，这三样是不是占了大头？对一般人来说实现起来有多难？
Philip Kiely： 如果从头自己做，工作量很大。但今天已经有很多现成资源了，有人已经发布了 NVFP4 权重，有人训练好了推测解码器，你直接拿来用就行。如果看我们叠加的“2 倍”：从 BF16 到 NVFP4 不是正好 2 倍，大概是 30% 到 40% 的提升，从 16 位到 8 位再叠一个 30% 到 40%，乘起来接近 2 倍。推测解码再来一个 2 倍。分离式推理在有足够硬件和流量的条件下也是 2 倍。再加上更好的运行时和最新的 kernel 带来的百分之几十的提升。就这么叠出来的。
Ali Taha： 构建每个组件：量化权重对一个懂行的人来说是几小时到几天的工作；训练推测解码器也是几小时到几天；分离式设置，第一次做当然很难，但有了基础之后边际成本就低很多了。
Philip Kiely： 如果你是手头有 B200 节点、想自己托管模型的普通用户，你不需要自己量化，总会有人发布开源的量化 checkpoint，NVIDIA 自己也会推，再不然各家服务商也会放出他们训练好的 spec decoder，你直接用就行。
Ali Taha： 像 GLM 5.2 自带了 MTP（多 token 预测）机制，可以用来做自推测解码。
模型再大，系统跟不上也没用
swyx： 我一直等着有人提 Dynamo（英伟达的开源分布式推理调度系统，管理一堆GPU怎么一起跑模型的“总调度员”）。这东西应该是你用来做基准线的标准吧？
Philip Kiely： 我会把 Dynamo 看作一个“构建工具包”，而不是“开箱即用的系统”。当我们讨论 KV 感知路由、KV 卸载、预填充-解码分离时，Dynamo 本质上是一个开源的 NVIDIA 库，用来帮你协调这些东西。它支持不同的推理框架，也兼容多种硬件。但它本质上是一个“路由器”，不是一个“优化层”。Dynamo 擅长的是在集群里搬运数据：你有一个 KV cache 在节点 A，需要把它弄到节点 B，Dynamo 帮你协调 NVLink（英伟达开发的一种高速互联技术，专门用来连接多张 GPU）做传输。但这不意味着你 pip install Dynamo 就能自动获得巨大性能提升，它更像一个开发者工具包。
Ali Taha： 它确实带了一些默认配置，你可以替换。如果行业里大家都用标准化的部署方式，它可能会成为一个可信的基准线。但我们看到的现实是，各家实现方式差异很大。
swyx： 我想多聊聊预填充-解码分离，这应该算推理优化里排名第三的大头，前两个是量化和推测解码。书里第 5.2.2 是 *Medusa，5.2.3 是 Eagle，5.5 是分离式。我想问的是：这些技术现在还有效吗？Medusa 挺老的了，但你在书里把它作为“好的基准线，你应该知道”来写的。
*Medusa：早期的推测解码方案，通过加多个“预测头”来猜后续 token，简单但已不是主流；Eagle：更新的推测解码方案，通过单独训练一个小模型来猜后续 token，猜得更准，目前工业界常用；分离式（预填充-解码分离）：把“读问题”和“吐答案”两个阶段拆到不同的 GPU 上去跑，各干各的，互不干扰，整体效率更高
Philip Kiely： 写这本书有几个目标：一个是给读者提供这个领域的工作词汇，另一个是建立直觉，每个技术大概怎么工作、为什么有用。推测解码这个领域比其他所有东西跑得都快。所以即使在写书的时候，Medusa 也是作为“理解这个领域如何演进”的入口来写的，而不是当作“最前沿技术”来推。现在当然有 *DFlash、Despark，有比 Eagle 更新的技术，虽然 Eagle 还是很常用。还有“推测式推测解码”，这是 Tri Dao 发的一篇新论文，本质上就是对推测解码再做一层推测解码，作者确实测出了非平凡的加速。但训练复杂度很高，几乎跟训练基座模型本身一样复杂，是个非常微妙的东西。
*DFlash： 小模型一口气同时猜出后面一串 token，猜得快，但前后 token 互相不沟通，容易猜出前后矛盾的“乱码”。；DSpark： 在 DFlash 的基础上，加了一个“修正模块”，让后面的 token 能看一眼前面猜了什么再调整。猜得准，速度更快。
Ali Taha： 直觉上，推测解码就像 iPhone 的自动纠错，你先用一个小模型快速生成三个候选 token，然后大模型一次验证。现在你的推测解码器本身也在做三次自回归，那为什么不再加一个更小的模型来预测它呢？递归下去似乎有理论上的可能性。但问题在于：如果你能训练一个“推测式推测解码器”，一个小模型能准确预测中间层推测解码器会预测什么，而中间层又能预测最终目标模型会预测什么，那你为什么不直接用那个最小的模型？
swyx： 推测解码器一般多大？比如 GLM 的推测解码器？
Ali Taha： 大概 10 亿参数。MiniMax 的话更小，就一层，通常是原始模型的 1/60 左右。
Philip Kiely： 实际上，推测解码器有一个实际约束：它必须和主模型跑在同样的硬件上。这里面有资源编排和竞争的问题。草稿 token 的生成要消耗计算资源，也需要软件层去管理这个复杂度。如果有“无限递归”的推测解码器，你不仅在训练层面增加了复杂度，在推理引擎的实现层面也是。而且有一个更根本的问题：如果你能训练一个“推测式推测解码器”，一个小模型能准确预测中间层推测解码器会预测什么，而中间层又能预测最终目标模型会预测什么，那你为什么不直接用那个最小的模型？
swyx： 所有这些都是在数据中心里跑的，对吧？有多少优化适用于“在 MacBook 上高效跑 Gemma”这种本地场景？
Philip Kiely： 我跟 Selo 在播客里聊过这个问题。数据中心推理和本地推理的根本区别在于：本地 AI 的命题是“怎么把这个模型塞进我的硬件，然后让它别那么蠢”，数据中心推理的命题是“怎么加载这个模型，然后让它别那么慢”。当然两边都关心对方的指标，但优先级完全不同。本地 AI 生态在量化，尤其是动态量化方面是专家，还有剪枝、蒸馏、层移除，这些技术他们在用，我们在数据中心基本不碰。但有意思的是，虽然他们的技术不能直接搬过来用，因为硬件条件和目标不同，但他们的“方法论”和整个社区的开放性，是很值得我们学习的。
Ali Taha： 比如 Turbo 量化，在本地设备上火得一塌糊涂。我们在 Twitter 上做过完整的技术深挖：它是什么、怎么工作、为什么有效或无效。它确实被广泛部署到本地设备上，因为 MacBook 的内存带宽太慢了。但同样的方法放到 NVIDIA B200 上，Turbo 根本不会有人用。NVIDIA 自己就明确说过这不是一个有效优化，我们也亲身体验过：在 kernel 里做动态量化的开销比省下来的访存时间还大，因为 B200 有 3.5 TB/秒的带宽，你不需要那么极端地去压存储。但在边缘设备上，它极其重要、极其有效。
swyx： 你们也做了很多模型并行的工作，尤其是跨异构拓扑的。
Philip Kiely： 本地 AI 在多机互联上面临的挑战比我们更多。他们在做的，比如 Exo Labs 那帮人，用一堆 Mac Mini 堆起来跑模型。我们在 Baseten 做了大量张量并行的工作，用节点内全部 8 张 GPU 把模型打散来跑。但张量并行对本地 AI 不友好，因为它需要非常高带宽的互联，比如 NVLink。本地 AI 可能被迫做流水线并行，那东西我们只在多节点推理时才会碰。
Ali Taha： 关于张量并行和专家并行：张量并行适用于任何模型，专家并行只适用于 MoE 模型，实际上今天所有大到值得跨多 GPU 并行的模型都是 MoE。专家并行的思路是把整个专家放在一张 GPU 上，通常专家数比 GPU 多，所以每张 GPU 上放多个专家，然后复制路由器，路由器很小，到每张 GPU 上。通过在 GPU 内部移动生成过程，它们不争抢跨卡资源，吞吐量大幅提升，GPU 间互联的重要性就降低了。张量并行要求做 all-gather（全收集） 和 all-reduce（全规约），你把模型完整地切分到所有 GPU 上，每一步都要合并结果，所以互联速度至关重要。一般来说张量并行对延迟有帮助，实际生产中经常是两种并行方式组合使用。
swyx： 流水线并行呢？
Ali Taha： 我们从来不用流水线并行。唯一要用流水线并行的情况是：如果你被逼到要做多节点推理，比如模型比单节点硬件能承载的还大，你把不同层拆开，一半层放一个节点，另一半放另一个。比如在 H100 上部署万亿参数模型，你不得不用多个 H100 节点。因为节点间互联太慢了，唯一可行的并行方式就是流水线。然后在每个节点内部再做专家并行和张量并行。H100 的瓶颈是 HBM，显存不够大。
Philip Kiely： B200 每张 GPU 是 180GB，一个节点 8 张就是 180 乘 8，FP4 下每个参数占 0.5 字节，所以能装下约 800GB 的模型。H100 是 80GB。我做这行久了，还记得 H100 的规格呢。
Ali Taha： 有一件事我一直觉得奇怪：为什么没更多人做像 Jamba 那样的事。AI21 的 Jamba 会针对特定硬件设计模型架构维度，能跑满那个硬件。为什么所有模型不都这样做？
Philip Kiely： 他们在训练侧可能会做类似的事情。
Ali Taha： 训练的话更像数学题，你可以算 FLOPS 然后最大化。推理更像自动调优，你定义“我有两张 GPU，可以做 TP1、TP2、EP1、EP2”这些组合，然后用真实流量做影子测试，看哪个配置给最好的 TPM/TPS，就用哪个。我不喜欢的是你没法先验地推理哪种配置最好，也没有一个配置永远最优。但自动调优就是找最优解的方法。kernel 和 GPU kernel 也是一样：你设计完 kernel，定义启动多少线程、用多少共享内存，然后就自动调优，扫参数空间，凭经验决定哪个最好。
Philip Kiely： 确实有一些训练是面向特定硬件的。比如 NVIDIA 的 Nemotron 模型在 Blackwell 上跑得非常好，这不意外。但大多数开源实验室是想让模型能在尽可能多的硬件上跑，而不是只针对某一款芯片。
Ali Taha： 关于“巨型内核”这个方向，我得说我比较看空。虽然直觉上你会觉得“有那么多启动开销，干脆把所有东西揉成一个大的算了”，听起来很理想，但实际写一个高度优化的巨型内核本身就是一件极难的事情。就算有些公司在尝试做这种方案，我问过的人都说，他们最后往往不会在生产环境里用，因为英伟达的 TensorRT-LLM 和 Modular 那些更细粒度的 kernel 跑得反而更快。你可以分别优化每个小模块，让它们各自跑各自的，还能并行起来，整体速度反而更优。而且从英伟达下一代 Rubin 架构的设计来看——他们技术负责人昨天刚发了推文公布规格——GPU 的硬件方向基本上把巨型内核这条路堵死了，以后你根本不需要大量用这玩意儿了。所以我觉得，这个研究方向可能也就这样了。
Philip Kiely： 说到英伟达的下一代架构 Rubin，我在书里也提过，算是提前做了点未来验证。我已经经历了三个硬件发布周期：Ampere（安培）、Hopper（霍珀）、Blackwell（布莱克韦尔）。从硬件发布到真正能拿来做推理，中间有很长的时间差。像 vLLM 这个推理框架，最早是针对 Ampere 架构写的，后来要更新适配 Hopper，再更新适配 Blackwell。每一代迭代都更快、更紧迫，但也更复杂。看 Rubin 的话，英伟达的 Dynamo 系统给了我很多技术上的提示，让我知道哪些工作会变得有价值。NVFP4（英伟达的 4 位浮点格式）继续是重点，Blackwell 上 NVFP4 张量核心的算力已经很大了。但更关键的是系统层面的变化：CPU 和 GPU 之间的互联、GPU 和 GPU 之间的互联被放到了更重要的位置。Dynamo 这个系统本质上就是围绕“怎么把 KV 缓存移到它该去的地方”来设计的。所以 KV 缓存卸载、KV 感知路由、预填充-解码分离这些方向，在 Rubin 时代会变得更重要。这意味着推理工程不再只是写 CUDA 内核的问题，而是一个很传统的硬件基础设施问题。从内核到硬件再到系统，能在这个多个层面之间都搞得懂的人，会变得非常有价值。
Ali Taha： 我再往前推一步。我觉得趋势是它正在变成一个纯粹的“基础设施问题”，预填充-解码分离、训练、推测解码、kernel 适配这些问题，未来可能不会成为大问题，因为 GPU 正在往 ASIC 方向演化。你不再是逐线程地控制 GPU，而是在更高的层面做编排。QTAL、QDSL 这些东西，你是在数据的“瓦片”级别工作，不再控制每个线程做什么，那些已经被底层处理好了。所以我问一个问题：你同不同意 GPU 和未来的 GPU 正在变得越来越像 ASIC，你只需要“启动”它，它自己就会完成数据操作？
swyx： 这是市场的一个方向。ASIC 在专有负载上当然性能更高，但 GPU 里的“G”（通用性）让它继续保持了通用性。
Philip Kiely： 我觉得这是一条光谱，从非常通用的计算到像 Taalas（AI 芯片初创公司，做的事情简单来说就是：把大模型“刻”进芯片里。）那样，把特定模型权重直接烧进芯片。我不觉得我们会走到那一步，但沿着光谱的方向，硬件正在变得更多专用化。
swyx： 我觉得 Ali 想说的是：如果不是把权重烧进芯片，那确实不实际，因为你要微调、要量化、要发布新 checkpoint，烧进去一个月就没用了。那你怎么能看着 NVIDIA 每一代都在加更多专用指令、专用张量核心、专用 MMA 指令，让 GPU 越来越像 ASIC，同时还对做 AI ASIC 的公司保持乐观？
Ali Taha： 我的论点就是这个。从 Ampere 到 Rubin，GPU 已经基本上是一个 ASIC 了。它当然还是通用的，有线程，你可以写 CUDA 去控制它。但它有了脉动阵列、张量核心、TMA、张量内存，这些东西几乎只对加载模型权重有用。它有了张量核心指令，这些指令几乎只针对当前市场上模型的头维度做优化。你说要做 ASIC、把东西蚀刻进去，但下一代架构出来它就过时了。
Philip Kiely： 嗯，我不确定。关键是硬件周期有多长。今天出来的芯片，设计工作在几年前就启动了。NVIDIA 在预测市场方向这件事上做得很好，他们当然拥有最多的信息。但你看今天开源的模型架构，和几年前的早期版本差不多。Rubin 其实是第一个完全在这个“新世界”里设计出来的芯片。所以你能看到他们理解了这个芯片要承担什么样的工作负载。
swyx： 我做不了直接回答这些问题的专家。但我会为一个方向做辩护：垂直整合的模型实验室做 ASIC，比如 OpenAI 和 Broadcom 做的那个什么芯片。Martin Casado 在播客里说过：如果你有一万亿或者五千亿美元的 training run，拿五百亿出来做 ASIC，完全合理，从 ASIC 那里拿到的效率提升远超 10%。所以模型专用芯片是有意义的。但 ASIC 公司，我觉得你过度关注 Taalas 那种方向了。他们做的更多是“表面积工程”，内存和硬件的实际分配、芯片间通信，这些东西可能 Rubin 不会碰。
Ali Taha： 我明白。真正阻碍 10 倍、1000 倍推理速度的，不是能在现有 GPU 设计里重新排列的东西。
swyx： 对，那些 ASIC 公司目标是 30 万 token/秒，不是闹着玩的。
Philip Kiely： 但我觉得很有意思的是，你做了这么多 kernel 工程工作，却对它这么“看空”。
Ali Taha： 我做得越多，越觉得它不是“大”的那种工作。
swyx： 我还想补充一点：模型是有代际的。你们这边看到的是 GLM、Kimi、DeepSeek、MiniMax，有些在做完全不同的东西，Gemma 没有编码器，最新的思考机器是从头写的。但另一边，GPT-5 这一代已经跑了多久了？当然有更多训练、有不同的 checkpoint，但你可以从中挤出不少东西。如果你砸了几十亿美元做了一轮训练，让它效率提高 X%，这个模型你要服务很久。Claude 5 也是一样。就算他们一年发一个新模型，如果架构上有些改动，你每年花 500 亿做新 ASIC，然后去年的 ASIC 就扔掉了。
Philip Kiely： 我不太同意。还是有人在用 GPT-4o，还有 Llama 3，不是 Llama 2，是 Llama 3。我还能看到 Llama 3 的流量。因为如果它已经做完了、被验证了、被信任了，那就别动它。这就是开源的一个承诺，你不用搞“Save Llama 3”运动，你只需要在某个地方有一台 8×H100 就行。
swyx： 我觉得在某个点上，问题变成了：如果一个模型能做好工具调用、能当智能体、能网络搜索、能写代码，你还需要继续往上卷吗？当然我们会继续，因为你们会让它更便宜、更快、更小，我可以直接换进去。但你给我 GLM 5.2 或者随便什么 120B 的模型，我能用好一阵子。
Philip Kiely： 这假设了你不需要更高的智能。
swyx： 我觉得很多场景需要的是可靠性和可预测性。企业场景下这个模型已经经过验证了，被 5000 个 stakeholder 签字通过了，我不会去动它。
Philip Kiely： 对，就是那种每天固定跑一次的批量任务，结果一直很稳定，不会出什么意外。企业一旦把这种流程跑顺了，就不会轻易动它。
swyx： 是的。当然新东西会更稀疏、更便宜、更好，但这不意味着旧模型比如 GLM 50 就不能用了。如果我们遇到某种“停滞”，还有大量潜力可以挖掘。
视频为什么还很落后？token 太多，注意力太贵
swyx： 我们聊了很多 LLM，那音频和视频呢？推理工程的另一面是什么？Ali 你在视频扩散方面比较熟。
Ali Taha： 视频扩散模型在很多方面跟 LLM 很不一样。它不是自回归的，你不做批处理，每个请求进一张 GPU，一张 GPU 服务它。模型也小得多，比如 Wan 2.2 是 200 亿参数，比最好的 LLM 小一个数量级。但开源和闭源的差距在视频领域比 LLM 大得多。LLM 领域开源和闭源的差距已经很小了，以前说差 6 个月，现在我觉得已经不是 6 个月了，基本快追平了。视频模型绝对不是，差距巨大。开源视频模型比如 Wan 2.2，跟 Kling 或 Veo 比，质量差得天壤之别。这就导致媒体公司绝大多数时候还是选闭源模型。如果我跟你说“我能用这个开源模型给你生成整部 3 小时电影，优化到只要 10 美元”，而闭源要 1000 美元，我便宜 100 倍，他们还是会选闭源，因为质量差距摆在那。
Philip Kiely： 这就成了鸡生蛋蛋生鸡的循环：需求少导致投入少，导致开源 checkpoint 发布少。一些曾经发布开源模型的实验室也开始闭源最新版本了，比如 Wan 2.7 就没开源，我们还停在 Wan 2.2。
Ali Taha： 视频模型的核心瓶颈是 token 数量。你要生成高质量视频，16 帧/秒是最低标准，480p。你看 token 体量：就四帧的视频，如果做全注意力，稍微往上一点，480p 乘 720 乘 81 帧，也就是 5 秒钟（16fps 乘 5），压缩到 latent space 之后你仍然在做 30 乘 50 乘 21 的 token 矩阵。这意味着 5 秒钟的视频，注意力要在 3.5 万个 token 上运算。注意力是平方级的复杂度，5 秒、10 秒、20 秒、30 秒，要生成 1 分钟的好片段，在同样的计算预算下几乎不可能。所以你只有两条路：要么在整个视频上做全注意力，被迫做稀疏注意力，每个 token 只关注最相关的 12.5%，比如代表王冠的 token 只关注头部、面部、前一帧和后一帧，但这会严重伤害质量。要么转向自回归视频。自回归视频在我看来是未来的方向，但今天没有好的开源自回归视频模型。如果你想得到小时级别的电影、想让视频模型生成好莱坞级别的作品，它们必须是自回归的，或者计算能力出现某种飞跃，能高效地在百万级 token 上做全注意力。
swyx： 自回归视频的优缺点是什么？比如一致性方面，你生成 10 分钟后会“遗忘”前面的内容？
Ali Taha： 自回归模型的好处是你可以把 LLM 的优化，推测解码这些，直接搬过来用。如果有高质量、大规模的自回归视频模型，你可以做流式输出：先显示第一帧，然后像 2023 年的 GPT 一样边生成边看，视频就是边生成边播放。缺点是每个自回归视频模型目前质量都很差。跟 Wan 2.2 比，自回归模型生成的东西就像 Tom and Jerry 的劣质仿版。所以生成长视频的变通方案成了“不做纯自回归”，比如 Grok Imagine 做得很好的是把 7 秒的片段拼接起来：生成 7 秒，然后问“能不能扩展这个视频？”，再把两段拼在一起。开源没有这些技巧，闭源我们也不知道具体怎么做的。你能做的最接近的是取最后一帧，喂给“文本+图像到视频”模型，让它生成下 5 秒，这样不断扩展。但你会产生“漂移”：第一段 5 秒质量高，第二段低一点，第三段更低，第四段更低。有时候你看到新视频比前一个暗一点点，下一个更暗，到 25 秒就黑屏了。我们试过做一个 demo 来展示这个问题，但实在太尴尬了，最后决定不发了。我觉得模型最终能做到，需要大幅扩大规模并转向自回归，但训练方法还不清晰。
Philip Kiely： 核心区别在于：扩散是双向的，自回归只能向前。这就是为什么如果你简单地把视频生成建模为线性帧序列，它会跑偏，你不能回到序列里修正某个东西来让整体一致。而扩散模型把所有 token 保留在内存里，迭代整个序列，你可以“回头”调整过去来让未来更合理。所以能带我们走向更长、更丰富序列的架构，很可能是自回归和扩散的混合体，让各自的优势部分发挥作用。
Ali Taha： 直观上你能理解为什么。语言本质上就是从左到右的，你可以流式输出 token、流式输出思维链，人写作的时候，就是写了然后想下一个要写什么，继续往下写。当然你有时候需要回头编辑，但需要回头的频率比你以为的低。视频不一样，左上角的像素和右下角的像素几乎同等需要互相“看见”来保证整体质量，而文本没有这么强的全局依赖。
swyx： 那音频呢？大概一年前有音频 LM、音频扩散、自回归，现在基本切换到自回归了。
Philip Kiely： 音频里的语音部分肯定是自回归的。一年半前的 Orpheus 架构就是你把波形加到词汇表里，LLM 就能输出代表波形的 token，然后构建语音，这就是流式传输的方式。音乐的话有段时间扩散和自回归都有，两者质量差不多。
swyx： 另外，图像方面 Nano Banana 和 GPT Image 已经是自回归图像了，是混合方法。虽然还没进视频空间，但应该不会太远。扩散文本这边也有动静，比如 Mercury，你们托管了。扩散 Gemma 是开源的。还有虚拟细胞模型也在用扩散。但扩散文本还是在“便宜、快 token”的世界里。我觉得营销方向错了，你打不过 LLM 的优化，但你可以有不同的 API，比如做诗歌、做情节结构，让内容“扩散”到位。诗歌就是个好例子，LLM 到今天还是搞不对音节，如果能跨所有 token 做注意力，就能把音节搞对。
Ali Taha： 但最重度使用的模型里没有一个在用扩散文本。
swyx： 这是个鸡生蛋的问题，如果你给它更多规模呢？
Ali Taha： 最大的扩散 LLM 有多大？好像不大，扩散 Gemma 是 25B。
Philip Kiely： 对，在它的规模上质量不错。
Ali Taha： 这跟视频模型的问题一样，你在拿它跟规模大得多的模型比。
模型已经开始自己优化自己
swyx： 推理工程以前就是“拿个开源模型让 GPU 跑起来”就结束了。现在看起来，人们越来越多地用推理来做后训练，训练和推理正在融合。
Ali Taha： “推理服务于训练”这一点很明显：做强化学习训练的时候，需要先让模型去跑一些样本数据生成结果（也就是做一次推理），这个过程叫“展开”。如果这个“展开”步骤太慢，整个训练流程就会被卡住，只能干等着。如果当前模型不被像 vLLM 这类高性能推理框架支持，你就只能退回到更慢的旧推理引擎上去做“展开”，速度一下子就下来了。而且你肯定不想在偏离当前策略太远的“展开”结果上去做训练，因为那样效果不好，所以整个训练管线就堵住了。反过来，“训练服务于推理”主要体现在推测解码器的训练、Eagle 这种推测解码方案的训练，以及后训练这些环节上。比如你要把一个模型量化到 NVFP4 这种 4 位精度格式，有时候运气好，直接做训练后量化就能用；但有时候量化完质量掉得太厉害，你就必须在模型上做额外的后训练，让它学会在低精度下还能保持原来的输出质量。你可以用普通的监督微调，也可以用专门针对量化设计的训练方法。越来越多的新技术也在往这个方向走，比如英伟达发过一篇论文，做法是：同时保留一个低精度版本和一个全精度版本，然后让低精度版本去模仿全精度版本的输出分布，通过这种“蒸馏”式的训练来弥补量化带来的损失。所以现在我们的推理工程师越来越需要懂训练技术，得会写训练代码才行。
swyx： 最终目标是不是一个“持续改进”的系统？
Philip Kiely： 这其实已经在发生了。未来几个月到几年内，领先的智能体构建者会在生产环境里真正跑通这种循环，你一边做推理，一边从推理中学习。我们已经做了很长时间的在线动态调整，任何动态调整都会优于静态配置。然后你可以从产品中生成 trace，持续后训练模型，做 A/B 测试，获得更好的信号，得到更好的模型和产品。这个循环非常有前景，支撑它的技术和基础设施正在快速成熟。训练和推理的统一化只会加速。
swyx： 我们有“模型训练模型”，下一步显然就是“模型优化自己的推理”。
Ali Taha： 我们内部有一个很具体的例子。GLM 5.2 非常擅长写 GPU kernel。我们搞了一个 GLM 5.2 端点，接在我们的云代码工具链里。每个工程师都用我们的 GLM 5.2，它对 GLM 5.2 实例做一次前向传播，拿到性能追踪数据，分析出 SGLang 里的瓶颈 kernel，然后自己重写这些 kernel，再做一次性能追踪，完成后把镜像上传到我们的仓库，我们拉下来，重复这个循环。所以有一段时间，我们推理引擎里的 GPU kernel 相当一部分是 GLM 5.2 写的，整个优化过程是由 GLM 5.2 驱动的。这个循环确实是真实存在的。当然模型还有很多做不了的事，它们还不够强，会试图“奖励黑客”走捷径，决策能力还很差。但模型优化自己的推理已经是真实发生的事情了。
swyx： 你觉得 GLM 5.2 在优化自己这件事上是特别擅长，还是说它只是我们当时能拿到的最好的编程模型？换 DeepSeek 或 Kimi 来干也一样？
Ali Taha： 有些人会说，当它去优化一个完全不同的架构时可能会“策略偏移”。但我不信那个。试试就知道了。
下一个大瓶颈：网络速度
swyx： 我们没来得及聊的推理工程趋势还有什么？
Philip Kiely： 大方向很明显：模型更大、硬件更强、用户习惯了一定速度之后会要求更快。我兴奋的是系统层面的东西，组合多个模型、新模态、语音到语音还没有完全解决。还有继续在 10 倍、10 倍、10 倍的规模上运作。看 AI 在全球的渗透率，跟更成熟的技术比，需求量可能还有好几个 10 倍的增长空间。所以还有海量问题要解决。
Ali Taha： 我的答案可能听起来很无聊，但就是更快的网络，更快的芯片间通信。越来越多的时候，内存是瓶颈。你想跑更大的模型，现在大规模服务时你要把 KV cache 从一个节点传到另一个节点。但具体怎么传？找到 KV cache，确定它在哪，传到另一个节点，放到那个节点的内存里，再从内存传到 GPU 的张量核心。这中间有两级传输，让你在 KV cache 传输上严重受限，拖累解码和预填充的时间。HBM 极快，4.5 TB/秒，比节点间通信快好几个数量级。如果你能在理想世界里做到极快的节点间通信，就能省掉中间那一步，直接把 KV cache 从一个节点传到另一个节点。这能让节点间的聚合服务速度提升接近 100 倍。当然我不清楚做更快网络的技术挑战是什么，肯定有物理或工程上的原因导致它们比 HBM 慢这么多，但如果有人能解决这个问题，解码速度会直接提升两个数量级。
swyx： 最后一个趋势提名？
Philip Kiely： 推理工程用于持续学习。如果你要从处理过的所有东西中学习，你会改变什么？还是说保持现有范式，放进记忆里、被 KV cache 消耗掉，就够用了？
Ali Taha： 关键问题是：你怎么重塑推理让它边推理边学习？KV cache 压缩是一个相关方向。Charlie 和我之前在 Twitter 上争论过这个问题。持续学习有两条路：要么模型学到了，持续把新知识推进权重里，那推理只需要持续拉新权重；要么做 KV cache 压缩，加一个 LoRA 层，只更新 LoRA。反对“推权重”路线的理由是：你只能“注入”一个孤立事实，比如“世界上最好的大学是滑铁卢大学”，但第二层问题呢？“我应该从哪个大学招实习生”？如果你刚把“滑铁卢是最好的”写进知识库，那“从哪个大学招实习生”的推理答案应该用上这个信息。但模型不会自动做这件事，它记住了事实，但没有用它来推理。这就是试图在 MLP 里改一个事实的根本问题。KV cache 压缩，或者说像我们发表的“Still”论文里做的那样，能让你的 KV 几乎无限，压缩方式让你不丢失任何知识，这样你就能真正做持续学习。在这个方向上，Charlie 是对的，我承认他的观点正确。KV cache 是前进的方向。那样的话推理本身不会大变，因为你还用 KV cache，只是多了一步更新 KV cache，权重不变，所以推理时间不变，推测解码器也不变。
Philip Kiely： 非常好，我们刚发了相关的博客，大家可以去看看。
swyx： 太棒了，聊了整整两个小时，完全没意识到时间过了这么久。感谢你们这么慷慨地分享，推理工程这个话题我们从来没有这么深入地聊过。
Philip Kiely： 谢谢邀请，希望一年后一切都变了，我们可以回来说“我们之前说的全是错的”。
Ali Taha： 我等着“mega kernel”那条评论发出去，看看大家怎么说。
Philip Kiely： 我要不要躲起来？我知道 mega kernel 社群会来找我麻烦的。
Ali Taha： 我特别欣赏你的一点是，你从来不害怕捅马蜂窝。
Philip Kiely： 我觉得没那么有争议。谁知道呢。
swyx： 走着瞧。谢谢大家！
