推理框架选型：vLLM、SGLang、TensorRT-LLM、LMDeploy 与端侧框架¶
本书以 vLLM 和 SGLang 为主线，但实际工作中常要回答"为什么选它、不选别的"。这一章按选型时真正要问的问题，把几个主流框架放在一起比较：它们各自的设计重心、擅长的场景、需要付出的代价。框架迭代很快，这里只写相对稳定的定位和判断方法；具体的功能与性能，一定以你自己的模型、硬件和负载上的实测为准。
自测：能答上来就可以跳过本章
- vLLM 和 SGLang 的设计重心有什么不同？
- TensorRT-LLM 适合什么场景？代价是什么？
- 选型时最应该先确认的三件事是什么？
- 怎样做一次公平的框架对比测试？
自测参考答案（先自己答，再展开对照）
- vLLM 通用、生态最广、硬件覆盖最全（多种 GPU 和加速卡），重视稳定和兼容；SGLang 更偏性能和前沿特性：前缀缓存（RadixAttention）、大规模 EP、结构化输出、RL 相关的能力。
- 只在 NVIDIA GPU 上、追求极致性能、模型相对固定的场景。代价是模型要先编译成引擎、换模型或改动的周期长，支持新模型较慢，调试和定制更难。
- 模型支持（包括量化格式）、硬件支持、你的场景需要的关键特性（比如多 LoRA、结构化输出、PD 分离、长上下文）。
- 同样的模型、精度和请求分布；每个框架都按官方建议调好参数（并行方式、batch 上限、分块大小、CUDA Graph 档位），不用默认配置；比较 SLO 下的 goodput 曲线而不是峰值吞吐；抽样检查输出质量，确认不是"更快但更差"。
几个主流框架的定位¶
| 框架 | 设计重心 | 擅长 | 需要注意 |
|---|---|---|---|
| vLLM | 通用、生态最广：分页 KV 的起源，V1 引擎把调度、KV 管理、执行分层；插件化的硬件后端 | 模型覆盖面广、新模型支持快；多种硬件（NVIDIA、AMD、TPU 等）；KV connector 接口让 PD 分离和 KV 卸载可插拔 | 功能多、配置项多，需要按负载调参；某些前沿特性的落地可能晚于专门优化的框架 |
| SGLang | 性能与前沿特性：RadixAttention 前缀缓存、零开销的重叠调度、结构化输出、大规模 EP | 多轮对话和智能体（前缀复用多）、DeepSeek 类 MoE 的大规模部署（DP Attention、DeepEP、EPLB）、RL rollout（verl、slime 等都在用） | 迭代快，版本之间的变化较大；部分硬件的支持不如 vLLM 全面 |
| TensorRT-LLM | NVIDIA 官方：高度优化的 kernel 与引擎，新硬件特性（FP8、FP4、新的注意力 kernel）支持最早 | 在 NVIDIA GPU 上追求极致性能；与 Triton Inference Server、Dynamo 的集成 | 只支持 NVIDIA；传统的"编译引擎"流程较重（新版本也提供了 PyTorch 的工作流）；定制新模型的成本较高 |
| LMDeploy | C++ 的 TurboMind 引擎加 PyTorch 引擎；量化工具链完整 | W4A16（AWQ）、KV Cache 的 INT8 / INT4 量化；国内模型的适配 | 社区与生态规模小于前两者 |
| llama.cpp / Ollama、MLX、ExecuTorch | 端侧与本地：CPU、Apple Silicon、手机 | 单用户、离线、隐私场景（见端侧推理） | 不适合高并发的服务端 |
此外还有很多围绕这些引擎的组件：NVIDIA Dynamo、llm-d、Mooncake 做分离式架构的调度与 KV 管理，LMCache 做 KV 缓存层，Triton Inference Server、KServe 做通用的模型服务框架。它们通常不替代引擎，而是组合在引擎之上。
选型时要问的问题¶
按优先级：
- 模型和硬件能不能跑：目标模型（包括新发布的模型）是否在第一时间被支持？你的硬件（GPU 型号、AMD、国产卡）有没有维护良好的后端？这一条不满足，其他都不用谈（框架怎样接入不同的硬件，见多硬件支持）；
- 关键特性是否具备：你的场景需要的特性——前缀缓存、分块 prefill、PD 分离、大规模 EP、多 LoRA、结构化输出、投机解码、量化格式、长上下文——哪些是成熟可用的，哪些只是"支持"但还不稳定；
- 在你的负载上的性能：用你真实的请求分布（输入输出长度、并发、前缀共享比例）压测，比较满足 SLO 时的最大吞吐（goodput），而不是厂商的基准数字；
- 可运维性：指标与追踪、Kubernetes 集成、升级的平滑程度、问题排查的难度；
- 可定制性与社区：团队需要改代码吗？代码是否好读、好改（Python 为主还是大量 C++）？社区活跃度、问题响应速度、发版节奏。
很多团队的实际做法是主力 + 备选：以一个框架为主，另一个作为特定场景（比如 RL rollout、某类模型）的补充，并保持在两者之间切换的能力（统一的 OpenAI 兼容接口、统一的网关）。
怎样做一次公平的对比¶
- 同样的模型文件和精度：同一个 checkpoint、同样的量化方式；
- 同样的请求：固定随机种子生成的数据集或真实流量的回放，相同的输入输出长度分布；输出长度用
ignore_eos或固定的最大长度控制，避免因为提前结束造成的差异； - 各自调好参数：用默认配置比较是不公平的——每个框架都要按官方建议调好并行方式、batch 上限、分块大小、CUDA Graph 档位；
- 比较 goodput：在 TTFT、TPOT 的 SLO 下，每秒能完成的请求数；同时报告 P50 / P99 延迟曲线（随负载增加的变化），而不是单点；
- 检查输出：抽样对比输出质量，确认没有因为某个优化（比如激进的量化、错误的采样参数）而"更快但更差"。
压测方法见压测、SLO 与容量规划，定位差距用 Profiling 推理引擎。
怎么讲清楚
"为什么用 vLLM / SGLang"不要只说"性能好、社区大"。按选型的顺序讲：模型与硬件支持 → 场景需要的关键特性 → 在自己负载上的 goodput 实测 → 可运维性 → 可定制性。再举一个具体的取舍，比如"多轮对话前缀复用多，SGLang 的 RadixAttention 命中率更高；但我们的 AMD 集群上 vLLM 的后端更成熟，所以……"。能说出"怎样做一次公平的对比"，比报出某个基准数字更有说服力。
练习¶
1. 厂商的基准测试说 A 框架比 B 快 2 倍，你会怎样验证？
参考思路
先看基准的条件：模型、精度、硬件、请求长度分布、并发、是否开启了投机解码或特殊的量化、比较的是吞吐还是延迟、B 框架是否用了推荐配置。然后在自己的负载上复现：固定请求集、各自调好参数，画出 goodput 随负载变化的曲线。常见的情况是，在某个特定的负载点上确实快 2 倍，但在你关心的区间里差距很小，或者反过来。
小结¶
- vLLM 通用、生态广、硬件覆盖全；SGLang 偏性能与前沿特性（前缀缓存、大规模 EP、RL）；TensorRT-LLM 在 NVIDIA 上追求极致性能；LMDeploy 量化工具链完整；端侧另有专门的框架。
- 选型顺序：模型与硬件支持 → 关键特性 → 自己负载上的 goodput → 可运维性 → 可定制性与社区。
- 公平对比：同样的模型与请求、各自调参、比较 SLO 下的 goodput 曲线并检查输出质量。
发现错误或有更好的写法？在 GitHub 上编辑此页提交问题