AI芯片HBM为何总喂不饱？片上互连怎么疏堵？

峰值带宽写得很高，实际执行却总像喂不饱阵列，这种落差常常不在 HBM 规格本身，而在数据流并没有均匀走到每一条通路。AI芯片若把外存分布和片上互连解耦看，理论带宽再大也会先堵死在局部热点。

HBM 首先不是一整块连续水库，而是由多个 stack、channel、pseudo-channel 和 bank group 组成的分层资源。地址映射一旦偏斜，某些头部、权重或 KV 缓存会长期压在同几条通道上，结果一边队列拉长，一边别的通道仍有闲量。此时监控上看到的平均带宽可能并不差，真正限制性能的却是最忙那几条通道的等待时间。

许多模型还会天然制造热点。注意力中的某些缓存张量被所有头部反复读取，MoE 路由后的热点 expert 也会在同一时刻吸来大量请求。若编译器和运行时只按线性地址铺排数据，而不考虑访问并发结构，HBM 的理论并行度很快就会被少数热点张量吃穿。把大张量切开不够，还得把访问相位错开，否则只是把热点切成多块同步热点。

片上互连的问题则更容易被低估。即便 HBM 端已经均匀出数，数据要送到阵列、共享缓存和归约单元之间，仍要经过 NoC、crossbar 或环网。多播分发、归约回写和指令流请求一旦在同一区域叠加，背压会沿队列一路反传，最后看起来像外存带宽不足，实际是片上网络先在某几跳被堵住了。

对AI芯片来说，互连拥塞最麻烦的地方在于它会把局部问题放大成全局抖动。某个 tile 的结果回写稍慢，就会拖住后续片段进入共享缓存；共享缓存入口一堵，前端 DMA 又开始积压；再往前，HBM 控制器看到的就是突发性回压，调度器也很难再维持均匀发放。于是一次局部塞车，最后演化成整个 pipeline 的呼吸式空转。

疏堵不能只靠加宽链路，因为更宽的链路若没有配套的仲裁和分流，热点仍会沿原路径堆积。更稳妥的办法通常是三层联动：先在张量布局上做地址交织，把天然热点拆散；再在编译时安排访存相位，减少同周期争用；最后在互连调度上给多播、回写和指令流不同优先级，避免低价值流量把关键数据堵在路上。

分析这类瓶颈时，单看总外存带宽和平均 hop 利用率都容易误判。需要把最忙 pseudo-channel 延迟、每跳队列占用、背压持续时间以及阵列等待来源一并摊开，才能看清究竟是 HBM 热点先出现，还是 NoC 某一段先发生拥塞。

若系统支持多模型混跑，问题还会更复杂。不同模型的访存相位和张量尺寸各异，单模型下均衡的映射到了混部时未必仍均衡。没有按业务组合做过压测的布局，往往在共享集群里最先露出外存和 NoC 的真实短板，尤其在长序列上。

所以，HBM 喂不饱往往不是规格书虚高，而是数据并没有均匀跑完最后一公里。把外存分布和片上互连一起梳顺，算力单元才不会总在等最慢那条路。