算
推理集群跑起来后最常见的怪象：明明总算力还够，个别卡却先爆显存，或者延迟毛刺只出现在某几张卡上。单卡调优之前，先把负载不均的源头分清楚。
我的排查顺序是这样的。第一，看调度层：请求是不是按轮询分发、长短请求有没有混在同一个 batch 里，长请求会拖住整批的 TPOT，表现为某卡持续高负载。第二，看显存碎片：PagedAttention 之后碎片少了，但 KV Cache 块大小配得不合理时，碎片仍会随并发上涨，用“已分配显存 / 实际 token 显存”这个比值就能看出来。第三，看模型并行切分：张量并行切得不均时，通信量大的 rank 会先成为瓶颈，表现为固定几张卡的 NVLink 带宽先打满。第四，看数据本身：带长上下文的请求如果集中落在同一组卡上，负载天然就不均，这时要靠请求级负载均衡而不是加卡。
还有一个容易被忽略的点：监控粒度。只看集群平均利用率会掩盖问题，一定要看到单卡级的 P99 延迟和显存占用曲线，平均值好看、P99 难看的集群，用户体感就是卡顿。
你们的推理集群出现过多卡负载不均吗？最后定位到的根因是调度、碎片还是并行切分？
我的排查顺序是这样的。第一，看调度层：请求是不是按轮询分发、长短请求有没有混在同一个 batch 里，长请求会拖住整批的 TPOT，表现为某卡持续高负载。第二，看显存碎片：PagedAttention 之后碎片少了，但 KV Cache 块大小配得不合理时，碎片仍会随并发上涨，用“已分配显存 / 实际 token 显存”这个比值就能看出来。第三，看模型并行切分：张量并行切得不均时，通信量大的 rank 会先成为瓶颈，表现为固定几张卡的 NVLink 带宽先打满。第四，看数据本身：带长上下文的请求如果集中落在同一组卡上，负载天然就不均，这时要靠请求级负载均衡而不是加卡。
还有一个容易被忽略的点：监控粒度。只看集群平均利用率会掩盖问题，一定要看到单卡级的 P99 延迟和显存占用曲线，平均值好看、P99 难看的集群，用户体感就是卡顿。
你们的推理集群出现过多卡负载不均吗？最后定位到的根因是调度、碎片还是并行切分？