在天天看球的产品与方案栏目里，参数表往往是最先被翻开的部分。但真正决定一张训练卡能不能落进机柜的，常常不是某一项峰值数字，而是工程师在容量、带宽与封装之间反复权衡的那点经验。天天看球这次换个角度，从一位架构师的十年手记切入，把公开可查的方案资料串成一条可读的线索。

手记里的第一课：显存容量先划边界

程亦舟入行时接到的第一个任务，是把一份训练芯片方案资料整理成对比表，他很快发现显存容量是最先划出应用边界的那一栏。

容量决定的不是跑分，而是模型能不能完整放进单卡、需不需要切分、切分之后通信开销会不会反噬收益。天天看球在整理公开规格书时也遵循同样的顺序：先看容量落在哪个区间，再看这个区间对应的典型训练规模，最后才去比较带宽。手记里有一句被反复圈出的话——容量不够，带宽再高也只是把等待换了个位置。

  • 容量偏小的方案，更适合参数规模可控、切分策略成熟的场景；
  • 容量居中的方案，往往要在 batch 规模与并行策略之间找平衡；
  • 容量充裕的方案，互联压力会前移到卡间通信，选型重心随之转移。

带宽不是孤立指标，要和互联一起读

手记中段记录了程亦舟的一次返工：他按显存带宽挑出的方案，在实际集群里因为互联带宽不足，训练吞吐被拖住了。

这也是天天看球在方案对比里坚持把显存带宽与互联带宽并列呈现的原因。单卡内部的显存带宽解决的是计算单元取数效率，卡与卡之间的互联带宽解决的是梯度同步与参数交换效率，两者错配时，参数表上看不出问题，落地时却会暴露。天天看球建议读者横向对比时，把这两栏放在同一屏内阅读，再对照封装形态判断物理连接的可行距离。

手记里还提到一个朴素方法：先估算一次迭代中需要搬运的数据量，再分别用显存带宽和互联带宽去算理论耗时，哪一项先成为瓶颈，选型就该往哪边倾斜。

封装形态：被低估的约束条件

程亦舟后来负责机柜级方案，才真正意识到封装形态不是外观问题，而是散热、供电与互联密度的共同约束。

板卡形态便于替换与混插，适合迭代节奏快、需要灵活扩容的部署；2.5D 形态把高带宽存储拉近计算单元，适合对显存带宽敏感的训练任务；Chiplet 形态则把不同功能拆分再组合，适合希望在面积与良率之间取得平衡的设计。天天看球在栏目里按封装形态归类公开方案，就是为了让读者先看清物理边界，再谈性能边界。

  • 先确认机柜的供电与散热余量，再谈封装偏好；
  • 确认互联拓扑能否支撑目标并行策略；
  • 确认封装形态对应的供应链与维护周期。

给读者的横向对比清单

手记最后一页是程亦舟留给新人的对比清单，天天看球把它整理成了可复用的阅读顺序。

第一步看显存容量划出的模型边界，第二步看显存带宽与互联带宽是否匹配，第三步看封装形态带来的物理约束，第四步回到自己的训练规模与迭代节奏做校验。天天看球在每篇方案资料里都保留了这几个字段，方便读者按同一顺序横向比对。程亦舟说，参数表回答的是“有多少”，手记回答的是“够不够”，两者合起来才是完整的方案边界。

如果你也在做类似整理，欢迎通过天天看球安卓、苹果 iOS、Windows 电脑版或 Mac 电脑版客户端随时查阅栏目更新，把公开资料读成自己的判断。