AI System Performance Bottlenecks
AI System Performance Bottlenecks
看到一项新技术时,问两个问题:它在第几层?它主要解决哪类瓶颈?
六类瓶颈
- Compute:FLOPs、Tensor Core、GEMM、kernel fusion。
- VRAM:参数、梯度、optimizer state、activation、KV Cache。
- Memory bandwidth:权重和 KV 在 HBM 中的搬运,尤其影响 Decode。
- Communication:All-Reduce、All-to-All、KV transfer、多机网络。
- Scheduling:batch、request、worker 和 GPU 资源何时运行。
- Service quality:TTFT、TPOT、throughput、P95/P99、SLO、成本。
映射示例
| 技术 | 所在层 | 主要瓶颈 |
|---|---|---|
| GQA | 模型架构 | VRAM、memory bandwidth |
| FlashAttention | Kernel | memory bandwidth、VRAM |
| PagedAttention | 推理引擎 | VRAM、scheduling |
| Speculative Decoding | 推理算法 | compute、service quality |
| Prefill-Decode Disaggregation | 分布式推理 | communication、scheduling、service quality |
| ZeRO | 训练引擎 | VRAM、communication |
| Ray | 分布式控制 | scheduling |
| Kubernetes | 集群控制 | scheduling、isolation |
从现象反推瓶颈
1 | 请求延迟上升 |
GPU utilization 不是性能总指标:decode 可能因内存带宽受限而 Tensor Core 不满,通信可能让 GPU 等待,或者请求根本排在队列中尚未执行。平均值也会掩盖长 prompt、KV eviction、跨节点通信和抢占造成的尾延迟。
同一技术可能跨多个瓶颈。GQA 先减少 KV head,直接降低 VRAM 和 memory bandwidth,随后可能提高有效并发,间接改变 scheduling;但它也可能带来质量损失。PD 分离先解决 prefill/decode 互相干扰,再引入 KV transfer 的 communication 成本。
向下连接硬件、kernel 和 KV Cache,向上连接 Serving and LLMOps 的 SLO 与成本,横向连接 Inference Engine Selection。每次报告都应给出 workload、硬件、版本、指标定义和改变的因果假设。
观测字段要能闭合因果链
仅有一个 GPU utilization 或平均 latency 无法定位瓶颈。最小 trace 应把一次请求拆成:gateway 等待、tokenize、prefill queue、prefill kernel、KV handoff、decode queue、每轮 decode、stream flush 和完成/取消;资源侧再对齐 GPU HBM、显存 allocator、NCCL、网络、CPU 和磁盘。这样“TTFT 上升”才能回答到底是排队、prompt 变长、KV transfer 还是首个 kernel 变慢。
1 | 资源饱和? → compute / HBM / VRAM / network |
同一现象可能来自不同层
“GPU 不满”可能是 decode 的 memory-bound,也可能是请求没有组成有效 batch、CPU tokenizer 卡住,或者跨节点 collective 在等最慢 rank;“显存不足”可能是权重本体、KV 增长、allocator 碎片、workspace 或多模型共驻。排查顺序应先把占用按对象拆账,再选择技术:PagedAttention 不能减少权重字节,量化不能修复路由排队,换 Triton kernel 不能消除跨节点等待。
优化报告的反例约束
每项优化都要写出一个可能失败的反例:GQA 可能省 KV 但损失任务质量;连续 batching 可能增吞吐但伤短请求 P99;PD 分离可能隔离阶段却增加 KV transfer;TP 可能放下模型却被通信拖慢。复测时除了平均 throughput,还要保留质量、错误率、P95/P99、成本和取消/重算次数,避免把局部指标改善误写成系统改善。