Agentic AWP：规模化 Profiling 驱动的 GPU 效率 Breakdown 与能力体系

这是一份来源摘要。它保留原文的 Breakdown 和能力建设框架，但不把原文中的示例占比、建议收益或阈值当成本站实测。

六个诊断视角

维度	关心的资源或控制面	常见证据
D1 访存	权重、KV、激活与 HBM	DRAM throughput、bytes、memory stall
D2 计算	Tensor Core、shape、有效 FLOPs	Roofline、Kernel、occupancy
D3 容量	权重/KV/workspace/碎片对 Batch 的约束	显存账本、KV blocks、OOM/抢占
D4 Runtime	CPU launch、API、同步和框架空隙	CPU-GPU Timeline
D5 调度	请求到达、Queue、Batch 和 Prefill 干扰	Scheduler 事件、延迟分布
D6 通信	NVLink/PCIe/IB 与 collective	NCCL/Network trace、拓扑

容量为何是间接维度

容量本身不一定消耗 GPU 时间，但会限制可用 Batch、KV 保留和准入，进而放大访存或调度损失：

容量不足
  → Batch / 并发受限或发生抢占
  → 权重摊薄变差、调度空洞增加
  → 吞吐与尾延迟恶化

因此 Breakdown 报告应表达因果链与口径，而不是把 D3 和由它诱发的全部 D1/D5 损失重复相加。

L0 到 L3 的能力层级

层级	回答什么	典型产物
L0 常驻遥测	有没有异常？	指标、基线、告警、分组趋势
L1 按需 Profiling	时间花在哪里？	Trace、Roofline、Memory、NCCL
L2 Breakdown	哪些证据支持哪个可操作原因？	口径化分解、对照、因果链、未解释项
L3 闭环	改动是否有效并可持续？	实验授权、A/B、回归、推荐与审计

L0 追求低开销和覆盖，L1 追求解释力；两者不应互相替代。规模化系统还要记录模型、租户、版本、节点、拓扑、配置和时间窗，才能识别异构性与退化趋势。

一份可行动报告应包含什么

1. Case 身份：模型、硬件、拓扑、负载、精度、并行与时间窗；
2. 结果层：TTFT、TPOT/ITL、吞吐、尾延迟、OOM/错误；
3. 证据层：Timeline、Kernel、Memory、Communication、Scheduler；
4. 归因层：已证实、可能解释、未解释三种状态；
5. 动作层：最小实验、预期影响方向、风险和验收指标；
6. 回归层：改动后用同 Case 复测，并保留版本身份。

若证据只说明“调度等待占比高”，它尚不能授权“可回收多少损失”；还需要相关性、对照或实验。

建设顺序

原文建议从数据底座逐步走向闭环。压缩为四个可验收里程碑：

1. 看得见：L0 指标与 L1 Trace 能关联到同一任务和节点；
2. 说得清：Roofline、Memory、NCCL、Scheduler 使用统一 Case 口径；
3. 可行动：Breakdown 输出 Top 原因、证据和最小实验，不隐藏未知；
4. 能守护：实验结果回流，版本变化能自动发现回归。

不要在证据身份尚未统一时先做自动建议；否则系统只会规模化地复制弱归因。

相关页面

• GPU Trace 分析 — 时间线证据
• 关键路径分析 — 从重叠时间寻找真实控制点
• Profiling → Simulation 证据链 — 配置、校准与实验
• Agentic Infra 推理优化 — 同来源体系的优化侧摘要
• LLM 推理系统全栈地图 — 机制与资源压力入口