第一课：认清你的硬件平台——CPU、GPU、NPU与内存带宽的瓶颈分析
各位同行，咱们直接开门见山。
现场调参，说白了就是跟硬件斗智斗勇。你模型再牛，算法再花哨，上了机器跑不动，全是白搭。我见过太多人，拿着笔记本上的跑分数据去部署，结果一到现场，推理延迟直接翻倍，甚至OOM（内存溢出）。
为什么会这样？
因为你没搞清楚手里的牌到底是什么。CPU、GPU、NPU，这三兄弟各有各的脾气。今天咱们就把它们扒开看看，到底谁在拖后腿。
1.1 三兄弟的分工：谁该干什么活？
先给个直观的对比。你想想看，一个深度学习模型从训练到部署，本质上就是一堆矩阵乘法加激活函数。但不同的硬件，干这活的效率天差地别。
| 硬件 | 核心优势 | 典型场景 | 我的个人感受 |
|---|---|---|---|
| CPU | 串行计算强，逻辑控制灵活 | 预处理、后处理、小模型、控制流 | 它像个老管家，什么都能干，但别指望它干重活 |
| GPU | 大规模并行计算，吞吐量高 | 大模型推理、训练、批量处理 | 它是主力军，但显存和带宽是命门 |
| NPU | 专用架构，极致的能效比 | 端侧推理、低功耗场景、定点量化 | 它是个偏科生，用好了是神器，用不好是摆设 |
核心观点： 现场调参的第一步，不是调模型参数，而是确认你的瓶颈在“算力”还是“带宽”。算力不够，换硬件；带宽不够，改模型结构或量化。
1.2 CPU瓶颈：别让老管家累死在路上
很多人觉得CPU不重要。错了。在部署流水线里，CPU往往是第一个卡脖子的地方。
我记得有一次在客户现场，GPU利用率只有30%，但推理延迟就是降不下来。查了半天，发现是数据预处理（图像解码、Resize、Normalize）全在CPU上跑，而且用的是单线程。CPU直接跑满了，GPU在那干等着。
CPU瓶颈的典型症状：
- CPU利用率100%：预处理或后处理代码没优化，或者用了Python原生的循环。
- 内存带宽打满：频繁的数据拷贝（CPU→GPU→CPU），DDR带宽成了瓶颈。
- 上下文切换频繁：进程/线程数开得太多，操作系统在调度上浪费了大量时间。
我的习惯： 现场第一件事，先看htop或perf。如果CPU的sys%很高（超过20%），大概率是内核态开销大，比如频繁的系统调用或中断。这时候我会检查是不是用了太多小文件I/O，或者锁竞争严重。
1.3 GPU瓶颈：显存与带宽的博弈
GPU是主力，但也是最容易出问题的。说白了，GPU的瓶颈就两个：显存容量和显存带宽。
显存容量不足：
- 模型太大，Batch Size稍微大一点就OOM。
- 解决方案：换小模型、做量化（FP16→INT8）、或者用模型并行。
显存带宽打满：
- 这是最隐蔽的瓶颈。GPU计算单元没跑满，但显存带宽已经到顶了。
- 典型场景：模型中有大量的逐元素操作（Element-wise），比如ReLU、Add、LayerNorm。这些操作计算量小，但访存量大。
- 解决方案：算子融合（Fuse Ops），把多个小操作合并成一个大的Kernel。
避坑指南： 我曾经在部署Transformer模型时，发现GPU利用率只有40%，但延迟很高。用nvidia-smi一看，显存带宽利用率99%。后来把LayerNorm和Residual Add融合成一个自定义算子，延迟直接降了60%。记住，GPU不是算力不够，是数据喂得太慢。
1.4 NPU瓶颈：偏科生的特殊癖好
NPU（神经网络处理器）这几年很火，但坑也最多。它不像GPU那么通用，每个厂商的NPU都有自己的“脾气”。
NPU的常见问题：
- 算子支持不全：模型里有个自定义算子，NPU不支持，直接回退到CPU执行，性能断崖式下跌。
- 量化精度敏感：NPU通常只支持INT8推理，但有些层对量化特别敏感，精度掉得厉害。
- 内存带宽受限：NPU的片上SRAM很小，如果模型参数或中间结果放不下，就得频繁访问DDR，带宽就成了瓶颈。
我的建议： 用NPU之前，先跑一遍厂商提供的Profiling工具。看看哪些算子是在NPU上执行的，哪些回退到了CPU。如果回退比例超过10%，我建议你重新考虑模型结构，或者换一个更兼容的模型。
1.5 一张图看懂瓶颈分析流程
下面这张图是我在现场排查问题时常用的思路，你可以把它当成一个检查清单。
1.6 内存带宽：被忽视的隐形杀手
最后，咱们单独聊聊内存带宽。这东西，说实话，比算力更难搞。
算力不够，你可以换卡。但带宽不够，你只能改算法。
为什么带宽这么重要？
- 现代GPU的算力增长远超带宽增长。比如A100，算力是V100的3倍多，但带宽只涨了1.7倍。
- 很多模型（尤其是Transformer）是带宽受限的，而不是算力受限。你算得再快，数据搬不过来，白搭。
实战经验： 判断一个模型是算力受限还是带宽受限，有个简单方法：看计算密度（Arithmetic Intensity）。计算密度 = 总计算量（FLOPs）/ 总访存量（Bytes）。如果这个值小于硬件的最佳计算密度（比如A100是~200 FLOPs/Byte），那它就是带宽受限的。
现场调参时，怎么缓解带宽瓶颈？
- 减少数据精度：FP32→FP16→INT8，访存量直接减半或减四分之三。
- 算子融合：把多个小Kernel合并成一个，减少中间结果的读写。
- 调整Batch Size：有时候增大Batch Size反而会降低延迟，因为带宽利用率更高了。但要注意显存上限。
- 使用更高效的访存模式：比如在CPU上用SIMD指令，在GPU上用共享内存（Shared Memory）。
避坑指南： 我曾经在调一个OCR模型时，发现推理延迟波动很大。查了三天，最后发现是内存带宽被其他进程抢占了。现场环境复杂，有时候不是你模型的问题，是隔壁进程在跑数据备份。所以，调参前先lsof或者nvidia-smi看看有没有“偷吃”的进程。
好了，这一课的核心就这些。记住，认清硬件平台，是现场调参的第一步。别急着调模型，先搞清楚你的瓶颈在哪。是CPU在拖后腿？GPU显存不够？还是带宽被吃满了？对症下药，才能药到病除。