第3章 · CPU性能瓶颈定位

CPU 是推理任务的“大脑”，但很多时候它并没有全力工作——或者忙在了错误的地方。我个人习惯把 CPU 性能分析比作医生听诊：先看整体负载（使用率），再听心跳节律（上下文切换），最后查毛细血管（缓存命中率、指令级并行）。这一章我们就一步步拆解，最后用一个真实案例把整套方法串起来。

3.1 CPU使用率分析——别被数字骗了

很多人看到 CPU 使用率 100% 就觉得“满负荷了，正常”。其实不一定。我遇到过好几次，推理服务 CPU 跑满，但吞吐量却很低。为什么？因为 CPU 可能在疯狂轮询、自旋，或者被中断风暴淹没。

我个人习惯用 top 和 htop 先看一眼，但更关键的是看 %user、%system、%iowait 和 %steal。如果 %system 超过 20%，说明内核态开销太大，大概率是锁竞争或系统调用频繁。

3.2 上下文切换——看不见的税

上下文切换是 CPU 的“隐形税”。每次切换，TLB、缓存都要重新预热。你想想看，如果每秒上下文切换次数超过 5 万次，那 CPU 基本在忙着“换人”，而不是干活。

用 vmstat 1 看 cs 列，或者 pidstat -w 看每个进程的切换量。我曾经在一个推理服务上发现每秒 12 万次上下文切换，最后定位到是线程池开得太多，加上锁粒度太粗。调整后吞吐直接翻倍。

3.3 缓存命中率——LLC miss 是性能杀手

现代 CPU 的 L1/L2/L3 缓存，命中率直接决定内存延迟。推理任务中，模型权重和中间激活如果频繁 miss LLC，性能会断崖式下跌。用 perf stat -e cache-misses,cache-references 可以快速看 miss 率。

我优化过一个 BERT 推理，发现 LLC miss 率高达 40%。后来通过模型权重重排、算子融合，把 miss 率降到 12%，延迟降低了 30%。说白了，数据局部性就是钱。

3.4 指令级并行性——CPU 的“隐藏流水线”

现代 CPU 可以同时执行多条指令，但分支预测失败、数据依赖会堵住流水线。用 perf stat -e branch-misses,branch-instructions 可以看分支预测准确率。如果 miss 率超过 5%，说明代码里有大量难以预测的分支。

我记得有一次优化一个循环内带 if 的算子，分支 miss 率高达 12%。改成查表法 + 无分支设计后，性能提升了 18%。嗯，指令级并行性往往被忽略，但它确实是压榨 CPU 的最后几招之一。

3.5 实战案例：定位一个 CPU 密集的推理任务瓶颈

假设我们有一个基于 Transformer 的推理服务，用户反馈延迟高。我按以下步骤排查：

1. top 看全局：CPU 使用率 800%（8核），但 %user 只有 60%，%system 占了 35%。不对劲。
2. vmstat 1：上下文切换 8 万次/秒，runnable 队列经常超过 10。
3. perf top：发现大量开销在 spin_lock 和 __schedule。锁竞争严重。
4. perf stat -e cache-misses,context-switches：LLC miss 率 28%，上下文切换 7.8 万/秒。
5. 定位到线程池：模型并行用了 16 个线程，但实际只有 8 核，且每个线程频繁申请临时内存。

这个案例里，如果只看 CPU 使用率，你可能会觉得“已经跑满了，没办法”。但深入拆解上下文切换和缓存命中率后，才发现真正的瓶颈是锁和内存分配。这也是为什么我总说：CPU 使用率高 ≠ 没有优化空间。

# 快速诊断命令组合（我常用的三板斧）
top -H -p <pid>            # 看每个线程的 CPU 消耗
perf stat -e task-clock,context-switches,cache-misses,branch-misses -p <pid> sleep 5
pidstat -w -p <pid> 1      # 每秒输出上下文切换次数
perf record -e cache-misses -c 1000 -p <pid> -- sleep 10; perf report