Chiplet 带宽实验：互连何时成为主成本

实验把一批 token 的跨 die 传输量 $B$ 除以有效互连带宽 $W$，得到传输时间：

$$T = B / W$$

并计算互连能耗：

$$E = B \times e$$

默认每 token 2 MiB、带宽 256 GB/s 时：

$$2 \times 2^{20} / (256 \times 10^9) \approx 8.2 \mu s$$

批量 16 个 token 再乘 16，延迟进入百微秒量级。对实时视频或控制回路，这已经可能超过计算本身。

设计顺序

1. 先把数据流分区，尽量让权重与激活留在本地 die；
2. 只为低复用、可流水的数据设计跨 die 路径；
3. 用压缩、批处理和预取隐藏部分延迟；
4. 把互连能耗与计算能耗相加；
5. 再评估封装良率与产品复用收益。

打开 Chiplet 带宽账本 调整参数。模型只回答“方向是否可行”，最终仍需封装与板级实测。

传输时间如何与计算重叠

跨 die 传输不是天然串行的。若数据可以被预取到双缓冲中，传输时间可以和本地计算重叠。设单批计算时间 $T_c$、传输时间 $T_l$，在理想流水线下总时间约为 $\max(T_c,T_l)$；如果必须等待传输完成才能开始计算，则接近 $T_c + T_l$。不同分区和调度方式会在这两个极端之间。

因此，模型算出的 $T=B/W$ 只是传输本身的下限，不是端到端延迟。它应该与计算窗口放在一起比较：

无重叠:  compute -> transfer -> compute
有重叠:  compute(block 1) || transfer(block 2)

如果每层都依赖上一层的完整输出，跨 die 通信就无法被隐藏。若能把注意力或前馈层切成独立 tile，并让下一块数据提前流入，链路利用率才可能提高。

带宽与能耗的联合预算

每 token 传输 2 MiB、互连有效带宽 256 GB/s，单 token 传输下限约为 8.2 µs。批量 16 个 token 时，若协议可以合并传输，时间可能只增加一次开销；若每 token 单独握手，延迟会接近 16 倍。批处理、协议聚合和流控策略会显著改变结果。

按每字节 $e$ pJ 计算的传输能耗，也要与计算能耗相加：

$$E_{\text{total}} = E_{\text{compute}} + B \times e + E_{\text{static}}$$

$E_{\text{static}}$ 包括 PHY、SerDes、时钟和链路的静态功耗。对低占空比的边缘设备，链路长时间保持开启可能比传输本身更耗电；对持续推理设备，静态功耗会被计算时间摊薄。

模型没有覆盖的物理层

这个实验忽略了：

• 链路训练、lane 降级和时钟补偿；
• 封装走线的阻抗与串扰；
• 协议重传和错误恢复；
• 跨 die 的一致性维护；
• 电源管理与 DVFS 切换；
• 计算与传输共享的片上网络。

这些因素可能让实际有效带宽低于标称值，也可能增加尾延迟。模型适合回答“架构方向是否正确”，不适合估算某款 UCIe 实现的实际吞吐。

如何做敏感性分析

建议至少扫描四个维度：

1. 每 token 跨 die 字节从 0.1 MiB 到 8 MiB；
2. 有效带宽从 32 GB/s 到 2 TB/s；
3. 批量从 1 到 64；
4. 重叠比例从 0 到 90%。

如果只有极端配置才能满足截止期，说明系统对分区或模型结构过于敏感。若在中等配置下仍有余量，再进入 RTL、封装和板级验证。

结论

Chiplet 的互连预算应该先于产品宣传。先证明常用数据流可以保持在本地，再证明剩余跨 die 数据能被流水隐藏。若互连时间与计算时间同量级，增加计算 die 的峰值只会让链路更早饱和。

有效带宽的测量

有效带宽应通过实际数据流测量，而不是直接使用 PHY 标称值。测试应包含大块顺序传输、随机小块传输、并发读写和不同 lane 数。协议头、流控和重传会让小包效率下降；温度与电压变化可能触发降速。

对推理负载，还要测“每 token 有效字节”。若权重和缓存高度复用，实际跨 die 数据可能远小于模型大小；若每层都同步完整激活，数据量会迅速放大。软件 trace 是估算的起点。

降级与容错

封装内某条 lane 或某个 die 失效时，系统是否还能运行？可设计降带宽模式、禁用部分计算单元或切换到本地小模型。降级策略必须提前验证，否则故障时才发现软件依赖完整互连。

可复现实验

每次实验保存：

• 每 token 字节与批量；
• 有效带宽和测量方法；
• 链路频率、lane 数和协议开销；
• 计算时间与重叠比例；
• 能耗、温度和错误率。

结论只有在这组条件下才成立。Chiplet 的数据流账本应当与封装、热和软件团队共同评审。

此外，模型应把“有效带宽下降”作为独立场景。若链路因温度、lane 故障或拥塞只能达到标称值的 50%，系统是否仍满足截止期？如果答案依赖理想链路，就应增加本地缓存、降低跨 die 数据量或设计可关闭的功能。Chiplet 的可靠性来自分区和降级，而不是寄望于互连永远满速。

该模型也不应被用来比较不同厂商的 UCIe 实现。链路训练、封装距离、时钟模式和错误率都会改变有效带宽。跨厂商比较必须使用同一 trace、同一 batch 和同一功耗状态，否则只是比较宣传口径。

把模型输出写进设计文档时，最好同时列出“可接受的最差互连带宽”。如果系统在带宽降至一半时仍能降级运行，架构就更稳健；如果一降速就错过截止期，说明本地缓存和分区策略还不够。

同时，把跨 die 传输的能量计入每 token 成本。只比较延迟会漏掉移动设备最敏感的热和电池约束。

最后，保留链路空闲功耗与唤醒延迟这两种基线，才能判断持续推理和间歇推理是否采用同一种分区方案。

对每个分区方案，都应记录最坏吞吐而不是只给平均吞吐，确保结论可用于截止期判断。