推理工程大师课：自回归和扩散模型的部署优化

推理工程大师课：自回归和扩散模型的部署优化 | 前端进阶之旅

Full translation

完整中文译文

我们去年首次报道 Baseten 时，DeepSeek 热潮正处于炒作顶峰。如今，他们已经完成了一轮规模惊人的融资，公司估值达到 130 亿美元，并成为新一批 AI 基础设施十角兽之一；与 Nvidia、Intel 及半导体产业链一道，它们都是“推理拐点”的主要受益者。

在 2026 年新一轮开放权重争论最激烈之际，我们再次将目光投向 Baseten。Ali 发布了一篇对 Kimi K3 的拆解文章，并迅速走红：

自从你上次见到 Philip 以来，他已经在 AI Engineer 大会上发表演讲，还撰写了堪称推理工程权威之作的书，如今在旧金山随处可见：

三年前，“推理工程”几乎还没有作为一个独立领域存在。

如今，它已经成为 AI 领域最关键的学科之一。推理工程所解决的问题，本质上不同于常规的模型训练：“如何把训练得到的那些权重，转化为一个在大规模运行时快速、可靠且成本可控的产品？”聚焦这些目标，会产生一套全新的优化问题。

在最近一次 GLM-5.2 实验中，对模型更多部分进行量化，实际上既保留了模型的基准测试质量，又将吞吐量提升了 20%，因为不同层中引入的误差可以相互抵消。

推理不再只是训练完成后的最后一步。它正在成为一门独立的工程学科，拥有自己的研究问题、基础设施，以及日益专业化的岗位。

本期节目中，Baseten 的 Philip Kiely 和 Ali Taha 与 swyx、Vibhu 一起，解释一个新的开放模型发布后究竟会发生什么，以及如何将“我们生成了一个 token”变成快速、可靠且可用于生产环境的 API。

我们深入探讨了缓存感知路由、预填充与解码分离、量化、推测解码、KV 缓存迁移、模型并行、GPU 内核，以及让前沿模型速度提升至多 10 倍的竞赛。Philip 和 Ali 解释了为什么推理优化仍然可以带来 20%、100% 甚至 200% 的提升；量化误差如何相互抵消；为什么相同权重在不同集群上的表现可能不同；以及 Baseten 如何在不改变底层语言模型的情况下，将 Kimi 的视觉编码器嫁接到 GLM-5.2 上。

随后，对话从 LLM 扩展到 NVIDIA Dynamo、巨型内核、Rubin、AI 专用芯片、本地推理、视频生成、扩散模型与自回归模型之争，以及生成连贯长视频所面临的巨大算力壁垒。最后，我们探讨了训练与推理的融合、通过持久化 KV 缓存实现持续学习，以及模型帮助优化其自身运行基础设施的新兴闭环。

当一个包含 200,000 个 token 的请求进入推理系统时，会发生什么

缓存感知路由与复用此前计算的 KV 缓存

为什么预填充和解码越来越多地由不同的 GPU 处理

专用部署何时会比共享 API 更便宜、更可靠

推测解码如何使用较小的模型加速较大的模型

工具调用、结构化输出，以及 LLM 实际上在做什么

首日支持一个新的开放模型需要做些什么

将 Kimi 的视觉编码器嫁接到 GLM-5.2 上

使用其他架构中的组件改造低效的模型层

为什么模型有时会崩溃为不断重复同一个 token

硬件、内核与竞态条件如何造成非确定性故障

在提高推理速度的同时保持模型保真度

量化误差如何相互抵消

为什么推理优化仍能带来 20%、100% 和 200% 的提升

经过优化的服务如何让模型速度提升至多 10 倍

NVIDIA Dynamo、KV 感知路由与分布式模型服务

对推测解码器进行推测解码

为什么本地 AI 的重点是让模型不那么笨，而数据中心 AI 的重点是让模型不那么慢

跨 GPU 的张量并行、专家并行与流水线并行

硬件感知的模型设计、自动调优，以及反对巨型内核的理由

Rubin，以及为什么推理正在成为一个系统工程问题

现代 GPU 是否正在演变成可编程的 AI ASIC

为什么 Kimi K3 这样的超大模型需要 GB300 级硬件

为什么开源视频生成仍然落后于 Veo、Kling 及其他闭源模型

长视频 AI 生成背后的二次方注意力瓶颈

自回归视频、实时生成与不断累积的质量漂移

为什么未来的视频系统可能会结合自回归架构与扩散架构

面向推理进行训练，以及利用推理辅助训练

持续的后训练、部署、评估与改进闭环

GLM-5.2 如何帮助优化为 GLM-5.2 自身提供服务的内核

为什么更快的网络能够显著提升解码速度

持续学习、KV 缓存压缩与持久化模型记忆

如何为 Kimi K3 构建首日可用的 API

22580：从 GPT2 到 Kimi3，详解

LinkedIn: https://www.linkedin.com/in/philipkiely

X: https://x.com/philipkiely

推理工程：https://www.baseten.co/inference-engineering/

LinkedIn: https://www.linkedin.com/in/aliestaha/

X: https://x.com/waterloointern

00:00:00 开场与 20 万 token 的提示词

00:03:18 专用部署、推测解码与工具调用

00:11:26 发布可用于生产环境的开放模型

00:19:06 模型改造、故障模式与非确定性

00:28:22 量化与误差抵消

00:32:15 推理速度提升 10 倍的竞赛

00:40:48 Dynamo、推测技术，以及本地 AI 与数据中心 AI

00:50:18 模型并行、自动调优与巨型内核

01:00:55 Rubin、GPU 与 ASIC，以及定制 AI 芯片

01:10:03 超大模型与 GPU 显存的极限

01:12:42 AI 视频、二次方注意力与自回归生成

01:21:47 音频、图像与扩散模型

01:27:32 训练、自我优化模型与持续学习

01:40:06 结束语

开场：Baseten、Waterloo Intern 与推理工程

Swyx [00:00:00]：好的，我们现在和 Philip 一起坐在演播室里。他是我的老朋友，来自《Inference Engineering》这本书，也来自 Baseten；我们之前各自以及共同做过的所有事情，大家应该都很熟悉。此外还有 Ali。欢迎二位。

Ali [00:00:15]：很高兴见到你。

Swyx [00:00:15]：Waterloo intern。

Ali [00:00:16]：永远都是 Waterloo intern。

Swyx [00:00:17]：你什么时候把“Waterloo intern”用作账号名的？

Ali [00:00:19]：用作账号名？哦。

Ali [00:00:20]: 我觉得这次改名是在三月中旬发生的。当我看到这个机会开放时，我想，"我一定要抓住这个机会。"

Philip [00:00:26]: 问题是 Ali 工作做得真的很好，不会当实习生太久了。

Philip [00:00:30]: 所以我们得想清楚谁会接下来管理这个账号。

Ali [00:00:33]: 嗯，我会把这个接力棒传给下一个实习生。

Swyx [00:00:34]: 哦，好的。就像，你可以把它传给另一个滑铁卢大学的毕业生。

Ali [00:00:37]: 传给另一个滑铁卢大学的实习生。不，伙计。

Philip [00:00:39]: 是的。

Ali [00:00:39]: 实习生。

Swyx [00:00:40]: 实习生，是的。

Ali [00:00:40]: 不是毕业生。

Philip [00:00:41]: 你得从滑铁卢大学招一个实习生。

Ali [00:00:42]: 是的，我得从滑铁卢大学招个实习生。

Swyx [00:00:44]: 对。

Ali [00:00:44]: 但他们得走这条路。

Swyx [00:00:45]: 哦，可以，不过也可能来自 Baseten，所以就是 Baseten 从滑铁卢招来的那个人。

Ali [00:00:48]: 对。

Swyx [00:00:49]: 拥有滑铁卢账号的头衔。

Ali [00:00:50]: 它就留在这个生态里。

Philip [00:00:51]: 完全同意。

Ali [00:00:52]: 实习期中途，你要么升职，要么出局。

Philip [00:00:55]: 你们还应该搞个盛大的毕业典礼，改一下账号。

Ali [00:00:59]: 就这样说吧。

Philip [00:00:59]: 给所有人看。

Swyx [00:01:00]: 你们显然很擅长举办典礼。我们搞过一个很成功的新书发布会。但在深入讨论这些之前，我想从一个有趣的问题开始。好的，你是推理工程方面的专家。当我发送一个很长的查询，比如二十万个 token，到 Baseten 的推理系统时会发生什么？从 GPU 模型路由、均衡来看，完整的流程是什么？那些我们通常不会想到的东西是什么？

长上下文请求、KV缓存和缓存感知路由

Philip [00:01:26]: 针对一个长查询，我首先要问的是，"你之前给我发过这个查询吗，或者至少发过它的一部分？"我真的很希望你发过，因为这对我来说会容易得多，对你来说也会便宜得多。首先我们要看的是缓存感知路由，在这种情况下，我们可能有多个实例、多个副本在运行你要访问的任何模型。我们想把这个请求发送到有以下特点的地方：第一，有可用的预填充 worker，第二，理想情况下已经有一些缓存的输入，这样我们至少可以跳过这二十万个 token 中一部分的预填充。如果你在做二十万个 token，这可能是编程或多轮对话智能体的场景，你应该期望会有缓存。如果没有，我们就得把请求发送到一个预填充 worker。在某些模型上，我们已经将预填充和解码分离了，所以你会有一组 GPU 专门处理输入、创建 KV缓存、获取第一个 token，然后这个结果会被传递给另一组 GPU，它会运行解码。我们会迭代地生成那些 token。我们前面可能还会有一个推测器模型。我假设你在做编程，因为这样的话，我们的推测器模型——它假设你在做编程——就会有很高的草稿 token 接受率。如果我猜错了，你其实是要我总结每部《哈利·波特》书，那就会慢一些。然后我们把输出流式传输给你，计算成本，对你收几分钱，然后说，"你还想发一个吗？"

Swyx [00:03:04]: 除了 Baseten 不是按分钱来收费。

Philip [00:03:07]: 是的，我们确实收费。我假设我们讨论的是公开模型 API。如果你是在设置一个专用部署，那么是的，就不是分钱了。

公开 API 与专用部署

Swyx [00:03:18]: 是的，我最初和 Baseten 交流时的一个关键区别是，那些需要超高流量的人只需要按盒子租赁，因为那样的话就由你来想办法怎么充分利用这个盒子。

Ali [00:03:31]: 更多情况下，比如你每小时处理几百万个 token，按小时付费而不是按 token 付费会便宜得多。

Philip [00:03:37]: 是的，确实是这样。我觉得我们越来越看到对按 token 付费 API 的需求，因为每个人都想试试开源模型，一旦他们找到了真正粘性强的用例，就会转向专用部署。

Swyx [00:03:51]: 有没有最佳实践来判断什么时候该切换？

Philip [00:03:54]: 有几个原因。是的，可靠性是其中一个很重要的。

Ali [00:03:57]: 比如，如果他们有一个很特定的用例，他们会希望你为他们专门训练什么东西，比如他们想要自己的推测解码，适配他们自己的流量。

Swyx [00:04:04]: 推测解码是 Speculative Decoding。

推测解码和自定义推测器

Ali [00:04:05]: 推测解码，是的。

Swyx [00:04:07]: 你得解释一下。

Ali [00:04:07]: 抱歉。就是说，推测解码是这样的——如果你有一个巨型模型，对吧？那么这个模型每一轮、每一次前向传播都会生成一个 token。所以我们会添加一个小的、像一个寄生虫一样的层在模型上面，这个模型只需要预测。它做三次非常快速的自回归前向传播，会预测三个确定的 token，然后你对整个原始模型做一次前向传播来验证这些预测是否正确，然后接受或拒绝它们。现在，这个草稿模型是针对特定流量的，所以如果你像 Philip 说的那样，如果你在总结《哈利·波特》书籍，我可以专门用《哈利·波特》书籍的数据来训练这个草稿模型，我可以保证每次都会接受这三个 token。通过这种方式，我提高了你的解码速度。但如果你在共享端点上，我就没办法给你提供这个功能

Swyx [00:04:53]: 是的

Ali [00:04:53]: 因为我不知道你是在做《哈利·波特》、在做编程还是在做英文。我们不知道。另外，书里提到过一个东西，如果他们真的关心某个特定阈值的话，我记得是第四章。你还记得吗？

Philip [00:05:06]: 是的。你可以做的事情包括设置特定的批大小、特定的并行策略，如果你试图优化吞吐量和延迟的话。也许一个 NVFP4 量化不符合你的基准测试标准，你想用更高的精度运行模型，你可以这样做。有一大堆理由让你可能想要自己的端点，当然最大的原因就是，你不用处理别人在你试图服务用户的时候对这个端点进行一亿个 token 的基准测试流量。

Swyx [00:05:40]: 是的。我想这是一个经典的发展历程。就像人们问的那样，当你在浏览器里输入 Google 时会发生什么。工具调用，这就只是生成 JSON 还是还有其他的复杂性？

工具调用、JSON 和结构化输出

Ali [00:05:58]: 我们的某些客户有自己的后训练模型，所以他们要求的工具调用不仅仅是解析文件或查找天气这种东西。那是一个非常特定的东西，你必须对这个模型进行后训练。而且如果模型上的后训练不好，或者后训练之后的量化为了让推理变快而质量下降，那么模型就会在读取 JSON 文件和工具调用时遇到困难。但这不需要自己的沙箱。这不像工具调用会被用来逃逸沙箱或必须被限制在某个范围内。它就可以是一个普通的专用部署。工具调用的挑战越来越多地似乎是公司要求特定的工具调用，这是一个训练时非常敏感的东西。而且因为你在处理所有的 JSON 输出，如果模型没有以非常特定的方式关闭请求的末尾，你最终会得到一个完成了工具调用和思考的模型，因此作为解码的结果，它没有看到结果，只是幻觉生成了结果。这似乎是工具调用最具挑战性的地方，真正不是沙箱模型问题。

Philip [00:06:56]: 是的，这是训练方面的一个挑战，然后在推理方面，你可以做一些工作来限制可能的输出。我们大约两年前发布过这个问题的解决方案，就是你构建一个状态机并用它来将输出限制在特定的格式。这就是结构化输出问题。如果你还记得的话

Swyx [00:07:27]: 是的，特定的语法是

Philip [00:07:29]: 是的，完全同意

Swyx [00:07:30]: GML 有这个功能。

Philip [00:07:31]：对。所以这就像那种老派提示词：“确保输出只能是 JSON”、只返回 JSON，否则——

Swyx [00:07:38]：对。

Philip [00:07:38]：奶奶就要死了之类的提示词。

Swyx [00:07:39]：是 BNF 文法吗？OpenAI 之前曾经发布过一个东西，大概就是说，如果你想约束输出，就编写 BNF 文法，用 NOR 的形式返回。

Philip [00:07:47]：在我们的推理系统中，它只是一个指定的输出格式。你可以获得保证，输出会按照该格式进行结构化。因此，把它应用到工具调用中，可以帮助减少一些问题。模型仍然可能调用错误的工具，或者根本不调用工具。它无法解决确定性问题，但至少解决了输出结构化的问题——

Swyx [00:08:10]：对。

Philip [00:08:10]：至少在工具调用中是这样。

Swyx [00:08:12]：而 MCP 也只是工具的另一种形式，对吧？

Philip [00:08:14]：对，完全正确。

Swyx [00:08:15]：就这个层面而言，它并没有什么特殊之处。

Philip [00:08:16]：我总是在向人们解释的一点是，LLM 本身没有能力执行任何事情。它只能提出应该做什么的建议；然后，如果这些建议以某种特定格式呈现，并被应用到一个知道如何处理它们的系统中，才会真正发生相应的操作。

Swyx [00:08:32]：对。有意思的一点是，这个问题在工具调用之外也能得到解决。比如在智能体循环中，如果输出不正确，或者像你说的，推理和工具调用发生在推理轨迹中，模型就可以说：“哦，我不知道该怎么办。让我再试一次。”尝试几次之后，它可能就能得到正确结果。再接着你关于训练的观点，有时这对较小的模型来说会更困难，所以从大模型直接切换过去之后，得到的输出质量不会完全相同——

Ali [00:08:56]：对。

Swyx [00:08:57]：对吧？

Ali [00:08:59]：对。不过我得说，在此之前，我觉得我们需要回到真正的推理工程上。

Ali [00:09:04]：但我原本预计会有某种东西取代 JSON，因为 JSON 很难进行流式传输：JSON 必须是完整的，必须有配对的左括号和右括号，以及其他所有内容。因此，在内容流式传输的过程中，很难对其进行解析或验证。于是人们发明了各种各样的替代方案，我忘了其中一些叫什么，但可能是类似 TOML、类似 YAML 的东西。不过目前来看，JSON 似乎仍然占据主导地位。

Philip [00:09:30]：JSON 输出通常不会那么长，对吧？它也可能很长——因为工具调用中还包含参数，对于某些工具，你可能会传入一个非常长的参数。不过就我的印象而言，典型工具调用的 token 数量相对较少，对吧？因此我预计，推测模型通常很擅长处理 JSON 这种格式规整的内容。这样一来，解码步骤就会非常快，流式传输的价值也没那么大。不过也可能是我错了。

Ali [00:10:02]：我觉得你还会受到模型要集成的软件的限制。如果软件本身使用 JSON 进行工具调用，或者你的客户告诉你，他们的软件就是这样工作的，工具接口使用 JSON，那么你当然可以要求他们修改软件，并对他们说：“对，这样对模型会更好。”但只要训练得当，差异应该也不会太大。而且如果模型输出更多 token，可能还会更赚钱。

Swyx [00:10:25]：这取决于你的商业模式。

Swyx [00:10:27]：确实非常取决于商业模式。不过我得说，作为一名经常处理生成内容的作者，我确实会尝试从纯文本转向 JSON 文本，而这种 JSON 会非常长，对吧？比如每个字段中都有若干段落，因为我正在尝试对内容进行结构化，对吧？

Philip [00:10:44]：对。

Swyx [00:10:44]：我希望你先陈述事实，然后发表观点，再给出要点摘要，还要包含日期、实体引用和参考来源，所有这些东西。总之，我觉得真正深入尝试结构化输出的人，必须认真考虑这些问题。不过，我们稍微沿着技术栈往上回溯一下。开始录制之前，你提到了一件非常酷的事情：当一家新的模型提供商发布新模型时，会涉及大量工程工作——也就是推理工程，对吧？比如我们把它叫作 GLM-5.2、Kimi K3。我之前一直以为，尤其是像从 GLM 5 到 5.1，再到 GLM-5.2 这种情况，你们以前已经支持过这些模型了。还需要那么多工作吗？

支持一个新的开放模型需要做些什么

Ali [00:11:26]：工作量非常大。

Swyx [00:11:28]：对。好吧。比如每次有新模型发布时，很多人——包括你们——都会争先恐后地说：“哦，Hugging Face 已经支持它了，Fireworks 已经支持它了，Spacetime 已经支持它了。”而我会想：“对，当然会支持。”但这背后需要做些什么？具体包括哪些工作——

Philip [00:11:40]：我觉得这还不只是“支持”而已，对吧？它会给消费者带来很大好处。比如最新的 Kimi K2.5 或 GLM-5.2 发布时，就发生过一场推理大战，对吧？某个提供商的速度是每秒 90 个 token。第二天，我们达到了每秒 150 个。接下来——

Swyx [00:11:55]：GLM-5.2 的这场竞争某种程度上是我挑起来的。

Swyx [00:11:58]：我在 Twitter 上写了一篇相关文章，获得了大约 50 万次浏览。

Ali [00:12:02]：是因为排名第一——

Swyx [00:12:03]：对。

Ali [00:12:04]：还是因为别的什么？

Swyx [00:12:05]：对。然后——

Ali [00:12:06]：我的天。

Swyx [00:12:07]：然后所有人都对此非常兴奋：嘿，我们还能怎样进一步挑战极限——

Philip [00:12:14]：“支持这个模型”存在两种不同的含义。一种是“我能让这个模型生成一个 token”，另一种则是“我能为这个模型提供生产级 API”。

Philip [00:12:26]：做到“我能让这个模型生成一个 token”并没有那么困难，因为通常情况下，像 vLLM、SGLang 这样的开源推理引擎，往往会提前拿到模型权重——至少其维护者会提前拿到——或者模型开发者会合并 PR，以便——