Baseten工程师揭秘AI推理层的真实战场

这期节目来自AI工程播客Latent Space，主持人swyx与Baseten的Philip Kiely和Ali Taha展开了一场深度对话。Philip此前曾与swyx合作出版《Inference Engineering》一书，Ali则是来自滑铁卢大学的实习工程师。两人从一个200,000 token的请求进入推理系统的那一刻开始，拆解了现代AI推理层的每一个关键环节。

Baseten是一家专注于模型推理基础设施的公司，为企业提供从共享API到专属部署的全套推理服务。Philip和Ali所描述的推理工程，早已不是"把模型跑起来"这么简单——它是一套涉及GPU调度、缓存路由、量化策略、投机解码的复杂系统工程。而这套系统正在经历一场静悄悄的革命：推理优化仍然能带来20%、100%甚至200%的性能提升，最优化的服务方案可以让同一个模型快10倍。

1. 一个200,000 token的请求，进入系统后发生了什么

"你之前发过这个请求吗？哪怕是一部分？"——这是Philip收到超长请求时脑子里冒出的第一个问题。

缓存感知路由（cache-aware routing）是处理长上下文请求的第一道关卡。系统会在多个模型副本中寻找两个条件同时满足的节点：一是有空闲的预填充（prefill）算力，二是已经缓存了部分输入的KV cache。如果命中缓存，200,000 token的请求就可以跳过大量重复计算，既省时间又省钱。

如果没有缓存，请求会被送往专门的预填充节点。Baseten在部分模型上已经实现了预填充与解码（decode）的分离部署：一组GPU专门处理输入、生成KV cache并产出第一个token，另一组GPU接手后续的逐token生成。这种"分离式推理"（disaggregated prefill and decode）让两个阶段各自用最适合的并行策略，不再互相拖累。

解码阶段前面通常还挂着一个投机解码（speculative decoding）模型。这个小模型会快速猜测接下来的三个token，然后让大模型一次性验证——如果猜对了，就相当于一次前向传播完成了三步解码。Ali打了个比方：这个小模型像是寄生在大模型上的"寄生层"，专门负责快速草稿。

2. 什么时候该从共享API切换到专属部署

"如果你每小时推几百万token，按小时付费比按token付费便宜得多。"

Philip指出，从共享API迁移到专属部署通常有两个触发点：一是可靠性，二是定制化需求。共享端点意味着你的流量和别人的基准测试流量混在一起——当别人在跑大批量评测时，你的用户请求可能就在排队。

专属部署能做的事情远不止隔离流量。你可以为自己的流量训练专属的投机解码草稿模型——Ali举例说，如果你的用例全是哈利·波特相关的摘要任务，就可以专门在哈利·波特语料上训练草稿模型，token接受率接近100%，解码速度大幅提升。共享端点做不到这一点，因为它不知道你的请求是哈利·波特还是代码补全。

此外，专属部署还允许自定义批处理大小、并行策略、量化精度——如果NV FP4量化没通过你的基准测试，你可以选择更高精度运行，而不是将就。

3. 工具调用：真正的挑战不在沙箱

大多数人以为工具调用的难点是安全隔离，但Ali指向了另一个方向。

"LLM实际上什么都做不了，它只能建议做什么。"这是Philip对工具调用本质的概括。模型输出的是格式化建议，由外部系统决定是否执行。MCP（Model Context Protocol）也不例外，本质上只是另一种工具调用形式。

真正的挑战在于训练质量与推理精度的交叉地带。一些企业客户有高度定制化的工具调用需求，需要对模型进行后训练（post-training）。如果后训练质量不佳，或者后训练之后的量化破坏了模型对JSON格式的理解，模型就会在工具调用的思考阶段产生幻觉——它没有看到工具返回的结果，却直接编造了一个结果继续解码。

推理侧的应对方案是结构化输出（structured outputs）：用状态机约束模型的输出格式，保证JSON的括号一定闭合、格式一定合法。Philip提到Baseten大约两年前就发布了这套方案。这解决的是输出结构问题，但不解决"调用了错误的工具"或"根本没调用工具"的问题——那是训练侧的责任。

4. JSON的流式解析困境，以及它为何还没被取代

"我一直以为会有什么东西来替代JSON，"Philip说，"因为JSON很难流式解析——你必须等到括号完全闭合才能验证。"

JSON的流式解析问题由来已久。早期的解决方案是BNF语法（Backus-Naur Form）约束——OpenAI曾经推出过让用户自己写BNF语法来约束输出格式的功能。Baseten的推理系统则内置了指定输出格式的能力，在推理层直接保证输出符合预定结构。

在智能体循环（agent loop）中，这个问题有时会被推理能力本身绕过：如果输出格式不对，模型可以在推理过程中意识到"我不知道该怎么做，让我再试一次"，通过多次尝试最终得到正确结果。但这依赖于模型足够大、推理能力足够强——在小模型上，同样的策略效果会差很多。

5. GLM-5.2用自己写的GPU内核服务自己

对话开头提到的一个细节，是整期节目最令人印象深刻的片段。

Baseten将Kimi的视觉编码器嫁接到了GLM-5.2（JLM52）上，在不改变底层语言模型权重的情况下，为其增加了视觉理解能力。这种"架构移植"（retrofitting）代表了一种新的模型工程思路：不从头训练多模态模型，而是把不同架构的组件拼接起来。

更有意思的是GLM-5.2参与自身推理优化的方式。Ali描述了一个完整的自优化循环：GLM-5.2端点被接入工程师的开发环境，对自身运行的GLM-5.2实例做前向传播，获取性能剖析（profile trace），找出推理引擎中的瓶颈内核，然后编写新的GPU内核，再做一次剖析验证，上传镜像，拉取并重复循环。"我们在GLM-5.2推理引擎里跑的部分GPU内核，就是GLM-5.2自己写的。"

这不是一个概念演示，而是Baseten内部工程师日常使用的工作流。它指向了一个更大的趋势：训练与推理的边界正在模糊，模型开始参与优化运行自身的基础设施。

推理工程正在成为AI栈中最被低估的一层。从缓存感知路由到分离式预填充解码，从投机解码到结构化输出，每一个环节都有20%到200%的优化空间等待挖掘。而当模型开始为自己编写GPU内核，这个领域的边界就变得更加模糊——它不再只是"让模型跑起来"，而是让模型参与定义自己如何运行。