在 NVIDIA Blackwell 与 Apple Silicon 上通过 10GbE 实现分布式 LLM 推理

在追求极致的显存（VRAM）容量时，开发者往往面临两难选择：是投资昂贵且难以维护的企业级集群，还是寻找创意方案来桥接异构硬件？本文将带你深入了解一种极客式的混合架构方案：将拥有顶级算力的 NVIDIA DGX Spark（基于 GB10 Blackwell 架构）与拥有高效统一内存的 Apple Mac Studio M2 Ultra 结合。通过一根简单的 10GbE（万兆以太网）直连线，我们成功解锁了 248 GB 的 GPU 可访问显存，从而能够运行超过 2000 亿参数的超大规模模型，而这类模型在任何单台机器上都无法独立运行。

虽然很多开发者会优先选择 n1n.ai 提供的云端 API 来获取即时的 LLM 算力，但构建本地分布式推理阵列能让我们更深刻地理解现代 AI 网络中的性能瓶颈。本文将详细记录我们的实现过程、在 Exo 框架上遭遇的失败，以及使用 llama.cpp RPC 后端取得的最终成功。

硬件配置：异构双雄

我们的测试环境由两台在计算领域各具特色的机器组成：

1. NVIDIA DGX Spark: 搭载 GB10 Blackwell GPU，拥有 120 GB 统一显存。它利用最先进的 Tensor Core 和 CUDA 13 驱动，在矩阵乘法运算中拥有恐怖的吞吐量。
2. Mac Studio (M2 Ultra): 配备 128 GB 统一内存。虽然其原始 TFLOPS 略逊于 Blackwell，但其极高的内存带宽和针对 Metal 的深度优化使其成为理想的推理节点。

总显存容量达到了 248 GB。对于像 DeepSeek-R1、Qwen3-235B 或 MiniMax M2.5 这样的大模型，这种容量至关重要。如果你不想折腾复杂的硬件维护，n1n.ai 是一个极佳的选择，它通过聚合 API 让你轻松调用这些顶级模型。

网络连接：10GbE 直连的艺术

为了尽可能降低延迟，我们放弃了网络交换机，直接使用一根 CAT6A 网线将两台机器相连：

• DGX IP: 192.168.100.2/24 (Realtek 10GbE 网卡)
• Mac Studio IP: 192.168.100.1/24 (原生 10GbE 端口)

实测吞吐量达到 9.41 Gbps。在分布式推理中，网络不仅仅是数据传输的通道，它实际上充当了模型 KV 缓存和权重同步的“背板”。对于跨越 80 多个层的大型模型，每一微秒的抖动都会被放大。

软件探索：Exo 的困境与 MLX 的壁垒

最初，我们尝试使用 Exo。这是一个旨在同时支持 Metal 和 CUDA 后端的分布式推理框架。Exo 的愿景很美好：自动发现节点并划分模型。然而，在实际操作中，我们撞上了“南墙”：截至 MLX 0.31.1 版本，mx.distributed.init(backend="ring") 在 CUDA 环境下会无限期挂起。

尽管我们提交了多个 PR 来修复边缘振荡和 Linux 接口检测问题，但核心的分布式路径依然不通。这再次证明，虽然 n1n.ai 等平台提供的商业级服务非常稳定，但在异构分布式计算的 DIY 领域，软件兼容性依然处于“蛮荒时代”。

最终方案：llama.cpp RPC 后端

llama.cpp 通过其 RPC (远程过程调用) 后端提供了一种更稳健的路径。它不需要所有节点运行相同的 ML 框架，而是允许一台机器作为主控（Host），将特定的计算层卸载（Offload）到远程 RPC 服务器上。

1. 环境构建

两端必须使用完全相同的代码提交版本（Commit）进行编译，以确保协议一致。

在 DGX (Linux/CUDA) 上：

# 编译并开启 CUDA 和 RPC 支持
cmake -B build -DGGML_CUDA=ON -DGGML_RPC=ON
cmake --build build --config Release

# 启动 RPC 服务端
LD_LIBRARY_PATH=build/bin build/bin/rpc-server -H 192.168.100.2 -p 50052

在 Mac Studio (macOS/Metal) 上：

# 编译并开启 Metal 和 RPC 支持
cmake -B build -DGGML_METAL=ON -DGGML_RPC=ON
cmake --build build --config Release

# 启动 llama-server 并将层卸载到 DGX
build/bin/llama-server \
  -m /models/minimax-m2.5-q4_k_m.gguf \
  --rpc 192.168.100.2:50052 \
  -ngl 99 \
  --host 0.0.0.0 --port 9999 \
  -c 4096

性能数据分析

我们对比了 Llama 3 8B 和 70B 模型在本地运行与 RPC 模式下的表现：

Prefill (预填充) 的巨大优势

Prompt 处理是高度并行的。DGX Blackwell 的 Tensor Core 极大地加速了输入 Token 的矩阵乘法运算。在 8B 模型上，RPC 模式带来了 4.2 倍的提速。即使是 70B 模型，性能也有所提升，尽管此时 10GbE 的带宽开始成为限制因素。

Decode (解码) 的性能损失

Token 生成是一个串行过程。每生成一个 Token，都需要在网络上进行一次往返，以同步 KV 缓存状态。在 10 Gbps 的带宽下，每一层大约会增加 0.2ms 的延迟。对于像 70B 这样拥有 80 层的模型，网络开销高达 16ms/token，这直接导致生成速度减半。

分布式推理的价值所在

如果模型能塞进单台机器的显存，本地运行永远是首选。网络协议栈带来的开销远超额外 GPU 带来的算力提升。然而，分布式推理的真正价值在于运行那些“单机无法承受之重”。

凭借 248 GB 的显存池，我们可以运行：

• MiniMax M2.5 Q4_K_M (138 GB): 230B 参数的 MoE 模型。
• Qwen3-235B Q4_K_M (132 GB): 拥有 22B 激活参数的巨型模型。
• DeepSeek-R1: 能够以更高的量化精度运行复杂推理任务。

在 Q4 量化下，200B+ 的 MoE 模型可以达到 4–8 tokens/s 的速度。虽然不适合实时对话，但对于代码审查、复杂文档分析或长文本推理来说，这已经非常实用了。相比之下，如果您需要更快的响应速度，n1n.ai 提供的企业级 API 加速服务将是更高效的选择。

专家建议：避坑指南

1. GGUF 格式的一致性: 并非所有 GGUF 都是标准化的。Ollama 生成的 GGUF 往往包含一些 llama.cpp 无法识别的元数据（如 rope.dimension_sections 数组长度错误）。建议直接从 Hugging Face 上的 bartowski 等知名贡献者处下载模型。
2. 解耦架构的未来: 实验结果表明，未来的最佳实践可能是“解耦式”的：使用 Blackwell 等高算力节点负责 Prefill 阶段，使用 Apple Silicon 等高带宽节点负责 Decode 阶段。这种异构协同将最大化各平台的长处。
3. 网络优化: 务必在两端开启“巨型帧”（Jumbo Frames，MTU=9000），这能显著减少处理网络包的 CPU 开销。

总结

将 NVIDIA Blackwell 与 Apple Silicon 结合不再是科幻，而是一个可落地的工程方案。虽然像 Exo 这样的原生分布式框架仍在磨合期，但 llama.cpp RPC 已经为我们打开了大门。

如果你不想处理复杂的网络配置和硬件调试，n1n.ai 提供了最便捷的路径，让你一键接入全球最顶尖的 LLM 算力，无需担心万兆网线的延迟问题。

立即在 n1n.ai 获取免费 API 密钥。