一、先分清是“算力不够”还是“路不通”

算网融合调度被讨论得多，用起来却常遇到一个尴尬场面：明明平台显示资源充足，任务还是慢，甚至比在本地机房跑得更久。这时候第一反应往往是“再加几张卡”，但加完之后速度并没有变化，投入落空，问题也没有找到。更务实的做法是先停下来分清层次：依次检查算力本身、网络通路、调度决策、应用与数据这四层，用排除法逐层收窄，而不是一上来就扩容。本文按这条思路，把算网融合调度中最常遇到的“变慢”拆成四层，给出每一层的判断依据、需要看的指标，以及两个可以反复使用的定位方法。

1.1 一个常见的误判

把网络因素当成算力因素，是这类场景里最普遍的一次误判。原因并不复杂：算力是看得见的数字，网络是看不见的路径。资源使用率、卡型规格、任务队列长度都能在控制台上一眼读到，而带宽够不够、路径有没有绕远、链路上有没有丢包，往往藏在中间环节。看得见的指标容易被当作答案，看不见的因素则被跳过。

1.2 三个需要先说清的名词

讨论定位之前，有三个名词需要先统一口径。

① 端到端时延：从发起请求到拿到结果的全部耗时，包含排队、传输、计算、回传各段，它是用户真正感知到的那个数字。

② 带宽与吞吐：带宽是通路在一段时间内所能承载的数据总量上限，吞吐是任务实际跑出来的速度。两者不是一回事，带宽足够而吞吐偏低，通常说明瓶颈不在容量，而在并发度、往返次数或者链路质量。

③ 丢包与重传：数据在通路上没有按时到达，需要重新发送。少量丢包对网页浏览几乎无感，对大规模分布式训练却是致命的，因为一次重传会让所有参与节点一起等待。

1.3 四层归因的顺序为何不能颠倒

顺序的意义在于少走弯路。四层的检查代价差异很大：

① 算力层代价最小，几条读数就能确认，几分钟内可以排除。

② 网络层次之，需要看链路指标或做一次分段测量，通常以小时计。

③ 调度层再次，需要回看任务放置与排队记录，可能要跨天比对。

④ 应用与数据层最费工夫，往往要改动代码或数据组织方式才能验证。

从代价最小的那一层开始排除，是这套方法的核心。反过来从应用层猜起，容易改了很久才发现是链路绕行。

二、第一层：算力本身是否真的够

2.1 三个几分钟能完成的检查

这一层不需要复杂工具，三个检查基本能覆盖大多数情况。

① 规格与占用是否匹配：申请的规格和实际跑起来的占用是否一致。有时任务跑在小规格上，或者多个任务挤在同一批资源里，显示的资源总量是够的，分到单个任务上的却不足。

② 显存与并发是否顶到上限：显存接近打满时会触发反复释放与申请，速度骤降但并不会报错；并发数开得过高，也会让计算部件频繁切换，反而变慢。

③ 任务是否被抢占或降级：在共享环境下，高优先级任务到来时低优先级任务可能被暂停或压缩资源。现象是“跑到一半突然变慢”，从日志里能看到明显的断点。

2.2 这一层被排除之后意味着什么

如果三项检查都正常，任务仍然慢，那就得到一个有价值的结论：问题不在计算能力，继续加卡不会有效果。这个结论本身就是进展，它把注意力从“扩容”转向“通路”。

三、第二层：网络通路的四类现象与判断依据

网络侧的问题不会自己写成一句话告诉你，但它会通过四类现象表现出来。把现象和判断依据对上号，是这一层最实用的部分。

3.1 吞吐上不去：是容量不足还是并发不足

同样是吞吐偏低，成因可以完全不同。判断时可以看两点：

① 单个大文件传输的速度是否正常。单流正常而多任务总量偏低，说明单条通路没有问题，问题在并发调度或任务切分方式。

② 传输过程中的往返次数是否偏多。小文件多、请求密集的场景，单次往返的固定开销会被放大，此时提升带宽几乎没有帮助，减少往返更有用。

3.1.1 一个实用的分辨办法

把同一批数据换成一个大文件重新传一次，速度明显改善，说明瓶颈在往返次数与请求开销；速度依然一样，才需要怀疑容量不足或链路质量。

3.2 时延忽高忽低：是绕行还是排队

时延波动比时延偏高更值得警惕，因为它说明通路上存在不确定因素。两种典型成因的区分方法如下：

① 绕行：数据走了一条地理上更远的路径。特征是波动稳定存在、与业务高峰无关，且跨区域访问时尤为明显。

② 排队拥塞：通路在特定时段被占满。特征是波动集中在固定时段，与业务量曲线高度重合。

把时延曲线和业务量曲线叠在一起看，两条线是否同步起伏，基本就能分辨出是哪一种。

3.2.1 两条曲线叠在一起看的方法

具体做法可取同一时段的两组数据：一组是通路上的时延读数，一组是业务的请求量或数据流量。若两条曲线同步起落，属于排队拥塞，处理方向是错峰或扩通路；若时延曲线平直地高出正常水位、与业务量无关，则更可能是路径绕行，处理方向是调整落点或改走更近的通路。

3.3 训练反复中断：丢包与链路质量

分布式训练对链路质量格外敏感。参与训练的节点之间有大量同步通信，任何一个节点的一次等待，都会让整轮计算停下来。现象上表现为：单机训练正常，多机训练速度随节点数增加而明显衰减，甚至出现周期性的卡顿。此时应重点看链路的重传比例与通信等待时长，而不是继续调参。

3.3.1 节点数增加而速度反降，通常说明什么

正常情况是节点越多、单轮耗时越短。若曲线在某个节点数之后掉头向下，说明新增节点的通信开销超过了它带来的算力增益。这一现象在算网融合调度里尤其值得注意，因为它提示的不一定是链路本身不好，也可能是任务被分散到了相隔较远的区域。把并行规模与实际通路能力匹配起来，比继续增加节点更有效。

3.4 跨域读写慢：数据在哪决定要走多远

跨区域调用时，慢的往往不是计算，而是数据往返。判断方法很直接：看任务读取的数据存放在哪个区域。如果计算在甲地、数据在乙地，每一次读取都要跨越长距离链路，速度自然受限。这类情况在算网融合调度里很常见，解法也不在扩容，而在把任务放到数据附近，或者把数据提前搬到任务附近。

四、第三层：调度决策是否把人放错了位置

4.1 三类调度侧原因

资源占着不等于用得上，调度层的问题常被误读为网络问题。三类原因最常见：

① 放置位置不当：任务被分配到距离数据较远、或者与其他高负载任务相邻的资源上。

② 排队与抢占策略：任务没有失败，只是一直在等。表现为“提交后很久才有反应”，从任务记录里能看到明显的等待时长。

③ 配额与上限限制：单任务可用的资源被配额封顶，实际并发能力低于预期。

4.2 一个典型现象：资源在眼前，任务在远方

使用方看到的是自己身边的资源池尚有余量，实际任务却被调度到了另一个区域。原因通常是就近资源被更高优先级的任务占住，或者就近资源不满足任务的规格要求。这类现象看似网络慢，实质是放置结果与使用方的预期不一致。确认方法只有一个：把任务实际的落点调出来看，而不是凭感觉推断。

五、第四层：应用与数据这一段最容易被忽略

5.1 三个可以自己调的参数

这一层不涉及平台配置，完全在使用方手里，也常是被忽略的一段。

① 批大小与并发数：批太小跑不满通路，批太大又容易在等待中空转，需要找一个匹配点。

② 读写模式：大量小文件随机读写，效率远低于顺序读写；把零散文件合并、把随机改成顺序，往往比扩容更有效。

③ 检查点与日志频率：过于频繁的落盘会与训练争夺通路，间隔可以放宽。

5.2 数据准备放在哪里

预处理放在计算侧还是数据侧，会直接影响通路压力。放在计算侧，意味着每次都要把原始数据搬过来；放在数据侧，只把处理后的结果传回，通路压力小得多。这一项在方案设计阶段就该定下来，事后改动代价较大。

六、判断要用的三组数据与两个方法

6.1 三组数据缺一不可

① 任务侧：提交时间、开始执行时间、结束时间、实际使用的资源规格。这组数据回答“等了多久、用了多少”。

② 算力侧：使用率、显存占用、并发数。这组数据回答“计算部件是否被喂饱”。

③ 网络侧：吞吐、时延、重传比例。这组数据回答“通路是否通畅”。

三组数据要放在同一时间轴上比对。只看其中一组，很容易得出错误结论：单看使用率会以为算力不足，单看时延会以为网络拥塞。

6.2 两个可以反复使用的定位方法

① 分段对照：把一次任务拆成数据准备、传输、计算、回传几段，分别计时。哪一段占比异常，问题就在哪一段。这是最直接的方法，也最容易被跳过。

② 单变量替换：只改一个条件，其他全部保持不变。比如把数据换到任务同区域再跑一次，或者把并发数减半再跑一次。变量唯一，结论才可靠；同时改三处，即便速度变好了，也不知道是哪一处起了作用。

6.2.1 单变量替换的操作要点

操作上有三个细节容易被忽略：一是输入规模要相同，否则耗时没有可比性；二是要跑足够多次，一次结果可能只是波动；三是替换的那一个变量要真的只有一个，比如换了数据位置，就要确保规格、并发、任务代码都没有同时变化。这三点做到，两三次测试就能得出结论。

6.3 记录口径要一致

两次对比的数据若口径不同，结论就是错的。需要统一的有三项：统计的时间窗口、是否包含排队时间、数据规模是否一致。这三点看似琐碎，却是很多“越优化越乱”的根源。

七、把归因变成常态的三条经验

① 先建基线，再谈优化：在业务平稳期记录一组正常数据，包含三组指标与典型任务的耗时。没有基线，就没有“变慢”这个判断本身。

② 给任务留标记：在任务提交时带上业务标识、数据位置、期望时长。事后回看时，这些标记能把一堆记录还原成一条清晰的线索。

③ 复盘写成结论而不是过程：每次定位结束后记下三句话，现象是什么、原因在哪一层、下次怎么更快发现。积累几次之后，同类问题基本可以凭现象直接定位。

八、天翼云息壤在“看得见”这一侧的支撑

归因方法要落地，前提是数据看得见、落点查得到。天翼云息壤相关产品能力可以从几个方面对应到上面的四层：

8.1 全局视图与任务可追溯

统一平台把算力资源、任务与用量收在一处呈现，任务的实际落点、排队时长、资源占用都能回看。这直接支撑第三层的判断：不必靠推测，把落点调出来看即可。

8.2 网络禀赋与跨域通路

云网融合是长期积累的方向，跨区域的数据回传与就近接入有专门通路安排，配合算力分发网络提供统一入口。对于跨域读写慢这类问题，通路侧的优化空间比单纯扩容更有针对性。

8.3 调度与编排能力

平台支持异构算力的统一封装与任务级调度，可按任务性质与位置安排落点，并提供配额分层与优先级设置，减少“资源在眼前、任务在远方”的情况。

8.4 安全合规与公开可查的资质

在数据分级、权限隔离与合规方面有相应机制，相关的规模数据、实践案例与资质荣誉可通过天翼云官网及官方渠道查询核对。本文涉及的产品信息、案例与荣誉均以官方渠道信息为准，具体条目与适用范围建议在评审阶段按需核对。

九、科普小结

算网融合调度带来的能力，不只是把更多资源连起来，更是让“慢在哪里”变成一个可以被回答的问题。四层归因的价值在于秩序：先用几分钟排除算力，再用小时级的观察判断通路，然后回看调度落点，最后才动应用与数据。顺序对了，绝大多数“变慢”都能在早期被定位，也不会出现加了资源却毫无改善的尴尬。