结论前置：多数推理场景的瓶颈不在算力峰值，而在每瓦带宽

在主流大模型推理负载中，解码阶段的算术强度往往低于训练阶段，芯片算力峰值很难被持续占满，真正决定每秒生成令牌数的是显存带宽与带宽利用率。看个比赛技术解读栏目在梳理公开规格书时发现，同一代工艺下不同产品的算力差距可能只有三成，而显存带宽差距可达两倍以上，这直接解释了实测吞吐的离散度。对工程师而言，选型时先看带宽与容量的配比，再看算力，通常比反过来更接近真实表现。

需要强调的是，带宽不是单一数字。标称带宽、有效带宽、以及在实际批处理规模下能跑出的带宽利用率，三者之间常有明显落差。看个比赛在整理方案对比资料时，会把这三项分开列示，避免用一个峰值数字掩盖工程现实。

路线一：HBM堆叠代际带来的带宽跃升与成本曲线

HBM通过硅中介层与逻辑die互连，用更宽的接口换取更高带宽，代价是封装复杂度与单位容量成本。代际演进的主线是接口位宽与堆叠层数同步提升，同时单引脚速率上行，但每比特成本下降幅度远小于带宽提升幅度。这意味着堆叠代际升级对吞吐的改善是真实的，对成本结构的改善却有限。

  • 带宽增益主要来自位宽扩展，工程上要同步评估中介层面积与基板布线密度是否跟得上。
  • 堆叠层数提升会推高散热设计难度，热密度集中在中介层附近，封装与系统散热需协同设计。
  • 容量与带宽并非同比例增长，大容量型号往往在带宽上做妥协，选型要按负载的键值缓存需求反推。

从公开路线图看，堆叠代际的节奏相对稳定，但量产爬坡与良率爬坡并不同步。看个比赛建议工程师在方案评估阶段把封装产能与交期纳入模型，而不是只看规格表上的带宽数字。

路线二：片上缓存层级与数据复用决定有效带宽

同样的标称带宽，在不同缓存层级设计下跑出的有效带宽可能相差四成。核心在于注意力机制中的键值缓存访问模式是否被片上存储层级有效拦截。把高频复用的权重块与激活块驻留在靠近计算单元的SRAM中，可以显著降低对HBM的访问频次，从而把标称带宽转化为更高的有效吞吐。

工程取舍在于SRAM面积与算力密度的矛盾。增大片上缓存会挤占计算单元面积，降低单芯片算力峰值；但若缓存不足，带宽利用率上不去，算力峰值同样无法兑现。看个比赛在技术解读中反复提示，这是一个需要按目标负载建模的优化问题，而非越大越好的单向选择。

  • 先做访问轨迹分析，确认键值缓存与权重的复用距离，再决定缓存容量。
  • 关注编译器对数据布局的调度能力，同一硬件在不同软件栈下的有效带宽差异明显。
  • 批处理规模会改变复用模式，小批量低延迟场景对缓存的依赖更强。

路线三：近存计算的现实边界与导入节奏

近存计算把部分计算单元搬到存储侧，缩短数据搬运距离，理论上能显著改善能效比。但当前阶段的现实边界在于：可编程性弱、生态工具链不成熟、以及只适合特定算子。它更像是带宽瓶颈的补充手段，而不是通用替代方案。

较务实的导入路径是先在高频、规则、复用度高的算子上做卸载，例如部分矩阵向量运算，再逐步扩展。看个比赛观察到，公开文献中近存计算的能效收益多在特定负载下成立，通用负载下的收益会被数据调度开销侵蚀。因此评估时应要求给出目标负载下的端到端能效，而非单算子数据。

对工程师而言，三条路线并非互斥。合理的做法是以HBM堆叠保证带宽下限，以缓存层级优化提升有效带宽，以近存计算在特定算子上做能效补强，并按目标负载建立可核验的评估矩阵。看个比赛客户端在安卓、苹果iOS、Windows电脑版与Mac电脑版上同步更新这类技术解读，方便工程师随时对照方案参数。