第1章：数据流与片上互联——NoC与Ring Bus

大家好，我是你们的讲师。今天咱们聊聊芯片内部的数据流动问题。

你想想看，大模型推理芯片里，动辄几十甚至上百个计算单元。它们之间怎么交换数据？总不能每个单元都拉一根线到另一个单元吧？那芯片得做成什么样？

这就是片上互联要解决的问题。说白了，就是给芯片内部修路。路修得好，数据跑得快；路修得烂，再强的计算核心也得堵死。

1.1 为什么互联这么重要？

我在做第一代AI芯片时，犯过一个低级错误。当时觉得计算单元性能够强就行，互联随便搞搞。结果流片回来，跑ResNet-50时，计算单元大部分时间都在等数据。利用率不到30%。

嗯，从那以后，我再也不敢轻视互联架构了。

大模型推理有几个特点，决定了互联必须精心设计：

• 数据量大：一个70B模型，光权重就140GB。片内SRAM根本放不下，得频繁从HBM搬数据。
• 通信模式复杂：有all-reduce、all-gather、点对点传输，还有广播。
• 延迟敏感：推理是实时任务，用户等不了。数据多等一个周期，延迟就多一分。

1.2 两种主流方案：Ring Bus vs NoC

目前业界主要用两种互联方式：环形总线（Ring Bus）和片上网络（NoC）。

我个人的习惯是，先看应用场景再选方案。没有绝对的好坏，只有合不合适。

1.2.1 Ring Bus：简单但有限

Ring Bus就是把所有节点串成一个环。数据沿着环单向或双向传输。

优点：

• 结构简单，布线容易
• 延迟可预测（每个节点最多绕一圈）
• 面积小，功耗低

缺点：

• 带宽受限（所有节点共享环带宽）
• 扩展性差（节点多了，绕一圈时间太长）
• 单点故障（环断了，整个系统瘫痪）

我曾经在一个16核的芯片上用Ring Bus。跑小模型还行，一上大模型，环上全是数据包，延迟直接爆炸。后来不得不改成NoC。

1.2.2 NoC：灵活但复杂

NoC借鉴了计算机网络的思想。每个节点通过路由器连接，形成网格或胖树拓扑。

优点：

• 高带宽（多条路径同时传输）
• 可扩展（加节点只需加路由）
• 容错（一条路径断了，走另一条）

缺点：

• 面积大（每个节点需要路由器和缓存）
• 延迟不确定（取决于网络拥塞程度）
• 设计复杂（路由算法、流控、死锁避免）

1.3 数据流的核心设计要点

不管用哪种互联，数据流设计都有几个关键点。我总结成三条：

1. 局部性优先：数据尽量在本地处理，减少跨片通信。我在做TPU-like架构时，把权重分片到每个计算单元附近，通信量直接减半。
2. 流水线化：计算和通信重叠。别等数据全到了再算，边传边算。这需要硬件支持异步DMA。
3. 带宽匹配：互联带宽要跟计算吞吐匹配。算力100TFLOPS，互联带宽只有50GB/s，那计算单元一半时间在空转。

1.4 一个实际案例：8芯片互联设计

假设我们要设计一个8芯片的推理系统。每颗芯片有32个计算核心。

我推荐用2D Mesh NoC。为什么？

• 8颗芯片，每颗内部32核，总共256个节点。Ring Bus肯定不行。
• 2D Mesh布线简单，适合芯片封装。
• 每颗芯片内部用局部Ring，芯片之间用Mesh。混合架构。

具体参数：

层级	互联方式	带宽	延迟
片内核心间	Ring Bus	256 GB/s	5-10 ns
片间	2D Mesh NoC	100 GB/s per link	50-100 ns
片外HBM	HBM3接口	819 GB/s	100-200 ns

你看，片内延迟低但带宽有限，片间延迟高但带宽大。设计时要把频繁通信的节点放在同一芯片内。

1.5 避坑指南

我踩过的坑，你们就别再踩了：

• 死锁问题：NoC里最头疼的。我曾经因为路由算法没设计好，芯片跑着跑着就卡死了。后来加了虚拟通道才解决。
• 拥塞控制：多个数据流同时发往同一个目标，路由器会爆。需要做端到端流控。
• 时钟域同步：不同芯片可能用不同时钟。跨时钟域传输时，一定要做同步处理。否则数据会错。

1.6 本章知识体系

下面这张图，是我手绘的NoC与Ring Bus对比框架。你看一眼就能明白核心逻辑。

这张图左边是Ring Bus，四个节点串成一个环。右边是NoC，九个节点组成3x3网格。你看，Ring Bus只有一条路径，NoC有多个路径可选。这就是本质区别。

---

公众号:蓝海资料掘金营，微信deep3321