2. 性能优化基础

在深入BM1688的Batch、线程、内存与视频解码协同优化之前，必须先建立一套统一的性能度量体系。如果无法准确测量，优化就无从谈起——你无法判断一次改动究竟是提升了性能还是引入了回退。本章将围绕推理延迟、吞吐量、CPU占用率、内存带宽四大核心指标展开，讲解它们的物理含义、测量工具、计算方法和典型误区，为后续章节的调优动作提供量化基准。

上图展示了BM1688性能优化的核心测量框架：输入数据经过推理引擎处理后产生输出，在此过程中需要同时采集延迟、吞吐量、CPU占用率和内存带宽四个维度的数据。这四个指标相互关联又彼此制约——例如增加Batch通常能提升吞吐量，但会牺牲单帧延迟；多线程解码能降低CPU空闲等待，却可能增加内存带宽压力。理解它们之间的关系，是后续所有优化决策的基础。

2.1 推理延迟：从单次请求到端到端时延

核心原理

推理延迟（Latency）定义为从输入数据准备好到输出结果完全产生的总耗时。在BM1688平台上，延迟由三部分构成：预处理耗时（图像缩放、归一化、通道转换）、TPU计算耗时（模型在NPU上的前向传播）、后处理耗时（NMS、阈值过滤、结果格式化）。值得注意的是，BM1688的TPU与CPU是异步工作的，因此实际延迟并非三者简单相加，而是存在流水线重叠。测量时必须区分单次推理延迟（仅TPU计算）和端到端延迟（包含前后处理），两者在优化时的侧重点完全不同。

测量方法

1. 使用Python time.perf_counter()：在推理调用前后打点，适用于快速原型验证。注意需要预热10次以上，避免首次加载模型带来的冷启动误差。
2. 使用bmrt_test工具：Sophon SDK自带的benchmark工具，可直接测量模型在TPU上的纯计算延迟，支持多Batch配置。
3. 使用chrono::steady_clock（C++）：在C++部署环境中，使用高精度时钟测量端到端延迟，并分别记录预处理、TPU推理、后处理三段耗时。

// C++端到端延迟测量示例
auto start = std::chrono::steady_clock::now();
// 预处理
preprocess(input_image, &tensor);
auto t1 = std::chrono::steady_clock::now();
// TPU推理
bm_tpu_inference(&tensor, &output);
auto t2 = std::chrono::steady_clock::now();
// 后处理
postprocess(&output, &result);
auto end = std::chrono::steady_clock::now();

auto pre_ms = std::chrono::duration<double, std::milli>(t1 - start).count();
auto infer_ms = std::chrono::duration<double, std::milli>(t2 - t1).count();
auto post_ms = std::chrono::duration<double, std::milli>(end - t2).count();
printf("预处理: %.2fms, TPU推理: %.2fms, 后处理: %.2fms\n", pre_ms, infer_ms, post_ms);

案例拆解：延迟瓶颈定位

某安防项目使用YOLOv5s模型在BM1688上运行，目标帧率25FPS（即单帧预算40ms）。初步测量发现端到端延迟为52ms，超出预算30%。通过分段打点发现：预处理12ms、TPU推理18ms、后处理22ms。后处理耗时异常偏高，进一步分析发现NMS实现使用了Python循环而非向量化操作。将NMS改为C++实现并利用BM1688的SIMD指令后，后处理降至6ms，端到端延迟降至36ms，满足实时性要求。这个案例说明：延迟优化必须从分段测量开始，不能盲目优化TPU计算。

2.2 吞吐量：衡量系统整体处理能力

核心原理

吞吐量（Throughput）表示单位时间内系统能处理的样本数量，常用FPS（Frames Per Second）或QPS（Queries Per Second）表示。与延迟不同，吞吐量关注的是系统的并行处理能力。在BM1688上，吞吐量受三个因素影响：TPU的算力利用率、CPU与TPU的流水线重叠程度、内存带宽是否成为瓶颈。理论上，吞吐量 = 1 / 端到端延迟，但在实际流水线并行中，由于多级流水线重叠，吞吐量可以显著高于单帧延迟的倒数。

测量与计算方法

在BM1688上测量吞吐量时，必须注意输入数据的准备方式。如果使用单线程逐帧读取图片，CPU解码会成为瓶颈，测得的FPS无法反映TPU的真实能力。正确做法是使用多线程预取数据，或使用内存中的张量直接输入。

实战场景：多路视频分析

假设需要同时分析8路1080p视频流，每路25FPS，总需求为200FPS。使用bmrt_test测得模型在Batch=1时TPU推理延迟为8ms，理论最大吞吐量为125FPS，无法满足需求。将Batch增大到4后，TPU推理延迟为20ms（单帧等效5ms），理论吞吐量提升至200FPS。但实际测试发现FPS仅为160，原因是内存带宽饱和——4路视频同时进行预处理时，DDR读写冲突加剧。解决方案是错开各路的预处理时间，并利用BM1688的DMA引擎进行异步数据传输。

2.3 CPU占用率：平衡负载与功耗

核心原理

CPU占用率反映CPU核心的忙碌程度。在BM1688平台上，CPU承担三类任务：应用逻辑控制（调度、同步）、数据预处理（图像解码、缩放）、后处理计算。过高的CPU占用率（>80%）会导致系统响应变慢、任务调度延迟增加，甚至引发看门狗超时。但过低的CPU占用率（<20%）则可能意味着CPU在空转等待TPU，流水线未充分重叠。理想状态是CPU占用率在50%-70%之间，且各核心负载均衡。

测量工具与解读

• top/htop：查看整体CPU使用率及各进程占用，注意区分用户态（us）和内核态（sy）占比。
• perf stat：统计CPU周期、指令数、缓存命中率，判断是否存在指令级瓶颈。
• /proc/stat：采样两次计算CPU利用率差值，适合脚本化监控。

# 使用pidstat监控特定进程的CPU占用
pidstat -p $(pgrep -f your_app) 1 10
# 输出示例
# 时间    PID    %usr  %system  %guest  %CPU  CPU  Command
# 10:00:01  1234   45.2    12.3     0.0   57.5   2   your_app

案例：多线程解码的CPU瓶颈

某项目使用OpenCV的VideoCapture读取4路RTSP流，发现CPU占用率高达95%，但FPS仅为30。通过perf分析发现，超过60%的CPU时间消耗在H.264解码的软件实现上。BM1688虽然内置硬件解码器，但OpenCV默认使用FFmpeg软件解码。改用BM1688的硬件解码接口（bmcv_video_decode）后，CPU占用率降至35%，FPS提升至120。这个案例说明：CPU占用率过高时，首先要检查是否使用了硬件加速能力。

2.4 内存带宽：隐藏的系统瓶颈

核心原理

内存带宽指单位时间内CPU/TPU与DDR之间传输的数据量，单位GB/s。BM1688的DDR带宽是共享资源，TPU计算、CPU读写、DMA传输、视频解码都会消耗带宽。当带宽接近饱和时，所有组件的访问延迟都会增加，表现为系统整体性能下降。内存带宽瓶颈的典型特征是：增加Batch或线程数时，FPS提升不明显甚至下降。

测量方法

1. 使用bm_mem_profiler：Sophon SDK提供的内存带宽监控工具，可实时显示DDR读写带宽。
2. 通过性能计数器：读取BM1688的DDR控制器性能计数器，获取精确的带宽利用率。
3. 间接估算：对比不同Batch下的FPS变化，如果Batch从1增至2时FPS提升不足80%，可能存在带宽瓶颈。

优化策略与案例

在视频分析场景中，输入图像通常为1080p RGB（1920×1080×3 ≈ 6.2MB）。如果每帧都从DDR读取并写回，100FPS就需要约1.2GB/s的带宽。加上模型权重读取和中间特征图存储，总带宽需求可能超过3GB/s。某项目在Batch=8时发现FPS从预期的200降至150，通过bm_mem_profiler检测到带宽占用率达85%。优化措施包括：将图像从YUV420转换为RGB时使用硬件加速（避免CPU逐像素操作）、使用tensor的stride布局减少内存碎片、将中间特征图保留在TPU的SRAM中。优化后带宽占用降至60%，FPS恢复至190。