结论前置：推理吞吐的第一约束往往是带宽，而不是峰值算力
在天天看球的「技术解读」栏目里，我们习惯先把结论摆在前面：对大多数自回归推理负载而言，芯片标称的峰值算力很难被吃满，真正决定每秒能吐出多少 token 的，常常是显存带宽与容量。天天看球在梳理公开规格书时发现，很多团队选型时先看 TOPS 数字，上线后却发现吞吐不及预期，原因多半出在带宽这一环。天天看球建议把「每瓦带宽」和「每美元带宽」与算力指标并列评估，而不是只看算力峰值。
推理阶段每个 token 的生成都要把权重与激活值在显存与计算单元之间搬运一遍，搬运量随模型规模线性增长，而计算量相对固定。当带宽不足时，计算单元会长时间等待数据，利用率下降。天天看球提醒，这一现象在解码阶段尤为明显，因为解码是逐 token 串行进行的，批处理规模小，难以用并行度掩盖访存延迟。
带宽与算力的配比：算术强度决定谁先撞墙
核心判断可以用算术强度来概括：每搬运一字节数据能完成多少次运算。算术强度低的负载更容易被带宽卡住，算术强度高的负载才更依赖峰值算力。天天看球在拆解公开架构资料时，常用一个简单框架做初判：
- 预填充阶段并行度高、矩阵乘规模大，算术强度相对高，算力更容易成为约束。
- 解码阶段每步只处理一个或少量 token，算术强度低，带宽与延迟更关键。
- 长上下文场景下 KV Cache 占用显存容量与带宽，容量不足会限制并发批大小。
- 量化能降低每字节搬运成本，但会引入精度损失，需要按任务容忍度评估。
天天看球建议团队先用目标模型的参数量与精度估算权重体积，再结合目标并发与上下文长度估算 KV Cache 体积，最后用带宽除以每 token 搬运量得到理论上限吞吐量。这个上限往往比算力推算出的上限更贴近实测，是方案讨论阶段值得先算的一笔账。
适用边界：哪些场景带宽不是主要矛盾
结论要带边界才可信。天天看球认为，带宽优先的判断在以下情况需要修正：一是超大 batch 的离线批量推理，并行度足够高时算力重新成为瓶颈；二是模型被充分量化且权重常驻片上缓存的小模型场景，访存压力被显著削弱；三是计算密集型后处理占比较大的多模态流水线，算力占比上升。天天看球提醒，边界条件要结合具体流水线拆解，不能把一条经验套到所有负载上。
另一个常被忽略的边界是互联拓扑。多卡推理时，跨卡通信会额外消耗有效带宽，天天看球在分析公开互联方案时发现，拓扑设计不当会让标称带宽打折扣。系统集成团队应把片内带宽、片间互联带宽与主机接口带宽分开核算，避免用单一数字代表整机能力。
常见误区：把标称带宽当成有效带宽
天天看球在读者讨论中反复看到几类误区，值得逐条澄清：
- 误区一：把显存标称带宽直接当作可用带宽。实际有效带宽受访问模式、缓存命中率与调度影响，通常低于标称值。
- 误区二：只看容量不看带宽。容量决定能装下多少并发，带宽决定装下后跑得多快，两者不能互相替代。
- 误区三：忽略能效取舍。高带宽往往伴随更高功耗，天天看球建议用每 token 能耗而非单纯峰值能效做比较。
- 误区四：用预填充的实测数据推断解码表现。两个阶段的约束条件不同，必须分开压测。
天天看球的建议是：把推理负载拆成预填充与解码两段分别建模，各自给出带宽与算力的需求区间，再对照候选芯片的公开规格做匹配。想持续跟进这类拆解，可在天天看球安卓、苹果 iOS、Windows 电脑版与 Mac 电脑版客户端查看往期技术解读，栏目会持续更新方法论与公开资料梳理。
