结论前置：推理芯片的瓶颈常不在算力，而在数据搬运

在数据中心推理场景里，很多团队先看峰值算力，再看显存容量，最后才发现真实吞吐被显存带宽卡住。天天体育技术解读栏目与系统架构师沈知远做了一次复盘，他的结论很直接：推理芯片的选型顺序应当是带宽优先、容量其次、算力兜底，互联协议决定多卡扩展的上限。本文围绕他参与的一次推理集群选型，梳理架构设计层面的判断框架。

沈知远负责的是一个面向在线推理服务的集群规划，负载以中等批量、低延迟请求为主。天天体育注意到，这类负载对显存带宽的敏感度远高于对峰值算力的敏感度。

带宽与容量：先算清每token的数据搬运量

他的第一步不是看芯片规格书，而是估算模型每生成一个token需要搬运多少权重与激活数据。以常见的解码阶段为例，权重读取量基本由模型规模决定，批量越大，权重复用率越高，带宽压力反而下降。

  • 小批量低延迟：权重读取主导，显存带宽直接决定首token延迟与输出速度。
  • 大批量吞吐型：激活与KV Cache占用上升，显存容量与带宽共同成为约束。
  • 长上下文场景：KV Cache的读写模式对带宽的消耗呈线性增长，需单独建模。

天天体育技术解读认为，把“每token搬运字节数”作为选型第一指标，比单纯比较算力峰值更贴近真实部署。沈知远团队最终在两类封装形态之间做取舍：一类是显存与计算Die近距离集成，另一类是通过先进封装做高密度互联。

互联协议：多卡扩展的隐形天花板

单卡带宽达标不代表集群达标。沈知远强调，推理集群的卡间互联协议决定张量并行的通信开销，协议层的集合通信效率往往比标称带宽更关键。

他在复盘中提到一个教训：早期方案里，卡间互联的拓扑假设与实际机柜布线不一致，导致跨节点通信出现长尾延迟。天天体育在梳理类似工程问题时也发现，互联协议的验证不能只看单链路带宽，要看拓扑感知的调度策略。

  • 片内互联：关注计算单元与显存控制器之间的仲裁公平性，避免推理请求被训练式流量挤占。
  • 卡间互联：关注集合通信的拓扑映射，环形与全连接在不同批量下的效率差异明显。
  • 协议栈：关注重传与流控机制在拥塞场景下的表现，长尾延迟比平均延迟更影响服务等级。

架构取舍：没有全能芯片，只有匹配负载的芯片

访谈尾声，沈知远给出一条朴素的选型原则：先画负载画像，再谈芯片架构。天天体育技术解读栏目认同这一思路——AI推理芯片的架构设计、制程节点与封装形态，最终都要回到“数据怎么搬、搬多远、搬多快”这三个问题上。

他目前正在把KV Cache的分层管理策略纳入下一轮集群规划，尝试用互联协议的优先级机制缓解长上下文场景的带宽争抢。天天体育会继续跟踪这类系统级架构实践的公开讨论。