最近有网友分享了一个有趣的实验：尝试用两台主机组合运行80B大模型，期望获得更快的推理速度，结果却事与愿违。

## 硬件配置与实验设置

- **台式机**：AMD Ryzen 7 7800X3D、32GB DDR5、RX 9060 XT 16GB VRAM

- **Jetson**：NVIDIA Jetson Orin AGX、64GB统一内存、Ampere架构

- **模型**：unsloth Qwen3 80B Q8（87GB）

模型大小超过单台设备的内存容量，但两台设备的总内存足够容纳整个模型。用户使用llama.cpp的多主机功能，通过1Gbps网络连接两台设备。

## 令人困惑的结果

多机推理时生成速度仅为1.1 token/秒，而仅使用台式机单机推理时速度达到2.2 token/秒——多机反而慢了一倍。

更奇怪的是，网络监控显示每个生成token都会引起16-24 MiB/s的网络流量峰值，这显然不正常。

## 问题出在哪里？

有经验的技术人员指出了几个关键问题：

**1. 层分配策略失误**

命令行中的`-ot ".ffn_.*_exps.=CPU"`选项将稀疏专家层分配给台式机CPU，而Qwen3-Next模型中95%的权重都是专家层。这意味着80GB的模型权重被塞进了32GB的系统内存，导致大量数据从SSD反复读取。

**2. 调试标志拖累性能**

Jetson端的`GGML_RPC_DEBUG=1`标志会导致大量日志数据输出，严重拖慢推理速度。这正是异常网络流量的罪魁祸首。

**3. 线程设置不当**

`--threads -1`的设置可能没有充分利用多核CPU的优势。对于需要CPU参与推理的场景，应该设置合适的线程数。

## 分布式推理的本质限制

llama.cpp目前只支持层分割（pipeline parallel），不支持张量并行（tensor parallel）。这意味着它主要解决大模型内存不足的问题，而不是提升推理速度。

网络延迟是关键瓶颈：即使1Gbps网络的带宽足够，但每次网络通信引入的毫秒级延迟会累积成显著的性能损失。有网友比喻这就像"每秒按10次暂停键"。

## 可行的解决方案

- 禁用调试标志：立即移除`GGML_RPC_DEBUG=1`

- 优化层分配：手动调整各层在设备间的分布，避免内存溢出到SSD

- 升级网络：考虑10GbE或InfiniBand等低延迟网络

- 考虑其他框架：vLLM支持张量并行，但对硬件一致性要求更高

这个案例提醒我们，分布式推理不是简单的硬件堆砌，需要深入理解框架特性和系统瓶颈。有时候，最简单的单机方案反而是最优解。