苹果英伟达组了台248GB显存的怪物，10G网线拖后腿了

把一台Mac Studio和一台NVIDIA DGX Spark用网线直连，能拼出一台248GB显存的分布式AI工作站。这个数字听着像科幻片道具——足够塞下100B参数的模型，还是带量化那种。

但问题很现实： heterogeneous GPU（异构图形处理器）+ 10GbE网络，这套组合真能跑起来吗？还是只是工程师的自嗨？

实测数据先摆出来。作者用CAT6A网线直连两台机器，测得吞吐量9.41 Gbps，接近理论上限。WiFi留给日常上网，这根线专门伺候模型推理。没有交换机，没有路由器，两根网线直接对插——这是局域网里能想到的最干净拓扑。

两套方案，两种命运

第一轮用的是Exo，一个支持MLX跨Metal和CUDA后端的分布式推理框架。作者成功让128GB的MiniMax M2.5模型横跨两台机器，却在启动环节卡死：mx.distributed.init(backend="ring")在CUDA后端上无限挂起。MLX 0.31.1版本的CUDA ring实现根本还没跑通，连单节点ring初始化都能在DGX上挂掉。

作者顺手修了选举不稳定、边缘震荡、模型路径匹配、Linux网卡检测等一堆bug，还提交了一个P2P模型分发PR。但核心路径被堵死了——得等苹果把CUDA ring支持补进MLX。

第二轮换llama.cpp的RPC后端。这条路更务实：不要求两端跑同样的ML框架，DGX只暴露原始算力，Mac Studio当大脑，按需把层卸载到远程节点。

启动命令行很朴素。DGX端跑rpc-server，Mac端跑llama-server带--rpc参数。模型文件只存在Mac上，llama.cpp自己决定怎么切分层、怎么分配显存。两台机器用同一份commit（b0f0dd3e5）编译，各自带自己的GPU后端。

速度拆解：预填充起飞，生成环节翻车

预填充（prefill）环节，RPC确实有用。DGX的Blackwell张量核心加速矩阵乘法，7B模型的预填充速度提升到4.2倍。72B大模型也有小幅增益——输入处理阶段，算力就是正义。

但token生成（decode）环节，网线成了瓶颈。每生成一个token，KV缓存状态要往返同步一次。10Gbps带宽下，每层增加约0.2ms延迟。72B模型80层，单token就要16ms网络开销——直接把生成速度砍半。

具体数字：72B模型本地跑11 tok/s，走RPC掉到6 tok/s。模型越小，RPC overhead占比越高，亏得越惨。

什么场景能回本？

这套配置的真正价值在"模型塞不下"的临界点。100B+参数、128GB量化模型，单台机器根本加载不了，RPC再慢也是唯一解。作者把它比作"用慢车运超大件"——慢，但能运。

另一个隐藏收益是内存带宽叠加。DGX Spark的Blackwell架构和Mac Studio的统一内存，两种内存子系统并行工作，某些层能吃到带宽红利。

但10GbE明显是短板。作者算过账：80层×0.2ms=16ms/token，这还只是单向。如果升级到25GbE或100GbE，网络开销能压到可忽略区间，RPC方案可能全面反超本地。

一个有趣的副产品：这套拓扑证明了异构GPU互联的可行性。苹果和英伟达从未官方支持这种玩法，但llama.cpp的RPC抽象层把差异抹平了。Metal和CUDA在后端各自干活，前端用户无感知。

作者最后提了个开放问题：如果苹果哪天把MLX的CUDA ring修好了，Exo的框架级优化能不能跑赢llama.cpp的通用RPC？现在没人知道答案，因为MLX的CUDA支持还停留在"能编译，跑不起来"的阶段。

那根9.41 Gbps的CAT6A网线，现在还插在桌底下。