3、测试基础概念：区分帧率（FPS）、延迟（Latency）、吞吐量（Throughput）、准确率（Accuracy）和稳定性（Stability）的定义与计算方式
在BM1684/BM1688项目验收中，测试团队最常犯的错误之一，就是将帧率、延迟、吞吐量、准确率和稳定性这五个指标混为一谈，甚至用单一指标（如FPS）来评判整个系统的优劣。实际上，这五个指标分别从时间维度、空间维度、正确性维度和可靠性维度刻画了AI推理系统的不同侧面。帧率回答“每秒能处理多少帧”，延迟回答“单帧从输入到输出需要多久”，吞吐量回答“单位时间内系统能完成多少有效推理任务”，准确率回答“推理结果与真值之间的吻合程度”，稳定性则回答“上述指标在长时间运行中是否保持一致”。本章将逐一拆解这五个指标的定义、计算公式、测量方法及相互之间的制约关系，为后续章节的验收标准制定奠定理论基础。
3.1 帧率（FPS）：衡量系统处理速度的核心指标
3.1.1 核心原理
帧率（Frames Per Second，FPS）定义为系统在1秒内能够处理的视频帧或图像数量，其本质是系统处理能力的频率表征。在BM1684/BM1688项目中，FPS通常指完整推理链路（包括图像解码、预处理、模型推理、后处理）每秒能够完成的帧数。计算公式为：FPS = 总处理帧数 N / 总耗时 T（秒）。例如，若在10秒内处理了250帧图像，则FPS = 25。
3.1.2 测量方法与操作流程
- 确定测试集：选取与真实业务场景分辨率、内容复杂度一致的测试视频或图像序列，建议不少于1000帧。
- 预热系统：正式测量前先运行50-100帧，让芯片达到稳态温度、缓存填充完毕，避免冷启动影响。
- 计时测量：使用高精度计时器（如
std::chrono或gettimeofday）记录从第1帧输入到第N帧输出完成的总时间。 - 计算与记录：FPS = N / T，重复测量3次取平均值，同时记录最大值和最小值。
3.1.3 案例拆解：目标检测模型的FPS测量
在某智慧安防项目中，使用BM1684部署YOLOv5s模型，输入分辨率为1920×1080。测试团队选取了500帧包含不同场景（白天、夜晚、雨天）的监控视频，预热100帧后，测得处理500帧耗时18.5秒，计算得FPS ≈ 27.0。但进一步分析发现，白天场景FPS为30.2，夜晚场景仅为22.8，原因是夜晚图像噪声大导致预处理耗时增加。这说明FPS并非恒定值，与输入内容密切相关，验收时应按场景分别统计。
3.2 延迟（Latency）：感知实时性的关键指标
3.2.1 核心原理
延迟指从输入数据到达系统到输出结果产生的总时间间隔，通常以毫秒（ms）为单位。与FPS关注“平均吞吐”不同，延迟关注“单次请求的响应速度”，尤其在自动驾驶、工业质检等实时性要求高的场景中，延迟比FPS更重要。延迟的计算公式为：Latency = T_output - T_input。需要特别区分端到端延迟（包含采集、传输、处理全链路）和推理延迟（仅模型计算部分）。
3.2.2 延迟的统计口径
| 统计口径 | 定义 | 适用场景 | BM1684/88典型值 |
|---|---|---|---|
| 平均延迟（Avg） | 所有样本延迟的算术平均值 | 整体性能评估 | 30-80ms |
| P95/P99延迟 | 95%/99%样本的延迟阈值 | 尾延迟敏感场景 | P95 ≤ 120ms |
| 最大延迟（Max） | 所有样本中的最大值 | 极端情况评估 | ≤ 200ms |
3.2.3 案例拆解：延迟抖动分析
在某工业缺陷检测项目中，BM1688单次推理延迟平均为45ms，但P99延迟达到180ms。通过打点分析发现，延迟尖峰主要出现在以下环节：①当DDR带宽被其他任务占用时，输入数据拷贝耗时从2ms增至35ms；②当温度超过75℃时，芯片降频导致推理时间从40ms增至70ms。针对此问题，团队通过设置DDR带宽预留和优化散热方案，将P99延迟降至85ms。
clock_gettime(CLOCK_MONOTONIC)获取纳秒级时间戳。
3.3 吞吐量（Throughput）：系统整体处理能力的度量
3.3.1 核心原理
吞吐量指系统在单位时间内成功处理的任务总数，常用“帧/秒”“次/秒”或“GB/s”表示。与FPS的区别在于：FPS强调“视频帧”这一特定输入形态，而吞吐量更通用，可以是任意任务单元（如检测框数量、分类次数、数）。在BM1684/BM1688中，吞吐量计算方式为：Throughput = 完成任务数 / 总时间。当系统采用批处理（Batch）方式时，吞吐量 = Batch大小 × Batch数 / 总时间。
3.3.2 吞吐量与FPS的关系
在单流场景下，吞吐量数值上等于FPS；但在多路视频分析场景中，吞吐量 = FPS × 路数。例如，BM1684单路FPS为25，若同时处理4路视频，则系统吞吐量为100 FPS（但每路延迟不变）。需要注意的是，吞吐量提升往往以延迟增加为代价，因为批处理需要等待更多数据凑齐一个Batch。
3.3.3 实战场景：多路视频分析吞吐量测试
// 测试配置：BM1684，8路1080p视频流，YOLOv5s
// 批处理大小 = 4，推理引擎使用TPU-KERNEL模式
测试结果：
- 单路FPS：25.3
- 4路并行FPS：24.1（每路）
- 系统总吞吐量：96.4 FPS
- 平均延迟：从39ms增至52ms（批处理等待引入）
- 结论：吞吐量提升约3.8倍，延迟增加33%3.4 准确率（Accuracy）：推理正确性的核心保障
3.4.1 核心原理
准确率衡量模型推理结果与真实标注（Ground Truth）的吻合程度。在BM1684/BM1688项目验收中，准确率测试通常包含两类：模型算法准确率（与训练时一致）和部署后精度（考虑量化、算子优化带来的精度损失）。计算公式因任务类型而异：分类任务用Top-1/Top-5准确率；检测任务用mAP（mean Average Precision）；分割任务用mIoU（mean Intersection over Union）。
3.4.2 部署精度对比方法
| 对比项 | FP32参考模型 | INT8量化模型 | 允许偏差 |
|---|---|---|---|
| mAP@0.5 | 0.742 | 0.731 | ≤ 1.5% |
| Top-1准确率 | 0.815 | 0.802 | ≤ 2% |
| 单帧推理耗时 | 85ms | 32ms | — |
3.4.3 案例拆解：量化精度损失排查
某交通违章检测项目在BM1688上部署INT8量化模型后，车牌识别准确率从98.2%降至91.5%，超出验收标准。排查过程：①对比FP32与INT8模型在各层输出的余弦相似度，发现第12层（特征提取层）相似度仅0.82；②检查该层权重分布，发现存在极端离群值（最大值是均值的50倍）；③采用“逐通道量化”替代“逐张量量化”，并增加校准集样本至2000张，最终准确率恢复至96.8%。
3.5 稳定性（Stability）：长期运行的可靠性保障
3.5.1 核心原理
稳定性指系统在长时间连续运行过程中，各项性能指标（FPS、延迟、准确率）保持一致的特性。常用指标包括：变异系数（CV = 标准差/平均值）、漂移率（Drift Rate）和故障间隔时间（MTBF）。稳定性测试通常持续12-72小时，重点关注：①性能是否随时间衰减（如因内存泄漏、缓存失效）；②是否出现周期性波动（如因温度控制、DDR刷新）；③极端情况下是否发生崩溃或死锁。
3.5.2 稳定性测试流程
- 制定测试计划：确定运行时长（建议≥24小时）、监控指标（FPS、延迟、内存占用、芯片温度）、采样间隔（每30秒记录一次）。
- 持续运行：使用自动化脚本循环输入测试数据，模拟真实业务负载。
- 数据采集：记录每个采样点的FPS、延迟、内存、温度、CPU/TPU占用率。
- 数据分析：计算各指标的均值、标准差、CV值，绘制时间序列曲线，识别异常波动点。
- 结论判定：若CV ≤ 5%且无持续下降趋势，判定稳定性合格。
3.5.3 案例拆解：72小时稳定性测试发现内存泄漏
某智慧园区项目使用BM1684运行人脸识别服务，验收前进行72小时稳定性测试。测试结果如下：
时间区间 平均FPS 平均延迟(ms) 内存占用(MB) 芯片温度(℃)
0-6小时 28.5 42.3 512 62
6-12小时 28.2 43.1 548 64
12-24小时 27.8 44.5 623 66
24-48小时 26.9 47.2 758 68
48-72小时 25.1 52.8 934 71分析发现：内存占用从512MB持续增长至934MB，FPS从28.5降至25.1，判定存在内存泄漏。通过代码审查定位到后处理模块中cv::Mat未正确释放，修复后重新测试，72小时内存波动范围控制在±3%以内，FPS稳定在28.3±0.4。
3.6 五指标联动分析与验收决策
3.6.1 指标间的制约关系
在实际项目中，五个指标往往相互制约：提高批处理大小可提升吞吐量但增加延迟；量化模型可提升FPS但可能降低准确率；降低分辨率可提升FPS和降低延迟但影响准确率。因此，验收时必须建立多指标联合评估矩阵，而非单一指标达标即可。
| 优化手段 | FPS | 延迟 | 吞吐量 | 准确率 | 稳定性 |
|---|---|---|---|---|---|
| 增大Batch | ↑ | ↓（变差） | ↑↑ | → | 可能↓ |
| INT8量化 | ↑↑ | ↓（变好） | ↑↑ | ↓（轻微） | → |
| 多线程流水线 | ↑ | → | ↑ | → | 需验证 |
| 降低分辨率 | ↑↑ | ↓（变好） | ↑↑ | ↓↓ | → |
3.6.2 验收决策框架
建议采用“门槛+加权”方式：首先设定各指标的硬性门槛（如FPS ≥ 20、P95延迟 ≤ 100ms、准确率 ≥ 95%基线、CV ≤ 5%），任何一项不达标即判定验收失败；在全部达标的基础上，再根据业务优先级对指标加权评分，确定最终验收结论。例如，实时监控场景权重分配为：延迟30%、FPS 25%、准确率25%、稳定性15%、吞吐量5%。