I Plugged a DGX Spark and Mac Together... and Didn’t Expect This

网络瓶颈与硬件升级实验

在初步测试中，作者发现将KV缓存从GB10传输到Mac Mini时，25,000个token的计算耗时不到1秒，但通过2.5 GB USB以太网适配器传输却耗时25秒。这意味着96%的总时间都消耗在网络传输上，GPU处于空闲等待状态。为了更准确地评估解耦架构（Disaggregated）的优势，作者意识到需要两个关键条件：更快的网络和非思维链模型（Non-thinking model）。此前使用Qwen 3.5等思维模型时，隐藏推理token的生成速度在所有平台上几乎相同，掩盖了预填充（Prefill）阶段的差异。

为此，作者购买了一个Thunderbolt 5外部 enclosure，试图安装Intel 810网卡（100G QSFP双端口），但Mac OS提示缺少驱动，实验失败。随后，他改用之前用于框架集群的Mellanox Connect X4网卡（50G QSFP端口），Mac OS立即识别并加载了内置驱动。连接端使用了Microchip CSR 812交换机，经过调试建立链路后，KV缓存传输速度提升了约30%。作者推测，若能解决100G网卡的驱动问题，速度还会更快。

解耦架构性能基准测试

在硬件升级后，作者选用Llama 3.1 8B模型（非思维链、稠密模型）和Llama Ben工具进行HTTP API层面的基准测试。测试对比了三种配置：GB10单独运行（BF16）、Mac Mini单独运行（4bit）以及GB10预填充+Mac Mini解码的解耦模式。测试结果显示，GB10在2048和4096 token的提示处理长度下，吞吐量接近1,800 tokens/秒，而Mac Mini的预填充速度较低，但其解码速度显著更快。解耦模式在4096 token输入下，首字生成时间（TTFT）约为2.4秒，与GB10单独的2.3秒几乎持平，证明50G链路带来的开销几乎可以忽略不计。

然而，诚实的数据揭示了局限性：解耦模式的解码速度为34 tokens/秒，低于Mac Mini单独的52 tokens/秒，这归因于远程KV缓存注入的开销。作者指出，单张RTX Pro 6000工作站显卡凭借6倍的内存带宽和3.5倍的算力，可能在两项指标上都优于双机解耦方案。但核心变量在于内存带宽：Mac Mini M4 Pro的内存带宽为273 GB/s，而Mac Studio M3 Ultra高达819 GB/s，是前者的三倍。

Mac Studio M3 Ultra 最终验证

作者将Mac Mini替换为Mac Studio M3 Ultra（512GB统一内存），保持相同的网络架构（Connect X4/X7网卡和交换机）和Llama 3.1 8B模型进行对比。尽管Mac Studio的内存带宽是Mac Mini的三倍，但在Batch Size为1时并未完全饱和，解码速度从52 tokens/秒提升至106 tokens/秒，约为前者的两倍。在预填充阶段，Spark单独运行达到1,585 tokens/秒，Mac Studio单独运行达到1,420 tokens/秒，解耦模式下的预填充速度为1,584 tokens/秒，与Spark单独运行几乎一致，链路开销仅约18毫秒。

最终的解码数据表明，解耦模式下的解码速度为84 tokens/秒，虽低于Mac Studio单独的106 tokens/秒（因KV缓存注入开销），但仍是Spark单独运行（14 tokens/秒）的六倍。结合Spark极高的预填充速度（1,700+ tokens/秒）和Mac Studio强大的解码能力，这种组合展现出实际构建的价值。

70B模型量化困境与备选方案

在尝试将Llama 3.1 70B模型部署到DGX Spark上时，遇到了严重的量化兼容性问题。由于完整精度的70B模型需要140GB显存，而Spark仅有128GB，必须使用量化版本。然而，作者尝试的FP8、AWQ（int4）、W4A16以及GPTQ Marlin等量化格式均告失败。根本原因在于VLM wheel for Spark仅支持BF16和FB16内核，缺乏针对SM121架构的量化内核支持，重新编译源码成本过高。因此，测试转向了32B和27B量级的模型，这些模型在BF16精度下可舒适运行于Spark，同时在Mac Studio上使用4bit MLX量化版本进行对比。

预填充阶段：Spark优势随模型增大而显著

在预填充（Prefill）阶段，DGX Spark展现出随模型规模增大而提升的性能优势。对于32B的Qwen 2.5模型，Spark以875 tokens/s的速度领先，远超Mac Studio的356 tokens/s，DAG（分布式）模式达到792 tokens/s，约为Mac Studio的两倍以上。对于27B的Gemma模型，Spark预填充速度为779 tokens/s，Mac Studio为379 tokens/s，DAG为722 tokens/s。数据表明，DAG的首个Token生成时间（TTFT）始终与Spark的单卡预填充时间一致，且随着模型从8B增至27B/32B，Spark在预填充上的优势从微弱领先扩大至2到2.5倍。这说明在较大模型规模下，分布式预填充的价值更加凸显，因为Spark的预填充速度远超Mac Studio。

解码阶段：带宽瓶颈解除与性能差距缩小

解码（Decode）阶段的表现与预填充截然不同。在8B模型中，Mac Studio凭借带宽优势以8倍于Spark的速度领先，但在27B和32B模型中，这一差距急剧缩小至1.25到1.3倍。对于Qwen 32B，Mac Studio解码速度为29 tokens/s，Spark为23 tokens/s；对于Gemma 27B，Mac Studio为30 tokens/s，Spark为24 tokens/s。作者指出，DAG的解码速度损失约20%用于KV Cache注入开销，这解释了为何DAG数据接近Spark单卡数据。性能变化的原因在于：对于Gemma，滑动窗口注意力限制了KV Cache读取量；对于Qwen，VLM内核融合大幅降低了带宽需求。随着模型变大，Spark的解码效率相对提升，Mac Studio的带宽优势不再主导局面。

综合性能对比与硬件建议

综合三个不同架构和规模的模型测试，结果呈现出清晰的规律：预填充阶段Spark主导，解码阶段Mac Studio优势随模型增大而减弱。以下是关键性能数据汇总：

"Two machines doing what they're good at. Talking over a 50 gig link and spitting out tokens faster than either one could alone. That's the whole pitch and it finally delivers."

尽管异构推理概念验证成功，但作者认为对于新购机用户，DGX Spark和Mac Studio的组合性价比不高。鉴于两者价格昂贵，更推荐购买RTX Pro 6000构建专用工作站，以获得更强的整体性能。