结论前置：选型先看瓶颈，再看峰值

推理芯片选型最常见的误区，是拿训练卡的峰值算力直接类比。推理负载的瓶颈往往不在算力本身，而在数据搬运、批处理调度与精度路径上。一个可操作的判断顺序是：先确认模型形态与批量大小，再核算显存容量与带宽是否够用，最后才比较算力与能效。看个比赛技术解读栏目在整理公开规格书时发现，多数选型失误发生在第二步——带宽账没算清，算力再高也跑不满。

下面五项指标，每一项都对应一份可以公开查到的资料，工程师可以逐条核对，而不必依赖厂商口头承诺。

指标一：显存容量与带宽，先算账再谈卡数

显存带宽决定了单位时间内能喂给计算单元多少数据，是推理帧率与吞吐的第一约束。核验方法很直接：用模型权重体积加上单批激活值，估算单卡显存占用；再用「带宽 ÷ 每 token 需搬运的字节数」估算理论上限吞吐。看个比赛在过往的技术拆解中反复强调，这个上限与实际测得值之间的差距，往往就是软件栈效率的体现。

  • 查规格书中的显存类型、容量与总线位宽，自行换算理论带宽，不要只看标称值。
  • 确认是否支持权重量化后的带宽收益，低比特路径能否真正减少搬运量。
  • 关注多卡切分时显存是否可池化，跨卡访问是否引入额外时延。

指标二：互联拓扑，单机与多机要分开看

单机多卡靠片间高速链路，多机集群靠节点间网络，两者的效率曲线完全不同。推理场景常做张量并行或流水并行，通信量随并行度上升，拓扑设计不当会让扩展效率迅速衰减。看个比赛的读者在部署实践中反馈，八卡以内的效率损失通常可控，跨节点后需要重新评估。

  • 核验片间链路的单向带宽与实测时延，注意是理论值还是可复现的公开测试值。
  • 确认集合通信库对主流框架的支持程度，是否开箱可用。
  • 估算并行策略下的通信占比，判断瓶颈落在计算还是互联。

指标三：能效曲线，别只看一个点

能效比通常以每瓦吞吐表示，但单点数字意义有限。真正有用的是功耗从三成到满载的整条曲线：低负载区间是否高效，直接决定在线服务的实际电费。看个比赛建议要求厂商提供不同批量、不同精度下的功耗与吞吐对照，并标注测试条件。

  • 核验测试条件是整卡功耗还是芯片功耗，是否含内存与互联。
  • 关注低批量场景的能效，线上推理的批量往往远小于离线压测。
  • 确认散热方案对应的持续功耗上限，短时峰值不等于长期可用。

指标四与指标五：精度支持与软件栈成熟度

精度路径决定能否在可接受的精度损失内换取吞吐，软件栈决定这些能力能否被实际调用。两项都属于「纸面之外」的指标，必须靠公开文档与可复现的示例来核验。看个比赛在整理术语百科时，把这两项列为选型清单的收尾项，因为前面三项算完，剩下的就是落地成本。

  • 核验支持的精度格式清单，以及每种格式是否有公开的精度对齐说明。
  • 查算子覆盖度文档，重点看模型中自定义算子与动态shape的支持情况。
  • 确认推理服务框架、量化工具链与监控接口是否齐全，多端调试是否方便。

把这五项做成一张核验表，逐条打勾，比对着算力排行榜选卡要可靠得多。看个比赛的客户端覆盖安卓、苹果 iOS、Windows 电脑版与 Mac 电脑版，工程师在机房现场也能随时翻查参数对照与术语解释，把选型讨论拉回可核验的事实层面。