从单机多卡扩展到多机多卡，真正的工程门槛不在并行代码本身，而在网络、存储和任务调度这三件事。单机环境下，NVLink和本机磁盘替你遮掉了大量通信细节；一旦加上第二台机器，这些被掩盖的问题会全部浮出水面，并以报错、超时、训练中断的形式排队等你处理。
单机8卡和8机8卡有哪些本质区别
很多团队的路径是先在单机8卡上跑通小模型，然后换到双机甚至四机八卡去扩大规模，刚开始，你以为只是多开几台机器的事，实际跑起来才发现，单机8卡和8机8卡的区别，几乎等同于“调用GPU”和“搭建分布式系统”的区别。
通信链路的数量级落差
单机多卡之间走的是NVLink或PCIe Switch，延迟极低，带宽极高，跨机之后，数据只能走网卡、交换机和网线，即便你用上千兆网卡,带宽也比NVLink低了不止一个数量级。
数据并行训练中，每个step结束都要做一次全局梯度同步，通信量约等于模型参数总量乘以2，这个动作在单机上几乎是瞬间完成的，到了多机环境下，却可能成为整个训练流程的瓶颈，行业共识认为，多机多卡的实际训练吞吐，首先看通信能不能跟上,其次才看GPU算力。
代码语义一样，观察方式完全不同
单机多卡时，你只需要知道“本地有8张卡”，多机多卡后，你需要理解三个新概念：rank、world_size、master_addr，每个进程的rank变成全局编号，不再局限于0到7；World size变成所有卡的总数；主节点的IP和端口决定所有进程如何握手。
很多第一次跑多机训练的人，会把两台机器的nproc_per_node都设为8，却忘记把rank从0开始分别计算，这会导致初始化失败，或者多个进程抢同一个GPU，这类问题在单机环境下根本不会出现,属于多机场景特有的工程坑。
多机多卡分布式训练环境怎么配？五个必踩的坑
这里说的“配置”，不只是pip install和torchrun，而是从网络到存储再到运行时的完整链路，按出现频率排序,下面五个问题最值得提前排查。
共享存储缺失，另一台机器看不到数据
你的数据、checkpoint、日志，不能只放在主节点的本地磁盘上，多机训练要求所有节点访问同一份数据目录，NFS挂载是最常见的做法，如果你把数据放在单机本地盘，另一台机器会直接报找不到文件，或者更隐蔽地跳过部分样本,导致训练结果无法复现。
- 主节点执行：
sudo mount -t nfs 主节点IP:/data /data - 从节点执行同样的挂载命令
- 注意权限统一，uid和gid不一致会导致读写失败
端口和防火墙导致NCCL超时
PyTorch分布式训练默认走NCCL，主节点需要开放一个可用端口（比如29500），多机之间如果防火墙策略严格，或者交换机隔离了广播域，训练就会卡在“NCCL Timeout”。
实操建议：先在两台机器上用nccl-tests跑一遍all_reduce benchmark，确认通信链路是通的，如果超时，按顺序检查安全组／防火墙、MTU设置、以及网卡是否协商到预期速率。
环境不一致，数值悄悄漂移
两台机器上CUDA、GPU驱动、PyTorch版本存在差异时，程序不一定立刻崩溃，典型表现是：同一份代码在两台机器上跑出的loss曲线逐渐分叉,最终模型的精度也出现较大偏差。
解决这个问题的最直接方式是容器化，导出同一份NVIDIA镜像，确保每台机器运行相同环境,比在裸机上逐台对齐版本要省心得多。
启动命令暴露了你的习惯
很多人习惯了单机下写死的init_method，换到多机就开始懵，PyTorch 2.0之后，推荐直接用torchrun管理启动参数,不应该在代码里手写IP和端口。
torchrun --nnodes=2 --nproc_per_node=8 --rdzv_backend=c10d --rdzv_endpoint=主节点IP:29500 train.py
代码里只保留init_process_group(backend="nccl"),rank和world_size交给框架填充。
断点恢复不是可选项
单机训练挂了，重跑一遍通常能接受，多机环境下，重启整个集群的时间成本翻倍，checkpoint必须成为标配，保存路径要放在共享存储上，并且每隔一定步数保存一次,否则任何一个节点故障都会让整个训练前功尽弃。
多机多卡网络怎么选？跨机房值不值得
多机多卡和单机多卡在成本结构上差别很大，单机8卡整机采购时，一次性预算压力高，但运维简单，换成两台4卡机器，单台价格确实降下来了，但你要额外考虑机柜空间、交换机、光模块、布线甚至电费。
| 网络类型 | 适用规模 | 成本等级 | 推荐指数 |
|---|---|---|---|
| 千兆以太网 | 极小模型 | 低 | 不推荐 |
| 万兆以太网 | 小规模，勉强可跑 | 中低 | 一般 |
| RoCE | 中等规模多机 | 中 | 较好 |
| InfiniBand | 大规模训练 | 高 | 最好 |
同机房优先，跨机房基本别玩
多机训练对延迟非常敏感，同机柜内延迟在微秒到百微秒级别，跨机房延迟直接跳到几十毫秒，每个step都要做梯度同步，如此高的延迟会拖垮整个训练效率，北京、上海、深圳的IDC机房，计算节点和存储节点如果不在同一栋楼，就已经够呛；跨城市组多机,几乎不可能做到稳定训练。
这也解释了为什么很多公司选择算力租赁而非自建，租用同一机房的算力集群，按小时付费，比自己买两台机器放在异地要实用，尤其对于双机多卡这类临时扩容需求,云上租用反而能省下大量机房运营成本。
业内专家指出，多机多卡的真实性能表现不由GPU数量决定，而是由通信瓶颈和任务调度共同决定，跨机部署不等于速度翻倍，通信占比高的模型,在多机环境下的速度甚至可能不如单机8卡。
从单机脚本到多机脚本，最少要改哪些环节
实际改动量没有想象中那么大，如果只用DDP，核心改动集中在一个地方：启动方式。
把硬编码的进程协调交给torchrun
单机多卡场景下，你可以直接用torch.multiprocessing.spawn，传入固定的master_addr和master_port，多机场景下，rank和端口必须由协调者统一分配，让torchrun接管这些参数,代码会干净很多。
- 删除代码中写死的rank、world_size
- 保留
MASTER_ADDR、MASTER_PORT环境变量的读取逻辑 - 用
dist.get_rank()区分不同节点的行为
数据加载方式需要重新审视
单机多卡用DataLoader默认的shuffle逻辑没问题，多机环境下，每个节点各自shuffle会导致样本重复或漏采，建议在dataloader中设置固定的seed，并按rank偏移采样偏移量,保证每个batch覆盖全量数据。
梯度累积的节奏会变化
单机8卡时，梯度累积是为了模拟更大的batch size，跨机后，通信频次本身就会影响训练速度，如果你还想叠加梯度累积，需要额外注意通信与同步的配合，通信次数越多，网络开销越大,训练效率反而下降。
Q&A：多机多卡分布式训练常见问题汇总
多机多卡训练报NCCL超时怎么办
首先检查两台机器间的网络连通性，ping通不代表端口可用，还需要验证防火墙是否放行，接着用nccl-tests跑一遍小规模all_reduce测试，确认网卡驱动和固件版本一致，如果测试正常，再用小batch size跑一次完整训练，观察日志中卡在哪个阶段，多数超时问题都出在安全组策略、网卡MTU或交换机PFC配置上。
多机多卡一定比单机8卡快吗
不一定，通信占比高的模型，频繁的梯度同步会让网络成为瓶颈，多机环境下的吞吐甚至可能低于单机8卡，如果模型本身就较大，多机的显存总量可以容纳更大batch size，训练效率才有明显优势，建议先用小规模数据跑通性能测试，对比单机和多机的实际吞吐,再决定是否扩容。
双机多卡租用算力比自己采购两台机器更合适吗
需要看使用频率和任务持续性，长期运行、每周都要训练大量模型，自建机器按折旧摊薄成本低一些，但双机多卡还涉及机房托管、日常维护和GPU故障率问题，这些隐性成本经常被低估，短期项目或需求波动明显的情况下，租用同一机房的分布式算力集群更灵活,也不需要在任务结束后继续承担电费和带宽成本。