4. 性能建模与瓶颈定位方法
在EyeQ平台上做视觉性能优化，最忌讳“凭感觉改代码”。EyeQ芯片内部由多个异构计算单元组成——CPU负责调度与后处理，向量处理器（如EyeQ4/5中的VMP、SFP）承担卷积与像素级运算，专用加速器处理光流、深度等任务，同时还有共享的L2/L3缓存与DDR带宽。一个视觉任务从摄像头输入到输出检测框，会依次经过ISP、预处理、神经网络推理、后处理等多个阶段，每个阶段消耗的资源类型完全不同。因此，性能建模的第一步不是写代码，而是把任务拆解成“计算—内存—IO”三条资源主线，再分别量化。
一、建立三层性能模型
EyeQ视觉任务的性能模型可以抽象为三层：算子层、数据流层和系统层。算子层关注单个卷积、池化、激活函数的计算量与访存量；数据流层关注张量在DDR、L2缓存、片上SRAM之间的搬运路径与复用率；系统层关注多任务并发时CPU、加速器、DDR控制器的争用情况。三层模型不是孤立的，算子层的访存模式会决定数据流层的缓存命中率，而缓存命中率又直接影响系统层的DDR带宽占用。
以典型的YOLO类检测网络在EyeQ5上运行为例，假设输入为512×512×3，主干网络包含约30个卷积层。我们可以用“计算强度”（Arithmetic Intensity，AI）来初步判断瓶颈类型：AI = 浮点运算次数 / 访存字节数。当AI低于芯片的“拐点”时，任务受限于内存带宽；高于拐点时，受限于计算单元。EyeQ5的向量处理器峰值算力约2.5 TOPS（INT8），DDR带宽约12.8 GB/s，拐点大约在200 OPS/Byte附近。一个3×3卷积、输入输出通道均为64、特征图64×64的层，计算量约为2×64×64×64×64×9≈3.0 GFLOPs，访存量约为输入输出特征图加权重的字节数，约(64×64×64 + 64×64×64 + 64×64×9)×1 Byte≈0.56 MB，AI≈5400 OPS/Byte，远高于拐点，属于计算瓶颈。而一个逐元素相加层，AI通常只有个位数，属于典型的内存瓶颈。
二、用Profiling工具量化三类瓶颈
EyeQ平台通常提供两类profiling手段：一类是硬件性能计数器（PMU），可以读取每个计算单元的周期数、指令数、缓存命中率、DDR读写字节数；另一类是软件插桩，在任务关键节点打时间戳，统计各阶段耗时。实际工作中，两者结合使用效果最好。
对于计算瓶颈，重点观察向量处理器的利用率（Utilization）和每周期有效运算数。如果某个卷积层的利用率长期低于60%，说明计算单元在等待数据，问题可能出在数据供给上，而非算力本身。此时应检查该层的输入张量是否已驻留在L2或SRAM中，若每次都要从DDR重新读取，则实际瓶颈是内存而非计算。
对于内存瓶颈，核心指标是DDR带宽占用率和L2缓存命中率。EyeQ5的L2缓存约2MB，若一个特征图超过缓存容量，就会发生容量冲突，导致命中率骤降。例如，当特征图尺寸为128×128×256（约4MB，INT8）时，已超过L2容量，此时若连续访问多个大张量，缓存会频繁换入换出。优化手段包括：将大张量分块（Tiling），使每块能放入L2；调整算子执行顺序，让同一块数据在被换出前完成尽可能多的计算；使用NHWC布局替代NCHW，提升空间局部性。
对于IO瓶颈，需要区分“摄像头输入IO”和“DDR搬运IO”。摄像头输入通常通过MIPI CSI接口进入ISP，若ISP输出格式与后续预处理不匹配，会引入额外的格式转换和内存拷贝。DDR搬运IO则体现在DMA传输次数和每次传输的突发长度上。一个常见的反例是：每层卷积后都将结果写回DDR，下一层再读回，导致DDR读写量翻倍。正确做法是让连续多个算子在同一块SRAM缓冲区中完成，仅将最终结果写回DDR。
三、一个可复用的瓶颈定位流程
下面给出一个在EyeQ上定位视觉任务瓶颈的实操流程，以“检测网络推理耗时超标”为场景：
- 建立基线：在无其他负载的情况下，运行单帧推理，记录总耗时、各阶段耗时（预处理、推理、后处理）以及PMU中的DDR读写字节数、向量处理器周期数。
- 计算理论下界：根据网络总计算量和EyeQ峰值算力，算出计算下界；根据总访存量和DDR带宽，算出内存下界。两者取较大值即为理论最短耗时。
- 对比定位：若实测耗时接近计算下界，说明是计算瓶颈；若接近内存下界，说明是内存瓶颈；若两者都远低于实测，说明存在IO等待、调度开销或缓存冲突。
- 逐层下钻：对耗时最高的前5个算子，分别读取其PMU数据，计算各自的AI和缓存命中率，标记出“高耗时+低利用率”的算子。
- 验证假设：针对疑似内存瓶颈的算子，尝试将其输入输出张量改为分块驻留L2，重新测量耗时。若耗时明显下降，则假设成立。
四、常见误区与判断依据
在瓶颈定位中，有几个容易误判的地方。第一，把“耗时高”直接等同于“计算量大”。实际上，一个计算量很小的逐元素操作，如果访存模式差，耗时可能超过一个大卷积。判断依据是看该算子的AI是否低于芯片拐点。第二，忽略多任务并发的影响。EyeQ上通常同时运行多个视觉任务（如车道线检测、目标检测、交通标志识别），它们共享DDR和加速器。单独测每个任务都达标，合在一起却超标，说明系统层存在资源争用。此时应使用PMU的“每主设备带宽占用”数据，找出争用最严重的资源。第三，只看平均耗时，不看抖动。实时视觉任务对最坏情况延迟更敏感。如果某任务平均耗时20ms，但偶尔跳到50ms，需要检查是否有DDR刷新、中断风暴或温度降频。建议在profiling中记录P99耗时，而不仅仅是均值。
最后，性能建模不是一次性的工作。当网络结构、输入分辨率、并发任务数发生变化时，三层模型中的参数都会改变，需要重新校准。建议将上述流程固化为一个可重复执行的脚本或检查表，每次迭代后自动输出瓶颈报告，这样才能在EyeQ平台上持续保持视觉任务的性能可控。