MCP里用PyTorch做分布式训练，DDP总是卡住是啥情况？

我之前也踩过类似的坑，卡在初始化多半不是参数问题，而是MCP那个容器里默认的共享内存太小，DDP的进程组初始化需要IPC同步，建议试试加--shm-size或者直接设NCCL_DEBUG=INFO看卡在哪一步。另外torchrun其实会自己设MASTER_ADDR，你手动指定反而可能和它的默认值冲突，先注释掉看看。还有个小细节，如果用了gloo后端但网络配置不对，也会无限等待，可以换成nccl试试。

八成是MCP把NCCL的socket变量劫持了，试试在torchrun前手动unset那俩环境变量。

八成是init_method没指定，默认连的是env://，MCP那边环境变量可能被过滤了。试试直接传init_method='tcp://127.0.0.1:23456'，绕开环境变量最省事。

我之前也踩过DDP卡初始化的坑，多半不是MCP的锅，而是glibc或者NCCL的通信超时设置问题。你可以试试在启动命令前加export NCCL_DEBUG=INFO，这样能看到具体卡在哪个rank的socket连接上。另外如果用的是torchrun，记得检查一下env://这个默认初始化方式跟你的MASTER_ADDR是不是匹配，有时候手动设了环境变量反而会让它冲突。还有个容易忽略的点，单机多卡要确保每个进程的local_rank传对了，可以打印一下rank和world_size确认。要是还卡着，直接换gloo后端跑一下，能通就说明是NCCL的问题。

大概率是MCP把NCCL的socket接口给劫持了，试试设NCCL_DEBUG=INFO看卡在哪一步。

torchrun拉起前先确认下共享内存够不够，之前遇到过/tmp/shm太小卡死的坑。

我之前也踩过这个坑，最后发现是MCP的容器网络模式跟torchrun默认的NCCL通信对不上。你试试把init_process_group里的backend换成gloo跑一下，如果能通那就基本实锤是NCCL在MCP的虚拟网卡上建不了RDMA连接。另外检查下MCP是不是给每个进程分配了不同的PID namespace，torchrun靠pid发现rank有时候会失灵，手动指定rank和local_rank参数看看。还有一个隐蔽点，如果MCP的进程管理器把stdout重定向了，DDP的rank0会等所有进程的barrier日志输出，但日志被吞了看起来就像卡死。你可以加个环境变量NCCL_DEBUG=INFO，跑起来后看是不是在等待某个socket或者报busy loop。最后怀疑下共享内存，/dev/shm太小的话NCCL会死锁，MCP默认给得少，得在启动命令里加--shm-size参数。我自己后来干脆不用torchrun了，直接自己在脚本里手动spawn多进程，避开MCP对命令行参数的重写，反而稳得很。

大概率是MCP把NCCL的socket环境变量劫持了，试试在torchrun前显式unset掉MASTER_ADDR。

我之前也踩过这个坑，大概率不是MCP环境变量的问题，而是DDP初始化时默认用了gloo后端，但你的卡是NVLink互联的话，得显式指定nccl。还有个小细节，torchrun会自己设置MASTER_ADDR和MASTER_PORT，你手动再设一遍反而可能覆盖成错的，建议直接删掉相关配置试试。如果还卡着，可以在init_process_group前面加个print看看进程是否都走到了那一步，有时候是某张卡没同步上。

八成是MCP把NCCL的socket变量劫持了，你手动export一下NCCL_DEBUG=INFO看看卡在哪一步。

八成是MCP把NCCL需要的共享内存或者网络接口给劫了，试试设NCCL_DEBUG=INFO看卡在哪一步。

我之前也踩过这个坑，大概率不是MCP环境变量的问题，而是init_process_group里缺了backend参数，或者nccl的初始化没跟上。你试试把init_method设成tcp://localhost:23456，然后加个timeout参数，我这么改完就没卡过了。另外torchrun现在其实不推荐手动设MASTER_ADDR了，你检查下是不是有旧的环境变量残留，把distributed.launch的缓存清掉再跑一次，说不定就好了。

我之前也踩过类似的坑，症状完全一样，卡在init_process_group但没报错。后来发现是torchrun和MCP的容器网络模式有冲突，MCP默认可能启用了沙箱网络隔离，导致本机通信的gloo后端找不到可用网卡，尤其是多卡之间走的是lo回环地址，但环境变量里没显式指定NCCL_SOCKET_IFNAME或GLOO_SOCKET_IFNAME，它就卡在等待handshake。你可以试试在torchrun命令前加上export NCCL_SOCKET_IFNAME=eth0，或者干脆把init_method改成tcp://127.0.0.1:23456，绕开文件共享方式。另外，如果用的是最新版PyTorch，torch.distributed.launch已经废弃了，torchrun虽然兼容，但MCP的进程管理器可能会把stdin重定向成非阻塞，导致rank0卡在等待所有进程就绪的barrier上。我之前是把torchrun换成python -m torch.distributed.run，并且显式传--master_port=29500，再在代码里设置os.environ["NCCL_DEBUG"]="INFO"，就能看到具体卡在哪个集合通信上了。还有个小细节，如果你在MCP里定义了多副本（replica）策略，每个副本会各自启动训练进程，那WORLD_SIZE就得除以副本数，不然总进程数对不上，初始化永远等不齐。你检查下MCP的任务配置里是不是默认开了多副本，或者看看进程树里是不是起了两份torchrun。

八成是MCP把NCCL的socket变量劫持了，试试在torchrun前手动unset那俩环境变量。

先别用launch，直接python里调spawn试试，大概率是初始化顺序跟MCP的进程组撞了。

八成是MCP把NCCL的socket变量劫持了，先unset那俩环境变量试试torchrun。

之前我也卡这，最后发现是init_method没写tcp://，换个gloo后端直接秒过。

这问题我之前在MCP里也踩过，大概率不是环境变量冲突，而是init_process_group里漏了init_method或者backend没显式指定。你先试试把nccl换成gloo跑一下，能通的话基本就是网卡或者共享内存的问题，单机多卡经常栽在这。另外torchrun现在不推荐手动设MASTER_ADDR了，检查下是不是端口被占了，多开几个进程时容易撞。日志没报错但卡住的话，八成卡在等待rank同步，可以用strace或者加个超时看看具体卡在哪一步。

八成是MCP把NCCL需要的共享内存给限制了，试试加--shm-size参数或者换gloo后端。

八成是MCP把NCCL的socket环境变量劫了，试试在torchrun前头强制export NCCL_SOCKET_IFNAME=lo看看。

日志没输出多半卡在rank同步上，检查下init_method里是不是漏了tcp://前缀。

MCP的环境变量确实会覆盖PyTorch的，检查下有没有重复设置MASTER_PORT吧

MCP里用DDP卡初始化，十有八九是MASTER_ADDR或端口那步没对齐。我之前也踩过这个坑，表面看环境变量都设了，但torchrun内部会覆盖一部分，最好在代码里显式指定init_process_group的backend和rank。另外单机4卡记得检查下NCCL版本跟驱动是否匹配，有时候它会静默hang住。可以先拿个最小脚本只测init_process_group，排除是模型代码的问题。

卡初始化又没报错，大概率是进程间通信没建起来。先确认MCP有没有自己劫持RANK/LOCAL_RANK这些变量，跟torchrun的会打架。另外单机4卡记得把NCCL的socket网卡指定一下，比如NCCL_SOCKET_IFNAME=lo或者实际网卡名，不然它可能挑到不通的接口就干等。init_process_group里timeout设短点，卡住能直接抛错，比干等强。