能，但不能只看新增节点是否上线。训练集群横向扩容方案评估，应在正式接入前验证通信拓扑、存储吞吐、并发访问和故障恢复；否则节点数量增加，数据读取或梯度通信仍可能成为瓶颈。评估结果要对应实际训练任务和数据路径，而不是单看设备标称带宽。
先判断扩容会把压力推向哪里
先画出从训练进程到数据源的完整路径：节点之间经过哪些交换机，训练数据来自本地盘、共享文件系统还是对象存储，检查点写到哪里。记录现有节点数、网卡速率、链路汇聚方式、存储协议、数据集大小和并发作业数。重点确认新增节点是否与原节点共享上行链路，以及存储端是否存在统一的网关或元数据服务。
风险通常分为三类：一是网络过度订阅或链路配置不一致，导致通信等待；二是存储读取能力跟不上并行任务，节点空等数据；三是检查点集中写入时挤占训练读流量，甚至延长故障恢复时间。采用 RDMA 或 InfiniBand 的环境，还应核对端到端配置和交换网络路径，不能只确认网卡支持相关能力。
用分层测试提前暴露瓶颈
先测单节点，再测并发
先在一台代表性节点上检查网卡状态、链路速率和丢包，再逐步增加节点进行点对点与多对多通信测试。可使用 iperf3 检查 TCP 路径，用 nccl-tests 检查 GPU 集合通信表现；两者测量对象不同，前者不能替代训练框架实际通信验证。测试时记录吞吐、延迟、错误和交换机端口计数，并与单节点基线比较。
让存储测试接近真实访问模式
使用 fio 在测试目录中模拟训练数据的顺序读取、小块随机读取和并发写入。块大小、队列深度、并发进程数应参考数据加载器和检查点配置；测试文件要大于缓存能够轻易容纳的范围，避免把内存缓存误当成磁盘能力。若生产使用 Lustre，应同时观察客户端读写与元数据操作；若通过 S3 兼容接口读取对象，则要测试实际请求并发、对象大小和重试行为。不要在生产数据目录直接进行破坏性写入测试。
按步骤执行扩容评估
建立基线：在当前规模下运行固定数据集和代表性训练任务，记录数据等待、通信等待、存储吞吐及检查点耗时。
小批量接入节点：先增加一组节点，核对交换机端口、路由、MTU、存储挂载和权限，确认配置与原集群一致。
逐级提高并发：依次运行网络测试、存储测试和真实训练任务；每次只改变节点规模或并发度，便于定位性能变化来源。
加入混合负载：训练读取期间触发检查点写入，并观察共享链路、存储队列和元数据请求是否相互影响。
验证恢复：模拟单节点不可用或任务重启，检查检查点是否可读、恢复步骤是否清晰，以及恢复流量是否拖慢其余作业。
比较结果时看趋势与边界
不要把某个通用吞吐数字当作合格线。不同网卡、交换拓扑、文件系统、数据大小和软件版本会显著改变结果。更可靠的判据是：新增节点后，实际训练等待是否明显增加；共享存储是否出现持续排队；检查点时间是否超出作业允许的恢复窗口；多轮测试的结果是否稳定。若通信测试表现正常而训练变慢，应进一步检查数据加载、文件元数据和应用配置，而不是立即追加网络设备。
选择存储路径也要看工作负载。节点本地 NVMe 适合可重新生成或可分发的数据缓存，读取延迟低，但数据需要管理同步与失效；共享并行文件系统便于多节点访问，管理和运维要求更高；NVMe-oF 可提供网络化块存储能力，但仍需评估网络、目标端和多路径配置。不存在适用于所有集群的单一优选项。
结论与常见问题
训练集群横向扩容方案评估的核心，是把网络、存储与真实训练流程放到同一套分阶段验证中，并预设停止扩容的条件。发现瓶颈后，先定位是链路、存储服务还是数据访问模式，再决定调整拓扑、分散负载或改变数据布局。
只测网络带宽够吗？
不够。带宽测试无法覆盖存储排队、元数据访问、数据加载和检查点写入对训练的影响。
扩容前必须停掉现有作业吗？
隔离测试资源时通常更容易获得可比结果。若必须在共享环境测试，应选择低负载时段，并记录其他作业与存储负载。
什么情况应暂停继续加节点？
若新增节点后通信等待或存储排队持续恶化、检查点无法在恢复目标内完成，或错误与超时增加，应先停止扩容并排查共享瓶颈。
何时复测？
网络拓扑、存储配置、驱动或训练框架发生变化后应复测；即使配置不变，也可在扩容批次完成后用代表性任务验证整体表现。
