Strix Halo + R9700 异构组合实测 Qwen3.5-122B 推理速度翻倍

一位 r/LocalLLaMA 社区用户在已有 Strix Halo 128GB Framework 桌面主板的基础上，外接一张 AMD R9700 Pro AI 显卡，组成了「CPU 统一内存 + 独显」的异构推理平台，并以 Qwen3.5-122B-A10B 这一 MoE 模型为对象做了一轮实测。结果显示，原本单独使用 Strix Halo 时约 24 tok/s 的生成速度，提升到了 49 tok/s；32K 上下文预填速度也从约 272 tok/s 提升到 682 tok/s，整体性能约翻倍。整套硬件投入约 5000 美元，作者表示其体验接近 DGX Spark，但拥有更大的可用内存（约 160GB）和一台常规 16 核 Ryzen PC 的形态。

核心思路：把模型按访问特性拆到两种显存里

Strix Halo 自带的统一内存容量大、带宽相对一般；R9700 显存约 32GB，但具备更高的计算和显存带宽。两者之间仅有一条 x4 PCIe 4.0 的窄链路。作者没有简单地「模型一半塞这里、一半塞那里」，而是按数据被访问的频率做了切分：

• MoE 路由专家（约 62GB）：只在处理特定 token 时被触发，每个 token 实际只读取其中约 2GB 数据，适合放在 Strix Halo 的大容量统一内存中。
• 稠密层（约 4GB）：每个 token 都要访问，对带宽敏感，部署在 R9700 上。
• KV 缓存：同样放在 R9700 的显存里。
• MTP 投机解码草稿模型：也放在 R9700，借助独显带宽加速草稿生成。

由于每个 token 在两个设备间仅需传输约 12KB 数据，x4 4.0 链路的带宽瓶颈并不显著，延迟才是关键。作者特别指出，这种场景下并不适合用张量并行（Tensor Parallelism），因为后者需要持续大量跨链路通信。

关键配置与性能数据

作者使用 llama.cpp 的 llama-server 启动模型，并借助自行修改的 llama 分支以及一个重新量化、嫁接了 MTP 头的 GGUF 模型。其简化后的启动配置大致如下：

• 模型：Qwen3.5-122B-A10B-Opus-Reasoning-Q4_K_XL.gguf，启用 MTP 草稿模型 mtp-draft-out-q4_K.gguf（投机解码类型 draft-mtp）。
• 设备：-dev ROCm0,ROCm1，草稿模型运行于 ROCm0。
• 上下文与批处理：-c 32768 -ub 4096 -b 4096。
• 卸载规则：使用 -ot 将第 14–49 层的 FFN 专家（ffn_gate/up/down_exps）显式分配到 ROCm1，并通过 -ngl 999 -fa on --no-mmap 控制加载方式。
• 投机解码参数：--spec-draft-n-max 4 --spec-draft-p-min 0.5。

在 Q4_K_XL 量化下，最终跑出 32K 上下文预填 682 tok/s、生成 49 tok/s 的成绩，相比单独使用 Strix Halo 的 24 tok/s、272 tok/s 预填分别提升约 2 倍和 2.5 倍。

软件层面的小幅优化

作者指出，最初的版本并未跑满两套设备的理论带宽，主要瓶颈来自 kernel launch 过多。为此他对 llama.cpp 做了一轮针对性改动，发布在 GitHub 仓库 sixvolts/llama-halo-hybrid；同时为支持 MTP 投机解码，他还在 Hugging Face 上放出了一份重新量化并嫁接 MTP 头的 SixVolts/Qwen3.5-122B-A10B-Opus-Reasoning-MTP-GGUF 版本，供同类硬件的用户参考。

讨论与延伸

作者认为，这种「统一内存 CPU + 独显」的异构配置并非一次性的实验，而是本地大模型推理未来可能持续存在的一种形态：当模型大到单卡装不下、又不必使用专业互联（如 NVLink）时，把稀疏访问的部分放到容量更大的设备上，把热数据放到带宽更高的设备上，可以取得比「硬塞单卡」更合理的平衡。

他也提到，发布当天 Alex Ziskind 也放出了一段基于 Oculink 外接 NVIDIA 显卡的类似尝试，但受限于 PCIe 带宽、跨厂商驱动以及只能走 Vulkan 的限制，体验和性价比都不及本次方案。同期发布的 Qwen 3.8 Flash-Next 则被作者列为下一步需要继续适配和调优的对象。