DGX Spark + Strix Halo 拆分推理实测

在本地运行大模型时，预填（prefill）和解码（decode）阶段对硬件的要求并不相同。一位长期在 Strix Halo（型号为 Bosgame M5）上做本地 Agent 编码的用户发现，统一内存虽然充裕、token 生成速度也够用，但预填性能在长上下文下急剧恶化，难以支撑 OpenCode 这类需要反复回读上下文的智能体工作流。

为缓解这一问题，他尝试将预填卸载到 NPU，结果不如 iGPU；随后入手了 NVIDIA DGX Spark，并借鉴此前 EXO 将 DGX 与 Mac 组合的思路，提出让 DGX 专门做预填、Strix Halo 专门做解码的分离式推理方案。作者借助 Claude Code 修改 llama.cpp 源码，花数小时跑通了基于 Qwen 3.5 122B（MTP）GGUF 的跨机 PP→TG 流水线。

解码性能：两机基本打平

在拆分之前需要先确认解码端是否合理。对比显示，DGX Spark 与 Strix Halo 在各上下文长度下的 token 生成速度差距仅 13%–15%，且几乎不随上下文变化。这是典型的内存带宽瓶颈——两台机器对该模型的有效带宽相当，DGX Spark 算力上的优势在解码阶段几乎被浪费。因此，把 DGX 算力投入到它真正擅长的预填阶段，是整个拆分方案成立的逻辑前提。

拆分推理核心结果

下表汇总了关键单请求基准数据（短上下文到 127k tokens）：

• 512 tokens：Strix 独立总耗时约 8100 ms，拆分后约 1999 ms，加速 4.1 倍。
• 2047 tokens：13098 ms → 3960 ms，3.3 倍。
• 7999 tokens：33220 ms → 11832 ms，2.8 倍。
• 15935 tokens：63137 ms → 22714 ms，2.8 倍。
• 63551 tokens：332168 ms → 94075 ms，3.5 倍。
• 127039 tokens：915995 ms → 210537 ms，4.4 倍。

Strix Halo 自身的预填速度从 275 t/s（512 tokens）一路下滑至 140 t/s（127k tokens），且上下文越长退化越严重，这正是长会话 Agent 难以忍受的故障模式。而 DGX Spark 的预填在同区间内几乎不受上下文长度影响。结果是：在 127k tokens 场景下，Strix Halo 单独完成全程需要约 916 秒，而拆分方案只需约 210 秒，已从「等一杯咖啡的时间」变成「可用」。

网络速度的影响

拆分并非零成本，KV cache 需要在两机之间搬运。Bosgame M5 配有 2× USB4 与 2.5GbE 网口，而 DGX Spark 仅提供 USB 3.2 Gen2、10GbE 以及面向 Spark 间互联的 ConnectX（约 200Gb 级别），无法与 AMD 设备直接走 USB4 协议。作者最终只能通过 2.5GbE 互联，也是上文所有数据的测试条件。

以 127k tokens 对应的 3129.2 MB KV cache 为例，不同链路下传输耗时与端到端总耗时如下：

• 2.5GbE（约 300 MB/s）：传输 10431 ms，总计 206523 ms。
• 10GbE（约 1.2 GB/s）：传输 2608 ms，总计 198700 ms。
• 20GbE（约 2.4 GB/s）：传输 1304 ms，总计 197396 ms。
• 40GbE / USB4 级（约 4.8 GB/s）：传输 652 ms，总计 196744 ms。
• 100GbE（约 12 GB/s）：传输 261 ms，总计 196353 ms。

20GbE 以上时，传输耗时几乎被淹没在 DGX 自身的计算时间里（DPX Spark 约 196 秒 + 解码约 8 秒）。也就是说，2.5GbE 已经足以让拆分方案物有所值，但若配齐更高速链路，长上下文下的收益还能进一步释放。

小结

对算力预算有限的本地 LLM 用户而言，这套实验传递了三个信号：第一，PP 与 TG 的硬件需求差异很大，混部并不一定最优；第二，NVIDIA 与 AMD 平台借助分离式推理可以互补——DGX 算力做预填、Strix Halo 的内存与带宽做解码；第三，跨机互联带宽是决定长上下文收益上限的关键变量，值得在搭建时优先规划。