【学习笔记】推理框架横评：vLLM / TGI / TensorRT-LLM / SGLang 全面对比（17/35）

上一篇我们详细讲了 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 五大框架定位卡

1.2.1 🚀 vLLM (Berkeley)

• •定位：通用首选

• •核心创新：PagedAttention

• 甜蜜场景：通用 LLM 服务、HuggingFace 模型生态

• 死亡场景：极致结构化输出、特殊硬件深度优化

• 生态：最广

1.2.2 ⚡ SGLang (LMSYS)

• 定位：结构化输出之王 + Agent 友好

• 核心创新：RadixAttention（树状 KV 共享）+ 编程模型

• 甜蜜场景：JSON 输出、Tool Use、Agent、Few-shot

• 死亡场景：极致单序列性能

• 生态：增长最快

1.2.3 🔥 TensorRT-LLM (NVIDIA)

• 定位：性能上限

• 核心创新：极致的 CUDA kernel + 完整模型编译

• 甜蜜场景：超大流量、需要最强单卡吞吐

• 死亡场景：快速迭代、新模型适配

• 生态：NVIDIA 全家桶

1.2.4 🤗 TGI (HuggingFace)

• 定位：HF 生态融合

• 核心创新：与 HF Inference Endpoints 深度集成

• 甜蜜场景：HF 工具链用户、企业 API 服务

• 死亡场景：追求极致性能、特殊优化

• 生态：HF 集成

1.2.5 🇨🇳 lmdeploy (OpenMMLab)

• 定位：国产、轻量、中文友好

• •核心创新：W4A16 量化、TurboMind 引擎

• •甜蜜场景：中文应用、国产硬件、对 InternLM 系列优化

• •死亡场景：海外模型生态、复杂分布式

• 生态：以 InternLM / OpenMMLab 为核心

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

2.1 推理优化技术支持矩阵

2.2 易用性与生态

三、性能横评：实测对比

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：单序列吞吐（生成速度）

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

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

结论：

• 单序列：TensorRT-LLM 最强（极致 CUDA 优化）

• 高并发：SGLang 最强（结构化场景 + 共享 KV）

• 通用场景：vLLM 和 SGLang 几乎平手

3.3 延迟对比

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

TPOT（单 token 解码延迟）：

3.4 特殊场景：结构化输出

强制 JSON 输出的实测：

任务：生成符合特定 schema 的 JSON 1 万次

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

3.5 一张总结表

四、各框架深度解读

4.1 vLLM：稳健的通用首选

为什么仍然主流：

• 上手最快（一行启动）

• 生态最广（HF 模型几乎全支持）

• 社区活跃（每周更新）

• 文档完善（坑少）

• 工业验证最多（OpenAI、字节等都在用类似栈）

适用场景：

• 通用对话 / QA

• 内容生成

• 代码助手

• 大多数 ToB 应用

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

短板：

• 复杂 JSON 输出不如 SGLang

• 极致性能不如 TensorRT-LLM

• 部分前沿优化（如 Disaggregated Prefill/Decode）落地慢

4.2 SGLang：结构化输出之王

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

两个核心创新：

4.2.1 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%

4.2.2 编程模型（@function 装饰器）

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

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：

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 部署命令：

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 针对每个模型架构定制

代价：

复杂度极高

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

# 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" 选项

• 性能不再领先，但稳定

典型启动：

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 系列原生支持

典型启动：

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 业务场景推荐

5.3 团队规模 vs 框架

5.4 一些反直觉的建议

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

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

• ToC 聊天 → vLLM

• 内部 Agent → SGLang

• 嵌入式 / 端侧 → Ollama

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

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

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

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

六、迁移成本与生态

6.1 API 兼容性

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

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 的regexJSON 模式 → vLLM 用 outlines

• TensorRT-LLM 的 ensemble 模式 → 完全不同

6.2 迁移工程量

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 让迁移成本可控——但要注意特性差异

• 多框架共存是大团队的实际选择

参考文档：

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