AI 加速器¶

简介¶

部分 SF32 器件提供 AI 加速器，在 SDK 中称为 NNACC，用于分担受支持的神经网络运算。它可用于端侧 AI，让推理在设备本地完成，而不依赖云端服务。能否缩短延迟（latency）、减少 CPU 占用或降低能耗，取决于模型、内存布局、软件实现和完整产品负载。

可穿戴设备、健康监测设备、智能显示设备、语音配件、传感器融合系统及小型 AIoT 产品都可以考虑采用这类加速。这些电池供电设备通常同时运行蓝牙（Bluetooth）、图形、音频、传感器采集和用户交互。将受支持的运算交给硬件，可能为其他任务腾出 CPU 时间；实际响应速度和节能效果仍需测量。

具体 AI 功能取决于 SF32 器件和 SDK 支持。在确定模型架构或内存规划之前，必须查阅目标芯片的数据手册、参考手册和 SDK 文档。

下文涉及的 CMSIS-NN 算子说明及各器件的 NNACC 数量，依据 SiFli-SDK v2.5.1 文档整理。该版本的 NNACC 指南列出了 SF32LB55x/56x/58x 各系列的 NNACC 数量，但没有确认 SF32LB52x 或 SF32LB57x 是否配备 NNACC；未列出不等于这些系列不具备该能力。地址窗口检查、等待行为及 GC032A 配置则是该版本 HAL 或驱动源码中的具体实现，并非所有芯片修订版或 SDK 版本的通用保证。所引用的 NNACC 指南和示例并未证明存在完整模型转换工具或计算图运行时、自动 CPU 回退，也未证明所有型号和开发板都支持摄像头采集。冻结设计前，请核实具体的 SDK 版本与配置、芯片修订版、运行时和开发板。

当你需要判断本地 AI 功能是否适合所选 SF32 器件，或需要为传感器、CPU、内存和加速器安排推理任务与数据处理职责时，请阅读本文。若要了解模型集成和部署流程，请先参阅配套的 AI 概览。

端侧 AI 的价值¶

许多嵌入式产品需要智能功能，却不适合持续把原始数据传输到手机或云端。端侧 AI 可以带来：

• 可能降低延迟：端侧推理可以避免与手机或云服务之间的数据往返，但仍应在整机上测量从传感器采集到作出判断的端到端延迟。
• 更好的隐私保护，因为原始生物特征、音频或运动数据可以留在本地。
• 更少的无线传输量，因为只需传输事件或摘要。
• 更好的离线能力，因为核心功能不依赖网络。
• 只有当准确率和检测覆盖范围相当，且完整功能在相同使用时长内消耗的能量更低时，平均功耗才会随之降低；比较时还需计入任务卸载（offload）本身增加的开销。

对可穿戴和 AIoT 设备而言，这些优势非常实际。例如，手表可以识别手势、检测活动状态、监测健康信号、识别简单语音触发或处理传感器数据，同时保持显示、蓝牙和应用处理器响应流畅。

这些收益都有前提。只有产品不再发送原始数据，本地处理才会减少无线传输量；保护隐私仍需要合适的存储方式、访问控制及传输数据保护。下文列出的应用是设计方向，不代表 SDK 已提供所有对应模型。

在 SF32 系统中的位置¶

简化的 SF32 端侧 AI 流水线如下：

传感器 / 音频 / 摄像头
        │
        ▼
预处理
  - 滤波
  - 分帧
  - 归一化
  - 特征提取
        │
        ▼
固件 / 推理运行时
  - 模型计算图调度
  - NNACC 支持的运算
  - 其他运算由 CPU 执行（前提是已有实现）
        │
        ▼
后处理
  - 阈值判断
  - 平滑处理
  - 事件检测
  - 应用层决策
        │
        ▼
应用、UI、蓝牙或存储

加速器只是完整 AI 流水线的一部分。实际产品仍需完成数据采集、缓冲、预处理、推理调度、后处理和应用层决策。围绕内存层级和可用加速器设计整条流水线，通常能获得最佳性能，而不是把推理当作孤立的函数调用。

AI 加速器的作用¶

AI 加速器之所以有用，是因为许多神经网络负载会把同样的数学运算模式重复执行成千上万乃至数百万次。这些模式可能包括卷积、矩阵乘法、向量运算、激活函数、池化或其他定点运算内核。专用硬件执行选定的内核时，能效可以高于通用 CPU。

这些是神经网络常见的计算类型，不是 SF32 NNACC 的支持清单。SiFli-SDK v2.5.1 NNACC 指南列出了 NNACC 可加速的三种 CMSIS-NN q7 卷积函数，包括逐通道卷积（depthwise convolution），并称启用 NNACC 加速的 CMSIS-NN 实现速度是 CMSIS-NN 中 Arm DSP 实现的 8 倍。该指南未说明这项数据的测试条件；应将其视为厂商公布的对比结果，而非对整个模型端到端延迟或能耗降低的保证。你需要逐项核对模型算子及其数值格式与所选实现是否兼容，不能据此认定矩阵乘法、激活函数或池化都能独立获得硬件加速。SDK 还提供用于直接控制加速器的 HAL API，但不要假定任一接口都包含完整的模型转换工具或计算图运行时。固件或单独的推理运行时仍需调度各层、管理缓冲区；若要回退到 CPU，还需为不受支持的算子提供相应实现。

SF32 器件的内存和带宽有限，因此宜从紧凑型嵌入式模型开始。核实具体型号的 NNACC 支持和算子覆盖，再测量整条流水线的内存占用、延迟和能耗；不能仅根据系列名称推断其支持情况。

常见 AI 工作负载包括：

• 关键词识别或简单语音事件检测。
• 根据加速度计和陀螺仪数据进行手势识别。
• 活动分类和运动状态检测。
• 可穿戴和健康设备中的传感器融合。
• 在传感器和算法支持范围内进行生物信号分析。
• 在支持摄像头输入的器件上进行简单图像分类或基于摄像头图像的分类。
• 异常检测和本地事件过滤。

CPU、加速器与内存的职责¶

可以将系统理解为：CPU 控制完整流程，加速器执行受支持且计算密集的内核。

加速器不能替代 CPU，也不能单独执行任意模型。固件仍需准备输入、配置受支持的运算、等待完成、处理结果并控制应用。只有所选运行时或应用已经实现了对应的 CPU 算子，不受支持的运算才能转交 CPU 执行；否则模型可能无法部署。芯片提供硬件加速，并不意味着软件会自动回退到 CPU。

器件系列定位¶

选型应依据算子兼容性、内存预算和完整产品负载，而不是按系列给出统一的性能排名。SDK v2.5.1 指南记载：SF32LB55x 和 SF32LB56x 的 HCPU 子系统各有一个 NNACC；SF32LB58x 的 HCPU 和 LCPU 子系统各有一个 NNACC。这些资源可以作为选型依据，但不能保证整个模型运行更快或耗能更低。你仍需核对具体型号和配置下的资源可用性、可访问内存及软件支持。

该表仅用于产品选型，不能代替数据手册。必须针对具体型号验证加速器是否可用、支持哪些算子、内存限制和 SDK 工具链。

模型开发流程¶

典型嵌入式 AI 工作流程包括：

1. 在工作站上使用具有代表性的数据训练或选择模型。
2. 通过模型选择、剪枝、量化或更改架构，使模型满足嵌入式约束。
3. 选择或实现推理运行时和模型表示方式，再核对其算子覆盖范围、数值格式与所选 SDK 计算内核是否兼容。不能默认 NNACC HAL 自带完整模型转换工具。
4. 转换和量化后验证数值精度。
5. 将预处理、推理和后处理集成到固件中。
6. 在真实硬件上分析延迟、内存占用、功耗和精度。
7. 在蓝牙、显示、音频和传感器并行运行的真实负载下测试，并覆盖进入和退出目标低功耗状态的过程。

最常见的错误是只优化神经网络，而忽略流水线其他部分。对许多嵌入式产品而言，预处理、数据搬运、传感器时序和后处理的重要性不低于加速器本身。

量化与模型大小¶

微控制器级 AI 通常依赖紧凑模型和高效数值格式。与浮点模型相比，通常采用 8 位整数数据的量化模型可以降低内存占用、内存带宽需求和计算成本。

模型采用 8 位格式，并不意味着它一定兼容 NNACC。SDK v2.5.1 HAL 配置使用 int8_t 缓冲区及 bias_shift / out_shift 字段。这些字段不能证明它支持任意零点、逐通道缩放或所有现代 int8 算子。你需要依据具体计算内核核对张量布局、有符号或无符号处理、移位及偏置的表示方式，再用有代表性的数据和边界输入，与软件参考结果逐项比较。

量化存在以下权衡：

• 可以显著提高效率。
• 可以减小模型体积和张量的内存占用。
• 如果训练或校准不谨慎，可能降低精度。
• 部分算子可能无法高效映射到加速器或运行时。

用于量产时，应在转换后同时测量精度和系统性能。桌面训练环境中表现良好的模型，在经过量化、真实传感器噪声和嵌入式预处理后，可能表现不同。

内存与带宽注意事项¶

即使模型文件看起来很小，AI 工作负载仍可能需要大量内存，包括：

• 模型权重。
• 输入张量。
• 中间激活缓冲区。
• 输出张量。
• 音频帧、传感器窗口或摄像头帧。
• 预处理和后处理缓冲区。
• 同时运行的 UI、蓝牙和应用数据。

应依据具体器件的内部 SRAM、Flash、PSRAM 和缓存配置，将频繁访问的张量及中间缓冲区放在 CPU 和加速器都能高效访问的位置。外部存储、工作缓冲区和数据复制应一起纳入预算，不能只优化模型大小。

先确认所选 NNACC 能访问每个缓冲区；数据放在外部 Flash 或 PSRAM 中，不代表硬件一定可以直接使用，可能需要先复制到工作缓冲区。内存预算和性能评估应计入复制时间、工作 RAM 及能耗。SDK v2.5.1 HAL 实现将检查用的缓冲区大小取整到 4 字节；如果起始地址与检查用的结束地址位于不同的 1 MiB（1,048,576 字节）地址窗口，就会拒绝该缓冲区。输入与偏置还必须位于同一窗口。结束地址恰好落在下一个窗口边界时，也不能通过该检查。你应按这些实际检查规则安排内存，并在启动下一次运算前处理错误返回。

CPU 与 DMA 或 NNACC 共享缓冲区时，每次传输或运算期间都应明确唯一的访问方。硬件读取前，先将 CPU 写入的输入数据从缓存写回内存。硬件写入前，按 SDK 要求处理目标缓冲区的缓存行，防止 CPU 的脏缓存行稍后写回并覆盖结果。确认硬件完成后，再使 CPU 中的旧缓存副本失效，然后读取输出。缓存维护范围应覆盖完整缓存行，且不要与其他仍在使用的数据共用这些缓存行。硬件写入后再写回旧输出缓存可能破坏结果；缓存写回（clean）与缓存失效（invalidate）不可互换。

音频、传感器与摄像头流水线¶

AI 加速很少单独工作，通常是传感器、音频或摄像头流水线的一部分。

音频与语音¶

语音或音频事件检测流水线可以包含麦克风输入、DMA 缓冲、分帧、滤波、特征提取、推理和检测结果平滑处理。NNACC 执行受支持的神经网络运算；其余计算图由固件或所选运行时处理，CPU 或音频子系统负责样本和特征管理。你仍需准备模型及经过验证的软件实现。

典型应用包括：

• 关键词识别。
• 在软件支持范围内实现唤醒词检测。
• 音频场景或事件分类。
• 语音活动检测。

运动与传感器融合¶

可穿戴产品的传感器数据通常来自加速度计、陀螺仪、心率传感器、SpO2 传感器、ECG 前端或其他外设。AI 可以识别运动状态、手势、活动模式或健康信号特征。

在检测覆盖范围和延迟要求允许时，可以批量处理样本，并利用中断触发处理。将适合的后台任务交给可由用户编程的低功耗处理器，可能减少应用 CPU 唤醒次数；但比较能耗时，也要计入该处理器的运行、传感器采样及唤醒开销。不能为了省电关闭检测目标事件所必需的采集。

摄像头与图像输入¶

摄像头接入取决于具体芯片、封装、开发板和采集驱动。SDK v2.5.1 GC032A 传感器驱动可配置 8 位 DVP 或两位 SPI 传感器输出，但这不能证明所有 SF32 器件都能通过这两种路径采集图像。选用摄像头前，需核对引脚、外设或 PTM 采集支持、传感器时序及驱动。图像负载通常比音频或运动检测需要更大的帧缓冲和更高带宽，但仍应按实际分辨率和采样速率比较。

可以考虑减小图像尺寸、仅处理感兴趣区域、降低帧率或选用面向嵌入式推理的模型。采集后再由固件裁剪图像，只会减小模型输入，不一定减少摄像头传输量或采集缓冲区；要降低这些开销，可能需要在传感器端裁剪或减少采集量。

调度与电源管理¶

AI 任务必须与系统其他部分协同调度。可穿戴产品可能需要同时保持蓝牙连接、刷新显示、采集音频、读取传感器并运行推理，同时满足功耗和延迟目标。

良好的调度方式包括：

• 根据检测覆盖范围、漏检风险和延迟要求，选择周期性推理或事件触发的推理。
• 可由中断或事件触发时，避免轮询循环。
• 在延迟要求允许时批量处理传感器样本。
• 控制从输入到判断结果的延迟，同时保留可靠检测所需的输入窗口。
• 协调 AI、显示和蓝牙工作负载。
• 确认运算完成、完成缓冲区交接并释放相关电源管理锁后，再让 CPU 和加速器进入允许的低功耗状态；仍需工作的传感器及其他待处理任务不能被一并关闭。

应通过对实测供电功率（供电电压×电流）进行时间积分，测量完整功能的能耗，而不能只看推理延迟。测量范围包括传感器采集、预处理、数据复制、加速器运算、CPU 回退计算、后处理及空闲间隔。执行更快可能减少运行阶段的耗能，但不一定能让系统更早睡眠；节能效果还取决于其他系统负载。降低推理频率前，应比较等效的检测覆盖范围和准确率。

SDK v2.5.1 的阻塞式 HAL 启动函数通过轮询等待完成，自身没有显式超时。中断方式需要正确接入 IRQ 处理函数和完成通知。你应检查启动错误、限制应用等待时间，并明确恢复流程，然后才能复用缓冲区或释放电源管理锁。

精度、延迟与功耗权衡¶

嵌入式 AI 设计需要兼顾精度、延迟和功耗。

最佳平衡取决于产品。手势检测器可以接受少量延迟来节省电量；语音触发要求快速响应，同时必须避免误唤醒；健康监测算法可能更重视稳健性和长期续航，而不是即时分类。

实用设计建议¶

规划 SF32 AI 产品时，应从产品行为而不是模型出发：

• 设备必须在本地作出什么判断？
• 哪些传感器提供输入数据？
• 推理需要多久执行一次？
• 可接受的延迟是多少？
• 模型权重和张量的最大内存预算是多少？
• 模型量化后能否保持足够精度？
• 所选芯片和 SDK 可以加速哪些运算？
• 蓝牙、显示、音频和推理同时运行时会发生什么？
• 如何使用真实产品数据验证模型精度？
• 如有需要，固件如何在现场更新或替换模型？

成功的嵌入式 AI 产品通常会结合紧凑的模型、规范的数据采集、适合硬件的内存布局、真实场景下的性能测量，以及避免无效唤醒的电源管理策略。

典型应用¶

当算子支持和系统实测预算满足要求时，可以考虑在联网、电池供电产品中用 SF32 AI 加速执行紧凑的本地推理：

• 手表、手环和手持设备的手势识别。
• 运动和健康产品的活动分类。
• 音频配件的语音事件或关键词检测。
• 可穿戴设备的传感器融合算法。
• 在传感器和软件支持范围内进行生物信号分析。
• 智能设备的本地异常检测。
• 在支持摄像头输入的设备上进行简单图像分类，或由摄像头输入触发事件。
• 根据用户情境调整行为的智能 HMI。

要点¶

• NNACC 可以分担受支持的运算，减少 CPU 占用；延迟和能耗收益应针对完整功能验证。
• 它只是完整流水线的一部分，系统还包括传感器、音频或摄像头输入、预处理、数据搬运、后处理和应用逻辑。
• SDK v2.5.1 记载了 SF32LB55x、SF32LB56x 和 SF32LB58x 的 NNACC 资源，但没有确认 SF32LB52x 或 SF32LB57x 是否配备 NNACC；应核实具体型号和工作负载，不能仅凭系列名称推断支持或不支持。
• 实际性能取决于模型大小、量化、受支持算子、内存布局、缓存处理、DMA 行为和 SDK 运行时支持。
• 本地推理的价值在于满足产品的响应速度、离线运行、隐私保护或无线传输量目标；仅有加速器硬件并不能自动实现这些收益。

最后更新: 2026-10-21