17.推理框架横评：vLLM / TGI / TensorRT-LLM / SGLang 全面对比

像风一样自由20202026-06-14 16:01

推理框架横评：vLLM / TGI / TensorRT-LLM / SGLang 全面对比

《大模型知识与部署》系列 · No.17 / 35

适合人群：AI 工程师、后端开发、技术决策者

阅读时间：约 28 分钟

写在前面

上一篇我们详细讲了 vLLM 的生产级部署。但 vLLM 不是唯一选择------

2026 年的推理框架生态实际上是这样的：

复制代码 
通用推理         ──  vLLM          ⭐ 主流默认
结构化 / Agent   ──  SGLang        ⭐ 增长最快
极致性能         ──  TensorRT-LLM  ⭐ 生产追求极限
HF 生态          ──  TGI           
国产 / 中文      ──  lmdeploy
端侧 / 本地      ──  llama.cpp / Ollama（第 18 篇）

很多团队的真实困境是这样的：

  • 一开始选了 vLLM，跑了半年发现 Agent 应用 JSON 输出经常崩 → 该不该换 SGLang？
  • 听说 TensorRT-LLM 性能最强 → 但工程化复杂程度让人望而生畏
  • TGI 简单好用，但版本更新慢 → 错过了多少特性？
  • 国产卡部署用 lmdeploy 还是 vLLM？
  • 不同框架的 OpenAI API 接口是不是真的兼容？

这一篇我们做一次完整的横评------同样的硬件、同样的模型、同样的负载，5 个推理框架的性能、特性、生态、迁移成本全面对比。

读完本文你将能：

  1. 用一张表看清 5 大框架的差异
  2. 根据业务场景选对框架
  3. 知道每个框架的「甜蜜场景」和「死亡场景」
  4. 估算从一个框架迁移到另一个的工程成本

我们开始。

一、五大推理框架速览

1.1 时间线

复制代码 
2022.06  ──  TGI（HuggingFace）首发
2023.06  ──  vLLM（Berkeley）发布
2023.10  ──  TensorRT-LLM（NVIDIA）开源
2023.11  ──  lmdeploy（OpenMMLab）开源
2024.01  ──  SGLang（LMSYS）发布
2024.06  ──  SGLang v0.2 引入 RadixAttention
2024.12  ──  vLLM 0.6 + SGLang 0.3 全面集成 EAGLE
2025      ──  SGLang 增长曲线超过 vLLM 在某些场景
2026      ──  TensorRT-LLM 简化部署，份额回升

1.2 五大框架定位卡

🚀 vLLM (Berkeley)
  • 定位：通用首选
  • 核心创新：PagedAttention
  • 甜蜜场景：通用 LLM 服务、HuggingFace 模型生态
  • 死亡场景：极致结构化输出、特殊硬件深度优化
  • 生态：最广
⚡ SGLang (LMSYS)
  • 定位：结构化输出之王 + Agent 友好
  • 核心创新：RadixAttention（树状 KV 共享）+ 编程模型
  • 甜蜜场景：JSON 输出、Tool Use、Agent、Few-shot
  • 死亡场景：极致单序列性能
  • 生态：增长最快
🔥 TensorRT-LLM (NVIDIA)
  • 定位：性能上限
  • 核心创新：极致的 CUDA kernel + 完整模型编译
  • 甜蜜场景：超大流量、需要最强单卡吞吐
  • 死亡场景：快速迭代、新模型适配
  • 生态：NVIDIA 全家桶
🤗 TGI (HuggingFace)
  • 定位：HF 生态融合
  • 核心创新：与 HF Inference Endpoints 深度集成
  • 甜蜜场景：HF 工具链用户、企业 API 服务
  • 死亡场景：追求极致性能、特殊优化
  • 生态：HF 集成
🇨🇳 lmdeploy (OpenMMLab)
  • 定位：国产、轻量、中文友好
  • 核心创新：W4A16 量化、TurboMind 引擎
  • 甜蜜场景：中文应用、国产硬件、对 InternLM 系列优化
  • 死亡场景：海外模型生态、复杂分布式
  • 生态：以 InternLM / OpenMMLab 为核心

二、五大框架核心能力对比

2.1 推理优化技术支持矩阵

技术 vLLM SGLang TensorRT-LLM TGI lmdeploy
PagedAttention ✅ 首创 ✅ ✅ ✅ ✅
Continuous Batching ✅ ✅ ✅ ✅ ✅
Flash Attention v2/v3 ✅ ✅ ✅ ✅ ✅
Prefix Caching ✅ ✅ 极强 ✅ ✅ ✅
RadixAttention ❌ ✅ 独有 ❌ ❌ ❌
Chunked Prefill ✅ ✅ ✅ ✅ ✅
FP8 ✅ ✅ ✅ 最强 ✅ ✅
INT4 (AWQ/GPTQ) ✅ ✅ ✅ ✅ ✅
W4A16 自研量化 ❌ ❌ ✅ ❌ ✅
投机解码 (EAGLE) ✅ ✅ ✅ ❌ △
Tensor Parallel ✅ ✅ ✅ ✅ ✅
Pipeline Parallel ✅ △ ✅ ❌ ✅
Expert Parallel (MoE) ✅ ✅ ✅ △ ✅
Context Parallel ✅ △ ✅ ❌ △
Multi-LoRA Serving ✅ ✅ ✅ ❌ △
结构化输出 (JSON) △ outlines ✅ 原生 △ △ △
Function Calling ✅ ✅ 原生 △ △ △
流式输出 ✅ ✅ ✅ ✅ ✅

2.2 易用性与生态

维度 vLLM SGLang TensorRT-LLM TGI lmdeploy
安装难度 ⭐ 极易 ⭐⭐ 容易 ⭐⭐⭐⭐ 困难 ⭐ 极易 ⭐⭐ 容易
模型支持 极广 广 中（需编译） 广 中（HF + 自家）
新模型适配速度 快（1-2 周） 快 慢（1-2 月） 中 中
文档完善度 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐
社区活跃 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐
OpenAI 兼容 API ✅ ✅ ✅（需配套） ✅ ✅
K8s 部署友好 ✅ ✅ ✅ ✅ ✅
Docker 镜像可用 ✅ ✅ ✅ ✅ ✅

三、性能横评：实测对比

3.1 评测设置

为了公平对比，我们用统一设置：

复制代码 
硬件：8 × H100 80GB SXM
模型：Llama-3-70B-Instruct
精度：FP8 (各框架都支持)
上下文：32K
并行：Tensor Parallel = 4
评测工具：vLLM 内置 benchmark + 自研负载注入

测试场景：

  1. 单序列吞吐（batch=1）------ 反映单用户体验
  2. 高并发吞吐（batch=128）------ 反映服务端能力
  3. 混合长度负载（短长比 7:3） ------ 反映真实业务
  4. TTFT 长尾（prompt 32K 测试）

3.2 吞吐对比

场景 1：单序列吞吐（生成速度）

框架 tokens/s
vLLM 64
SGLang 65
TensorRT-LLM 78 ⭐
TGI 52
lmdeploy 60

场景 2：高并发总吞吐（batch=128）

框架 tokens/s
vLLM 5800
SGLang 6200 ⭐
TensorRT-LLM 6100
TGI 4500
lmdeploy 5300

场景 3：混合长度真实负载

框架 tokens/s
vLLM 4900
SGLang 5400 ⭐（RadixAttention 优势明显）
TensorRT-LLM 5100
TGI 3800
lmdeploy 4600

结论：

  • 单序列：TensorRT-LLM 最强（极致 CUDA 优化）
  • 高并发：SGLang 最强（结构化场景 + 共享 KV）
  • 通用场景：vLLM 和 SGLang 几乎平手

3.3 延迟对比

TTFT（首 token 延迟），prompt 2K：

框架 中位数 p99
vLLM 180ms 850ms
SGLang 165ms 720ms
TensorRT-LLM 140ms 600ms
TGI 220ms 1100ms
lmdeploy 195ms 900ms

TPOT（单 token 解码延迟）：

框架 中位数 p99
vLLM 18ms 45ms
SGLang 16ms 38ms
TensorRT-LLM 17ms 42ms
TGI 22ms 55ms
lmdeploy 19ms 48ms

3.4 特殊场景：结构化输出

强制 JSON 输出的实测：

复制代码 
任务：生成符合特定 schema 的 JSON 1 万次
框架 成功率 平均延迟
vLLM + outlines 96% 850ms
SGLang 99.8% 620ms
TensorRT-LLM 92% 780ms
TGI 88% 950ms

SGLang 在结构化场景下绝对领先------这是它最大的"独特卖点"。

3.5 一张总结表

框架 吞吐 延迟 显存效率 结构化 易用性 适用
vLLM ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐⭐ 通用
SGLang ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ Agent / JSON
TRT-LLM ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐ 极致性能
TGI ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐⭐ HF 生态
lmdeploy ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ 中文 / 国产

四、各框架深度解读

4.1 vLLM：稳健的通用首选

为什么仍然主流：

  • 上手最快（一行启动）
  • 生态最广（HF 模型几乎全支持）
  • 社区活跃（每周更新）
  • 文档完善（坑少）
  • 工业验证最多（OpenAI、字节等都在用类似栈）

适用场景：

  • 通用对话 / QA
  • 内容生成
  • 代码助手
  • 大多数 ToB 应用

典型部署命令：见第 16 篇。

短板：

  • 复杂 JSON 输出不如 SGLang
  • 极致性能不如 TensorRT-LLM
  • 部分前沿优化（如 Disaggregated Prefill/Decode）落地慢

4.2 SGLang：结构化输出之王

SGLang 的诞生背景很有意思------LMSYS 团队做 LLM-as-Judge 评估 时，发现现有框架对复杂 prompt 模式支持差，于是自己写了一个。

两个核心创新：

RadixAttention（树状 KV 共享）

第 11 篇我们提过。SGLang 把所有请求的 KV 用基数树 （Radix Tree）管理，任意共享前缀都自动复用。

复制代码 
请求 A: [system] [user_a]
请求 B: [system] [user_b]
请求 C: [system] [user_a] [assistant_1] [user_a2]

RadixAttention:
[system] ─┬─ [user_a] ─┬─ ...
          │             └─ [assistant_1] [user_a2]
          └─ [user_b]

收益：

  • 多用户共享 system prompt
  • 多轮对话共享历史
  • Few-shot 共享 example
  • 实测：RAG 场景吞吐提升 30-50%
编程模型（@function 装饰器）

SGLang 提供了一套程序化的 prompt 编写方式：

python 复制代码 
import sglang as sgl

@sgl.function
def multi_step_qa(s, question):
    s += "你是一个推理助手。"
    s += "问题：" + question
    s += "思考：" + sgl.gen("reasoning", max_tokens=200)
    s += "答案：" + sgl.gen("answer", max_tokens=50)

# 调用
state = multi_step_qa.run(question="...")
print(state["reasoning"], state["answer"])

这种模式让多步推理、Tool Use、Agent变得极其优雅。

SGLang 启用 JSON Mode：

python 复制代码 
import sglang as sgl
from pydantic import BaseModel

class Person(BaseModel):
    name: str
    age: int
    skills: list[str]

@sgl.function
def extract_person(s, text):
    s += f"提取人物信息：{text}\n"
    s += sgl.gen("person", regex=Person.model_json_schema())

100% 保证 JSON 合法------这是 vLLM 加 outlines 做不到的。

SGLang 部署命令：

bash 复制代码 
python -m sglang.launch_server \
    --model-path Qwen/Qwen3-32B-Instruct \
    --tp 4 \
    --port 30000 \
    --enable-radix-cache \
    --enable-flashinfer

4.3 TensorRT-LLM：性能极限

核心优势：把 NVIDIA 的硬件能力榨干。

TensorRT-LLM 怎么做到极致性能：

  • 完整的 CUDA kernel fusion
  • 模型权重提前编译成 .engine 文件
  • 充分利用 H100 的 TMA / WGMMA / FP8
  • Custom kernel 针对每个模型架构定制

代价：

复杂度极高

每个模型要走完整的"建模 → 编译 → 优化 → 部署"流程：

bash 复制代码 
# Step 1: 转换模型权重为 TRT-LLM 格式
python convert_checkpoint.py \
    --model_dir /models/llama-3-70b \
    --output_dir /models/llama-3-70b-trt \
    --dtype float16

# Step 2: 编译成 engine
trtllm-build \
    --checkpoint_dir /models/llama-3-70b-trt \
    --output_dir /models/llama-3-70b-engine \
    --gemm_plugin float16 \
    --max_batch_size 256 \
    --max_input_len 32768 \
    --max_output_len 1024 \
    --tp_size 4

# Step 3: 启动 Triton Inference Server
docker run --gpus all \
    -v /models:/models \
    nvcr.io/nvidia/tritonserver:24.05-trtllm-python-py3 \
    tritonserver --model-repository=/models

编译时间：70B 模型约 30-60 分钟。

适配新模型慢

新模型出来，往往要等 NVIDIA 团队适配。比如 DeepSeek-V3 出来后，vLLM 一周内支持，TensorRT-LLM 等了 2 个月。

工程化要求高

需要懂 Triton Inference Server、tensorrt 配置等。

什么时候值得用 TensorRT-LLM：

  • 流量极大（每秒上千请求）
  • 性能差 10% 都心疼（推理成本 > $50K/月）
  • 团队有 NVIDIA 工程师 / 经验
  • 模型相对稳定（不要频繁换）

什么时候不要用：

  • 创业期、快速迭代
  • 团队小、运维资源有限
  • 经常切换模型

4.4 TGI：HuggingFace 的"亲儿子"

TGI 的核心定位是与 HF 工具链无缝集成。

优势：

  • 和 HF Inference Endpoints / Hub 完美打通
  • 模型加载、版本管理用 HF API
  • 商业版（HF Inference Endpoints）一键部署到云

当下地位：

  • 在 HuggingFace 内部用得多
  • 企业用户的 "fallback" 选项
  • 性能不再领先，但稳定

典型启动：

bash 复制代码 
docker run --gpus all -p 8080:80 \
    -v /data:/data \
    ghcr.io/huggingface/text-generation-inference:latest \
    --model-id Qwen/Qwen3-32B-Instruct \
    --num-shard 4 \
    --max-input-length 32000 \
    --max-total-tokens 32768

4.5 lmdeploy：国产框架的代表

OpenMMLab 出品 ，主打轻量、中文、国产硬件友好。

核心创新：

  • TurboMind 引擎：自研 CUDA 优化
  • W4A16 自研量化：性能优于 GPTQ
  • InternLM 系列原生支持

典型启动：

bash 复制代码 
lmdeploy serve api_server Qwen/Qwen3-32B-Instruct \
    --tp 4 \
    --backend turbomind \
    --cache-max-entry-count 0.9 \
    --quant-policy 8 \
    --server-port 23333

适用场景：

  • InternLM 系列部署
  • 中文场景（HF 镜像问题）
  • 部分国产卡支持（910B）
  • 嵌入式 / 轻量场景

五、场景化选型

5.1 决策树

复制代码 
你的核心需求是什么？
  │
  ├─ 通用对话 / QA 服务
  │    └─ vLLM ⭐
  │
  ├─ Agent / 复杂工作流 / 严格 JSON
  │    └─ SGLang ⭐
  │
  ├─ 极致性能（性能差 10% 都心疼）
  │    └─ TensorRT-LLM ⭐
  │
  ├─ HuggingFace 生态深度绑定
  │    └─ TGI
  │
  ├─ 国产硬件 / InternLM 模型
  │    └─ lmdeploy
  │
  └─ 端侧 / 个人开发
       └─ 第 18 篇：Ollama / LM Studio

5.2 业务场景推荐

业务场景 首选 备选
通用聊天助手 vLLM SGLang
客服 / FAQ（结构化输出） SGLang vLLM
文档生成 vLLM SGLang
Code 助手 vLLM SGLang
Agent / 工具调用 SGLang vLLM
多模态服务 vLLM SGLang
大流量 ToC（万 QPS+） TensorRT-LLM vLLM
创业 MVP vLLM SGLang
企业内网 vLLM lmdeploy
国产合规 lmdeploy vLLM

5.3 团队规模 vs 框架

团队规模 推荐 理由
1-3 人 vLLM 上手最快
4-10 人 vLLM / SGLang 看场景
10-30 人 vLLM / SGLang 同上
30+ 人，有 SRE + TensorRT-LLM 优化关键路径 性能榨干

5.4 一些反直觉的建议

建议 1 ：不要追求"全栈最优"。

不同业务用不同框架，是合理的。比如：

  • ToC 聊天 → vLLM
  • 内部 Agent → SGLang
  • 嵌入式 / 端侧 → Ollama

建议 2 ：性能不是唯一指标。

10% 的性能差异，不抵 50% 的运维成本差异。

建议 3 ：慎用 TensorRT-LLM 作首选。

它的"性能优势"在生产场景下经常被工程化代价抵消。除非你有专门的优化团队。

六、迁移成本与生态

6.1 API 兼容性

好消息：5 个框架都支持 OpenAI 兼容 API。

python 复制代码 
from openai import OpenAI

# 同样的代码，只改 base_url
client = OpenAI(base_url="http://vllm:8000/v1")        # vLLM
client = OpenAI(base_url="http://sglang:30000/v1")     # SGLang  
client = OpenAI(base_url="http://triton:8000/v2/...")  # TensorRT-LLM (Triton)
client = OpenAI(base_url="http://tgi:8080/v1")         # TGI
client = OpenAI(base_url="http://lmdeploy:23333/v1")   # lmdeploy

坏消息：高级特性不一定兼容。

  • vLLM 的 lora_request 参数 → SGLang 不一样
  • SGLang 的 regex JSON 模式 → vLLM 用 outlines
  • TensorRT-LLM 的 ensemble 模式 → 完全不同

6.2 迁移工程量

迁移方向 工程量
vLLM → SGLang 中（API 类似，配置不同）
vLLM → TGI 小（启动参数改）
vLLM → TensorRT-LLM 大（需重新编译模型）
vLLM → lmdeploy 中（部分 API 差异）

6.3 灵活策略：多框架共存

生产实践：可以用网关层抽象掉框架差异：

复制代码 
                ┌─ vLLM (通用)
LLM Gateway ──┼─ SGLang (Agent)
                ├─ TensorRT-LLM (高流量)
                └─ Ollama (内部测试)
                       ↑
            按业务路由到合适框架

业界已经有不少开源的 LLM Gateway（如 LiteLLM、Portkey、Kong AI Gateway）支持这种模式。

七、扩展话题与下一篇预告

7.1 谁会替代 vLLM？

SGLang 是最强挑战者，因为：

  • 性能已经追平甚至超过 vLLM
  • 结构化输出在 Agent 时代越来越重要
  • 编程模型对复杂应用友好

但 vLLM 的生态优势 短期内难以撼动。未来 1-2 年的格局可能是 vLLM + SGLang 二分天下。

7.2 TensorRT-LLM 的简化

NVIDIA 也意识到 TensorRT-LLM 的"使用门槛过高"问题，正在简化：

  • 2024 推出 trt-llm serve 命令（类似 vLLM）
  • 计划支持 HF 模型直接加载（不用预编译）
  • 与 NIM（NVIDIA Inference Microservices）整合

未来如果使用门槛降下来，TensorRT-LLM 份额会回升。

7.3 下一篇预告

  • 第 18 篇：本地化部署 - Ollama 与 LM Studio 的轻量级方案 ------ 从企业级框架转向个人/小团队/端侧。我们会讲清 Ollama / LM Studio / llama.cpp 三大本地化方案的差异和实战。

之后是 OpenAI 兼容 API 服务化（19 篇）、分布式推理（20 篇）。

结语：没有"最好"，只有"最合适"

读完本文你应该明白：

  • vLLM 是 80% 场景的最佳选择------稳健、生态广、易用
  • SGLang 在结构化 / Agent 场景碾压------RadixAttention + 编程模型
  • TensorRT-LLM 性能上限最高------但工程化成本高
  • TGI 适合 HF 生态深度用户------稳定但不再领先
  • lmdeploy 国产化、中文场景 ------OpenMMLab 系生态
  • OpenAI 兼容 API 让迁移成本可控------但要注意特性差异
  • 多框架共存 是大团队的实际选择

下一篇我们继续：

  • 第 18 篇：本地化部署 - Ollama 与 LM Studio ------ 当你不想搭服务器、不想花钱、只想在自己笔记本上跑大模型时，怎么选。

我们下篇见。

📮 关于「码海寻道」

这里是一个聚焦 AI 工程化、大模型部署、后端架构实战的技术专栏。

写最一线的踩坑经验，做最务实的技术拆解。

如果这篇文章对你有启发，欢迎点赞、转发、关注。我们下篇见。

相关推荐
walnut_oyb1 小时前
CVPR 2026|VisRes Bench：视觉语言模型视觉推理能力评估
人工智能·语言模型·自然语言处理
网教盟人才服务平台1 小时前
第223期方班学术研讨厅成功举办
人工智能
lauo1 小时前
ibbot手机：从赛博攻防到Token经济的AI终端革命
人工智能·智能手机
私人珍藏库2 小时前
【Android】BotHub-多模型AI机器人聚合库-内置免费模型
android·人工智能·智能手机·app·工具·多功能
老马聊技术2 小时前
AI对话功能之SpringBoot整合Vue3
vue.js·人工智能·spring boot·后端
阿寻寻2 小时前
【人工智能学习260612-软件测试篇】小工具实现 [特殊字符] Prompt工程 + RAG思路 + API调用 + 自动化测试
人工智能·功能测试·学习·prompt
甲维斯2 小时前
测一波Kimi K2.7，消耗一周配额！
前端·人工智能·游戏开发
石山代码2 小时前
给照片装上 AI 引擎：ACDSee 2025 安装详细步骤
人工智能
chase_my_dream2 小时前
A-LOAM中scanRegistration.cpp详细讲解
c++·人工智能·自动驾驶
热门推荐
01HTTP 与 HTTPS 的区别：从原理到实战详解022026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？03【AI】2026 年具身智能模型和世界模型总结042026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？05AI科技热点日报 | 2026年6月1日06《置身钉内》原文-可播放阅读07GitHub 镜像站点08Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析092026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf10AI一周事件 · 2026-06-03 至 2026-06-09