LLM 推理服务化架构深度对比：vLLM vs SGLang vs TensorRT-LLM vs TGI------从核心原理到生产级选型决策
摘要：2026 年，LLM 推理服务化已形成 vLLM、SGLang、TensorRT-LLM、TGI 四大引擎并立的格局。本文从 KV Cache 管理、调度器设计、前缀缓存、结构化输出四个核心技术维度深入剖析各引擎的架构差异，结合 Q2 2026 最新 benchmark 数据给出生产级选型决策框架和部署参数调优指南。
一、为什么推理服务化架构值得深入研究
大模型部署不是 python serve.py 就完事了。当你面对以下场景时，推理服务化架构的选型直接决定了系统上限：
- 高并发 Chat API：200+ 并发用户，P99 延迟必须控制在 200ms 以内
- RAG 系统：数千用户共享同一套系统 Prompt 和知识库上下文
- 结构化输出：Agent 工具调用需要严格的 JSON Schema 约束，吞吐不能打折扣
- 成本敏感：每百万 Token 成本差 $0.10，日处理亿级 Token 时就是每月数万美元的差异
本文将深入四个主流推理引擎的架构设计，帮你做出正确的技术选型。
二、四大引擎架构全景
2.1 核心差异一览
| 维度 | vLLM | SGLang | TensorRT-LLM | TGI |
|---|---|---|---|---|
| 主导方 | UC Berkeley → PyTorch Foundation | LMSYS / xAI / DeepSeek | NVIDIA | HuggingFace |
| 首发时间 | 2023-06 | 2024-01 | 2023-10 | 2022-11 |
| 核心创新 | PagedAttention + Continuous Batching | RadixAttention + 零开销调度 | TensorRT 编译优化 | Rust 运行时 + Rolling Batch |
| 实现语言 | Python（调度器）+ CUDA | Python + FlashInfer | C++（TRT Runtime） | Rust（Server）+ Python（Worker） |
| 定位 | 开源事实标准 | 高性能+结构化输出 | NVIDIA 硬件天花板 | 企业 HF 生态集成 |
2.2 架构设计差异：以请求处理流水线为例
vLLM v1 架构（2025 正式默认）：
ini
EngineCore 进程
├── Scheduler（continuous batching，Python）
│ ├── prefix hash 查找 → 命中则复用 KV block
│ ├── block_table 分配（PagedAttention，block_size=16）
│ └── chunked prefill 自动拆长 prompt
├── KVCacheManager（block 粒度管理）
└── ModelExecutor（FlashAttention-2/3 + FlashInfer）vLLM 的关键设计是 Scheduler 与 Worker 进程解耦，v1 版本将调度逻辑独立为 EngineCore 进程，Worker 只做前向计算。这使得调度策略可以独立演进而不影响推理性能。
SGLang 架构：
arduino
TokenizerManager → Scheduler
├── RadixCache（radix tree 组织 KV cache）
├── TokenToKVPool
└── ModelRunner（FlashInfer + CUDA Graph）
├── overlap scheduling（CPU 准备 batch N+1 时 GPU 跑 batch N）
└── xgrammar（结构化输出的 GPU 端 token mask 生成）SGLang 的核心差异化在于三点：
- RadixAttention：用 radix tree（基数树）组织所有历史请求的 KV cache，前缀共享粒度为单 Token 级别
- Overlap Scheduling：CPU 调度与 GPU 前向完全并行，调度开销接近零
- xgrammar 原生集成：结构化输出的 mask 在 GPU 端异步构造，无 GPU-CPU 同步瓶颈
TensorRT-LLM 架构：
arduino
Builder（编译阶段）
├── 模型 → TensorRT Engine（.engine plan file）
├── 算子融合 + SM 架构特定 CUDA kernel 生成
└── 自定义 Plugin（MHA/PagedKV/MoE/Quantization）
↓
Runtime（推理阶段）
├── In-flight Batching（IFB，等价于 Continuous Batching）
├── Paged KV Cache（自研实现，block size 可配）
└── Triton Inference Server Backend（gRPC/HTTP 服务化）TensorRT-LLM 的"编译优化"哲学意味着它在 NVIDIA 硬件上的性能天花板最高，但代价是编译步骤耗时（30 分钟到数小时）且编译结果硬件特定（A100 编译的引擎不能在 H100 上运行）。
TGI 架构特点：
TGI 曾是大模型推理的早期事实标准，但在 vLLM 和 SGLang 崛起后逐渐式微。其 Rust HTTP Server + Python Worker 的架构在延迟开销上有天然优势，但功能迭代速度慢、模型支持范围窄，2023 年底一度修改 License 为 HFOIL 更是加速了用户流失。
三、KV Cache 管理：推理服务化的核心战场
KV Cache 是 LLM 推理中最关键的内存管理问题。Decode 阶段每生成一个 Token，都需要从 GPU 内存中读取整个模型权重矩阵（约 140GB for 70B），同时还要读写不断增长的 KV Cache。在长序列或高并发场景下，KV Cache 可能占用与模型权重相当的 GPU 内存。
3.1 PagedAttention（vLLM）
核心思想：借鉴操作系统虚拟内存管理，将 KV Cache 划分为固定大小的 Page（block_size=16 Token），按需非连续分配。
scss
传统方案：为每个请求预分配 max_seq_len 的连续内存
├── 实际使用 512 token，预分配 4096 token
└── 浪费率：60-80%
PagedAttention：按需分配 block，用完即释放
├── block 可非连续存储
├── 通过 block_table 映射逻辑位置到物理位置
└── 浪费率：< 4%实际收益：相比朴素 PyTorch 推理，吞吐量提升 2-4 倍。在混合长度负载下，vLLM 的 GPU 内存利用率可达 ~98%。
3.2 RadixAttention（SGLang）
核心思想：用 radix tree 组织所有请求的 KV cache，实现 Token 级别的精确前缀共享。
arduino
请求1：system_prompt + "翻译：Hello" → KV 存储在 radix tree
请求2：system_prompt + "翻译：World" → 自动复用 system_prompt + "翻译：" 的 KV
请求3：system_prompt + "总结：..." → 自动复用 system_prompt 的 KV与 vLLM Prefix Caching 的关键差异：
| 对比维度 | vLLM Prefix Caching | SGLang RadixAttention |
|---|---|---|
| 数据结构 | Hash 表，block 级匹配 | Radix tree，token 级匹配 |
| 前缀粒度 | block（16/32 token） | 任意长度，单 token 级别 |
| 共享效率 | 仅系统 prompt 级别 | 任意前缀（多轮对话、RAG context、few-shot 示例） |
| 多租户 | 靠 request id 隔离 | radix tree 节点自然隔离 |
| 释放策略 | 请求结束立即释放或 LRU | 节点引用计数，自动共享 |
实际场景收益：在 RAG 场景（16K 上下文）中，SGLang 的吞吐量比 vLLM 高约 40%。原因在于数千用户共享同一知识库上下文时，SGLang 的 Token 级前缀匹配能最大化 KV 复用，而 vLLM 的 block 级匹配可能因为 few-shot 示例的微小差异导致退化为各自独立存储。
3.3 内存效率对比（Q2 2026 Benchmark）
| 引擎 | 内存布局策略 | GPU 内存利用率 | 特点 |
|---|---|---|---|
| vLLM | PagedAttention（非连续分页） | ~98% | 接近最优，碎片极少 |
| SGLang | RadixAttention（前缀树） | ~95%（典型） | 高提示复用时可减少 30-50% 内存 |
| TensorRT-LLM | 分块 KV-Cache + 核融合 | ~94% | 小请求可能留有空块 |
| TGI | 混合连续布局 | ~92% | 简单但效率最低 |
四、调度器设计：吞吐量与延迟的博弈
4.1 Continuous Batching（迭代级调度）
传统静态批处理的问题是：等 N 个请求一起处理，全部完成后再释放。短请求必须等待长请求完成，GPU 利用率极低。
Continuous Batching 的核心改进：每步解码时动态添加新请求，已有请求完成即释放资源。
css
Step 1: [Req1(token=5), Req2(token=3), Req3(token=8)] → forward
Step 2: [Req1(token=6), Req2(token=4), Req3(token=9), Req4(token=1)] ← Req4 新加入
Step 3: [Req1(token=7), Req3(token=10), Req4(token=2)] ← Req2 完成，释放
Step 4: [Req1(token=8), Req4(token=3), Req5(token=1)] ← Req3 完成，Req5 加入4.2 Chunked Prefill（vLLM v1）
长 Prompt 的 Prefill 阶段是计算密集型操作，如果一次性处理 32K token 的 Prefill，会导致其他请求的 Decode 被阻塞（首 Token 长尾延迟）。
Chunked Prefill 的解决方案：把长 Prompt 切成小块，与 Decode 请求混跑。
scss
不开启 Chunked Prefill：
Prefill(32K) → 阻塞 200ms → 然后才能处理其他请求的 Decode
开启 Chunked Prefill（chunk_size=2048）：
Prefill(chunk 0-2047) + Decode(req1, req2) → 15ms
Prefill(chunk 2048-4095) + Decode(req1, req3) → 15ms
...vLLM v1 中 Chunked Prefill 默认开启，是消除首 Token 长尾延迟的关键手段。
4.3 Overlap Scheduling（SGLang）
SGLang 的调度器进一步做到了 CPU 调度与 GPU 前向的完全并行：
传统调度：
CPU 调度 batch → GPU 前向 → CPU 调度 batch → GPU 前向
调度开销：每步 1-5ms
SGLang Overlap Scheduling：
GPU 前向 batch N ────────────────────
CPU 调度 batch N+1 ──────────────
调度开销：接近 0配合 CUDA Graph 回放（Decode 阶段消除 kernel launch overhead），SGLang 在高并发场景下比 vLLM 的吞吐高 5-10%。
五、量化策略对比：显存与精度的平衡
5.1 各引擎量化支持矩阵
| 量化方案 | vLLM | SGLang | TensorRT-LLM | 典型场景 |
|---|---|---|---|---|
| FP16/BF16 | ✅ | ✅ | ✅ | 精度优先，70B 需 4-8 卡 H100 |
| FP8 (E4M3/E5M2) | ✅ (Hopper+) | ✅ | ✅ （最完整） | Hopper 硬件，2× KV 容量 |
| INT8 SmoothQuant | ✅ | ✅ | ✅ | 通用量化 |
| AWQ (W4A16) | ✅ | ✅ | ✅ | 4-bit 权重，质量损失 <1% |
| GPTQ | ✅ | ✅ | ✅ | 4-bit 权重，需校准数据 |
| NVFP4/MXFP4 | ✅ (Blackwell) | ✅ | ✅ | Blackwell 新特性 |
5.2 量化对部署的实际影响
以 Llama-3.3-70B 为例：
| 精度 | 显存占用 | 所需 GPU | 吞吐（vLLM, batch=32） | 适用场景 |
|---|---|---|---|---|
| BF16 | ~140GB | 8×H100（80GB） | 50 tok/s | 精度敏感（数学/代码） |
| FP8 | ~70GB | 4×H100 | 75 tok/s | 通用生产（推荐） |
| INT4 (AWQ) | ~35GB | 2×H100 | 100 tok/s | 高吞吐、成本敏感 |
关键实践：FP8 是 Hopper 架构上的"甜蜜点"------近 INT8 的内存效率，但质量优于 INT4，尤其适合数学推理和代码生成场景。TensorRT-LLM 在 FP8 上的优化最为激进，吞吐可达 vLLM 的 1.25×。
六、生产级 Benchmark：Q2 2026 最新数据
以下数据基于 8×H200 SXM（141GB HBM3e/GPU），Llama-3.3-70B（4-bit GPTQ），混合工作负载：
6.1 吞吐量对比
| 工作负载 | vLLM | TGI | SGLang | Triton-TRT |
|---|---|---|---|---|
| Chat（32 并发） | 4,250 tok/s | 3,120 tok/s | 4,880 tok/s | 5,210 tok/s |
| RAG（16 并发，4K 上下文） | 2,200 tok/s | 1,890 tok/s | 2,310 tok/s | 2,480 tok/s |
| 批量摘要（16 请求） | 5,100 tok/s | 4,200 tok/s | 5,300 tok/s | 5,450 tok/s |
6.2 延迟对比（512 token prompt）
| 引擎 | p50 TTFT | p99 TTFT | p50 TPOT | p99 TPOT |
|---|---|---|---|---|
| Triton-TRT | 75ms | 118ms | 7.6ms | 12.4ms |
| SGLang | 79ms | 135ms | 7.9ms | 14.8ms |
| vLLM | 82ms | 140ms | 8.2ms | 15.1ms |
| TGI | 94ms | 165ms | 9.1ms | 17.3ms |
TTFT = Time To First Token（首 Token 延迟），TPOT = Time Per Output Token（每输出 Token 延迟）
6.3 成本对比（每百万 Token，H200 $4.00/hr，50% 利用率）
| 引擎 | 成本/百万 Token | 相对 vLLM |
|---|---|---|
| Triton-TRT | $0.48 | -12.7% |
| SGLang | $0.51 | -7.3% |
| vLLM | $0.55 | 基线 |
| TGI | $0.63 | +14.5% |
七、选型决策框架
7.1 场景驱动的选型决策树
css
你的场景是什么？
│
├── 通用 API 服务 / 快速上线 / 最广模型支持
│ └── → vLLM（默认首选）
│ 理由：pip install 即可部署，OpenAI 兼容 API，模型支持最广
│ 关键参数：--gpu-memory-utilization 0.90 --enable-chunked-prefill
│
├── 结构化输出密集 / 长前缀场景 / DeepSeek 生态
│ └── → SGLang
│ 理由：RadixAttention 长前缀吞吐 +40%，xgrammar 结构化输出吞吐 +30%
│ 关键参数：--schedule-policy lpm --attention-backend flashinfer
│
├── 极致性能 / NVIDIA 纯血环境 / 模型稳定不频繁更新
│ └── → TensorRT-LLM（通过 Triton Inference Server）
│ 理由：H100/H200 上吞吐高 20-50%，延迟最低，但需编译步骤
│ 关键参数：FP8 量化 + In-flight Batching + Tensor Parallel
│
├── HuggingFace 深度集成 / 延迟敏感的交互式应用
│ └── → TGI
│ 理由：Rust 核心延迟开销最低（每请求 1-5ms），HF Hub 紧密集成
│ 注意：新项目不推荐作为首选
│
└── CPU / 端侧 / 消费级 GPU
└── → llama.cpp / Ollama
理由：GGUF 极致量化，单二进制无依赖，15 分钟可部署7.2 混合部署策略（推荐）
不要非此即彼 。生产环境的最佳实践是混合部署：
scss
┌─────────────┐
│ Gateway │ （路由层：按请求特征分发）
└──────┬──────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ vLLM │ │ SGLang │ │Triton-TRT │
│ (通用API) │ │(结构化输出) │ │(离线批处理) │
└────────────┘ └────────────┘ └────────────┘典型路由规则：
- 包含
response_format: {type: "json_schema"}→ 路由到 SGLang - 离线批量评估任务（摘要、翻译、分类）→ 路由到 Triton-TRT
- 常规 Chat 请求 → 路由到 vLLM
7.3 各引擎关键部署参数
vLLM 生产配置：
bash
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.3-70B-Instruct \
--gpu-memory-utilization 0.90 \
--max-model-len 32768 \
--max-num-seqs 256 \
--max-num-batched-tokens 8192 \
--enable-chunked-prefill \
--enable-prefix-caching \
--kv-cache-dtype fp8 \
--tensor-parallel-size 4SGLang 生产配置：
bash
python -m sglang.launch_server \
--model-path meta-llama/Llama-3.3-70B-Instruct \
--mem-fraction-static 0.88 \
--context-length 32768 \
--max-running-requests 256 \
--schedule-policy lpm \
--attention-backend flashinfer \
--enable-torch-compile \
--tp 4关键参数解读：
--gpu-memory-utilization 0.90：留 ~10% 给 CUDA workspace，避免 OOM--max-num-seqs 256：并发上限，过高会导致 TTFT 恶化--schedule-policy lpm：SGLang 的 longest-prefix-match 策略，配合 RadixAttention 使用--enable-torch-compile：首次启动慢（约 10 分钟编译），稳态吞吐 +10%
八、PD 分离：2025-2026 年最大的架构演进
8.1 核心问题
Prefill（处理输入 Prompt）是 compute-bound ，Decode（逐 Token 生成）是 memory-bound。放在一起会互相踩踏：
同一 GPU 上：
Prefill 吃满 SM → Decode 被阻塞 → 首 Token 延迟飙升
Decode 吃满显存带宽 → Prefill 等待 → 吞吐下降8.2 PD 分离架构
scss
┌─────────┐
│ Router │
└────┬────┘
┌────────┴────────┐
▼ ▼
┌─────────┐ ┌─────────┐
│P Worker │──KV──▶│D Worker │
│(A100×8) │transfer│(H100×4) │
└─────────┘ └─────────┘
Compute-bound Memory-bound
高算力GPU 高带宽GPU代表实现：
- Mooncake（月之暗面）：生产级 KV Cache 池 + P/D 解耦，已在 Kimi 大规模验证
- vLLM v1 disagg ：通过
KVConnector抽象接入 Mooncake/NIXL - SGLang PD ：原生内置，
--disaggregation-mode prefill|decode
8.3 部署命令
bash
# Prefill 节点（A100×8，高算力）
python -m sglang.launch_server \
--disaggregation-mode prefill \
--tp 8
# Decode 节点（H100×4，高带宽）
python -m sglang.launch_server \
--disaggregation-mode decode \
--tp 4PD 分离适合大规模生产部署（日处理亿级 Token），小规模部署不建议使用，因为 KV transfer 的额外开销可能抵消收益。
九、总结：四句话选型指南
- 追求性价比和生态兼容性 → vLLM：开源事实标准，模型支持最广，OpenAI 兼容 API 开箱即用
- 结构化输出或长前缀密集 → SGLang：RadixAttention 带来 40% 长上下文吞吐提升，xgrammar 结构化输出 +30%
- 追求极致性能且使用 NVIDIA 硬件 → TensorRT-LLM：H100/H200 上吞吐高 20-50%，FP8 优化最激进，但需编译步骤和工程投入
- 已深度使用 HuggingFace 生态 → TGI：Rust 核心延迟最低，HF Hub 紧密集成，但不推荐作为新项目首选
最终建议：从 vLLM 开始，当你遇到结构化输出或长前缀瓶颈时引入 SGLang，当你需要压榨最后 20% 性能时考虑 TensorRT-LLM。三者可以共存于同一生产环境，通过 Gateway 层按请求特征智能路由。
本文基于 Q2 2026 最新 benchmark 数据撰写，所有性能数据基于 8×H200 SXM + Llama-3.3-70B（4-bit GPTQ）测试环境。实际部署中建议基于自身工作负载进行压测验证。