大模型推理优化

一句话定义：大模型（LLM）推理优化，是围绕"自回归逐 token 生成"这一特性，把显存账本、批处理调度、并行与量化组合起来的系统工程——目标是让每个 token 的生成又快、又省、又能服务更多并发。

行业洞察：LLM 推理把传统推理的优化逻辑整个重写了。你的直觉"显存大头是权重"在 LLM 场景是错的——随并发与上下文长度增长，KV Cache 会吃掉比权重还多的显存；"batch 越大越划算"在自回归解码里也不成立，因为每个请求长度不同，静态 batching 会让整批人等最慢的那个。vLLM 之所以一战成名，正是把"显存管理"这个被忽视的问题做成了核心创新（PagedAttention），证明了系统层面的工程能带来数量级收益。这一节给你一套完整的"显存账本 + 优化工具箱"。

一、LLM 推理的三个特性

1. 自回归生成：一次前向只产生一个 token，下一个 token 依赖前一个——生成 N 个 token 要跑 N 次前向，无法一次算完；
2. KV Cache 吃显存：每个请求在生成过程中持续缓存注意力键值，随序列长度线性增长；
3. 解码阶段带宽受限：每次只算 1 个新 token，权重搬运占主导——这决定了量化、批处理对 LLM 尤其有效。

LLM 生成的时间线：
request: "部署模型的" + 生成中...
  预填充(Prefill)：一次前向算完整 prompt → 产出第一个 token（TTFT）
  解码(Decode)  ：每步 1 次前向 → 1 个 token（TPOT，逐 token 重复）

二、显存账本：权重 + 激活 + KV Cache

以 7B FP16 模型（权重约 14GB）为例，部署在 80GB A100 上的显存分配：

┌──────────────────────────────────────────────────┐
│  权重 ~14GB（FP16）                                │
│  激活 ~2GB（batch=16 时）                          │
│  KV Cache：随 并发 × 上下文长度 增长                 │
│    每请求每 token ≈ 2×层数×头数×头维度×2字节          │
│    例：32 层 × 128 头 × 128 维 × 2B ≈ 2MB/token     │
│    128 个并发请求、平均 2K token 上下文              │
│    ≈ 128 × 2048 × 2MB = 512GB（远超权重！）         │
└──────────────────────────────────────────────────┘

关键结论：KV Cache 不是"一点开销"，而是主要显存项。KV Cache 的估算公式：

KV Cache 大小 = 2 × 层数 × num_kv_heads × head_dim × 字节数(FP16=2) × 序列总长度

这就是为什么"支持多长的上下文、多少并发"是 LLM 部署的显存决策核心。缓解手段：KV Cache 量化（INT8/FP4）、GQA/MQA 架构（共享 KV head）、以及下一节的 PagedAttention 式动态管理。

三、核心优化：七件套

1. KV Cache 管理：PagedAttention

vLLM 论文（SOSP 2023）的核心思想：像操作系统管理内存一样管理 KV Cache——按固定大小的块（page）分配，块之间用索引表连接，消除"预留整段连续显存但只用一小块"的碎片浪费。收益：

• 显存利用率从 ~60% 提到 90%+；
• 同一块页可被多个请求共享（如 beam search 的公共前缀）；
• 吞吐提升最高 20 倍+（论文实测，长上下文场景）。系统论文解析见 论文精读：PagedAttention。

2. 连续批处理（continuous batching）

传统静态 batching：一批请求必须全部生成完才释放资源，短请求等长请求。连续批处理改为逐 token 粒度调度：

静态 batching：  请求A ████████
                请求B ████████████  ← B 短，但必须等 A 完，GPU 空等
连续 batching：  请求A ████ ✓（先完成先走）
                请求B ████████
                请求C       ████████  ← 新请求随时插入空位

这是 LLM 服务吞吐翻数倍的头号手段，vLLM、TGI、SGLang 都内置。

3. 投机解码（speculative decoding）

思路：用一个小草稿模型（draft model）一次猜出未来 K 个 token，再用大模型一次前向并行验证——对了就赚，错了退回。在 QPS 不受限（有空闲算力）时，加速比可达 2~3 倍，且输出与贪心解码一致。

draft 小模型：猜出 "你好世界" 4 个 token
大模型一次前向：同时验证这 4 个位置
  → 3 个对，1 个错 → 接受前 3 个，从错处重来
  → 平均每次前向"白赚" 2~3 个 token

4. 量化：LLM 的带宽解药

解码阶段每次前向都要把全部权重搬一遍，权重位宽直接决定速度：FP16 → INT4，权重搬运减 75%，生成速度近线性提升。LLM 量化方法与校准纪律见 量化，重点方法是 AWQ/GPTQ/GGUF。

5. 前缀缓存（prompt caching）

LLM 的 prompt 常含大段不变的系统提示与上下文。缓存"公共前缀"的计算结果（KV），命中的请求跳过预填充，TTFT 可降低 50%+。多轮对话场景尤其划算。vLLM 的 prefix caching、OpenAI 的 prompt caching 都是这个思路。

6. 预填充与解码分离（PD 分离）

预填充（compute-bound，吃算力）与解码（memory-bound，吃带宽）对硬件的需求不同。用一批 GPU 专跑预填充、另一批专跑解码，配合调度，可让两种资源都打满。适合超大规模、高并发场景，属于"高级玩法"。

7. 显存卸载（offload）

权重/激活按需在 GPU 与 CPU 内存间搬移，换取"小显存跑大模型"，代价是速度下降一个量级——只适合"能跑就行"的场景（如本地工具）。

四、并行：张量 / 流水 / 数据

并行方式	切分对象	通信频率	适用
张量并行（TP）	每层内的矩阵切成多卡	每层多次（极高）	单模型放不下，2~8 卡
流水并行（PP）	按层分组到多卡	每段一次（低）	超深模型、跨节点
数据并行（DP）	完整模型 × N 卡	仅在同步时	吞吐扩容，与 TP/PP 组合

工程要点：TP 通信密集，必须 NVLink/InfiniBand 高速互连；跨节点时优先 PP 而非 TP。深读 论文：并行与分布式推理。

典型 8×H100 部署 70B：
  TP=8（单节点内张量切分，NVLink 全互连）
  或 TP=4 × PP=2（2 节点，节点间低通信）
  实际以通信带宽压测为准

五、服务框架一句话定位

框架	定位	亮点
vLLM	高吞吐 LLM 服务	PagedAttention + continuous batching + prefix caching
Hugging Face TGI	与 HF 生态整合	部署简单、功能全
SGLang	极致调度（RadixAttention）	复杂 prompt 场景性能最强
llama.cpp	本地/CPU 友好	跨平台、GGUF 生态
TensorRT-LLM	NVIDIA 硬件极限	图编译 + 各类优化集成

选型考量：生态与性能的平衡。vLLM 是目前生产落地最广的默认选择，实战见 vLLM 大模型推理服务。

六、性能指标与成本优化

• TTFT：预填充速度决定，受输入长度与预填充算力影响；
• TPOT：解码速度决定，受权重位宽与带宽影响；
• 吞吐（tokens/s）：连续批处理 + 量化的直接受益者。

成本优化优先级：

① 连续批处理（吞吐 2~5×，几乎免费）
② 量化到 INT8/INT4（带宽减半/减 75%）
③ KV Cache 量化 + GQA（支持更多并发/更长上下文）
④ 前缀缓存（对话场景 TTFT 大降）
⑤ 投机解码（QPS 有余量时）
⑥ 弹性伸缩 + PD 分离（规模更大时）

七、典型部署架构

客户端
  │ 流式 SSE/WebSocket
  ▼
API 网关（鉴权/限流/路由）
  ▼
LLM 推理集群（K8s）
  ├─ vLLM 实例×N（每实例可加载多模型，按模型路由）
  │    └─ 张量并行（多卡时）
  ▼
监控：TTFT/TPOT/吞吐/GPU/显存（见 /concepts/monitoring）

权衡与取舍

决策点	选项	怎么选
吞吐 vs 延迟	大 batch vs 小 batch	在线交互保 TTFT；离线生成冲吞吐
框架	vLLM vs TensorRT-LLM vs llama.cpp	生产高并发 vLLM；NVIDIA 极限 TensorRT-LLM；本地 llama.cpp
量化位宽	FP16 vs INT8 vs INT4	带宽不够再降位宽，始终验收精度
上下文长度	越长越吃 KV Cache	按业务真实需求设限，别盲目追求 128K
单卡 vs 多卡	简单 vs 容量/吞吐	先量化 → 再 TP → 再 PP

一句话总结：LLM 推理的工程本质是管理好三本账——显存账本（KV Cache 是主角）、调度账本（连续批处理填满每一刻）、通信账本（并行别被互连拖死），三本账平衡了，吞吐和成本自然就对了。

延伸阅读

• 论文精读：PagedAttention —— KV Cache 分页管理的系统论文
• vLLM 大模型推理服务 —— vLLM 从部署到调优的实战
• 量化 —— GPTQ/AWQ/KV Cache 量化详解
• 论文：并行与分布式推理 —— TP/PP/DP 的论文级讲解
• 性能优化与容量规划 —— LLM 服务的压测与容量核算
• GPU 与硬件选型 —— 显存账本与多卡选型

参考资料

• Efficient Memory Management for Large Language Model Serving with PagedAttention（vLLM 论文，SOSP 2023）
• Orca: A Distributed Serving System for Transformer-Based Generative Models（continuous batching 来源）
• Fast Inference from Transformers via Speculative Decoding（Leviathan et al.）
• vLLM 官方文档
• NVIDIA TensorRT-LLM 文档