本地部署 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 段只有两条：
bash
10.10.0.0/24 dev enp1s0f1np1 proto kernel scope link src 10.10.0.10
10.10.3.0/24 dev enp1s0f0np0 proto kernel scope link src 10.10.3.11只有两条。也就是说 dgx1 只跟 dgx2（走 10.10.0 段）和 dgx3（走 10.10.3 段）直连。四台之间的连接是这样：
bash
dgx1 ──10.10.0/24── dgx2
│ │
10.10.3/24 10.10.1/24
│ │
dgx3 ──10.10.2/24── dgx4一根环。四条边，没有交换机。
对角线呢？dgx1 到 dgx4 我直接试了：
bash
$ ip route get 10.10.1.11
10.10.1.11 via 192.168.11.1 dev enP7s7 src 192.168.11.111
$ ping -c 3 10.10.1.11
3 packets transmitted, 0 received, 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 并发：
| 边 | 实测带宽 | 对 200G 标称 |
|---|---|---|
| dgx1 → dgx2 | 105.2 Gbps | 52.6% |
| dgx2 → dgx4 | 95.6 Gbps | 47.8% |
| dgx4 → dgx3 | 99.9 Gbps | 50.0% |
| dgx3 → dgx1 | 110.7 Gbps | 55.4% |
平均 102.8 Gbps，达成率 51.4%。
四条边的离散度很小（95.6 到 110.7），这个特征很重要：不是某台机器坏了、也不是某根线劣质，是整条链路的统一天花板。 单台故障不会让四条边整整齐齐地都在一半上下。
再拆一层。同一条边上加并发流：
| 并发流数 | 吞吐 | 相对单流 |
|---|---|---|
| 1 条 | 40.0 Gbps | 1.00× |
| 4 条 | 102.3 Gbps | 2.56× |
| 8 条 | 110.9 Gbps | 2.77× |
一条 TCP 只吃到 200G 的两成。 四条流直接跳到 2.56 倍，八条流基本饱和。
这一条解释了我之前一直没想通的事：生产容器里为什么写死 NCCL_MIN_NCHANNELS=4 / NCCL_MAX_NCHANNELS=4。不是调优参数，是不开多通道，200G 网卡等于 40G。
③ 加机器，带宽一点没多
这是今天最反常识的一组数。同一份 NCCL all-reduce，同一批机器，同样走 RoCE，只改世界大小：
| 消息大小 | 2 机 busbw | 4 机 busbw |
|---|---|---|
| 1 MB | 72.9 Gbps | 73.4 Gbps |
| 8 MB | 103.6 Gbps | 105.9 Gbps |
| 64 MB | 109.6 Gbps | 110.4 Gbps |
| 256 MB | 110.9 Gbps | 111.3 Gbps |
256MB 这一档，4 机是 2 机的 1.004 倍。
我把这张表看了两遍才接受。直觉里机器翻倍、聚合带宽应该跟着涨；环拓扑上不涨，因为 all-reduce 是串行的------每台机器要等前一跳的数据，四条边同时只有一条在传。加一台机器，只是让这个串行链条更长。
所以「加机器买不到带宽」这句话，在我这套拓扑上是字面成立的。 加机器买到的只有显存。
小消息更值得看，因为 decode 阶段全是小消息：
| 消息 | 单次 all-reduce |
|---|---|
| 4 KB | 31.5 μs |
| 10 KB | 36.4 μs |
| 20 KB | 41.1 μs |
| 40 KB | 43.6 μs |
4KB 一次要 31.5 微秒。一次 31.5 微秒听起来没多少，但 decode 是每个 token 都要走一遍的事，而且要走几十层。
④ rank 排错一位，四机直接起不来
今天最可复现的坑在这里。
按自然序排：dgx1=0、dgx2=1、dgx3=2、dgx4=3。启动，失败，报错原文：
bash
Call to ibv_modify_qp failed with 110 Connection timed out, on dev rocep1s0f0:1,
local GID index 3, local GID ::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 秒后报：
bash
Timed out after 181 seconds waiting for clients. 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 版本下具体数值会有差异，判断方法不变。
本文所有数字均为本机实测，非引用。环境与脚本版本见文末参考来源。 作者：丘山录 · 记录本地部署与算力实测