第 10 章 — LLM Engine 层

《LLM Primer VI: Scaling AI Systems》章节走读的第十篇。这一章要说的是:命名 engine 和平台之间的那道边界,并走一遍 2026 年在这一层占主导的五个 engine。

这一章为什么存在

第 1 到 9 章走了一次前向传播能碰到的那些机制:自回归循环、KV cache、GPU 底座、缩小它的量化、隐藏它空转时间的 batching、以及打破它顺序依赖的投机解码。它们没有一个是 pip install 就能用的库。得有人把它们连成一个单节点运行时,包住一个模型、拥有 KV cache、把请求调度到一份 continuous batch 上、暴露一份推理 API。这个运行时就是 engine。第 10 章命名 engine 层的分工,把它和平台层(第 11 章)划开,并走一遍在同一份分工上做出不同机制取舍的五个 engine —— vLLM、TensorRT-LLM、SGLang、TGI、Ollama。

10.1 vLLM 是 Python 原生的默认选择

vLLM 是多数生产团队第一个该拿的 engine,因为它在初学者不知道怎么想的每一根轴上都做了对的默认决定,而且是用 Python 做的。PagedAttention 把碎片化从 60–80% 打到个位数,让同一块 GPU 上可实现的 batch 大小大概翻一倍。Continuous batching 自然叠在上面,chunked prefill 把 prefill 和 decode 混到同一次迭代里,让两者的边界不再是死时间。基于 block-table 设计的写时复制前缀共享是免费的。接口真的就是几行离线批处理或 OpenAI 兼容 HTTP,新的模型架构因为社区面大也落地得很快。当负责部署的人没有特别的理由挑别的时候,vLLM 就是那个用来标准化的 engine。

10.2 TensorRT-LLM 用一条构建流水线换吞吐

TensorRT-LLM 的卖点很窄。如果 fleet 完全是 NVIDIA、每一个百分点的每美元吞吐都要计较、团队愿意为按模型和硬件代次编译各自的 engine 文件付一份工程税,TRT-LLM 在同一份硬件上能比 vLLM 多榨出 15–35% 的吞吐。机制是在 kernel 层面:把 transformer 图降到 NVIDIA 专有 IR、融合相邻 kernel(layernorm + matmul + activation 合成一次启动)、按 shape 从一份预调好的库里选最优 kernel、产出一份序列化 engine、在 Triton Inference Server 下运行。融合关键在于 kernel 启动开销每次 5–10 μs,而朴素的 70B 前向传播每 token 要派发几千次。税就是那条构建流水线本身 —— 一份按模型、按 GPU、按 batch 区间的编译步骤,大多数团队低估了它的运营成本。SGLang 是另一种特化:RadixAttention 把 engine 见过的每一份 prompt 前缀的 KV 存在一棵基数树里,两条共享 k token 前缀的请求跨 batch、跨时间共享正好那 k token 的 KV。在有长共享系统 prompt 和短变体后缀的 agent 型工作负载上,SGLang 比 vLLM 多 2–6× 吞吐,而且它的结构化输出 DSL 在 logit 层强制 JSON schema,输出保证过校验。

10.3 决策树走的是工作负载形状,不是标题吞吐

五个 engine 铺开成一棵小小的决策树。开发者笔记本或混合加速器边缘 → Ollama。生产 GPU fleet,完全 NVIDIA、高 QPS、吞吐 ROI 撑得起构建流水线 → TensorRT-LLM。混合硬件或频繁换模型、且工作负载被前缀重的结构化模式(agent、工具调用、长共享 prompt)主导 → SGLang。混合硬件、常规 chat、深度依赖 Hugging Face 集成 → TGI。其他一切 → vLLM。这个决定不是永久的:engine 在 API 边界上可互换 —— 它们都说 OpenAI 风格 HTTP —— 所以平台层的路由器可以按模型、按工作负载、按区域切流量,不用改客户端代码。很多生产栈里同时并肩跑两三个 engine。当心标题 benchmark:"Llama-2-7B 在 batch 1 时每秒多少 token" 回答的是没有哪一个生产工作负载真的问的那个问题。用自己的模型、自己的 prompt 分布、自己的并发画像去 benchmark;半天时间,省几个月。

第 10 章为下面铺了什么

本章描述的每一个 engine 都停在同一道边界前。它懂 kernel、KV block、continuous batching;它不懂副本、租户、编排、认证。第 11 章走那些管这些事的平台层 —— Ray Serve、KServe、BentoML、Triton Inference Server —— 并说明这个选择远远不是关于功能,而是关于哪一种运营模型贴合团队现有的基础设施和能力。

下一章 — 第 11 章:平台与编排层。Ray Serve、KServe、BentoML、Triton —— 坐在 engine 上面的四个平台,按 ops 文化契合度来挑。