服务框架对比：vLLM、SGLang、TensorRT-LLM 等

前面几章的技术（PagedAttention、连续批处理、投机解码、量化）都要有载体。推理服务框架就是把它们打包的软件层。本章横向对比主流框架、给出选型维度与基准测试方法——框架选型的正确姿势不是看榜单，是拿自己的模型和流量做基准。

主流框架一览

框架	定位	核心优势	典型用户
vLLM	通用开源王者	PagedAttention 发源地、生态最大、模型覆盖最广	默认起点
SGLang	高吞吐新锐	RadixAttention（前缀树 KV 共享）、结构化输出快	Agent/多轮对话
TensorRT-LLM	NVIDIA 官方	深度硬件优化、极致延迟	延迟敏感的生产服务
llama.cpp / Ollama	端侧/轻量	CPU/Mac 可跑、零依赖	本地部署、个人
DeepSpeed-FastGen / MII	微软系	与 DS 生态配套	已用 DS 的团队
Mooncake / DistServe	分离架构	P/D 分离、KV 传输优化	超大规模服务

一、模型覆盖：你的模型（架构、变长、多模态）被支持吗？vLLM 覆盖最广；TensorRT-LLM 要为每个模型编译 engine（新模型支持滞后）。

二、量化支持：AWQ/GPTQ/FP8 checkpoint 直接加载吗？（见量化）vLLM/SGLang 都支持主流格式。

三、高级特性：

特性	vLLM	SGLang	TRT-LLM
前缀共享	automatic prefix caching	RadixAttention（更彻底）	有
投机解码	支持	支持	支持
P/D 分离	扩展支持	支持	支持
结构化输出（JSON 等）	一般	快（编译级）	一般
CUDA Graph	有	有	最彻底

四、生态与运维：文档、社区答案、监控集成、版本节奏。vLLM 的社区最大，问题最容易被搜到；TRT-LLM 有 NVIDIA 商业支持。

五、性能：同一模型同一流量下实测——这是唯一可信的维度（榜单与宣传都不可信，见下）。

框架对比的错误姿势是"跑一个 benchmark 贴榜单"。正确姿势：

一、用自己的模型与流量：模型架构、序列长度分布、请求模式（并发、到达率）都要贴近真实。长度方差是吞吐的最大变量——评测集的长度分布错了，结论全错。

二、测三个指标，不只测吞吐（见连续批处理）：

三、扫到极限：单点数字无意义，画"吞吐-延迟曲线"（增加并发直到 SLO 破线），曲线的位置才代表框架的真实水平。

四、控制变量：同硬件、同精度、同 KV 配置（gpu_memory_utilization 对齐）、同投机解码配置——每个开关都影响巨大。

五、稳态测量：预热（KV 池填满、CUDA Graph 编译完）后再测；测 10 分钟以上——冷启动数字全是噪声。

坑	说明
max_model_len 虚设	预留按最大长度算，KV 池被虚高需求挤压（见 KV）
gpu_memory_utilization 太高	显存打满 → OOM 随机出现；留 10–15%
忽略预热	首批请求编译/分配，延迟全是假的
TP 配置与硬件不符	TP 跨 NVLink 域（见节点内互连）
拿单点吞吐对比框架	曲线位置才可信
版本漂移	vLLM/SGLang 迭代极快，每季度的性能差异巨大，基准要跟着重跑

场景	推荐形态
默认起点	vLLM（生态最大，踩坑最少）
Agent/多轮对话/结构化输出重	SGLang（RadixAttention + 结构化输出）
延迟极致、NVIDIA 全家桶	TensorRT-LLM
个人/本地	Ollama / llama.cpp
超大规模、SLO 严格	P/D 分离方案（Mooncake/DistServe）+ 按需选框架
深度自定义	vLLM/SGLang 源码级定制（都是 Apache/MIT）