第二章：性能调优基础

2.1 性能指标：四个核心维度

做边缘AI性能调优，说白了就是跟四个数字打交道：延迟、吞吐量、功耗、内存占用。我刚开始接触这个领域时，总觉得把模型跑起来就行，结果在客户现场被问得哑口无言——"你的方案延迟多少？功耗多少？"嗯，从那以后我学乖了，先搞清楚这四个指标再动手。

延迟（Latency）

延迟就是一次推理从输入到输出花的时间。单位通常是毫秒。我个人习惯把延迟分成三部分：

• 预处理延迟：图像缩放、归一化这些操作的时间
• 推理延迟：模型真正计算的时间
• 后处理延迟：比如NMS（非极大值抑制）的时间

你想想看，如果摄像头每秒来30帧，你推理一次要100毫秒，那肯定跟不上。我在项目中遇到过这种情况，最后发现是预处理用了Python的PIL库，换成OpenCV的C++接口后，延迟直接降了40%。

吞吐量（Throughput）

吞吐量是单位时间内能处理多少数据。比如每秒能处理多少帧，或者每小时能处理多少张图片。延迟和吞吐量其实是跷跷板——你强行压延迟，吞吐量可能就下来了。

举个例子：你有一个batch size为1的推理，延迟是10ms，那吞吐量就是100 QPS（每秒查询数）。但如果把batch size调到4，延迟可能变成25ms，但吞吐量能到160 QPS。为什么？因为硬件利用率上去了。我建议你在调优时，先明确业务要的是低延迟还是高吞吐。

功耗（Power Consumption）

边缘设备最头疼的就是功耗。你想想看，一个摄像头模组可能只有5W的功耗预算，AI推理芯片就得在这5W里分一杯羹。我见过一个项目，模型精度很高，但功耗超标，最后只能降频运行，结果延迟又上去了。

功耗的测量其实不难：

• 用功率计直接测整板功耗
• 或者用芯片自带的PMU（电源管理单元）读数

内存占用（Memory Footprint）

边缘设备的内存通常很金贵。比如一个树莓派只有4GB内存，你模型加载就占了2GB，那系统还怎么跑？内存占用包括：

• 模型权重：参数占的空间
• 中间激活值：推理过程中产生的临时数据
• 运行时开销：框架本身占的内存

我建议你用模型量化来降内存。比如把FP32的模型转成INT8，内存占用直接砍到四分之一。代价是精度可能会掉1-2个点，但大部分场景下可以接受。

2.2 性能分析工具介绍

工具这东西，用对了事半功倍。我这些年用过不少，挑几个最常用的说说。

perf：Linux自带的性能分析神器

perf是Linux内核自带的工具，轻量又好用。它能告诉你CPU在忙什么、缓存命中率多少、分支预测失败了多少次。

# 采样30秒，记录CPU周期和缓存事件
perf stat -e cycles,cache-misses,cache-references -p <PID> sleep 30

# 生成火焰图
perf record -F 99 -p <PID> -g -- sleep 30
perf script > out.perf
./stackcollapse-perf.pl out.perf > out.folded
./flamegraph.pl out.folded > out.svg

我个人习惯先用perf stat看整体情况，如果发现cache-misses很高，再深入分析。我曾经调一个模型，发现L1缓存命中率只有60%，后来把数据布局从NCHW改成NHWC，命中率直接升到90%。

gprof：GNU的调用图分析工具

gprof适合分析函数级别的性能瓶颈。它需要你在编译时加-pg选项，然后运行程序，最后用gprof生成报告。

gcc -pg -o my_app my_app.c
./my_app
gprof my_app gmon.out > analysis.txt

gprof的输出会告诉你每个函数被调用了多少次、花了多少时间。嗯，这里要注意：gprof对多线程程序支持不太好，如果你用的是多线程推理，建议用perf或者VTune。

Valgrind：内存问题的照妖镜

Valgrind最出名的是它的memcheck工具，能检测内存泄漏、越界访问、使用未初始化内存等问题。边缘设备上内存本来就少，泄漏一点就可能导致OOM（内存耗尽）。

valgrind --tool=memcheck --leak-check=full ./my_app

我曾经在项目中遇到一个诡异的问题：模型跑着跑着就崩了，查了两天才发现是某个算子实现里有个数组越界。Valgrind一跑，直接定位到第137行。从那以后，我每次提交代码前都会跑一遍Valgrind。

Intel VTune：专业级性能分析

VTune是Intel出的性能分析工具，功能非常强大。它能分析CPU的微架构事件、内存访问模式、线程并行效率等。虽然它主要针对Intel平台，但很多分析思路是通用的。

VTune的典型用法：

• 热点分析：找出最耗时的函数
• 内存访问分析：看缓存命中率和带宽利用率
• 线程分析：看多线程的负载均衡情况

我建议你刚开始用VTune时，先跑一个"热点分析"，看看CPU时间都花在哪了。很多时候你会发现，瓶颈不在模型计算本身，而在数据加载或者预处理上。

2.3 性能瓶颈识别方法论

工具是死的，方法论是活的。我总结了一套"三步走"的瓶颈识别方法，分享给你。

第一步：从宏观到微观

先看整体，再看局部。不要一上来就盯着某个函数看。我习惯的顺序是：

1. 看系统资源：CPU利用率、内存使用、I/O等待
2. 看应用层面：延迟、吞吐量、帧率
3. 看函数层面：哪个函数最耗时
4. 看代码层面：具体哪一行代码有问题

你想想看，如果CPU利用率只有20%，那说明程序根本没跑满硬件，瓶颈可能在I/O或者锁竞争上。这时候你去优化一个函数，效果微乎其微。

第二步：用"二八定律"找重点

80%的时间花在20%的代码上。这是性能调优的铁律。我建议你先用perf或者VTune找出那20%的热点代码，然后集中精力优化它们。

举个例子：我调过一个目标检测模型，发现80%的时间花在了NMS后处理上。后来我把NMS从Python实现改成C++实现，延迟从120ms降到了45ms。其他部分我根本没动。

第三步：排除法验证

找到瓶颈后，别急着改。先验证一下你的判断对不对。我常用的方法是：

• 替换法：把怀疑有问题的模块换成最简单的实现，看性能有没有提升
• 隔离法：单独测试某个模块，排除其他模块的干扰
• 对比法：换一个硬件平台或者框架，看问题是否还存在

常见瓶颈速查表

现象	可能原因	推荐工具
CPU利用率低，延迟高	I/O瓶颈、锁竞争	perf、Valgrind
CPU利用率高，但吞吐量低	算法效率低、缓存不命中	perf、VTune
内存占用持续增长	内存泄漏	Valgrind
功耗异常高	算力利用率低、频率策略不当	perf、芯片PMU

好了，这一章的内容就这些。记住，性能调优不是一蹴而就的事，需要反复测量、分析、优化。下一章我会讲具体的调优策略，包括模型量化、算子融合、内存复用这些实战技巧。到时候见。