跳到主要内容
推理优化

第8章：推理优化选型与端到端实战

掌握推理优化选型决策树、技术叠加注意事项,完成从需求分析到上线监控的端到端部署实战

推理优化 选型决策 端到端部署 课程总结

本章是推理优化模块的收官,也是整个 AI Infra 课程的总结。把前面 28 章的理论编织成一张实战网络:针对症状选技术、把多个优化叠加时避开陷阱、走完一次”从需求到上线”的完整部署。最后回顾四大模块的核心知识图,送给所有走完这条路的同学一份学习地图。

📑 目录

1. 优化技术全景速查表

技术解决什么代价章节
FlashAttention长上下文 Attention 慢 / OOM实现复杂度模块二 6
PagedAttentionKV 碎片化、并发低间接寻址模块四 2
Continuous BatchingGPU 利用率低调度复杂度模块四 2
Prefix Cache共享前缀重复 Prefill显存占用模块四 2
Chunked Prefill长 Prefill 拖慢 Decode多次调度模块四 2
INT4 量化(AWQ + Marlin)模型显存大精度小损模块四 4
W8A8 (SmoothQuant)模型显存 + 算力精度小损模块四 4
KV Cache 量化长上下文 KV 大精度小损模块四 4
FP8(H100+)算力 + 显存 + 通信需要 H100模块四 4
Speculative DecodingDecode 串行慢Draft 开销模块四 5
PD 解耦尾延迟失控KV 跨节点模块四 6
Tensor Parallel单卡装不下大模型通信模块三 4
torch.compile通用算子开销编译时间模块二 7

2. 症状驱动的选型决策树

2.1 第一步:跑 baseline,看哪个指标最差

genai-perf profile -m my_model --concurrency 64 --num-prompts 500 ...

得到 TTFT / TPOT / Throughput / 显存 / GPU 利用率 五个数。找最差的那个,从下面对应分支入手。

2.2 [A] TTFT 过高

TTFT 过高(用户等首 token 太久)
│
├─ Prompt 很长(几千~几万 token)?
│   ├─ Chunked Prefill 切块
│   └─ 升级到 H100 / 用 FP8 加速 GEMM
│
├─ 共享 prompt 多?
│   └─ Prefix Cache(vLLM) / RadixAttention(SGLang)
│
└─ Tokenizer / 调度成为瓶颈?
    ├─ Nsight Systems 抓 trace 看 GPU 是否 idle
    └─ 排查 CPU 端开销

2.3 [B] TPOT 过高

TPOT 过高(token 蹦得慢)
│
├─ KV Cache 搬运成瓶颈(memory bound)?
│   ├─ FlashAttention / FlashInfer
│   └─ KV Cache 量化(INT8 / FP8 / KIVI)
│
├─ Decode 串行的本质限制?
│   └─ Speculative Decoding(Medusa / EAGLE-2)
│
└─ GPU 算力没喂饱(并发太低)?
    └─ Continuous Batching + 提高并发上限

2.4 [C] 显存不够 / OOM

OOM
│
├─ KV Cache 占大头(长上下文 / 高并发)?
│   ├─ PagedAttention
│   └─ KV 量化 / KIVI 2-bit
│
└─ 模型权重本身就装不下?
    ├─ INT4 weight-only(AWQ + Marlin)
    ├─ Tensor Parallel 切到多卡
    └─ FP8(H100)

2.5 [D] 尾延迟失控(P95/P99)

P95/P99 飙升
│
├─ Prefill 和 Decode 互扰?
│   ├─ Chunked Prefill(轻方案)
│   └─ PD 解耦(DistServe / Splitwise,大集群)
│
└─ SLO 严苛、需要全局调度?
    └─ TaiChi / SLO-aware scheduler

3. 技术组合的陷阱与冲突

优化技术不能简单叠加,常见冲突:

3.1 Speculative + 量化

Draft 模型量化后接受率可能大幅下降——量化对小模型更敏感。建议:Target 量化、Draft 保持 FP16/BF16。

3.2 Speculative + Continuous Batching

不同请求的 spec K 不一样,增加调度复杂度。高并发时 spec 收益消失(GPU 已 compute bound)——动态判断,小 batch 才开 spec。

3.3 INT4 + 小 batch

INT4 dequant 开销大,没 Marlin kernel 时小 batch 反而比 FP16 慢。必须用 Marlin 才有真正加速。

3.4 PagedAttention + Speculative

Spec 验证时要并行多个候选,KV Cache 的页管理要支持 fork/copy——并非所有引擎都成熟。

3.5 多 LoRA + Prefix Cache

不同 LoRA 的 KV 不能共享(权重不同导致 K/V 计算不同),Prefix Cache 命中率会下降。需要”per-LoRA Prefix Cache”。

4. 优化顺序:先解什么、后解什么

1. 先解决 OOM(否则服务起不来)
   ↓
   方案:量化 + PagedAttention + TP

2. 再优化 TTFT(直接影响用户感知)
   ↓
   方案:Prefix Cache + Chunked Prefill + GEMM 优化

3. 然后提升 TPOT 和吞吐
   ↓
   方案:FlashAttention + Continuous Batching + Speculative

4. 最后处理尾延迟(投入最大)
   ↓
   方案:PD 解耦 + SLO 感知调度

每一步都要重新跑 benchmark,确认当前瓶颈是什么再走下一步——不要”把所有技术都堆上”,一次优化一项,验证收益。

5. 端到端部署实战

5.1 需求分析

收集这些信息:

项示例
模型LLaMA-3-70B
业务场景客服 chat
QPS50 req/s
平均输入800 token
平均输出150 token
TTFT SLO< 500 ms (P95)
TPOT SLO< 50 ms (P95)
硬件预算8 张 H100 80GB
容错要求99.9% 可用性

5.2 方案设计

模型 70B BF16 = 140 GB
8 张 H100 = 640 GB,够用

并行:TP=8(单机 NVLink)
量化:权重 FP8(算力 +2×,显存 ÷ 2)
KV:FP8(同上)
Prefix Cache:开
Chunked Prefill:开
Speculative:不开(高并发场景收益小)

预估单卡显存:

  • 权重 FP8 = 70 GB / 8 = 8.75 GB
  • 临时 buffer ≈ 5 GB
  • 留给 KV ≈ 65 GB / 卡 → 8 卡共 520 GB
  • 单请求 KV(GQA, 4K, FP8)≈ 2.5 GB
  • 最大并发 ≈ 200 个请求

5.3 部署流程

# 1. 下载量化模型
huggingface-cli download neuralmagic/Meta-Llama-3-70B-Instruct-FP8

# 2. 启动 vLLM
python -m vllm.entrypoints.openai.api_server \
    --model neuralmagic/Meta-Llama-3-70B-Instruct-FP8 \
    --tensor-parallel-size 8 \
    --kv-cache-dtype fp8 \
    --enable-prefix-caching \
    --enable-chunked-prefill \
    --max-num-batched-tokens 8192 \
    --max-num-seqs 200 \
    --gpu-memory-utilization 0.9 \
    --port 8000

# 3. 压测验证
genai-perf profile -m neuralmagic/Meta-Llama-3-70B-Instruct-FP8 \
    --service-kind openai --url http://localhost:8000 \
    --num-prompts 1000 --concurrency 100 \
    --synthetic-input-tokens-mean 800 --output-tokens-mean 150

# 验证 SLO:TTFT P95 应 < 500ms,TPOT P95 < 50ms

# 4. 接入业务,灰度 5% → 50% → 100%

6. 上线后:监控与容量规划

6.1 监控指标

基础设施层:
  - GPU 利用率(per GPU)
  - GPU 显存使用率
  - GPU 温度
  - 网络带宽(IB)

服务层:
  - QPS / 实例
  - TTFT / TPOT 分位线(P50, P95, P99)
  - 请求队列长度
  - KV Cache 利用率

业务层:
  - 业务成功率
  - 用户停留时长(流式输出场景)
  - 内容质量(人工抽样)

Prometheus + Grafana 是事实标准。vLLM 有原生 /metrics 端点。

6.2 告警

告警阈值严重程度
TTFT P95 持续 5min > SLOwarning
TPOT P95 > SLOwarning
任意请求 latency > 30scritical
GPU 显存 > 95%critical
实例 OOMcritical

6.3 容量规划

当前 1 实例(8 H100)= 50 QPS
目标:200 QPS
需要:4 实例

Surge 容量:再多 1 实例处理峰值
故障容忍:N+1 部署
总:6 实例 = 48 张 H100

7. 四大模块知识图回顾

                     AI Infra 知识树
                          │
    ┌──────────┬──────────┼──────────┬──────────┐
    │          │          │          │          │
模块一       模块二      模块三     模块四      性能分析
前置知识    CUDA算子    分布式训练   推理优化   (横切)

  Transformer FlashAttn   ZeRO        PagedAttn   Nsight
  PyTorch     GEMM        Megatron    vLLM        torch.profiler
  GPU 硬件    Triton      FSDP        量化         GenAI-Perf
  集合通信    AI 编译器    3D 并行     PD 解耦

7.1 核心思维:Trade-off 表

优化牺牲换取
ZeRO通信显存
Activation Checkpointing计算显存
量化精度显存 + 带宽 + 算力
SpeculativePrefill 开销Decode 速度
PD 解耦系统复杂度 + KV 迁移尾延迟 + goodput
FlashAttention实现复杂度显存 + 速度
Tensor Parallel通信(NVLink)装下大层
Pipeline ParallelBubble跨机扩展

🌟 这就是 AI Infra 的本质:在”计算 / 通信 / 显存 / 精度”四象之间做最优权衡。

8. 持续学习建议

8.1 跟踪前沿

渠道推荐
arXivcs.DC、cs.AI 类目,关注 OSDI / SOSP / MLSys / ASPLOS / ISCA
GitHubvLLM、SGLang、FlashAttention、CUTLASS、Megatron 的 release notes
微信公众号 / 知乎猛猿、方佳瑞、DefTruth、OneFlow
Twitter / XTri Dao(FlashAttention 作者)、Lianmin Zheng(SGLang)、vLLM team
视频NVIDIA GTC 历年 talks、LLM Devday

8.2 参与开源

最好的学习是参与:

  • vLLM:从修文档、加单测开始,逐渐做 issue / feature
  • PyTorch:贡献 op、profiler 改进
  • FlashAttention / FlashInfer:Kernel 优化
  • Megatron:模型实现 / 通信优化

8.3 工程实战

不要只看论文,真正在 GPU 上把模型训起来 / 推起来:

  1. 拿一个 7B 模型,在自己机器上跑通 vLLM 推理
  2. 用 4 张 GPU 训一个 1B 模型,把 DDP / FSDP / TP 都试一遍
  3. 写一个简单的 CUDA / Triton kernel,与 PyTorch 对比性能
  4. 复现一篇你感兴趣的优化论文

8.4 心态

AI Infra 是一个所有学过的东西很快会过时,但底层思维不会过时的领域:

  • 工具会变(从 DeepSpeed → FSDP → 下一代),思想不变(冗余切分 + 通信换显存)
  • 硬件会变(A100 → H100 → B200),约束不变(算力增长快于带宽,memory wall 永恒)
  • 模型会变(GPT → LLaMA → MoE),计算 pattern 不变(GEMM + Attention + FFN 几个核心)

理解了核心思想,新工具新硬件来了你能快速上手。

✅ 自我检验清单

  • 症状决策:给 4 种症状(TTFT 高 / TPOT 高 / OOM / P95 飙),能立刻给出对症方案
  • 冲突识别:能列出 5 种技术叠加的常见冲突
  • 优化顺序:能说出”OOM → TTFT → TPOT → 尾延迟”的优化优先级及依据
  • 完整方案:给一个具体业务需求,能输出完整的部署方案(框架 / 量化 / 并行 / 配置 / 容量)
  • 监控指标:能列出基础设施 / 服务 / 业务三层各 5 个核心监控指标
  • trade-off 表:能默写至少 6 种优化的”牺牲什么、换取什么”
  • 学习路径:能为自己设计未来 6 个月的 AI Infra 学习计划

📚 参考资料

综合

  • Towards Efficient Generative LLM Serving: A Survey:https://arxiv.org/abs/2312.15234
  • LLM Inference Optimization 综述:HuggingFace 博客系列
  • NVIDIA Inference Performance Blog

实战

持续跟踪

  • OSDI / SOSP / MLSys / ASPLOS 历年 LLM 推理论文
  • NVIDIA GTC 历年 talks(免费在线)
  • vLLM Office Hours 月度公开会议

系统级综述

  • AI Systems Performance Engineering（Chris Fregly, O’Reilly 2025）:learning.oreilly.com —— Ch10 案例研究、Ch12 175+ 项性能优化检查清单,可作为本章端到端实战完成后的”全栈复盘 cheat sheet”

🎉 恭喜完成 AI Infra 课程!

这套四大模块覆盖了从硬件、算子、训练到推理的完整链路。但真正的功力在落地——把这些知识用到一个真实的项目中,才能内化成自己的能力。

愿你在 AI Infra 的路上一直保持对底层细节的好奇心,也保持对系统全局的把控力。The bottom is where the magic happens.