跨国深谈← 返回←大模型背后：推理引擎到底在干什么

大模型背后：推理引擎到底在干什么

关联

人物 Charles Frye

公司 Modal · SGLang · vLLM · PyTorch

概念 推理 · 推理引擎 · 调度器 · 预填充 · 解码 · KV 缓存 · 投机解码 · 分词器 · CUDA 图 · 智能体 · 可观测性

Modal 的 Charles Frye 在一场工程师活动上拆解了推理引擎的内部结构：

从进程架构、调度器瓶颈，到推测解码这类能带来数倍加速的关键技术。

你每天跟大模型对话，token 进、token 出，中间发生了什么？Charles Frye 在这场演讲里把这层壳拆开了。

他在 Modal 工作数年，帮很多团队在上百甚至上千块 GPU 上部署推理。

他说，用 PyTorch 加 Hugging Face Transformers,一两个小时就能写出一个能跑的引擎；真正的难点是让它高性能地跑——这决定了整套系统的设计。

为什么值得做推理，而不是训练模型？

Frye 的核心判断很直接：训练是成本中心，推理是收入中心。

卖模型权重很难做成生意，但用户愿意为推理付费——给系统输入 token,让它产出软件或答案。

现在行业里的格局是：少数模型铸造厂生产基础模型，大量推理工程师负责部署和定制。

连训练也离不开推理——模型的后训练适配需要从模型中生成样本，用的正是同一套技术。

对工程师来说，这个领域还很新，你要从应用架构一路管到硬件，是个游乐场。

什么样的任务会跑在推理引擎上？

Frye 把负载分成三类。第一类是 Chatbot Plus,像 ChatGPT 或 Claude Code,有人等在另一头，几百毫秒看不到响应就会不耐烦，输出通常几十到几百个 token。

第二类是后台代理，比如 Devon、OpenClaw,干的活类似但没人在等——几分钟出一个 PR 都可以接受。

第三类是数据处理，比如 Reducto 把 PDF 变成结构化数据、Fathom 从视频里提取文字。这类任务的指标不是延迟，而是总吞吐量。

在引擎内部，每个请求都分两步：先做 prefill 处理输入，再做 decode 一个个吐出输出 token。

这两步实际上是两个半独立的子负载，走不同的代码路径——prefill 每个请求的计算量大得多，decode 则轻得多。

这个差异是配置和优化引擎的出发点。

引擎长什么样？一个调度器卡住了整条流水线

典型的推理引擎(他拿 SGLang 举例)是一组互相通信的进程：

一个负责 HTTP 收发，一组做 token 化和反 token 化，中间是调度器，最里面是真正在 GPU 上干活的模型前向计算进程。

有意思的是瓶颈所在。GPU 是最贵、算力最强的部件，但调度器才是它的守门人。

调度器在语义上是单线程的：必须有唯一的地方决定 GPU 接下来跑什么。它自己做的运算不多，却可能拖住整台 GPU。

有人问能不能并行跑多个调度器，Frye 说目前不值得——协调 GPU 资源带来的复杂度远超收益，只要主机侧比 GPU 侧快就够了。

至于为什么用 Python 而不是 Rust:Python 对 GPU 的支持最好，模型前向那部分离 GPU 近的代码其实都被编译优化过，Python 只是在组织工作。

倒是调度器是个很合适的 Rust 重写目标——它纯粹在主机侧，不需要懂 PyTorch。

为什么没人谈token 化缓存？

引擎靠外部库提供 GPU 内核，所以各家引擎在裸 GPU 性能上差别不大，比的是多会给 GPU 让路。

每个引擎真正的独门绝活是批构造：怎么把请求拼成批，要不要把 prefill 和 decode 混在一个队列里。

一个细节：输入 token 的到达速率远高于输出 token 的产生速率，所以 SGLang 用多个 token 化进程，反 token 化只有一个。

还有，所有人都在谈 KV 缓存，却没人谈 token 化缓存——虽然技术上完全可以做。

推测解码：少数能带来成倍加速的技术

decode 是串行的：每生成一个 token,都要把模型参数(可能是几百 GB)重新加载一遍。想每毫秒出一个 token,就需要 PB 每秒级的内存带宽，不现实。

推测解码的思路是让一个小模型先连猜几个 token,再让目标模型并行批改。

用对采样技巧，可以保证输出和逐个生成完全一致——相当于把 decode 变成了迷你 prefill。

Frye 强调，大多数优化都是挤百分比的游戏，一次挣 5%、10%;而把推测模型练好，直接给你 2 倍、4 倍甚至 8 倍的提速。

这是在 NVIDIA 硬件上对相当大的模型跑到每秒 1000 token 的关键。

出了问题怎么查？

生产环境里的 bug 分几层：模型本身行为怪是应用开发者的事；模型质量 bug 是引擎的事——你做了性能优化，有没有改变模型行为？

模型刚发布时 token 化器常有小 bug,几周后才会修好。最烦的是性能随时间退化的回归，以及不同副本之间性能不一致。

他的建议很朴素：日志记的指标要远多于你以为需要的，因为你不知道哪个交叉比对会让 bug 从查不出变成一眼看穿。

查 token 化 bug 的窍门是把 token ID 也记下来。遇到流量洪峰，排队会让首 token 时间和 token 间隔延迟一起飙升，解法是扩副本分摊请求。

想上手的话，他推荐看 MiniSGLang 和 NanoVLLM 这两个极简实现——代码少到能整个塞进一个智能体的上下文窗口里。

本集带走

• 训练是成本中心，推理是收入中心，这是推理工程值得投入的根本原因。
• 推理引擎的真正瓶颈常常不是 GPU,而是语义上单线程的调度器——GPU 的守门人。
• 每个请求都拆成 prefill 和 decode 两个子负载，计算强度差别巨大，决定了引擎怎么设计。
• 推测解码是少有的能带来成倍(而非百分之几)加速的技术，值得往推测模型上砸数据和算力。
• 日志记的指标要比你以为需要的多得多，交叉比对常常是定位 bug 的关键。

我认为，这里是工程工作如此关键的落点、作为工程师在这里工作如此酷的根本原因是：归根结底，训练是成本中心，推理是收入中心。
I think the fundamental reason why this is such a critical place for engineering work to get done and why it’s such a cool place to work as an engineer is that in the end, training is a cost center and inference is a revenue center.
—— Charles Frye · [04:52]

人们普遍无法把直接向别人出售模型权重的生意做成，所以你没法真正把一个训练部门变成一个能自我支撑的系统。
People have not generally been able to make businesses work where they sell model weights to people directly, and so you can’t really turn a training setup into a proper self-supporting system.
—— Charles Frye · [05:11]

一旦你在乎性能，它就是有状态的，而这几乎是所有情况。
It’s stateful once you do care about performance, which is pretty much every case.
—— Charles Frye · [20:03]

你试图在 GPU 资源上管理锁或协调所带来的复杂度增加，远大于收益，因为即使你能把它降到微秒级，工作也要等到 GPU 上前一个工作完成后才会开始。
The complexity increase that you get from trying to manage locks or coordination on the GPU resources, that complexity increase is much greater than the gain, because even if you were able to get it down to a microsecond, the work wouldn’t start happening until the previous work on the GPU had finished.
—— Charles Frye · [24:08]

我把那本质上视为引擎的一种失败状态，如果我到了出现 KV cache 抖动或者东西被刷到磁盘的地步，那说明我把引擎部署得不对。
I think of that as essentially like a failure state of the engine that we, like I’ve deployed my engine improperly if I get to the case where I have KV cache thrashing or like things being flushed to disk.
—— Charles Frye · [45:46]

这是每秒 PB 级的内存带宽。
That’s petabyte per second scale memory bandwidth.
—— Charles Frye · [51:23]

你能对推理引擎做的许多其他优化，都像是寸土必争的百分比游戏，每次百分之五、百分之十，而且你必须为每一个百分点做非常困难的性能工程。
So many other optimizations that you can do on your inference engine are like, it’s like a game of inches of a percent, five percent, 10 percent each time, and you have to do the very difficult performance engineering for each of those percentage points.
—— Charles Frye · [52:31]

所以这已经成为让你能够在 NVIDIA 硬件上以每秒约 1,000 个 token 运行相当大的模型的关键技术之一，而不必去用像 LPU 或 Cerebras 这样的新型加速器。
So this has emerged as one of the key techniques to allow you to operate, say, 1,000 tokens per second on NVIDIA hardware for actually fairly large models without having to go to a novel accelerator like an LPU or Cerebris.
—— Charles Frye · [53:06]