Strix Halo ROCm + MTP 笔记 (2026年5月)

随着 MTP 合并到 llama.cpp 主线，我想尝试一些我想到的其他优化。最终测试了后端、MTP 并升级到 ROCm nightly 版本。变化如下： - ROCm 7.13 可在 gfx1151 上运行（7.2.2 能识别 GPU 但无法编译着色器） - MTP 于昨天（5月16日）合并到 llama.cpp 主线 - 我运行了 3 个模型 × 2 个后端 × 3 种提示长度 + 一个全上下文解码测试 重点：ROCm 在全上下文时下降 64%，但 MTP 恢复了大部分性能。Vulkan 几乎没有下降。 完整文章及所有表格：https://kmarble.dev/posts/strix-halo-full-context-decode-drops/ 但快速版本： 35B MoE 在全上下文时（76K 提示令牌，5K 输出）： - ROCm 非 MTP：16.6 tok/s（空上下文时为 46.2） - ROCm MTP：37.5 tok/s（空上下文时为 63.7） - Vulkan 非 MTP：28.9 tok/s（空上下文时为 32.7） - Vulkan MTP：34.3 tok/s（空上下文时为 46.8） 122B MoE： - Vulkan 非 MTP：23.7 tok/s（仅下降 12%） - ROCm MTP：19.2 tok/s（下降 38%） - Vulkan MTP：21.9 tok/s（下降 6%） 27B 密集模型（避免使用）：无论后端如何，全上下文时均为 6-9 tok/s。 见解： 1. 在空上下文中，ROCm 是 Vulkan 的 2.3 倍（46 vs 32 tok/s），但在全上下文中差距缩小到 1.3 倍（37.5 vs 28.9） 2. Vulkan 在全上下文中更稳定——仅下降 12%，而 ROCm 下降 64% 3. 在 122B Vulkan 上使用 MTP 实际上略有帮助（比非 MTP 下降 6%），而在 122B ROCm 上使用 MTP 则下降 38% 4. 密集模型 27B 不可用——比 35B MoE 慢 5 倍，因为它每个令牌处理 270 亿活跃参数，而 35B MoE 仅处理 30 亿 设置：ROCm 7.13，使用来自 kyuz0 工具箱的 therock-gfx1151 代码生成路径。Vulkan 1.3 RADV。llama.cpp b9188。所有都是实际的 llama-swap 代理测试，而非合成的 llama-bench 运行。 BF16 模型在 Strix Halo 上的全上下文中无法工作。35B 使用 Q8，122B 使用 Q4。 对于我的设置，ROCm MTP 在 35B MoE 上仍然是生产环境的选择：全上下文 37.5 tok/s，功耗低于 100W，可用 262K 上下文。 但如果你更关心质量而非速度，那么在 Vulkan 上运行 122B 以 23-24 tok/s 的速度也很有竞争力。