必须先看全局负载：用sar命令检查Load Avg、%usr+%sys和%iowait，若Load高但CPU使用率低则指向IO或锁阻塞；再通过nvidia-smi和perf top区分CPU与GPU瓶颈，警惕GPU-Util低实为CPU预处理拖慢；最后用iostat、strace和DataLoader配置确认IO瓶颈，避免因num_workers设置不当导致GPU饿死。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你发现Grok模型推理延迟飙升、吞吐骤降或训练卡顿，必须快速判断瓶颈落在CPU、GPU还是IO子系统——不能靠猜，也不能等日志堆满才动手。
第一步：看全局负载，排除假阳性
执行 sar -uqrSbBWSv -d -n DEV -rALL 1 5，采集5秒内全维度指标。重点关注三组数值：【Load Avg】是否持续高于逻辑CPU总数；【%usr + %sys】之和是否长期＞90%；【%iowait】是否＞15%且伴随await＞20ms。
如果load avg远高于CPU核数但%usr+%sys＜60%，说明进程大量阻塞在IO或锁上，不是纯CPU问题；如果%usr+%sys＞95%且load avg接近核数，才真正指向CPU密集型瓶颈。
第二步：区分CPU瓶颈与GPU瓶颈
方法一：用nvidia-smi -l 1实时观察GPU状态
盯住三列：GPU-Util（计算单元使用率）、Memory-Usage（显存占用）、Power Draw（功耗）。若GPU-Util长期＜30%但推理延迟高，说明GPU没被喂饱——问题不在GPU本身，而在前面的CPU预处理或数据搬运环节。
方法二：用perf top -e cycles,instructions,mem-loads,mem-stores -s comm
看顶部进程的指令周期比（IPC = instructions/cycles）：IPC＜0.8且cycles占比极高，大概率是CPU计算瓶颈；若IPC正常但mem-loads暴增且命中LLC-misses，说明CPU正在疯狂等内存，可能触发GPU等待数据就绪。
【关键陷阱】不要只看nvidia-smi里GPU-Util低就断定“GPU不忙”——Grok类大模型常因CPU端tokenizer慢、batch padding不齐、host-to-device拷贝未异步化，导致GPU长期空转。
第三步：确认是否IO瓶颈
第一步：跑iostat -x 1 5，重点看%util和await
若%util接近100%且await＞50ms，基本锁定磁盘IO瓶颈；但Grok训练/推理更多依赖NVMe SSD或RAM disk，所以更要查cat /proc/diskstats中rd_sec/s和wr_sec/s是否异常偏低——这说明应用根本没发IO请求，而是卡在了文件打开、mmap映射或HDFS客户端阻塞上。
第二步：用
strace -p $(pgrep -f 'grok' | head -1) -e trace=open,openat,mmap,read,write -T 2>&1 | grep -E '(open|read|mmap)' | tail -20</p> <p>这一步直接抓进程系统调用行为。如果看到大量<code>openat(..., O_RDONLY) = -1 ENOENT或
mmap返回-12（ENOMEM），说明数据路径出错或内存不足；如果read调用耗时动辄几百毫秒，才是真IO慢。
第三步：检查数据加载器（如PyTorch DataLoader）配置
确认num_workers设为CPU核心数的70%（非盲目设成CPU核数），pin_memory=True已启用，且prefetch_factor≥2。若num_workers=0，所有数据加载都在主线程做，GPU必然饿死——这时看似GPU空闲，实为IO调度缺陷。
