利用率偏低怎么排查
服务端 GPU 利用率偏低，常见原因有：批太小、请求本身稀疏、CPU 侧预处理或分词成为瓶颈、采样与后处理占用，以及网关限流导致的排队。按请求链路逐层定位比盯着利用率数字有效率：请求有没有进来、有没有在排队、批大小是否偏小、CPU 是否跟不上、有没有被降频。
基本信息
| 常见原因 | 批太小、请求稀疏、CPU 预处理瓶颈、采样与后处理占用、网关限流排队 |
|---|---|
| 观测工具 | 整卡与进程级滚动监控、Python 侧热点分析、服务与网关指标 |
| 判断方法 | 用较长窗口的利用率对照请求速率，而不是看瞬时值 |
| 正常现象 | 请求间隙的低利用率属于常态 |
| 关联因素 | 时钟降频会让利用率看起来正常而吞吐偏低 |
排查顺序
- 第一层：请求有没有进来——对网关与入口日志核对请求速率
- 第二层：是否在排队——看等待请求数与网关侧排队时长
- 第三层：批大小是否偏小——并发不足时每步能塞进去的请求很少
- 第四层：CPU 侧是否瓶颈——预处理、分词与后处理跟不上会让 GPU 周期性空转
- 第五层：是否被降频——功耗与温度触发的降频会让吞吐低于预期
- 第六层：采样与输出侧开销——长输出场景下采样与文本处理也会拖慢整体节奏
现场观察与热点定位
现场观察与热点定位
# 整卡与进程级滚动观察：利用率是否呈周期性空转
nvidia-smi dmon -s um -d 2
nvidia-smi pmon -o T
# Python 侧热点定位：确认时间花在预处理、采样还是推理调用上
py-spy top --pid <服务 PID>
# 服务侧对照：等待请求数是否长期为零
curl -s http://127.0.0.1:8000/metrics | grep -E 'num_requests_waiting|num_requests_running'现象与验证方法
| 现象 | 可能原因 | 验证方法 |
|---|---|---|
| 利用率低但有排队 | 排队发生在链路其他位置 | 查网关日志与限流配置 |
| 利用率低且请求稀疏 | 流量本身不足 | 对照请求速率与并发 |
| 利用率低但延迟高 | CPU 预处理瓶颈或降频 | 看热点分析与降频原因 |
| 利用率忽高忽低 | 批大小随流量波动 | 看运行中请求数曲线 |
利用率天然随流量波动，判断要用较长时间的窗口与请求速率对照，不要用瞬时值下结论，否则容易误判成服务有问题。
排查顺序的实用写法：先看队列，再看输入长度，最后才看模型侧算子；把顺序固定下来，值班时不必每次重新想。