第 8 章 引擎选型：四个引擎各解决什么问题

账算完了，还差一个选择

二十个同事、8K 合同、一张 80GB 卡。账算清楚了：14 条并发，6 条排队。

现在要把这些请求真正服务出去。打开搜索，四个名字反复出现：vLLM、SGLang、llama.cpp、TensorRT-LLM。

它们解决的不是同一个问题，把它们当成"四个竞品"比较，比不出结果。

vLLM：把显存分配和调度做到通用

vLLM 的起点是第 5 章那个浪费问题。它把缓存分页管理，论文里报告浪费降到 4% 以下、吞吐提升 2 到 4 倍。

配套的是连续批处理和分块 prefill，第 3、4 章讲的两件事它都有。

它的定位是通用服务端：一张到多张 GPU，标准接口，多模型。你要的东西它基本都有，参数多，文档厚，社区大。

代价是"通用"本身。默认参数不一定贴合你的负载，很多收益要自己调出来。

SGLang：为共享前缀和结构化输出而生

SGLang 的出发点是多轮对话和 Agent：同一个系统提示、同一份文档、同一个工具描述，会在成百上千次请求里反复出现。

它把这些共享前缀做成可复用的树结构，一条新请求只要接上已有前缀，就不用重算。

如果你在第 5 章算过前缀缓存那笔账——二十条共享 500 token，省 4.9 GiB——这个场景就是它的主场。

它还擅长约束解码：输出必须是 JSON、必须符合某个 schema，它在生成时就把不合法的路堵死，而不是生成完再解析。结构化抽取、函数调用多的时候，这条很值钱。

llama.cpp：CPU、Mac、单机、极致量化

前三个都默认你有 NVIDIA 的卡。llama.cpp 不是。

它用 GGUF 格式，能在 CPU 上跑，能上 Apple Silicon，能在笔记本和树莓派上跑。量化档位多到离谱，从 2 比特到 8 比特都有。

代价很明确：它的强项是单机小规模，不是高并发服务。二十个同事同时来，它不是首选。

适合的场景是本地验证、离线批处理、边缘设备，以及你没有 GPU 的那些天。

TensorRT-LLM：把模型编译成一台专用机器

TensorRT-LLM 走的是另一条路：针对特定模型、特定 GPU、特定精度，提前编译出一份引擎文件。

好处是极致。算子融合、显存排布、kernel 选择都按你的卡调过，同样的硬件能压出更多吞吐。

代价是约束：换个模型要重新编译，换张卡要重新编译，调一个不支持的参数可能直接编不出来。模型更新频繁、硬件异构的团队会被这套流程拖住。

四问定选型

第一问，硬件是什么。没有 NVIDIA 卡，答案基本只剩 llama.cpp。

第二问，负载形状是什么。前缀高度重复、输出要结构化，SGLang 的优势会被放大；负载杂、模型多、要通用，vLLM 更稳。

第三问，性能要到什么程度。差 20% 能接受，vLLM 够；差 20% 就是钱，才值得上 TensorRT-LLM 的编译流程。

第四问，谁维护。团队两个人，选生态大的；有专门的人做部署，再考虑重编译的方案。

四问的顺序不能反。先硬件，再负载，再目标，最后人力。

迁移不是免费的

换引擎不是改个 import。

接口行为会变：同样的参数名，语义可能不同；同样的并发设置，实际 batch 可能不一样。

指标口径会变：TTFT 的起算点、P99 的统计方式，各家未必一致。换之前先用同一套压测脚本跑一遍基线，否则你无法判断是引擎变好了，还是你测的东西变了。

特性覆盖也会变：前缀缓存的默认开关、量化的支持档位、长上下文的实现方式，都需要逐项核对当期文档。

证据等级说明

这一章大部分判断来自各项目的论文和文档，属于 B 级：方向可信，具体倍数随版本、模型、硬件变化。

vLLM 的 2 到 4 倍来自论文实验，不是你的机器。SGLang 的收益取决于你的前缀重复率，重复率低就没有收益。TensorRT-LLM 的加速取决于它是否支持你的模型结构。

真要选，唯一的办法是在你的负载上跑一次第 9 章的压测。文档告诉你它能做什么，压测告诉你它对你做了什么。

经验：先用默认参数跑通，再谈优化

选型时最容易犯的错，是拿"调优过的 A"和"默认的 B"比。

正确顺序是：四个引擎都用默认参数跑通同一个负载，拿到基线；再各自调一轮；最后比。第一轮的结果往往和网上说的不一样，因为它反映的是默认值，不是引擎的上限。