大模型推理部署：硬件、引擎、并行策略与连续批处理
摘要: 从硬件基础、推理引擎、并行策略和连续批处理四个维度系统阐述了大模型推理部署的技术体系。硬件层面，详细对比了主流GPU型号的显存与带宽指标，解析了显存需求与模型规模的关系公式，并介绍了 TPU/NPU 等专用加速器。推理引擎层面，深入分析了 vLLM 的 PagedAttention 显存管理、SGLang的 RadixAttention 前缀缓存、TensorRT-LLM 的极致 NVIDIA 优化、llama.cpp 的 CPU 推理能力以及 Ollama 的本地部署工具链。并行策略层面，对比了张量并行（TP）、流水线并行（PP）、数据并行（DP）和专家并行（EP）的切分方式、通信模式与适用场景。最后，详细阐述了 Continuous Batching 相比传统静态批处理的性能优势与动态调度策略，给出了 GPU 利用率优化与生产部署的成本估算参考。
核心问题
大模型训练完成后，如何高效地把它"跑起来"服务用户？本章从硬件到软件、从单卡到集群，系统讲解大模型推理部署的核心技术与实践考量。
1. 硬件基础
大模型推理对硬件的要求远超传统 Web 服务。理解硬件的各项指标，是做好部署规划的第一步。
1.1 GPU（图形处理器）
GPU 是大模型推理的核心计算硬件。理解不同 GPU 型号的差异，就像汽车工程师理解不同发动机型号一样重要。
主流 GPU 型号对比
| 型号 | 显存 (VRAM) | 显存带宽 | FP16 算力 (TFLOPS) | 功耗 | 典型用途 | 上市时间 |
|---|---|---|---|---|---|---|
| A100 80GB | 80 GB | 2.0 TB/s | 312 | 400W | 训练+推理主力 | 2021 |
| H100 80GB | 80 GB | 3.35 TB/s | 989 | 700W | 当前训练/推理旗舰 | 2023 |
| H200 141GB | 141 GB | 4.8 TB/s | 989 | 700W | 大显存推理 | 2024 |
| B200 192GB | 192 GB | 8.0 TB/s | ~2,250 | 1000W | 下一代旗舰 | 2025 |
| RTX 4090 | 24 GB | 1.0 TB/s | 83 | 450W | 本地实验/调试 | 2022 |
| A10 | 24 GB | 0.6 TB/s | 31 | 150W | 云端轻量推理 | 2021 |
| L40S | 48 GB | 0.86 TB/s | 91 | 350W | 中等负载推理 | 2023 |
如何选择 GPU？
对于一个需要部署的模型，显存是最关键的约束条件。 核心公式：所需显存 = 模型大小 + KV Cache + 其他开销
VRAM 与模型规模的关系（FP16 推理）
模型参数与显存需求的关系：
参数数量 × 2 字节（FP16）= 纯模型权重的显存
模型大小 权重显存 推荐总显存（含开销） 单卡能跑吗？
────────────────────────────────────────────────────
1B 2 GB 4 GB ✓ 几乎所有卡都能
3B 6 GB 10 GB ✓ RTX 3060(12GB) 即可
7B 14 GB 20 GB ✓ 单张 A10 / 双张 4090
8B 16 GB 22 GB ✓ 单张 A10
13B 26 GB 34 GB ✓ 单张 A100-40GB
34B 68 GB 80 GB ✓ 双张 A100-80GB
70B 140 GB 160 GB ✗ 需要 2-4 张 A100/H100
405B (Llama)810 GB 900 GB+ ✗ 需要 8+ 张 H100/B200为什么显存带宽比算力更重要（对于推理）
推理的本质：逐个生成 token
每生成一个 token 的过程：
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 从显存读权重 │ ──→ │ 做矩阵乘法 │ ──→ │ 得到下一个 │
│ (内存密集) │ │ (计算密集) │ │ token (输出) │
└──────────────┘ └──────────────┘ └──────────────┘
↑ ↑
时间占比 ~60-80% 时间占比 ~20-40%
因为大部分时间花在"搬运数据"上而不是"计算"上
所以显存带宽比理论算力更能决定推理速度！
类比：工厂流水线
算力 = 工人处理速度
显存带宽 = 原材料传送带速度
传送带太慢，工人再快也只能等待
这就是为什么 H100 带宽升级对推理提升显著1.2 TPU / NPU（专用 AI 加速器）
除了 NVIDIA GPU，不同厂商也推出了各自的 AI 加速芯片。
- TPU（Tensor Processing Unit）：Google 自研，Cloud TPU v5p 单芯片提供 459 TFLOPS BF16 算力，适合大规模训练和推理
- Apple Neural Engine：集成在 Apple Silicon（M1/M2/M3/M4）中，ANe 提供高效的本地推理，是 llama.cpp 在 Mac 上运行的关键加速硬件
- 华为昇腾（Ascend）：国产 NPU，910B 对标 A100，用于国内推理部署场景
- 高通 Hexagon NPU：移动端推理，让大模型在手机上运行成为可能
GPU vs TPU vs NPU 的选择考量
| 维度 | GPU (NVIDIA) | TPU (Google) | NPU (国产/移动端) |
|---|---|---|---|
| 生态成熟度 | 最高（CUDA） | 高（JAX/TF） | 发展中 |
| 硬件自由度 | 云/自建均可 | 仅 Google Cloud | 受限 |
| 软件兼容性 | 几乎所有框架 | PyTorch/XLA 适配中 | 需要专门适配 |
| 成本 | 高（供需紧张） | 中（预付费/包年） | 中低 |
| 推理场景 | 通用最佳 | 大规模高吞吐 | 端侧/国产替代 |
1.3 显存（VRAM）与模型规模的关系详解
GPU 显存在推理阶段的消耗可以分为几个部分：
┌─────────────────────────────────────────────────┐
│ 显存消耗全景图（推理时） │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────┐ │
│ │ 1. 模型权重（Model Weights） │
│ │ 参数数 × 每参数字节数 │
│ │ 例：7B FP16 = 7B × 2B = 14 GB │
│ │ 例：7B INT4 = 7B × 0.5B = 3.5 GB │
│ └──────────────────────────┘ │
│ │
│ ┌──────────────────────────┐ │
│ │ 2. KV Cache（键值缓存） │
│ │ 对每个已生成的 token，需要存储其 K 和 V 矩阵 │
│ │ 公式：2 × 层数 × 隐藏维度 × token数 × 字节/元素 │
│ │ 例：7B 模型，4096 token 上下文 ≈ 2.5 GB │
│ │ 例：7B 模型，128K token 上下文 ≈ 80 GB！ │
│ └──────────────────────────┘ │
│ │
│ ┌──────────────────────────┐ │
│ │ 3. 激活值（Activations） │
│ │ 前向传播中的中间计算结果 │
│ │ 相对较小，批量推理时累积 │
│ └──────────────────────────┘ │
│ │
│ ┌──────────────────────────┐ │
│ │ 4. 框架开销（CUDA context 等） │
│ │ 通常固定 0.5-2 GB │
│ └──────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘量化：让大模型"瘦身"跑起来
量化是将模型参数从高精度（FP16/BF16）转为低精度（INT8/INT4），大幅降低显存占用。
量化精度对比：
精度 每参数字节 7B 权重显存 70B 权重显存 质量影响
──────────────────────────────────────────────────────────
FP32 4 字节 28 GB 280 GB 基准（极少使用）
FP16/BF16 2 字节 14 GB 140 GB 几乎无损（标准用法）
INT8 1 字节 7 GB 70 GB 微小损失（0.1-0.3%）
INT4 0.5 字节 3.5 GB 35 GB 轻微损失（推理可接受）2. 推理引擎
推理引擎是连接模型与硬件的软件层，它负责将模型的数学运算高效地映射到硬件上执行。选择什么推理引擎，直接影响服务的吞吐量、延迟和成本。
2.1 vLLM（PagedAttention / Continuous Batching）
vLLM 是 UC Berkeley 开源的推理框架，目前是社区中最主流的 LLM 推理引擎之一。
核心创新：PagedAttention
PagedAttention 借鉴了操作系统中的虚拟内存分页思想，解决了 KV Cache 的内存管理问题。
传统 KV Cache 管理的问题：
┌─────────────────────────────────────────────┐
│ 为每个请求预留连续的最大上下文窗口的显存 │
│ │
│ 请求 A（32K max）: ████████████████████████ │
│ 实际上只用了 2K: ██░░░░░░░░░░░░░░░░░░░░░ │ ← 大量浪费
│ │
│ 请求 B（32K max）: ████████████████████████ │
│ 实际用了 30K: ████████████████████░░░░ │
│ │
│ 浪费的显存可高达 80% │
└─────────────────────────────────────────────┘
PagedAttention 的解决方案：
┌─────────────────────────────────────────────┐
│ 将 KV Cache 分成固定大小的"页"（Block） │
│ │
│ 物理显存： ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐ │
│ │A │B │A │A │C │B │B │A │C │C │ │ ← 按需分配
│ └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘ │
│ │
│ 请求 A 的 KV Cache 分布在第 1,3,4,8 页 │ ← 分散但高效
│ 请求 B 的 KV Cache 分布在第 2,6,7 页 │
│ 请求 C 的 KV Cache 分布在第 5,9,10 页 │
│ │
│ 显存利用率从 20-40% 提升到接近 100% │
└─────────────────────────────────────────────┘PagedAttention 带来的收益
- 显存利用率从 20-40% 提升到 90%+
- 支持更大的批量（batch size）——因为单个请求的显存"押金"降低了
- 吞吐量提升 2-4 倍（在同等硬件上）
- 使得更长的上下文窗口在推理部署中变得可行
Continuous Batching（连续批处理）
详见第 4 节。vLLM 原生支持 Continuous Batching，在 PagedAttention 的基础上进一步提升了 GPU 利用率。
2.2 SGLang（RadixAttention）
SGLang 是一个新兴的 LLM 推理和服务框架，由斯坦福等机构开发。
核心创新：RadixAttention
RadixAttention 是一种前缀感知的 KV Cache 复用技术。
RadixAttention 的核心洞察：
多个用户的 prompt 通常有共同的前缀：
用户 A："请翻译以下内容为法语：{长文本 A}"
用户 B："请翻译以下内容为法语：{长文本 B}"
用户 C："请总结以下内容： {长文本 A}"
三个请求共享前缀 "请翻译以下内容为法语：" 或 "请"
传统方式：为每个请求单独计算 + 存储 KV Cache
→ 前缀部分重复计算 + 重复存储
RadixAttention：
用 Radix Tree（基数树）组织 KV Cache，自动检测和复用公共前缀
┌─────────────────────────────────────────────┐
│ Radix Tree 结构 │
│ │
│ ┌── "请翻译以下内容为法语：" │
│ │ │ │
│ "请" ─┤ ├── {文本 A 的 KV} │
│ │ └── {文本 B 的 KV} │
│ │ │
│ └── "请总结以下内容：" │
│ └── {文本 A 的 KV} │
│ │
│ "请" 的 KV Cache 被三个请求共享，只计算一次 │
└─────────────────────────────────────────────┘RadixAttention 的适用场景
- 多轮对话（每轮的 system prompt 相同，前缀可复用）
- Few-shot prompting（示例部分是相同的）
- 批量相似请求（如翻译服务的相同系统指令）
- 代理系统中的重复模板 prompt
SGLang 的其他特点
- 内置 Structured Generation（结构化输出：JSON / 正则约束）
- 支持前端语言 DSL，便于构建复杂推理 pipeline
- 与 vLLM 各有优势：vLLM 更成熟、社区更大；SGLang 在前缀复用和结构化生成上有独到之处
2.3 TensorRT-LLM
TensorRT-LLM 是 NVIDIA 官方出品的 LLM 推理优化框架，将各种优化技术封装在一个工具包中。
核心优化技术
| 技术 | 说明 | 收益 |
|---|---|---|
| Kernel Fusion | 将多个小算子融合为一个大算子，减少显存读写 | 20-50% 加速 |
| KV Cache 量化 | 将 KV Cache 从 FP16 量化为 INT8/FP8 | 减少 50-75% KV Cache 显存 |
| In-flight Batching | NVIDIA 版本的 Continuous Batching | 2-5x 吞吐提升 |
| Multi-GPU Tensor Parallelism | 内置的 TP 支持（详见 3 节） | 大模型单卡放不下时的方案 |
| FP8/INT4 推理 | NVIDIA 新一代 GPU（H100+）原生支持的量化 | 显存减半，加速 2x |
TensorRT-LLM 的优势与劣势
优势：
✓ NVIDIA 官方维护，硬件适配最好
✓ 在 NVIDIA GPU 上通常是性能天花板
✓ 企业级支持和文档
劣势：
✗ 仅支持 NVIDIA GPU
✗ 编译/部署流程比 vLLM 复杂
✗ 开源程度不如社区方案
✗ 模型支持需要手动 ONNX 转换选择建议
- 如果追求极致的 NVIDIA GPU 推理性能 → TensorRT-LLM
- 如果追求灵活性和对多种硬件的支持 → vLLM
- 如果场景涉及大量前缀复用 → SGLang
2.4 llama.cpp（CPU 推理）
llama.cpp 是一个从头用 C/C++ 编写的 LLM 推理库，专注于在消费级硬件（甚至无 GPU）上运行大模型。
核心特色：纯 CPU 推理 + 极致量化
llama.cpp 支持的量化格式：
格式 每参数位宽 7B 模型大小 质量评估
─────────────────────────────────────────────
Q4_0 4.5 bit 4.0 GB 较好
Q4_K_M 4.5 bit 4.2 GB 更好（推荐）
Q5_K_M 5.5 bit 5.1 GB 好
Q6_K 6.5 bit 6.1 GB 非常好
Q8_0 8.5 bit 7.7 GB 几乎无损
F16 16 bit 13.5 GB 无损
GGUF 格式：llama.cpp 使用的模型文件格式
将模型权重 + 配置 + tokenizer 打包为一个文件Apple Silicon 上的特殊优化
llama.cpp 在 Apple Silicon（M1/M2/M3/M4）上利用 Metal API 进行 GPU 加速，8B 模型在 MacBook Pro（M3 Max）上可达到 30-50 tokens/s，这对于本地推理来说已经非常可用。
MacBook 上的运行体验（llama.cpp + Q4_K_M 量化）：
MacBook Pro M3 Max (36GB RAM)
├── Llama 3.1 8B： ~35 tokens/s ← 流畅可用
├── Qwen 2.5 14B： ~18 tokens/s ← 可用
└── Qwen 2.5 32B： ~8 tokens/s ← 勉强可用
MacBook Air M2 (8GB RAM)
├── Llama 3.2 3B： ~25 tokens/s ← 流畅
├── Qwen 2.5 7B： ~10 tokens/s ← 可用但慢
└── 更大模型： ← 内存不够会疯狂 swap使用场景
- 本地隐私敏感场景（数据不出本地）
- 开发调试（快速测试模型行为，不需要启动远程服务器）
- 低成本边缘部署
- 对延迟不敏感的离线批处理
2.5 Ollama（本地部署工具）
Ollama 是基于 llama.cpp 的上层封装，让本地部署大模型变得像 ollama run llama3 一样简单。
Ollama 做对了什么：
安装体验：
$ curl -fsSL https://ollama.com/install.sh | sh
（一行命令安装）
使用体验：
$ ollama run llama3.2
>>> 你好，请用中文介绍你自己
（直接开始对话）
API 体验：
$ ollama serve # 启动本地 API 服务器
$ curl http://localhost:11434/api/generate -d '{
"model": "llama3.2",
"prompt": "你好"
}'
（兼容 OpenAI API 格式）
模型管理：
$ ollama pull qwen2.5:7b # 下载模型
$ ollama list # 列出本地模型
$ ollama rm qwen2.5:7b # 删除模型Ollama 的模型定制（Modelfile）
# Modelfile 示例
FROM qwen2.5:7b
# 设置系统提示
SYSTEM "你是一位精通中文的 AI 助手，回答简洁明了。"
# 设置参数
PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER num_ctx 8192
# 自定义停止词
PARAMETER stop "<|im_end|>"
PARAMETER stop "</s>"推理引擎对比总结
| 引擎 | 硬件要求 | 性能 | 易用性 | 最佳场景 |
|---|---|---|---|---|
| vLLM | NVIDIA GPU | 高 | 中 | 云端服务、高并发 |
| SGLang | NVIDIA GPU | 高 | 中 | 前缀复用、结构化输出 |
| TensorRT-LLM | NVIDIA GPU | 最高 | 低 | 极致性能追求 |
| llama.cpp | CPU / Apple Silicon / 多种 | 中 | 中 | 本地、隐私、低成本 |
| Ollama | 同上（封装 llama.cpp） | 中 | 最高 | 个人使用、快速体验 |
3. 并行策略
当单张 GPU 装不下整个模型时（70B 模型在 FP16 需要约 140 GB 显存，单张 H100 只有 80 GB），就需要将模型拆分到多张 GPU 上。这就是并行策略解决的问题。
3.1 四种并行策略一览
┌─────────────────────────────────────────────────────────────┐
│ 并行策略族 │
├───────────────┬───────────────┬───────────────┬──────────────┤
│ 数据并行(DP) │ 张量并行(TP) │ 流水线并行(PP) │ 专家并行(EP) │
│ 分数据 │ 分算子 │ 分层 │ 分专家 │
├───────────────┼───────────────┼───────────────┼──────────────┤
│ 每个 GPU 有 │ 矩阵乘法被 │ 前几层在 │ MoE 模型中 │
│ 完整模型副本 │ 切分到多个 │ GPU0，中几层 │ 不同专家分布 │
│ │ GPU │ 在 GPU1... │ 在不同 GPU │
├───────────────┼───────────────┼───────────────┼──────────────┤
│ 通信量低 │ 通信量极高 │ 通信量中 │ 通信量中 │
│ 扩展性好 │ 仅限单机内 │ 跨机可扩展 │ MoE 专属 │
└───────────────┴───────────────┴───────────────┴──────────────┘3.2 Tensor Parallelism（张量并行）
把单个矩阵乘法运算拆分到多个 GPU 上并行计算。
张量并行（TP=2 为例）：
原始矩阵乘法（单 GPU）：
X W Y
┌────┐ ┌────────┐ ┌────┐
│ │ × │ │ = │ │
│ d │ │ d × d │ │ d │
│ │ │ │ │ │
└────┘ └────────┘ └────┘
GPU 0 承担全部计算
TP=2 按列切分：
X W₁ W₂
┌────┐ ┌────┐ ┌────┐
│ │ × │d×d/2│ │d×d/2│
│ d │ └────┘ └────┘
│ │ GPU 0 GPU 1 ← 每个 GPU 只算一半列
└────┘ │ │
▼ ▼
┌────┐ ┌────┐
│d/2 │ │d/2 │ ← 部分结果
└────┘ └────┘
│ │
└────┬────┘
▼
┌────────┐
│ d │ ← All-Reduce 合并结果
└────────┘
通信模式：All-Reduce，每次矩阵乘法后都需要同步 → 通信量极高TP 的关键特征
- 切分的是计算（矩阵乘法本身），而不是数据或层
- 每次前向传播涉及多次 All-Reduce 通信 → 需要极高带宽的互联（NVLink/NVSwitch）
- 适合单机多卡（同一台机器内的 GPU 通过 NVLink 互联，带宽可达 900 GB/s）
- 不适合跨机（网络带宽通常只有 100-400 Gbps，远不如 NVLink）
TP 的适用范围：
TP=2：常用，两张 H100 可推理 140GB 的 70B 模型
TP=4：可推理更大的模型，但通信开销显著增加
TP=8：单机 8 卡的极限，通信开销极其显著
一般不建议 TP > 8，效率折损严重3.3 Pipeline Parallelism（流水线并行）
把模型的不同层分给不同 GPU，数据像流水线一样依次流过。
流水线并行（PP=4）：
时间 →
───────────────────────────────────────────────→
GPU 0: [Batch 1] [Batch 2] [Batch 3]
层 1-8 层 1-8 层 1-8
│ │ │
GPU 1: [Batch 1] [Batch 2] [Batch 3]
层 9-16 层 9-16 层 9-16
│ │ │
GPU 2: [Batch 1] [Batch 2] [Batch 3]
层 17-24 层 17-24 层 17-24
│ │ │
GPU 3: [Batch 1] [Batch 2] [Batch 3]
层 25-32 层 25-32 层 25-32
GPU 利用率问题：
│
├── 初始阶段：GPU 0 忙，GPU 1-3 空闲 ← "冷启动"
├── 稳定阶段：4 个 GPU 都在忙 ← 理想状态
├── 结束阶段：GPU 3 忙，GPU 0-2 空闲 ← "排空"
│
└── 有 bubble（气泡）：GPU 空闲等待的时间占比PP 的关键特征
- 切分的是层（layer-wise）
- 通信量相对低：只需在层边界传输激活值（大小 = batch_size × hidden_dim）
- 适合跨机扩展：即使网络带宽低，也能正常运作
- Bubble 问题：流水线有空闲期，可通过 Micro-Batching 缓解
Micro-Batching 缓解 Bubble：
将一个大 Batch 拆分成多个 Micro-Batch：
Batch = [M1, M2, M3, M4]
GPU 0: [M1] [M2] [M3] [M4]
GPU 1: 空闲 [M1] [M2] [M3] [M4]
GPU 2: 空闲 空闲 [M1] [M2] [M3] [M4]
GPU 3: 空闲 空闲 空闲 [M1] [M2] [M3] [M4]
微批次越多，bubble 占比越小（但通信次数增多）3.4 Data Parallelism（数据并行）
每个 GPU 拥有一份完整的模型副本，处理不同的输入数据。
数据并行（DP=4）：
输入 Batch = [样本1, 样本2, 样本3, 样本4, 样本5, 样本6, 样本7, 样本8]
│
┌──────────────┼──────────────┬──────────────┐
▼ ▼ ▼ ▼
GPU 0 GPU 1 GPU 2 GPU 3
[1,2] [3,4] [5,6] [7,8]
│ │ │ │
前向传播 前向传播 前向传播 前向传播
│ │ │ │
本地梯度 本地梯度 本地梯度 本地梯度
│ │ │ │
└──────────────┴──────┬───────┴──────────────┘
│
All-Reduce 平均梯度
│
┌────────────┼────────────┐
▼ ▼ ▼
GPU 0 GPU 1 GPU 3 ← 所有 GPU 更新为相同参数DP 的关键特征
- 适用于训练，推理时通常不需要
- 要求每个 GPU 能装下完整模型 → 对大模型不实用
- 对于推理场景，如果不做模型切分，DP 意味着每个 GPU 复制一份模型 → 各 GPU 独立服务不同请求
3.5 Expert Parallelism（专家并行，MoE 专用）
MoE（Mixture of Experts）模型中有多个"专家"子网络，每次只激活其中一部分。EP 将不同的专家分布到不同的 GPU 上。
专家并行（EP=4，8 个专家为例）：
GPU 0: Expert 0, Expert 1
GPU 1: Expert 2, Expert 3
GPU 2: Expert 4, Expert 5
GPU 3: Expert 6, Expert 7
一次前向传播：
┌──────────────────────────────────────────────┐
│ Token ──→ Router（门控网络） │
│ │ │
│ "这个 token 应该去 Expert 2 和 Expert 5" │
│ │ │
│ ┌────────┼────────┐ │
│ ▼ │ ▼ │
│ GPU 1 │ GPU 2 │
│ Expert 2 │ Expert 5 │
│ │ │ │ │
│ └────────┼────────┘ │
│ ▼ │
│ 加权合并输出（All-to-All 通信） │
└──────────────────────────────────────────────┘EP 的通信模式
- All-to-All 通信：每个 GPU 可能需要向其他所有 GPU 发送/接收 token
- 通信量取决于 MoE 的 top-k 设置（通常 k=2，每个 token 去 2 个专家）
- 是 MoE 架构的核心优化方向
3.6 混合并行（3D Parallelism）
在实际生产部署中，常常组合使用多种并行策略。
3D 并行示例：部署一个 70B 模型在 8 个节点、每节点 8 张 GPU 上
PP=8（8 级流水线，每级在 1 个节点上）
├── 节点 0：层 1-10
├── 节点 1：层 11-20
├── ...
└── 节点 7：层 71-80
每节点内部 TP=4（4 张 GPU 做张量并行）
├── GPU 0,1,2,3 切分相同层的权重
DP=2（2 份数据拷贝）
├── 可用于提高吞吐
综合：8 节点 × 8 GPU = 64 GPU
交叉通信复杂但高效4. Continuous Batching（连续批处理）
Continuous Batching 是大模型推理服务性能优化的关键技术，直接决定了服务能同时处理多少用户、每个用户的响应有多快。
4.1 传统批处理 vs 连续批处理
传统（Static）Batching 的问题
传统批处理：
时间 →
──────────────────────────────────→
请求到达时间：
A 先到 ────────────────────────────────
B 后到 ──────────────────────────
C 最后到 ────────────────
传统批处理的工作方式：
[等一批满] → [开始推理] → [等待全部完成] → [返回结果]
批次 1: [A, B, C] ← A 必须等 C 到了才开始
████████████
推理完成，但 A 等了很久
如果 C 生成长度是 A 的 5 倍：
批次 1: [A██████░░░░░░░░░░░░░░░░░░]
████████████████████████████
完成 等待 → A 已经完成了，但 GPU 还在
为 B 和 C 工作，A 的结果却
不能提前返回！Continuous Batching 如何工作
连续批处理：
时间 →
──────────────────────────────────────→
请求到达即可加入，完成后立即退出
[等待队列:] [推理中:] [已完成:] [返回:]
时刻 1: A 到达 → [A 开始推理]
时刻 2: B 到达 → [A ████░░░░] 完成 A → 返回给用户，B 继续
→ A 不用等待 B！
时刻 3: C 到达 → [B █████████████] B 完成 → 返回给用户
→ 加入 C 开始推理
时刻 4: → [C ████████] C 完成 → 返回给用户直观对比
场景：3 个请求，生成长度分别为 10, 50, 30 tokens
静态批处理（batch_size=3）：
────────────────────────────────────────
│A│B │
│ │████████████████████████████████████████│ → 总耗时 = 50 tokens 的时间
│ │C │ A 在 10 tokens 处完成，
└─┴──────────────────────────────────────┘ 但结果要到 50 才返回
等待时间 = 40 tokens
连续批处理（evolving batch）：
────────────────────────────────────────
│A│ A 完成立即返回
│ │B─────────────────────────
│ │ │C─────────────────
│ │ │ │新请求D───
└─┴──┴──┴──────────────────────────────
A 10 tokens 完成 → 立即返回
C 30 tokens 完成 → 立即返回
B 50 tokens 完成 → 返回
延迟改善：A 的响应延迟减少约 70%
GPU 利用率始终接近 100% → 吞吐提升 2-5 倍4.2 动态请求调度
Continuous Batching 的核心是调度器——它决定了每时每刻哪些请求在 GPU 上执行。
调度器的工作循环
while True:
1. 接收新的推理请求，放入等待队列
2. 检查当前正在推理的请求是否已完成
→ 完成的移出，返回结果给用户
3. 检查显存是否还有空间
→ 有空间就从等待队列中取出请求，开始推理
4. 对当前活跃请求执行一个 step（生成一个 token）
5. 回到步骤 1调度策略对比
| 策略 | 规则 | 适用场景 | 优劣 |
|---|---|---|---|
| FCFS（先到先服务） | 最简单的轮询 | 通用 | 公平但非最优 |
| Priority-based | 按优先级队列 | 付费分层 / VIP | 可商业化，但可能饿死低优 |
| Shortest-first | 预测生成长度，优先短请求 | 延迟敏感 | 短请求响应极快，长请求可能饿死 |
| Fairness-aware | 混合策略，确保不饿死 | 通用服务 | 最推荐，平衡性好 |
调度中的核心挑战：Preemption（抢占）
场景：一个请求生成了 5000 tokens 还没停，新来了 100 个短请求
问题：长请求占着 GPU，短请求全部在排队
解决方案 —— Preemption（抢占）：
1. 将长请求的 KV Cache 保存到 CPU 显存或内存
2. 暂停长请求
3. 处理短请求
4. 短请求处理完毕后，加载长请求的 KV Cache 恢复执行
这就像操作系统的进程切换——只是"上下文"
变成了 KV Cache（可能几 GB 到几十 GB）4.3 GPU 利用率最大化
GPU 利用率是推理部署的核心经济指标
按小时付费的 GPU 实例：A100 约 $1-2/小时/卡，H100 约 $2-4/小时/卡
GPU 利用率 30% → 70% 的钱在烧空气
GPU 利用率 90% → 几乎每一分钱都在产生价值
年度成本差异（单卡）：
30% 利用率：$17,520/年 中只有 $5,256 在真正工作
90% 利用率：$17,520/年 中有 $15,768 在真正工作达到高 GPU 利用率的策略
策略 1：增大并发数
─────────────────
增加同时在 GPU 上运行的请求数量。
需要 PagedAttention 来高效管理显存。
策略 2：混合长短请求
─────────────────
长请求（摘要、翻译长文档）→ 保证 GPU 始终有事做
短请求（对话、问答） → 在长请求间隙快速处理
就像餐厅：大桌慢菜 + 小桌快菜，厨房永远不空
策略 3：Batching 相关的 CUDA Kernel 优化
─────────────────
现代推理引擎（vLLM / TensorRT-LLM）将多个请求
的矩阵乘法融合为一个大的 GEMM 操作：
传统：Request 1 × W, Request 2 × W, Request 3 × W
→ 3 次小矩阵乘法，GPU 算不满
优化：Concat([R1, R2, R3]) × W
→ 1 次大矩阵乘法，GPU 满载
这个过程叫"packing"或"kernel fusion"实际吞吐量数据参考（单张 A100-80GB，Llama 2 7B）
| 配置 | 吞吐量 (tokens/s) | 平均延迟 (s) | GPU 利用率 |
|---|---|---|---|
| 静态批处理 batch=1 | ~50 | ~0.02 | ~30% |
| 静态批处理 batch=8 | ~200 | ~0.04 | ~60% |
| Continuous Batching | ~400 | ~0.03 | ~91% |
| Continuous Batching + FP8 量化 | ~700 | ~0.02 | ~93% |
延迟 vs 吞吐量的权衡
这是部署中最经典的权衡。
吞吐优先配置（高 batch size）：
→ 同时处理很多请求，GPU 利用率高
→ 但每个请求的延迟增加（GPU 被分摊）
→ 适合：批量数据处理、离线评估
延迟优先配置（低 batch size）：
→ 只同时处理少量请求，GPU 利用率低
→ 但每个请求响应很快
→ 适合：实时对话、交互式应用
推荐策略：SLA 驱动的自适应调度
→ 设定延迟目标（如 p95 < 500ms）
→ 在不超出延迟预算的前提下，尽可能增大 batch
→ 动态调整成本实战参考：部署一个 7B 模型到生产环境
场景：为 1000 个日活用户提供对话服务
估算公式：
- 平均每个请求：输入 500 tokens + 输出 200 tokens
- 峰值 QPS：20 请求/秒（按日活 2% 的同时在线估算）
- 单卡 A100-80GB 约能支撑：15-25 QPS（Llama 7B + vLLM + Continuous Batching）
硬件配置：
方案 A：2x A100-80GB（一主一备） → 每月成本约 $1,500-3,000（云端）
方案 B：单卡 A100-80GB + 限流 → 每月成本约 $1,000-2,000（需容忍偶尔排队）
对于 70B 模型：
- 需要 2-4 张 A100/H100
- 云端月成本约 $5,000-15,000
- 推荐使用模型量化（INT4）来降低到 2 卡可运行5. 结束语
大模型推理部署是一个涉及"硬件选型 × 推理引擎 × 并行策略 × 批处理优化"的综合性工程问题。不存在放之四海而皆准的最优配置——最佳方案始终取决于具体的模型规模、流量特征、延迟约束与成本预算。
核心优化思路在于：借助 PagedAttention 等显存管理技术提升单卡利用率，通过 Continuous Batching 最大化吞吐能力，并在必要时引入并行策略实现水平扩展。值得注意的是，这一领域的技术实践正在快速迭代演进，建议持续关注 vLLM、SGLang 等主流开源项目的最新进展。