AWP 六维 Breakdown 框架与能力体系摘要

核心主张

优化的前提是度量，度量的前提是 Breakdown。AWP 的核心价值不是告诉用户”GPU 利用率低”，而是告诉用户**“低的那 80% 里，45% 是访存等待、20% 是框架开销、15% 是通信阻塞”**——每一项都有数据支撑、有归因路径、有优化抓手。

第1章：为什么需要规模化 Breakdown

单一指标的陷阱

“GPU 利用率 X%” 几乎没有可操作性。SM Active 30% 可能是 Batch 太小、Kernel 间隙大、或通信阻塞——一个数字无法指导行动。需要将 GPU 时间分解到各维度，量化贡献比例，按大小排序，先解决头部问题。

GPU 时间的穷尽分解

GPU 的每一微秒时间都必然落入以下六个互斥类别之一（MECE）：

类别	说明
有效计算时间	Tensor Core 在做有用的 GEMM/Attention
低效计算时间	GPU 在算，但 Kernel 实现低效 / 精度浪费
访存等待时间	等待 HBM 数据搬运到 SRAM
通信等待时间	等待 All-Reduce / P2P / PP 传输完成
框架开销时间	Kernel Launch / CPU-GPU 同步
调度空闲时间	无 Kernel 运行：等请求 / 凑批 / Prefill 干扰

只有”有效计算时间”在产出 token，其余五项都是损耗。AWP 的核心任务：量化这五项损耗各自占多少，哪项最大，为什么大，怎么减小。

规模化 Profiling 的必要性

单机 Profiling 无法回答集群级问题（统计显著性、异构性、负载相关性、时间维度、归因能力）。规模化 = 全集群 × 全时段 × 全负载条件，是从”诊断工具”到”效率度量平台”的本质跃迁。

第2章：六维 Breakdown 框架

框架总览

将 GPU 效率损失分解为六个正交维度，每个维度有独立的度量方法、AWP 采集能力和优化路径：

维度	符号	定义	典型贡献占比
D1: 访存瓶颈	T_mem	GPU 在等待 HBM 数据搬运的时间	35-50%（Decode 主导）
D2: 计算效率	T_compute_waste	Kernel 低效浪费的部分	10-20%
D3: 显存容量	T_mem_cap	显存不足被迫缩小 Batch 的间接损失	10-25%（长序列更高）
D4: 框架开销	T_framework	Kernel Launch、同步、Python 开销	10-25%（小 Batch 更高）
D5: 流量调度	T_scheduling	凑批等待、Padding、Prefill-Decode 干扰	5-15%
D6: 通信瓶颈	T_comm	All-Reduce 等待、Straggler 拖尾、PP Bubble	5-25%（TP≥4 更高）

核心等式：

GPU 总时间 = T_effective_compute + T_mem + T_compute_waste + T_mem_cap_indirect + T_framework + T_scheduling + T_comm

为什么是这六个维度

六个维度对应六个独立的物理资源约束（HBM 带宽、Tensor Core 算力、HBM 容量、CPU 处理能力、请求到达模式、互联带宽）。正交性意味着每个维度可以独立优化，且优化一个维度不会恶化另一个维度。

第3章：各维度深度 Breakdown

D1: 访存瓶颈

Decode 阶段每生成一个 token 需从 HBM 读取全部模型权重（70B FP16 ≈ 140GB）和全部历史 KV Cache，算术强度仅 ≈ 1-2 FLOPs/Byte。

访存时间可分解为：T_mem = T_weight_load + T_kv_cache_read + T_kv_cache_write + T_activation_transfer

优化杠杆：增大 Batch Size、模型量化（FP8/INT8）、KV Cache 量化、GQA/MLA、FlashAttention。

D2: 计算效率

即使 GPU 在”计算”，也不意味着高效。损失来自：Tensor Core 未充分利用、Kernel 实现质量差、未使用最优精度、算子未融合。

分解：T_compute_waste = T_non_tensor_core + T_low_occupancy + T_unfused_overhead + T_precision_waste

D3: 显存容量

显存不直接消耗 GPU 时间，但通过约束 Batch Size 上限间接影响效率。Batch Size 从 1 增大到 32，吞吐可提升 10-20x。

典型 LLaMA-70B FP16 在 8×H100 TP=8 部署中，KV Cache 可占 38-63% HBM，是最大变量。

D4: 框架与运行时开销

当 Kernel 本身很小（Decode 阶段 <10μs）时，Launch 开销（~7μs/次）可能超过执行时间。

分解：T_framework = T_kernel_launch + T_sync_block + T_cpu_scheduling + T_h2d_d2h + T_python_overhead

batch=1 无 CUDA Graph 时框架开销可达 30-40%；batch=32 + CUDA Graph 可降至 3-5%。

D5: 流量与调度

即使硬件和框架最优，请求到达模式和调度策略不好，GPU 仍会大量空闲。这是线上环境与 benchmark 差异最大的维度。

分解：T_scheduling = T_queue_wait + T_padding + T_prefill_interference + T_load_imbalance

D6: 通信瓶颈

TP=8 场景下每个 Transformer 层需 2 次 All-Reduce，70B 模型一次前向传播有 160 次 All-Reduce。AWP 需度量的是未被 Overlap 的通信时间。

分解：T_comm = T_allreduce + T_allgather + T_p2p + T_straggler_wait + T_pp_bubble

第4章：AWP 能力体系 — L0 到 L3

四级能力分层

层级	名称	设计原则	回答的问题
L0	常驻遥测	7×24 采集，开销 <1%	“有没有问题？“
L1	深度 Profiling	按需触发，开销 5-15%	“问题的根因是什么？“
L2	Breakdown 分析	基于 L0+L1 自动计算	”效率损失分布在哪里？“
L3	自动化闭环	发现→归因→推荐→验证→守护	”如何自动优化？“

L0 常驻遥测

采集 GPU 硬件指标（SM/TC/HBM/功耗/温度）、推理引擎指标（TTFT/TPOT/QPS/Batch Size）、系统指标、健康检查。异常检测规则触发 L1。

L1 深度 Profiling

五大能力：Kernel Trace、Roofline 数据、CPU-GPU 时间线、显存时间线、NCCL Trace。触发方式包括 L0 自动触发、手动触发、定时采样、版本发布触发。

L2 Breakdown 分析（核心能力）

六维 Breakdown 报告：饼图展示各维度占比 + 子项明细
Roofline 自动标注：每个 Kernel 的 Compute/Memory Bound 标签
GPU Idle 归因：每段 Idle 的原因分类
集群 Breakdown 热力图 + Straggler 标注
跨维度关联分析：识别因果链（如 D3 显存不足 → Batch 缩小 → D1 访存占比上升）

L3 自动化闭环（目标态）

自动 Breakdown 报告生成、异常自动归因、优化方案推荐、A/B 验证自动化、回归防护、配置自动调优。

第5章：典型场景应用

场景一：Decode 吞吐不达标

Breakdown 发现访存等待 48%（头部原因），框架开销 18%。关联分析：KV Cache 占用过大(D3) → Batch 受限 → 访存主导(D1)。优化建议：KV Cache FP8 量化 + CUDA Graphs，预期吞吐提升 2.5-3x。

场景二：TPOT P99 尾延迟飙升

P99 请求的调度损失占 55%（vs P50 的 18%），其中 Prefill 干扰占 38%。根因：长 Prompt Prefill 期间所有 Decode 暂停。优化：Chunked Prefill 或 Prefill-Decode 分离。

场景三：集群级 GPU 浪费排查

1000 GPU 集群 SM Active 均值 22%。分类：A 类正常（32%）、B 类低效（48%）、C 类空闲（20%）。B 类进一步归因到 D5 调度、D3 显存、D4 框架、D6 通信。C 类归因到无流量、僵尸进程、硬件故障。

第6章：能力建设路线图

阶段	核心交付
Phase 1 (Q1)	L0 常驻遥测 + L1 Kernel Trace + Timeline
Phase 2 (Q2)	L1 Roofline + NCCL Trace + L2 Roofline 自动标注
Phase 3 (Q3)	L2 六维 Breakdown + 集群热力图（核心里程碑）
Phase 4 (Q4)	L1 内存分析 + L2 跨维度关联 + L3 自动归因
Phase 5 (次年)	L3 方案推荐 + A/B 自动化 + 回归防护

与姊妹文档的关系

本文档与《LLM 推理性能优化与 GPU 利用率提升》互补：

本文档回答”效率损失分布在哪里”（先 Breakdown，再优化）
姊妹文档回答”有哪些优化手段”（知道瓶颈后如何优化）

协同工作流：线上性能不达标 → 本文档 Breakdown 量化 → 姊妹文档选择优化方案 → 实施 → 本文档验证效果。