AMD Strix Halo 上的 Luce DFlash + PFlash：Qwen3.6-27B 解码速度提升 2.23 倍，预填充速度提升 3.05 倍（相较于 llama.cpp HIP）

大家好，Llama 社区的伙伴们，长话短说。我们刚刚为 AMD Ryzen AI MAX+ 395 集成显卡（gfx1151, Strix Halo, 128 GiB 统一内存）发布了 **DFlash** 和 **PFlash** 支持。这套 Luce DFlash 技术栈与 [几周前关于 RTX 3090 的文章](https://www.reddit.com/r/LocalLLaMA/comments/1sx8uok/luce_dflash_qwen3627b_at_up_to_2x_throughput_on_a/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) 中提到的完全相同，现在可以在消费级 AMD APU 平台运行了。**仓库：** [https://github.com/Luce-Org/lucebox-hub](https://github.com/Luce-Org/lucebox-hub) (MIT) # TL;DR 在 Luce Q8\_0 DFlash 草稿模型辅助下，端到端运行 Qwen3.6-27B Q4\_K\_M：**解码速度达到 26.85 tok/s**，**在 16K 上下文长度下预填充时间为 20.2 秒**。与在同一硬件上使用 llama.cpp HIP 相比，解码速度快 2.23 倍，预填充速度快 3.05 倍。在 16K 提示词 + 1K 生成任务的工作负载下，总耗时从 147 秒降至 58 秒，**端到端速度提升 2.5 倍**。同一台 128 GiB 的机器可以加载高达 ~100 GiB 的检查点，这是 24 GiB 消费级 GPU 无法触及的模型类别（如 Qwen3.5-122B-A10B, MiniMax-M2.7-REAP 139B-A10B, 全 BF16 27B 模型）。 # 数据详情 **硬件：** 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` **解码 (Qwen3.6-27B Q4\_K\_M, tok/s):** |引擎|tok/s|vs AR| |:-|:-|:-| |llama.cpp HIP AR|12.02|1.00x| |llama.cpp Vulkan AR|12.45|1.04x| |**Luce DFlash (本 PR)**|**26.85**|**2.23x**| **预填充 (Qwen3.6-27B, 16K tokens):** |引擎|TTFT|vs AR| |:-|:-|:-| |llama.cpp HIP AR|61.69 s|1.00x| |**Luce PFlash**|**20.2 s**|**3.05x**| 速度提升随上下文长度增加而扩大：PFlash 压缩复杂度为 O(S)，而自回归 (AR) 预填充复杂度为 O(S^2)。在 16K 长度下，NIAH（长上下文检索）测试依然通过。 **调优笔记：** `--ddtree-budget=22` 是 gfx1151 的最优值。更高的预算意味着每一步接受更多 token，但在 LPDDR5X 上每一步的成本更高。带宽瓶颈在片上利用率带来收益之前就限制了性能提升。相比之下，gfx1100（7900 XTX, GDDR6 936 GB/s）的最优预算为 8，因为片上浪费比启动摊销更关键。默认出厂设置已具备架构感知能力。 # 复现步骤 ```bash # 1. 为 gfx1151 构建 PR #119 git clone https://github.com/Luce-Org/lucebox-hub.git cd lucebox-hub git fetch origin pull/119/head:pr119 && git checkout pr119 git submodule update --init --recursive cd dflash cmake -B build -S . \ -DCMAKE_BUILD_TYPE=Release \ -DDFLASH27B_GPU_BACKEND=hip \ -DDFLASH27B_HIP_ARCHITECTURES=gfx1151 \ -DDFLASH27B_HIP_SM80_EQUIV=ON cmake --build build --target test_dflash -j # 2. 模型：Qwen3.6-27B 目标模型 + Lucebox Q8_0 DFlash 草稿模型 mkdir -p models/draft hf download unsloth/Qwen3.6-27B-GGUF Qwen3.6-27B-Q4_K_M.gguf --local-dir models/ hf download Lucebox/Qwen3.6-27B-DFlash-GGUF dflash-draft-3.6-q8_0.gguf --local-dir models/draft/ # 3. 基准测试 (DFlash 解码 + PFlash 长上下文预填充) LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH \ DFLASH_BIN=$PWD/build/test_dflash \ DFLASH_TARGET=$PWD/models/Qwen3.6-27B-Q4_K_M.gguf \ DFLASH_DRAFT=$PWD/models/draft/dflash-draft-3.6-q8_0.gguf \ DFLASH27B_DRAFT_SWA=2048 \ DFLASH27B_PREFILL_UBATCH=512 \ python3 scripts/bench_he.py --n-gen 128 --ddtree-budget 22 ``` `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 原生多行模式（R=4-8 输出行共享激活寄存器状态），目前占长上下文压缩时间的 30%。 * **gfx1151 的第二阶段片形状调优。** 当前的 rocWMMA flashprefill 片形状是针对 gfx1100 调优的。Strix Halo 具有不同的 LDS 和 VGPR 特性。 * **70B+ MoE 目标模型。** 128 GiB 显存用于 27B 模型有些浪费。Qwen3.5-122B-A10B 和 MiniMax-M2.7-REAP 139B-A10B 都可以加载。DFlash 数学部分可以干净地移植到 MoE；主要工作是将专家路由前向传播接入推测验证循环中。 # 限制条件 需要 ROCm 7.2.2+，针对 gfx1151 调优（也支持使用架构感知默认值的 gfx1100），仅支持贪婪验证，此路径暂不支持 Vulkan / Metal / 多 GPU。我们正在努力改进这些方面，但知道还有很多需要提升的地方。非常欢迎反馈 :)