推理引擎组件对比 · Plan B 附录

4 大主流推理引擎横向对比，每个维度都打分，给管理层做选型决策。

引擎介绍

引擎	出品	主打	首发
vLLM	UC Berkeley	高吞吐 + PagedAttention	2023
SGLang	LMSYS	长上下文 + 结构化输出 + RadixAttention	2024
TensorRT-LLM	NVIDIA	低延迟 + kernel 融合 + 商业级	2023
TGI	Hugging Face	HF 官方推理	2022

一、性能对比（H800 单卡 · Qwen2 7B FP16）

引擎	吞吐 (tok/s)	TTFT (ms)	TPOT (ms)	备注
vLLM 0.6	1200	180	30	默认设置
SGLang 0.3	1100	200	32	长上下文更强
TRT-LLM 0.10	1400	120	25	编译期长
TGI 2.0	900	250	40	已不推荐

数据来源：各家 benchmark 汇总；实际数字随 batch size / 长度浮动 ±20%

二、功能特性对比

特性	vLLM	SGLang	TRT-LLM	TGI
PagedAttention	✅	✅	✅	部分
Continuous batching	✅	✅	✅	✅
Prefix caching	✅	✅✅（RadixAttention）	部分	❌
Speculative decoding	✅	✅	✅	❌
Chunked prefill	✅	✅	✅	❌
FP8 (H100/H800)	✅	✅	✅	❌
INT8 (SmoothQuant)	✅	✅	✅✅	❌
Grammar-guided	outlines 插件	✅✅（内建）	❌	❌
JSON Mode	outlines 插件	✅✅	❌	✅
Function calling	✅	✅	❌	❌
LoRA hot-swap	✅	✅	✅	❌
Multi-LoRA batching	✅	✅	✅	❌
Tensor Parallel	✅	✅	✅	✅
Pipeline Parallel	✅	✅	✅	✅
CPU offload	✅	✅	❌	❌

三、生态 & 运维

项	vLLM	SGLang	TRT-LLM	TGI
GitHub Star	30K+	8K+	8K+	8K+
社区活跃度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
学习曲线	简单	中	复杂	简单
编译期	无	无	10-60 分钟/模型	无
Docker 镜像	官方	官方	需自建	官方
K8s Operator	社区多个	少	NVIDIA 官方	HF Inference
稳定性	极高	高	高	中

四、场景匹配矩阵

场景	推荐引擎	备注
通用对话 30B 以内	vLLM	综合最优
通用对话 100B+ FP8	vLLM	H800 上跑 Qwen3 235B / DeepSeek V3
128K 长上下文	SGLang	RadixAttention 显著优势
结构化 JSON 输出	SGLang	Grammar 内建
函数调用密集	SGLang	或 vLLM + outlines
极低延迟（≤ 50ms TTFT）	TensorRT-LLM	但受限模型少
大 batch 离线批处理	vLLM	吞吐王
多 LoRA 混合	vLLM	或 SGLang
Embedding	vLLM 或 TEI	TEI 更轻
视觉（VL 模型）	vLLM	视觉扩展支持最好
音频 TTS/ASR	独立引擎	别硬塞 LLM 引擎

五、Tradeoff 决策表

如果只能选一个，选 vLLM。理由：

覆盖 70%+ 场景
社区最活跃，坑最少
更新最快，新模型 24 小时内适配

如果 vLLM 之外再加一个，选 SGLang。理由：

补长上下文和结构化输出的短板
学习成本可控
与 vLLM 生态兼容

慎选 TensorRT-LLM。理由：

编译期长，模型迭代快时会卡壳
运维复杂，对普通团队负担大
只对特定场景（低延迟小模型）有明显收益
商业级稳定但灵活性差

不选 TGI。理由：

特性落后 vLLM 半年+
HF 已官方推荐迁移到 vLLM
除非已有 HF 生态深度耦合

六、混合部署策略（v2 推荐）

                    请求
                     │
              路由决策
       ┌─────────────┼─────────────┐
       │             │             │
   80% vLLM      15% SGLang    5% TRT-LLM
   (通用)         (长/结构化)   (低延迟)

分工：

vLLM 主力，占 80% 请求
SGLang 处理 128K+ 上下文、JSON Schema、Grammar
TRT-LLM 只跑 1-2 个高频小模型（客服机器人、意图分类）

七、部署最佳实践

vLLM

python -m vllm.entrypoints.openai.api_server \
  --model deepseek-ai/DeepSeek-V3.2 \
  --tensor-parallel-size 8 \
  --enable-prefix-caching \
  --max-model-len 32768 \
  --quantization fp8 \
  --served-model-name deepseek-v3

SGLang

python -m sglang.launch_server \
  --model-path Qwen/Qwen3-72B \
  --tp 4 \
  --context-length 131072 \
  --enable-radix-cache

TensorRT-LLM

提前编译：trtllm-build --checkpoint_dir ...
通过 Triton Inference Server 提供服务
K8s 部署走 NVIDIA GPU Operator + Triton Operator

八、性能优化清单（不分引擎）

量化：FP8（H800/H100）> AWQ（A100）> BF16
Batch size：调到 GPU 显存 90%（OOM 边缘）
Prefix cache：多轮对话 + 共享 system prompt 必开
Chunked prefill：长上下文场景强制开启
Speculative decoding：小模型加速大模型，快 1.5-2×
Tensor Parallel：卡数越多，通信开销越大，别硬堆
KV Cache 显存池：留 30% 显存给 KV
Warmup：服务启动时预推 100 次，避免首个请求慢

九、监控核心指标

指标	说明	目标
`time_to_first_token` (TTFT)	首 token 延迟	P99 < 800ms
`time_per_output_token` (TPOT)	后续 token 时延	< 50ms
`num_running_reqs`	当前并发请求	稳定，不打满
`num_waiting_reqs`	排队请求	长期 = 0
`gpu_kv_cache_usage`	KV Cache 占用	70-90% 最优
`preemption_count`	抢占次数	越少越好
`prefix_cache_hit_rate`	前缀缓存命中率	越高越好

十、常见坑

vLLM 显存 OOM：--gpu-memory-utilization 0.85 别调太高
NCCL 通信卡死：多机 vLLM 需要正确配 NCCL_SOCKET_IFNAME
长请求饿死：调 --max-num-batched-tokens 避免长请求把 batch 塞满
SGLang RadixAttention 效果不好：说明客户请求 prompt 变化太多，换回 vLLM
TRT-LLM 编译失败：CUDA / TensorRT 版本对不上，锁定版本
量化精度差：先跑 eval，某些任务对量化敏感（数学 / 代码）

推理引擎组件对比 · Plan B 附录

On this page