Coral NPU 开放 32 位架构与编译器

Coral NPU 开放边缘计算技术栈

Google 10 月 20 日的开发者帖子描述了开放的 32 位 Coral NPU 架构、v1.0 编译器基础和合作伙伴硬件。原始日期很重要：这是为 10 月 25 日发行选择的 10 月 20 日技术公告，而不是周日发布的新内容。谷歌表示，该架构的第一到第四个里程碑现已推出，包括可配置高达 1 TOPS 的矩阵执行单元，目标平均推理功率约为 10 mW。这些数字描述的是配置和设计目标，而不是针对每块开发板或每种负载的独立验证基准。完整的 32 位 RTL 从项目存储库链接，使得实现比单独的图表更易于检查。

为什么开放设计仍然需要编译器

加速器指令集只是可用边缘推理的一部分。开发人员从 JAX、PyTorch 或 TensorFlow 中的模型开始，然后需要导出路径、支持的运算符、CPU 和 NPU 之间的分区、内存布局、量化和可重复的性能测量。 Google 推出了基于 IREE 和 MLIR 构建的 Coral Compiler v1.0，作为软件桥梁。它表示该堆栈接受标准表示，包括 StableHLO 和 TOSA、算子融合、按本地内存容量对矩阵分块，并且可以模拟目标。编译器存储库是可用代码的主要来源。成功的编译并不能证明特定传感器产品的数值准确性或能源效率；这些需要电路板和测量设置。

该架构结合了 C 语言可编程 RISC-V 标量前端、RVV 1.0 向量单元和新矩阵单元。矩阵单元使用与 RISC-V VME 方向相关的专用外积乘法累加引擎。这种工作分工反映了常见的边缘模型：控制流和预处理看起来不像大型矩阵乘法，而注意力层和视觉层却常常如此。共同设计的软件堆栈可以决定每个操作所属的位置。需要在整个应用程序级别来衡量优势，包括传感器捕获、CPU 回退和内存​​移动。如果不受支持的操作在处理器之间重复移动数据，则高峰值 TOPS 数字可能会与较差的应用程序延迟共存。

区分架构目标与具体硬件规格

同一篇文章指出了 Synaptics Astra SR200 微控制器芯片的速度为 400 GOPS，并介绍了 Coralboard SR 开发套件。它还表示，Coralboard SL（被描述为 1 TOPS 板）在早期预览后通过 DigiKey 全面上市。这些不是可互换的测量：一个描述第二代微控制器系列，另一个描述一块板，可配置架构目标是一个单独的声明。文章报道了供应商宣布的内容；它没有测量每个地区的电力消耗、价格或可用性。评估产品的团队应在选择型号之前确认确切的芯片版本、内存容量、支持的编译器版本和实际购买状态。

开放 RTL 降低门槛，也暴露集成难题

发布 RTL 和编译器，为芯片与工具链团队提供了可检查、可实验的基础，但不会让成品芯片免去制造成本，也不保证现有模型的每个算子都受支持。硬件集成商仍需完成验证、时序收敛、软件驱动和安全认证。应用开发者则需测试模型经过压缩或算子替换后，边缘部署能否保持精度。文中的商业产品只是供应商给出的应用实例，不能据此推算整个行业的采用规模。

消息人士称，下一个路线图阶段包括 64 位架构和 CHERI 支持。这些只是计划，而不是 32 位版本的功能。当前需要 32 位的项目应该审查已发布的 RTL 和编译器，而不是围绕未来的分支进行计划。安全敏感设备还应该将内存安全目标与当今硬件和固件的隔离特性区分开来。同样的注意事项也适用于 10 mW 目标：平均推理功率目标并不是整个设备的电池寿命。无线电、传感器、CPU 和备用电源可以主导永远在线的产品。

可重复的边缘评估

选择一个紧凑的模型并发布试验中使用的精确图形、输入形状、数值公差和评估数据。首先运行 Coral 编译器和模拟器来识别不支持的运算符和 CPU 回退，然后在具有稳定时钟、电源仪器和环境条件的指定板上测量相同的模型。记录每次推理的端到端延迟、吞吐量、模型质量、内存使用和总系统能耗。与使用相同工作负载的纯 CPU 或其他加速器基准进行比较。如果模型需要重写层，请将重写报告为结果的一部分。该提议的协议将开放工具的声明与测量的产品性能分开。

重要的发展是工程师可以检查和调整的架构和编译器工件的可用性，以及具体的合作伙伴硬件。谷歌提供了主要代码链接和产品声明，但来源并未为每个边缘用例提供独立的跨设备基准测试。对于机器人、可穿戴设备和本地推理领域的读者来说，有用的下一步是测试他们自己的模型，而不是推断单一的 TOPS 数值或功耗数据。 10 月 25 日出版日期为社论；上游公告和其中引用的 Synaptics 事件的日期为 10 月 20 日。