在人人体育的技术解读栏目里，我们习惯先给结论：显存带宽从来不是一个孤立参数，它是一张被互联拓扑、封装形式和制程节点共同拉扯的网。这句话说起来轻巧，但真正把它落到工程判断上，需要有人在一线反复试错。周立衡就是这样一个把带宽账算到小数点后面的人。

他先学会的不是算带宽，而是怀疑带宽

周立衡入行时做的是AI训练卡的硅后验证。他的第一份工作笔记里写着一句话：数据手册上的带宽是理论峰值，不是你能拿到的带宽。这句话后来成了他带新人的开场白。

他解释得很朴素：一颗芯片标称的显存带宽，是把显存接口位宽乘以等效速率再除以八得到的，但真正跑训练任务时，有效带宽会被访问模式、缓存命中率、互联拥塞层层打折。人人体育的读者如果只看厂商公布的峰值数字做选型，很容易在真实负载下发现落差。

  • 理论峰值带宽：接口位宽与速率的乘积，属于物理上限。
  • 有效带宽：实际负载下能稳定拿到的带宽，通常显著低于峰值。
  • 瓶颈位置：可能不在显存，而在芯片间互联或封装走线。

周立衡的习惯是把这三个数分开记，分别标注来源。他说，混在一起记，人就容易偷懒，把峰值当成果。

封装取舍：他为什么反对一味堆层数

第二年，周立衡转到封装协同的验证岗，开始接触先进封装方案。他的核心判断是：封装不是把显存堆得越高越好，而是要让带宽增长和散热、良率、成本同步走。

他做过一个内部对比，把同一颗逻辑die配不同数量的显存堆叠，观察有效带宽随负载变化的曲线。结论是带宽在某个点之后增长明显放缓，而热密度上升得更快。他把这个点称为“带宽甜点”，并坚持在评审会上把这个词写进结论页。

人人体育技术解读栏目一直强调术语释义，这里补一句：所谓带宽甜点，指的是在给定封装与散热条件下，继续增加显存堆叠带来的有效带宽增量开始低于系统代价增量的临界位置。它不是标准术语，而是工程团队内部用来对齐判断的说法。

  • 堆叠层数增加，单位面积功耗密度上升，散热设计余量被压缩。
  • 互联拓扑复杂度上升，信号完整性与时序收敛难度同步增加。
  • 封装良率随复杂度下降，成本曲线不再线性。

周立衡的结论是，封装方案要和目标负载绑定。训练场景追求持续高带宽，推理场景更在意首字延迟和能效，两者的甜点位置并不相同。

制程节点：他把它放回了它该在的位置

第三年，周立衡参与一颗推理芯片的架构评审。会上有人主张直接上更先进的制程节点，理由是“节点先进，带宽和能效自然好”。他当场提了一个问题：这颗芯片的瓶颈到底在计算还是在搬数据？

他的判断是，如果瓶颈在搬数据，那么制程节点带来的计算密度提升对整体性能的贡献有限，反而应该把资源投向显存接口和互联拓扑。他把这个思路整理成一页纸，标题写得很直白：先定位瓶颈，再谈节点。

这个观点和人人体育此前讨论过的封装取舍逻辑是相通的：制程节点是手段，不是答案。周立衡的说法更朴素——节点决定你能放多少晶体管，但决定数据跑多快的是带宽和拓扑。

  • 计算受限的负载，制程节点收益更直接。
  • 带宽受限的负载，显存接口与互联拓扑优先级更高。
  • 两者都受限时，需要先做量化拆解，再分配工程资源。

他坚持在每个项目里做一次瓶颈定位的量化拆解，哪怕结论是“维持原方案”。他说，验证岗的价值不是证明方案对，而是让方案错得明白。

他把经验写成了可复用的检查表

三年下来，周立衡攒了一份显存带宽相关的检查表，共十几条，覆盖从规格解读到负载验证的环节。他不认为这是方法论，只说这是“少踩坑的备忘录”。

这份检查表里最常被引用的一条是：任何带宽数字都要标注测试条件。没有测试条件的带宽数字，只能当参考，不能当依据。人人体育的读者在阅读芯片资料时，也可以用这条标准做一次自检。

周立衡现在依然在做验证，依然会在评审会上追问瓶颈在哪里。他说，工程判断的乐趣不在于一次选对，而在于把取舍的逻辑讲清楚，让下一个人少走一段弯路。