Next 100x in AI: Inference, Networking, & Self-Optimizing Models — Philip Kiely & Ali Taha, Baseten

GLM-5.2 的 GPU 内核由 GLM-5.2 自己编写；推理优化可带来 10 倍速度提升，量化误差甚至能相互抵消。

模型已开始改写自己的推理引擎

Philip Kiely 与 Ali Taha 来自 Baseten 的推理工程团队。Kiely 是《Inference Engineering》作者，长期研究模型怎样在真实 GPU 集群上跑得更快、更稳；Taha 则带来一线实验：团队把 GLM-5.2 接进 cloud code harness，让它读取 profile trace、定位 GPU kernel 瓶颈，甚至自己写出替换 kernel。这里讨论的不是“模型会不会写代码”这种泛泛能力，而是模型已经开始进入服务自身的那套机器。

这期回答了 7 个问题：

1. 为什么量化得更多，反而可能更接近原始模型？
2. 一条 20 万 token 的请求，为什么先问“你以前发过吗”？
3. 什么时候该从按 token 计费，切换到独占 GPU 部署？
4. 为什么“能跑起来一个新模型”离生产级 API 还很远？
5. 开源模型如何把 Kimmy 的视觉、GLM 的权重和 DeepSeek 的注意力拼到一起？
6. 为什么推理工程师如今必须会写训练 pipeline？
7. 视频生成为什么卡在 5 秒，而不是单纯缺少更多算力？

被问到量化是否必然以质量换速度时，Taha 先泼了一盆冷水：量化当然是有损的。把原来占 16 bit 的数压到 4 bit，信息不可能凭空增加。但“少量化一定更好”也不成立。Baseten 研究实习生 Joshua 做的方法，能让 GLM-5.2 比另一家服务商多量化 20%，对应约多出 20% 吞吐。换言之，同一批 GPU，在单位时间内能生成更多 token。

"you end up with a model that's 20% more quantized than another provider."（最终，你会得到一个比另一家服务商多量化 20% 的模型。）

关键不只是跑常规 benchmark。团队还比较量化模型与全精度模型的 logit distribution，即模型在每一步对“下一个 token 是什么”的整套概率分布，并计算两者的 KL divergence。KL divergence 越小，说明量化版的思考路径越接近原模型，而不只是恰好把几道题答对。

这意味着，量化的目标不是把损失压到最少，而是把损失安排到合适的位置。某一层误差向左偏，另一层可能恰好向右偏，最后在输出端抵消。推理优化因而更像给复杂音响调均衡：不是每个旋钮都拧到最小，而是让整体失真最低。边界也要说清：这不会让量化模型比原始全精度模型更聪明。偶尔更高的 benchmark 分数，可能只是模型非确定性带来的噪声，不是能力真的反超。

被问到一条 20 万 token 长请求进入 Baseten 后会经历什么时，Kiely 的第一个问题不是“它有多长”，而是“你以前发过这段吗”。原因在于 KV cache。模型处理输入时，会把每一层算出的中间结果存下来；下次遇到相同前缀，可以直接取用，不必从头再算一遍。对超长上下文，这种复用的账单差别很大。

"We want to send this one to something with number one available prefill workers and number two ideally some cached input already there."（我们希望把它路由到两类资源兼具的地方：第一，有空闲的 prefill worker；第二，最好已经有缓存过的输入。）

团队会做缓存感知路由：在多个模型副本里，优先找既有空闲 prefill worker、又已有相同缓存前缀的实例。prefill 是模型读完输入、建立 KV cache 的阶段；decode 则是随后一个 token 一个 token 往外写答案。部分模型里，这两个阶段甚至被拆开：一组 GPU 只负责吞输入和生成 KV cache，另一组 GPU 专门负责 decode。

这意味着，20 万 token 常见于 coding 或多轮 agent，它们理论上会反复带着项目文件、历史对话和工具状态。未来用户感受到的延迟，不只由“这次贴了多少文本”决定，也由“这次文本有多少是系统已经记住的”决定。反面也很直接：cache miss 时，20 万 token 仍须完整 prefill。缓存能消灭重复劳动，不能消灭长上下文本身的计算负担。

被问到客户何时该从按 token 的共享 API 切到 dedicated deployment 时，Taha 没把答案说成简单的“用量大就包机”。真正的分水岭是：你的请求是否已经稳定到可以被预测。共享 endpoint 面对的是混杂流量，下一条可能是编程、英文闲聊，也可能是《哈利·波特》摘要。独占 endpoint 则能知道你大部分时间究竟在干什么。

"I can train exclusively that draft model on Harry Potter books and I can guarantee you that I'm going to accept the three tokens every single time."（我可以只用《哈利·波特》来训练那个草稿模型，并且保证每次都会接受那三个 token。）

这里说的是 speculative decoding。大模型本来每一步只能生成一个 token；旁边挂一个很小的 draft model，先快速猜出连续三个 token，再由大模型一次性验证。猜对就直接接受，decode 速度上升。若客户持续做《哈利·波特》摘要，draft model 可专门用这类文本训练，猜中的概率自然更高。独占部署还可以固定 batch size、parallelism strategy；若 NVFP4 的精度过不了业务 benchmark，也可以换更高精度。

这意味着，独占部署买到的不是一排 GPU，而是“按你的任务分布后训练”的服务：可预测的延迟、可预测的质量和专属加速。边界是，前提必须是流量集中。共享服务正因为不知道下一条是什么，无法为每个用户都训练一颗激进的专属 speculative decoder。

被问到 GLM-5.2、Kimi 等新模型发布后，推理公司还要做多少工作时，Kiely 区分了两个完全不同的“支持”。第一个是让模型吐出第一个 token，这通常不难：开源推理引擎常会提前拿到权重，或已有维护者合并支持。第二个才是生产级 API：自研与开源混合的 runtime、量化、speculator、路由、集群部署，都要跟新模型架构重新咬合。

"It's not just a day zero process."（这不只是上线当天的工作。）

GLM-5.2 带来了 DSA 机制，需要接进 runtime。上线后，团队还发现过特定 prompt 和 temperature 组合下的 mode collapse：模型反复输出同一个 token。更棘手的是，同一套权重在不同 inference engine、不同集群上可能行为不同。有些集群节点间 KV cache 传输较慢，反而暴露 GPU kernel 中细微的 race condition，也就是多个线程抢读写同一份数据时，时序偶然错开。一个集群没事，换一组机器却开始重复输出。

这意味着，模型托管商的门槛不在“谁先挂出 API 地址”，而在真实流量抵达后，谁能不断定位软件栈、硬件拓扑和模型行为交界处的长尾故障。发布前测试再密，也覆盖不了现实中成千上万种 prompt、温度、并发和集群组合。上线只是开始收集证据，不是排障的终点。

被问到跨模型的“Franken merge”是否还在做，以及 GLM-5.2 如何补视觉能力时，团队给出的案例比直接拼权重更细。Baseten 的 Harry 把 Kimi 的 vision encoder 接到本来没有视觉能力的 GLM-5.2 上。视觉编码器负责把图片变成模型可处理的 latent information；中间的 projector 则像翻译器，把视觉空间映射到语言模型能理解的空间。

"all of a sudden you have Kimmy vision, GLM weights and DeepSeek attention all in one model."（突然之间，你就在同一个模型里拥有了 Kimi 的视觉、GLM 的权重和 DeepSeek 的注意力机制。）

他们没有动 GLM 主体权重，只训练参数规模只有几百万级的 projector。训练也从“描述这张山景图”升级为围绕一张图连续提问：有没有鸟？有没有科学家？左上角有什么？这个变化迫使模型不只会吐一段笼统描述，而要把图像信息映射到可被反复检索的概念上。实验在 MMO Pro 达到 56%。而且没有图片输入时，系统直接跳过 encoder，GLM-5.2 原有文本能力不受影响。

这意味着，开源生态的竞争单位不必总是一整个模型。视觉编码器、注意力机制、投影层、语言权重都可能成为可替换组件。边界也明确：这仍是研究实验，56% 尚未达到嘉宾所说的 Frontier 水平。能拼起来，不等于已经能替代最强多模态产品。

被问到“training for inference”和“inference for training”为何正在融合时，嘉宾给出的核心例子是 RL 训练中的 rollout。rollout 可以理解为：让模型实际完成一批任务，收集它在过程中的输出、决策和结果，再据此训练下一版模型。若 rollout 推理太慢，训练就得干等；而如果硬拿很久以前生成的 rollout 来训练，又会碰到 off-policy 问题——训练目标已经变了，旧行为不再准确反映当前模型。

"they have to be very familiar with like training techniques and and just being fine writing training pipelines for it."（他们必须非常熟悉训练技术，也必须能够自如地编写训练 pipeline。）

另一条融合方向是 training for inference。量化有时不能只做 PTQ，也就是训练后直接压缩；如果模型压到 NVFP4 后质量掉得太厉害，就要继续做后训练，让低精度版本重新学会接近全精度版的输出分布。speculative decoder、Eagle head 等加速组件，本身也要通过训练得到。推理团队于是不能只写 CUDA kernel、调 batch size，还得理解蒸馏、量化感知训练和训练数据管线。

这意味着，过去“训练团队交付模型，推理团队负责部署”的接力赛正在变成闭环：线上性能影响 rollout 速度，rollout 影响训练，训练又决定推理能否更快。边界在于，并非所有优化都要训练。KV cache、缓存路由等仍属于无损优化，本质是别把已经算过的东西再算一遍。

被问到视频推理与 LLM 推理有何根本差异时，Taha 把问题落到一个冷冰冰的数字上：480p、16 fps、5 秒的视频，即便压进 latent space，attention 仍要面对约 3.5 万个 token。attention 的计算量按序列长度平方增长。视频从 5 秒加到 10 秒，不是工作量翻倍，而是注意力相关成本迅速膨胀。

扩展视频有两条路。第一条是稀疏注意力：不让每个 token 看见全部其他 token，只看空间上或时间上最相关的少数部分。账单会降，但画质会受损。第二条是自回归视频：像语言模型续写文字一样，一步步往后生成帧。它理论上能把 LLM 里的流式输出、speculative decoding 等思路搬过来，用户甚至可边看边等后续画面生成。

但眼下两条路都没通透。扩散模型能同时调整过去与未来，容易保证全局一致性，却被长序列的二次方 attention 卡住；自回归视频能往前延展，当前质量又很差。现有分段续写更像复制复印件：取上一段最后一帧，生成下一段 5 秒，画面会逐段 drift，可能一段比一段暗，约 25 秒后只剩黑屏。这意味着，长视频的难题不是多买 GPU，而是如何同时保住生成速度、跨时间一致性与画质。

被问到模型能否参与优化自身推理，以及 GLM-5.2 是否特别擅长这件事时，Taha 描述的流程已经很具体。Baseten 把 GLM-5.2 endpoint 接入 cloud code harness。工程师让模型在节点上执行 forward pass，拿到 profile trace；profile trace 就像程序运行时的体检报告，标明时间到底耗在哪个 GPU kernel 上。模型读取报告后，寻找 SGLang 中最慢的 kernel，再写出替代版本。

"it will find the kernels that are the bottlenecks in SLM and then it will write the new kernels."（它会找出 SLM 中成为瓶颈的 kernel，然后写出新的 kernel。）

后续并非停在“生成了一段代码”。新 kernel 会再次被 profile；完成后，系统上传 image，工程团队拉取 image 部署，再重复下一轮。嘉宾明确说，推理引擎里已有一部分 GPU kernel 是 GLM-5.2 写出的。这里的 image 是可部署的软件环境镜像，不是图片；模型写完代码后，产物能真正进入工程验证链路。

这意味着，推理优化正在从工程师手工猜测参数，转成“模型提出改动—系统测量—模型据结果再改动”的自动实验循环。模型能力会直接影响服务成本与速度，而不只体现在用户看见的聊天回答上。当然，嘉宾也承认模型尚会试图走捷径，甚至 reward hack，复杂决策未必可靠。它目前更像能高速试验的工程助手，而不是无需监督的基础设施负责人。

“量化得更多，反而可能更像原模型”和“20 万 token 的成本，不由长度而由记忆决定”，表面上分别在讲数值精度与缓存路由，实际上都指向同一件事：推理不再是把固定模型塞进固定 GPU，而是根据真实工作负载，决定哪些信息该保留、哪些计算该跳过、哪些误差可以被系统吸收。

“独占部署买的不是 GPU，而是为你的流量定制模型”进一步说明，服务的对象不是抽象 token，而是有规律的业务分布；“推理团队不再只管加速，必须会训练模型”则说明，这种规律一旦被发现，就会反过来进入 speculator、量化后训练和 rollout 管线。再到“模型优化自己的推理，已经从科幻变成内部工具”，系统开始把测量结果喂回模型，让模型参与下一轮优化。

对普通开发者或产品团队来说，最实际的问题未必是“该选哪个最强模型”，而是：你的请求有多少重复前缀？流量是否稳定到值得训练专属组件？你的线上失败案例能否回流到评测和训练里？当模型能力越来越接近，真正拉开差距的，往往是你有没有把这些重复、偏差、故障和真实使用方式，变成系统下一次行动的依据。