小团队应该选择哪个推理引擎？

推荐 vLLM。社区最活跃、文档最完善、支持的模型最多，部署只需 pip install 加几行代码。SGLang 性能略高但生态成熟度不如 vLLM，TensorRT-LLM 部署门槛太高不适合小团队。

SGLang 的 RadixAttention 是什么？为什么能提升性能？

RadixAttention 是 SGLang 独有的 KV Cache 复用技术。它将多次请求共享的前缀 token 的 KV Cache 用基数树（Radix Tree）管理，避免重复计算。在多轮对话和 few-shot 场景中效果显著，可减少 40% 以上的 KV Cache 重计算。

TensorRT-LLM 的部署为什么这么复杂？

TensorRT-LLM 需要先将模型编译为 TensorRT 引擎文件，这个过程涉及算子融合、量化配置、显存规划等多个步骤，且编译产物与 GPU 型号绑定。好处是编译后推理速度极快，适合模型固定、长期运行的生产场景。

这三个引擎支持 Apple Silicon Mac 吗？

都不原生支持。这三个引擎都针对 NVIDIA GPU 优化（CUDA 生态）。Apple Silicon 用户建议用 llama.cpp（通过 Metal 加速）或 MLX 框架。Ollama 底层就是 llama.cpp，是 Mac 上最方便的选择。

2026 年有没有新的推理引擎值得关注？

LMDeploy（商汤开源）在国产 GPU 适配上表现突出，性能接近 SGLang。oMLX（Meta 开源）专注于推理编排而非底层优化，适合复杂的多模型调度场景。此外，vLLM 和 SGLang 正在走向融合，SGLang 已开始复用 vLLM 的部分组件。

LLM 推理引擎横评 2026：vLLM vs SGLang vs TensorRT-LLM 实测对比

为什么推理引擎的选择至关重要

当你训练好一个模型（或选择了一个开源模型），部署上线时面临的第一个问题就是：用什么推理引擎来跑它？

推理引擎直接决定了三个关键指标：

吞吐量（Tokens/s）：每秒能处理多少 token，决定了你需要多少 GPU
首 token 延迟（TTFT）：用户发送请求到看到第一个字的等待时间
显存效率：同一块 GPU 能同时处理多少并发请求

选错引擎，轻则浪费 30-50% 的 GPU 资源，重则延迟飙升、用户体验崩塌。

截至 2026 年 5 月，生产级 LLM 推理引擎形成了三足鼎立的格局：vLLM、SGLang、TensorRT-LLM。本文基于公开基准测试数据和社区实测报告，进行全面对比。

基本信息对比

维度	vLLM	SGLang	TensorRT-LLM
开发方	UC Berkeley (开源社区)	UC Berkeley (开源社区)	NVIDIA
开源协议	Apache 2.0	Apache 2.0	Apache 2.0
首次发布	2023.06	2024.01	2023.09
GitHub Stars	~45K	~18K	~12K
核心语言	Python + CUDA	Python + CUDA	C++ + Python
安装方式	`pip install vllm`	`pip install sglang`	Docker / 源码编译
支持模型数	200+	120+	80+
多模态支持	是	是	部分

H100 基准测试数据

以下数据基于 Llama 3.3 70B（FP16）在单张 H100 80GB 上的测试结果，数据来源为多个独立基准测试报告的综合：

吞吐量测试（输出 Tokens/s）

并发数	vLLM	SGLang	TensorRT-LLM
1	42	55	58
4	168	210	225
8	330	405	420
16	640	720	680
32	1,180	1,250	1,050
64	2,100	2,050	1,620
128	3,200	2,800	2,100

关键发现：

低并发（<16）：SGLang 和 TensorRT-LLM 领先，SGLang 比 vLLM 高约 29%
高并发（>64）：vLLM 反超，得益于其成熟的 PagedAttention 调度器
TensorRT-LLM 在高并发下性能下降最明显，调度器不够灵活

首 token 延迟（TTFT，ms）

输入长度	vLLM	SGLang	TensorRT-LLM
128 tokens	85	72	45
512 tokens	120	105	68
2048 tokens	280	245	155
8192 tokens	850	720	420

TensorRT-LLM 的 TTFT 全面领先，因为其编译优化后的 prefill 阶段效率最高。

显存占用（GB，加载 Llama 3.3 70B FP16）

组件	vLLM	SGLang	TensorRT-LLM
模型权重	35.2	35.2	33.8
KV Cache	38.5	36.1	32.0
运行时开销	2.8	3.2	5.5
总计	76.5	74.5	71.3

TensorRT-LLM 通过算子融合和内存布局优化，显存占用最低，但代价是更高的运行时开销。

架构差异深度剖析

vLLM：PagedAttention 的开创者

vLLM 的核心创新是 PagedAttention——将 KV Cache 按固定大小的”页”管理，类似操作系统的虚拟内存：

传统方式: 每个请求预分配最大长度的连续 KV Cache 空间
  → 大量显存浪费（平均利用率 ~30%）

PagedAttention: KV Cache 按 16 token 为一页动态分配
  → 显存利用率提升到 ~95%
  → 支持更多并发请求

这使得 vLLM 在高并发场景下表现优异——同一块 GPU 能同时处理更多请求。

优势：

生态最成熟，几乎支持所有主流模型
社区活跃，bug 修复速度快
简单的 API 设计，上手成本低

劣势：

单请求性能不是最优
对 CUDA Graph 的利用不如 TensorRT-LLM 充分

SGLang：RadixAttention 的缓存魔法

SGLang 的杀手锏是 RadixAttention，用基数树（Radix Tree）管理 KV Cache 的前缀复用：

请求 A: "你是一个编程助手。请用 Python 写一个快排算法。"
请求 B: "你是一个编程助手。请用 Python 写一个二分查找。"

传统方式: 两个请求分别计算各自的 KV Cache
RadixAttention: 共享前缀 "你是一个编程助手。请用 Python 写一个" 的 KV Cache
  → 前缀部分的计算只做一次
  → 适合多轮对话、few-shot、batch 推理

优势：

前缀共享场景下性能碾压其他引擎
对 DeepSeek 等 MoE 模型的推理优化最好
内置的约束解码（JSON mode）比 vLLM 更高效

劣势：

支持的模型数量少于 vLLM
高并发调度不如 vLLM 稳定
文档质量参差不齐

TensorRT-LLM：编译优化的极致

TensorRT-LLM 采用完全不同的思路——先编译，再推理：

# Step 1: 转换模型格式
python convert_checkpoint.py --model_dir ./llama-70b \
    --output_dir ./tllm_checkpoint \
    --dtype float16

# Step 2: 编译为 TensorRT 引擎（耗时 30-60 分钟）
trtllm-build --checkpoint_dir ./tllm_checkpoint \
    --output_dir ./tllm_engine \
    --gemm_plugin float16 \
    --max_batch_size 64 \
    --max_input_len 4096 \
    --max_seq_len 8192

# Step 3: 启动推理服务
python run.py --engine_dir ./tllm_engine

编译过程中会进行算子融合、内存布局优化、量化等操作，生成针对特定 GPU 硬件优化的推理引擎。

优势：

单请求延迟最低（TTFT 比 vLLM 低 40-50%）
NVIDIA 官方支持，硬件适配最好
支持 FP8 量化，Hopper 架构 GPU 上性能释放最充分

劣势：

部署复杂度高，需要编译步骤
编译产物与 GPU 型号绑定，不可迁移
模型更新需要重新编译
社区相对封闭，issue 响应慢

特定场景推荐

场景 1：在线对话服务（高并发、低延迟）

推荐：vLLM

高并发是 vLLM 的主场。PagedAttention 的显存管理在 100+ 并发时优势明显：

from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.3-70B-Instruct",
    tensor_parallel_size=4,
    max_model_len=8192,
    gpu_memory_utilization=0.92
)

params = SamplingParams(
    temperature=0.7,
    max_tokens=2048,
    top_p=0.9
)

# 批量处理并发请求
outputs = llm.generate(prompts, params)

场景 2：多轮对话 / Few-shot 推理

推荐：SGLang

RadixAttention 的前缀缓存在多轮对话中效果拔群：

import sglang as sgl

@sgl.function
def multi_turn_chat(s, history, new_message):
    # 系统提示和历史对话的 KV Cache 会被自动缓存
    s += sgl.system("你是一个专业的技术顾问。")
    for msg in history:
        s += sgl.user(msg["user"])
        s += sgl.assistant(msg["assistant"])
    s += sgl.user(new_message)
    s += sgl.assistant(sgl.gen("response", max_tokens=1024))

实测数据：10 轮对话场景下，SGLang 比 vLLM 快 2.1 倍。

场景 3：低延迟推理（实时翻译、语音助手）

推荐：TensorRT-LLM

当 TTFT 是第一优先级时，TensorRT-LLM 的编译优化无可替代：

import tensorrt_llm

runner = tensorrt_llm.ModelRunner.from_dir("./tllm_engine")

output = runner.generate(
    prompts=["Translate to Chinese: Hello, how are you?"],
    max_new_tokens=128,
    streaming=True
)

场景 4：预算有限的小规模部署

推荐：vLLM + 量化

# 使用 AWQ 量化模型，单张 RTX 4090 (24GB) 跑 70B 模型
vllm serve meta-llama/Llama-3.3-70B-Instruct-AWQ \
    --quantization awq \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.95

部署复杂度对比

步骤	vLLM	SGLang	TensorRT-LLM
安装	pip install	pip install	Docker + 源码编译
模型加载	自动下载	自动下载	需要格式转换 + 编译
启动服务	1 条命令	1 条命令	3-5 步
模型更新	改参数重启	改参数重启	重新编译（30-60min）
多 GPU	`--tensor-parallel N`	`--tp N`	编译时指定
监控	Prometheus 内置	Prometheus 内置	Triton 集成
从零到上线	30 分钟	30 分钟	4-8 小时

选型决策树

你的场景是什么？
├── 高并发在线服务（>50 QPS）
│   └── 选 vLLM
├── 多轮对话 / few-shot / 前缀共享
│   └── 选 SGLang
├── 极致低延迟（TTFT < 100ms）
│   └── 选 TensorRT-LLM
├── 预算有限 / 快速原型
│   └── 选 vLLM
├── DeepSeek 等 MoE 模型
│   └── 选 SGLang
└── 不确定
    └── 先用 vLLM，遇到瓶颈再切换

未来趋势

vLLM 和 SGLang 走向融合：SGLang 已开始复用 vLLM 的部分组件，未来可能共享底层基础设施
Disaggregated Serving：将 prefill 和 decode 拆分到不同的 GPU 上执行，三家都在跟进这个方向
Speculative Decoding 普及：投机解码正在从实验特性变为标配，可进一步降低延迟
FP4/FP6 量化：下一代量化精度将在 Blackwell GPU 上释放更大的推理性能

选择推理引擎没有银弹，关键是理解自己的场景需求，然后用数据验证。建议在正式部署前，用真实的请求分布做压测，而不是只看公开基准测试——你的数据分布可能和基准测试差别很大。