LLM 推理引擎对比与选型

推理引擎是”把模型跑起来”的发动机。选错引擎，可能同样的 GPU 吞吐差 3-5 倍。本文横向对比主流引擎的设计取向、强项与适用场景，给出选型决策表。

---

一、为什么需要专用推理引擎

朴素部署（HuggingFace model.generate()）的问题：

• 无 PagedAttention：KV Cache 连续分配，长序列碎片严重，并发上不去
• 静态 Batching：必须整批凑齐才能跑，短请求被长请求拖死（head-of-line blocking）
• 无 CUDA Graph / 算子融合：kernel launch 开销大
• 单卡思维：多卡、多机、MoE 路由都要自己写

专用引擎就是为了解决这四点。

---

二、主流引擎矩阵

引擎	主导方	核心卖点	最强场景	语言/生态
vLLM	UC Berkeley / 社区	PagedAttention 鼻祖、生态最全、OpenAI API 兼容	通用、高并发在线服务	Python
SGLang	SGLang 团队	RadixAttention(前缀复用)、结构化输出快、高吞吐	长上下文/多轮 Agent/JSON 输出	Python
TensorRT-LLM	NVIDIA	极致 kernel 优化、CUDA Graph、低延迟	NVIDIA 硬件上的最低 TPOT	C++/Python
LMDeploy	上海AI实验室	TurboMind 引擎、量化友好、国产卡适配	国产卡/量化部署	Python
Ollama	Ollama	一键本地、模型库丰富、开发者友好	本地开发/笔记本/Apple Silicon	Go
llama.cpp	ggerganov	GGUF 量化、纯 CPU/端侧、无 GPU 依赖	端侧/边缘/老机器	C++
Triton IS	NVIDIA	多框架统一、动态批处理、企业级	多模型混合推理平台	C++/Python
Ray Serve	Anyscale	通用 Python 服务、复杂路由/组合	自研编排/多模型 pipeline	Python
DeepSpeed-MII	Microsoft	与 DeepSpeed 训练打通	训练集群顺手部署	Python

---

三、关键能力对比

能力	vLLM	SGLang	TRT-LLM	Ollama/llama.cpp
PagedAttention	✅	✅(RadixAttention)	✅(paged KV)	⚠️(llama.cpp 有 KV 缓存)
Continuous Batching	✅	✅	✅	⚠️ 弱
前缀缓存复用	✅(自动)	✅(Radix 树共享)	✅	❌
投机解码	✅	✅	✅	✅(llama.cpp)
张量并行(多卡)	✅	✅	✅	⚠️(有限)
MoE 优化	✅	✅(强)	✅	⚠️
量化(AWQ/GPTQ/FP8)	✅	✅	✅	✅(GGUF)
OpenAI API 兼容	✅	✅	⚠️(需适配)	✅(Ollama)
国产卡(昇腾/海光)	⚠️	⚠️	❌	⚠️(llama.cpp)

---

四、选型决策表

场景 → 推荐
─────────────────────────────────────────────────
本地开发 / 笔记本 / Apple Silicon      → Ollama 或 llama.cpp
端侧 / 边缘设备 / 无 GPU              → llama.cpp (GGUF)
通用在线服务 / 高并发 / 快速验证     → vLLM（默认首选）
长上下文 / 多轮 Agent / 大量 JSON    → SGLang（前缀复用省显存）
极致低延迟 / 全 NVIDIA / 已上 TRT    → TensorRT-LLM
国产算力卡 / 量化优先                → LMDeploy
企业多模型统一平台                  → Triton + (vLLM/SGLang 后端)
自研复杂编排 / 多模型 pipeline       → Ray Serve

经验法则：没有特殊诉求时，vLLM 是安全默认；当你发现账单里”重复 prefill 长 prompt”占比高、或多轮对话 KV 反复算，切 SGLang 常常立省 30-50% 显存。

---

五、vLLM 启动示例（最常用）

# 单卡起 7B，OpenAI 兼容端口 8000
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768 \
  --enable-prefix-caching \
  --port 8000

# 调用（与 OpenAI SDK 完全一致）
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"你好"}]}'

---

六、SGLang 启动示例（强调前缀复用）

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --tp 1 \
  --mem-fraction-static 0.85 \
  --enable-radix-cache \
  --port 30000
# RadixAttention 自动在多请求间共享相同 prompt 前缀的 KV

---

七、引擎不是银弹：硬件仍是天花板

无论选哪个引擎，单请求延迟最终受限于：

1. 显存带宽（decode 是访存密集，HBM 带宽决定 TPOT 下限）
2. 算力峰值（prefill 是算力密集，FLOPS 决定长 prompt 的 TTFT）
3. 多卡互联（张量并行跨卡要看 NVLink/PCIe 带宽）

引擎解决的是”软件利用率”，硬件决定”物理上限”。当 TPOT 卡在某个值上不去，先看 HBM 带宽是否被 KV Cache 读满——这正是 KV Cache 原理与 PagedAttention 要讲的。

---

关联知识

• LLM 推理服务化知识总览 — 本系列定位与指标
• KV Cache 原理与 PagedAttention — 引擎性能差异的底层来源
• 高并发调度与吞吐优化 — Continuous Batching / 投机解码如何进一步拉吞吐
• ../llm-training/大模型架构对比 — MoE/MLA/GQA 影响引擎实现复杂度
• ../gpu-cluster-ops/hardware/NVIDIA GPU 架构演进 — HBM 带宽与算力上限

参考资源

• vLLM GitHub
• SGLang GitHub
• TensorRT-LLM GitHub

学习时间

阶段	时间	备注
内容创建	2026-07-20	引擎对比矩阵、选型决策表、vLLM/SGLang 启动样例

状态标记

📖 已掌握 — 主流引擎定位、能力对比、按场景选型 📝 待补充 — 各引擎实测吞吐数字、TRT-LLM 构建流程、国产卡实测