AI加速器内部的计算单元正变得愈发密集。一颗芯片可能同时集成数十甚至数百个计算Tile，它们依赖片上网络（NoC）完成数据交换、任务分发和结果同步。算力规模越大，通信效率对整体资源利用率的影响就越直接。
过去，NoC的主要职责很单纯：把数据包从一个计算单元送到另一个，做好路由、仲裁和流量控制即可。但AI工作负载充斥着大量广播、归约与同步操作——同一份数据要同时抵达多个计算单元，或者多个计算单元的结果要汇聚到同一位置。
支持集合通信的NoC架构，将计算资源与片上数据传输网络连接起来。
当这类操作频繁到一定程度，单纯提高NoC带宽已经难以覆盖所有问题。MLSys 2026的一项研究给出了新思路：让NoC直接支持集合通信，使原本由计算单元组织的部分通信操作下沉到网络内部完成。
01｜AI计算为什么给NoC增加了新任务？
拿矩阵计算来说，同一组权重常常需要分发给多个计算Tile。传统单播网络可以把数据逐个发往每个目的地，但接收端一多，相同数据就可能在共享链路上被重复传输，白白占用带宽和路由器缓冲资源。
归约（Reduction）是另一类常见操作。多个计算Tile各自产生部分结果，需要借助求和、最大值等方式合并成最终结果。传统实现中，数据通常先被送到指定计算单元，再由该单元完成合并。随着参与者数量上升，数据汇聚容易造成局部链路拥塞，同步等待也随之增加。
组播与归约的数据流动特征差异较大，对片上互连提出了新的要求。
这两类操作分别对应集合通信里的Multicast和Reduce。它们并非AI芯片独有，但大规模并行计算显著提升了这些操作的频率，也让通信组织方式对性能的影响更加凸显。
问题的关键在于，传统NoC往往把这些通信模式当作普通数据包处理，而没有充分利用组播和归约自身的结构特点。
02｜让NoC理解组播和归约
MLSys 2026论文的研究人员基于开源FlooNoC，提出了一种支持集合通信的NoC架构。
在组播场景下，网络不必让发送端生成多份相同数据，而是借助路由结构在合适的分支点复制数据包。共享链路只需要传输必要副本，重复传输自然减少。
在归约场景下，研究提出了 Direct Compute Access（DCA）机制，让网络能够调动计算资源执行部分归约操作。这样，部分数据在传输途中就完成了合并，后续需要搬运的数据量随之下降。
DCA使NoC能够调用计算资源执行部分归约操作，减少不必要的数据传输。
需要注意，这并不意味着每个NoC路由器都变成了计算核心。研究重点在于让通信网络识别集合操作，并通过DCA协调计算资源，而不是在每个路由节点部署完整算术单元。
这种设计也避开了把大量计算逻辑塞进路由器所带来的面积、功耗和时序压力。
03｜通信优化能带来多少收益？
论文在支持集合通信的NoC原型上完成了评估。在1—32 KiB数据规模下，研究报告给出的几何平均加速如下：
- Multicast（组播）：2.9倍
- Reduce（归约）：2.5倍
- 路由器面积开销：16.5%
这组数据表明，对于集合通信特征明显的工作负载，网络结构优化能够显著压缩通信时间。
支持集合通信的NoC在1—32 KiB数据规模下获得组播与归约性能提升。
不过要清楚，这些结果来自论文评估的特定架构和数据规模，并不等于整个AI模型推理速度都能提升2.9倍。实际收益还取决于通信在总执行时间中的占比、计算与通信能否重叠，以及工作负载的具体拓扑。
从硬件设计角度看，16.5%的路由器面积开销同样值得关注。NoC支持更复杂的通信语义，意味着需要在路由资源、缓冲、控制逻辑和芯片面积之间重新权衡。
04｜NoC的设计边界正在扩大
传统NoC设计通常聚焦拓扑、链路带宽、路由算法、虚拟通道、仲裁和拥塞控制。这些基础机制依然重要，但面对AI计算，互连架构师还需要考虑数据本身的通信模式。
例如，某个计算任务是否存在大量一对多分发？多个计算单元是否频繁执行求和归约？网络能否在不引入复杂全局同步的前提下组织这些操作？这些问题都会影响NoC应当提供哪些硬件能力。
集合通信支持需要在NoC控制逻辑、路由资源与硬件面积之间做出权衡。
对NPU和SoC架构师而言，这也意味着计算Tile与NoC之间的接口可能需要承载更多通信语义。过去由软件或计算核心组织的广播、归约操作，如今可以通过硬件通信机制获得更高效率，但编译器和运行时也必须能够识别并调用这些能力。
NoC正在从通用的数据传输基础设施，向理解特定计算通信模式的专用互连演进。这并不要求所有SoC都增加集合通信支持。对于通信规模较小、数据流相对简单的设计，传统网络说不定仍然更划算。
但对拥有大量并行计算单元的AI加速器来说，NoC早已不只是连接计算核心的导线。它所支持的通信操作、数据复制方式以及与计算资源的协同机制，都可能成为决定系统效率的关键变量。
发表于 昨天 22:05
|
查看: 9|
回复: 0
