推理引擎架构：vLLM / TensorRT-LLM / SGLang
1. 推理引擎在做什么？
推理引擎 = 把前面 5 章学到的所有优化技术整合到一个系统中：
用户请求 → [推理引擎] → 生成结果
│
├── KV Cache 管理 (PagedAttention) ← 第1章
├── 性能分析 (Compute/Memory bound) ← 第2章
├── 量化支持 (INT4/INT8/FP8) ← 第3章
├── 批处理调度 (Continuous Batching) ← 第4章
├── 投机解码 (Speculative Decoding) ← 第5章
├── Kernel 优化 (FlashAttention 等)
├── 并行策略 (Tensor/Pipeline Parallel)
└── API 服务 (OpenAI 兼容接口)2. 核心 Kernel 优化
2.1 FlashAttention
标准 Attention 的问题：
标准实现:
Q·K^T → [seq_len × seq_len] 中间矩阵 → 存到 HBM
softmax → 读回 HBM → 存到 HBM
× V → 读回 HBM → 最终结果
问题: 中间矩阵 O(seq_len²) 太大，反复读写 HBMFlashAttention 的解决方案：
FlashAttention (Tiling + Online Softmax):
1. 把 Q, K, V 切成小块 (tiles)
2. 每次只加载一小块到 SRAM（片上高速缓存）
3. 在 SRAM 中完成 Q·K^T → softmax → ×V
4. 用 online softmax 算法累积结果
5. 永远不把 seq_len × seq_len 的中间矩阵写到 HBM
效果:
- 内存: O(seq_len²) → O(seq_len)
- 速度: 减少 HBM 访问 → prefill 加速 2-4x
- 支持更长序列（不会 OOM）内存层次:
SRAM (片上): ~20 MB, ~19 TB/s 带宽 ← FlashAttention 在这里算
HBM (显存): 80 GB, ~2-3 TB/s 带宽 ← 标准 attention 反复读写这里
SRAM 带宽是 HBM 的 ~10 倍！2.2 FlashDecode
FlashAttention 优化的是 prefill（长序列 attention）。Decode 阶段有不同的特点：
Decode attention:
Q: [1, num_heads, head_dim] ← 只有 1 个 token
K: [seq_len, num_heads, head_dim] ← KV Cache 中所有历史
V: [seq_len, num_heads, head_dim]
问题: Q 太小，标准 FlashAttention 的 tiling 策略不适用FlashDecode 针对 decode 优化：
FlashDecode:
1. 把 KV Cache 按 seq_len 维度分成多个 split
2. 每个 split 独立计算 partial attention
3. 最后 reduce 合并结果
本质: 增加并行度，让更多 GPU 线程参与计算
效果: decode attention 加速 2-8x2.3 Kernel Fusion
把多个小操作合并成一个 GPU kernel，减少 kernel launch 开销和中间结果的 HBM 读写：
未融合:
LayerNorm → 写 HBM → 读 HBM → Linear → 写 HBM → 读 HBM → GELU → 写 HBM
每个操作都要读写 HBM，开销巨大
融合后:
[LayerNorm + Linear + GELU] → 一个 kernel 内完成
中间结果留在寄存器/SRAM，只写一次 HBM3. 三大推理引擎对比
3.1 vLLM
定位: 高吞吐量推理引擎，社区最活跃
核心创新: PagedAttention
架构:
┌─────────────────────────────────┐
│ OpenAI-Compatible API Server │
├─────────────────────────────────┤
│ AsyncLLMEngine │
│ ├── Scheduler (连续批处理) │
│ ├── BlockManager (PagedAttn) │
│ └── ModelRunner │
├─────────────────────────────────┤
│ Attention Backend │
│ (FlashAttention / FlashInfer) │
├─────────────────────────────────┤
│ Model (PyTorch / custom ops) │
└─────────────────────────────────┘
特点:
✓ PagedAttention 原生支持
✓ 连续批处理
✓ 支持 NVIDIA + AMD GPU
✓ 量化支持广泛 (GPTQ/AWQ/FP8/BnB)
✓ 投机解码支持
✓ LoRA 动态加载
✓ 社区活跃，模型支持最广
✗ 不如 TensorRT-LLM 极致优化
✗ Python 为主，部分场景有 overhead3.2 TensorRT-LLM
定位: NVIDIA 官方推理引擎，极致性能
核心创新: 深度硬件集成 + 编译优化
架构:
┌─────────────────────────────────┐
│ Triton Inference Server │
├─────────────────────────────────┤
│ TensorRT-LLM Runtime (C++) │
│ ├── Inflight Batching │
│ ├── KV Cache Manager │
│ └── Beam Search / Sampling │
├─────────────────────────────────┤
│ TensorRT Engine (编译优化) │
│ (Kernel Fusion / FP8 / INT4) │
├─────────────────────────────────┤
│ CUDA Kernels (手写优化) │
└─────────────────────────────────┘
特点:
✓ NVIDIA 硬件深度优化（FP8 Tensor Core 等）
✓ C++ runtime，overhead 最小
✓ Kernel fusion 最激进
✓ 单请求延迟通常最低
✗ 仅支持 NVIDIA GPU
✗ 需要编译模型（build 过程复杂）
✗ 模型支持不如 vLLM 广
✗ 学习曲线陡峭3.3 SGLang
定位: 高效推理 + 结构化生成
核心创新: RadixAttention (前缀共享)
架构:
┌─────────────────────────────────┐
│ SGLang Frontend (Python DSL) │
├─────────────────────────────────┤
│ SGLang Runtime │
│ ├── RadixAttention │
│ ├── Continuous Batching │
│ └── Constrained Decoding │
├─────────────────────────────────┤
│ FlashInfer Kernels │
└─────────────────────────────────┘
RadixAttention 核心思想:
用 Radix Tree 管理所有请求的 KV Cache 前缀
相同前缀自动共享，不重复计算
请求 A: "You are a helpful assistant. 用户问题A"
请求 B: "You are a helpful assistant. 用户问题B"
→ system prompt 部分的 KV Cache 自动共享
特点:
✓ 前缀共享效率最高（RadixAttention）
✓ 结构化输出（JSON schema 约束）
✓ 多轮对话场景优势明显
✓ 性能接近甚至超过 vLLM
✗ 生态不如 vLLM 成熟
✗ 社区规模较小3.4 选型指南
| 场景 | 推荐引擎 | 原因 |
|---|---|---|
| 通用生产部署 | vLLM | 生态最好，模型支持最广 |
| NVIDIA 极致性能 | TensorRT-LLM | 硬件深度优化，延迟最低 |
| 多轮对话/Agent | SGLang | RadixAttention 前缀共享 |
| 本地/边缘部署 | llama.cpp (GGUF) | CPU 支持，资源占用小 |
| 快速实验 | Ollama | 一键部署，开箱即用 |
| AMD GPU | vLLM | ROCm 支持最好 |
4. 并行策略
当模型太大放不进单卡时，需要多卡并行：
4.1 Tensor Parallelism (TP)
把每一层的权重矩阵切分到多张卡:
单卡: W [4096, 4096] ← 放不下
TP=2: GPU 0: W[:, :2048] GPU 1: W[:, 2048:]
各算一半 → AllReduce 合并结果
特点:
- 每层都需要通信（AllReduce）
- 需要高速互联（NVLink）
- 降低单请求延迟
- 适合同一节点内的多卡4.2 Pipeline Parallelism (PP)
把不同层分配到不同卡:
PP=2: GPU 0: Layer 0-15 GPU 1: Layer 16-31
GPU 0 算完 → 传给 GPU 1 → GPU 1 算完
特点:
- 只在层边界通信（传激活值）
- 通信量小，可跨节点
- 有 pipeline bubble（GPU 空闲时间）
- 适合跨节点部署4.3 实际部署组合
Llama-3-70B (FP16 = 140GB) 部署方案:
方案 A: 2×A100-80GB, TP=2
每卡 70GB 权重 + KV Cache
NVLink 互联，延迟低
方案 B: 4×A100-40GB, TP=4
每卡 35GB 权重 + KV Cache
需要 NVLink
方案 C: 2×A100-80GB, TP=2 + INT4 量化
每卡 ~18GB 权重 + 大量 KV Cache 空间
可以跑更大 batch5. 性能指标与 Benchmark
5.1 核心指标
| 指标 | 含义 | 优化方向 |
|---|---|---|
| TTFT (Time to First Token) | 首 token 延迟 | Prefill 速度 |
| TPOT (Time Per Output Token) | 每 token 生成时间 | Decode 速度 |
| ITL (Inter-Token Latency) | token 间延迟 | 用户感知流畅度 |
| Throughput (tokens/s) | 系统总吞吐 | 服务容量 |
| Latency P99 | 99 分位延迟 | 尾延迟控制 |
5.2 典型 Benchmark 数据 (Llama-3-70B, A100-80GB×2)
vLLM TRT-LLM SGLang
TTFT (ms): ~150 ~120 ~140
TPOT (ms): ~35 ~28 ~33
Throughput: ~2800 ~3500 ~3000
(tokens/s,
32 concurrent)
注: 数据为近似值，实际取决于具体配置和版本6. 关键要点总结
┌──────────────────────────────────────────────────────────┐
│ 推理引擎核心认知 │
├──────────────────────────────────────────────────────────┤
│ 1. 推理引擎 = 前5章所有优化技术的系统集成 │
│ 2. FlashAttention 在 SRAM 中完成 attention，避免 HBM 瓶颈 │
│ 3. vLLM 生态最好，TRT-LLM 性能最强，SGLang 前缀共享最优 │
│ 4. TP 降延迟（同节点），PP 省互联（跨节点） │
│ 5. 选引擎看场景：通用选 vLLM，极致选 TRT-LLM │
│ 6. 看懂一个引擎的源码，就从"会用推理"变成"懂推理引擎" │
└──────────────────────────────────────────────────────────┘7. 延伸阅读
- Inside vLLM: Anatomy of a High-Throughput LLM Inference System — vLLM 官方架构深度解析
- vLLM vs TensorRT-LLM: Inference Runtime Guide — 两大引擎对比
- Top 6 LLM Inference Engines to Use in 2025 — 推理引擎全景对比
- vLLM vs TensorRT-LLM vs HF TGI v3 vs LMDeploy — 四大引擎 benchmark
- LLM Inference Optimization: vLLM and TensorRT-LLM — 含完整代码示例的优化指南
修改历史1 次提交
- docs(ai-systems): add comprehensive LLM inference documentationxiaocheng··
7c98505