AMD Strix Halo 上的 DFlash + PFlash

我们刚刚发布了针对 AMD Ryzen AI MAX+ 395 iGPU（gfx1151, Strix Halo, 128 GiB 统一内存）的 DFlash 和 PFlash 支持。

在 Qwen3.6-27B Q4_K_M 模型上，配合 Luce DFlash 草稿模型（drafter），端到端测试结果为：解码速度 26.85 tok/s，在 16K 上下文长度下的 PFlash 预填充时间为 20.2 秒。这比同硬件上 llama.cpp HIP 的解码速度快 2.23 倍，预填充速度快 3.05 倍。

同一台机器可以承载高达约 100 GiB 的模型检查点，这是拥有 24 GiB 显存的消费级 GPU 无法触及的一类模型。

GIF

摘要

• PR #119 将 lucebox 第二阶段 rocWMMA flashprefill 内核移植到了 HIP。DFlash 草稿器、DDTree 验证器、推测性预填充压缩以及稀疏目标预填充现在都直接在 gfx1151 iGPU 上运行。配套的 PR #159 将压缩预填充的 ubatch 默认值从 16 提升到了 512。

• 解码 (Qwen3.6-27B Q4_K_M)：使用我们的 Q8_0 GGUF DFlash 草稿器和 SWA=2048，速度达到 26.85 tok/s。比 llama.cpp HIP AR（12.02）快 2.23 倍，比 llama.cpp Vulkan AR（12.45）快 2.16 倍。

• 预填充 (Qwen3.6-27B, 16K)：TTFT（首字生成时间）为 20.2 秒，而 llama.cpp HIP 为 61.69 秒。NIAH（大海捞针）检索测试通过。随着上下文增加，加速效果更明显：PFlash 压缩是 O(S)，而 AR 预填充是 O(S^2)。

• 端到端：在 16K 提示词 + 1K 生成的工作负载下，总实际耗时从 147 秒降至 58 秒。快了 2.5 倍。

• 调优：--ddtree-budget=22 是 gfx1151 的最佳预算值。更高的预算虽然每步接受更多 token（接受率 AL 持续上升），但每一步在 LPDDR5X 上的开销更大。带宽限制了收益，因为在此之前 tile 利用率尚未发挥优势。

• 下一步：BSA 评分内核需要原生 rocWMMA 移植（目前仅支持 CUDA/CUTLASS）。填补这一差距预计能在长上下文预填充上再带来 2-3 倍的加速。

数据详情

硬件：Ryzen AI MAX+ 395，Radeon 8060S iGPU (gfx1151)，128 GiB LPDDR5X-8000，ROCm 7.2.2。目标模型：Qwen3.6-27B Q4_K_M (15.65 GiB)。草稿模型：Lucebox/Qwen3.6-27B-DFlash-GGUF Q8_0 + DFLASH27B_DRAFT_SWA=2048。基准测试：10 个 HumanEval 风格的提示词，参数 --n-gen 128 --ddtree-budget 22 --fast-rollback。

3.6 SWA 路径是 Qwen3.6 的标准设置。我们在 Lucebox/Qwen3.6-27B-DFlash-GGUF 发布了匹配的 Q8_0 GGUF 草稿模型。DFLASH27B_DRAFT_SWA=2048 激活了针对 3.6 草稿模型全注意力层的滑动窗口修正。如果不使用 SWA，相同路径的速度会降至 24.29 tok/s。

预填充：PFlash 对比原始 AR

长上下文 TTFT 是另一个关键维度。在 gfx1151 上，原生的 llama.cpp 以 265.6 tok/s 的速度预填充 Qwen3.6-27B Q4_K_M 的 16K token，这意味着你要盯着空白屏幕等待 61.7 秒。PFlash 使用 Qwen3-0.6B BF16 草稿模型压缩提示词，评估每个 token 的重要性，保留 5% 的切片，并仅将该切片输入目标模型。在 16K 长度下，使用 WMMA 回退方案（HIP 上的 BSA 是剩余的关键部分），NIAH 检索测试仍然通过。

PFlash 压缩阶段（草稿评分 + 选择）在任何低于守护进程 KV 上限的源长度 S 下都是常数；主要开销在于对压缩提示词的目标预填充。PR #159 将守护进程的压缩预填充 ubatch 默认值从 16 提升到 512，这使得在保留 1205 个 token 时，target_prefill 时间从 12.4 秒降低到 5.2 秒。无需额外的内核工作，提交的字节流完全相同。

端到端实际耗时

解码加速对于长生成最为关键。预填充加速对于大提示词最为关键。完整的请求两者兼具。以下是数据：PR #119 PFlash TTFT（配合 PR #159 ubatch=512）+ PR #119 DFlash 解码速度 26.85 tok/s，均基于 Qwen3.6-27B Q4_K_M 和 Lucebox Q8_0 草稿模型。

为什么 Strix Halo 上预算设为 22

DDTree 每步构建包含 N 个候选 token 的推测树，并在一个批处理的目标前向传播中验证它们。树越大，每步接受的 token 越多，但每一步的 KV 内存流量开销也越大。在受带宽限制的硅片上，开销占主导。我们遍历了从 8 到 128 的预算值：

对比 gfx1100 (7900 XTX, GDDR6 936 GB/s)：根据 PR #156，在那些硬件上 budget=8 胜出，因为 tile 浪费比启动摊销更重要。而在 Strix Halo 上情况相反。默认发布是架构感知的。

128 GiB 的余量

对于 Qwen3.5-27B Q4_K_M（15.65 GiB 目标模型 + 1.84 GiB 草稿模型 + KV 缓存），剩余 约 100 GiB 空闲。同一台机器可以运行：Qwen3.5-122B-A10B，MiniMax-M2.7-REAP 139B-A10B（占用 78 GiB），完整 BF16 精度的 27B 模型（占用 50 GiB）。PR #119 的加速目前适用于 27B 级别的模型。

复现步骤

DFLASH27B_PREFILL_UBATCH=512 覆写会在 PR #119 的基础上应用 PR #159 的修复。一旦 #159 合并，这将成为守护进程的默认设置。

尚缺少的部分

• HIP 上的 BSA 评分内核。草稿压缩评分路径在 CUDA 上使用 BSA（块稀疏注意力）。PR #119 在 HIP 上禁用了它并回退到 ggml 的 flash_attn_ext，守护进程警告标志显示其速度慢了约 3.4 倍。原生 rocWMMA 稀疏 FA 内核将填补这一差距。落地后，16K 下的 PFlash TTFT 将从 27.6 秒降至约 8 秒。在 128K 下，预计比 llama.cpp AR 快 7-10 倍。

• 多行 q4_K 解码 GEMV。RDNA 原生的多行 GEMV 模式（R=4-8 输出行共享激活寄存器状态）用于草稿模型前向传播，这在长上下文中占压缩时间的 30%。

• gfx1151 的 Phase 2 tile 形状调优。当前的 rocWMMA flashprefill tile 是针对 gfx1100 调优的。Strix Halo 具有不同的 LDS 和 VGPR 特性。

• 70B+ MoE 目标模型。在 16 GiB 的 27B 模型上，128 GiB 的余量被浪费了。Qwen3.5-122B-A10B 和 MiniMax-M2.7-REAP 139B-A10B 都能放下。DFlash 数学可以干净地移植到 MoE；主要工作是将专家路由前向传播接入推测验证循环。

结论

PR #119 加上 PR #159 使得 lucebox 在 Strix Halo 上针对标准的 Qwen3.6-27B 路径变得飞快。16K 上下文下，端到端实测解码速度 26.85 tok/s，预填充时间 20.2 秒，分别比同一 iGPU 上的 llama.cpp HIP 快 2.23 倍和 3.05 倍。架构提升（从 CUDA 到 HIP，rocWMMA flashprefill，DDTree 验证器）是一大块拼图；剩余的收益来自内核优化。

AMD 消费级硬件上的本地推理故事不再是神话。一台 Ryzen AI MAX+ 395 拥有 128 GiB 统一内存，运行 Qwen3.6-27B，承载 DFlash 推测解码和 PFlash 长上下文预填充，在现实的 16K + 1K 工作负载下，实际耗时为 58 秒，而 llama.cpp 为 147 秒。同一硬件接下来也足以承载 122B 和 139B 的 MoE 类模型。