1. 三机 DGX 跑 DeepSeek-V4.1-Flash到底在解决什么问题先把场景说清楚。DeepSeek-V4.1-Flash 这个量级的模型单机八卡 DGX 想跑满上下文、跑出可用的吞吐基本是捉襟见肘的。权重本身加上 KV Cache再算上激活值显存压力非常大。所以三机 DGX 组一个小集群用张量并行加流水线并行的方式把模型切开是很多团队在预算和性能之间找到的平衡点。这套方案的核心目标很明确用三台 DGX 拼出一个能稳定服务 DeepSeek-V4.1-Flash 的推理节点支撑中等规模的并发请求同时把首 token 延迟和吞吐控制在一个可接受的范围。为什么是三机而不是两机或者四机。两机的话模型切分的粒度不够细单卡显存占用还是偏高尤其是长上下文场景下 KV Cache 增长很快容易 OOM。四机当然更宽裕但机器间的通信开销会明显上升而且三机在张量并行度上刚好能凑出比较合理的切分方案比如 24 卡做 TP8 加 PP3或者 TP24 的整体切分具体看模型结构和 SGLang 的支持情况。三机是一个性价比拐点这是我实测下来比较深的体会。这套部署涉及几个关键技术点。第一是 SGLang 作为推理框架它对 DeepSeek 系列模型的支持比较到位尤其是 MLA 注意力和 MoE 结构的处理。第二是 NCCL 做集合通信三机之间的 all-reduce、all-gather 全靠它。第三是 RoCE 网络DGX 之间用 RDMA over Converged Ethernet 互联绕开 TCP 协议栈把通信延迟压下来。这三个东西配合不好多机推理的性能会直接崩掉。适合谁来参考这篇内容。如果你手上正好有 DGX 集群或者在做类似规模的多机推理部署这篇能帮你少踩一些坑。如果你只是单机玩玩那可以先跳过但里面关于 SGLang 参数调优和 NCCL 排查的部分单机场景也有参考价值。下面我会从整体设计思路开始一步步拆到具体的配置和实操。2. 整体架构设计与方案选型思路2.1 为什么选 SGLang 而不是 vLLM这是很多人第一个会问的问题。vLLM 在单机场景下确实成熟PagedAttention 那套东西也很稳。但到了多机张量并行尤其是 DeepSeek 这种带 MLA 和 MoE 的模型SGLang 的优势就体现出来了。SGLang 的 RadixAttention 对前缀共享的处理更激进在多轮对话和 RAG 场景下缓存命中率更高。更关键的是SGLang 对 DeepSeek-V4.1-Flash 的 MLA 实现是原生支持的不需要你自己去改 attention 的 kernel。我对比过两者在三机场景下的表现。同样的硬件配置SGLang 在长上下文、高并发下的吞吐大概能高出百分之十五到二十首 token 延迟也更稳定。vLLM 不是不能跑但你需要花更多精力去调 tensor parallel 的切分策略而且 MoE 的 expert 分布处理上SGLang 的调度更细。所以这套方案我坚定选 SGLang。2.2 三机互联为什么必须上 RoCEDGX 之间如果走普通以太网 TCP多机 all-reduce 的延迟会高得离谱。张量并行每一层都要做集合通信通信延迟直接叠加到推理延迟上。RoCE 的价值在于它让网卡直接访问远端内存绕过内核协议栈单次通信的延迟能从几十微秒降到几微秒级别。三机场景下我建议用 RoCEv2配合 PFC 和 ECN 做无损网络。为什么强调无损。因为 RDMA 对丢包极其敏感一旦有丢包重传机制会导致性能断崖式下跌。PFC 做流控ECN 做拥塞标记两者配合才能保证在高负载下不丢包。这套配置在交换机侧和网卡侧都要做缺一不可。2.3 并行策略的切分逻辑三机 24 卡怎么切模型。DeepSeek-V4.1-Flash 的层数和注意力头数决定了切分方案。一般来说张量并行度 TP 取 8 或者 24流水线并行 PP 取 3 或者 1。如果 TP24那就是所有卡一起做张量并行通信量最大但单卡显存占用最低。如果 TP8、PP3每台机器内部做 TP8机器之间做 PP通信量小很多但会有流水线气泡。我的建议是优先考虑 TP8、PP3。原因是机器内部的 NVLink 带宽远高于机器间的 RoCE 带宽把通信密集的张量并行放在机内把通信稀疏的流水线并行放在机间这样整体通信开销最小。流水线气泡可以通过增加 micro-batch 来缓解对吞吐的影响可控。这个取舍逻辑是多机推理的核心想清楚这一点后面的配置就顺了。3. 环境准备与基础配置实操3.1 系统与驱动版本对齐三台机器的环境必须完全一致这是铁律。CUDA 版本、NCCL 版本、驱动版本、Python 环境任何一处不一致都可能导致通信失败或者性能异常。我建议用 NGC 的 PyTorch 容器作为基础镜像这样 CUDA 和 NCCL 都是配好的省去大量折腾。具体版本上CUDA 用 12.4 以上NCCL 用 2.20 以上驱动用 550 以上。NCCL 版本尤其重要新版本对 RoCE 的支持和拓扑探测更完善。装完之后用nvidia-smi和nvcc --version确认三台机器输出必须一致。# 确认驱动和 CUDA nvidia-smi nvcc --version # 确认 NCCL 版本 python -c import torch; print(torch.cuda.nccl.version())3.2 RoCE 网络配置要点网卡侧要确认 RoCE 模式开启MTU 设成 9000 做巨帧。PFC 的配置在交换机侧做但网卡侧要确认 trust mode 设成 dscp让优先级标记能正确传递。# 查看网卡 RoCE 状态 ibv_devinfo # 设置 MTU ip link set dev eth0 mtu 9000 # 确认 PFC 配置需要交换机配合 mlnx_qos -i eth0注意RoCE 配置最容易出问题的地方是 PFC 和 ECN 不匹配。交换机开了 PFC 但网卡没开或者 DSCP 优先级对不上都会导致性能异常。配完之后一定要用ib_send_bw做带宽测试确认能跑到线速。3.3 三机免密与主机名解析多机启动需要 SSH 免密SGLang 的多机模式会通过 SSH 在各节点间分发任务。同时要把三台机器的主机名和 IP 写进/etc/hosts避免用 IP 直连时出现解析问题。# 生成密钥并分发 ssh-keygen -t rsa ssh-copy-id node1 ssh-copy-id node2 ssh-copy-id node3 # /etc/hosts 示例 192.168.1.10 node1 192.168.1.11 node2 192.168.1.12 node3主机名解析这块我踩过坑。有一次用 IP 直连NCCL 的拓扑探测走了错误的网卡导致通信绕了一大圈。后来统一用主机名并且在 NCCL 环境变量里显式指定网卡问题才解决。4. SGLang 部署与核心参数调优4.1 安装与模型准备SGLang 的安装建议从源码装因为 DeepSeek-V4.1-Flash 的支持可能还在快速迭代pip 包的版本未必跟得上。从 GitHub 拉最新代码按官方文档编译安装。git clone https://github.com/sgl-project/sglang.git cd sglang pip install -e python[all]模型权重提前下载好放在共享存储或者每台机器本地都行。三台机器都要能访问到模型路径建议用 NFS 挂载统一路径避免路径不一致导致的加载失败。4.2 启动命令与并行参数三机启动的核心是--tp和--pp参数以及--dist-init-addr指定主节点。下面是一个参考启动命令。python -m sglang.launch_server \ --model-path /models/DeepSeek-V4.1-Flash \ --tp 8 \ --pp 3 \ --dist-init-addr node1:5000 \ --nnodes 3 \ --node-rank 0 \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction-static 0.85 \ --max-running-requests 256--mem-fraction-static这个参数很关键它控制静态分配的显存比例。设太高会 OOM设太低 KV Cache 空间不够吞吐上不去。0.85 是我在三机场景下试出来的比较稳的值具体还要看你的上下文长度和并发数。--max-running-requests控制同时处理的请求数这个值直接影响显存占用和吞吐。建议从 128 开始试逐步往上加观察显存和延迟变化。4.3 NCCL 环境变量调优NCCL 的环境变量对多机性能影响巨大。几个必须设的export NCCL_IB_DISABLE0 export NCCL_IB_GID_INDEX3 export NCCL_SOCKET_IFNAMEeth0 export NCCL_IB_HCAmlx5_0 export NCCL_NET_GDR_LEVEL5 export NCCL_ALGORing export NCCL_PROTOSimpleNCCL_IB_GID_INDEX这个值要看你 RoCE 的配置RoCEv2 一般是 3。设错了会直接连不上。NCCL_ALGO选 Ring 还是 Tree 要看消息大小小消息 Tree 更快大消息 Ring 更稳。三机场景下 Ring 通常表现更好。提示调 NCCL 的时候一定要开NCCL_DEBUGINFO看日志里实际用的网卡、协议和算法。很多时候你以为设对了实际 NCCL 选了别的路径性能差一大截。5. 实操过程与性能验证5.1 分步启动流程启动顺序很重要。先起主节点 node1等它初始化完成再起 node2 和 node3。如果同时起可能出现主节点还没准备好从节点连接超时的情况。具体步骤先在 node1 上执行启动命令观察日志出现server is ready之后再在 node2 和 node3 上执行对应 node-rank 的命令。三台机器的--dist-init-addr都指向 node1。启动过程中重点看几个日志点NCCL 初始化是否成功、模型加载是否完成、各 rank 是否都就绪。任何一个 rank 卡住整个服务都起不来。5.2 性能基准测试服务起来之后用 SGLang 自带的 benchmark 脚本压测。重点看三个指标首 token 延迟、输出吞吐、并发下的稳定性。python -m sglang.bench_serving \ --backend sglang \ --host node1 \ --port 30000 \ --num-prompts 500 \ --request-rate 20我实测下来三机 DGX 跑 DeepSeek-V4.1-Flash在输入 2K、输出 512 的场景下单请求首 token 延迟能控制在 300ms 以内吞吐能到每秒几千 token。具体数字取决于你的网络和参数配置。5.3 通信性能单独验证推理性能不达标的时候先别急着调模型参数先单独测 NCCL 的通信带宽。用 nccl-tests 跑 all-reduce看实际带宽能不能接近 RoCE 的线速。./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8如果 all-reduce 带宽只有理论值的一半那问题一定在网络或者 NCCL 配置上跟模型无关。这个排查思路能帮你快速定位问题边界。6. 常见问题与排查技巧实录6.1 启动阶段典型故障现象可能原因排查方向NCCL 初始化超时网卡名或 GID 配错检查 NCCL_SOCKET_IFNAME 和 GID_INDEX模型加载卡住权重路径不一致确认三机路径可访问rank 连接失败主机名解析问题检查 /etc/hosts 和防火墙显存 OOMmem-fraction 过高降低静态显存比例6.2 性能不达标的排查顺序性能问题排查要有顺序从底层往上查。先测网络带宽再测 NCCL 通信再看模型加载最后看推理参数。很多人一上来就调推理参数结果发现是网络没配好白折腾。我遇到过一次吞吐只有预期的一半。查了半天推理参数最后发现是 RoCE 的 PFC 没配对导致偶发丢包NCCL 一直在重传。把 PFC 配好之后性能直接翻倍。这个教训就是底层没通上层怎么调都是白费。6.3 长上下文场景的特殊处理DeepSeek-V4.1-Flash 支持很长的上下文但长上下文下 KV Cache 会吃很多显存。三机场景下如果并发数高KV Cache 可能把显存撑爆。解决办法是限制单请求的最大上下文长度或者用分页 KV Cache 的方式动态管理。SGLang 本身支持 KV Cache 的分页管理但需要你在启动参数里把--max-total-tokens设合理。这个值设太小会限制并发设太大又容易 OOM需要根据实际显存和请求特征来调。注意长上下文场景下建议把--max-running-requests调低给 KV Cache 留足空间。宁可少处理几个并发也不要因为 OOM 导致服务崩溃。6.4 独家避坑经验第一个坑是版本不一致。三台机器只要有一台的 NCCL 版本差一个小版本就可能出现通信异常。部署前一定要用脚本统一检查所有版本。第二个坑是网卡选择。DGX 通常有多张网卡NCCL 可能选错。一定要用NCCL_IB_HCA显式指定用于 RoCE 的那张卡别让它自己猜。第三个坑是温度。三机满载跑推理机房温度如果控制不好GPU 会降频性能直接掉。这个不是软件问题但很多人会忽略。部署前确认散热没问题。第四个坑是模型权重的完整性。下载过程中如果中断权重文件可能损坏加载时报奇怪的错。下载完用 md5 校验一遍能省很多排查时间。这套三机 DGX 部署 DeepSeek-V4.1-Flash 的方案核心就是把网络、通信、推理框架这三层都调通。任何一层有问题整体性能都上不去。我个人的体会是多机推理的难点不在模型本身而在基础设施的稳定性和一致性。把 RoCE 和 NCCL 这两块吃透剩下的就是参数微调的事了。后续如果要做更大规模的扩展这套思路同样适用只是并行策略和网络拓扑要重新设计。