86
Through interviews with San Francisco AI engineers, the article clarifies the critical role of inference systems in deploying large models, emphasizing that factors such as caching, prefilling/decoding, and cost control determine whether models can be reliably delivered. 
Today 3586 words (about 15 min) View Source →
Sign in to highlight text and take notes as you read. Sign in now
原创 姜篇 2026-08-11 17:30 北京
推理工程才是AI真正的战场！旧金山AI工程师：开发者别卷Prompt了，模型决定会不会做，推理系统决定能不能交付
编辑 | 姜篇
> “I can make a token out of this model.” > > > “I have a production-ready API from this model.” > > > Philip Kiely：让模型吐出一个Token，和把它做成可以稳定调用的生产API，是两回事。
模型已经训练完，并不代表用户就能顺畅使用。
请求怎么排队，20万Token怎样送进GPU，缓存能不能命中，机器出了故障如何切换，都会影响模型的速度、稳定性和账单。
把这些问题处理好，就是推理工程。
近日Philip Kiely和Ali Taha，用近两个小时拆解大模型背后的推理系统。
备注：Philip Kiely _是 AI 推理基础设施公司 Baseten 的 AI 教育负责人、软件开发者。他于 2022 年加入 Baseten，曾在 NVIDIA GTC、PyTorch Conference 等大会分享推理工程。_
_Ali Taha就读于滑铁卢大学计算机工程专业，访谈录制时在Baseten实习。主要分享推理引擎、GPU硬件和模型性能优化的工程案例。_
这场访谈回答了不少开发者每天都能碰到的问题：为什么同一个模型换个平台就变慢了，为什么上下文越长等待越久，为什么模型没有变，服务成本却能相差数倍。
以下为访谈内容，我们进行了翻译与整理。
_Philip 给“10 倍提速”加上适用范围_
能吐出 Token，离生产 API 还有多远
Philip 提到，GLM-5.2 发布时，Baseten 很快就让模型跑出了第一个 Token。
但“模型能运行”和“外部开发者可以稳定调用”，中间还隔着不少工作。
_Philip 谈“能吐出 Token”和“生产可用 API”的差别_
一个生产 API 要同时处理不同长度的请求，遇到流量突增时不能排队太久，节点故障后要能切走，更新推理引擎也不能让已有应用突然失灵。
模型还可能需要量化、校准和专门的加速方案，做完以后再重新检查输出质量。
不少 AI 项目从 Demo 走向上线，第一次就卡在这里。
本地测试只有一个人，提示词也很短。正式开放以后，长请求和短请求混在同一条队列里，GPU 利用率忽高忽低，P95 延迟一路上涨。
这里的 P95，指 95%的请求能够在多长时间内完成。平均速度看起来还行，排在后面的那批用户已经等得不耐烦了。
因此，开发者评估一个模型服务时，至少要带上真实的请求长度、并发量和输出长度。只用一句“你好”测出的首 Token 速度，说明不了它能不能扛住 Agent 连续工作半小时。
20 万 Token 进来，系统先找“看过它”的 GPU
> 主持人给Philip出了一道题：把20万Token发进Baseten，后台会怎么处理？ > > > Philip先追问了一句：“这段内容之前发过吗，或者其中一部分发过吗？”
Coding Agent 连续修改同一个仓库时，系统提示、项目说明和大量代码会反复出现。
如果每一轮都从头读取，时间和算力都浪费在重复内容上。Baseten 会先做缓存感知路由，把新请求交给已经保存过相同前缀的节点。
_Philip 解释缓存感知路由_
接下来，输入处理和文字生成还可以交给两组 GPU。前一组负责“读完”20 万 Token 并生成第一个 Token，后一组继续往下生成。用推理工程里的说法，前一步叫 Prefill，后一步叫 Decode。
落到应用代码里，开发者也有能立刻做的事。系统提示、仓库摘要和工具说明尽量保持稳定，把每次都变化的时间戳、随机 ID 放到后面，缓存才更容易命中。Agent 每轮都重新拼出一份结构完全不同的提示词，服务端再聪明，也很难复用前一次计算。
长上下文并非只有“模型能不能装下”一个问题。相同的 20 万 Token，缓存是否命中、由哪个节点处理、Prefill 和 Decode 怎么分工，都会改变用户等到第一行答案的时间。
同一份权重，换个集群就可能换一种结果
Ali 讲了一次排障经历。某个客户发现模型会陷入重复生成，他们拿到完全相同的权重和代码，却怎么都复现不出来。
换掉推理引擎以后，问题消失了。再往下查，他们怀疑某个集群较慢的互联网络暴露了竞态条件。模型权重没有变化，运行它的软件和硬件环境变了，故障就只在部分机器上出现。
_Ali 提醒团队先检查推理系统_
> Ali：“It’s an inference problem.” > > > 翻译过来就是：先查推理系统，别急着认定模型坏了。
这类问题对使用自部署模型的团队尤其麻烦。
只记录模型名称和权重版本还不够，推理引擎版本、量化方式、GPU 型号、容器镜像和所在集群也要跟着请求留下来。否则线上偶发一次重复输出，日志里只有一句“模型回答异常”，研发很难把现场还原出来。
升级 vLLM、SGLang 或 TensorRT-LLM 时，也应该像升级数据库一样做灰度。先让少量流量进入新版本，比较延迟、错误率和一组固定任务的结果，再逐步扩大。模型相同，不代表运行结果天然相同。
同一个模型，速度能差 4 到 10 倍
> Philip：现在一次推理优化带来的提升，经常还有20%、100%，甚至200%。把缓存、量化、推测解码和并行策略叠在一起，同一个模型在不同服务商手里会拉开数倍差距。
Philip 也给这个数字加上了适用范围：10 倍需要更好的硬件、量化、推测解码、较高的缓存命中率，以及偏向低延迟的并行配置。实际比较不同服务商时，更常见的是 4 到 6 倍的差距。
开发者不必先学会写 CUDA，至少要把“快”拆开看。
代码助手最怕第一行迟迟不出现，应该重点看首 Token 延迟；语音助手要边说边出字，更关心生成过程是否流畅；离线处理一批文档，用户不盯着屏幕，吞吐量就比单个请求的速度更重要。
只看每秒生成多少 Token，很容易选错服务。一个接口生成得快，却在排队阶段等了两秒，放进 IDE 后仍然显得迟钝。另一个接口首 Token 很快，但并发一上来就掉速，也扛不住团队里的 Agent 同时跑任务。
模型榜单回答“它会不会做”。推理压测回答“它能不能在你的流量里按时做完”。上线前，两张表都得看。
调用量一上来，推理成本就成了产品问题
访谈中谈到一个很实际的选择：继续按 Token 调用公共 API，还是租下一组专用 GPU。
> Ali：当调用量达到每小时数百万Token，按时租用算力往往比按Token付费便宜。专用部署还可以针对自己的请求训练推测解码模型，稳定性和可控性也更高。
_Ali 谈高调用量下的计费方式_
专用 GPU 并不天然省钱。白天请求很多、夜里几乎空闲，机器照样按小时计费。团队需要先看真实流量：一天有几个高峰，GPU 平均利用率多少，请求能否批量处理，缓存命中率是否稳定。
Agent 应用还要换一个记账口径。一次任务可能先读仓库，随后调用搜索和终端，失败后再重试两次。便宜的单 Token 价格，未必能带来更低的任务成本。更实用的数字是：完成一次代码审查、修复一个 Bug 或生成一份报告，总共花了多少钱，其中有多少消耗在失败和重复调用上。
这项数据能反过来影响产品设计。任务拆得太碎，模型往返次数会变多；上下文每轮重新发送，Prefill 成本会上涨；验收条件不清，Agent 会反复试错。降低推理成本，最后仍要回到工作流本身。
模型开始给自己的推理系统写内核
访谈后半段，Ali 讲了一个更特别的案例。
Baseten 把 GLM-5.2 接进团队的编码 Agent 工作流。模型先运行一次，读取性能轨迹，找出拖慢速度的 GPU 内核，再写出新的内核并重新测试。循环跑完后，工程师检查结果，继续下一轮。
_Ali 谈模型自优化推理系统_
Ali 把它概括为：“The model optimizing its inference.”
也就是让模型参与优化承载它自己的推理系统。
这套流程还不能无人值守。Ali 坦言，模型在决策上仍会犯错。哪些内核值得改，提速有没有损伤精度，新版本能否进入生产环境，都要由工程师判断。
它已经给出了一条很具体的工作路径：把性能轨迹、压测结果和失败日志交给 Agent，让它寻找瓶颈、提出修改、重新运行测试。过去 Agent 主要读取业务代码，接下来它还会进入编译、内核和部署层。
写在最后：模型选完，工程才刚开始
模型名字相同，用户拿到的体验可以完全不同。
20 万 Token 能不能迅速读完，取决于缓存和路由；偶发重复输出，问题可能藏在推理引擎或集群互联里；同一份权重跑得快不快，还要看量化、推测解码和并行方式如何组合。
开发团队准备上线 AI 功能时，可以先补四项记录：真实流量下的首 Token 延迟和吞吐量、每次请求对应的运行环境、固定任务的回归测试，以及每个完成任务的总成本。
模型更新以后，再用同一批请求跑一遍。推理引擎、GPU 或量化方案更新，也做同样的检查。
模型负责生成答案。把答案稳定、及时地送到用户面前，仍然是一项完整的软件工程工作。
参考链接：
https://www.youtube.com/watch?v=1P1hJ36rxM0&t=226s
——好文链接——
程序员远没到“完了”的时候！Sam Altman：OpenAI不包办一切，模型只是底座，开发者仍是AI生态的主角
AI时代，最强开发者更像CEO！Claude Code创始人：“一人军队”时代将要到来，好想法成为新的稀缺资源
AI时代的工作要靠自己创造！斯坦福AI经济学家：下一代开发者，要学会给一群Agent找事做，更大的机会是复制高手的工作方法