LLM 推理服务工程全景：从 vLLM 到 SGLang 的高性能部署架构

LLM 推理与传统深度学习推理有本质区别。传统模型（如 ResNet、BERT）的推理是「一次前向传播，一次输出」，而 LLM 推理是「自回归生成」——每生成一个 token 都需要完整的前向传播，一个典型的回答需要生成 500-2000 个 token。

这带来三个核心挑战：

第一，显存瓶颈。LLM 的 KV Cache（键值缓存）随序列长度线性增长。一个 70B 参数模型在 4096 token 上下文下的 KV Cache 占用约 40GB 显存，超过了单张 A100 80GB 的可用容量。传统静态显存分配方式会导致 GPU 利用率低于 30%。

第二，请求变长。不同请求的输入长度（100-100,000 token）和输出长度（50-4000 token）差异巨大。传统「批处理」方式要求等待同一批中最长的请求完成才能处理下一批，导致延迟不可预测。

第三，吞吐与延迟的矛盾。高吞吐需要大 batch size，但大 batch 意味着用户需要等待更多请求凑齐才能开始处理，首 token 延迟（TTFT）急剧上升。

2023 年，Kwon 等人在 SOSP 会议上提出了 PagedAttention，这是 LLM 推理服务的第一个突破性优化。PagedAttention 将 KV Cache 分割成固定大小的「页」（通常 16 token），通过类似操作系统虚拟内存的机制实现动态分配，显存浪费从 60-80% 降低到 4% 以下。

PagedAttention 催生了 vLLM 项目，随后 SGLang 和 TensorRT-LLM 分别在不同方向上推进了推理服务的工程极限。到 2026 年，这三个引擎构成了 LLM 推理服务的主流技术栈。

vLLM 的设计理念是「服务优先」（serving-first）——让 LLM 部署变得简单、高效、兼容性强。它的核心优势在于 PagedAttention、Continuous Batching 和广泛的模型/硬件支持。

PagedAttention 深度解析

传统 KV Cache 分配是「连续内存」模式——为每个请求预分配最大可能长度的连续显存块。这导致两个问题：

内部碎片：实际生成长度通常远小于预分配长度，浪费的显存无法被其他请求使用。

外部碎片：不同请求释放后留下大小不一的空闲块，新请求找不到足够大的连续空间。

PagedAttention 的解决方案：将 KV Cache 分割成固定大小的「页」（page），每页存储 16 个 token 的键值对。页可以非连续分布在显存中，通过「页表」（page table）映射逻辑序列到物理显存。

效果数据：在 H100 上运行 Llama 2 70B，PagedAttention 将显存浪费从 60-80% 降低到 4% 以下，吞吐量提升 2-4 倍（相比 HuggingFace Transformers 的静态分配）。

Continuous Batching（连续批处理）

传统静态批处理：等待 batch 中所有请求完成才处理下一批。如果 batch 中有一个请求需要生成 2000 token，其他 999 token 的请求都要等它。

Continuous Batching 的实现：每个生成步骤后检查哪些请求已完成，立即用新请求填充空位。这要求 KV Cache 支持动态分配（PagedAttention 正好满足）。

效果数据：在混合长度请求场景下，Continuous Batching 比静态批处理吞吐量提升 3-5 倍，P99 延迟降低 50%。

vLLM 的生态优势

模型支持：支持 200+ 模型架构（Llama、Mistral、Qwen、DeepSeek、Phi 等），新模型通常在发布后 1-2 周内获得支持。

硬件支持：NVIDIA GPU（A100/H100/B200）、AMD GPU（MI300X）、Google TPU、AWS Inferentia。这是三大引擎中最广的。

API 兼容：内置 OpenAI 兼容 API 服务器，无需额外组件即可对接现有应用。

vLLM 的性能基准（H100 80GB，Llama 3.1 70B，TP=2）：

vLLM 的适用场景：

首选 vLLM 的情况：

• 需要快速上线（5 分钟部署）
• 模型频繁更换（实验阶段）
• 异构硬件环境（NVIDIA + AMD）
• 需要社区支持和文档

SGLang 的设计哲学是「执行效率优先」——通过 RadixAttention、C++/CUDA 调度器和结构化生成优化，在特定工作负载上实现比 vLLM 更高的性能。

RadixAttention：前缀缓存的革命

问题背景：许多 LLM 应用存在大量前缀共享：

• 多轮对话：每轮都包含完整的对话历史
• RAG 系统：所有请求共享相同的系统提示 + 检索上下文
• Few-shot 提示：多个示例共享相同的指令前缀

传统推理引擎对每个请求独立处理前缀，即使前缀完全相同也要重新计算 KV Cache。

RadixAttention 的解决方案：使用基数树（Radix Tree）索引所有已计算的 KV Cache 页。当新请求的前缀与已有请求匹配时，直接复用 KV Cache，跳过前缀的 prefill 计算。

效果数据（H100，Llama 3.1 70B，TP=2，5980 请求）：

关键洞察：RadixAttention 在独立提示场景下几乎没有额外开销（+2.5%），但在前缀共享场景下收益巨大。如果你的应用是 RAG 或多轮对话，SGLang 是明显更优的选择。

C++/CUDA 调度器

vLLM 的调度器用 Python 实现，在高并发（100+ 请求）时 Python 的 GIL 和解释器开销成为瓶颈。

SGLang 的调度器用 C++ 实现，核心逻辑（请求排队、页表管理、批处理决策）都在 C++/CUDA 中运行，Python 仅负责 API 接口。

效果数据：在 100 并发、独立提示场景下，SGLang 的调度开销比 vLLM 低 40%，TTFT P99 低 25%。

结构化生成优化

SGLang 对 JSON Schema、正则表达式等结构化输出有专门优化。当用户要求输出符合特定格式时，SGLang 使用 Trie 约束解码——在每一步只生成符合 schema 的 token，避免无效采样。

效果数据：在 JSON 输出任务上，SGLang 的结构化生成比 vLLM 快 2-3 倍（因为减少了重试和无效 token）。

SGLang 的性能基准（H100 80GB，Llama 3.1 70B，TP=2）：

SGLang 的适用场景：

首选 SGLang 的情况：

• RAG 系统（大量前缀共享）
• 多轮对话应用
• 需要结构化输出（JSON Schema）
• 高并发（100+ 请求）且对延迟敏感

TensorRT-LLM 的设计目标是「性能至上」——通过编译时优化、算子融合和 NVIDIA 硬件特化，在稳定工作负载上实现最高吞吐和最低延迟。

编译时优化（Build-Time Optimization）

与 vLLM/SGLang 的「即时服务」不同，TensorRT-LLM 需要先「编译」模型——将 PyTorch 模型转换为 TensorRT 引擎，这个过程包括：

算子融合（Operator Fusion）：将多个小算子合并为一个大算子，减少显存访问次数。例如，将 LayerNorm + Linear + GeLU 融合为单个 kernel。

精度校准（Precision Calibration）：自动寻找 FP16/INT8/FP8 量化的最优缩放因子，在精度损失最小的前提下最大化性能。

Kernel 自动调优（Auto-Tuning）：针对具体 GPU 型号和 batch size，选择最优的 CUDA kernel 实现。

编译时间：Llama 3.1 70B 在 H100 上的编译时间约 28 分钟。这是 TensorRT-LLM 的主要代价——不适合频繁更换模型的场景。

性能优势

编译完成后，TensorRT-LLM 在吞吐量和延迟上全面领先：

H100 基准测试（Llama 3.1 70B，TP=2）：

延迟对比（TTFT，100 并发）：

TensorRT-LLM 的延迟优势来自：

• 编译时优化的 kernel 启动开销更低
• INT8/FP8 量化减少显存带宽压力
• NVIDIA 驱动级别的优化

硬件限制

TensorRT-LLM 仅支持 NVIDIA GPU（A100/H100/B200），不支持 AMD 或 TPU。这是它与 vLLM/SGLang 的最大区别。

部署复杂度

TensorRT-LLM 通常需要配合 NVIDIA Triton Inference Server 使用，部署流程比 vLLM/SGLang 复杂：

1. 导出 PyTorch 模型为 TensorRT 引擎（trtllm-build）
2. 配置 Triton 模型仓库
3. 启动 Triton 服务器
4. 通过 Triton 客户端或 OpenAI 兼容层访问

TensorRT-LLM 的适用场景：

首选 TensorRT-LLM 的情况：

• 模型稳定（不频繁更换）
• 纯 NVIDIA GPU 环境
• 对吞吐量和延迟有极致要求
• 有工程资源处理编译和部署复杂度

选择推理引擎不是「哪个最好」的问题，而是「哪个最适合你的工作负载」的问题。 本节提供一个可操作的决策框架。

决策维度一：工作负载特征

前缀共享度：

• <20%（独立提示为主）：vLLM 或 TensorRT-LLM（SGLang 的 RadixAttention 优势不明显）
• 20-60%（混合场景）：SGLang 开始展现优势
• >60%（RAG/多轮对话）：SGLang 是明确首选（吞吐提升 50-70%）

并发水平：

• <50 并发：三个引擎差异不大，优先看部署便利性
• 50-100 并发：SGLang 的 C++ 调度器开始优势
• >100 并发：SGLang 或 TensorRT-LLM（vLLM 的 Python 调度器可能成为瓶颈）

请求长度分布：

• 短输入 + 长输出（聊天）：三个引擎差异不大
• 长输入 + 短输出（分类/提取）：关注 TTFT，TensorRT-LLM 最优
• 长输入 + 长输出（翻译/总结）：关注整体吞吐，TensorRT-LLM 最优

决策维度二：工程约束

模型稳定性：

• 频繁更换（每周+）：vLLM（即时加载，无需编译）
• 偶尔更换（每月）：SGLang（即时加载，编译开销低）
• 稳定不变（季度+）：TensorRT-LLM（28 分钟编译可接受）

硬件环境：

• 纯 NVIDIA：三个都支持，看性能需求
• NVIDIA + AMD：vLLM 或 SGLang（TensorRT-LLM 不支持 AMD）
• NVIDIA + TPU：仅 vLLM 支持

团队工程能力：

• 小团队/快速迭代：vLLM（5 分钟部署，文档完善）
• 中等团队/性能优化：SGLang（需要理解 RadixAttention 调优）
• 大团队/极致性能：TensorRT-LLM（需要 Triton 部署经验）

决策树总结（按顺序判断）：

1. 模型每周更换？ → 是 → vLLM
2. 有 AMD/TPU 硬件？ → 是 → vLLM
3. 前缀共享度 >60%？ → 是 → SGLang
4. 并发 >100 且对延迟敏感？ → 是 → TensorRT-LLM（纯 NVIDIA）或 SGLang
5. 默认 → vLLM（最安全的默认选择）

迁移路径：从 TGI 到现代引擎

HuggingFace TGI 已于 2025 年 12 月进入维护模式，官方推荐使用 vLLM 或 SGLang。迁移步骤：

第一步：API 兼容性检查。vLLM 和 SGLang 都提供 OpenAI 兼容 API，如果你的应用已经使用 OpenAI SDK，迁移几乎零成本。

第二步：性能基准测试。用你的实际工作负载在 vLLM 和 SGLang 上各跑一次基准，对比吞吐量和延迟。

第三步：灰度切换。先在非生产环境切换到 vLLM/SGLang，验证功能正确性，然后逐步切换生产流量。

迁移成本估算：对于已经使用 OpenAI SDK 的应用，迁移到 vLLM/SGLang 的工作量约 1-2 天（主要是部署配置）。

选择引擎只是第一步，生产部署还涉及一系列工程决策。 本节总结经过验证的最佳实践。

张量并行（Tensor Parallelism）配置

张量并行将模型权重切分到多张 GPU 上，是部署大模型（>30B 参数）的必需技术。

经验法则：

• 7B-13B 模型：单卡（A100 80GB）或 TP=2（H100 80GB）
• 30B-70B 模型：TP=2（H100 80GB）或 TP=4（A100 80GB）
• >100B 模型：TP=4-8（H100 80GB）

性能考量：TP 增加会提升吞吐，但也会增加通信开销。TP=2 通常是最优性价比点——相比 TP=1 吞吐提升 1.8-1.9 倍（而非理论上的 2 倍），但显存容量翻倍。

量化策略

FP16：默认选择，精度无损，显存占用大。

INT8：显存占用减半，吞吐提升 30-40%，精度损失 <1%（在 Llama/Qwen 等主流模型上）。推荐用于生产环境。

INT4：显存占用降至 1/4，吞吐提升 60-80%，精度损失 2-5%。适合对精度不敏感的场景（聊天、总结）。

FP8（H100 专属）：H100 原生支持 FP8 计算，INT8 量化的替代方案。精度损失 <0.5%，吞吐提升 40-50%。

KV Cache 优化

KV Cache 大小估算：

公式：KV Cache (GB) = 2 × 层数 × 隐藏维度 × 序列长度 × batch size × 精度字节 / 1e9

示例（Llama 3.1 70B，80 层，隐藏维度 8192，FP16，序列长度 4096，batch size 32）：KV Cache = 2 × 80 × 8192 × 4096 × 32 × 2 / 1e9 ≈ 68 GB

优化手段：

• PagedAttention：减少显存浪费（vLLM/SGLang 默认启用）
• KV Cache 量化：将 KV Cache 从 FP16 量化到 INT8，显存减半（实验性功能）
• Prefix Caching：复用共享前缀的 KV Cache（SGLang RadixAttention）

监控指标

生产环境必须监控以下指标：

吞吐量（Throughput）：输出 token/s。低于基准 80% 触发告警。

首 token 延迟（TTFT）：P50 和 P99。P99 超过 2 秒触发告警。

每 token 延迟（TPOT）：P50 和 P99。反映生成速度。

GPU 利用率：低于 60% 说明调度效率低或 batch size 过小。

显存使用率：超过 90% 有 OOM 风险。

请求队列长度：持续增长说明吞吐不足。

自动扩缩容

基于请求队列长度的自动扩缩容策略：

扩容条件：队列长度 > 10 持续 2 分钟 → 增加 1 个实例。

缩容条件：队列长度 = 0 持续 5 分钟 → 减少 1 个实例。

冷却时间：扩容后 5 分钟内不再扩容，缩容后 10 分钟内不再缩容。

工具推荐：Kubernetes HPA（Horizontal Pod Autoscaler）+ Prometheus 指标。

本节关联现有面试题库，帮助读者将知识库内容转化为面试准备素材。

相关面试题：

aieng-llm-serving-opt-001：LLM 推理服务优化的核心技术与选型策略

• 覆盖 PagedAttention、Continuous Batching、量化等技术
• 包含 vLLM/SGLang/TensorRT-LLM 的选型决策
• 与本文第一、五章直接对应

aieng-ml-serving-scale-001：机器学习模型服务化的规模化挑战

• 覆盖从单模型到多模型的部署架构演进
• 包含自动扩缩容、负载均衡等生产实践
• 与本文第六章对应

aieng-semantic-cache-001：语义缓存的设计与实现

• 覆盖语义相似度计算、缓存失效策略
• 与本文推理成本优化部分对应

延伸阅读：

知识库文章：

• infer-001：LLM 推理加速技术全景（三）：从推测解码到块扩散
• infer-002：LLM 推理加速（四）：新范式从 Speculative Decoding 到 DFlash
• infer-kv-cache-001：KV Cache 深度优化

博客文章：

• blog-406：Compute-Optimal 推理工程：过思考陷阱、智能路由与推理成本优化

外部资源：

• vLLM 官方文档：https://docs.vllm.ai/
• SGLang 官方文档：https://sgl-project.github.io/
• TensorRT-LLM GitHub：https://github.com/NVIDIA/TensorRT-LLM
• Inference Engineering（Philip Kiely 著）：https://inferenceengineering.tech/

LLM 推理服务是 AI 工程化的核心环节。选择正确的推理引擎、配置合理的优化策略，可以将 GPU 成本降低 50% 以上，同时提升用户体验。

核心要点回顾：

第一，三大引擎各有定位。vLLM 是服务优先的通用引擎，部署简单、兼容性强；SGLang 是执行效率优先的专家，在前缀共享和高并发场景下性能最优；TensorRT-LLM 是性能至上的极致优化，在纯 NVIDIA 环境且模型稳定时吞吐最高。

第二，PagedAttention 是基础。它将 KV Cache 的显存浪费从 60-80% 降低到 4% 以下，是 Continuous Batching 的前提。vLLM/SGLang/TensorRT-LLM 都实现了 PagedAttention。

第三，RadixAttention 是差异化。SGLang 的 RadixAttention 在前缀共享场景（RAG、多轮对话）下吞吐提升 50-70%，这是它区别于 vLLM 的核心优势。

第四，选型看工作负载。前缀共享度、并发水平、模型稳定性是三大决策维度。没有「最好」的引擎，只有「最适合」的引擎。

第五，TGI 已死。HuggingFace TGI 进入维护模式，vLLM/SGLang 成为双寡头。如果你还在用 TGI，现在就该规划迁移。

行动建议：

如果你还没部署 LLM 推理服务：从 vLLM 开始。5 分钟部署，OpenAI 兼容 API，是最安全的默认选择。

如果你在跑 RAG 或多轮对话：试试 SGLang。RadixAttention 的前缀缓存可以显著降低你的 GPU 成本。

如果你有纯 NVIDIA 环境且模型稳定：评估 TensorRT-LLM。28 分钟编译的代价换来 13-16% 的吞吐提升，在高流量场景下值得。

如果你还在用 TGI：计划迁移到 vLLM 或 SGLang。API 兼容性很好，迁移工作量约 1-2 天。

如果你在优化推理成本：先实施 INT8 量化（吞吐提升 30-40%，精度损失 <1%），再考虑语义缓存（命中率 25-35%），最后评估智能路由（简单任务用小模型）。

LLM 推理服务工程仍在快速演进。2026 年下半年，我们可能看到 vLLM 和 SGLang 的深度整合，以及 NVIDIA Dynamo 等新型编排层的成熟。保持关注，但不要被新工具迷惑——理解核心原理（PagedAttention、Continuous Batching、前缀缓存）比追逐新框架更重要。