LLM 推理引擎横评：vLLM vs SGLang vs TensorRT-LLM 选型指南（2026）

2026 年 LLM 推理引擎市场已形成三足鼎立格局：vLLM 以易用性和生态广度领跑、SGLang 在高并发吞吐上后来居上、TensorRT-LLM 在极致性能追求上无可替代。三者各有擅长场景，盲目选择任何一个都可能在某些维度踩坑。

本文基于真实生产数据给出选型框架，不是“谁最快”的简单排名，而是“你的场景用哪个最合适”的实用指南。

三大引擎基本信息

性能横评数据

以下数据基于 H100 SXM 80GB，Qwen3-32B（BF16），4 卡 TP=4 配置：

在线推理（单请求延迟优先）

TBT = Time Between Tokens（生成延迟，越低越好）

高并发吞吐（批处理效率）

SGLang 在中高并发下超过 vLLM，TRT-LLM 在峰值吞吐上遥遥领先。

显存效率

功能特性对比

SGLang 的差异化优势：RadixAttention

SGLang 的核心创新是 RadixAttention，相比 vLLM 的 Block-based Prefix Caching，RadixAttention 以 Radix Tree 结构管理 KV Cache，支持更精细的前缀共享：

vLLM Prefix Caching（Block 对齐）：
[S S S S | S S S S | S S Q Q]
 Block1    Block2    Block3
只有 Block 对齐的前缀才能共享，多出的 Token 无法利用缓存

SGLang RadixAttention：
[S S S S S S S S S S Q Q]
 ↑─────────────────────↑
 精确到 Token 级别的前缀共享，不需要 Block 对齐

适合 RAG 场景：不同查询使用同一文档，文档 Token 被精确复用，命中率显著高于 vLLM。

TensorRT-LLM 的差异化优势

TRT-LLM 的核心优势是 Engine 编译时优化：

1. Kernel Fusion：将多个小算子合并为一个大 Kernel，减少 GPU 启动开销
2. Weight-Only INT4 × FP16：NVIDIA 专有混合精度，不同于标准 INT4
3. In-flight Batching：NVIDIA 实现的连续批处理，比 vLLM 的实现更底层
4. Graph Optimization：编译时静态图优化，运行时无 Python 开销
5. FP4 Sparse：Blackwell GB200 专属，其他引擎暂不支持

但这些优化都需要付出编译时间成本：

# TRT-LLM 编译 Qwen3-32B Engine（H100 4卡）
# 以下命令耗时约 45-90 分钟
trtllm-build \
  --checkpoint_dir /models/qwen3-32b-trtllm-ckpt \
  --output_dir /engines/qwen3-32b-fp8 \
  --gemm_plugin fp8 \
  --workers 4 \
  --max_batch_size 64 \
  --max_input_len 8192 \
  --max_output_len 4096

# 每次修改参数（batch_size、max_len）都需要重新编译！

部署方式对比

vLLM 部署（最简单）

# 5 分钟内上线
pip install vllm
vllm serve /models/qwen3-32b \
  --tensor-parallel-size 4 \
  --dtype fp8 \
  --port 8000

SGLang 部署

pip install sglang[all]
python3 -m sglang.launch_server \
  --model-path /models/qwen3-32b \
  --tp 4 \
  --dtype float16 \
  --port 8000 \
  --mem-fraction-static 0.85

TRT-LLM 部署（最复杂）

# 步骤 1：量化转换（约 30 分钟）
python3 /opt/tensorrt_llm/examples/quantization/quantize.py \
  --model_dir /models/qwen3-32b \
  --output_dir /models/qwen3-32b-fp8-ckpt \
  --dtype float16 \
  --qformat fp8 \
  --calib_dataset cnn_dailymail \
  --calib_size 512 \
  --tp_size 4

# 步骤 2：编译 Engine（约 45-90 分钟）
trtllm-build \
  --checkpoint_dir /models/qwen3-32b-fp8-ckpt \
  --output_dir /engines/qwen3-32b \
  --gemm_plugin fp8 \
  --workers 4 \
  --max_batch_size 64

# 步骤 3：启动 Triton Inference Server
docker run --gpus all -v /engines:/engines \
  nvcr.io/nvidia/tritonserver:24.12-trtllm-python-py3 \
  tritonserver --model-repository=/engines

选型决策树

你的首要需求是什么？
│
├─ 快速上线 / 开发调试 / 多硬件支持（AMD、昇腾）
│     → ✅ vLLM
│        原因：pip install 即用，社区最活跃，硬件支持最广
│
├─ 高并发 RAG / 多轮对话 / Prefix Cache 命中率最大化
│     → ✅ SGLang
│        原因：RadixAttention 前缀共享效率更高，中高并发吞吐优于 vLLM
│
├─ 极致推理性能 / 生产级 SLA（P99 < 200ms）/ 离线批处理
│     → ✅ TensorRT-LLM
│        原因：编译时优化的 Engine 性能最高，TTFT/TBT 最低
│        代价：编译复杂，修改参数需重新编译，仅支持 NVIDIA
│
└─ Reasoning 模型（QwQ、DeepSeek-R2）
      ├─ 需要 thinking_budget 控制 → vLLM（0.21 原生支持）
      └─ 需要高吞吐 → SGLang（也支持 Reasoning 模型）

混合部署策略（推荐）

生产环境中，可以根据流量特征混合使用：

# 架构示例：流量分层路由
在线 API（P99 < 200ms）
  └── TRT-LLM（H100，编译优化的 Engine，延迟最低）

高并发 RAG / 问答
  └── SGLang（H100，RadixAttention 缓存效率高）

开发 / 测试 / AMD GPU / 异构环境
  └── vLLM（最简部署，广泛硬件支持）

离线批处理（夜间任务）
  └── TRT-LLM 或 vLLM（按需选择）

Benchmark 建议

不要依赖别人的 Benchmark，在你自己的数据分布和硬件上实测：

# 通用 LLM 推理基准工具
pip install llmperf

# 对比三个引擎（假设都在 localhost 的不同端口）
python3 token_benchmark_ray.py \
  --model qwen3-32b \
  --llm-api openai \
  --max-num-completed-requests 200 \
  --timeout 600 \
  --num-concurrent-requests 16 \
  --mean-input-tokens 512 \
  --stddev-input-tokens 128 \
  --mean-output-tokens 256 \
  --stddev-output-tokens 64 \
  --results-dir /results/vllm \
  --additional-sampling-params '{"max_tokens": 512}'

测试时务必覆盖你的实际数据分布：System Prompt 长度、用户问题长度、期望输出长度、并发量。

小结

结论：

• 日常部署首选 vLLM：最易用、生态最广、多硬件支持
• RAG/多轮对话选 SGLang：RadixAttention 在重复前缀场景效率更高
• 极致性能选 TRT-LLM：接受 45-90 分钟编译换取 30-50% 吞吐提升

三者并非竞争关系，同一集群可以部署多个引擎服务不同场景。选型最重要的原则：先 Benchmark，基于你自己的数据和硬件说话，不要用别人的测试结果做决策。