20 引擎选型
20.1 引擎全景
推理引擎是把模型权重变成可调用服务的软件层，它决定了同一批硬件能产出多少 token。
| 引擎 | 出身 | 定位特点 |
|---|---|---|
| vLLM | 加州大学伯克利分校发起的开源项目 | PagedAttention 的提出者，社区最大，模型覆盖最全 |
| SGLang | 开源社区项目，与 LMSYS 生态关系密切 | 结构化生成与前缀复用见长，国内团队参与度高 |
| TensorRT-LLM | 英伟达官方 | 与自家硬件耦合最深，特定配置下峰值性能强，灵活性较低 |
| Dynamo | 英伟达官方的分布式推理框架 | 面向多节点分离式部署与调度编排 |
| 自研分支 | 在上述之一基础上改造 | 多数产能运营方的真实形态 |
现实中很少有人从零写引擎。主流做法是选一个开源引擎作为底座，在调度、缓存、内核三处做自己的改动。录音里描述的做法也是如此：生产推理引擎基于 SGLang 改动。录
图 45引擎在技术栈中的位置
分层为逻辑划分，不同引擎的边界并不完全一致。
我们不重写引擎，我们改的是中间这两层：怎么排队、怎么管缓存、关键算子怎么写。
20.2 能力矩阵
选型不看综合评分，看你的流量画像落在哪个格子里。
| 能力项 | 为什么重要 | 选型时的追问 |
|---|---|---|
| 模型覆盖 | 新模型出来多久能跑起来 | 目标模型是否 day-0 支持，还是要等社区适配 |
| 前缀缓存 | 编程类流量的主要成本杠杆 | 跨请求跨会话是否复用，命中率如何统计 |
| PD 分离 | 决定能否做异构与独立扩缩容 | 是否原生支持，KV 传输走什么后端 |
| 量化支持 | 决定单机能装多大模型 | 支持哪些精度，是否有官方验证的质量数据 |
| 投机解码 | 特定流量的加速手段 | 草稿模型如何配置，接受率可观测吗 |
| 多租户隔离 | 商务上能否签独占 SLA | 配额粒度到什么程度 |
| 可观测性 | 决定运维能不能定位问题 | 能否分阶段输出首字与出字分布 |
图 46按流量画像做引擎选型
能力项为示意分组，不代表任一引擎的实际能力评价。
没有最好的引擎，只有最适配我们这批客户流量的引擎。先看流量长什么样，再选。
20.3 选型判据
选定一个引擎作为底座，用三项实测决定，不用综述文章决定。第一项，目标模型的 day-0 可用性。这门生意的节奏由模型发布节奏驱动，新模型出来一周内能不能上线直接决定能不能吃到那一波需求。验证方法是回看过去三次重要模型发布，各引擎分别隔了多久支持。第二项，在自有流量画像下的吞吐与延迟。用真实流量的长度分布回放，而不是用固定长度的合成负载，两者结论经常相反。第三项，故障时的可诊断性。生产系统的成本大头不是峰值性能，而是出问题时定位要多久：能不能分阶段输出指标、能不能复现单个请求的执行路径，这决定了运维人力规模，见第 21.5 节和第 36.1 节。
追问上一个大模型发布时，这套引擎隔了几天可用；对比数据用的是我方流量分布还是合成负载。
修订记录
| 日期 | 改了什么 | 为什么 | 谁 |
|---|---|---|---|
| 2026-08-04 | 按章导入，正文与插图保持原样 | 原稿结构清晰，重写反而损失信息 | 工程 |