结论：解码阶段的吞吐上限由带宽决定，不由峰值算力决定

对自回归大模型推理而言，每生成一个 token 都需要把模型权重完整读一遍（或读当前激活的部分），这个过程的耗时主要由显存带宽决定。看球宝技术解读栏目在梳理公开规格书时发现，很多方案宣传的算力数字与实际 token 吞吐之间缺少可换算的中间量，而这个中间量正是带宽。理解这一点，比记住任何单一算力数字都更有价值。

可以用一个极简的换算框架来估算：单 token 延迟约等于「单次需读取的权重字节数 ÷ 有效带宽」，再乘以并行度修正系数。这个框架不追求精确，但能快速判断一款芯片在特定模型规模下是否「带宽够用」。看球宝在整理参数库时，会把带宽、容量、算力三项并列展示，原因就在这里。

  • 权重读取量随模型参数量与量化位宽线性变化；
  • 有效带宽通常低于标称带宽，需扣除刷新、冲突与利用率损失；
  • 批处理能摊薄权重读取，但会推高容量占用与调度复杂度。

带宽利用率：标称值与有效值之间的落差

标称带宽是理论上限，实际推理中很难跑满。看球宝在对比公开数据时注意到，不同架构在相同标称带宽下的实测利用率差异明显，这直接改变了「哪颗芯片更适合解码」的结论。

影响利用率的因素包括访存模式是否连续、是否存在大量小尺寸随机读、片上缓存能否有效拦截重复访问，以及调度器能否把访存与计算重叠起来。以厂商「澜芯微」公开的架构白皮书为例，其在连续大块读取场景下利用率较高，但在稀疏激活导致的碎片化访存下会明显下降。这类差异无法从标称带宽单一指标中读出，必须结合访存模式一起看。

因此看球宝建议读者建立「场景—访存模式—利用率」的三段式判断习惯，而不是拿两个标称带宽数字直接相除。对于工程师而言，手里有一份自己业务负载的访存特征画像，比任何通用榜单都更可靠。

容量与带宽的取舍：为什么大模型推理不能只看带宽

带宽决定速度，容量决定「能不能装下」。当模型权重加 KV 缓存超出显存容量时，系统被迫走主机内存或跨卡通信，实际带宽会骤降一个量级，此前的带宽估算全部失效。

看球宝在数据整理中把这一现象称为「容量悬崖」：容量利用率在阈值以下时吞吐平稳，越过阈值后延迟快速抬升。工程上的应对方式包括量化压缩、KV 缓存分页管理、张量并行切分，以及把部分层卸载到其他存储层级。每种方式都会引入新的带宽开销，需要重新做一遍换算。

  • 量化降低权重字节数，同时往往降低单次访存效率，需实测权衡；
  • KV 缓存随上下文长度线性增长，长上下文场景下容量压力常先于带宽成为瓶颈；
  • 多卡切分引入互联带宽约束，互联规格需与单卡带宽同量级评估。

给工程选型的数据清单

看球宝建议在做推理芯片选型时，至少准备四组数据：目标模型的参数量与量化方案、目标上下文长度与并发数、业务可接受的单 token 延迟、以及可用的互联拓扑。把这四组数据代入前述换算框架，得到的结论通常比看算力排行榜更贴近真实体验。

需要强调的是，公开规格书里的带宽与算力都是理想条件下的数值，实际系统还受编译工具链成熟度、算子覆盖度与调度策略影响。看球宝在技术解读栏目持续整理这类可核验的公开参数与分析方法，帮助读者把数字还原成工程判断。无论你是在安卓、苹果 iOS、Windows 电脑版还是 Mac 电脑版上阅读，看球宝都希望这些内容能直接用于你的下一次架构讨论。