本地部署 LongCat-2.5，要 7 台机器我只有 4 台

本地部署 LongCat-2.5，要 7 台机器我只有 4 台

摘要：这台「四机集群」其实是一根环。

本文为本地实测记录，含完整命令与原始数据，可按步骤复现。

关键数据：加机器根本买不到带宽——4 台的 all-reduce 是 111.3 Gbps，2 台是 110.9 Gbps，1.004 倍。

今天凌晨我把四台 DGX Spark 之间的网线挨条测了一遍，测完发现一个事：这台「四机集群」其实是一根环。

加机器根本买不到带宽——4 台的 all-reduce 是 111.3 Gbps，2 台是 110.9 Gbps，1.004 倍。

而美团在 LongCat-2.5 的技术说明里，把万亿参数的秘诀写成「让参数与任务数据的主要通信在超节点内的高速互联网络中完成」。这句话我信，但我手上这四台不是超节点，是一根环。所以这篇写的是：当你的机器只有环，万亿模型到底还差多少。

① 先看清楚这四台是怎么连的

不看不知道。dgx1 上ip route里，10.10 段只有两条：

10.10.0.0/24 dev enp1s0f1np1 proto kernel scopelinksrc10.10.0.1010.10.3.0/24 dev enp1s0f0np0 proto kernel scopelinksrc10.10.3.11

只有两条。也就是说 dgx1 只跟 dgx2（走 10.10.0 段）和 dgx3（走 10.10.3 段）直连。四台之间的连接是这样：

dgx1 ──10.10.0/24── dgx2 │ │10.10.3/2410.10.1/24 │ │ dgx3 ──10.10.2/24── dgx4

一根环。四条边，没有交换机。

对角线呢？dgx1 到 dgx4 我直接试了：

$iproute get10.10.1.1110.10.1.11 via192.168.11.1 dev enP7s7 src192.168.11.111 $ping-c310.10.1.113packets transmitted,0received,100% packet loss

掉到 1G 管理网上去了，而且一个包都不通。dgx1 和 dgx4 之间，在 200G 这一层根本没有路。

更怪的是每台机器上有 4 个 200G 网口（/sys/class/net/*/speed全是 200000），ibv_devinfo里 4 个 RoCE HCA 全是PORT_ACTIVE，但只有 2 个配了 IP。另外两个enP2p1s0f0np0/enP2p1s0f1np1有物理层、有链路、没有地址——不知道原本打算接什么。

买机器的时候没人告诉我这件事。所以你下单前问自己一句：你买的那台「集群」，是一根环，还是一台交换机。

② 环上每条边，200G 只跑出一半

四条边我逐条测，8 条 TCP 并发：

平均 102.8 Gbps，达成率51.4%。

四条边的离散度很小（95.6 到 110.7），这个特征很重要：不是某台机器坏了、也不是某根线劣质，是整条链路的统一天花板。单台故障不会让四条边整整齐齐地都在一半上下。

再拆一层。同一条边上加并发流：

一条 TCP 只吃到 200G 的两成。四条流直接跳到 2.56 倍，八条流基本饱和。

这一条解释了我之前一直没想通的事：生产容器里为什么写死NCCL_MIN_NCHANNELS=4 / NCCL_MAX_NCHANNELS=4。不是调优参数，是不开多通道，200G 网卡等于 40G。

③ 加机器，带宽一点没多

这是今天最反常识的一组数。同一份 NCCL all-reduce，同一批机器，同样走 RoCE，只改世界大小：

256MB 这一档，4 机是 2 机的1.004 倍。

我把这张表看了两遍才接受。直觉里机器翻倍、聚合带宽应该跟着涨；环拓扑上不涨，因为 all-reduce 是串行的——每台机器要等前一跳的数据，四条边同时只有一条在传。加一台机器，只是让这个串行链条更长。

所以「加机器买不到带宽」这句话，在我这套拓扑上是字面成立的。加机器买到的只有显存。

小消息更值得看，因为 decode 阶段全是小消息：

4KB 一次要 31.5 微秒。一次 31.5 微秒听起来没多少，但 decode 是每个 token 都要走一遍的事，而且要走几十层。

④ rank 排错一位，四机直接起不来

今天最可复现的坑在这里。

按自然序排：dgx1=0、dgx2=1、dgx3=2、dgx4=3。启动，失败，报错原文：

Call to ibv_modify_qp failed with110Connection timed out, on dev rocep1s0f0:1,localGID index3,localGID ::ffff:10.10.3.11, remote GID ::ffff:10.10.1.11

我盯了很久才看懂。dgx3 和 dgx4 明明有直连（10.10.2 段），但报错里 NCCL 用的却是 dgx3 的 10.10.3.11 去连 dgx4 的 10.10.1.11——它挑了错的那张网卡。

dgx3 上没有 10.10.1.0/24 的路由，所以那个 QP 建不起来，超时 110。

报错里的两个 GID 已经把答案写全了：它试图跨越环的对角线。rank 顺序决定了 NCCL 认为谁是「邻居」，rank 2 和 rank 3 按算法是邻居，可物理上这两台的对角方向没有通路。

改成物理环序：dgx1=0、dgx2=1、dgx4=2、dgx3=3。一次通过，111.3 Gbps。

还有一个更阴的。rendezvous 地址我一开始写MASTER_ADDR=10.10.0.10（200G 段地址，看着最合理），结果卡 180 秒后报：

Timed out after181seconds waitingforclients.3/4 clients joined

因为 dgx3 和 dgx4 到不了 10.10.0 段。必须用管理网 192.168.11.111 做 rendezvous，200G 只跑数据面。

这两条都不在教程里。教程默认你有交换机、有全互联、有正经的 IP 规划；环拓扑上，rank 顺序就是拓扑顺序，控制面和数据面必须分网。

⑤ 那 1.6T 到底要几台

LongCat-2.5 是 2026-11-02 发布的，官方口径：总参 1.6T、每 token 激活 48B、专家权重和激活都量化到 4bit（W4A4）。

按 W4A4 每参数 0.5 字节粗算，权重约800 GB。

DGX Spark 每台可用 unified memory 121.7 GiB。800 ÷ 121.7 ≈6.6，向上取 7 台。

如果量化没到位，按我 11-01 实测的 GLM-5.2 那个比例（1506.69 GB / 744B = 2.03 字节每参数）反推，则要约 13 台。

我现在有 4 台。4 × 121.7 = 487 GiB。

800 GB 减去 487 GiB，差 313 GB。

这不是调参能解决的差距，也不是「再优化一下显存复用」能挤出来的差距。现在这套机器跑不了 LongCat-2.5，一台都起不来，差 313 GB 的物理显存。

而且就算补齐到 7 台，你面对的仍然是这根环——7 台串起来是更长的环，加机器还是买不到带宽。真想让它跑得像样，得先有超节点或交换机，那是另一笔钱，另一个数量级的钱。

⑥ 顺带测出来的一个反差

既然讲切分，就得回答「那能不能不切，直接从盘上流式读」。

我在 dgx1 上测了本机 NVMe 顺序读，4GB 文件iflag=direct：9.6 / 9.9 / 9.6 GB/s，三次都在这个量级。dgx2 同条件8.6 GB/s。

而环上单边 8 流 110.7 Gbps = 13.8 GB/s，那是收发两端合计，折成单向大约 6.9 GB/s。

本机盘 9.9 GB/s，跨机单向 6.9 GB/s。本地盘反而更快。

这个结论把「分布式」的账算穿了：在这套环拓扑上，多机拼显存的传输优势，还不如干脆从本地盘流式加载。切分要解决的是「单机装不下」，不是「网络比盘快」。

如果你的机器是交换机全互联、带宽真到 200G×N，这个结论会反过来；但在环上，它是这个方向。

⑦ 落到你身上

三段，对应三类人。

已经在跑多机推理的：先去看ip route，别去看商品页。如果 10.x 段只有两三条路由，你就是环。环上的第一件事是把 rank 顺序改成物理拓扑顺序，第二件事是把 rendezvous 放到管理网。这两件不做，机器再多也起不来——今天我就是被这一条卡住的。

正在评估要不要上多机的：算清楚你要装的模型多大。1.6T 这个量级，四台 DGX Spark 差 313 GB，跑不了。你要么补到 7 台（还得先解决环），要么把模型降到单机能装下的规模。单机能装下的（比如 14.8B 这个量级），切分是纯亏损——通信开销白付，一点收益没有。

用云端 API 的：这条对你是省钱的。你账单上跑的那个万亿模型，背后是超节点或交换机全互联，那笔硬件钱你按 token 在摊。自己凑一套环去追同样的模型，是花了钱还跑不动。判断标准很简单：你的模型装得进一台机器，就别碰多机；装不进，先算清楚差几台、再算清楚那几台之间怎么连。

⑧ 边界，写清楚

四件事。

第一，LongCat-2.5 的权重我没下。截至今天官方页面仍标「即将上线」，拿不到真实字节数。800 GB 是按 W4A4 每参数 0.5 字节推的，13 台是按 GLM-5.2 实测比例反推的——两个都是算得，不是量得。

第二，1M 上下文这个说法两个口径打架。新闻稿写 1M，官方文档写窗口 104K、单次输出上限 26.2K。本文按官方文档理解，但两个口径我都没能独立核实。

第三，TP4 的通信税 8.2% 是算得。我的算法是：hidden 5120、40 层、bf16，每层一次 10KB all-reduce，实测 36.4 μs，40 × 36.4 = 1.456 ms/token；生产 decode 实测 56.32 tok/s = 17.76 ms/token，占比 8.2%。这里假设了「每层正好一次 10KB all-reduce」，真实 sglang 可能合并或拆分，只能当量级参考。

第四，200G 只跑 51.4% 的成因我没定位到。可能是 RoCE 没调 PFC/ECN，可能 GPUDirect 没生效，可能单队列深度不够。我只测到了现象，没测到根因。

还有一条：MoE 的 EP 切分靠 all-to-all，而我只测了 dense all-reduce。EP 的通信开销完全没测，这是最大的空白。所以本文所有关于「切分代价」的判断，都只覆盖 dense 这一半。

参考来源

• 拓扑与带宽：4 台 DGX Spark（dgx1–4 / GB10）2026-11-03 00:00–00:26 实测。ip route/ip route get/ping/ibv_devinfo//sys/class/net/*/speed逐台采集；四条边各 8 条 TCP 并发打流
• NCCL：all-reduce busbw 2 机 / 4 机同配置对照，RoCE 走rocep1s0f0、rocep1s0f1，与生产容器NCCL_SWITCHLESS_RING_ONLY=1 / NCCL_ALGO=Ring一致；小消息延迟为 4 机 bf16 单次 all-reduce
• 生产服务指纹：dsv41-head容器（Up 38 小时），TP_SIZE=4 / EP_SIZE=4 / NNODES=4 / DIST_INIT_ADDR=192.168.11.111:20000，DeepSeek-V4.1-Flash 官方 config（40 层 / hidden 5120 / 384 routed experts 激活 6 + 1 shared /kv_source_layer_ids=[2,8,14,20]）
• 本机 NVMe：dgx1 与 dgx2 上 4GB 文件dd oflag=direct conv=fdatasync写、iflag=direct读，各 3 次
• LongCat-2.5：美团官方发布口径（总参 1.6T / 每 token 激活 48B / W4A4 / 2026-11-02），上下文窗口以官方文档 104K 为准
• GLM-5.2 权重体积 1506.69 GB：2026-11-01 经 hf-mirror 文件清单逐文件求和实测（295 个文件）
• 800 GB / 7 台 / 13 台 / 313 GB 四个数均为按官方参数量与实测字节比例的除法推算，非 profiler 实测

声明

本文所有带宽、延迟、磁盘数字均来自本机真机实测，测量条件、并发流数、文件尺寸已在文中标明。未测到的部分（LongCat-2.5 权重字节数、EP 的 all-to-all 开销、200G 只跑 51.4% 的根因、1M 上下文两个口径的核实）已在文中逐条写为未测或算得，未用估算值冒充实测。厂商口径与实测值全程分开表述，不混用。不同固件、不同拓扑、不同 NCCL 版本下具体数值会有差异，判断方法不变。

原创声明：本文为本人原创实测记录，转载请注明出处与作者（丘山录）。

复现说明：文中脚本与原始数据留在本机，参数不同结论会变，请自行复测。