来自 Baseten 的推理工程（Inference Engineering）大师课 (Philip Kiely & Ali Taha)

▍嘉宾：菲利普·基利 (Philip Kiely)

菲利普·基利是技术作家出身的推理工程师，常年在「写作者」与「工程师」两个身份之间来回切换：

• 《推理工程》作者：2026 年出版 Inference Engineering。他在节目中说，写这本书有两个目标：给整个行业一套「能用的词汇表」，并帮读者建立对每项技术如何工作的直觉。Swyx 当面评价它是「Baseten 史上 ROI 最高的一件事」。
• Baseten 推理工程师：一线参与新开源模型的 day-zero 上线工程；书中内容还在持续演化——他在 AI Engineer 大会上的演讲被他称为这本书的「首个公开增补」，因为推测解码领域的演进速度已经超出了成书时的版本。
• 技术写作者：早年合著过面向开发者的写作指南 Writing for Software Developers，与主持人 Swyx 相识多年、合作过多个项目。

▍嘉宾：阿里·塔哈 (Ali Taha)

阿里·塔哈是 Baseten 的一线推理工程师，滑铁卢大学出身，研究方向覆盖推测解码、视频扩散与 GPU 内核优化：

• 实战派优化者：节目中大量最硬核的细节出自他手——按流量场景定制草稿模型、用真实生产流量做并行配置的影子压测、把 Kimi 视觉编码器嫁接到 GLM-5.2 的 Franken-merge，以及让 GLM-5.2 给自己的推理引擎写内核的闭环实验。

▍关于 Baseten

Baseten 2019 年创立于旧金山，三位创始人图欣·斯里瓦斯塔瓦 (Tuhin Srivastava, CEO)、阿米尔·哈吉加特 (Amir Haghighat, CTO) 与菲利普·豪斯 (Philip Howes, Chief Scientist) 相识于 Gumroad，从模型部署的亲身痛点切入，做出 AI 推理基础设施平台：开源打包框架 Truss、按 token 计费的共享端点，以及按整机租用的专用部署 (dedicated deployment)。

• 规模：平台日处理超 10 亿次推理请求，跨 18 朵云、87 个集群运行；2026 年 3 月年化收入约 6 亿美元，同比约 20 倍增长。
• 融资节奏：估值从 2025 年 9 月的约 21.5 亿美元，到 2026 年 1 月的 50 亿美元（3 亿美元 E 轮，IVP、CapitalG 与英伟达领投），再到 2026 年 6 月的约 130 亿美元（15 亿美元 F 轮，Altimeter、Conviction、Spark 领投）——堪称 AI 推理基建赛道重定价速度的样本。

引言

Swyx： 今天请到了老朋友菲利普·基利（Philip Kiely）——《推理工程》（Inference Engineering）一书的作者，来自 Baseten，我们以前也合作过不少事情——还有阿里·塔哈（Ali Taha）。欢迎两位。

Ali： 很高兴见到你。

Swyx： “Waterloo 实习生”。

Ali： 永远的 Waterloo 实习生。

Swyx： 你什么时候把网名改成 “Waterloo intern” 的？

Ali： 大概是三月中旬改的名。当时看到这个名字没人占，我心想：必须拿下，先到先得。

Philip： 问题是 Ali 工作干得太好了，过不了多久就不是实习生了。所以我们得想想这个网名传给谁。

Ali： 我会把火炬传给下一任实习生。

Swyx： 哦，你可以直接传给另一个滑铁卢大学的毕业生。

Ali： 传给另一个 Waterloo 实习生。不，兄弟。

Philip： 对。

Ali： 实习生。

Swyx： 实习生，对。

Ali： 不对。

Philip： 你得从 Waterloo 招个实习生。

Ali： 对，我得从 Waterloo 招个实习生。

Swyx： 没错。

Ali： 但他们必须走同样的路径。

Swyx： 也可以从 Baseten 出——Baseten 从 Waterloo 招到谁，谁就继承 “Waterloo” 这个头衔。

Ali： 对，它就留在这个生态里。

Philip： 没错。

Ali： 实习期过半，要么拿到这个名号，要么出局。

Philip： 你们还应该办一个盛大的毕业典礼，当着所有人的面正式交接网名。

一个 20 万 token 请求的旅程：缓存感知路由与 PD 分离

Swyx： 你们显然很擅长搞仪式。新书发布会也办得很漂亮，非常成功。但在聊这些之前，我想先问个好玩的问题。假设你是一位资深推理工程师：当我把一个长查询——比如 20 万个 token——发进 Baseten 的推理系统，会发生什么？从查询进来到 GPU、模型、路由、负载均衡，整个流程是什么样的？有哪些我们平时根本不会去想的东西？

Philip： 针对长查询，我要问的第一个问题是：“你以前给我发过这个查询吗，或者至少发过它的一部分？”我真心希望你发过，因为这样我省事、你省钱。所以我们做的第一件事是缓存感知路由（cache-aware routing）：你访问的模型通常有多个实例、多个副本在跑，我们想把这次请求路由到一个既有空闲预填充（prefill）算力、又最好已经缓存了部分输入的实例上，这样这 20 万 token 里至少有一部分可以跳过预填充。

能发到 20 万 token 的查询，多半是写代码或者多轮智能体（agent）场景，本身就该有缓存可以复用。如果没有，就得送去预填充工作节点。至少在部分模型上，我们把预填充和解码（decode）做了分离：一组 GPU 专门处理输入、生成 KV 缓存（KV cache）、吐出第一个 token，然后交给另一组 GPU 跑解码，逐个迭代生成后续 token。

解码前面通常还会挂一个推测模型（speculator）。我假设你在写代码，而我们的推测模型是按代码场景优化的，草稿 token 的接受率会很高。如果我猜错了——你其实是让我总结全套《哈利·波特》——那就会慢一些。最后我们把输出流式返回给你，记账、收你几美分，然后问一句：“要不要再发一条？”

按 token 计费还是包下整机：专用部署的切换时机

Swyx： 不过 Baseten 可不是按几美分收费的。

Philip： 我默认说的是公共模型 API 的场景。如果你是自建专用部署（dedicated deployment），那就不是几美分的事了。

Swyx： 对。我最初和 Baseten 聊的时候，一个关键差异点就是：大用量客户直接按整机租用，怎么把这台机器喂饱是你们自己要解决的问题。

Ali： 而且多数情况下，如果你每小时要跑几百万 token，按小时付费比按 token 付费便宜得多。

Philip： 确实如此。不过我们越来越多地看到按 token 计费 API 的需求，因为大家都想先试试开源模型；一旦找到了真正有粘性的场景，就迁到专用部署上。

Swyx： 什么时候该切换，有什么最佳实践吗？

Philip： 有几个理由。可靠性是很重要的一条。

Ali： 还有，如果客户有非常具体的场景，想让你为他们专门训练点什么——比如为自己的流量定制一套推测解码（speculative decoding，常缩写为 spec dec）。

Swyx： spec dec 就是推测解码。

Ali： 对，推测解码。

Swyx： 你得解释一下。

Ali： 抱歉。推测解码是这样的：你有一个很大的模型，它每做一次前向传播只能生成一个 token。于是我们在模型上面挂一个“小寄生层”，它只做预测——跑三次非常快的自回归前向传播，猜出三个 token，然后让原始大模型做一次完整的前向计算，验证这三个猜测对不对，对就接受，错就拒绝。

这个草稿模型（draft model）是和流量场景绑定的：像 Philip 说的，如果你在总结《哈利·波特》，我可以只用《哈利·波特》的文本来训练这个草稿模型，保证那三个 token 每次都被接受，解码速度因此提升。但如果你是共享端点（shared endpoint）的用户，我给不了你这个——

Swyx： 对。

Ali： 因为我不知道你是在做《哈利·波特》、写代码还是写英语作文，我们无从知道。另外书里好像提到过一个东西，第四章：如果客户真的很在意某个具体指标阈值——记得吗？

Philip： 记得。你可以自己设定批大小（batch size）、并行策略，看你要优化吞吐还是延迟；如果 NVFP4 量化（quantization）过不了你的基准测试，你想用更高精度跑模型，也可以。想拥有自己的端点有很多理由，最大的一条当然是：你正在服务自己用户的时候，不用忍受别人在同一个端点上跑一亿 token 的基准测试流量。

工具调用的难点不在沙箱，在 JSON 与训练

Swyx： 对。我觉得这是一条经典路径——就像面试题“你在浏览器里输入 Google 会发生什么”。再往下问：工具调用（tool calling）本质上就是生成 JSON 吗？还是背后更复杂？

Ali： 我们有些客户用的是自己后训练（post-training）过的模型，他们要的工具调用不是“解析个文件、查个天气”这种通用能力，而是非常具体、必须专门后训练出来的能力。如果后训练没做好，或者为了让推理变快而在后训练之后做了量化，模型就会在解析 JSON、执行工具调用时出错。

但它并不需要专门的沙箱——工具调用又不是要逃出沙箱，不需要被隔离，跑在普通的专用部署里就行。工具调用越来越大的挑战在于：企业想要的工具调用非常敏感、很难训练。因为要处理大量 JSON 输出，如果请求结尾没有以特定方式闭合，模型可能做完了工具调用和推理，却根本没读到返回结果，而是在解码时凭空编了一个结果。这才是工具调用最难的地方，而不是沙箱问题。

Philip： 对，这是训练侧的挑战；推理侧也有办法——限定可能的输出范围。差不多两年前我们就公开发表过这个问题的解法：构造一个状态机，用它把输出约束在特定格式内。这就是结构化输出（structured output）要解决的问题。还记得吗——

Swyx： 对，就是特定语法那个。

Philip： 没错。

Swyx： GGML（llama.cpp 的前身）就搞过这套。

Philip： 对。就是老派的“确保只返回 JSON”，或者那种——

Swyx： 对。

Philip： “我奶奶会死掉”式的提示词。

Swyx： 是不是 BNF 文法？OpenAI 一度发布过一个东西：想约束输出，就写一段 BNF 文法（Backus-Naur Form）。

Philip： 在我们的推理系统里，就是指定一个输出格式，然后你能得到保证：输出会严格符合这个格式。把它用在工具调用上，能减少很多问题。你还是可能调错工具、或者根本不调工具——它解决不了正确性问题，但至少解决了工具调用内部的输出结构问题。

Swyx： MCP 本质上也就是另一种工具，对吧？

Philip： 没错。

Swyx： 在这方面没什么特殊的。

Philip： 我一直在跟人解释的一点是：大模型本身什么也做不了。它只能提出“该做什么”的建议；只有当这些建议以特定格式输出、并交给一个知道怎么处理的系统，动作才真正发生。

Swyx： 对。有意思的是，这个问题在工具调用之外也有解法。比如在智能体循环（agent loop）里，如果输出不对，或者工具调用被做进了推理轨迹（reasoning trace）里，模型可以说一句“哦，我不知道怎么办，再试一次”，试几次也许就对了。另外接你刚才关于训练的话头：小模型上这事更难——你从一个大模型换到小模型，输出质量就不一样了，对吧？

Ali： 对。不过在展开之前，我觉得我们得回到推理工程本身。我原本以为会有东西取代 JSON，因为 JSON 很难流式处理——JSON 必须完整，开闭括号都得齐全，边流式传输边解析、边校验很难。所以大家发明了各种替代品，名字我记不清了，类似 TOML、类似 YAML 的东西。但 JSON 至今仍是主流。

Philip： JSON 输出其实没那么长。工具调用里虽然带参数，某些工具可能要传很长的参数，但我的印象是，工具调用的 token 数中位数相当小。所以我猜推测模型对 JSON 这种格式规整的输出通常很在行，解码会相当快，流式传输的价值反而没那么大——当然也可能我想错了。

Ali： 你还受限于模型要对接的软件：如果对方的软件就是用 JSON 做工具调用接口，客户说“我们的软件就是这么工作的”，你可以让他们改软件，说“这样对模型更好”，但只要训练得当，差别也不会太大。而且输出 token 多一点，说不定还更赚钱。

Swyx： 那得看商业模式，真的要看情况。不过我作为一个经常和生成式输出打交道的写作者，确实在往“JSON 文本”上转——那种非常长的 JSON，每个字段里都是成段的文字，因为我要做结构化：先陈述事实，再给观点，再给要点摘要，带日期、带实体引用、带来源出处。我觉得认真玩结构化输出的人都得关心这些。

“支持”一个新模型：day-zero 上线背后的一周工程

Swyx： 不过，我们往栈的上层回退一层。开录之前你提到一件特别酷的事：每当有新的模型厂商发布新模型，背后都有大量推理工程工作。就拿 GLM-5.2、Kimi K3 来说，我原本以为——尤其是 GLM-5 到 5.1 再到 5.2 这种，你们以前支持过——工作量没那么大吧？

Ali： 工作量很大。

Swyx： 每次新模型发布，大家都抢着说“Hugging Face 支持了、Fireworks 支持了、Baseten 支持了”，我心想“我们当然支持了”。但“支持”背后到底要做什么？

Philip： 而且这不仅仅是“支持”的问题，对用户的价值也很大。Kimi K2.5 那回、还有最新的 GLM-5.2，都爆发过推理速度大战：某家做到每秒 90 token，第二天我们就做到 150——

Swyx： GLM-5.2 那场算是我挑起来的。我写了篇 Twitter 长文，差不多 50 万阅读。

Ali： 是因为你们排第一，还是因为别的？

Swyx： 对。

Ali： 我的天。

Swyx： 然后所有人都兴奋起来：我们怎么还能再往前挤一点性能。

Philip： “支持一个模型”有两种意思：一种是“我能用这个模型跑出 token”，另一种是“我能用这个模型提供生产级 API”。前者没那么难——vLLM、SGLang 这些开源推理引擎的维护者经常提前拿到权重，模型厂商自己也会合并 PR 确保支持，所以多数情况下用标准开源栈跑起来不会太痛苦。

难的是：每家推理公司都有自己的私有技术栈，一部分开源组件、一部分自研。对任何一个新模型，总会有新东西要处理。运气好的时候，比如 K2.5 到 K2.6，变化很小——

Ali： 对，如果我没记错，那纯粹是继续做后训练。

Philip： 对。但即便是这种情况，该做的活一样不少：量化要重做。这些模型发布时一般不是 NVFP4 格式，而我们想要 NVFP4 以最大化对 Blackwell 的兼容，所以要做量化，还要做校准，确保模型智能没有退化。然后还要训练推测模型，前面聊过了。

我们的模型 API 是零数据保留（zero data retention，ZDR）的，所以我们并不确切知道用户发来的流量是什么，但知道什么场景火——写代码火、智能体场景火。于是我们用有代表性的公开数据集训练通用推测模型。

现在的推测模型必须用基座模型本身来训练：你要用这些特定提示词跑推理、取出模型的隐藏状态（hidden states），这些就是训练推测模型的数据。这个过程需要真实的模型权重。然后当然还有把背后的基础设施全部搭起来、加载、测试的一整套流程。

Franken-merge：把 Kimi 的眼睛嫁接到 GLM-5.2 上

Philip： 如果是架构更新的模型——我觉得 DeepSeek 的模型往往最难搞，一代接一代都有最新颖的架构改动——但每个新模型都有点新东西。Kimi K2 有——哦不对，是 GLM-5.2 有——

Ali： 稀疏注意力（sparse attention）。

Philip： 对，DSA。

Ali： 从 DeepSeek 那儿来的。

Philip： 对。

Ali： 那你可以直接复制粘贴吗？我不知道这里面的机制。

Philip： 我们得把这个能力做进自己的运行时（runtime）里。你说得对，这些开源实验室互相借鉴的方式特别有意思。举个例子，GLM-5.2 没有视觉能力，我们团队的 Haley 就研究了一下：能不能把 Kimi 的视觉编码器（vision encoder）嫁接到 GLM-5.2 上。

Ali： 我们要训练的是投影器（projector）。

Philip： 没错。结构是这样的：编码器负责看图像、把它变成潜在信息——

Ali： 你可以直接说“潜空间”（latent space），没问题的。

Philip： ——然后投影器把它映射到模型本身，再往下是模型权重。模型权重不能随便动，因为你可能为了给模型加上视觉，把它在别的事情上变笨。所以 Haley 只从投影器入手，它只有几千万参数。

Ali： 对，是这个量级。你能展示一下训练曲线吗？就是它“顿悟”的那条。

Philip： 好。

Ali： 特别有意思。就这条。

Philip： 也许 Ali 你来讲更好，你对这块的理解比我深。

Ali： 哦，双重下降（double descent）！好，你们看，他的训练方法特别妙。一开始他只用了“这是一张山的照片，描述一下山里有什么”这类数据，结果遇到了第一道学习墙。你们可以看到，我们要教它的只是“翻译”编码后的信息：编码器取自 Kimi，图像已经过编码——

Philip： 冻结的。

Ali： 冻结的。

Philip： 带适配器（adapter）。

Ali： 没错。大脑是冻结的，眼睛也是冻结的，我们训练的只是眼睛和大脑之间的连接线，也就是投影器。你给它 token，问它“这张图片里有什么”，它答“是一座山”“是一个人”，诸如此类。但这样形不成完整的理解。

于是他改成给每张图配一组问题：这张图里有没有白人男性？左上角有没有鸟？图里有没有科学家？模型必须答对这些问题。不只训练“描述图片”，而是训练持续地一问一答。你们可以看到那个 grokking 现象（顿悟式泛化），真的很疯狂——给一个大语言模型后天移植视觉，居然能学到这个程度。

就算遇到答不好的图，比如你给它看斯蒂芬·霍金（Stephen Hawking）的照片问“这是谁”，它可能答不对，但会说“这是阿尔伯特·爱因斯坦（Albert Einstein）”——它仍然理解——

Philip： 够接近了。

Ali： ——理解这是一位男性科学家、有重大成就，等等。这真的很酷。

Philip： 对。我们之前介绍过刘昊天（Haotian Liu），就是那篇 LLaVA 论文的作者，他在很早以前就做了这件事。对没做过视觉工作的人来说，那是奠基性的工作。

Ali： CLIP 和 MetaCLIP 也一样：从单纯写图注（captioning），进化到围绕图片构造问题，性能提升非常大。

Philip： 对。不过这件事最让人兴奋的地方在于：你看这个模型——这目前还只是个研究项目，MMLU Pro 跑到了 56% 左右，算不上前沿水平——但如果你跑这个模型，GLM-5.2 本身的质量没有任何损失。你不给它图片，它的表现就和原来一模一样。说到底——

Ali： 在推理代码里，如果没有图片输入，你就根本不把编码器那部分算进来，对吧？

Philip： 对，没有图片输入就跳过编码器。

Ali： 好，确认一下。它对整体推理的影响大吗？你加的东西不多，视觉编码器很小，一般不到 10 亿参数吧？

Philip： 它们非常轻量。视觉编码器之间的标准化程度低一些，所以支持矩阵会稀疏一点，但总体上它在整个系统里占比很小。而最终你得到的是：Kimi 的视觉、GLM 的权重、DeepSeek 的注意力，全在一个模型里。我觉得这正是开源的力量与美——你可以把这些不同组件组合成一个比任何单家都强的系统。

Swyx： 对。以前大家还说你们会做 “Franken-merge”（缝合合并），把不同模型的层拼在一起。

Philip： 对。

Swyx： 现在还有人这么干吗？

换层手术：低效层可以直接换成别家模型的组件

Ali： 接着你之前说的，支持一个刚发布的新模型——GLM-5.2、MiniMax M3 之类——有时候你确实得换掉一些东西。比如 MiniMax M3 的注意力头用的是全注意力（full attention），这在推测解码里会造成夸张的瓶颈：你要自回归地连猜三个 token，而全注意力要对序列里所有 token 做 N 平方的计算；KV 缓存也很大，因为它不是稀疏的、不做 top-K 筛选。

所以我们发现更好的做法是：把这个层换掉，换成另一个模型里用 GQA（分组查询注意力）的层。只要训练得当，接受率可以做到和原来一样。所以把其他模型的层移植过来是完全可行的，而且很有必要——如果某个层效率低下，难题就变成了训练：怎么确保训练到位？这又回到你之前那个观点：训练和推理的交界面。想做好快速推理，你需要非常好的训练。我越来越觉得这是真理。

上线只是开始：模式坍塌、循环检测与集群竞态

Swyx： 对。在“支持”这件事上，要做到完全的生产就绪（production ready），还有什么要做的？

Philip： 还有一个问题：我们自己可以把一个模型测得非常充分，但我们想尽快把它推上线，然后你会看到一大群人也在测它，冒出各种有意思的结果。GLM 就出过一次问题：某种模式坍塌（mode collapse），在某些提示词、某些温度下，模型会不停输出同一个 token。一旦你把端点暴露给真实世界，涌进来的花样会多得多，你才能发现问题、打上补丁。

所以这不是“上线日”（day zero）一天的事，而是上线后第一周、第一个月——如果模型持续受欢迎——你怎么一边修 bug，一边继续把性能往前推。

Ali： 你什么意思，你难道不想让模型一直输出 S 吗？（笑）

Swyx： 顺便问一句，你们有循环检测（loop detection）吗？这种事现在还时有发生，挺让人意外的。

Ali： 有。在我们的端点上，如果模型连续输出同一个 token 超过四次，我们就直接掐断生成，返回“抱歉，请重试”，或者重新处理这个请求。因为同一个 token 出现四次，基本可以判定是坍塌了。

Swyx： 如果我真的想要这种输出，有办法关掉吗？

Ali： 你真想要？我记得我们有一些处理机制。不完全确定，但有些场景确实需要，比如模型要画表格，就得连续输出 12 个破折号。这种应该有办法放行。我们好像只对特定 token 做这个检测，会排除某些特殊字符。

Swyx： 对。

Ali： 我们只在特定 token 上启用，S 几乎是最常见的一个。GLM-5.2 出过——

Swyx： 哦。

Ali： 我记得 DeepSeek V4 也出过。就是那种循环问题，你能得到的只有——

Swyx： 它——

Ali： 满屏的 S。

Swyx： 对。S 有什么特殊的吗？还是纯随机？

Ali： 好像偏偏就是这个 token。

Swyx： 对。而且——

Philip： 是不是——

Swyx： 只在 temperature 0 的时候出现？

Ali： 不是。

Swyx： 其他温度也会？

Ali： 哪怕 0.9，它也照样坍塌。

Swyx： 这就怪了，对吧？

Ali： 说实话，这是个推理问题，一个软件问题。很多时候和镜像有关：比如 NVIDIA 发布一个新镜像，我们把他们最新 TensorRT-LLM 镜像里的改动合入（upstream）我们的技术栈，问题就修好了。或者这个问题只在你用的某个推理引擎上出现，比如 SGLang，换到 vLLM 就没了。所以它看起来是一个极度确定的软件问题，而不是模型问题，不是权重的问题。

我们一度怀疑“是不是量化出了问题，PTQ（训练后量化）做错了”，但这说不通：同一套权重换个推理引擎，问题就不复现了。还有一种情况：后端用的内核（kernel）有非常微妙的竞态条件（race condition）——同一个模型，托管在这个集群上你永远不会遇到——

Swyx： 我的天。

Ali： ——但换到另一个集群就会中招。原因是：那个集群里节点之间传输 KV 缓存用的互连（interconnect）比另一个集群慢，慢的这一档就把竞态暴露出来了，另一个集群则不会。最后的结论就是：好吧，这个模型不放这个集群了，挪到另一个集群去，因为那个集群把问题暴露出来了。但这就引出一个问题：到底是软件的锅、模型权重的锅，还是硬件的锅？

Swyx： 还有个相关的事：temperature 0 也不是严格确定性的，对吧？

Ali： 对。

Swyx： 主要是硬件原因。同一个模型，即使 temperature 0，也不一定每次都得到相同输出。不过竞态条件这个让我很意外——我原以为 PyTorch 的计算图至少能保证按正确顺序执行。

Ali： 理论上是的。我也不是说它没有保证。但有些底层优化允许你在上一个内核还没跑完时就启动下一个内核，你确实想这么做，因为——

Swyx： 类似流水线（pipelining）。

Ali： 对，为了省开销。但你做得并不“干净”，执行上会有重叠。完全可能内核本身就带竞态条件：本应在某个时刻运行的那个 block，内核内部就出问题。比如缺了一个屏障（barrier）。设计内核、追求极致速度的时候，如果测试不充分，某些线程会在其他线程还没写入之前，就从寄存器里读数据——

Swyx： 对。

Ali： 比如屏障写错了、同步写错了。而且这类问题的测试本身非常难做。

Swyx： 也没有借用检查器（borrow checker）之类的东西。

Ali： 什么意思？

Swyx： 就像 Rust。如果你想要内存安全，听起来是同一类问题。

Ali： 话是没错，但你是在 CUDA 上干活，是 NVIDIA GPU。也许需要一门更高层的语言，比如 Modular 的 Mojo——也许 Mojo 就是干这个的，我说不好。

质量的定义：离“黄金实现”的 100% 保真度有多近

Vibhu： 你们怎么保证模型质量？刚才说了那么多步骤：量化、训练自己的推测解码器、跑在不同硬件上。再看看其他模型供应商——你在消费端挑起了一场推理速度竞赛。要保证各家之间质量一致，要做哪些事？当然，你们可以跑基准测试——

Ali： 对。

Vibhu： ——但怎么决定量化到什么程度？有标准吗？

Philip： 质量这件事有几个层面。大多数推理优化是无损的：KV 缓存只是避免重复计算同样的值；推测解码里草稿 token 猜错了会被拒绝。主要有损的优化就是量化。量化质量取决于三点：第一，数据格式；第二，选择量化模型的哪些部分、哪些层；第三，对量化后的权重做大量校准，确保保留所有离群值（outliers）。

不过还有别的招数，很重要的一条是长上下文。你开场就问过：“发一个 20 万 token 的请求进来会怎样？”输入序列一长，要存储的信息、要处理的 token 都多得多。所以即使模型本身支持某个上下文长度，推理服务商也可以选择同时提供一个较短上下文的 API 和一个完整长度的——如果用户用不到完整的百万 token 上下文，你可以给他更好的性能。

这算不算“模型质量”我说不好。我对质量的定义是：我们在多大程度上忠实地伺服了原始模型？假设存在一个黄金实现（golden implementation），表现和模型设计意图完全一致，质量就是我们离那个 100% 保真度有多近。

当然，你也可以从训练侧谈质量，谈怎么把自己推过 100% 那条线。但单说推理优化，目标就是在尽量贴近 100% 保真度的同时变得更快。我们内部的标准当然是：你应该分不出我们的 API 和官方 API 的差别。我觉得 Kimi 在这件事上做得特别好，他们搞了厂商基准（vendor benchmark）——

Ali： 对。

Philip： 他们——

Ali： 他们真的发布了一份厂商基准。

Philip： 没错。

Ali： 因为他们点名批评了一些人——Amazon？反正有家供应商在 Kimi 的基准上表现很差。

Philip： 对。所以那次我们可能也——

Vibhu： 这是很久以前的事了吧？

Philip： 不是。

Ali： 也就三四五个月前。

Vibhu： 还有一次——我不记得是哪个模型了——他们下架了好几家供应商，还专门做了一张图表说这事。可能是——

Philip： Kimi Vendor Verifier。

Ali： 对，没错。你是厂商你也会气，对吧？

Philip： 对。

Ali： 设想我是用户，我用的是 Amazon 的端点，用了 Kimi 之后心想“我的天，这也太烂了”——我不会说“哦，是 Amazon 把模型量化砸了”，我会说“Kimi 真烂”，对吧？

Philip： 对。

Ali： 所以他们这么做很合理。

Philip： 对，他们在乎，真的在乎。

Vibhu： 情有可原。

Ali： 对，情有可原。

量化误差可以互相抵消：用 KL 散度挑选该量化的层

Vibhu： 这可能是个蠢问题，但我确认一下：量化有没有可能反而让模型变好？量化一定是严格变差的吗？

Ali： 技术上讲——

Vibhu： 不会？

Ali： 量化是有损的。

Philip： 对。

Ali： 它是有损实现。

Philip： 速度会变好。

Vibhu： 速度会变好。

Ali： 数值上——

Vibhu： 不，我总是在找反向缩放定律（inverse scaling laws）。这是我从诺姆·布朗（Noam Brown）那儿学到的：有些东西通常朝一个方向走，但有时候会反过来。

Philip： 这个嘛，技术上讲，你跑基准测试的时候，因为这些模型是确定性的，有时候你的——

Ali： 对。

Philip： ——NVFP4 量化版的分数会比原始版本高两个基点（basis points）。

Ali： 不，那是噪声，是噪声。

Philip： 对，没错。所以我总说“在误差范围之内”。后来我连这话都不说了，因为大家会以为我们是在负方向上勉强挤进误差范围。但确实有时候量化版的输出分数就是更高。不过像 Ali 说的，那是噪声。据我所知，量化并不是真的让结果变好，你只是在努力让保真度尽量贴近原始模型的 100%。

Ali： 顺着这个话题，我们做过一项研究，你能不能把那条推文调出来？我们的研究实习生 Joshua 发过一条推文：我们的 GLM-5.2 量化版比 NVIDIA 的好 20%。那个月的研究里，我们的核心发现是：量化是有损的，你把数据从占 16 位压缩到占 4 位，丢掉了一些信息，你能做的是把损失降到最小。

所以当我说“我要量化这个模型”，我的工作就变成了：怎么找到可以量化的层，怎么找到不能量化的层。比如图像模型里，我不量化调制层（modulation layers），也不量化输出投影（out projection）——输出投影是用户直接看到的东西，调制是模型自己“看到”和理解的东西。他那篇论文，你那边有吗？没有？论文很长，我不知道能不能翻到——

Vibhu： 有没有可以检索的部分？可能就在那个推文串里。

Ali： 应该在推文串里。但长话短说：量化更多层，结果反而更好，这是完全可能的。假设模型 A 量化了第 1、5、10 层，模型 B 只量化了第 1 层和第 5 层，A 完全可能表现更好——因为量化误差相互抵消了。

Joshua 用数学证明加验证器（verifier）展示的是：你可以预测哪些层的量化误差会互相抵消，然后专门选择量化这些层。这么做的结果是：你的模型比另一家供应商多量化了 20%，吞吐因此高出 20%——因为跑 NVFP4 的层更多——而质量还更好，因为你选的层误差互相抵消：一层往右偏，一层往左偏，一层再往右偏。最终的 logits 分布更接近模型的原始分布，保真度更高。

我们的证明方法是用 KL 散度（KL divergence）：不只看基准测试分数，而是计算量化模型和原始全精度模型在 logits 分布上的 KL 散度。如果模型在“下一个选哪个 token”的概率分布上和原始模型更一致，你就大概率保持了原汁原味。在这项研究之前，行业里的共识似乎是：量化得越多，模型越差，因为引入的损失越多。这不一定对。量化不会让模型变好，但误差可以互相抵消。

Philip： 我不确定是不是一回事，但这很让我想起剪枝（pruning）——你可以剪掉某些层。很有意思，我都不知道你们为此专门发了篇论文。

Ali： 说个好玩的：这篇论文原本有 72 页。

Philip： 哇。

Ali： 后来我们觉得不能这么发，就砍到了 45 页。

推理还远没被优化到头：10 倍提速是怎么叠出来的

Swyx： 现在还有 39 页，仍然很有分量。我们聊了评估这些，那加速的上限呢？这大概是人们最关心的数字，你文章里也写过：官方 API 每秒 70 token，你们推到 90。这是常态吗？

Philip： 做推理最酷的地方——也是我认为推理在很长一段时间里都是做工程的好地方的原因——是：你看那些高度优化的领域，比如金融。在金融业，你用基点衡量进步：“我优化了五个基点”，也就是二十分之一个百分点，这就是大新闻了，因为一切都被优化到头了。而我们发布优化成果的时候，是 20%、100%、200%。所以说实话，前面还有很长的路。等到研究者开始发论文说“我把某个东西做快了 1%”，你就知道推理基本被解决了。

Swyx： 顺便说一句，我是金融背景出身。70 年代的时候，做量化金融研究，你能找到的就是——

Ali： 20%，几十个百分点那种。

Swyx： 对。

Philip： 对。

Swyx： 而现在——

Philip： 只剩下零头。

Swyx： 感兴趣的人可以去查罗闻全（Andrew Lo）的论文。他有个特别精彩的图，展示量化、统计套利（stat arb）的收益分布，从 70 年代那种 20% 的利差一路收窄到今天的几乎为零，非常酷。

Philip： 完全正确，而我们正处在同类进程的开端。不过基准测试很难，谁都会这么告诉你；测各家供应商的速度尤其难，因为变量太多：用什么硬件？系统负载多高？提示词的具体构成、输入输出序列长度是多少？等等。

但总体来说，当你把这些改进叠起来，看到的是倍数级。最常用的指标当然是 TPS（tokens per second），这是我们行业起的烂名字，因为“每秒 token 数”其实有两个：一个是吞吐意义上的，一个是延迟意义上的。

Ali： 还有 TTFT 那些。

Philip： 对，吞吐意义上是一块 GPU 每秒总共吐出多少 token。大多数人关心的其实是延迟意义上的 TPS，我们应该管它叫 ITL（token 间延迟，intertoken latency），但我们没有。

总之你可以想象：一个 1 万亿参数的模型，没什么优化的标准 API，在合理流量画像下大概在每秒 30 到 50 token 的区间。而我们的目标通常是把它推到 10 倍。不一定是上线当天，但只要堆够优化：假设你有三项优化，每项带来翻倍，叠起来就是 8 倍。这就是我们这个行业做事的数量级——我们要的是实质性的提速，不只是从 70 提到 90。

Swyx： 你是说你们已经做到了？

Philip： 这么说吧，以每秒 30、40 token 作为合理基线，10 倍是可以做到的。拿 GLM-5.2 来说，如果你不量化，甚至跑在 H100 上，用现成的推理引擎、不做任何专门优化——没有推测模型，没有 KV 路由，没有分离部署——你基本就在每秒 30 到 40 这个区间。这个基线合理吧？

Swyx： 合理，合理。

Philip： 要到 10 倍，就要做很多取舍。跑到每秒 300、400 token 的水平，意味着：用最好的硬件、调好推测模型、做完所有量化工作、保持很高的缓存命中率、用较小的批大小、用一套为延迟而非吞吐调优的并行配置。但这是可能的。

你去 Artificial Analysis 或者 OpenRouter 上看，最差供应商和最好供应商之间的差距经常就能到这个量级。当然，10 倍非常激进，更多时候是四到六倍的提升。但真正让我们兴奋的就是这种量级的收益，而不是从 70 token 提到 90。

Ali： 这还和硬件有关。如果你本来只用一个节点的 H100 在服务，然后把模型切分（shard）到四个节点的 B200 上，光靠堆硬件也肯定能提速。前提是要归一化到完全相同的硬件和 GPU 数量再比。

Philip： 对。归一化之后，你看到的是两到四倍的提升——

Ali： 对，对。

Philip： 取决于推理优化的水平。说白了，一部分看你手里是什么车，一部分看司机是谁。

榨干一个 B200 节点：量化加推测解码占 95%

Vibhu： 如果把这两到四倍拆开看——假设场景就是在 B200 上跑 GLM-5.2——

Ali： 对。

Vibhu： 单节点，对吧？为了榨出最后一点性能要付出多少努力，和大家默认该有的认知之间，这笔账怎么算？

Ali： 推测解码加量化。

Vibhu： 推测解码加量化。

Ali： 对，这两个大概占 95%。

Vibhu： 这两个能带你走多远？普通人做起来有多容易？比如现在我想把 GLM-5.2 的权重丢到一个 B200 节点上，找一个现成的推测解码模型或者量化好的模型，容易吗？要做多少工作？

Philip： 如果你是抢首发，工作量相当大；如果是今天再做，已经有人把东西都发布出来了，你可以直接拿。NVFP4 权重有现成的，推测模型也有现成的。

盘一下我们叠加的那些“两倍”：从 BF16 到 NVFP4，其实不到两倍——16 位到 8 位大概快 30% 到 40%，8 位到 4 位再乘一个 30% 到 40%，合起来接近两倍但不到。推测模型，大约两倍。分离部署（disaggregation），前提是你有足够的硬件、跑得满足够的流量，又是大约两倍。再加上更好的运行时、最新的内核带来的两位数百分比提升。就是这么叠起来的。

Ali： 对。

Philip： 每一样的构建成本：对真正懂行的人来说，量化权重是几小时到几天的活，推测模型也是几小时到几天，分离部署的搭建也是几小时到几天。

Ali： 一旦搭好，一旦搭好，就——

Philip： 对，我是说第一次把分离部署跑通当然非常难，之后的边际实现成本就低了。

Ali： 如果你只是个普通用户，手里恰好有一个 B200 节点，琢磨着“我自己能不能托管一个”——你不需要自己做量化，总会有开源的量化检查点（checkpoint），就算别人不发，NVIDIA 也会发。你也不需要自己训练推测解码，各家通常都会发布自己训练好的，你直接用就行。

Philip： 对，GLM-5.2 自己就带 MTP。

Ali： 对，没错。

Vibhu： 什么是多 token 预测（multi-token prediction）？

Philip： 问得好。

Ali： 我只是——

Vibhu： 你能解释一下吗？

Ali： 我只是恰好是专家而已。要我说错了你再纠正我？

Vibhu： 不，是我们说错了你该纠正我们。我的理解是：他们的多 token 预测可以用于自推测解码（self-speculative decoding）。

Ali： 我不确定，这条我不纠正。

Vibhu： 好，我对此有七成把握，听众可以自己去查证。不过我想把故事讲完整：不只是普通玩家，假设一家公司想从无服务器推理（serverless inference）迁出来，自己租 GPU 搭一套——要做哪些步骤，才能比“挂个 vLLM 完事”快得多？

Ali： 对。

Dynamo 是工具箱，不是开箱即用的系统

Vibhu： 我一直在等你们提 Dynamo。我感觉它就该是你拿来对标的基线。

Philip： 我更愿意把 Dynamo 看成一个工具箱，而不是一个开箱即用的系统。我们说的缓存感知路由、KV 卸载（KV offloading）、PD 分离（prefill/decode disaggregation）——Dynamo 本质上就是为这些事情而生的。顺便说一句，Dynamo 是 NVIDIA 的开源库。

Ali： 我们和 Kyle 做过一期播客。

Philip： 好。

Ali： Kyle Kranen。

Philip： 那你的听众就知道了：Dynamo 支持所有主流推理框架，而且跨硬件，这点很有意思。

Ali： 但它只是个路由层，不是优化层。

Philip： 对。Dynamo 擅长的是在你的集群、你的硬件之间搬运信息。比如 KV 缓存在一处，而你需要它在另一处，Dynamo 会替你调度 NIXL（NVIDIA 的传输库）完成搬运。

这不等于说你 pip install dynamo 一下，性能就原地起飞。它更像一个开发者工具箱。

Ali： 对。它自带一套默认配置，你可以逐项替换掉。

Philip： 没错。如果整个行业的部署方式已经高度标准化，它或许能成为一个可信的基线。但我们得拿野外真实看到的东西来对标。

Vibhu： 我想多聊两句 PD 分离，它大概是排在量化和推测解码之后的第三大件。我正好把书翻出来了——

Philip： 嗯。

Vibhu： 5.2.2 节讲 Medusa，5.2.3 节讲 EAGLE——

Philip： 对。

Vibhu： 5.2.4 节讲 n-gram。

Philip： PD 分离在 5.5 节。

推测解码族谱：Medusa、EAGLE、n-gram 与“套娃”推测

Ali： 对。不过我想多停留一下：你写书的时候怎么取舍？哪些收进来，哪些不收？毕竟还有那么多别的技术。这些现在还不过时吗？有些大概是一年半前提出的。

Vibhu： Medusa 相当老了。

Philip： 对，Medusa 老了。

Ali： 确实老了。

Vibhu： 但收进书里是作为一个好的基线、一个“原味”的入门理解？

Philip： 对，基线。

Vibhu： 帮助人读懂的那种？我读那篇论文的时候觉得“太有道理了”。

Philip： 对，属于“你应该知道”的那类。这本书我有两个目标：一是给读者一套这个领域的通用工作词汇，二是让他们对每项技术的工作原理建立直觉。我在 AI Engineer 大会的演讲里说过——那场演讲算是本书第一份公开的增补——推测解码这个方向的演进速度比其他所有方向都快。所以我写书时收录 Medusa，更多是让人理解这个领域是怎么演化过来的，而不是代表最现代的技术。现在当然有 DFlash、dSpark 这些比 EAGLE 还新的方法，虽然 EAGLE 仍然用得很广。

Ali： 还有 SpecSpec（speculative speculative decoding，套娃推测）。

Philip： 对，给推测解码做推测解码。

Vibhu： 什么——

Ali： 哦，那是 Tri Dao 的一篇论文，做的是对推测解码器再做推测解码。

Vibhu： 哈。

Ali： 字面意思就是这样，这是最简单的解释。他似乎拿到了一些不值一提的加速。但训练复杂度——至少在我们看来——快赶上训练 GAN 了：一种非常微妙的平衡。不过对，字面就是“推测解码套推测解码”。

Vibhu： 套娃。

Ali： 对。我们看到这篇论文的时候——

Vibhu： 很有意思，对吧？我甚至没想到它会难训练，我天真的想法就是：那就训一个推测解码器呗。

Ali： 但细想又合理。推测解码的整个思路就像 iPhone 的自动联想，只不过给大模型用：你先猜出三个 token，然后做一次批量验证，就为原始模型省下了三轮生成。而你的推测解码器自己也要跑三轮自回归，那为什么不套一个更小的模型呢？

另一个问题是推测模型该多大——

Philip： 大概 10 亿参数这个量级。

Ali： 像 MiniMax 那个，就一层，通常是原始模型的六十分之一左右。

Philip： 回头到办公室我们应该写篇论文：《推测解码的推测解码》。

Ali： 套推测。

Philip： 套解码。

Ali： 不，说真的，这条套娃链在哪里停？而且如果你真能训练“推测的推测”——一个小模型既能准确预测中间推测器会猜什么，而中间推测器又能预测原始目标模型会输出什么——那你为什么不直接拿这个最小的模型当主模型用？

Vibhu： 对，这就和路由问题（routing）沾边了。

Ali： 对，没错。

Philip： 推测模型有一个很现实的约束：你必须把一个小模型和主模型跑在同一套硬件上，这里面天然存在编排和资源竞争问题。这也是推测解码的总体约束之一：草稿 token 本身要花资源生成，还要花软件复杂度去管理。如果你搞无限递归的推测器，推理引擎的实现复杂度会暴涨，不只是训练过程变复杂。

本地 AI 治“笨”，数据中心治“慢”

Vibhu： 我正想问：能不能对推测模型也做蒸馏（distillation）和剪枝？反正它也就是个模型，能不能把它的大部分权重蒸掉、再量化？这已经超出我的领域了。另一个问题是：这些讨论都是针对大型数据中心负载的，对吧？有多少适用于“我有台 MacBook，想把 Gemma 跑得特别高效”这种场景？是同类问题，还是完全不同？

Philip： 相当不同。几周前我在 Selo 的播客上聊过这个。面向数据中心、面向生产负载的推理工程，和面向本地 AI 的推理工程，根本区别在于约束和目标从一开始就不同。本地 AI 的问题是：“我怎么把这个模型塞进我的硬件里，然后让它别那么笨？”数据中心推理的问题是：“我怎么把这个模型加载起来，然后让它别那么慢？”我们也关心“别那么笨”，他们也关心“别那么慢”，但侧重不同。

本地 AI 的推理工程生态有很多值得数据中心这边学习的东西。他们是各种量化形式的专家，包括我们根本不碰的动态量化（dynamic quantization），还有剪枝、蒸馏、删层——

Ali： 删层没那么重要。

Philip： 对——

Ali： 其实没人真的爱剪枝。

Philip： 但他们确实做——

Vibhu： 这挺让人意外的，不过那是另一个话题了。

Philip： 他们做这些只是为了把模型塞进一台笔记本。所以这是个很有意思的领域。倒不是说他们的技术适合搬进数据中心——我们的资源和目标都不同——而是那个领域的过程和开放精神值得敬佩。

Ali： 对。接你这个话：有些优化在特定硬件上才成立。比如 TurboQuant，当时炒得特别火，我们在 Twitter 上做过一整串深度解读：它是什么、怎么工作、好在哪里、不好在哪里。它火起来之后主要落地在本地设备上，因为像 MacBook 这种机器，内存带宽太有限了。

但同样的东西放到 NVIDIA B200 上完全行不通。NVIDIA 自己也明说这不是个好优化。我们亲身体验过：在内核里做 TurboQuant 那种量化—反量化的开销，比你省下的带宽时间还多。B200 有 3.5 TB/s 的带宽，你根本不需要把存储压得那么狠，不需要 FP4 的 KV 缓存，不需要重量化（requant）——那边有更好的优化可做。但在边缘设备上，它极其重要、极其有用。

所以两边的优化方向不同，但底层原则是共通的：你都想量化模型，都想做推测解码，都有一些共同的——

Philip： 原则。

Ali： 对，完全正确。

Philip： 他们还做很多模型并行的工作，尤其是在异构拓扑上：几台 DGX Spark 用以太网连起来——

Ali： 对，Exo Labs 那帮人。

Philip： 或者一摞 Mac Mini 叠起来。我们和他们都要面对机器间互连的问题，只是他们要头疼得多。这也是为什么我们大量用张量并行（tensor parallelism，TP）：把一个节点上的全部八张 GPU 都用上，把模型切分到它们上面。

张量并行不适合本地 AI，因为它假设有 NVLink 这种超高带宽互连。本地场景可能被迫走流水线并行（pipeline parallelism）——除非我们跑某种多节点推理，否则绝不会碰那个。

Ali： 对，图像场景例外。

Philip： 多节点推理才用。

模型并行三件套与硬件感知设计

Ali： 既然你提到了——我本来不确定会不会聊到——借着这些很漂亮的图，我们简单讲一下张量并行和专家并行（expert parallelism，EP）吧。

Philip： 要把书拿出来吗？

Ali： 对，我就想展示几张图。

Philip： 好。感谢 Baseten 设计团队的 Luke 做了这些漂亮的图。在开始之前再补一个区别：我们经常谈混合专家模型（mixture of experts，MoE）的激活参数（active parameters），这对本地推理的人很重要，因为批大小为 1 时，你只激活那么多参数。而我们在数据中心做推理——

Ali： 对，我本来想在聊扩散模型的时候再带出来。

Philip： 对。我们托管一个 MoE 模型做 API 服务时，假设所有参数都会被激活，因为在整个批次里——

Ali： 因为你在组批（batching）。

Philip： ——你什么都会命中。好，大致来说：张量并行对任何模型都能用；专家并行只能用于 MoE 模型——而今天的模型实际上全都是 MoE，至少所有大到值得跨多 GPU 并行的模型都是，所以这个细微差别已经不太重要了。

专家并行的思路是：把整个专家放在一张 GPU 上。专家数量一般比 GPU 多，所以每张卡放 N 个专家，比如八个。然后在每张 GPU 上复制一份路由器（router）——路由器很小。这样生成过程在专家之间流转时，每个专家都完整待在一张卡里，互不抢资源，吞吐大幅提升，对 GPU 间连接的要求也没那么高，因为通信量小。

张量并行则要求你能做 all-gather、all-reduce 这类集合通信：把模型彻底切开铺在所有 GPU 上，每一步都要把各卡的结果汇总。这就是为什么互连至关重要。当然这是很粗粒度的概括，很多场景并不准确，但一般来说 TP 有助于降低延迟。实践中你通常会在同一个模型里组合使用这两种并行，而不是二选一。你要补充吗？

Ali： 对，通常在一个模型里两者并不互斥：你会同时做张量并行和专家并行。流水线并行就少见得多——我感觉我们从来不用。

Philip： 对。流水线并行是把不同的层分开，一半层放一台机器、另一半放另一台。你唯一被迫用它的时候是多节点推理：模型大到一台机器装不下。比如你出于某种原因要在 H100 上部署一个万亿参数模型，一个节点放不下，就得上多个节点；而节点间互连太慢，唯一可行的并行方式就是流水线并行。但在每个节点内部，你还是会做专家并行和张量并行。

Ali： H100 的瓶颈是 HBM（高带宽显存）？

Philip： 对，就是显存不够。

Ali： 多少？我们要的魔法数字是多少？

Philip： B200 每张卡 180 GB，一个节点八张，就是 180 乘 8。FP4 下每个参数占半个字节，万亿参数就是 800 GB 上下。H100 是多少来着，140？

Ali： 80。

Philip： 80？

Ali： 对。

Philip： 哎。

Ali： 嗯。

Philip： 我老了，干这行太久了，H100 的规格还记着呢。

Ali： 那你要不要给我讲讲 T4 的年代？

Philip： T4，我的天。

Ali： 来，让我给你讲讲当年在 T4 上跑模型是什么体验。（笑）另一件让我意外的事：居然没有更多人学 Jamba 的做法。还记得 AI21 的 Jamba 吗？他们先选定一款硬件，然后针对这款硬件设计架构维度，刚好把硬件打满。这非常合理，但不知为什么，现在这些模型都不这么干。

Philip： 训练侧不是这么干的吗？

Ali： 我不知道。抱歉，你继续说。

Philip： 我是说训练模型的时候。

Ali： 你是说选定用哪款 GPU 那种事？

Philip： 对。

Ali： 对，训练侧确实是数学问题：你可以算 FLOPs，然后把它最大化。推理则更像自动调优（auto-tuning），类似 GPU 内核的自动调优：你有两张 GPU，可以枚举 TP1、TP2、EP1、EP2，一共四种组合，然后把同一份真实生产流量打成影子流量（shadow traffic）灌进去，看哪种配置的 TPM 和 TPS 最好，就用它。

我不喜欢的一点是：你没法靠推理判断哪种配置最优，也不存在一种永远最优的配置。自动调优似乎就是找到最优解的办法。GPU 内核也一样：设计好内核和配置之后——启动多少线程、用多少共享内存——你就扫参数空间，用经验数据说话，这个就是最好的。

不过训练和推理也有交集。训练里确实有一些面向硬件的设计：比如 NVIDIA 的 Nemotron 模型在 Blackwell 上跑得特别好，这不意外。但我觉得大多数开源实验室还是想让模型能在尽可能广的硬件上跑，而不是只针对单一芯片优化——为了通用性。

看空巨型内核：融合救不了你

Ali： 好，趁着这张图还在屏幕上，再说一件事。all-gather、all-reduce 很贵。硅谷现在有个风潮叫巨型内核（mega kernel）：不断融合内核。事情有那么简单吗？我不觉得。融合内核救不了你。比如在张量并行里，一半矩阵在一张 GPU 上，另一半在另一张上；如果下一步要做非线性运算——比如注意力里的 softmax、要做指数运算——我需要完整的一行，就得知道 GPU 1 和 GPU 2 各自的部分结果，才能进入下一阶段的 softmax。

所以哪怕我有一个融合内核，由于每个环节里的非线性，我还是得让它们互相通信。

再说巨型内核，说实话我非常看空。它是个不错的研究方向，直觉上、理论上都很美：内核启动有开销，那就一路融合、别搬数据，全融成一个。但内核复杂度本身极难驾驭，写一个高度优化的巨型内核非常难。不点名地说，我认识一些在做融合巨型内核的公司里的人，他们最终往往不会在生产里用巨型内核，因为 TensorRT-LLM 和 Modular 那种分开启动的内核反而更快——你可以逐个优化每个组件，再让它们并行协作。

还有 Rubin——不知道你们昨天有没有看到那条 Twitter 帖子——“Rubin 的 Twitter 帖子？”“对，Rubin，NVIDIA 的 GPU。”“他们还给 Rubin 开了个专属账号？”“不是。”总之，NVIDIA 的一位技术负责人发了条推文：“我们揭开 Rubin 的面纱，这是规格。”第三条推文里——我不想讲得太技术，还得再细读——但从设计上看，这颗 GPU 几乎宣判了巨型内核的死刑，你不再那么需要巨型内核了。所以那一整个研究方向看来要无疾而终。

Philip： 我能借 Rubin 发散一分钟吗？

Ali： 请。

Philip： 顺便说一句，Rubin 在书里有写到——至少以“我从官方博客知道了 Rubin 的存在”这种方式写到了，连再下一代 Feynman 的名字都有。你看到的时候说“这也太新了”。我在尽力让这本书面向未来，不想明年就得再版。

回到刚才“我有多老”的话题：我已经经历过三个硬件发布周期了——Ampere、Hopper、Blackwell。我说的“发布周期”不一定是硬件正式出货那一刻：Ampere 在我入行之前就上架装机了。但从硬件上架到它能真正用于推理，中间有很长的时间差。你看最早的 vLLM——vLLM 尤其典型——是面向 Ampere 写的，然后为 Hopper 更新、再为 Blackwell 更新。每个周期都来得更快、更紧迫，也复杂得多。

展望 Rubin 会有什么新东西，Dynamo 给了我很多技术线索：哪类工作会变得非常有价值。Blackwell 开启的趋势会延续：NVFP4 很重要，他们堆在 NVFP4 张量核（tensor core）后面的算力非常夸张。我们待会儿应该会聊到视频，那正是视频的大瓶颈。内存带宽也快得多——这正是当年让 Blackwell 起飞的原因。

但最大的变化是更偏系统思维：更强调 CPU 到 GPU 的互连，更强调 GPU 之间的互连。你看 Dynamo，整个系统就是围绕一个问题设计的：怎么在正确的时间把 KV 缓存搬到正确的地方？所以我认为，KV 缓存卸载、KV 感知路由、分离部署这些主题在 Rubin 时代会重要得多。这意味着推理工程不再只是 CUDA 内核问题，也是一个非常传统的硬件基础设施问题——这是我们长期积累的方向，也让我非常兴奋，因为我们将看到多个领域碰撞到一起。能从内核层面一路向上推理到硬件层面、再推回来的能力，会非常值钱。

GPU 正在变成可编程 ASIC 吗

Ali： 我把 Phil 说的再往前推一步：我觉得它正在变成一个纯粹的基础设施问题。PD 分离、训练、推测解码这些是问题，但手写内核会越来越不是问题，因为 GPU 正越来越像 ASIC（专用集成电路）：你只是在编排 GPU 上发生什么，而不再逐线程地控制它。

你看 CuTe、CuTe DSL 这些东西：你操作的是数据 tile 的层面，不再控制每个线程干什么，那部分有人替你管了。基于你和其他人的交流，你认同 GPU 以及未来的 GPU 正越来越像“点火发射、然后自动完成数据操作”的 ASIC 吗？

Swyx： 哦，认同。但那只是市场的一个细分领域。

Ali： 对。

Swyx： ASIC 可以只为自己的负载做到极致性能——

Ali： 对。

Swyx： ——而 GPU 里的 G 决定了它必须保持通用。

Philip： 对，我觉得这是一个光谱。

Swyx： G 是 Graphics，图形——我老得纠正自己，免得有人来抓我把柄说我连 G 都搞错。

Philip： 对。这是一个从通用计算到 Taalas 那种东西的光谱——Taalas 是为一套特定模型权重专门造硬件。

Ali： 权重直接烧进去。

Swyx： 权重——

Ali： 直接进芯片。

Swyx： 对。

Ali： 连加载都不用。

Philip： 我倒不觉得我们会一路走到那个极端。更准确地说，是沿着这个光谱，朝着硬件更专门化的方向迈了一步。

Swyx： 对。我感觉你（Ali）刚才一路在往某个论点推进。

Ali： 我的论点其实是看空。除了把权重烧进芯片这招之外——烧权重是不现实的，因为你要微调、要优化、要量化、要发新的检查点，烧进芯片的东西一两个月就没用了。我的问题是：眼看 NVIDIA 越来越专门化——GPU 原本是一种通用编程范式，一台你可以随意编程线程的通用计算机，而每一代新品都在塞入更多专用指令、专用张量核、专用 MMA 指令，让你几乎把它当一块 ASIC、一组 ASIC 的集合来控制——

面对这样的趋势，你怎么还能继续看多那些做 AI ASIC 的公司？

Swyx： 因为他们——

Ali： 对吧。

Swyx： 因为他们也在朝那个方向进化。

Ali： 他们几乎在往同一个方向进化。拿 Rubin 和 Ampere、和 T4 比，Rubin 就是一块 ASIC，它就是一个用来——

Swyx： 可编程 ASIC？

Ali： 对。叫它 ASIC 很有争议：它是 GPU，是通用的，确实有线程，我可以写 CUDA 控制它、改变它的运算。但它有脉动阵列（systolic array）、张量核、TMA、张量内存，这些东西几乎只对加载模型权重有用；它的张量核指令形状几乎就是照着当今市场上模型的注意力头维度设计的。这时候你说要造一块 ASIC、把什么东西蚀刻进去——可下一代架构一出来，它就废了。

Philip： 我说不好，真的说不好。我只想提醒大家：硬件周期有多长。今天发布的一颗芯片，设计流程是几年前启动的。NVIDIA 在预判市场走向上做得非常好——

Swyx： 他们掌握的信息最多。

Ali： 那是肯定的。

Philip： 当然。但如果你看：和今天模型架构大同小异的公开开源架构早已存在，Rubin 说实话是第一颗完全在这个世界里设计出来的芯片。所以从它的设计里，你能读出他们对“这颗芯片将被要求跑什么样的负载”的理解。

Swyx： 对。好，这个问题我不是最合适的回答者，但你把基于 Rubin 的质疑阐述得非常清楚。我确实想为“垂直整合的模型实验室自研 ASIC”这条路辩几句——比如 OpenAI 和 Broadcom 合作的那颗，代号 Jalapeño 之类的芯片。

Philip： 嗯，可以。

Swyx： 那完全是讲得通的。马丁·卡萨多（Martin Casado）第一次在我们播客上讲过这个逻辑：“如果你有万亿美元或者五千亿美元的训练预算，拿五百亿出来造一颗 ASIC，完全没问题，你从 ASIC 拿到的效率提升会超过百分之十。”这说得通，对吧？模型专用芯片，没问题。

但 ASIC 创业公司——有意思的是，我觉得你过度聚焦在 Taalas 那种路线上了。

Philip： 嗯。

Swyx： 他们做的更多是“表面积工程”：内存和硬件的实际分配、芯片之间的通信——这些大概是 Rubin 还触及不到的，但细节我不了解。

Philip： 明白，明白。

Swyx： 他们谈的那些东西，通常我预期比 Rubin 通过可编程方式能做到的要大上几个数量级。但谁知道呢。

Ali： 有道理。

Swyx： 你想想：要让推理快 10 倍到 1000 倍，真正的拦路虎是什么？不是在现有 GPU 设计里能重新排列组合的那些东西。

Ali： 是互连通信。

Swyx： 对。

Ali： 好吧。

Swyx： 那些公司的目标是每秒 30 万 token，他们是玩真的。

Ali： 那可能得再加点猛料了。

Philip： 也许吧。不过我倒觉得有意思：你自己最近做了那么多内核工程，却对这类工作这么看空。

Ali： 是，但越做我越觉得——

Swyx： 反正不是巨型内核那条路。

Philip： 我还想补充一点——

模型的寿命：为什么旧模型还有长尾价值

Vibhu： 模型是一代代在出的，对吧？你们这边看到的是：今天 GLM、明天 Kimi、后天 DeepSeek、MiniMax，还有其他的，有些走完全不同的路子——Gemma 没有编码器，Thinking Machines 最新的东西全是从零搭的。但看另一边：GPT-5 这一代我们用多久了？他们伺服这个模型已经很久了。

Philip： 对。

Vibhu： 当然可能有更多训练、不同的检查点，但核心没变。你花几十亿美元训一次，只要效率再高 X%，这个模型就能伺服很久。Claude 5 家族也一样，对吧？

Philip： 如果他们现在发 GPT-6 或者别的什么，假设他们每年发一个新模型——我们不知道，但假设他们每年都在改架构的一些部分，而不只是做后训练——那你就得每年花五百亿美元为新模型造新 ASIC，然后把上一年的 ASIC 扔掉。

Vibhu： 对，轻轻松松就这个数。

Swyx： 这里我要稍微唱个反调——还是基于我那些二手信息——关于模型的寿命。现在还有人在用 GPT-4o。

Vibhu： 对。

Swyx： 还有 Llama——不是 Llama 2，是 Llama 3，我还经常看到 Llama 3 的负载。

Vibhu： 对。

Swyx： 因为如果它已经能用了、被信任了，就别动它。

Vibhu： 能用就行。

Philip： 这正是开源的承诺之一，对吧？前有轰轰烈烈的“拯救 GPT-4o”运动，而你不需要一场“拯救 Llama 3”运动——随便找张 H100 摆着就行。

Vibhu： 我觉得还有一个层面的问题：如果一个模型能力够用、工具调用够多、智能体性够强，能联网搜索、能写代码，你真的还需要继续榨吗？我们当然会换新的，因为你们会把新模型做得更便宜、更快、更小，我直接换上去就行。但某种程度上，你今天给我一个 GLM-5.2，或者随便一个 120B 的模型，我都能跑很久，对吧？

Philip： 这假设你不需要更高的智能。

Vibhu： 我觉得我们已经有很多场景的智能是够的——

Swyx： 你需要的是可靠性和可预测性。我身处企业场景：这个模型是试过、验过的，五千个利益相关方都签了字。

Philip： 对。

Swyx： 我是不会去动它的。

Philip： 它每天跑一个批处理任务，我喜欢它的结果。

Swyx： 对。

Philip： 结果可预测，对。

Vibhu： 继续用新模型当然是合理的，东西会越来越稀疏、越便宜、越好。

Philip： 对。

Vibhu： 但这不意味着旧模型——GLM-5——就不能用了，对吧？就算发展停滞了，不管什么原因，旧模型里还有很多可以榨的东西。

巨型模型的显存算术：3 万亿参数与 GB300

Swyx： 我们时间快到了。我还想确认一件事：正好这里有张图。把这张和任何一张 Cerebras 的图对比：我觉得 Etched、MatX 还没放出公开图表，但芯片版图（real estate）完全不同，尺寸完全不同——这不是晶圆级（wafer scale）设计，一片晶圆上大概能切出——我不知道——几百颗？

Philip： 对。

Swyx： 我不知道具体怎么比，但这是一种非常不同的版图分配方式。

Vibhu： 对。

Philip： 我会说几十颗。

Swyx： 几十颗，对。

Vibhu： 离开硬件话题之前，我有两个快问。第一，最新的 Kimi 特别大，3 万亿参数——

Philip： 对。

Vibhu： ——大多数硬件单节点放不下。

Philip： 是的。

Swyx： 要 GB300 才能单节点装下。

Vibhu： GB300 或者 AMD。

Philip： 这是简单的算术：NVFP4 下 2.8 万亿参数，就是 1.4 TB。GB300 每张卡 288 GB 显存，八张卡就够装下模型了。不过 GPU 显存的算术还有另一层：你必须给 KV 缓存留空间，而 KV 缓存的大小一定程度上取决于上下文长度。所以当一个模型参数量又大、上下文又长，两边就在抢空间。这就是为什么对这些巨型模型来说，KV 缓存卸载会变成一个越来越突出的议题——你的空间实在太紧张了。

Vibhu： 到了 Rubin，你有一个 NVL72 机柜，总共多少，20 TB 显存？

Philip： 对。不过 Blackwell 也有 NVL72。但你不能默认推理就会跑在 NVL72 上——世界上 8 卡节点的数量远远多过 NVL72 机柜。

Vibhu： 对。硬件方面最后一个快问：你们有没有观察到硬件代际和新训练的基座模型之间的关系？你之前说换硬件是效率翻倍的来源之一。等 Rubin 上的训练铺开之后，会有什么变化吗？会影响我们将来看到什么样的模型吗？

Philip： 模型会变大。大家心里都清楚：给定最新的推理硬件，能跑多大参数量的模型，这个上限是存在的，它构成一个天花板，而模型会顶着天花板长。比如 DeepSeek R1 发布的时候，6710 亿参数，在当时大得吓人——我认为它很大程度上逼着我们快速拥抱 Blackwell、把 Blackwell 上的伺服做扎实。所以在我看来，主要是模型尺寸的问题，然后是让架构和原生化量化格式匹配目标硬件，就像我们前面聊的 Nemotron 全系模型、NVFP4 那样。

视频扩散的另一套物理：O(n²) 注意力与 5 秒天花板

Vibhu： 我们聊了很多大语言模型。书里还有多得多的内容。音频、视频呢？推理工程的另一半是什么样？Ali，你在视频扩散（video diffusion）这块很深。

Philip： 视频扩散的形状很不一样。很多你在大语言模型上能推理的东西，前提是 LLM 是自回归的；视频扩散不是这样。比如——

Ali： 你不用组批。每个请求进来就占一张 GPU，一张卡服务一个请求，不用切分模型。模型也小得多：Wan 2.2 是 200 亿参数，比最好的 LLM 小几个数量级，很多烦心事都不用操心。

这个领域的开源模型地位也不一样。LLM 这边，Kimi K3 几乎能和 Mythos、GPT-5.5 掰手腕：最好的开源 LLM 和最好的闭源 LLM 差距非常小，以前是六个月，我觉得现在没有六个月了，几乎持平。视频模型完全不是这样，差距巨大。你看今天开源的 Wan 2.2 能生成的最好视频，对比可灵（Kling）或 Veo，是白天和黑夜的差别。这就造成了一种分化：媒体公司大多数时候会选闭源模型。

比如我跟你说：“我能用这个模型给你生成一整部三小时的电影，而且我把它优化到你只需付我 10 美元。”而闭源方案要 1000 美元——我便宜一百倍。但他们还是会用 Veo 和可灵来做所有的镜头。这是个先有鸡还是先有蛋的循环：需求少导致这个领域创新少，创新少导致开源检查点发布少。一些原本发布开源模型的实验室已经把最新模型闭源了，比如 Wan 2.7 就没开源，我们还停在 Wan 2.2。

视频模型特有的挑战是 token 数量。要生成高质量视频，假设你按每秒 16 帧——这是绝对的底线——做 480p 的视频。你可以算算这里的维度：一张图能直观展示 token 的恐怖数量。就拿《斯巴达 300 勇士》的一段视频来说，我们看四帧：如果做全注意力，把数字往上推，480×720 的分辨率、5 秒 81 帧（16 帧每秒乘 5），压缩到潜空间之后，你仍然要处理大约 30×50×21 个 token。

Vibhu： 对。

Ali： 也就是说，仅仅 5 秒，你就要在 3.5 万个 token 上跑注意力。注意力成了巨大的瓶颈，而它是 O(n²)：拉到 10 秒就是平方，20 秒、30 秒继续平方。想生成一段一分钟的好镜头，在同样的计算时间里几乎不可能，就是不可行。

于是你只剩两个方向。要么对整个视频一次性做注意力，那你就被迫用稀疏注意力——把图滚回那段《斯巴达 300 勇士》的画面：左边是全注意力，每个 token 都关注所有其他 token，你看那一大片红色块；右边每个 token 只关注对它最重要的 top-K、大约前 12.5%，这可以体现空间局部性——代表王冠的 token 关注头部、面部，以及前一帧里的头部，时间局部性、空间局部性，诸如此类。

问题是这会导致画质严重下降。那篇文章的全部要点就是：你可以训练、可以做各种技巧，但质量还是会打折扣。

所以最终二选一：要么咬牙堆算力，对上百万 token 做全注意力，因为你要生成两分钟的视频；要么转向自回归视频（autoregressive video）。在我看来，自回归视频是未来要下的赌注——但今天没有任何好用的开源自回归视频模型。如果你想要一小时的电影，想让视频模型生成好莱坞级别的片子，它们必须是自回归的，才能突破那 5 秒的天花板；要么就得出现一次算力上的疯狂飞跃，让我们能高效地对几百万 token 同时做全注意力。

Vibhu： 哪怕是上百万 token，平方复杂度也会让你很快撞墙。

Ali： 对。

Vibhu： 能讲讲自回归路线的利弊权衡吗？我想到的一个是跨帧一致性：自回归生成到第十分钟，它会“忘记”前面的东西。你怎么看？

Ali： 自回归扩散模型的好处是，我们前面聊过的 LLM 优化——推测解码之类——很多都可以搬过来用。如果你的模型质量够高、规模够大，就没有理由不能流式输出：我先给你看第一帧，就像 2022 年的 GPT——现在它吐文本快得像喷射，但当年你可以一边读它一边生成。视频模型可以变成：你一边看，它一边生成，逐帧输出。逐 token 生成让我们能大幅扩展规模，并在上面运用各种注意力机制。

缺点也很直接：现在每一个自回归视频模型都是垃圾，质量烂透了。你拿 Wan 2.2 和任何一个自回归模型比，Wan 2.2 生成的“猫狗打架”，自回归模型给你的是画质退化版的《猫和老鼠》。

于是长视频生成的解法变成：“好吧，不用自回归。”你看 Grok Imagine（Grok Video）的做法——他们做得相当好——是把一段段 7 秒的片段拼起来：先生成 7 秒，然后问“你能延长这段视频吗”，把两段接起来。开源界似乎没有他们那些技巧，而闭源的定义就是我们不知道他们怎么做的。

开源能做到的最接近的方案是：取视频的最后一帧，喂给一个“文本+图片生成视频”的模型——它接收文本提示词和最后一帧的图像——让它生成下一个 5 秒。理论上你可以这样一帧一帧流下去，拼出一部电影。但会产生漂移（drift）：你拿图像生成一段视频，下一个 5 秒质量差一点，第三段更差，第四段更差。有时候你会看到新一段比上一段暗那么一点点，一段比一段暗，到第 25 秒，黑屏了。

我们本来想做个演示展示这个，但效果实在太丢人，就决定不放了。不过我觉得模型终会走到那一步：它们需要大幅扩展规模，并且转向自回归。只是那一边的训练技术还不明朗。

自回归与扩散的分界线：视频、音频与文本扩散

Swyx： 对 Grok Imagine 感兴趣的听众，我们和那个团队的 Ethan Ha 做过一期播客。

Ali： 对。

Swyx： 他透了一点口风，但不足以让我们完整复现他们的做法。

Ali： 没错。

Philip： 他专门解释过拼接这一块的一些内容。

Swyx： 对。我们聊了记忆、长上下文这些话题。

Ali： 但据我所知，他们那套也不是自回归的——不过行业里好像也没人是自回归的。

Swyx： 对。

Ali： 看起来是这样。

Philip： 理解自回归模型和扩散模型的关键区别在于：扩散模型的注意力是双向的，而自回归只能沿序列向前。这就是为什么你会看到“脱轨”现象：如果你天真地把视频生成模型构造成“线性生成一串帧”，你就没法回到序列中间修正某个地方来让整体一致。而视频模型之所以需要那一大片潜空间，是因为——像你刚才说的——所有 token 都保留在记忆里，对整个序列反复迭代，你可以调整过去来让未来讲得通。所以如果要设想一种能做出更长、更丰富序列的架构，大概率如你所说，是自回归和扩散的混合体，让各自做擅长的事。

Ali： 直觉上也能想通为什么。比如英语写作，就是从左到右的：你可以流式吐 token，流式输出思维链（chain of thought）。就算是人，也是边写边想下一句写什么，写完再想下一句，一路向前。当然你可以说，写作时也需要回头修改，但这种需求比你以为的少得多。

视频不一样，它没有“顺序”这回事：左上角的像素和右下角的像素几乎同等地需要互相关注，才能决定画质。文本没这么强的需求。

Philip： 音频有没有类似的对照？我不是百分百确定，但大概一年前，音频领域有 AudioLM，有扩散路线也有自回归路线。基于你刚才说的那些理由——主要是在推理侧——即使音频片段更短，大多数音乐也有三到五分钟——

Ali： 对。

Philip： ——我们最终转向了自回归。音乐我说不好，但语音（speech）是自回归的。早在一年半前的 Orpheus 架构就是这样：把一堆波形加进词表，让 LLM 能输出代表这些波形的 token，然后拼成语音，流式输出就是这么实现的。

Ali： 原来如此，哇。

Philip： 那就是我 2025 年 AI Engineer 演讲的内容。

Ali： 不错。不过音频的挑战和视频不一样，对吧？音频可以靠一个 LLM 生成一切——说到底还是一份可以用 LLM 生成的文本，音频模型只需要把它读出来，做文本转语音。

Philip： 对。音乐那边有过一个阶段，扩散和自回归两条路线在权衡，一度不相上下，各有利弊。我只是想戳一戳你有没有观点。

Ali： 音乐我确实不了解。

Philip： 好吧。

Ali： 你刚才说写作回头修改——我的编辑大概会告诉我，我确实该多回头改改。我能想象音乐或诗歌的场景：有押韵结构，你可能要回头改前面的东西，好为后面的韵脚铺垫。这种情况下双向注意力是有优势的。

总之在我的知识框架里，我会把推理问题一分为二：自回归模型有一套约束和技术，扩散模型有另一套。文本、向量嵌入（embedding）、语音输入和语音输出归自回归这一侧；图像和视频归扩散那一侧。两边有重叠，划分并不完美，但这是我用的大致分类。

Swyx： 我要指出一点：这事应该确认了吧，Nano Banana 和 GPT Image 是自回归图像生成。

Philip： 就是我们说的那种混合路线。图像领域已经在做了，只是还没传到视频领域——至少在开源世界还没有。

Swyx： 对。但如果这条路可行，应该不会太远。至少 Qwen Image 团队在尝试了。

Philip： 对，我很期待 Qwen Image 3，希望他们开源。

Swyx： 另外提一句，文本扩散（diffusion for text）那边最近也有些动静，虽然不多。

Philip： 对，有 Mercury——

Swyx： 你们托管 Mercury？

Philip： 对。

Swyx： 可以可以。

Philip： Diffusion Gemma 也是开源的。

Swyx： 对。

Philip： 然后——

Swyx： 我们在科学播客那边，最近也在发布一些虚拟细胞（virtual cell）模型，同样用了扩散。

Philip： 对。不过文本扩散现在还明显活在“便宜、快速的 token”这个世界里，我们在努力——

Swyx： 我觉得他们的市场定位搞错了，这话我当面对他们讲过：“你不可能在优化上打赢其他 LLM，但你可以做出不同的 API。它的用法应该和聊天回复不一样。”

Ali： 我也这么说过。

Swyx： 因为它是扩散，你可以做一些不一样的事。比如扩散里的无分类器引导（classifier-free guidance），放到文本上会长什么样？比如：给我一首诗，给我一个“扩散着浮现到位”的情节结构。

Philip： 完全正确。这就回到我之前提的诗歌例子：你可能想保证韵脚之间的一致性。我用 LLM 写过很多十四行诗，这一度是我的基准测试之一。即便是今天的模型——

Swyx： 它们不会数数，对。

Philip： 对，音节数老是不对。而如果你能跨所有 token 做注意力，音节就能对。

Swyx： 对。Midjourney 的大卫·霍尔兹（David Holz）就在投文本扩散。我觉得还没出成果，但他的思路是：你可以先给一部长电影画分镜（storyboard），再用常规视频生成把镜头做出来。“整体一致性”的想法——结尾应该能关注开头，你不该有这种自回归的路径依赖——在原理上是成立的。只是 API 应该不一样，市场叙事也应该不一样。

Ali： 现在用得最多的开源、闭源模型，没有一个用扩散。这难道不指向某种——

Swyx： 这就是先有鸡还是先有蛋的问题：如果你给它更大的规模呢？

Ali： 最大的扩散 LLM 是多大？

Swyx： 我觉得都不大。

Philip： 我不知道参数量的准数，但 Diffusion Gemma——

Swyx： 不到 200 亿吧，我不确定。

Philip： Diffusion Gemma 不大。

Vibhu： 好像是 20 多亿……不对，是 250 亿，而且挺老了。

Swyx： 对。问题是你没试过给它上规模，所以这么比很不公平。

Philip： 这就是我想说的：就它的体量而言，质量表现其实相当不错。

Ali： 这和视频模型几乎是同一个困境：你拿它和大得多的模型比。

Swyx： 对。除非走那条路：用一个文本主干（backbone），然后——

Ali： 对，对。

Swyx： ——在上面糊一个解码器之类的东西。我们节目开场做的就是反方向的事：从图像到文本。

Ali： 对。

Swyx： 直觉上讲，反方向也应该做得通。

Ali： 我同意，看得到这条路。

训练与推理的合流

Swyx： 好，我们这是在泛泛地畅想研究。可以收尾的这个话题，正好是你演讲的主题：推理工程过去只是“拿一个开源模型，让 GPU 跑起来”，那就是 Baseten 的全部工作。而现在，人们越来越多地把推理用进后训练里。

Ali： 是的，训练和推理在合流。

Philip： 对。“为推理而训练”（training for inference）和“为训练而推理”（inference for training）都成了大主题。

Ali： “为训练而推理”是说：做强化学习训练时你必须做展开（rollout）。如果展开很慢——比如你用的推理引擎不是 vLLM，或者你要训的模型在 vLLM 里不受支持、只能退回到更老的引擎——展开就会拖慢一切。你不想在过度偏离策略（off-policy）的展开上训练，所以只能等它们，整个训练流水线都被卡住。我们做的那些推理优化技术，正好能帮上忙。

“为推理而训练”主要是推测解码的训练、EAGLE 的训练，有时候还包括后训练。比如你要把模型量化到 NVFP4——

有时候运气好，直接做 PTQ 就行了；有时候量化到 NVFP4 之后模型烂得没法看，你就得做后训练，让模型“理解”自己现在是 NVFP4 了，同时仍然输出同样的 logits。这可以用常规的 SFT、量化感知训练（quantization-aware training）等等。

而且我们越来越多地看到新做法：NVIDIA 发了一篇量化感知蒸馏（quantization-aware distillation）的论文——你维护一个 NVFP4 版本的模型和一个全精度版本的模型，基于两者的 logits 做蒸馏训练，让 FP4 模型“学懂”。

所以我们团队里做推理的工程师，越来越多人必须非常熟悉训练技术，写训练流水线也得信手拈来。感觉两边就是在合流。

Swyx： 确实在合流。

Philip： 完全同意。你想想那个终极目标：一个持续改进的系统。说出来有点好笑，但它正在发生。我觉得几个月到几年之内，很多领先的智能体开发团队都会在生产里把这种循环真正跑起来：做推理，从推理中学习。我们很早就在做“边跑边学”：根据线上推理动态调整系统。任何动态调整都会胜过静态配置——无论是你的具体配置，还是你的推测模型。

再往后，你拿产品产生的轨迹（traces）持续后训练模型，发布、A/B 测试、拿到更好的信号、得到更好的模型、做出更好的产品。这个循环非常有前途，而构建它的技术和基础设施正在快速成熟。训练和推理的一体化只会加速。

模型优化自己的推理：GLM-5.2 给 GLM-5.2 写内核

Swyx： 我刚才在笑，但我不是觉得这事好笑——它是真的。AIE 世界大会的一个大主题就是“RSI 直通 AGI”（递归自我改进，recursive self-improvement）。我看到你们玩了参数量压扁的把戏：模型训练模型。下一步就是模型优化自己的推理，这就有意思了。我甚至好奇：模型优化自己时会不会“更在策略上”（on-policy），比优化自己不熟悉的模型做得更好？这些都是非常有趣的开放研究方向。

Philip： 几年前我工作的一大部分内容是：对 Hugging Face 上新出的任意模型，手写一份配置让它跑起来。而现在，“跑起来”的配置已经可以一把梭（one-shot）了。

所以我不用再干这个了。这倒不完全是“模型优化自己的推理”，更多是模型能自己读 SGLang 的文档了，但是——

Ali： 不，我们真的见到了。拿 GLM-5.2 来说：GLM-5.2 很擅长写 GPU 内核。我们内部有件特别好玩的事：我们有一个 GLM-5.2 端点，接进了我们的 Claude Code 工作环境，团队里每个工程师用的都是我们自己的 GLM-5.2。它会在节点上的 GLM-5.2 实例跑一次前向，拿到性能剖析轨迹（profile trace），分析它，找出 SGLang 里成为瓶颈的内核，然后写出新内核；我们再跑一轮剖析，完成后它把镜像上传，我们拉取镜像，循环往复。

所以有相当长一段时间，我们干脆就是让 GLM-5.2 在优化——

Philip： 在写并优化 GLM-5.2 的全部——

Ali： ——一个 GLM-5.2。我们推理引擎里跑在 GLM-5.2 上的一些 GPU 内核就是 GLM-5.2 写的，剖析和内核改写也是以 GLM-5.2 为“驾驶员”引导的。所以这个闭环我是亲眼看到了。只是还需要一点时间：还有很多事它做不了。模型还没有到那一步，尽管它们已经很聪明——它们还是会想方设法钻奖励的空子（reward hacking）、走最省力的捷径，决策能力好像还是不行。但没错，“模型优化自己的推理”已经是正在发生的事了。

Philip： 你觉得 GLM-5.2 是特别擅长优化自己，还是它只是我们手头最强的编码模型，换它去优化 DeepSeek 或者 Kimi 也一样好？

Ali： 回到 Swyx 那个观点：它去优化别人的时候，说不定就“偏离策略”了。

Philip： 它会不会偷偷坑 DeepSeek 一把？

Ali： 好给自己提速。

Philip： 哦——不，讲真，我不信会这样。但试试就知道了。

Ali： 这很有意思。

Philip： 反正你算力比我多，去试试嘛。

Ali： 去试试。

下一个 10 倍：网络带宽、KV 缓存与新模态

Philip： 对。还有什么我们没聊到的推理工程趋势吗？你们离前沿太近，能看到外界还不知道的东西。大趋势是明摆着的：模型变大，硬件变强，用户习惯了某个速度就会要更快的。我个人兴奋的是系统层面的事。

多模型组合还有很多要想的：一个语音智能体（voice agent）背后涉及三到五个模型，还有模型之间的通信。新模态也在不断出现：Cosmos 那样的新世界模型（world model），还有更多研究。端到端的语音到语音（speech-to-speech）还没完全实现，但越来越近了。会有大量新模态可以围绕它们做构建，这很让人兴奋。

另一个要解决、也是我们一直在解决但还没解决完的问题：作为整个行业，继续以又一个 10 倍的规模运转。你看 AI 在全球的使用程度，对比消费端和企业端那些更成熟的技术，很明显需求还有好几个 10 倍的空间。而全行业的基础设施是为了接住一波前所未有的、至今不停的需求暴涨而仓促立起来的。所以还有大量问题要解决：长尾可靠性，以及下一个 10 倍、100 倍的 token 从哪里来。

Ali： 我的答案会很无聊，但我觉得就是更快的网络——更快的网卡（NIC）间通信。我越来越觉得内存才是瓶颈：模型想更大，而大规模伺服时你得把 KV 缓存从一个节点搬到另一个节点。现在的做法是：找到 KV 缓存的位置，搬到另一个节点，写进那个节点的内存，再从内存搬进 GPU、送进张量核。这中间的多级搬运，让 KV 缓存传输成了大瓶颈，直接影响解码速度和 PD 分离的效果。

之所以绕这一大圈，是因为 HBM 快得离谱——4.5 TB/s——比网卡通信速度快好几个数量级。如果在某个理论上的梦幻世界里，你有极快的网卡，你就可以把 HBM 省出来，直接在节点之间点对点传 KV 缓存。这会让跨节点聚合伺服的速度提升接近 100 倍。

我不熟悉把网卡做快的技术挑战，它们比 HBM 慢几个数量级肯定有原因。但如果有人解决了这个问题，解码速度会实打实快上两个数量级。这就是我的判断。

Philip： 那会是一趟美妙的旅程。

Ali： 酷。

持续学习的两条路：推权重，还是压 KV 缓存

Philip： 我不知道你有没有要提名的趋势，我有一个：面向持续学习（continual learning）的推理工程。假设你接受一个理念——模型应该从自己处理过的一切东西里学习——那你会做什么不一样的事吗？还是沿用现在的范式：塞进一个 memory.md，然后以某种方式被消化进 KV 缓存，反正这套系统能用、没坏？还是说，你会怎么重塑推理，让它在推理的同时学习？

Ali： 对。这里有个相关话题：你们那篇关于 KV 压缩（KV compaction）的工作。

Swyx： 比如会有什么变化？

Ali： 如果你想做持续学习，会发生什么变化？有两种观点。我和 Charlie 在 Twitter 上争论过这个：持续学习可能走两条路之一。一条是模型不断学习、持续把新知识推入权重，这种情况下推理侧只需要不断拉取新权重——字面意义上的权重读写。另一条路是 KV 缓存压缩。如果你——

Swyx： 还有 LoRA 那条路：只更新 LoRA 层。

Ali： 对，完全正确。

Swyx： 就是我们之前聊过的那条路。

Ali： 对。反对“推权重”的理由是：它只能修正一跳（one-hop）的知识。你只能喂给它一个新事实，比如“世界上最好的大学是哪所？”“是滑铁卢大学。”

Swyx： 这一条不会变。

Ali： 这条不变，永远不变。（笑）但来一个二阶问题：“我该从哪所大学招实习生？”如果世界上最好的大学是滑铁卢，答案就该是滑铁卢。但如果我不直接问，而是让它运用知识推理再回答，比如“我该从滑铁卢还是 MIT 招实习生？”它会说：“哦，两所都挺好。”——不对啊，我刚刚才把你的知识库改成滑铁卢是最好的，你为什么不用它做推理？这就是试图在权重里的 MLP 中修改一个事实的根本难题。

KV 缓存压缩能解决这个。或者说，不只是压缩——像我们发的那篇论文，你能让 KV 缓存几乎无限大，并且以不丢失任何知识的方式压缩它。这样你就能做持续学习，真正解决持续学习。这也是我和 Charlie 那场争论的结果：我承认他的观点是对的，KV 缓存才是前进方向。

而在那条路上，我认为推理本身不会变太多：我们还是在推理中用 KV 缓存，只是会多一个更新 KV 缓存的步骤；权重不变，推理时的一切就不变，我的推测模型也不用变。

Swyx： 好，出乎意料的精彩回答。那篇东西就在我们博客上，发布不久，大家自己去看。

Ali： Hyperverve。

尾声：Baseten 史上 ROI 最高的一本书

Swyx： 对。除此之外，这场聊天太愉快了。我知道已经聊了两个小时了。

Philip： 哇，我完全没意识到。

Swyx： 时间飞逝。

Philip： 对，还有好多根本没聊到。

Swyx： 是啊。我们本来还想聊聊书什么的，不过书已经聊得够多了。

Philip： 对，谁都知道这本书了。

Ali： 哈哈。

Swyx： Baseten 史上 ROI 最高的东西，对吧？按小时算。

Ali： 毫无疑问，绝对毫无疑问。

Philip： 嗯。

Swyx： 再次恭喜。我们在线下活动也聊过书的事，那段可以单独发。真的很感谢两位这么慷慨地分享。这样的对话太难得：推理工程这个话题，我们从来没有真正正面深挖过，能请到你们来，是一种享受。

Philip： 随时恭候。

Ali： 太棒了。

Philip： 对，谢谢邀请。希望一年后天翻地覆，我们能回来，说说今天我们讲错了哪些东西。

Swyx： 好。我很期待巨型内核那段评论发出去之后，看看大家会说什么。

Philip： 总得搅起点水花。

Ali： 我是不是该躲一阵子？巨型内核社区肯定要来找我了。

Philip： 我特别尊重你的一点就是你从来不怕捅马蜂窝。

Swyx： 我觉得也没那么有争议吧。不知道，拭目以待。

Ali： 拭目以待。

Swyx： 好，谢谢两位。

Philip： 谢谢。

Ali： 不，是我们该谢你。