集群跑不满的原因不在芯片：互连与通信开销要先量出来
一、把”跑不满”拆成三层，原因才有落点
据公开报道，中国信通院给出的口径是：大规模分布式训练中网络通信耗时可以占到三到五成。这个区间值得读，但它是区间不是定论，成立前提是规模足够大、并且并行切分跨出了单机的边界。把它直接抄进自己几百卡不到的方案里，会得出”所有训练都卡在网络上”的错误结论，进而做出错误的采购决定。
要判断卡在哪一层，先做拆分。我们内部把利用率问题固定拆成三层，每层有自己的测量对象和失效方式。
单卡层看加速器本身在忙什么：是在算，还是在等数据。它的典型症状是设备利用率高但有效算力低，原因多半在算子实现、精度选择或者显存不足引发的频繁换入换出，与网络无关。
卡间层看同一台机器内部件之间交换中间结果的代价。这一段由整机结构决定，容量与拓扑都是既成的，用户能改的是切分方式而不是链路本身。
跨节点层看机器之间的网络：带宽、收敛比、拓扑对称性、故障与争用。这是最容易被远程因素拖累的一层，也是运维和采购真正有干预手段的一层。
之所以要这样分，是因为三层的整改成本差别极大。单卡层改代码就能修，卡间层要重排并行策略，跨节点层要么改作业放置要么换供应商。把它们混成一句”集群利用率低”，最常见的后果是在错误的层上做了一件本来正确的事。
二、通信占比可以测，但要按四个量分别测
洹拓科技给客户做训练性能归因时，交付物是一张”一个优化步的时间都花在哪”的分摊表，而不是一个总利用率数字。分摊表由四个量支撑，各自回答不同的问题。
第一个是梯度同步时间：在一个步内，从反向计算结束到参数更新开始之间，集合通信实际占用的墙钟时间。它回答”同步是不是在关键路径上”。注意它必须和第四个量一起读——如果同步与计算完全重叠，这个数字出现在统计里，却不出现在耗时里。
第二个是集合通信的带宽利用率：实际搬运的字节数，除以理论带宽乘以所用时间。这个数字偏低有两种解释，方向完全相反。一种是链路确实给不出这么多，需要看拓扑与争用；另一种是切分方式让传输呈现大量小包，每次通信的固定开销主导，加带宽毫无用处。分辨方法是改变单次搬运的体量再测：利用率随体量上升，说明是小包问题；不随体量变化，才更像链路受限。
第三个是同步步长的一致性：把各节点到达集合通信同步点的时间差记录下来。差值持续存在且固定，说明某段通信或某个节点慢；差值随机波动，才更像链路排队与争用。
第四个是慢节点定位，靠分布而不是均值。同一批步长时间序列里，如果总落后的是同一个节点，问题在它身上，应当先隔离它再看网络；如果落后的位置每轮漂移，网络的嫌疑才上升。
只有把重叠率单独量出来，前三个数字才能换算成真实损失。判断标准也很朴素：固定其他条件，把某个节点的步长单独拉长，看全局吞吐是否按同比例下降。按比例下降说明没有掩盖，不下降说明这层慢被计算吃掉了。
三、并行策略决定你需要多大带宽，别拿一个数字套所有场景
同样的硬件，换一种切分方式，通信需求会差出结构性的一截。谈互连瓶颈而不谈切分是没有意义的。
| 切分方式 | 通信发生在哪 | 最敏感的一段 | 放置上最常见的错误 |
|---|---|---|---|
| 数据并行 | 每步的梯度规约与参数广播 | 跨节点带宽、拓扑对称性 | 参与同一次规约的节点被分到不同收敛域 |
| 张量并行 | 层内中间结果的高频交换 | 节点内互连的延迟与带宽 | 把一个并行组跨机部署 |
| 流水并行 | 阶段边界上的激活传递 | 跨节点带宽、气泡占比 | 阶段边界与网络分组不一致，流量穿越核心层 |
| 专家并行 | 路由之后的跨设备分发 | 突发与负载不均 | 按静态流量做放置，热点设备挤在同机 |
由此得到一条可以写进作业提交规范的判据：切分组的边界应当与互连的分层边界对齐。节点内放得下的通信坚决不放到了机间；机间通信尽量落在同一个交换层内；需要频繁小消息交换的角色成组放置。
还要提醒一点：通信量不是模型的固有属性。是否使用梯度压缩、是否用重算换显存、精度选成什么、全局批大小与累积步数怎么配，都会改变这一层的负载。同一份代码在两种配置下的通信占比可以完全不同，这也是”别人的三成不能当成你的三成”的根本原因。
四、三类”看起来是 GPU 慢”的真实原因
第一类，批量太小，通信掩盖不住。当单步的计算量不足，同步时间的相对占比就上升，症状是”加卡不加吞吐，甚至越加越慢”。该动的是全局批大小、梯度累积步数、把一次大规约拆成多块与反向计算重叠，而不是升级网卡。这类问题的验证方式很便宜：只改批量测一轮步长曲线，占比立刻见分晓。
第二类，存储读取跟不上。数据加载是生产者，计算是消费者，一旦解码、增广或者海量小文件的随机读跟不上，加速器会周期性空转。它在时间序列上的形状是锯齿，而不是平滑地偏低，这个形状本身就是线索。归因动作是把单步拆成取数、前向、反向、同步四段分别计时：取数段在涨，网络和芯片都是清白的，该做的是数据格式合并、预取与本地缓存。
第三类，跨可用区或跨机架的带宽争用。同一个逻辑集群里的节点并不天然等价：跨机架要经过上层交换，跨可用区会引入额外时延与不确定性。典型表现是”小规模跑得正常，扩到全量后长尾出现”。查证方法是做一次成对的吞吐与时延测量，覆盖同机架、跨机架、跨可用区三种组合，并保留原始输出作为放置依据。没有这组对照，任何”网络不行”的结论都站不住。
五、不自建集群时，把互连写进合同和验收
多数企业客户不会自建训练集群，他们租用算力。这时上面所有问题都会转化成一件事：把可验证的指标写进合同附件与验收步骤，而不是出故障之后在群里扯皮。我们建议至少写清五项。
- 节点内互连的实际能力。不接受只有型号没有实测的交付，要求给出可复现的测试方法与原始结果，作为验收基线。
- 跨节点的带宽与收敛比。要写明任意两节点之间可达到的水平，以及在同机房其他任务满载时是否仍然成立。只承诺”接入带宽”是不够的。
- 故障节点与故障链路的替换时限。要落到时限和计数口径：什么状态算故障、多久内隔离、隔离期间不计费还是换机补位。
- 可观测数据的开放范围。集合通信耗时、网络丢包与重传、逐节点步长分布，至少有一项可以自己查，否则所有归因都得依赖供应商的一句话。
- 效率口径。约定按 MFU 还是 HFU 结算与验收，以及峰值算力按什么精度取。MFU 只计模型的有效浮点量，HFU 把重算掉的浮点量也计入分子，因此同一任务上 HFU 通常高于 MFU；口径没对齐，双方报出的数字看起来差很多但其实没有分歧。
六、先量再买，以及这条新闻对非训练团队的意义
写到这里可以给出一条判断标准：只有在做完通信与计算的占比拆分，并且确认瓶颈随规模而不是随实现变化之后，才进入扩产讨论。顺序颠倒的代价很直观——钱花在链路上，损失发生在取数或者切分方式上，利用率一动不动。
对绝大多数不买训练集群的企业，这条新闻的正确读法不是”要不要投资互连”，而是两件事。一是训练任务的预算里，通信与等待是可以被压缩的成本项，做一轮归因分析通常比追加资源便宜得多，这一点应当在和供应商或者内部平台组谈的时候拿出来。二是当你评估任何”算力平台”的时候，问的问题应该是分层的：单卡效率谁负责、卡间与机间带宽给不给实测、故障怎么处理、数据能不能自己看。四个问题都有书面答案的平台，才是可以把长任务放上去的平台。
我们把上面这套拆分与验收固定成了内部的性能归因模板：一次任务交付里必须留下分摊表、成组放置的说明、以及三种网络组合的对照测量。缺任何一项，就写清楚缺的原因和补测的时间。这个动作并不省时间，但它让”该不该扩容”从一个立场问题变成一个读表问题。