03 推理性能优化

学习目标：能用 TTFT、TPOT、tokens/s、GPU 利用率、显存、队列长度分析性能瓶颈；能解释 PD 分离、MoE+EPLB、分级 KV 分别优化的是什么问题；掌握量化选型和参数调优实战。 重点度：必会（25 分，全路线分值最高）

概述#

模型能返回结果不代表能线上使用。并发上来后迎接你的是：

首 token 很慢 / 输出 token 很慢 / 吞吐上不去
GPU 利用率低 / 显存占用高 / 请求排队严重 / 成本过高

这一章的核心问题是：如何理解和优化 LLM 推理的延迟、吞吐、显存和成本？

2026 年这一章有三个必须掌握的新主流：PD 分离（Prefill/Decode Disaggregation）、MoE 推理 + EPLB、分级 KV Cache。它们已经从加分项升级为生产主流，是面试和架构设计的标准答案。

核心指标#

延迟指标：TTFT 与 TPOT#

                    TTFT                   TPOT × N
                ┌──────────┐    ┌─────────────────────────┐
                │ Prefill  │    │   Decode（逐 token）     │
                └──────────┘    └─────────────────────────┘
                首 token 延迟      每 token 平均延迟

TTFT 和 TPOT 是两个独立维度：TTFT 高不一定 TPOT 高，反之亦然。它们是不同阶段不同瓶颈的体现。

SLA 典型目标：

• 实时对话：TTFT < 1s，TPOT < 50ms
• 代码补全：TTFT < 200ms，TPOT < 30ms
• 离线批处理：TTFT 无要求，吞吐优先

吞吐指标：tokens/s 与 QPS#

吞吐 vs 延迟的 trade-off：增大 batch size 提升吞吐，但每个请求的 TPOT 也上升（更多 token 竞争显存带宽）。需要在吞吐和延迟间找平衡点。

P50 / P95 / P99 延迟#

长尾延迟比平均值更重要：

• P50：一半请求的延迟低于此值（正常情况）
• P95：95% 请求的延迟低于此值（长尾用户体感）
• P99：99% 请求的延迟低于此值（SLA 关键指标）

为什么 P99 比 P50 重要：100 万用户里 P50 影响的是 50 万人的日常体验，P99 影响的是 1 万人最差体验——这 1 万人最可能投诉和流失。

资源指标#

KV Cache：推理显存的核心消耗#

为什么需要 KV Cache#

LLM 的每一层 Transformer 都需要计算 Attention。以 Decode 阶段为例，生成第 N+1 个 token 时，需要计算它与前 N 个 token 的注意力分数。如果不缓存，每次都要重新计算前 N 个 token 的 K 和 V 矩阵——重复计算量极大（O(n²) 复杂度）。

KV Cache 的做法：在 Prefill 阶段把每一层的 K 和 V 缓存在显存中，Decode 阶段直接读取，避免重复计算。

KV Cache 显存估算公式#

每 token 的 KV Cache 大小 =
    2 × num_layers × num_kv_heads × head_dim × dtype_bytes

以 LLaMA 3.1 70B（GQA）为例：

num_layers = 80
num_kv_heads = 8   （GQA，用了 8 个 KV head 而非 64 个 attention head）
head_dim = 128

FP16: 2 × 80 × 8 × 128 × 2 = 327,680 byte/token ≈ 320 KB/token
10 万 token = 32 GB 显存

GQA（Grouped Query Attention） 是现代模型的标配——多个 Q head 共享一组 K/V head，大幅减少 KV Cache 占用量。

KV Cache 压缩技术对比#

KV Cache 为什么大量占显存#

• 每一层都要存（80 层就 ×80）
• 每个请求独立一份（10 个并发 ×10）
• 长上下文是灾难：128K prompt × 320KB/token = 40GB

这就是为什么长上下文推理中，KV Cache 经常成为显存"第一消耗者"——占比超过模型权重是常态。所有降本优化（MLA、FP8 KV、分级 KV、PD 分离）都围绕 KV Cache 展开。

Continuous Batching：让 GPU 永不停机#

问题：Static Batching 的浪费#

传统 Static Batching 的做法：一批请求打包，等全部完成，再处理下一批。问题是——有的回复 10 个 token，有的回复 500 个。短请求完成后 GPU 就干等长请求。

Static Batching：
时间步 1-10:   [A, B, C] 都在生成
时间步 11:     A 完成（10 token），B 和 C 继续
时间步 11-100: A 的位置空着，GPU 算力浪费
时间步 100:    B 完成（100 token），C 继续
时间步 500:    C 完成，整个 batch 结束

解法：Iteration-level Scheduling#

Continuous Batching（也叫 Inflight Batching）每生成一个 token 就检查一次：完成的出队，新的入队。

时间步 1: [请求A, 请求B, 请求C] → 各生成第1个token
时间步 2: [请求A, 请求B, 请求C] → 各生成第2个token
时间步 3: 请求A完成（EOS）→ 立即把请求D加入
         [请求B, 请求C, 请求D] → 继续推理

效果：同等硬件，吞吐量提升 3-10 倍（取决于请求长度的方差）。请求长度方差越大，提升越明显。

实现：vLLM、SGLang、TRT-LLM（叫 Inflight Batching）都原生支持。

PagedAttention 与 RadixAttention#

PagedAttention（vLLM）#

核心思想：类比操作系统分页，把 KV Cache 切成固定大小的 Block（默认 16 token），通过 Block Table 映射，不要求连续显存。

解决的问题：

• KV Cache 的内部碎片（预分配固定大小 → 按需分页分配）
• 显存利用率从 ~60% 提升到 96%+
• 支持多个请求共享相同前缀的 KV block（Prefix Sharing）

Block Table 机制：

逻辑视图（请求看到的）：  物理视图（实际显存）：
  Block 0: token[0-15]    Block 0 → Physical Block 7
  Block 1: token[16-31]   Block 1 → Physical Block 23
  Block 2: token[32-47]   Block 2 → Physical Block 5
（连续）                  （不连续，通过 Block Table 映射）

RadixAttention（SGLang）#

核心思想：把 KV Cache 组织成 Radix Tree（基数树），不同请求可共享任意长度的公共前缀。

             [root]
              │
      ┌───────┴───────┐
   system A         system B
   (固定 6K token)   (固定 4K token)
      │               │
   ┌──┴──┐         ┌──┴──┐
 user1  user2     user3  user4
  │     │         │     │
 ...   ...       ...   ...

解决的问题：

• 前缀共享粒度从 block 级升级到 token 级
• 请求完成后 KV 仍然保留在树中供后续请求使用
• 多轮对话场景 KV Cache 命中率可达 60-85%

对比#

PD 分离：2026 生产主流#

问题本质#

Prefill 和 Decode 的资源需求完全不同（见第1章对比表），放在同一张 GPU 上互相干扰：

• Prefill 的算力突发会抢走 Decode 的显存带宽
• Decode 的低 GPU 利用率拖累 Prefill 的高效率
• 调度器需要在两种完全不同的工作负载间做 trade-off

具体表现：

混合部署（无 PD 分离）：
  一个 128K prompt 的 Prefill 进来
  → 占满 GPU 算力 2-3 秒
  → 同一 batch 里 20 个 decode 请求全部等待
  → TPOT 从 30ms 飙到 500ms
  → 用户感知：输出卡顿

PD 分离的做法#

         ┌──────────────┐
请求 ──→ │  Prefill 节点  │（算力密集，H100 或更高配）
         │  专门做 prompt │  高 SM 利用率
         │  批量计算      │  大 batch
         └──┬───────────┘
            │ KV Cache（通过高速网络传输到 Decode 节点）
            │ RDMA / NVLink over fabric
         ┌──▼───────────┐
         │  Decode 节点   │（访存密集，可多副本横向扩展）
         │  专门做逐 token│  高显存带宽利用
         │  生成          │  小 batch，多实例 DP
         └──────┬───────┘
                │
            输出 ──→ 用户

收益：

• Prefill 和 Decode 各自独立优化（硬件配置、batch 策略可不同）
• TTFT 降低（prefill 节点不再被 decode 请求抢占算力）
• 吞吐提升（decode 节点可以服务更多并发）
• 资源配比灵活（高峰期加 decode 节点，低峰期减 prefill 节点）

DeepSeek 生产数据：PD 分离后 TTFT 降低 30-50%，整体吞吐提升 2-3x。

实现方案#

KV Cache 跨节点传输#

PD 分离的核心挑战：Prefill 计算完的 KV Cache 要传给 Decode 节点。

KV 传输量 = num_layers × num_kv_heads × head_dim × seq_len × dtype_bytes

LLaMA 70B, 128K context, FP8 KV:
  80 × 8 × 128 × 128K × 1 byte ≈ 10 GB / 请求

网络要求：

• 100Gbps RDMA 是最低要求
• 400Gbps InfiniBand 是推荐配置
• GPU Direct RDMA 必须开启（避免 PCIe 回传）

优化手段：

• FP8 KV Cache（传输量减半）
• KV 压缩（传输前压缩）
• 流式传输（prefill 边算边传，不等全部完成）

注意事项#

• KV Cache 跨节点传输需要高速网络（100Gbps+ RDMA）
• KV 传输可能成为新瓶颈（监控 NIC 带宽）
• Prefill 与 Decode 节点比例需动态调整（高峰期 decode 多，低峰期 prefill 多）
• 不是所有场景都值得 PD 分离——小规模 + 流量平稳时，混合部署更简单

MoE 推理 + EPLB + MLA#

MoE 推理的特殊挑战#

MoE 模型的 expert 路由是不均衡的。DeepSeek-V2/V3 的生产数据显示，某些热门 expert 的负载是冷门 expert 的 10-20 倍。

问题表现：
  Expert 3 所在 GPU: 显存 95%，QPS 到上限
  Expert 7 所在 GPU: 显存 25%，GPU 几乎空闲
→ 整体集群吞吐被热门 expert 所在 GPU 卡死

根因：Router 是一个学习出来的线性层，它的路由分布取决于训练数据。某些语义模式（如代码、数学）会被高频路由到特定 expert，导致负载倾斜。

EPLB（Expert Parallelism Load Balancer）#

DeepSeek 开源的专家并行负载均衡器，通过动态调整 expert 到 GPU 的映射实现负载均衡：

• 实时监控每个 expert 的请求量
• 将热门 expert 的副本分配到多张空闲 GPU（replication）
• 冷门 expert 可以合并到同一张 GPU
• 周期性重平衡（不影响在线请求）

EPLB 工作原理：

重平衡前：
  GPU 0: [Expert 1, 2, 3]  ← Expert 3 是热门，GPU 0 过载
  GPU 1: [Expert 4, 5, 6]  ← Expert 4,5,6 冷门，GPU 1 空闲

重平衡后：
  GPU 0: [Expert 1, 2, 3副本A]
  GPU 1: [Expert 3副本B, 4, 5, 6]  ← Expert 3 复制到两块卡

热门 expert 有两份副本，负载分摊

MLA 如何配合 MoE#

MLA 压缩 KV Cache 的显存占用，为 MoE 的 expert 权重腾出更多显存空间。

为什么 MoE + MLA 是绝配：

MoE 的显存压力：全部 expert 权重都要加载（1.6T 参数 × 1 byte FP8 = 1.6TB）
MLA 的压缩：KV Cache 从 320KB/token 降到 20-40KB/token（1/8~1/16）

省出的 KV Cache 显存 → 可以加载更多 expert 副本
更多 expert 副本 → EPLB 负载均衡更容易
→ 整体吞吐提升

DeepSeek-V2/V3 靠 MLA 压缩 KV 支撑长上下文 + MoE；DeepSeek-V4 则进一步用 CSA/HCA（沿序列维度压缩 + 稀疏注意力）把 1M 上下文的 KV Cache 压到 V3.2 的约 10%——否则 1M 上下文的 KV Cache 会消耗数百 GB 显存。

分级 KV Cache：2026 降本核心#

问题：KV Cache 全放 GPU 太贵#

128K 上下文的 KV Cache 约 40GB，而 H100 总共才 80GB。GPU 显存是最贵的资源（H100 显存约 $3/GB，DRAM 约 $0.01/GB，差 300 倍）。

三级 KV Cache 架构#

┌────────────────────────────────────────────────┐
│ L0: GPU 显存（HBM）       最快，最小，最贵      │
│   热 KV：当前活跃请求        延迟：< 1μs         │
│   容量：80GB/H100                              │
├────────────────────────────────────────────────┤
│ L1: CPU 内存（DRAM）       较快，中等，便宜      │
│   温 KV：LRU 淘汰的短期缓存  延迟：~10μs        │
│   容量：512GB-2TB/节点                          │
├────────────────────────────────────────────────┤
│ L2: 远端存储（SSD/NVMe）   较慢，最大，最便宜    │
│   冷 KV：长期缓存/共享前缀   延迟：~100μs       │
│   容量：TB-PB 级（分布式缓存）                  │
└────────────────────────────────────────────────┘

分级策略：

• 活跃请求的 KV 在 L0（GPU）
• 请求完成后 KV 淘汰到 L1（CPU DRAM），短期内可恢复
• 高频共享前缀（system prompt、RAG 文档）持久化到 L2（远端）

关键开源实现#

LMCache 实战#

# LMCache 集成到 vLLM（配置层）
# vllm serve 启动时附加：
# --kv-transfer-config '{"role": "producer", "extra_kv_transfer_backend": "lmcache"}'

# 关键配置
LMCACHE_MAX_LOCAL_CPU_SIZE=50        # L1 CPU 缓存上限（GB）
LMCACHE_REMOTE_URL=redis://redis:6379  # L2 远端存储
LMCACHE_CHUNK_SIZE=256               # KV 传输块大小

命中率与经济性#

128K prompt + LMCache 80% 命中率：
  80% 的请求从 CPU/SSD 加载 KV → 省去 prefill 计算
  节省约 69% 的 prefill 成本

成本对比（128K prompt，1000 req/day）：
  无分级 KV：1000 × 128K prefill = 全量 GPU 计算
  80% 命中：200 × 128K prefill + 800 × KV 拷贝
  GPU 算力成本省 69%，多出的 CPU/SSD 成本可忽略

KV-aware Routing#

在编排层（如 Dynamo/llm-d）做智能路由：将请求路由到"KV Cache 已命中最长的节点"，避免重复 prefill。

请求进来 → Router 查询各节点的 KV Cache 状态
  ├─ 节点 A：命中前缀 100K token
  ├─ 节点 B：命中前缀 20K token
  └─ 节点 C：无缓存
→ 路由到节点 A（只需 prefill 剩余 28K token）

这与分级 KV 互补——分级 KV 管"去哪找缓存"，KV-aware routing 管"把请求送到有缓存的节点"。

分级 KV 的适用场景#

量化：用精度换显存和速度#

量化精度选型#

量化方法对比#

选择建议#

H100/H200：无脑 FP8（权重+激活+KV Cache 全 FP8）
A100：Weight-Only INT4 (AWQ) 或 SmoothQuant INT8
单卡跑 70B：必须 INT4/AWQ
精度敏感（代码/数学）：至少 FP8，不要用 INT4
Blackwell (B200)：FP4 原生，权重减半再减半
昇腾 950PR：FP4 原生支持

FP8 KV Cache 的收益#

LLaMA 70B FP8：
  KV Cache = 160 KB/token（vs FP16 320 KB/token）
  10 万 token = 16 GB（省 16 GB）
  省出的显存可多服务 3-5 个并发请求

FP8 vs INT8 的选择：FP8 是浮点（动态范围大），INT8 是定点（需要校准）。FP8 在 H100 上硬件原生，性能和精度都优于 INT8。A100 不支持 FP8，只能用 INT8 或 INT4。

其他优化技术#

Chunked Prefill#

将长 prompt 的 prefill 切成多个小块，与 decode 交替调度。防止一个 128K 的 prefill 把整个 batch 憋死。

# vLLM 开启
--enable-chunked-prefill --max-num-batched-tokens 2048

工作原理：

无 Chunked Prefill：
  时间步 1-500: [128K prefill 请求] 其他 decode 请求全部等待

有 Chunked Prefill（chunk_size=2048）：
  时间步 1: [128K prefill 的前 2048 token] + [decode 请求 A, B, C]
  时间步 2: [128K prefill 的下一 2048 token] + [decode 请求 A, B, C]
  ...decode 请求不被 prefill 阻塞

Prefix Cache#

缓存相同前缀（如 system prompt）的 KV Cache，RAG 和多轮对话场景收益显著：

# vLLM 开启（建议常开）
--enable-prefix-caching

命中率影响因素：

• system prompt 是否稳定（动态字段会破坏命中）
• RAG 文档集是否稳定
• 多轮对话历史是否完整传入

Speculative Decoding（投机解码）#

用小模型（draft model）先"猜"几个 token，大模型一次验证多个。

加速原理：LLM decode 串行生成（每次 1 token），GPU 大量时间在等待。Speculative Decoding 把串行变成批处理验证——小模型一次猜 4-8 个 token，大模型一次 forward 验证全部，正确接受的 token 直接输出。

适用场景：代码补全、格式化输出等输出规律强的任务。不适用：创意写作等高度不可预测的任务。

Multi-LoRA Serving#

同一 base 模型挂多个 LoRA adapter，请求时按需加载。一个推理实例服务多个定制方向，显存只多一点点（LoRA 增量通常 <1% 参数）。

vLLM Multi-LoRA：

vllm serve Qwen/Qwen2.5-72B-Instruct \
  --enable-lora \
  --max-loras 4 \
  --max-lora-rank 64 \
  --lora-modules legal=path/to/legal-lora medical=path/to/medical-lora

CUDA / Triton Kernel 优化#

岗位分支方向（ML Systems / 推理优化工程师），主线不要求，但需要知道：

• FlashAttention：利用 GPU SRAM 做分块计算，减少 HBM 读写（H100 HBM 3TB/s vs SRAM 19TB/s）
• FlashMLA：MLA 的高效 CUDA 实现，DeepSeek 开源
• CUDA Graph：捕获 kernel 序列为图，消除 launch overhead（decode 阶段 launch overhead 占 20-40%）
• 算子融合：将多个小 kernel 合并为一个大 kernel，减少 launch 开销
• Triton Kernel：Python 写 GPU kernel，比 CUDA 易开发

实战要点#

1. 所有优化都从监控开始：没有 TTFT/TPOT/GPU Util/KV Cache 使用率数据，优化就是盲调。vLLM 和 SGLang 都自带 Prometheus metrics。先建立基线，再调优。

2. 优先调整显存参数：gpu-memory-utilization（vLLM）或 mem-fraction-static（SGLang）调高 0.02 可能多出几个并发槽位。但不要超过 0.95，留 buffer 防 OOM。

3. max-model-len 是最大的隐式性能杀手：设到模型上限（128K），KV Cache 池子被撑大，并发直接掉到个位数。按业务实际设，99% 场景 8K-32K 足够。

4. PD 分离不是银弹：有额外复杂度（KV 传输、两套硬件），只在 prefill 和 decode 冲突严重的场景才值得引入。小规模 + 流量平稳时混合部署更简单。

5. FP8 是 2026 推理的基线精度：H100/H200 上无脑 FP8（权重+激活+KV Cache 全 FP8）。A100 上权衡 AWQ INT4。

6. 分级 KV 和 KV-aware routing 是 2026 的降本核心组合：128K 上下文 80% 命中率省 69% 的 prefill 成本。RAG 和多轮对话场景必上。

7. MoE 推理必须配 EPLB：不配 EPLB 的 MoE 推理，热门 expert 所在 GPU 会成为瓶颈，集群吞吐被卡死。

8. Chunked Prefill 长上下文必开：不开的话一个 128K prompt 会把整个 batch 的 decode 请求憋死。

9. Speculative Decoding 看场景：代码补全、格式化输出收益大（2-3x），创意写作收益小甚至负收益。

10. 调优顺序：监控基线 → max-model-len → 显存参数 → 量化 → 调度参数 → Prefix Cache → Chunked Prefill → PD 分离 → 分级 KV → Kernel 优化。

性能调优速查表#

小结#

这一章覆盖了 LLM 推理性能优化的完整路线：

核心指标（TTFT/TPOT/tokens/s/P95）
 → 核心机制（KV Cache/Continuous Batching/PagedAttention）
 → 2026 主流（PD 分离 / MoE EPLB / 分级 KV / FP8）
 → 进阶技术（Speculative Decoding / Multi-LoRA / Kernel 优化）

一个重要认知：PD 分离、MoE EPLB、分级 KV 在 2026 年已从加分项升级为主流，是面试和设计推理平台时的标准答案。

下一章进入 算力资源调度——如何让多模型、多任务、多团队高效共享 GPU/NPU 算力。