双 Jetson AGX Thor 四路 10GbE 直连实测：为什么总带宽只有 12 Gbps？
两台 Jetson AGX Thor 都提供了多路高速以太网接口。只看接口数量，很容易得出一个诱人的估算：4 路 10GbE 直连，理论总带宽应该接近 40 Gbps。
但在真实测试中，我们得到的结果是：每一条链路单独跑都能接近 10 Gbps，多条链路同时跑时，总吞吐却在约 12 Gbps 封顶。
这篇文章记录测试方法、原始结果，以及这个带宽上限对双机大模型推理到底意味着什么。
快速结论
| 问题 | 实测结论 |
|---|---|
| 单条 10GbE 链路正常吗？ | 正常，四条链路分别达到 8.98–9.75 Gbps |
| 单链路多流能否突破 10 Gbps？ | 不能，iperf3 -P 4 合计约 9.85 Gbps |
| 两条链路能否叠加？ | 能，但合计只到 12.18 Gbps |
| 四条链路能否接近 40 Gbps？ | 不能，合计约 11.88 Gbps |
| 是 CPU 跑满导致的吗？ | 测试期间 CPU 仍有约 76% 空闲，不像是 CPU 上限 |
| 12 Gbps 对层切分够用吗？ | 对只传小型隐藏状态的方案通常足够 |
| 对 KV Cache 传输够用吗？ | 取决于模型和上下文；本文案例中网络不是主要矛盾 |
测试拓扑
测试使用两台 Jetson AGX Thor，四组 MGBE 接口逐一网线直连。为避免公开实验室内部主机和完整地址，下面只保留接口与子网结构：
| 节点 A 接口 | 节点 B 地址 | 用途 |
|---|---|---|
mgbe0_0 | 192.168.100.2 | 链路 0 |
mgbe1_0 | 192.168.101.2 | 链路 1 |
mgbe2_0 | 192.168.102.2 | 链路 2 |
mgbe3_0 | 192.168.103.2 | 链路 3 |
测试工具为 iperf3，每轮持续约 8–12 秒。先逐条测试，再启动多个服务端口并行压测，观察多链路合计吞吐。
第一轮：逐条测试四个 10GbE 接口
单链路结果如下：
| 接口 | 吞吐 |
|---|---|
mgbe0_0 | 9.75 Gbps |
mgbe1_0 | 8.98 Gbps |
mgbe2_0 | 9.49 Gbps |
mgbe3_0 | 9.69 Gbps |
这个结果说明，四组接口和直连网络本身都能工作。考虑以太网、TCP/IP 协议开销，单链路接近 9–10 Gbps 属于合理表现。
最低的一条为 8.98 Gbps，但它并没有低到足以解释后面的多链路总吞吐上限。
第二轮：单链路增加并发流
随后在一条链路上使用：
iperf3 -c 192.168.100.2 -P 4
四条 TCP 流的合计吞吐约为 9.85 Gbps。
这说明单连接调度不是主要问题。增加 TCP 并发流可以更充分地利用一条 10GbE 链路，但不会让单个物理接口越过其线速上限。
第三轮：两条和四条链路并发
真正值得关注的是多接口同时传输的结果：
| 配置 | 各链路吞吐 | 合计吞吐 |
|---|---|---|
2 条并发：mgbe0_0 + mgbe2_0 | 6.25 / 5.93 Gbps | 12.18 Gbps |
| 4 条并发 | 3.39 / 1.67 / 3.40 / 3.42 Gbps | 11.88 Gbps |
从一条增加到两条，合计吞吐确实从约 9.8 Gbps 提升到约 12.2 Gbps；继续增加到四条，不仅没有继续增长，反而略微下降。
所以这套配置的实际结论不是“4 × 10 Gbps = 40 Gbps”，而是：
四个接口各自都可以接近 10 Gbps，但同时使用时共享了某个约 12 Gbps 的系统级瓶颈。
瓶颈可能在哪里？
测试过程中 CPU 约有 76% 空闲，因此当前证据不支持“CPU 已跑满”这个解释。四个接口单独测试也都正常，因此单个网口或单根网线同样不像根因。
更合理的推断是：多个 MGBE 接口在 SoC 内部共享了 DMA、内存或 I/O 数据通路，多链路并发时触碰了共同上限。但必须强调，这仍是根据吞吐形态做出的工程推断，不是通过 NVIDIA 内部互联计数器完成的硬件级归因。
如果要进一步定位，可以补充以下测试：
- 同时记录 EMC、MGBE、CPU 和 SoC 频率，排除功耗模式或时钟限制；
- 分别测试单向与双向流量，观察收发路径是否共享上限；
- 改变 MTU、TCP 窗口和 CPU 亲和性，确认协议栈与中断分配的影响；
- 使用设备侧性能计数器或 NVIDIA 分析工具检查内存与 I/O 压力；
- 在不同 JetPack、内核和功耗模式下复测。
在完成这些验证之前，我们可以确定“多链路没有线性叠加”，但不应把具体内部部件写成已经证实的故障点。
对双机 LLM 推理有什么影响？
12 Gbps 换算后约为 1.5 GB/s 的理论字节吞吐。它远低于四路 10GbE 的表面总和，但是否构成问题，取决于双机之间到底传什么。
1. 层切分：通常不是网络瓶颈
如果两台设备按模型层进行切分，跨机传递的是某一层的隐藏状态，而不是每生成一个 token 都搬运整套权重。
在我们已验证的一条 8-bit 隐状态路径中，跨机数据量约为 7 KB/token。即使考虑协议开销，12 Gbps 对这种数据规模也非常宽裕。此时更值得关注的是：
- 每个 token 的同步延迟；
- 两端算力是否均衡；
- 通信与计算能否重叠；
- 推理框架是否为这种切分方式做过优化。
换句话说，层切分场景不应该只看峰值带宽。
2. Prefill/Decode 分离：先算 KV Cache 体积
Prefill/Decode 分离会把预填充阶段产生的 KV Cache 发送到解码节点。这里网络需求更大，但仍然应该先计算真实传输量，而不是看到“分布式推理”就默认必须使用 100GbE。
以我们测试过的一个压缩 KV 模型为例，32K 上下文对应的 KV Cache 约为 0.78 GiB。若有效传输速度按 1.5 GB/s 粗略估算，纯数据搬运约需：
0.78 GiB ÷ 1.5 GB/s ≈ 0.5–0.6 秒
而该上下文的 prefill 约需 80 秒。即使不做流水化，网络传输所占比例也不到 1%。这个案例里，PD 分离不一定值得做，但原因不是 12 Gbps 太慢，而是它未必能改善真正限制吞吐的解码阶段。
这个结论不能直接套到所有模型。标准多头注意力、大 batch、更长上下文或未压缩 KV Cache 都可能显著增加传输量。部署前至少要测三个数字：KV Cache 字节数、真实有效带宽、prefill 与 decode 各自耗时。
多网卡框架配置能绕过上限吗？
如果瓶颈发生在路由或单接口选择上，UCX multi-rail、NCCL 多网卡或 NIXL 多 NIC 配置可能带来提升。
但本次测试中，多个独立 iperf3 进程已经分别绑定不同物理接口和子网，合计吞吐仍停在约 12 Gbps。因此，仅在应用层启用更多 rail，大概率无法自动突破同一个底层共享通路。
这些框架仍然有价值：它们可以改善接口选择、并发调度、容错和通信重叠。只是不能把“识别到四张网卡”等同于“必然得到四倍吞吐”。
部署建议
如果你也在两台 Jetson AGX Thor 之间做分布式推理，建议按下面的顺序验证：
- 逐接口测单链路，确认每条链路、网线和地址配置正常；
- 在单链路上用
-P 4测多流，排除单 TCP 流限制； - 使用独立子网和端口做多接口并发测试；
- 记录 CPU 空闲率、功耗模式、温度和时钟；
- 用模型真实张量大小计算通信需求；
- 最后再决定是否引入 UCX、NCCL、NIXL 或更复杂的调度层。
不要用网口数量代替实测，也不要只根据 iperf3 峰值判断分布式推理一定可行或不可行。网络带宽、同步延迟、张量体积和两端计算时间必须放在同一张账上计算。
总结
本次双 Thor 直连测试得到三个清晰结果：
- 四条 10GbE 链路单独使用时均接近线速；
- 两条或四条并发时，总吞吐约在 12 Gbps 封顶；
- 对小型隐藏状态传输以及本文的压缩 KV Cache 案例，这一带宽仍然够用。
真正重要的不是“40 Gbps 为什么没跑出来”这一项数字，而是系统设计方式：如果跨机传输量本来就小，继续堆网卡没有意义；如果通信量巨大，也应先证明瓶颈确实在网络，再投入更昂贵的互联方案。