3、推理引擎选型：主流推理引擎（vLLM、TensorRT-LLM、TGI、SGLang）对比、适用场景、性能基准测试方法
在生产级LLM推理系统的架构决策中，推理引擎的选型直接决定了系统的吞吐量、延迟、显存效率以及运维复杂度。当前主流引擎——vLLM、TensorRT-LLM、TGI（Text Generation Inference）和SGLang——各自基于不同的优化哲学与运行时设计，没有“万能最优解”，只有“场景最适配”。本章将深入剖析四者的核心原理、适用边界、性能基准测试方法，并结合真实案例给出选型决策框架。
3.1 核心原理：四种引擎的优化哲学
理解推理引擎的差异，首先要抓住其核心优化机制。vLLM 的基石是 PagedAttention，它将 KV Cache 划分为固定大小的块（Page），通过虚拟内存映射实现非连续显存分配，从而将显存碎片化率降低 60%-80%，并支持同一序列的 KV Cache 跨块存储。这种设计使得 vLLM 在长序列、高并发场景下表现优异，且天然支持连续批处理（Continuous Batching），即每步解码后立即插入新请求，最大化 GPU 利用率。
TensorRT-LLM 则走的是 编译期极致优化 路线。它将模型编译为 TensorRT 引擎，在构建阶段完成层融合（Layer Fusion）、内核自动调优（Kernel Auto-tuning）、精度校准（FP8/INT8/INT4）等操作。其核心优势在于：通过图优化减少 kernel 启动开销，通过量化降低显存带宽压力，在批量推理时能达到接近硬件理论峰值的吞吐量。但代价是模型转换时间长（通常 10-30 分钟），且对动态形状支持较弱。
TGI 由 HuggingFace 团队维护，其设计目标是 生产环境的易用性与稳定性。它内置了张量并行（Tensor Parallelism）、连续批处理、量化（/AWQ）、流式输出等特性，并提供 Rust 编写的 HTTP 服务器，具备良好的并发处理能力。TGI 的优化更偏向“工程化”，而非“算法级”，因此其性能通常略低于 vLLM 和 TensorRT-LLM，但胜在部署简单、生态兼容性好。
SGLang 是较新的引擎，其核心创新是 RadixAttention，一种基于基数树的前缀缓存机制。它能够自动识别并复用多个请求之间的公共前缀（如 System Prompt、Few-shot 示例），从而避免重复计算 KV Cache。此外，SGLang 引入了 RadixTree 调度器，支持细粒度的请求优先级控制，并提供了结构化生成（如 JSON Schema 约束）的原生支持。这使得 SGLang 在多轮对话、Agent 调用、批量处理相似请求时具有显著优势。
- vLLM：显存管理革命（PagedAttention）→ 高并发友好
- TensorRT-LLM：编译期优化（图融合+量化）→ 高吞吐离线
- TGI：工程化稳定（Rust服务+生态集成）→ 快速部署
- SGLang：前缀复用（RadixAttention）→ 高相似度请求
3.2 适用场景与选型判断方法
选型不能只看性能数字，必须结合业务负载特征、硬件环境、团队技术栈和运维能力综合判断。以下是基于实际项目经验的选型决策矩阵：
| 场景特征 | 推荐引擎 | 关键理由 | 需注意的代价 |
|---|---|---|---|
| 高并发在线服务（>100 QPS） | vLLM | PagedAttention 显存效率高，连续批处理吞吐稳定 | 长序列下调度开销增加 |
| 离线批量推理（数万条样本） | TensorRT-LLM | 编译优化后吞吐最高，FP8 可降本 | 模型转换时间长，需预热 |
| 快速原型验证/中小流量 | TGI | 部署简单，HuggingFace 模型直接加载 | 极端高并发下性能瓶颈 |
| 多轮对话/Agent 工具调用 | SGLang | 前缀缓存命中率高，结构化输出支持好 | 社区相对较小，文档待完善 |
| 多模态模型（LLaVA 等） | vLLM / SGLang | 两者均支持视觉编码器与 LLM 联合推理 | TensorRT-LLM 多模态支持滞后 |
判断操作流程：首先，明确业务负载类型（在线/离线/混合）；其次，统计请求的 长度分布（平均长度、P99 长度）；再次，评估硬件环境（是否全 NVIDIA、显存容量、是否支持 FP8）；最后，考虑团队维护能力（是否愿意接受 TensorRT 的编译复杂度）。建议在选型前，使用标准数据集对候选引擎进行 A/B 测试，而非仅凭文档参数决策。
3.3 性能基准测试方法
基准测试是选型的核心依据，但很多团队测试方法不规范，导致结果失真。一个严谨的基准测试应包含以下步骤：
- 定义负载模型：使用真实业务请求分布（如 ShareGPT 数据集或自采日志），而非固定长度输入。需记录输入 长度分布、输出长度分布、并发数。
- 确定关键指标：TTFT（首 延迟）、TPOT（每输出 延迟）、吞吐量（Tokens/s）、端到端延迟 P99、显存占用峰值。
- 控制变量：相同 GPU 型号、相同模型权重（需统一精度，如 FP16 或 FP8）、相同 Batch Size 策略（动态批处理 vs 固定批处理）、相同并发数。
- 预热与稳定性：每个引擎需预热 5-10 分钟，待显存分配稳定后再采集数据；测试时长不少于 15 分钟，避免冷启动影响。
- 多轮取中位数：每轮测试重复 3 次，取中位数而非平均值，以排除偶发抖动。
# 示例：使用 vLLM 的 benchmark 脚本
python -m vllm.benchmark.benchmark_throughput \
--model meta-llama/Llama-3-8B-Instruct \
--dataset ./sharegpt.json \
--num-prompts 2000 \
--max-num-seqs 256 \
--tensor-parallel-size 2 \
--output-json ./result_vllm.json3.4 案例拆解：某金融科技公司的选型实战
背景与约束：某金融科技公司需要部署一个面向客户的智能投顾助手，要求端到端延迟 P99 < 2 秒，支持 200 并发，模型为 Llama-3-70B-Instruct，硬件为 4×A100 80G，团队运维能力中等，偏好开源方案。
初始现象：最初使用 TGI 部署，发现并发超过 120 时，TTFT 从 300ms 飙升至 1.2s，且显存出现碎片化，导致 OOM 风险。通过监控发现，TGI 的连续批处理在长上下文（平均 2000 tokens）下效率下降明显。
分析过程：团队采集了 3 天的真实请求日志，发现 60% 的请求共享相同的 System Prompt（约 500 tokens），且多轮对话占比 40%。基于此，他们评估了 vLLM 和 SGLang。vLLM 的 PagedAttention 能解决显存碎片问题，但无法复用 System Prompt 的 KV Cache；SGLang 的 RadixAttention 则能直接命中前缀缓存，预计可减少 30% 的计算量。
实际操作：团队分别用 vLLM 和 SGLang 部署了相同的模型，使用相同的 ShareGPT 风格数据集进行压测。结果如下：
| 指标 | TGI（原方案） | vLLM | SGLang |
|---|---|---|---|
| 吞吐量（Tokens/s） | 1850 | 3200 | 4100 |
| TTFT P99（ms） | 1150 | 620 | 480 |
| 显存峰值（GB） | 72.5 | 65.2 | 61.8 |
| 端到端 P99（s） | 2.8 | 1.9 | 1.6 |
结果与复盘：最终选择 SGLang，因为其前缀缓存机制在真实负载下带来了 28% 的吞吐提升和 33% 的延迟下降。但团队也付出了代价：SGLang 的 API 与 不完全兼容，需要额外开发适配层；且其调度器在极端突发流量下（>300 并发）出现 CPU 瓶颈，需配合限流策略。复盘经验：选型必须基于真实负载特征，而非通用 benchmark；同时，新引擎的引入需评估周边生态（如监控、日志、弹性伸缩）的适配成本。
3.5 常见误区与总结
误区一：只看吞吐量，忽略延迟分布。 某些引擎平均延迟低，但 P99 抖动大，不适合在线服务。必须同时关注 TTFT 和 TPOT 的分布曲线。
误区二：忽略显存碎片化。 即使总显存足够，碎片化也可能导致 OOM。vLLM 和 SGLang 在长序列场景下表现更好，而 TGI 在极端长上下文下容易触发碎片问题。
误区三：不做模型精度对齐。 对比时若一个引擎用 FP16，另一个用 FP8，结果毫无意义。必须统一精度，并验证量化后的质量损失（如使用 perplexity 或下游任务指标）。
误区四：忽略 CPU 瓶颈。 高并发下，调度器（Scheduler）和 Tokenizer 可能成为瓶颈。建议在压测时同时监控 CPU 使用率，若 CPU 先于 GPU 打满，需考虑增加 CPU 资源或优化预处理。
总结：推理引擎选型是一个多目标优化问题。建议采用“两步走”策略：第一步，基于业务负载特征和硬件条件，用本章的决策矩阵筛选出 2-3 个候选引擎；第二步，设计贴近生产的基准测试，用数据驱动最终决策。同时，保持引擎的可替换性——通过抽象推理服务层（如统一 API 接口），降低未来切换引擎的迁移成本。