--- id: "7PSXtru6mmY" title: "推理前沿：从 10× 加速到自我优化 AI" channel: "Latent Space" host: ["swyx"] guests: ["Philip Kiely","Ali Taha"] date: "2026-08-03" updated: "2026-08-08" duration: "1:42:53" duration_seconds: 6173 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=7PSXtru6mmY" canonical: "https://pod-exp.pages.dev/7PSXtru6mmY/" transcript_jsonl: "https://pod-exp.pages.dev/7PSXtru6mmY/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["人工智能","AI 基础设施","半导体","AI 研究"] series: ["AI 基础设施","Baseten"] --- # 推理前沿：从 10× 加速到自我优化 AI > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** 这期从一个 20 万 token 请求进入推理系统后发生什么讲起，拆开 cache-aware routing、prefill/decode disaggregation、speculative decoding、量化、模型并行与 KV cache 移动等生产细节。Philip Kiely 与 Ali Taha 反复强调，所谓“10× 更快”必须带上硬件与 baseline 条件；同硬件下更常见的提升约为 2–4×。后半段把视野扩展到 Rubin、ASIC、视频 diffusion 与自回归生成，并落到训练与推理逐渐合流：模型已经开始参与分析 profile、改写 GPU kernel，而 continual learning 可能更多依赖持续的 KV 状态与 compaction，而不是不断重写 weights。 ## [0:02] 引言与 20 万 Token 的长提示词 · YouTube **说话人：** 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。 ## [3:19] 专用部署、推测解码与工具调用 · YouTube **说话人：** 在某些模型上，我们已经把 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，还是还有更复杂的东西？ ## [7:21] 工具调用的训练敏感性、结构化输出与 JSON · YouTube **说话人：** 有些客户用的是自己 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 的价值可能本来就没那么高。当然，也可能我判断错了。 ## [11:23] 一个被切开的过渡句 · YouTube **说话人：** ……所以我会预期，tool-call 这一步本身很快，流式输出未必像想象中那么重要；不过这个判断也可能是错的。 ## [11:26] 新模型从“能跑”到“可生产”的工程工作 · YouTube **说话人：** 工具调用的格式最终还是受它要接入的软件约束。如果客户的软件和工具接口就是 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。 ## [15:28] Speculator、架构适配与给 GLM“接上眼睛” · YouTube **说话人：** 今天训练 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 很基础的思路。 ## [19:06] 模型 Retrofit、真实流量故障与持续修补 · YouTube **说话人：** 这个实验本身更偏 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 做这个检测。 ## [23:06] 非确定性：软件、Kernel、硬件集群都可能是根因 · YouTube **说话人：** 主持人先追问：如果模型真的需要连续输出重复 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，所以理论上也不会改变最终输出分布。真正需要格外小心的是量化等会直接改变数值表示的优化。 ## [27:08] 质量的定义：量化、长上下文与对原模型的忠实度 · YouTube **说话人：** 真正主要的 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。 ## [28:22] 量化不只是“越少越好”：误差可以相互抵消 · YouTube **说话人：** 当然，从 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 会相互抵消。 ## [32:15] 推理速度竞赛：从两位数百分比到数倍提升 · YouTube **说话人：** 承接前一块，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。 ## [36:15] “10×”要带条件：同硬件通常更像 2–4× · YouTube **说话人：** 设想一个一万亿参数左右的模型，在比较普通、没有多少优化的 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×。 ## [40:18] 叠加优化的账：量化、Speculator、Disaggregation、Runtime · YouTube **说话人：** 在硬件和流量都足够、能够把 prefill/decode disaggregation 吃满时，disaggregation 还可能再贡献大约一个 2×。最后再叠上新版 runtime、更新的 kernels 等带来的两位数百分比增益，差不多就是这套加速栈如何一步步累积起来的。 ## [40:49] Dynamo、推测解码谱系与工程实现成本 · YouTube **说话人：** 对真正熟悉这套东西的人，从零做一份合格的 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 仍然很常用，但它后面也已经有新方法。 ## [44:51] Speculator 也可以被 Speculate，但递归并非免费 · YouTube **说话人：** 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 在这些方向积累了很多值得数据中心推理借鉴的经验。 ## [48:52] 本地 AI 的优化不能原样搬到 B200 · YouTube **说话人：** 本地 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。 ## [50:19] Tensor、Expert 与 Pipeline Parallelism · YouTube **说话人：** 接上本地 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。 ## [54:19] 多节点、自动调参，以及对 Mega-kernel 的保留态度 · YouTube **说话人：** 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 之外。 ## [58:19] Mega-kernel 的理论美感与生产现实 · YouTube **说话人：** 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 的经验背景。 ## [1:00:56] Rubin：推理从 CUDA Kernel 问题变成系统基础设施问题 · YouTube **说话人：** 从 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 的专用结构，同时保留可编程性。 ## [1:04:57] GPU 更专用，为什么专用 AI ASIC 仍可能成立 · YouTube **说话人：** 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”这一层。 ## [1:08:58] 模型的寿命可能比硬件论战假设得更长 · YouTube **说话人：** 另一方面，专用芯片的反对意见是假设模型一年一代、架构还会变；难道每年都为新模型花数百亿美元做一颗 ASIC，再把上一代扔掉？ **说话人：** 但企业 workload 的现实可能没那么快。很多老模型今天仍然有人运行，Llama 3 级别的旧 checkpoint 也还存在生产流量。原因很简单：**如果它已经被验证、被信任、每天稳定跑 batch job，就不要轻易改。** 企业可能有成千上万 stakeholder 已经签字认可行为和结果，predictability 本身就是价值。 **说话人：** 这也是 open-source model 的一个承诺：你不需要等待某家公司继续托管旧版本，只要手里还有能跑它的硬件，就可以一直维持这套系统。 ## [1:10:04] 巨型模型首先撞到的是显存容量与 KV Cache · YouTube **说话人：** 如果模型已经足够聪明、能 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 在这种模型上不再是边角优化，而可能变成部署是否可行的关键设计。这里的参数、容量和硬件规格均按节目中的口头计算保留。 ## [1:12:43] 视频模型：模型更小，但 Attention 的 Token 数巨大 · YouTube **说话人：** 新硬件会抬高“我们敢做多大模型”的天花板。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 秒，最终再到一分钟，计算会迅速变得不可行。 ## [1:16:47] Full Attention、Sparse Attention 与自回归视频的两难 · YouTube **说话人：** 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 仍高效运行的巨大跃迁；而后一条路仍然受平方复杂度约束。 ## [1:20:48] 为什么视频 Diffusion 能“回头改过去” · YouTube **说话人：** 自回归和 diffusion 的核心差异是 attention 方向。Autoregressive 只能向前看，已经生成的过去不能被后面的信息重新修正；diffusion 则可以在迭代中同时调整整段 latent sequence，让过去和未来彼此一致。 **说话人：** 因此长视频最终可能会混合两类机制：自回归负责把序列向前延展、stream；diffusion 或双向机制负责全局 consistency。节目也提到 Grok Imagine 团队曾透露过一些长视频技巧，但闭源细节不足以完整复现，而且目前行业主流并非纯 autoregressive。 ## [1:21:47] 音频、图像：哪些模态天然更适合自回归 · YouTube **说话人：** 先把上一段的架构差异说清楚：自回归 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 一类团队也会继续尝试，并期待后续开源。 ## [1:25:48] Text Diffusion：真正的价值也许不是“更快聊天” · YouTube **说话人：** 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 生成。这里更多是研究方向和产品想象，而不是已经成熟的生产方案。 ## [1:27:34] Training for Inference 与 Inference for Training 正在合流 · YouTube **说话人：** 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；这是预测，不是已经普遍实现的事实。 ## [1:31:35] 模型开始优化自己的 Inference · YouTube **说话人：** 这种闭环听起来像 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 也一样好？嘉宾没有给结论，只说值得直接实验。 ## [1:35:39] 下一波趋势：多模型系统、更多模态、以及更快的网络 · YouTube **说话人：** 大方向很显然：模型继续变大、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：让长期记忆以更紧凑形式持续存在，而不是每次都重新塞完整历史。 ## [1:39:39] Continual Learning 的两条路：更新 Weights，或更新 KV 状态 · YouTube **说话人：** 这里有两条路线。第一条是模型把新知识不断推回 weights；那 inference system 就要不断 fetch 新 weights、读取新的参数版本。还有更轻量的变体，只更新某些 lower layers / adapter，节目把它联系到之前讨论过的一种方法。 **说话人：** 第二条是尽量不改 weights，而是做 KV cache compaction，把新知识留在可持续更新的推理状态里。 **说话人：** 对“持续把新事实写入 weights”的批评是：它可能只修正一个显式 fact，却没有自然改变由这个 fact 推导出的二阶 reasoning。节目用一个玩笑举例：告诉模型“世界上最好的大学是 Waterloo”很容易，但接着问“那我应该从 Waterloo 还是 MIT 招实习生？”模型未必会把刚写进去的偏好真正用于推理。 ## [1:40:06] KV Cache Compaction、长期记忆与收尾 · YouTube **说话人：** 所以问题不只是把一条事实改进 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……不知道，看看吧。”[笑] **说话人：** 好了，谢谢大家。 **说话人：** 非常感谢。[音乐]