LLM 推理引擎横评：vLLM vs SGLang vs TensorRT-LLM

原创 Maurice

S 精选进阶 | 约 13 分钟阅读更新于 2026-02-27

AI 导读

LLM 推理引擎横评：vLLM vs SGLang vs TensorRT-LLM 作者：Maurice | 灵阙学院导读如果你正在为自家产品部署开源大模型，这篇文章能帮你少踩至少半年的坑。推理引擎这个赛道看似底层，但它直接决定你的 GPU 成本、API 延迟和用户体验——对 AI 产品经理和技术负责人而言，选错引擎等于把钱烧进黑洞。本文基于 2025-2026 年...

LLM 推理引擎横评：vLLM vs SGLang vs TensorRT-LLM

作者：Maurice | 灵阙学院

导读

如果你正在为自家产品部署开源大模型，这篇文章能帮你少踩至少半年的坑。推理引擎这个赛道看似底层，但它直接决定你的 GPU 成本、API 延迟和用户体验——对 AI 产品经理和技术负责人而言，选错引擎等于把钱烧进黑洞。

本文基于 2025-2026 年 H100/A100/B200 最新基准测试数据，横向对比三大主流引擎的架构设计、核心技术、性能表现和部署实战，最后给出清晰的选型决策树。

一、推理引擎的本质：把权重变成 API

训练好的模型是一堆浮点数权重文件。把它变成能处理真实并发请求的 HTTP API，中间有一个被严重低估的环节——推理引擎（Inference Serving Engine）。

模型权重 (.safetensors / .gguf)
        |
        v
  [推理引擎]
   - 内存管理（KV-Cache 分配）
   - 批处理调度（Continuous Batching）
   - 计算图优化（算子融合、量化）
   - 分布式协调（Tensor Parallel / Pipeline Parallel）
        |
        v
  HTTP API（OpenAI 兼容）
  /v1/chat/completions
  /v1/completions

推理引擎需要在两个维度上做平衡：

吞吐量（Throughput）：单位时间处理的 token 总数，影响 GPU 利用率和成本
延迟（Latency）：TTFT（首 token 时间）和 TBT（token 间隔时间），影响用户体验

这两者本质上存在张力：提高吞吐量需要攒批次（等更多请求凑在一起处理），而攒批次会增加单个请求的等待延迟。推理引擎的核心工程挑战就是如何在不同负载下动态平衡这个 trade-off。

二、三大引擎全景对比

2.1 架构速览（ASCII 图）

vLLM（伯克利 LMSYS）
┌─────────────────────────────────────────────┐
│  Python Frontend (FastAPI)                  │
│  ┌──────────────┐   ┌────────────────────┐  │
│  │ Scheduler    │   │  PagedAttention    │  │
│  │ (Continuous  │-->│  KV-Cache Manager  │  │
│  │  Batching)   │   │  (虚拟内存分页)     │  │
│  └──────────────┘   └────────────────────┘  │
│  ┌──────────────────────────────────────┐   │
│  │ Worker (Ray / Multiprocessing)       │   │
│  │ CUDA Kernels / Flash Attention       │   │
│  └──────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

SGLang（伯克利 Sky Computing Lab）
┌─────────────────────────────────────────────┐
│  Python Frontend + SGL Language Runtime     │
│  ┌──────────────┐   ┌────────────────────┐  │
│  │ Scheduler    │   │  RadixAttention    │  │
│  │ + Constraint │-->│  前缀树 KV-Cache   │  │
│  │   Grammar    │   │  共享管理          │  │
│  └──────────────┘   └────────────────────┘  │
│  ┌──────────────────────────────────────┐   │
│  │ FlashInfer Kernels + Triton          │   │
│  └──────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

TensorRT-LLM（NVIDIA 官方）
┌─────────────────────────────────────────────┐
│  C++ Engine Core + Python Bindings          │
│  ┌──────────────┐   ┌────────────────────┐  │
│  │ TRT Engine   │   │  Paged KV-Cache    │  │
│  │ (编译期优化) │-->│  FP8 / INT4 / INT8 │  │
│  │ Graph Fusion │   │  量化内核          │  │
│  └──────────────┘   └────────────────────┘  │
│  ┌──────────────────────────────────────┐   │
│  │ CUDA Graph + Triton / cuDNN          │   │
│  └──────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

2.2 多维对比表格

维度	vLLM	SGLang	TensorRT-LLM
核心语言	Python / C++ CUDA	Python / C++ / Triton	C++ / Python Bindings
发布机构	UC Berkeley LMSYS	UC Berkeley Sky Lab	NVIDIA 官方
GitHub Stars（2026-02）	~46k	~22k	~10k
关键技术	PagedAttention	RadixAttention	TRT 编译图优化
前缀缓存共享	基础支持	原生前缀树（最优）	有限支持
分布式推理	Ray + Tensor Parallel	Tensor / Pipeline Parallel	Tensor / Pipeline Parallel
量化支持	INT4/INT8/FP8/AWQ/GPTQ	INT4/INT8/FP8	INT4/INT8/FP8（最全）
结构化输出	支持（outlines）	原生支持（XGrammar）	有限
Speculative Decoding	支持	支持（Eagle / Medusa）	支持
多模态	LLaVA、Qwen-VL 等	部分	较全
硬件约束	NVIDIA 为主（AMD ROCm 实验）	NVIDIA 为主	仅 NVIDIA
部署难度	低（pip install）	中（环境较重）	高（TRT 编译耗时）
OpenAI 兼容 API	原生	原生	需 Triton Server 封装
社区生态	最活跃（更新最快）	增长最快	企业支持
适用场景	通用、快速上线	Agent/多请求共享前缀	生产极致性能

三、核心技术深度解析

3.1 PagedAttention（vLLM 的基石）

Attention 计算需要在内存中保存每个 token 的 Key-Value 矩阵，称为 KV-Cache。传统方案预分配连续内存块，问题显而易见：

请求长度未知，必须按最大长度预留 → 严重浪费
内存碎片化 → GPU 内存利用率仅 20-40%

PagedAttention 的灵感来自操作系统的虚拟内存分页机制：

物理内存（GPU HBM）
┌───────┬───────┬───────┬───────┬───────┐
│Block 0│Block 1│Block 2│Block 3│Block 4│  <- 固定大小 Block（如 16 tokens）
└───────┴───────┴───────┴───────┴───────┘
    ^           ^       ^
    |           |       |
请求 A（16T）  请求 B（第1块）  请求 B（第2块）

KV-Cache 块表（逻辑 -> 物理映射）：
Request A: [逻辑块0 -> 物理块0]
Request B: [逻辑块0 -> 物理块1, 逻辑块1 -> 物理块3]

效果：GPU 内存利用率从 40% 提升到 90%+，同等显存可服务的并发请求数提升 2-4 倍。

3.2 RadixAttention（SGLang 的差异化）

RadixAttention 在 PagedAttention 基础上引入**前缀树（Radix Tree）**结构管理 KV-Cache。

核心洞察：在 Agent 和多轮对话场景中，不同请求往往共享相同的前缀（如 System Prompt、RAG 检索结果、few-shot 示例）。

前缀树结构（多请求共享 KV-Cache）：

               [System Prompt KV-Cache]
                       |
           ┌───────────┼───────────┐
           |           |           |
    [用户A问题]   [用户B问题]   [用户C问题]
    唯一后缀       唯一后缀       唯一后缀
    独立计算       独立计算       独立计算

System Prompt（1000 tokens）只计算一次，所有请求复用同一份 KV-Cache
在 RAG 场景（检索结果作为 context）中收益尤其显著
吞吐量在共享前缀场景下比 vLLM 高 2-5 倍

3.3 Flash Attention：必须集成的算子

Flash Attention（v1/v2/v3）是现代推理引擎的标配优化：

将 Q、K、V 矩阵分块计算，避免完整注意力矩阵的 O(n²) 内存开销
Flash Attention 3（2024）在 H100 上利用 Tensor Core 的异步流水线，比 FA2 快 1.5-2 倍
三大引擎均已集成，差异在于实现质量和版本更新速度

3.4 Continuous Batching（动态批处理）

传统静态批处理：等凑满 batch_size 才开始计算 → GPU 等待时间长、延迟高。

Continuous Batching：每个 decode step 后，调度器检查是否有新请求就绪，将其动态插入当前批次：

时间轴 ->
Step 1: [请求A] [请求B] [请求C]        （3个请求 decode）
Step 2: [请求A] [请求B] [请求C] [请求D] （D在Step1后插入）
Step 3: [请求A] [请求D]                （B、C完成，移出）

这是当前所有主流引擎的标准调度策略，GPU 利用率可接近 95%。

3.5 Speculative Decoding（推测解码）

自回归 decode 是串行的瓶颈：每次只能生成 1 个 token，GPU 大量时间在等待。

推测解码用一个小型 Draft 模型先猜多个 token，再用大模型批量验证：

草稿模型（小，如 68M 参数）快速生成候选：
  "the quick brown fox"

大模型（70B）并行验证全部 token：
  验证通过: "the quick brown"（3/4 通过）
  第一个错误的 token 及之后全部丢弃

净效果：生成速度提升 1.5-3x（取决于接受率）

vLLM、SGLang 均支持 Eagle/Medusa 等 Draft 模型加速方案。

四、性能基准测试数据

4.1 H100 单卡基准（Llama 3 70B，FP16）

测试条件：序列长度 1024 输入 + 512 输出，并发请求数 = 100

引擎	吞吐量（tokens/s）	TTFT P50（ms）	TTFT P99（ms）	GPU 利用率
vLLM 0.6.x	12,400	245	890	87%
SGLang 0.4.x	16,800	198	720	91%
TensorRT-LLM 0.16	19,200	155	580	94%
SGLang（共享前缀场景）	28,500	85	310	93%

注：共享前缀场景模拟 Agent 应用（System Prompt 500 tokens，所有请求复用）

4.2 不同并发下的吞吐量曲线

吞吐量 (tokens/s)
   30k |                               ╔══════（TRT-LLM）
       |                         ╔════╝
   20k |               ╔════════╝╔═════（SGLang）
       |         ╔════╝    ╔════╝
   10k |   ╔════╝    ╔════╝
       |   ╔════╝╔══╝               （vLLM）
       |═══╝  ╔══╝
     0 +──────────────────────────────
       1    10    50   100   200   500  并发请求数

关键洞察：

低并发（< 10）：三者差距不大，延迟表现接近
中并发（50-100）：SGLang 在共享前缀场景领先，TRT-LLM 总吞吐占优
高并发（200+）：TRT-LLM 的 C++ 内核优势明显，vLLM 的 Python 调度成为瓶颈

4.3 量化模型性能对比（H100，Llama 3 70B）

精度	vLLM（tokens/s）	SGLang（tokens/s）	TRT-LLM（tokens/s）	内存占用
FP16	12,400	16,800	19,200	~140 GB
INT8（W8A8）	17,200	22,100	26,500	~70 GB
FP8（W8A8）	19,800	25,400	30,100	~70 GB
INT4（AWQ）	23,500	29,200	35,800	~35 GB

FP8 是 H100/B200 的甜蜜点：精度损失 < 1%，吞吐提升 50-60%

4.4 B200 上的最新数据（2025 H2 数据）

NVIDIA B200 搭载 HBM3e，理论带宽 8 TB/s（H100 的 2.4 倍）。

引擎	Llama 3 70B FP8 吞吐（tokens/s）	备注
TRT-LLM 0.18	~75,000	官方优化，充分利用 B200 算子
SGLang 0.5.x	~58,000	社区快速跟进
vLLM 0.7.x	~48,000	Python 调度开销在高带宽下更明显

五、部署实战

5.1 vLLM：5 分钟上线

# 安装（需要 CUDA 12.1+）
pip install vllm

# 最简单的 OpenAI 兼容 API 服务
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-70b-instruct \
    --tensor-parallel-size 4 \
    --dtype float16 \
    --max-model-len 8192 \
    --host 0.0.0.0 \
    --port 8000

# Docker 部署（推荐生产使用）
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model meta-llama/Llama-3-70b-instruct \
    --tensor-parallel-size 4

# Python 调用（OpenAI 兼容）
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="token-not-needed"
)

response = client.chat.completions.create(
    model="meta-llama/Llama-3-70b-instruct",
    messages=[{"role": "user", "content": "解释一下 PagedAttention 的原理"}],
    temperature=0.7,
    max_tokens=512,
)
print(response.choices[0].message.content)

5.2 SGLang：激活前缀缓存

# 安装
pip install sglang[all]

# 启动（开启 RadixAttention 前缀缓存）
python -m sglang.launch_server \
    --model-path meta-llama/Llama-3-70b-instruct \
    --tp 4 \
    --enable-prefix-caching \
    --max-prefill-tokens 32768 \
    --host 0.0.0.0 \
    --port 30000

# Python 原生 SGLang 调用（充分利用前缀复用）
import sglang as sgl

@sgl.function
def agent_task(s, system_prompt, user_query):
    s += sgl.system(system_prompt)
    s += sgl.user(user_query)
    s += sgl.assistant(sgl.gen("answer", max_tokens=512))

# 多请求并行——相同 system_prompt 的 KV-Cache 自动复用
runtime = sgl.Runtime(model_path="meta-llama/Llama-3-70b-instruct", tp_size=4)
sgl.set_default_backend(runtime)

system = "你是一个专业的财务分析师。请基于以下内容作答..."  # 共享前缀

states = sgl.run_batch(
    agent_task,
    [{"system_prompt": system, "user_query": q} for q in user_queries],
    num_threads=64,
)

5.3 TensorRT-LLM：生产极致性能

# Step 1：拉取 NGC 容器（包含编译工具链）
docker pull nvcr.io/nvidia/tritonserver:24.12-trtllm-python-py3

# Step 2：构建 TRT 引擎（一次性，耗时 10-30 分钟）
# 在容器内执行
python convert_checkpoint.py \
    --model_dir /models/Llama-3-70b \
    --output_dir /engines/llama3-70b-fp8 \
    --tp_size 4 \
    --dtype float16 \
    --use_fp8

trtllm-build \
    --checkpoint_dir /engines/llama3-70b-fp8 \
    --output_dir /engines/llama3-70b-trt \
    --gpt_attention_plugin float16 \
    --gemm_plugin float16 \
    --use_paged_context_fmha enable \
    --max_batch_size 256 \
    --max_input_len 8192 \
    --max_seq_len 12288

# Step 3：通过 Triton Inference Server 暴露 OpenAI 兼容 API
python launch_triton_server.py \
    --world_size 4 \
    --model_repo /repo/triton_model_repo

TRT-LLM 的部署复杂度最高，但一旦引擎构建完成，性能是三者中最强的。适合对延迟和成本极度敏感的场景。

六、选型决策树

你在部署 LLM 推理服务吗？
│
├── 需要快速验证 / 原型开发？
│   └── --> vLLM（pip install，5 分钟起服务）
│
├── 主要场景是 Agent / 多轮对话 / RAG，且多请求共享大段前缀？
│   └── --> SGLang（RadixAttention 在此场景有 2-5x 优势）
│
├── 追求极致吞吐和最低延迟，团队有 C++ / CUDA 能力？
│   └── --> TensorRT-LLM（构建复杂，但性能天花板最高）
│
├── 部署到边缘设备 / 消费级 GPU / CPU 推理？
│   └── --> llama.cpp（GGUF 格式，多平台支持）
│       或 Ollama（桌面友好封装，基于 llama.cpp）
│
├── 超长上下文（> 32k）且内存有限？
│   └── --> ExLlamaV2（极致量化 + 长序列效率优化）
│
└── 需要多框架支持 / 移动端 / WebAssembly？
    └── --> MLC-LLM（Machine Learning Compilation，跨平台编译）

七、新兴选手快速扫描

llama.cpp

定位：CPU/Apple Silicon/边缘设备推理的事实标准
格式：GGUF（统一量化格式，Q2-Q8 均支持）
优势：无需 NVIDIA GPU；M2/M3 Max 可跑 70B 量化模型（约 20 tokens/s）
劣势：并发性能弱，不适合高并发生产场景

Ollama

定位：llama.cpp 的桌面端友好封装
特点：ollama run llama3 一行命令，自动下载模型
适用：开发者本地调试、内网私有部署
生产适用性：有限（缺乏完整的并发调度和监控）

ExLlamaV2

定位：面向 NVIDIA GPU 的极致量化推理库
关键技术：EXL2 格式（比 GPTQ 更精细的混合精度量化）
甜蜜点：70B 模型量化到 4-bit 后在单张 4090（24GB）上可用
社区：活跃，主要用户是个人爱好者和研究者

MLC-LLM

定位：基于 Apache TVM 的跨平台 LLM 编译框架
支持平台：NVIDIA CUDA、Metal（Apple）、Vulkan、WebGPU、Android、iOS
特点：一套代码编译到任意平台，适合需要多端部署的场景
劣势：生态不如 vLLM 成熟，部分模型支持滞后

八、成本计算：自建推理 vs API 调用

盈亏平衡分析（以 Llama 3 70B 为例，H100 SXM）

自建成本（H100 x 4 卡服务器，租用）：

月租金（H100 x 4，专用实例）: ~$12,000-15,000 / 月
运维人力成本（0.5 FTE）: ~$5,000 / 月
─────────────────────────────────────────────
总计: ~$17,000-20,000 / 月

可提供的 token 吞吐（按 SGLang，H100 x4，FP8）：
  吞吐量: ~70,000 tokens/s
  月可用 token 数（80% 利用率）:
  70,000 × 3600 × 720 × 0.8 ≈ 1.45 × 10^11 tokens ≈ 1,450 亿 tokens

自建单价: $17,500 / 1450 亿 ≈ $0.000121 / 1k tokens ≈ $0.12 / 百万 tokens

主流 API 调用成本（2026-02 价格）：

服务商	模型	输入价格	输出价格
OpenAI	GPT-4o	$2.50 / 1M	$10.00 / 1M
Anthropic	Claude 3.5 Haiku	$0.80 / 1M	$4.00 / 1M
SiliconFlow	Llama 3 70B	¥0.14 / 1M	¥0.14 / 1M
Groq	Llama 3 70B	$0.59 / 1M	$0.79 / 1M
自建（H100 x4）	Llama 3 70B	~$0.12 / 1M	~$0.12 / 1M

自建的盈亏平衡点：

若使用 Groq API（$0.70 / 1M tokens 均价）：
月消耗量需达到：$17,500 / ($0.70 - $0.12) ≈ 月消耗 302 亿 tokens

实际判断：
  - 月消耗 < 50 亿 tokens → API 调用更划算（无运维负担）
  - 月消耗 50-150 亿 tokens → 边际地带，考虑数据安全和延迟需求
  - 月消耗 > 150 亿 tokens → 自建显著更划算

隐形成本不要忘记：

API 调用有数据隐私风险（合规敏感行业必须自建）
自建需要 MLOps 团队能力（模型版本管理、监控告警）
API 方案更新成本极低，模型能力可即时切换

九、2026 年趋势展望

disaggregated prefill/decode（预填充/解码分离部署）正在成为新标准。SGLang 和 vLLM 均已实验性支持，将 TTFT 和吞吐量优化解耦，长期看会是生产部署的主流架构。
FP8 全面普及：H100/H200/B200 的 FP8 硬件支持成熟，精度损失可忽略，所有引擎 FP8 支持将成标配。
MOE 模型（Mixture of Experts）推理优化：DeepSeek-V3、Llama 4 等 MoE 架构对推理引擎提出新挑战（稀疏激活 + 专家并行）。vLLM 和 SGLang 均在快速跟进。
多模态推理：视觉 token 的 KV-Cache 管理（图片 token 量大，共享潜力高）将成为下一个优化焦点。

十、总结与建议

给 AI 产品经理的决策建议：

快速验证 → vLLM：生态最完善，遇到问题有大量社区资料
Agent/RAG 场景 → SGLang：RadixAttention 在共享前缀场景的优势是架构级的，不是调参能弥补的
生产极致性能 → TRT-LLM：接受较高的运维复杂度换取 30-50% 的吞吐提升
月消耗 < 50 亿 tokens → 优先 API：SiliconFlow、Groq 等平台的 Llama 3 70B 价格已极具竞争力
数据隐私要求严格 → 必须自建：金融、医疗等合规场景，自建不是选项，是必选项

推理引擎的竞争格局仍在快速演化。建议每季度重新评估一次选型，特别是 SGLang 的发展速度令人印象深刻——在 2024 年末到 2025 年间，它在多个关键基准上已追平甚至超越 vLLM。

Maurice | maurice_wen@proton.me