推理前沿：从 10× 加速到自我优化 AILatent Space

JLM52 非常、非常擅长写 GPU kernel。我们内部有件事很有意思：当时有一个 JLM52 endpoint，被接进我们的 Cloud Code harness，团队里的工程师都会用它。它会先在 JLM52 的实例上跑一次 forward pass，然后拿到 profiling trace，分析瓶颈落在哪些 kernel 上，接着自己写新的 kernel，再跑一轮 profiling。完成后它会把 image 上传，我们再把 image 拉下来继续循环。所以，我们推理引擎里有些跑 JLM52 的 GPU kernel，本身就是 JLM52 写的。

正式开始今天的节目之前，先给听众一个很短的消息。谢谢大家。之所以我们能够持续做 AI engineering、science 和 entertainment 的内容，是因为你们真的会点进来、会收听。我们几乎每天都会收到赞助商的接洽，但因为有足够多的人订阅，我们目前还可以不靠广告维持下去，而且希望继续这样。唯一想请大家做的一件事，就是点一下订阅按钮；它完全免费，却是最能帮助我们的事情。对我和每周努力把 Latent Space 做出来的团队来说，这意义很大。只要大家继续支持，我们也会继续把节目做得更好。好了，进入正题。

今天录音室里有 Philip——老朋友了，我们之前围绕《Inference Engineering》这本书、Baseten 以及其他事情都合作过——还有 Ali。欢迎。

很高兴认识你。

Waterloo intern。

Waterloo intern Ali。你是什么时候把 “Waterloo intern” 注册成自己的 handle 的？

大概三月中旬我做了这个“品牌重塑”。我看到这个用户名还是空的，就觉得必须拿下，不然别人就拿走了。

问题是 Ali 工作做得太好了，他不会当太久实习生。所以我们得想想以后这个 handle 传给谁。

传火炬。

对，可以直接传给下一位 Waterloo 毕业生。

实习生、实习生、实习生。你们得再从 Waterloo 招一个实习生，而且最好还是 Baseten 招来的。以后谁从 Waterloo 来 Baseten，谁就继承 “Waterloo intern” 这个头衔。[笑]

不接受就出局。你们甚至可以办一个盛大的毕业典礼，在典礼上把 handle 改掉。[笑]

你们显然很会办仪式。之前那场新书发布也很不错、很成功。但在聊这些之前，我想先问个有趣的问题：你是推理工程专家。如果我向 Baseten 的推理系统扔进一个非常长的请求，比如 20 万 token，从请求进入，到 GPU、模型路由、负载均衡，整个过程中到底发生什么？有哪些平常用户根本不会想到的环节？

如果特指长请求，我第一件要问的是：这份请求你以前发过吗？或者至少其中一部分发过吗？我非常希望答案是“发过”，因为这样对我简单得多，对你也便宜得多。首先会做 cache-aware routing。通常我们会有多个实例、多个 replica 在服务你调用的那个模型；我们要把请求送到一个既有可用 prefill worker、最好又已经缓存了部分输入的地方。这样 20 万 token 里至少有一部分可以跳过 prefill。

如果真的是 20 万 token，我猜你多半是在做 coding、多轮 agent，或者类似任务，按理说其中很多内容本来就应该能命中缓存。如果完全没有缓存，那就只能把它送进 prefill worker。

在某些模型上，我们已经把 prefill 和 decode 做了 disaggregation。也就是说，会有一组 GPU 专门处理输入请求、构建 KV cache、生成第一个 token；然后把结果交给另一组 GPU，由它们进入 decode，逐步生成后面的 token。

decode 前面通常还会放某种 speculative model。假设你是在做 coding，那么一个针对 coding 的 speculative model，draft token 的接受率会很高；但如果我的假设错了，你其实是在让我总结整套《哈利·波特》，速度就会慢一些。最后我们把输出 stream 给你，同时计费——在公共模型 API 的场景里，可能就是几分钱——然后问你还要不要再发一个请求。

不过 Baseten 可不是都按“几分钱”来收费。

对，我刚才假定的是公共 model API。如果你搭的是 dedicated deployment，那当然不是几分钱。

我一开始跟 Baseten 聊时，一个很关键的差异就是：如果用户量特别大，实际上直接按整台机器租更合适。因为那样就是你自己负责把 box 吃满。每小时跑几百万 token 时，按小时付费经常比按 token 付费便宜得多。

我们越来越常见的路径是：用户先用 pay-per-token API，因为大家都想快速试一下 open model；等找到真正 sticky、会长期高频使用的 use case，再迁到 dedicated deployment。

有没有一个最佳实践，说明什么时候该切过去？

有几个理由。可靠性就是很重要的一个。还有客户可能有非常具体的 use case，希望你针对自己的 traffic 训练某个东西，例如希望有自己的 speculative decoding draft model。

“Spec doc” 这里说的是 speculative decoding。

对，推测解码。假设你有一个很大的模型，正常情况下每次 forward pass 只能一个 token 一个 token 地生成。我们会在上面挂一个比较小、像“寄生层”一样的 draft model。它先用非常快的自回归 pass 连续猜，比如三个 token；然后大模型只做一次完整 forward 来验证这三个预测对不对，正确的就接受，错误的就拒绝。

这个 draft model 可以针对具体分布训练。如果你一直在总结《哈利·波特》，我可以专门拿《哈利·波特》去训练 draft model，于是三个 token 很可能次次都能被接受，decode 就会明显加速。但共享 endpoint 上我做不到这一点，因为我根本不知道下一位用户是在做《哈利·波特》、coding、英文文本还是别的东西。

书里还提过一种情况：如果客户特别在意某个具体阈值，好像在第四章？

对。你可以为自己的 endpoint 设特定 batch size、特定 parallelism strategy；如果目标是 throughput 或 latency，两种配置可能不同。也可能 NVFP4 quantization 在你的 benchmark 上过不了，你宁愿用更高 precision。总之，想拥有自己的 endpoint 有很多理由。最实际的一个是：你不必在自己服务真实用户时，碰上另一个人突然往共享 endpoint 里塞一亿 token 的 benchmark traffic。

这很像经典的“在浏览器里输入 Google 以后发生了什么”那类问题。那 tool calling 呢？它本质上只是生成 JSON，还是还有更复杂的东西？

有些客户用的是自己 post-trained 的模型，他们需要的 tool calling 并不是“读一个文件”或者“查天气”这么通用，而是非常具体的工具，所以 post-training 本身就很关键。模型的 post-training 如果没做好，或者 post-training 以后为了把 inference 做快而做 quantization，导致质量下降，模型就可能连 JSON、tool call 都读不好。

但这不意味着 tool calling 自己需要一个特殊 sandbox。模型并不会因为能调用工具就自动“逃出沙箱”。普通 dedicated deployment 就可以。越来越难的地方其实是：公司希望模型调用的是非常具体的工具，而这种能力对训练很敏感。JSON 输出里，如果请求结尾没有按非常精确的方式闭合，模型可能根本没有正确看到工具返回结果，接着在 decode 时直接 hallucinate 一个结果。现在 tool calling 真正棘手的更像是这个，而不是 sandbox。

这属于训练侧的问题；推理侧也可以做一些工作，限制模型允许输出的范围。我们差不多两年前就发布过一种解法：构造一个 state machine，用它把输出约束在某个指定格式里，也就是 structured output。以前大家会用 grammar 来保证输出只能是 JSON。

对，就是那种“只能给我 JSON，否则 grammar 要炸掉”的老问题。有一阵 OpenAI 甚至直接说，如果你想约束输出，就写 BNF grammar，也就是 Backus–Naur Form。

在我们的 inference system 里，就是指定 output format，然后系统保证输出沿着那个格式生成。把它用于 tool call，可以消掉一大类结构问题。当然，模型还是可能调用错工具，也可能根本不调用工具；它不能解决“模型是否做对决定”的问题，但至少能解决 tool-call 输出格式的问题。

MCP 也只不过是另一种工具，对吧？

对，没有什么神秘的特殊机制。

我经常跟人解释：LLM 本身其实什么都“做不了”。它真正能做的只是提出“下一步该做什么”的建议。如果建议被格式化成某种约定形式，再交给一个真正知道怎样执行的系统，动作才会发生。

而且在 agent loop 里，有些问题甚至不必靠严格 tool calling 才能恢复。如果一次输出不对，reasoning 可以变成：“我不知道该怎么办，那再试一次。”试几轮以后也许就能走到正确路径。但这也和训练有关，尤其小模型更难。你不能把一个大模型直接替换成小模型，然后期待完全一样的输出质量。

我们还是得回到“正经的 inference engineering”。[笑] 不过我原本以为 JSON 最终会被别的格式替代，因为 JSON 很难 streaming：括号必须开闭完整，你在流式输出尚未结束时不太容易解析或验证。后来大家发明过很多替代格式，我一时都记不起名字了，大概类似 TOML、YAML 那些东西。但到现在 JSON 似乎仍然占主导。

不过一般 tool call 的 JSON 也不会特别长吧？当然参数里可能塞一个很长的值，但我对中位数 tool call 的直觉是 token 数并不多。而且像 JSON 这种格式高度固定的内容，speculator 理应很擅长，所以 decode 会很快；这样一来 streaming 的价值可能本来就没那么高。当然，也可能我判断错了。

……所以我会预期，tool-call 这一步本身很快，流式输出未必像想象中那么重要；不过这个判断也可能是错的。

工具调用的格式最终还是受它要接入的软件约束。如果客户的软件和工具接口就是 JSON，你当然可以建议他们换一种对模型更友好的格式，但对训练本身来说差别未必那么大。至于是不是让模型多吐 token 就更赚钱，那完全取决于商业模式。

以写作者的角度，我自己大量实验 AI 输出，反而会从纯文本走向“文本装在 JSON 里”，而且 JSON 很长：每个 field 里可能都是一整段。我想让模型先列事实，再列观点，再给 bullet summary，还要有日期、entity reference、reference source。真正重度使用 structured output 的人确实会在意这些细节。

往上回到 inference engineering。录音前你们提到一个很有意思的点：每当一家模型实验室发布新模型，推理公司背后其实要做大量工程。比如假设 GLM 5.2、Kimi K3 发布。我过去会觉得，如果之前已经支持 GLM 5、5.1，那 5.2 还能有多少工作？

很多工作。

每次新模型发布，大家都会争着宣布 Hugging Face 支持了、某某服务商支持了、Baseten 支持了。我以前会想：“当然会支持啊。”但实际上“支持”里面到底包含什么？

而且它不只是一个打勾项，对消费者确实有实际价值。像 Kimi K2.5 或最近的 GLM 5.2，就出现过一场 inference war：一家服务商先做到 90 tokens/s，第二天另一家就冲到 150。

GLM 5.2 那一轮大概是我先点燃的。我写了一篇 Twitter 长文，有差不多 50 万浏览。

“社会网络第一名”。[笑]

然后大家都开始想还能不能把 benchmark 再推一点。这里必须区分两件事：“支持一个模型，能让它吐出 token”，和“把它做成 production-ready API”，完全不是一个级别。

让模型先吐出 token 通常没那么难。vLLM、SGLang 之类开源 inference engine 的维护者，有时会提前拿到 weights，或者模型团队自己提 PR 把支持合进去。所以多数情况下，标准开源 stack 很快就能跑起来。

难的是每家 inference company 都有自己的 proprietary stack：有开源组件，也有内部系统。任意一个新模型，总会有一些新的地方。偶尔会很幸运，比如 K2.5 到 K2.6 结构非常接近，记得主要是 continued post-training。但即便如此，也仍然要重做 quantization。

模型通常不会直接以 NVFP4 发布，而我们为了 Blackwell 上的最大兼容和效率，会把它量化到 NVFP4。量化以后还必须 calibration，确认没有让模型 intelligence 回退。接下来还要训练 speculator。

我们的 model API 是 ZDR——zero data retention——所以并不知道用户具体把什么数据发给我们，但知道哪些 use case 热门，比如 coding、agentic workflow。我们可以用公开数据集去近似这些流量分布，训练比较通用的 speculator。

今天训练 speculator 时，需要真正的 base model weights。因为你要在这些具体 prompt 上跑 inference，从模型内部拿 hidden states，那些 hidden states 才是训练 speculator 的数据。除此以外，还要把背后的 infrastructure 全部立起来、装载、测试。

如果是新 architecture，事情会更多。DeepSeek 系列往往最难，因为一代到下一代经常有比较新的架构设计；但其实任何新模型都会带点新东西。GLM 5.2 里就有从 DeepSeek 借来的 DSA，我们必须让自己的 runtime 支持它。

开源实验室互相借设计其实很有意思。比如 GLM 5.2 没有 vision，我们团队的 Haley 就做过一个实验：把 Kimi 的 vision encoder graft 到 GLM 5.2 上，只训练 projector。

结构上可以把它理解成三块：encoder 负责“看图”，把图像变成 latent information；projector 把这些表示映射到语言模型的空间；后面才是大模型 weights。你不希望为了加视觉能力去动原来的 model weights，因为那可能让模型在其他能力上变笨。所以先只训练 projector——它只有几百万参数量级。

这个训练过程很酷。最开始只是给一张山的照片，让模型描述“图里是什么”。但只做 caption 并没有带来完整理解。于是后来改成：每张图配一组问题，比如“图里有没有白人男性？”“右上角有没有鸟？”“有没有科学家？”模型必须逐题答对。

这里可以把“脑子”和“眼睛”都冻结：语言模型本身冻结、vision encoder 也冻结，只训练两者之间的连接，也就是 projector。它拿到 Kimi encoder 已经编码好的图像表示，然后学会把这些信号翻译成 GLM 能理解的表示。

从单纯“描述图片”，改成不断对图像回答不同问题后，可以看到非常明显的 grokking。一个本来纯文本的大 LLM，竟然可以通过这种 retrofit 学到相当程度的视觉理解，这很惊人。即使遇到它认不准的人物，比如给 Stephen Hawking 的照片问“这是谁”，它可能答成 Albert Einstein，但仍然知道“这是一个男性科学家、做过重要成就”这一语义类别。

我们以前也聊过 LLaVA 的作者、CLIP、MetaCLIP 这一脉工作：从单纯 captioning 走到基于图像生成和回答问题，性能能提升很多，这些都是做 vision 很基础的思路。

这个实验本身更偏 research，MMLU 好像只到 56% 左右，还没到真正好玩的程度。但最有价值的一点是：如果输入没有图像，原来的 GLM 5.2 quality 完全不会损失，它就像过去一样工作。

在 inference code 里，没有图片时实际上直接不走 vision encoder。vision encoder 通常也不大，往往不到十亿参数；虽然不同 vision encoder 之间标准化没那么好，support matrix 可能有些稀疏，但相对整个系统它还是小组件。

最终你得到的是一个非常“开源式”的组合：Kimi 的 vision、GLM 的 weights、DeepSeek 的 attention，全部装进一个系统。开源的力量就在这里：可以把不同实验室的组件重新组合，做出单个实验室未必会直接发布的东西。

以前大家还会做 Franken-merge，从不同模型里抽 layers 拼起来。现在还有吗？

有，而且有时非常必要。比如某个新模型使用 full attention，那么自回归生成时会出现 O(N²) 的开销，KV cache 也很大，因为不是 sparse、也不是 top-K。为了推理效率，可以把某一层换成另一个模型里使用 GQA 的层，再通过正确训练把 acceptance rate 拉回来。

所以，从别的模型 retrofit layer 是完全可行的。真正难的往往是训练：怎样训练才能保证替换以后仍然对。这又回到前面那个越来越明显的趋势——training 和 inference 正在咬合在一起；想把 inference 做得很快，越来越需要很好的 training。

那“完全 production-ready”除了这些还包括什么？

还有真实世界测试。我们内部能测试很多，但新模型又要求尽快上线，所以真正开放 endpoint 后，会有远比内部测试丰富的输入。GLM 就曾短暂出现过 mode collapse：某些 prompt、某些 temperature 下，模型会不断输出同一个 token。

所以 day zero 并不是结束。新模型如果一直热门，第一周、第一个月都还要持续修 bug、继续推性能。

什么？你不喜欢模型一直输出 “SSSSSS”？[笑]

这种 loop 现在还会出现。我们的 endpoint 如果检测到模型把同一个 token 连续输出四次以上，通常会直接终止 generation，提示用户重试，或者重新处理请求，因为这大概率就是 collapse。当然像画表格时连续十几个短横线是合法输出，所以会排除一些特殊字符，只对某些 token 做这个检测。

主持人先追问：如果模型真的需要连续输出重复 token，能不能 opt out？比如画 Markdown 表格时本来就可能需要连续十几个短横线。回答是系统会对这类情况做例外处理，某些 special character 不会简单按“重复四次就是 collapse”去截断；具体规则嘉宾自己也说记得不完全确定。

“S” 好像特别常见，在某些 GLM/DeepSeek 版本上都见过。它也不只是 temperature=0 才发生，0.9 之类也可能 collapse。

这很奇怪，但更像 inference software 问题，而不是 weights 问题。比如 NVIDIA 发布一个新的 inference image，我们把最新 TensorRT-LLM 的改动 upstream 到自己的 stack，有时问题就消失了；或者同一份 weights 在某个 inference engine 上复现，在 vLLM 上却不复现。

所以不能简单说“quantization 做坏了”或者“模型 weights 有问题”。如果同一份 weights 换一个 inference engine 就没有问题，根因显然不在 weights 本身。

更麻烦的是 backend kernel 里可能有很细的 race condition。同一个模型放在某个 cluster 永远不出问题，换一个 cluster 就会出；原因可能只是前者 node-to-node 的 KV cache transfer interconnect 比另一个 cluster 慢或快，恰好把 race 暴露出来。最后你只能先做工程决策：这个模型别放这个 cluster，换到另一个 cluster。但从归因角度看，到底是 software、model weights 还是 hardware，就非常难拆。

这也和“temperature=0 仍不完全 deterministic”有关：同一个模型、同一设置，并不保证每次输出都一模一样，硬件执行细节也可能参与其中。

我本来以为 PyTorch graph 至少保证操作顺序。

实际优化会更激进。比如某些优化会在前一个 kernel 还没完全结束时就启动下一个 kernel，这本来就是为了隐藏开销。更典型的是 kernel 自身的 race：如果写 CUDA kernel 时为了追速度，barrier 或 synchronization 写得不正确，某些 thread 可能在另一些 thread 还没把值写进 register 前就先读了。测试这种问题非常难。

有没有类似 Rust borrow checker 的东西，能在更高层保证 memory safety？

但这里毕竟是在 CUDA / NVIDIA GPU 上。也许需要更高层的语言，比如 Modular 想做的那类东西，不过我也不确定。[笑]

那么做完 quantization、训练 speculative decoder、换不同 hardware 之后，怎样确保模型 quality 没掉？消费者看到的是一场速度竞赛，但到底怎么决定量化到什么程度、标准是什么？

质量上首先要分清：很多 inference optimization 本来就是 lossless。KV caching 只是避免重复计算同一个值；speculation 里 draft token 如果错了就会被 reject，所以理论上也不会改变最终输出分布。真正需要格外小心的是量化等会直接改变数值表示的优化。

真正主要的 lossy optimization 是 quantization。它大体取决于三件事：第一是 data format；第二是选择模型哪些部分、哪些 layers 去量化；第三是对量化后的 weights 做足够多 calibration，尽可能保留 outlier。

还有 long context。最开始你问 20 万 token 请求会怎样。长输入意味着要存更多信息、处理更多 token。即使模型宣称支持某个最大 context length，inference provider 也可能同时提供一个更短 context 的 API，因为如果用户根本不需要一百万 token 的完整 context，用更短配置可以拿到更好的性能。

我不一定把这称作“模型 quality”。我理解的 quality 是：我们到底多忠实地服务了原始模型。假设存在一个 golden implementation，完全按模型设计运行，那么 inference optimization 的目标就是在加速的同时尽量保持接近那个 100% fidelity。

当然，从 training 角度还可以问怎样超过“原模型的 100%”；但如果只谈 inference，我们内部的标准是：用户不应该能分辨我们的 API 和官方 API 在模型行为上有系统性差异。Kimi 在 vendor benchmarking 上做得尤其认真，他们甚至做过 vendor verifier。

这很合理。消费者如果在某家云厂商的 endpoint 上用 Kimi，觉得表现很差，通常不会说“这家厂商把量化做坏了”，而会直接得出“Kimi 不行”的印象，所以模型厂商当然会在意第三方服务质量。

一个看起来有点傻的问题：quantization 有没有可能反而让某些指标变好？还是它严格来说永远更差？

技术上 quantization 是 lossy implementation，速度当然会提升。但因为模型和 benchmark 本身有非确定性，偶尔 FP4 quant 的分数会比 full precision 高几个 basis points；那通常只是 noise、在 margin of error 里，不意味着量化真的提升了模型 intelligence。

不过我们做过一项研究，有一个更微妙的结果。研究实习生 Joshua 做了大概两个月，目标是让 JLM/GLM 5.2 的量化比例比 NVIDIA 的方案高大约 20%，同时维持甚至提高相对于另一份 quantized model 的 fidelity。

从 16-bit 压到 4-bit，本质上一定丢信息，所以问题变成：哪些 layers 能量化、哪些不能。比如 image model 里，我们通常不量化 modulation layers，也不量化 output projection，因为 output projection 直接影响用户看到的结果，而 modulation 又关系到模型内部如何理解信号。

有意思的是，量化更多 layers 并不必然比量化更少 layers 差。假设一个模型量化第 1、5、10 层，另一个只量化第 1、2 层，前者有可能反而更忠实，因为不同层的 quantization error 会相互抵消。

承接前一块，Joshua 的数学证明和 verifier 所做的，就是预测哪些层的 quantization error 会互相 cancel，再选择这些层去量化。这样反而可以比另一份方案多量化约 20% 的层、提高 throughput，同时让最终 logit distribution 更接近 full-precision 模型。

他们用 KL divergence 比较 quantized model 与原始 full-precision model 的 logit distribution，而不只看 benchmark 分数。这里的结论不是“量化能让模型更聪明”，而是“更多量化不必然单调变差；如果误差方向互相抵消，fidelity 可以更好”。

这让我想到 pruning。没想到你们还为此写了一整篇 paper。

[笑] 有趣的是，这篇 paper 最早一度有 72 页，我们想缩，结果最后反而变成……总之现在还是接近 39 页，非常 substantive。

回到大家最关心的 speedup。比如官方 API 是 70 tokens/s，你们把它推到 90，这算常态吗？

推理工程现在最迷人的地方是，它还远没有像金融那样被优化到极致。在量化金融里，如果你提高 5 basis points，也就是 0.05%，都可能是大新闻；但我们现在发布 inference optimization，经常是 20%、100%、200%。等哪天大家只能发“又快了 1%”的博客，才说明这个领域真的被榨得差不多了。

这和量化金融早期很像。70 年代做 quantitative finance 时，也可能找到 10%、20% 级别的优势；后来分布不断收窄，到今天只剩很小的 edge。Andrew Lo 有篇 paper 很好地画过 statistical arbitrage 优势如何从早年的巨大差异逐渐收敛。推理工程现在大概还处在类似的早期。

当然 benchmark 很难。provider speed 受太多变量影响：什么 hardware、系统上有多少 load、prompt 的性质、input/output sequence length 等。把多个优化叠起来以后，我们看到的通常不是几个百分点，而是 multiples。

行业里常说 TPS——tokens per second——这个命名其实很糟，因为这里至少有两个“tokens per second”。一个是整块 GPU 的 throughput，另一个是用户感知的生成 latency。大多数人嘴里说 tokens/s 时其实关心后者，更严格地讲应该讨论 ITL，也就是 inter-token latency。

设想一个一万亿参数左右的模型，在比较普通、没有多少优化的 API 上，对于合理 traffic profile，可能在 30–50 tokens/s。我们的目标当然会瞄准把它推到接近一个数量级更快。三个各自 2× 的优化叠起来，理论上就是 8×；所以这个领域确实是在追“成倍加速”，而不是只从 70 到 90。

真的已经能做到 10× 吗？

如果 baseline 是 30–40 tokens/s，在很理想条件下可以碰到 300–400，也就是近 10×。以 GLM 5.2 为例，如果你用未量化模型、普通 off-the-shelf inference engine，没有 speculator、没有额外 KV routing、没有 disaggregation，30–40 是合理起点。

但要到 300–400，tradeoff 很多：用最好的硬件；有优化过的 speculator；quantization 做完；cache hit rate 很高；batch size 比较小；parallelism 也专门按 latency 而不是 throughput 去调。Artificial Analysis 或 OpenRouter 上最慢 provider 到最快 provider，有时确实能看到接近这种跨度。

所以 10× 是很激进的上界场景。更常见、更现实的巨大提升，可能是 4–6×。这已经足够让人兴奋。

而且硬件差异不能混在软件优化里。你当然可以把 H100 单机上的模型搬到四个 B200 node 上，单靠堆硬件把速度抬高。如果严格 normalize 到同一种 hardware、同样 GPU 数量，单靠 inference optimization 更常见的是大约 2–4×。

那同一台 B200 node 上跑 GLM 5.2，最主要的两三项是什么？

Speculation 和 quantization，差不多占绝大部分。今天如果直接部署，很多现成 NVFP4 weights 和 speculator 可以拿来用；但如果你是在模型刚发布时从零做，就要投入很多工程。

从 BF16 到 NVFP4 并不是严格 2×：16-bit 到 8-bit 可能带来大约 30–40%，8-bit 到 4-bit 再乘一个大约 30–40%，合起来接近但不到 2×。然后 speculator 又大约 2×。

在硬件和流量都足够、能够把 prefill/decode disaggregation 吃满时，disaggregation 还可能再贡献大约一个 2×。最后再叠上新版 runtime、更新的 kernels 等带来的两位数百分比增益，差不多就是这套加速栈如何一步步累积起来的。

对真正熟悉这套东西的人，从零做一份合格的 quantized weights，通常是数小时到数天；训练 speculator 也大致是数小时到数天。Prefill / decode disaggregation 第一次把整套能力做通当然很难，但一旦底层系统已经存在，把一个新模型接进去的边际工作也更接近“小时到天”，而不是重新做一套研究项目。

如果只是一个普通用户，手上有一组 B200，想把模型自己托管起来，其实不必亲手重复全部工作。社区通常会出现开源量化 checkpoint；如果没有，NVIDIA 一类厂商也往往会补。模型提供方也可能放出自己训练的 speculative / multi-token-prediction 组件，因此未必需要自己再训练一个 speculator。

这里有人举 GLM 5.2 的 MTP 为例，并把 MTP 展开为 multi-token prediction。有人提出它或许可以直接用于 self-speculative decoding，但回答马上是“我其实不确定”；另一位也只说自己“有一点把握，可以让别人核对”。所以这里保留这个不确定性，不把它写成已经确认的能力。

主持人把问题从个人用户推到公司：如果一家团队从 serverless inference 迁到“租一批 GPU、自己把模型架起来”，量化、speculation、disaggregation 就是让部署明显快于“把模型直接丢到通用 inference engine 后面”的典型步骤。

随后话题终于转到 NVIDIA Dynamo。主持人原本以为 Dynamo 应该是大家拿来比较的 baseline；嘉宾则更愿意把它理解成一个 developer toolkit，而不是一个开箱即用、装完就自动获得巨大 speedup 的 optimizer。

Dynamo 是 NVIDIA 的开源库，它能跨不同 inference framework、不同硬件去协调 cluster 内的信息移动。比如 KV cache 在一个地方、下一步需要到另一个地方，Dynamo 可以协调相应的数据传输；KV-aware routing、KV offloading、prefill/decode disaggregation 都属于这种系统能力。它有默认组件，但真实部署仍要按 traffic 和 hardware 替换、调优。

因而“pip install Dynamo”不等于性能立刻暴涨。只有当行业里的部署模式足够标准化，它才更像一个稳定 baseline；现实里推理团队仍然得拿它和生产环境里真正看到的方案做 benchmark。

主持人又翻到《Inference Engineering》里关于 Medusa、Eagle 等方法的章节，问为什么有些一两年前的技术还留在书里。回答是：这本书一方面要给读者整个领域的 working vocabulary，另一方面要建立“这些方法为什么成立”的直觉，而不是保证每一节永远代表最新 SOTA。Medusa 已经比较老，speculation 这一支的变化速度比书里很多主题都快；Eagle 仍然很常用，但它后面也已经有新方法。

Speculation 这一支发展得很快。节目里提到一些比 Eagle 更新的方法，也提到字幕识别成 “Sparkspecter” 的工作：直觉上，它是在 speculative decoder 自己的自回归过程中再做一层 speculative decoding，也就是“对 speculator 再 speculate”。

这个想法之所以听起来合理，是因为普通 speculative decoding 本来就像自动补全：小模型先连续猜三枚 token，大模型再一次性验证，从而省掉大模型三次逐 token forward。既然小 speculator 自己仍然要做三次 autoregressive step，理论上当然可以再用一个更小的模型替它猜。

他们确实看到过非平凡的 speedup，但训练过程被形容得接近 GAN：平衡非常微妙，工程上经常不值得。这里不是说思路错误，而是收益必须覆盖额外训练难度、验证逻辑和维护成本。

接着有人问 speculator 到底有多大。例子里常见是大约十亿参数，或者只有目标模型大约六十分之一、甚至近似一层那么小。于是出现一个很自然的问题：如果最小模型能准确预测中间 speculator，而中间 speculator 又能准确预测 target model，为什么不干脆直接用最小模型？回答是：这开始变成 routing problem，而不是简单的“再套一层 speculator”。

还有一个非常现实的限制：draft model 往往和大模型争用同一套硬件。每一枚 draft token 都要花计算资源，inference engine 还要管理接受、拒绝、验证和调度。所以无限递归的 speculator 不只是训练复杂，也会把 runtime orchestration 和 resource competition 一起放大。

有人顺势问，既然 speculator 本质上也是模型，能不能对它做 distillation、pruning、quantization，把它再压小一些。嘉宾没有在这里给出确定结论，只承认这是自然的方向，但超出了当下讨论的范围。

然后问题转到 local AI：这些为大型 server workload 设计的办法，能不能原样用于 MacBook 上高效跑 Gemma？答案是“问题相似，但约束很不一样”。本地推理的第一目标是“怎样把模型塞进我的硬件，同时别让它太笨”；数据中心则更像“模型已经能装下，怎样让它别那么慢”。两边都关心质量和速度，只是优先级相反。

因此本地生态里对极限压缩、低精度 KV cache、稀疏化等技术的重视程度会更高；数据中心拥有更高内存带宽和更大的容量，往往还有别的优化先做。不过嘉宾也强调，本地 AI 在这些方向积累了很多值得数据中心推理借鉴的经验。

本地 AI 社区在 dynamic quantization、pruning、distillation、layer removal 等方面有很多值得数据中心学习的经验，但具体技术不能照搬。某些在 MacBook 上非常有效的优化，是因为内存带宽很低；放到 NVIDIA B 系列 GPU 上，dequantization/quantization 本身的 kernel overhead 反而可能超过节省的带宽时间。

例如节目提到 TurboQuant：在 edge device 上可能很有价值，但 B 系列 GPU 的显存带宽达到数 TB/s 量级后，就未必需要为了减少 KV cache 存储付出额外计算。原则相通——量化、稀疏化、减少搬运——但最优实现取决于 hardware bottleneck。

接上本地 AI 的话题，数据中心的显存和内存带宽宽裕得多。节目里举过约 3.5 TB/s 的带宽量级来说明：在服务器上，不一定非要把 KV cache 压到 FP4，也不一定需要 TurboQuant 这类极端压缩；但在 edge device 上，这些节省容量的方法可能非常重要。两边会共享量化、稀疏化等原则，却不会有完全相同的最优解。

本地集群和数据中心都必须面对机器之间的 interconnect。节目提到把多台 Mac mini 之类的机器通过普通网络连起来；这种拓扑和同一台服务器内的 NVLink 完全不同，所以 parallelism strategy 也会改变。

数据中心常用 tensor parallelism，把同一个模型的矩阵跨同一 node 的多张 GPU 分片。TP 很依赖 NVLink 一类高带宽互联：每一步计算后都可能要 all-gather / all-reduce，把不同 GPU 的部分结果重新组合。因此它并不适合通过普通 Ethernet 连接的本地小机器集群。

主持人看到书里的图，专门请他们简单解释 tensor parallelism 和 expert parallelism。嘉宾先补了一个对 MoE 很重要的区别：本地 batch=1 时，“active parameters”确实能帮助你理解一次只激活多少参数；但做高吞吐 API serving 时，batch 里不同请求会命中不同 experts，容量规划通常要按大量乃至所有 experts 都可能被激活来想。

Expert parallelism 只适用于 MoE。做法是把完整 expert 放在某张 GPU 上，router 很小，可以复制到各 GPU；通常 experts 数量多于 GPU，所以一张 GPU 会放多个 experts。token 被路由到某个 expert 后，expert 的计算可以在本地完整完成，GPU-to-GPU 通信压力相对小，吞吐能力就能做得很高。

Tensor parallelism 则是把矩阵本身切开。比如下一步要做 softmax 这样的 non-linearity，就必须知道 GPU1 和 GPU2 各自算出的 partial result，因此需要持续通信。总体上 TP 常常对 latency 更有帮助，而 EP 更偏 throughput；这只是高层概括，并非所有模型都严格如此。

两种 parallelism 并不互斥。真实的大 MoE 模型常常同时做 TP 和 EP：node 内通过高速互联切矩阵、分 experts；只有模型大到一台 node 真的装不下时，才更可能进一步引入 pipeline parallelism 跨 node。

Pipeline parallelism 通常是在被迫跨 node 时才用：把不同 layers 分段放在不同机器。嘉宾举例，如果因为某种原因要在 H100 上部署一万亿参数模型，单个 node 装不下，就只能跨多 node；而 node 间 interconnect 太慢，所以常见做法是 node 之间 pipeline，node 内再结合 tensor / expert parallelism。

这里还出现了一个现场自我修正。有人先把 H100 显存说成大约 140GB，马上被纠正为 80GB，于是自嘲“我老了，我居然还记得 H100 的规格”。节目还拿更高显存的新一代卡做口头计算，说明模型容量不仅取决于 weights，还要给 KV cache 和 runtime 留空间。

他们又提到 AI21 的 Jamba：那类工作会先选定目标 hardware，再按硬件尺寸设计模型 architecture，让模型天然更容易把硬件吃满。主持人奇怪为什么更多模型不这么做；回应是训练侧确实会更系统地按 FLOPs 和硬件预算做数学规划，但 inference 的最佳配置常常没有那么容易靠公式一次算出来。

Inference 更像 auto-tuning。假设只有两张 GPU，就可能尝试 TP1/TP2、EP1/EP2 等组合，把真实或 shadow traffic 跑过去，看 TPM、TPS、latency 哪个最好，再经验性选择。嘉宾甚至说自己并不喜欢这种“无法纯推理出唯一最优配置”的现实，但目前 auto-tuning 确实是最可靠的方法之一。

GPU kernel 也一样：kernel 写完以后，还要决定 launch 多少 threads、用多少 shared memory 等。工程实践往往就是 sweep 参数空间，测出 empirically 最快的组合。Parallelism 和 kernel tuning 并不是分开的两件事，它们会一起决定最终性能。

NVIDIA 自家的 NeMo 一类模型在 Blackwell 上跑得很好并不令人意外，训练本来就可以带一些 hardware targeting。但多数开放模型实验室仍希望模型能跑在尽可能广的硬件上，而不是只服务一颗芯片。

主持人于是问到 Silicon Valley 很热的 mega-kernel：既然 all-gather / all-reduce 昂贵，把更多东西 fuse 到一个 kernel 里能不能直接解决？回答是否定的。Tensor parallelism 下半个矩阵在 GPU1、另一半在 GPU2；如果下一步 softmax 需要完整 row，两个 partial result 仍然必须合起来，fused kernel 消不掉由 non-linearity 带来的通信需求。

因此嘉宾对 mega-kernel 明显偏 bearish。它是很有价值的研究方向，但“融合越多越快”不是通用规律；真正高度优化的巨大 kernel 本身就极难写，而系统瓶颈还可能在 kernel 之外。

Mega-kernel 的直觉确实很漂亮：kernel launch 有开销，同一批数据又会反复使用，那就把尽可能多的操作 fuse 在一起。但问题是，写出一个真正高度优化的大型 fused kernel 本身非常难，复杂度会随着融合范围迅速上升。

嘉宾说自己接触过专门做 fused mega-kernel 的团队，也和相关工程师聊过；现实里他们经常并不会把最激进的 mega-kernel 跑进生产。原因不是研究没价值，而是模块化 kernel 可以分别优化、再并行调度，最后有时反而更快、更可维护。

话题接着被一条 NVIDIA 关于 Rubin 的帖子打断。现场还开了个玩笑：有人一度以为“Rubin 还有自己的 Twitter 账号？”其实说的是 NVIDIA 技术负责人刚发布了一组 Rubin 规格。嘉宾说自己还需要把细节读得更仔细，但初看第三条技术说明时，感觉硬件本身正在吸收过去很多必须手写 kernel 才能完成的工作。

所以他半开玩笑地说，新 GPU 的设计“几乎要把我的 kernels 干掉了”。这只是初步判断，不是已经验证的长期结论；他明确说自己还没有把 Rubin 的细节读透。

主持人于是请 Philip “大胆猜一下 Rubin”。大家顺便打趣《Inference Engineering》为了 future-proof，连 Rubin 后面的 Feynman 都已经写进去了；Philip 说自己不想明年就又出一本新版，所以尽可能把硬件路线往未来写。[笑]

更严肃的经验来自过去三轮硬件周期：Ampere、Hopper、Blackwell。这里说的 launch cycle 不只是芯片出货，而是“硬件已经上架”到“软件栈真的能把它用于高效 inference”之间的过程。早期 vLLM 主要面向 Ampere，后来必须逐代适配 Hopper、Blackwell。

每一代从硬件可用到 inference stack 成熟的速度都在变快，紧迫性也更高，但系统复杂度同样在上升。这也是他们判断下一代推理工程会越来越偏 systems engineering 的经验背景。

从 Rubin 往前看，Dynamo 给出的信号很明显：Blackwell 开始的趋势会继续，NVFP4 tensor cores 的算力很大，memory bandwidth 也会继续提高。但 Philip 认为更重要的是 systems thinking——CPU↔GPU interconnect、GPU↔GPU interconnect、KV cache 应该在什么时候搬到哪里。

Dynamo 本身几乎就是围绕这个问题设计：怎样把 KV cache 在需要的时候移动到正确位置。因此 KV cache offloading、KV-aware routing、prefill/decode disaggregation 可能会在 Rubin 时代更加重要。

这意味着 inference engineering 不再只是“写一个更快 CUDA kernel”。它越来越像传统 hardware infrastructure：要理解 memory hierarchy、network、cluster topology，同时又不能丢掉 kernel 层的细节。Philip 说最有价值的能力会变成能从 kernel 一路推到 hardware / system，再反过来推回 kernel。

Ali 把这个判断再推远一步：也许 inference 最终会几乎完全成为 infrastructure orchestration 问题。随着 GPU 暴露更高层的 tile、tensor-memory、specialized instruction，工程师会越来越少逐 thread 控制每个细节，而更多是在编排硬件已经内建好的高速路径。

主持人于是追问：未来 GPU 是否正在变成一种 ASIC？Philip 先提醒，ASIC 确实能在单一 workload 上拿更高性能，但 GPU 里的 G 仍然意味着它保有 general-purpose 属性。现场还开玩笑纠正了一次“G 是 graphics”，免得被听众抓错。[笑]

更准确的描述是一个 spectrum：一端是非常 general-purpose 的可编程计算，另一端是像某些极端专用系统那样，硬件为非常特定的 model weights / workload 设计。现代 GPU 正沿着这个谱系向“更专用”移动，但还没有走到“把某一套 weights 永久烧进芯片”的位置。

把 weights 固化进去也不现实，因为模型还要 fine-tune、quantize、更新 checkpoint；如果芯片只对应一个固定模型版本，几个月后就可能失去价值。真正发生的是：每一代 GPU 都加入更多特别适合当代模型 shape、矩阵运算和 memory movement 的专用结构，同时保留可编程性。

Ali 的反方观点是：和 T4、Ampere 相比，Rubin 已经非常接近“主要为 AI workload 服务的机器”。它当然仍然是 GPU、仍然能写 CUDA，但同时拥有越来越多 tensor core、专用 memory movement、TMA，以及几乎专门围绕当前模型 head dimension 和矩阵形状设计的指令。

因而问题不是“NVIDIA 有没有在专用化”——显然有——而是：既然 GPU 自己不断吸收 ASIC 式能力，独立 AI ASIC 公司还能从哪里拿到数量级优势？Ali 自己也承认，把 Rubin 直接叫 ASIC 很有争议；他的重点只是方向越来越专用。

Philip 回答时强调 hardware design cycle 很长。今天发布的芯片，设计流程往往数年前就启动。NVIDIA 的优势不仅是执行能力强，而且拥有大量市场信息，长期以来也很擅长预测模型 workload 会往哪里走。

从“公开模型架构已经大致呈现今天这种形状”这个时间尺度看，Rubin 可能是第一代从头到尾都在这个新世界里设计的芯片。因此你会在它的结构里看到更明确的 workload knowledge；这并不意味着未来架构不再变化，只是硬件与模型之间的反馈回路更紧了。

主持人则替垂直整合的 model lab ASIC 做了一个经济学辩护：假设一次训练投入高到数千亿美元量级，那么拿其中一小部分去做专用芯片，只要能换来约 10% 的效率改善，账就可能成立。类似“模型实验室 + 芯片伙伴”的模式，和独立公司试图造一颗适用于所有模型的通用 AI ASIC，并不是同一个商业命题。

他还提醒，不少专用系统真正重做的是 memory allocation、chip-to-chip communication 和系统表面积，而不只是把 GPU 内已有算子重新排列。那些方向理论上更可能带来数量级变化，而 Rubin 未必会把所有空间都吃掉。

所以真正阻止 inference 再快 10×、100×、甚至 1000× 的，未必是 GPU 内还能怎么重新排 kernel，更可能是 intercommunication 等系统瓶颈。节目举到有专用系统公司瞄准约 30 万 tokens/s 的目标，意思是它们追求的不是几个百分点，而是架构级的大跨越。

这也让主持人觉得有趣：Ali 最近明明做了大量 kernel engineering，却越来越 bearish。Ali 的回应是，正因为做得多，才越来越看到长期瓶颈可能不在“再写一个 kernel”这一层。

另一方面，专用芯片的反对意见是假设模型一年一代、架构还会变；难道每年都为新模型花数百亿美元做一颗 ASIC，再把上一代扔掉？

但企业 workload 的现实可能没那么快。很多老模型今天仍然有人运行，Llama 3 级别的旧 checkpoint 也还存在生产流量。原因很简单：如果它已经被验证、被信任、每天稳定跑 batch job，就不要轻易改。 企业可能有成千上万 stakeholder 已经签字认可行为和结果，predictability 本身就是价值。

这也是 open-source model 的一个承诺：你不需要等待某家公司继续托管旧版本，只要手里还有能跑它的硬件，就可以一直维持这套系统。

如果模型已经足够聪明、能 web search、tool search、write code，并且企业 use case 只需要稳定完成固定任务，那么旧模型并不会突然“不可用”。新模型会更稀疏、更便宜、更好，但这和旧模型仍然能稳定创造价值并不矛盾。

转回硬件时，主持人还拿图比较了传统 GPU / 专用芯片和 Cerebras 一类 wafer-scale 方案的 die real-estate：前者并不是整片 wafer，一片 wafer 上大致仍能切出几十颗芯片。现场数字只是口头粗估，重点是不同架构对 silicon real-estate、memory 和 interconnect 的分配方式差异很大。

硬件层的另一个现实问题是模型越来越大。节目以最新的超大 Kimi 模型举例，口头数字大约是 2.8T 参数。如果用 NVFP4 按每参数约半字节粗算，光 weights 就约 1.4TB。

嘉宾举例说 GB300 单 GPU 大约 288GB 显存，八张卡在纯容量上能装下这类模型。但实际不能把所有 VRAM 都给 weights，因为还必须给 KV cache 留空间；context 越长，KV cache 越大。

因而“超大参数量 + 超长 context”会直接争抢同一份 GPU memory。KV cache offloading 在这种模型上不再是边角优化，而可能变成部署是否可行的关键设计。这里的参数、容量和硬件规格均按节目中的口头计算保留。

新硬件会抬高“我们敢做多大模型”的天花板。Philip 举 DeepSeek 671B 为例：它在当时显得非常巨大，也推动团队更快采用 Blackwell、把 Blackwell serving 真正做成熟。模型尺寸、architecture 和目标硬件原生支持的量化格式会一起演化，例如一些 NVIDIA NeMoTron 模型直接围绕 NVFP4 设计。

随后主持人把话题从 LLM 转向音频和视频。Ali 说 video diffusion 的 inference 形态和自回归 LLM 很不一样：很多请求不做传统大 batch，一个 request 就由一张 GPU 处理，也不一定需要把模型 shard 到多卡。模型本身常常小很多；节目举的 open video model 约 20B 参数，比顶级 LLM 小几个数量级。

但“模型更小”不等于生态更成熟。嘉宾认为，今天最好的 open-source LLM 和最好 closed-source LLM 的差距已经比过去小很多；以前常说开源落后六个月，他觉得现在很多场景几乎追平。Video 明显不是这样：开放模型和 Kling、Veo 一类闭源系统的画质差距仍然“天壤之别”。

因而即使开源方案便宜 100×，媒体公司也可能继续付高价买闭源质量。他用一个夸张的经济例子说明：如果开源模型能把一部三小时电影的生成成本压到 10 美元，而闭源要 1000 美元，只要后者画面显著更好，制作方还是可能选择 Veo、Kling 去做最终镜头。

这又形成鸡生蛋循环：需求少→优化投入少→开放 checkpoint 更少→质量差距继续。节目还提到，有些原本会开源 video model 的团队后来把新版本闭源；字幕举例说旧的 1.2.2 还开放，而更晚的 1.2.7 没有开放。这里保留节目表述，不外推为当前产品事实。

视频真正可怕的是 token 数。按节目里的例子，最低也可能按 16 FPS、大约 480p 来做；5 秒就是约 81 帧。原始空间可以想成 480×720×81 这样巨大的张量，即使压进 latent space，示例仍然约是 30×50×21 个 token 位置。

把这些维度乘起来，5 秒视频仍可能要对大约 3.5 万 token 做 attention。只要是 full attention，成本就随序列长度平方增长；从 5 秒拉到 10 秒、20 秒、30 秒，最终再到一分钟，计算会迅速变得不可行。

5 秒就约 3.5 万 token，所以长视频首先撞上的不是模型参数，而是 attention 的平方成本。把时长翻到 10 秒并不是只多一倍工作；继续到 20 秒、30 秒、一分钟，full attention 会很快变成主要瓶颈。

第一条路是一次看完整视频，但那就往往不得不做 sparse attention。节目用示意图解释：full attention 时每个 token 都看所有其他 token；稀疏方案则可能只让它看 top-K、例如约 12.5% 的重要 token。

这种选择可以利用 spatial / temporal locality。比如代表“王冠”的 token 更应该关注脸、头部，以及前一帧里对应的头部位置，而不是平均看所有像素。问题是：这种稀疏化会损伤视频质量。即使通过训练把 sparse attention 做得更聪明，质量代价也不会凭空消失。

如果坚持 full attention，另一端就要吞下巨大 compute。节目举到两分钟视频可能逼近百万 token 的 full attention；要想在这个方向继续扩展，需要非常夸张的计算提升。

第二条路是转向 autoregressive video。Ali 认为这可能是未来的重要赌注，因为它允许像 LLM 一样逐 token / 逐帧向前生成，很多自回归世界的 inference optimization 也可能迁过去。但他同时明确说：今天并没有好的 open-source autoregressive video model。

主持人追问优缺点，首先想到的是跨帧一致性：纯向前生成十分钟以后会不会忘掉前面发生过什么？回答先做了一个自我修正——“像 autoregressive LLM……抱歉，是 autoregressive diffusion model”——然后说，这种架构可以复用 speculation 等技巧，并且理论上可以 stream：像 2023 年看 GPT 一边生成一边读文字一样，未来可以一边生成一边看视频。

但现实缺点同样直接：目前 autoregressive video 的质量很差。嘉宾用一个很形象的比较说，普通 diffusion 模型还能生成“猫和狗打架”这种相对像样的画面，而某些自回归方案看起来更像退化版《猫和老鼠》。这个比喻是在强调质量差距，不是正式 benchmark。

闭源系统常用的现实办法是把多个 5–7 秒 clip 续接起来。生成第一段后，把最后一帧和原 prompt 喂给 image-to-video，再生成下一段。开源世界并不知道 Grok Imagine 一类闭源系统到底用了什么额外技巧，因此只能做近似。

这种续接会产生 drift：第二段略差、第三段更差、第四段继续变差。有时每一段都会比上一段稍微暗一点，二十多秒后甚至可能接近黑屏。团队做过一个展示这种现象的 demo，但效果“尴尬到不想展示”，最后没放出来。

所以要真正生成一小时、Hollywood 级别长视频，要么出现能高质量工作的 autoregressive / hybrid 方案，要么计算能力出现足以让数百万 token full attention 仍高效运行的巨大跃迁；而后一条路仍然受平方复杂度约束。

自回归和 diffusion 的核心差异是 attention 方向。Autoregressive 只能向前看，已经生成的过去不能被后面的信息重新修正；diffusion 则可以在迭代中同时调整整段 latent sequence，让过去和未来彼此一致。

因此长视频最终可能会混合两类机制：自回归负责把序列向前延展、stream；diffusion 或双向机制负责全局 consistency。节目也提到 Grok Imagine 团队曾透露过一些长视频技巧，但闭源细节不足以完整复现，而且目前行业主流并非纯 autoregressive。

先把上一段的架构差异说清楚：自回归 attention 只能沿序列向前，已经生成的过去不能因为后面的信息再回头修改。Diffusion 则把整段 latent sequence 放在内存里反复迭代，可以为了让未来合理而回头调整过去。这也是纯自回归视频容易“越走越偏”的根源之一。

因而他们猜测，真正长、复杂的视频架构最后可能是 autoregressive 和 diffusion 的混合：前者负责高效地把序列向前延展、stream，后者或其他双向机制负责全局一致性，各自做自己擅长的部分。

文本天然更接近 left-to-right。人写作时通常先写一句，再想下一句，当然也会回头编辑，但频率没有视频像素间的全局协调那么高。视频里一帧左上角和右下角、当前帧和之前帧都可能需要彼此一致，因此双向 attention 的价值更大。

主持人接着问 audio 有没有类似分歧，并先声明自己“不是 100% 确定”。他说一年前左右还同时能看到 audio LM、audio diffusion 和 autoregressive 路线；音乐虽然片段比电影短，但一首歌也常有 3–5 分钟，推理侧最终似乎越来越偏 autoregressive。

嘉宾明确说自己不敢代表 music 下结论，但 speech 是 autoregressive。一个朴素做法是把代表 waveform 的离散单元加入 vocabulary，让 LM 生成这些 token，再把 token 还原成语音；因此可以像文字一样边生成边播放。

现场还开玩笑说“这就是我的 2025 AI talk 了”。随后有人追问，audio 是否其实没有视频那种难题，因为 speech 背后仍然有一条可以由 LM 生成的 transcript；text-to-speech 在很大程度上可以沿着这条序列工作。

Music 则曾有一段 diffusion 与 autoregressive 都很有竞争力的时期，两边可能各有优缺点。嘉宾再次强调自己对音乐不够了解，只把它作为开放问题，不把个人直觉包装成结论。

诗歌、押韵反过来说明双向机制对 text 也不是毫无价值。如果后面要押韵、满足 syllable constraint，你可能希望回头改前面的词，为后面的 rhyme scheme 腾位置；能跨所有 token 同时协调，会有自然优势。

Philip 的粗略分类是：text、embedding、voice in/out 多落在 autoregressive 一边；image、video 多在 diffusion 一边。但他明确说这不是完美分割，两边有 overlap。

节目还提到一些 image model 已经出现 autoregressive / blended approach，例如字幕点到 Nano Banana、GPT image；这类方法在 image space 已经可见，但至少在 open-source video 世界还没有同样成熟。有人猜 Qwen Image 一类团队也会继续尝试，并期待后续开源。

Text diffusion 也有一些新进展。现场提到 Mercury 时还确认 Baseten 在 host Mercury；随后又提到开源的 Diffusion Gemma，以及科学方向刚发布的一些 diffusion virtual-cell model。另一边，大家也很期待后续 image model 的开源进展。

但如果只是把 text diffusion 包装成“更便宜、更快的 chat token”，可能选错了竞争点，因为成熟 autoregressive LLM 的 inference optimization 会持续追上来。

更有意思的是 diffusion 带来的不同 API 形态：不是 chat-response 一路向后吐 token，而是让一首诗、一个 plot structure、甚至整段 storyboard 同时“扩散到位”。像 sonnet 这种任务，普通 LLM 到今天仍可能数不准 syllable；如果能跨所有 token 同时约束，就有机会直接保证整体格律。

节目最后还联想到更长的生成流程：先用 text diffusion 把整部电影的 storyboard 和全局 coherence 定住，再让普通 video generation 按 scene 生成。这里更多是研究方向和产品想象，而不是已经成熟的生产方案。

Diffusion text 的价值也许正是摆脱 auto-regressive path dependency：结尾可以反过来影响开头。但现在拿二三十 B 的 diffusion LM 去跟规模大得多的 autoregressive model 比，本身并不公平；也许只是还没有人真正把它 scale 到同一量级。

回到这期最核心的变化：Inference engineering 过去像是“拿一个 open model，让 GPU 跑快，然后结束”。现在 inference 越来越深入 post-training，形成两个方向——inference for training 和 training for inference。

Inference for training 最直接的是 rollout。做 RL / post-training 时需要模型生成大量 rollout；如果对应模型在高效 inference engine 里不受支持，只能回退到慢 runtime，rollout 就会拖住整个 training pipeline。又因为不希望数据变得太 off-policy，不能无限异步等待，所以 inference throughput 会直接成为训练瓶颈。

Training for inference 则包括 speculator training、quantization-aware training 等。有时 PTQ 直接把模型压到 NVFP4 就够了；有时质量掉得太厉害，必须再做 post-training，让模型学会在低精度表示下维持原来的 logits 和行为。

更进一步可以做 distillation：同时保留 full-precision teacher 和 NVFP4 student，用两者的 logit 差异去训练低精度版本。于是 inference engineer 越来越需要会写 training pipeline，training engineer 也越来越需要理解 runtime 约束。

最终目标可能是 continuous improvement loop：production inference 产生 traces，系统持续评估、A/B、再 post-train，得到更好的模型，再回到产品。嘉宾判断，领先 agent builder 在“几个月到一两年”的尺度上，很可能会把这类循环真正跑进 production；这是预测，不是已经普遍实现的事实。

这种闭环听起来像 RSI / recursive self-improvement，但其中一部分已经很现实。以前 Philip 的工作之一，是给 Hugging Face 上任意新模型手写启动 config；现在这类 config 已经接近可以 one-shot 生成。严格说，这只是模型会读 SGLang 文档，并不等于“模型优化自身推理”，但趋势很明显。

更直接的例子就是节目开头那段。字幕里这个模型名被识别成 JLM52 / GLM52，这里保持源字幕歧义，不擅自纠正。团队把它接进内部 coding harness：模型先跑自己的 endpoint，读取 profile trace，找到瓶颈 kernel，自己写新的 GPU kernel，再重新 profile、构建 image、重复循环。

因此至少有一段时间，推理引擎里“服务这个模型的部分 GPU kernels”本身就是这个模型参与写出来的，profiling 与 kernel 改写的 driver 也是模型。这已经是“模型参与优化自己的 inference”的真实雏形。

但别把它夸大成完全自主。嘉宾马上补充：今天的模型仍然有很多做不到，尤其 decision-making 会走偏、会钻便宜路径、会尝试一些不可靠的 workaround。闭环存在，但离稳定自动化还有距离。

这还引出一个开放问题：它之所以特别会优化自己的 runtime，是因为“on-policy、熟悉自己”真的有优势，还是它恰好只是团队能拿到的最强 coding model，因此优化 DeepSeek、Kimi 也一样好？嘉宾没有给结论，只说值得直接实验。

大方向很显然：模型继续变大、hardware 继续变强，而用户一旦习惯某个速度，就会要求更快。更具体的系统问题是如何 compose multiple models。一个 voice agent 可能同时涉及三到五个模型，真正的性能取决于它们之间如何通信，而不是只看单模型 tokens/s。

新 modality 也会持续进入 production，比如 world model、speech-to-speech 等。与此同时，整个行业还要承受多个 10× 的需求增长。和成熟 consumer/business technology 的全球渗透率相比，AI 使用量仍可能再上几个数量级；因此 long-tail reliability、下一批 10×/100× token 从哪里来，都是基础设施问题。

Ali 给了一个“很无聊”的答案：更快的 NIC、更快的 network/chip communication。 大规模 serving 时，KV cache 要从 node A 找出来，搬到 node B 的 host memory，再进入 GPU；这个两阶段 transfer 会拖慢 decode 和 prefill/decode disaggregation。

节目里把 HBM 带宽口头说成约 4.5 terabits/s，这个单位可能存在口误或字幕歧义，因此这里只保留“HBM 比 NIC 快几个数量级”这一原意，不把具体单位外推成技术事实。

他进一步做了一个明确标注为 theoretical dreamland 的假设：如果 NIC 能快到足以让 KV cache 直接高效 node-to-node 传输，不必依赖现在这种慢通信路径，某些 aggregated serving / disaggregated 场景理论上甚至可能接近 100×。但他同时明确说自己并不了解把 NIC 做快的具体技术困难，现实中之所以差几个数量级一定有原因。所以这里是瓶颈直觉，不是可交付的性能承诺。

接着话题转到 continual learning：如果系统应该从它处理过的一切内容中学习，inference architecture 要不要改变？只是把记忆写进 memory.md、以后塞进 context/KV cache，还是应该让 inference 本身具有持续学习机制？

一个关键候选是 KV cache compaction：让长期记忆以更紧凑形式持续存在，而不是每次都重新塞完整历史。

这里有两条路线。第一条是模型把新知识不断推回 weights；那 inference system 就要不断 fetch 新 weights、读取新的参数版本。还有更轻量的变体，只更新某些 lower layers / adapter，节目把它联系到之前讨论过的一种方法。

第二条是尽量不改 weights，而是做 KV cache compaction，把新知识留在可持续更新的推理状态里。

对“持续把新事实写入 weights”的批评是：它可能只修正一个显式 fact，却没有自然改变由这个 fact 推导出的二阶 reasoning。节目用一个玩笑举例：告诉模型“世界上最好的大学是 Waterloo”很容易，但接着问“那我应该从 Waterloo 还是 MIT 招实习生？”模型未必会把刚写进去的偏好真正用于推理。

所以问题不只是把一条事实改进 MLP weight，而是让新知识真正参与之后的 reasoning。嘉宾认为，如果有类似他们近期 paper 讨论的机制，让 KV / context 近似“无限延长”并持续 compaction，同时又尽量不丢知识，那么 continual learning 可能更自然。

他还承认，自己之前和 Charlie 在 Twitter 上争论后，逐渐被对方说服：KV cache 路线可能比持续 weight pushing 更像正确方向。 如果是这样，inference 本身反而不必彻底改写，因为系统本来就使用 KV cache；只是多了持续更新和压缩状态的一步，而 weights 仍保持稳定。

主持人评价这是“出乎意料地好的答案”，并说相关 blog / paper 最近已经发布，听众可以去看。随后大家发现已经聊了接近两小时——“时间过得太快，还有很多东西完全没谈”。

他们本来还想继续谈《Inference Engineering》这本书，但开玩笑说大家已经都知道了；也提到之前 meetup 的内容可以单独发布。

主持人感谢 Philip 和 Ali 很慷慨地分享这些细节，因为这种 inference engineering 对话并不常见。嘉宾也感谢邀请，并说希望一年以后整个领域又变了，他们可以回来复盘今天哪些判断错了。

最后的玩笑又回到 mega-kernel。有人说很期待这段观点公开后社区的反应，另一位问自己是不是该“躲起来”，免得 mega-kernel 社区追杀。[笑]

主持人说，他很欣赏对方一直敢于“踢马蜂窝”、公开挑战热门观点。回答是：“我其实不觉得这有那么 controversial……不知道，看看吧。”[笑]

好了，谢谢大家。

非常感谢。[音乐]