🔥 Lucebox DFlash 在 7900 XTX 上跑 Qwen3.6-27B — 完整复现与实测报告

abaalei

写在前面

Reddit 有人发了 Lucebox DFlash 在 7900 XTX 上跑 Qwen3.6-27B 的测试，62.75 tok/s，看得手痒。趁着周末自己也搭了一遍，前后折腾了三天，踩了不少坑，也发现了一些有意思的东西。

这份报告不只是复制粘贴 Reddit 的结论，而是包括了我们自己各种方案的横评对比。

硬件配置

+-----------------------------------+------------------------------------------------+
| 组件 | 详情 |
+-----------------------------------+------------------------------------------------+
| CPU | Intel Xeon E5-2682 v4 × 2 (32C/64T) |
| 主板 | 华强北白牌X99-6Plus 槽距63mm pcie3.0（16x4 8x2）|
| GPU | AMD Radeon RX 7900 XTX 24GB (Navi 31) |
| 显存带宽 | ~936 GB/s |
| 系统内存 | 62 GiB DDR4 ECC |
| 系统盘 | SATA SSD |
| 额外 GPU（后处理/语音用） | NVIDIA GeForce RTX 3080 Ti 12GB |
+-----------------------------------+-------------------------------------------------+

注： 3080 Ti 插在机器上但做的是 ComfyUI 视频后处理和 VoxCPM 声线转换，测 LLM 时完全不参与。不过后文会提到——Vulkan 后端不会自动隔离它，这是个坑。

软件环境

+-----------------------------------+----------------------------------------+
| 组件 | 版本 |
+-----------------------------------+----------------------------------------+
| OS | Ubuntu 24.04 LTS |
| Kernel | 6.8.0-124-generic |
| ROCm | 7.2.0 |
| llama.cpp | 3ebe862b5 (2026-06) |
| Lucebox DFlash | 73678fa (master, HIP PR #119) |
+-----------------------------------+----------------------------------------+

对比的 Reddit 帖文用的是 Ubuntu 26.04 + ROCm 7.1，我们稍微新一点。但实际跑分差异主要不在这。

🧪 整个测试历程（三天踩坑实录）

Day 1: 先试 MTP，把参数撸了个遍

最开始没发现 DFlash，先用 llama.cpp 自带的 MTP (Multi-Token Prediction) 投机解码。目标是用 Huihui 的无审查 Q4_K 模型。

MTP 参数调优

MTP 有个核心参数：投机个数 n（每次猜几个 token）。

+-----------+--------+--------+----------------+
| n 值 | tok/s | 加速比 | 说明 |
+-----------+--------+--------+----------------+
| 无 MTP | 30.7 | 1.00x | 纯自回归基线 |
| n=2 | 43.3 | 1.41x | 还行 |
| n=3 | 47.3 | 1.54x | 最优 |
| n=4 | 40.7 | 1.32x | 过度投机，反降 |
+-----------+--------+--------+----------------+

结论： 在 RDNA3 上 n=3 是甜点。n=4 时 MTP 头预测的 token 接受率下降，白白浪费算力。

ROCm 优化参数验证（血泪教训）

网上抄了一堆「优化参数」一个个验证（编者注：有agent就是好，看到论坛内的贴/X上面的贴不管有没有用就直接扔
给agent进行分析匹配，然后一项项让她自己随即跑，省下不少时间，就是token烧不少了）：

+--------------------+--------+--------+----------------------------+
| 参数 | TG 前 | TG 后 | 结论 |
+--------------------+--------+--------+----------------------------+
| --batch-size 1024 | 47.3 | 47.3 | ≈ 完全无影响 |
| --flash-attn on | 47.3 | 47.3 | ≈ 完全无影响 |
| --cache-ram 0 | 47.3 | 48.7 | ≈ 可以忽略 |
| 全开(3个全加) | 47.3 | 47.3 | ≈ 完全无影响 |
| MMVQ_MAX_BATCH=3 | 47.3 | 30.7 | 降30%是毒药 |
| --no-mmap | 47.3 | OOM | 直接在 ROCm 上报错崩溃 |
+--------------------+--------+--------+----------------------------+

结论： ROCm + RDNA3 上绝大部分社区「优化参数」都是抄 CUDA 的，搬过来要么没效果要么反效果。核心只有 --spec-type draft-mtp --spec-draft-n-max 3，其他全删掉就是最优。

Day 2: Vulkan 对比 + 发现 3080 Ti 污染

想看看 Vulkan 和 ROCm 有多大差距，结果发现了一个大坑。

双 GPU 的 Vulkan 陷阱

+-----------------------------+--------+----------------------------------+
| 配置 | tok/s | 说明 |
+-----------------------------+--------+----------------------------------+
| ROCm (纯 7900 XTX) | 47.3 | ROCm 天然只看 AMD GPU |
| Vulkan (默认, 双卡都在) | 25~29 | 被 3080 Ti 分走部分 work |
| Vulkan + VK_ICD_FILENAMES | ~0 | RADV 退 CPU, GPU 0% |
| Vulkan + GGML_VULKAN_DEVICE | 25~29 | 设了也没用，3080 Ti 仍占 6.9GB |
+-----------------------------+--------+----------------------------------+

细说 Vulkan 的坑：

GGML_VULKAN_DEVICE=1 无法真正隔离 GPU — 设了之后 7900 XTX 干活，但 3080 Ti 仍然被分配了 ~6.9GB 显存。两张卡之间 PCIe 来回走，带宽瓶颈直接拖死。

VK_ICD_FILENAMES 可以物理隐藏 3080 Ti，但只能用 RADV 开源驱动（不能用 AMD 官方驱动）。RADV 下 compute 全退 CPU（GPU 0%, CPU 99%），根本跑不动。

结论：ROCm 才是纯 7900 XTX 的唯一可靠后端。 之前谣传的 Vulkan 好用，全是因为没发现 3080 Ti 在偷算力。

MTP 精度敏感

IQ4_XS GGUF 有的版本自带 MTP 层有的没有。如果模型不带 MTP 层，--spec-type draft-mtp 直接报 model doesn't contain MTP layers。就算带了，IQ4_XS 的接受率也只有 ~34%，不如 Q4_K 的 ~50%。

Day 3: DFlash 登场

社区发现 Lucebox DFlash 在 AMD 上能跑出 2.2x 加速，立马安排。

编译

git clone https://github.com/Luce-Org/lucebox-hub.git
cd lucebox-hub
git submodule update --init --recursive
cd dflash

cmake -B build -S . \
  -DCMAKE_BUILD_TYPE=Release \
  -DDFLASH27B_USE_HIP=ON \
  -DCMAKE_HIP_ARCHITECTURES="gfx1100" \
  -DROCM_PATH=/opt/rocm-7.2.0

cmake --build build --target test_dflash -j$(nproc)

踩坑： CMakeLists.txt 引用了不存在的 src/prefix_cache.cpp，删掉该行即可。

️ 模型层数陷阱（踩了两次）

DFlash 的草稿模型基于 Qwen3.6 原版架构（64 层），所以主模型也必须是 64 层。我们最早用的 Huihui Q4_K 有 65 层（含 MTP 头），DFlash 加载直接不兼容。

正确搭配必须是 64 层模型。

测量方法的坑

一开始用 scripts/run.py 单 prompt 测，只跑出 56.14 tok/s。后来发现 Reddit 帖子用的是 bench_he.py（10 道 HumanEval 编程题平均），测出来的才是纯解码速度：

DFLASH_BIN=$PWD/build/test_dflash \
DFLASH_TARGET=/path/to/64层主模型.gguf \
DFLASH_DRAFT=models/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 8

全部方案横向对比

+--------------------------------+---------+--------+----------------------------+
| 方案 | tok/s | 加速比 | 说明 |
+--------------------------------+---------+--------+----------------------------+
| Pure AR (llama.cpp HIP) | 30.83 | 1.00x | 自回归基线 |
| ROCm MTP n=2 (Q4_K) | 43.3 | 1.40x | 早期 MTP 配置 |
| ROCm MTP n=3 (Q4_K) | 47.3 | 1.53x | MTP 最优 |
| ROCm MTP n=4 (Q4_K) | 40.7 | 1.32x | 过度投机 |
| Vulkan MTP (受3080 Ti污染) | 25~29 | 0.9x | 比纯AR还慢 |
| DFlash Q4 draft + budget=22 | 27.03 | 0.88x | 草稿太慢+验证树太大 |
| DFlash chain (无DDTree) | 64.23 | 2.08x | 简单策略还行 |
| DFlash Q8 draft + budget=8 | 68.80|2.23x| 全场最佳 |
| DFlash Q8 draft + budget=22 | 60.94 | 1.98x | budget 太大浪费带宽 |
+--------------------------------+---------+--------+----------------------------+

DFlash 完整实测明细

1:1 对照 Reddit

+---------------------+-------------------+-------------------+--------+
| 项目 | Reddit 帖文 | 我们实测 | 差异 |
+---------------------+-------------------+-------------------+--------+
| AR 基线 | 28.07 tok/s | 30.83 tok/s | +10% |
| DFlash DDTree b=8 | 62.75 tok/s | 68.80 tok/s | +9.6% |
| 加速比 | 2.24x | 2.23x~2.45x | 持平 |
| 平均提交长度 | 4.93 | 4.79 | -3% |
| ROCm | 7.1 | 7.2 | — |
| 主模型 | 原版 Qwen3.6 27B | Heretic 无审查版 | — |
+---------------------+-------------------+-------------------+--------+

bench_he.py 10 题明细

+-----------------------------+-------+------+--------+
| prompt | tok/s | AL | 接受率 |
+-----------------------------+-------+------+--------+
| has_close_elements | 41.63 | 2.91 | 18.2% |
| separate_paren_groups | 68.61 | 4.92 | 30.8% |
| truncate_number | 61.05 | 4.13 | 25.8% |
| below_zero | 74.61 | 5.12 | 32.0% |
| mean_absolute_deviation | 55.97 | 4.43 | 27.7% |
| intersperse | 89.24 | 6.10 | 38.1% |
| parse_nested_parens | 70.85 | 4.92 | 30.8% |
| filter_by_substring | 69.46 | 4.74 | 29.6% |
| sum_product | 93.42 | 6.40 | 40.0% |
| rolling_max | 63.19 | 4.27 | 26.7% |
+-----------------------------+-------+------+--------+
| MEAN |68.80|4.79|30.0%|
+-----------------------------+-------+------+--------+

DFlash 时序分解（budget=8）

+----------------+----------+--------+
| 阶段 | 耗时/步 | 占比 |
+----------------+----------+--------+
| draft_build | 0.61 ms | 0.9% |
| draft_compute | 11.91 ms | 17.8% |
| verify_build | 1.66 ms | 2.5% |
| verify_compute | 51.85 ms | 77.6% |
| 其他 | 0.67 ms | 1.0% |
| 合计每步 | 66.85 ms | — |
| 每步提交 | 3.76 tokens | — |
+----------------+----------+--------+

瓶颈在验证阶段（78%），这是 RDNA3 的 WF32 物理上限。

DFlash 参数调优对比

+---------------------------+--------+---------------------------------------+
| 参数 | tok/s | 说明 |
+---------------------------+--------+---------------------------------------+
| Q4 draft + budget=22 | 27.03 | Q4 反量化拖草稿 + 验证树太大 |
| Q8 draft + budget=8 |68.80 | AMD RDNA3 上 Q8 反量化快于 Q4 |
| Q8 draft + budget=22 | 60.94 | budget 太大，验证树浪费 GDDR6 带宽 |
| chain（无 DDTree） | 64.23 | 短生成更快，长上下文不如 DDTree |
+---------------------------+--------+---------------------------------------+

关键发现（不只是抄结论）

1. Budget=8 是 7900 XTX 的甜点

完全验证了 Reddit 和 PR #156 的结论。budget=8 时验证树大小刚好填满 GDDR6 的 wavefront，再大就浪费了。

2. 无审查版不影响 DFlash 性能

Abliterate 改的是 attention 里拒绝回答的方向，对草稿接受率无影响。实测 68.80 tok/s 高于 Reddit 原版的 62.75，说明不存在负面作用。

3. ROCm 优化参数基本都是玄学

在 RDNA3 上 batch-size、flash-attn 这些 CUDA 优化全都没效果。--no-mmap 甚至直接 OOM。越简单越好。

4. 双 GPU 机器测 Vulkan 要小心 ️

Vulkan 默认把所有 GPU 拉进来干活，3080 Ti 被分配 ~6.9GB显存，跨卡 PCIe 瓶颈直接拖死。ROCm 天然隔离 NVIDIA，才是正确方案。

5. 测量方法很重要 ️

run.py 单 prompt → 56.14 tok/s（含预填充开销）
bench_he.py 多 prompt 平均 → 68.80 tok/s（纯解码速度）
对标别人必须用同款工具。

6. MTP n=3 是第二选择

如果不用 DFlash，ROCM MTP n=3 + Q4_K 是 47.3 tok/s 的可靠方案。但 Q4_K_M + DFlash 的 68.8 tok/s 直接拉开 45% 差距。

最终结论

Lucebox DFlash 在 RX 7900 XTX (24GB) + Qwen3.6-27B 上：

实测 68.80 tok/s（bench_he.py 10 HumanEval tg128）
相比 llama.cpp HIP 纯自回归基线 30.83 tok/s → 2.23x 加速
超越 Reddit 帖文 62.75 tok/s，证实 AMD 卡在 DFlash 上确实能跑出好成绩

参考链接

Lucebox DFlash: https://github.com/Luce-Org/lucebox-hub
草稿模型: https://huggingface.co/Lucebox/Qwen3.6-27B-DFlash-GGUF
主模型(Heretic 无审查): https://huggingface.co/Youssofal/Qwen3.6-27B-Abliterated-Heretic-Uncensored-GGUF
lcz.me 论坛帖: https://lcz.me/topic/195/
Reddit 原帖: https://www.reddit.com/r/LocalLLaMA/comments/1tgepbd/

写在最后：折腾的路还在继续，第二篇帖子已经写好了，再折腾半天即可发布~！
附上简陋的测试环境、杂乱的线材、远远比不上各位前辈们的海景房大机箱
图片_20260610101156.jpg

图片_20260610101147.jpg

abaalei

补充一下Deepseek v4 Flash 的账单

5ccccc

我用MTP差不多也是45左右，之前折腾DFlash没跑通，忘了是哪没搞定

abaalei

@5ccccc
那可以再试试，这是我发的贴的上半篇，下半篇后面发出来了，你可以发给agent让他对照你之前的经验进行除错，我也是烧了3天token才折腾好dflash

laobenxiong

这里写的编译指令貌似过时了。主要差异：

博客写的	现在的正确写法
`-DDFLASH27B_USE_HIP=ON`	`-DDFLASH27B_GPU_BACKEND=hip`（这个 flag 不存在了）
`-DCMAKE_HIP_ARCHITECTURES="gfx1100"`	`-DDFLASH27B_HIP_ARCHITECTURES="gfx1100"`
`-DROCM_PATH=/opt/rocm-7.2.0`	改为环境变量 `export ROCM_PATH=/opt/rocm`（不是 cmake 参数）
`cd dflash`	`cd server`（目录从 `dflash/` 重命名为 `server/`，PR #281）
`--target test_dflash`	应加上 `dflash_server`
删掉 `src/prefix_cache.cpp`	不需要手改 cmake 了
没提 `-DDFLASH27B_FA_ALL_QUANTS`	新选项

总结变化原因：PR #281 把 dflash/ 重命名为 server/，同时 CMake 选项也做了重整（DFLASH27B_USE_HIP → DFLASH27B_GPU_BACKEND=hip）。博客写的时候还是旧版本。

kenshin

跃跃欲试，现在qwen3.6 27B,稳定50t/s，但跑多了，也会掉到40+t/s，提供参数。

#!/bin/bash
export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json

./build/bin/llama-server \
  --host 0.0.0.0 \
  --port 8080 \
  -m ~/gguf_models/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf \
  -ngl 99 \
  -c 81920 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --cont-batching \
  --mlock \
  --no-mmap \
  --main-gpu 0 \
  -b 1024 \
  -ub 1024

CHIA AN YANG

@kenshin 請問有辦法調用hermes agent使用嗎?

williamlouis

@CHIA-AN-YANG 局域网都可以。直接问在线ai就可以了。

CHIA AN YANG

我抄作業了只要發telgram給hermes就炸顯存

williamlouis

@CHIA-AN-YANG 分析下显存的情况哈。你跑的什么模型现在是什么状态。驱动模型启动配置都是什么

williamlouis

分析下显存的情况哈。
我的：
最终汇总

DFlash + Huihui Q4_K_M 已就绪，端口 11435


目录隔离:
  /opt/lucebox-dflash/          ← DFlash 全套（编译+模型）
  /opt/llama.cpp/                ← 你原有的 llama.cpp（不动）

速度:
  test_dflash 原生:  ~46 tok/s   (vs 你原有 25 tok/s)
  API 模式:          ~26 tok/s

启动命令:
  cd /opt/lucebox-dflash/server
  HSA_OVERRIDE_GFX_VERSION=11.0.0 ./build/dflash_server \
    models/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf \
    --draft models/draft/dflash-draft-3.6-q8_0.gguf \
    --ddtree --ddtree-budget 8 \
    --fa-window 0 \
    --host 0.0.0.0 --port 11435

API 端点: http://127.0.0.1:11435/v1/chat/completions (OpenAI 兼容)

注意事项:
  - 每次重启系统后需重新 sudo tee DPM high
  - --ddtree-budget 必须用空格不能用等号
  - 草稿模型接受率对中文对话偏低(~15%)，代码场景会更高


两套系统零关联，互不影响。如果 Huihui 的去审查特性不是你需要的，随时可以把 --target 换成你原有的原版 Q4_K_M 模型路径来对比。

继续测试中。目前没什么问题。测作业中。
我的对话你参考下。这就接入到局域网的Hermes了。
──────────────────────────────────────
● 这个我需要接入到Mac的Hermes 在测是吧？
────────────────────────────────────────

╭─ Hermes ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
对，刚才的 curl 测试只是在 Linux 本机验证功能。要在 Mac 的 Hermes Agent 里实际对话，需要把 DFlash 配成 Hermes 的一个 provider。

你的 Linux 机（7900 XTX）和 Mac 在同一个局域网吗？如果可以互相 ping 通，配置就很简单——在 Hermes 里加一个自定义 provider，指向 Linux 机的 IP + 端口 11435。

如果可以的话，我先帮你确认一下 Linux 机的局域网 IP，然后告诉你 Mac 端 Hermes 怎么配。

╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

────────────────────────────────────────
● 好的。给我详细配置我发给 Mac的 Hermes
────────────────────────────────────────

┊ preparing terminal…
┊ preparing skill_view…
┊ $ ip addr show | grep -E "inet " | grep -v 127.0.0.1 2>&1 0.1s
┊ skill hermes-agent 0.0s

╭─ Hermes ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
Linux IP 是 192.168.8.247。先确认端口对外可达，然后给你生成 Mac 端配置。
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
┊ preparing terminal…
┊ $ ss -tlnp | grep 11435 2>&1 0.1s

╭─ Hermes ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
监听在 0.0.0.0:11435，对外可达。确认一下 API 完整参数：
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
┊ preparing terminal…
┊ $ curl -s http://127.0.0.1:11435/v1/models 2>&1 0.1s

╭─ Hermes ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮

Mac 端 Hermes 配置

在 Mac 的终端执行以下三条命令：

bash
hermes config set model.provider custom
hermes config set model.base_url http://192.168.8.247:11435/v1
hermes config set model.api_key not-needed


然后切换模型：

bash
hermes model


在出现的交互菜单中选择或直接输入 dflash。



配置说明

| 配置项         | 值                            | 说明                            |
|----------------|-------------------------------|---------------------------------|
| model.provider | custom                        | 自定义 OpenAI 兼容后端          |
| model.base_url | http://192.168.8.247:11435/v1 | 你的 Linux 机 LAN IP            |
| model.api_key  | not-needed                    | DFlash 不需要认证，填占位符即可 |
| 模型名称       | dflash                        | 服务端上报的名称                |

前提检查

确保 Mac 能 ping 通 Linux 机：
bash
ping 192.168.8.247


如果 Linux 有防火墙，需要放行 11435 端口（通常家庭内网不需要额外配置）。



如果要切回原来的模型

bash
hermes model          # 交互式换回之前的 provider
或者：
hermes chat -m 原来的模型名


不会影响现有配置，随时可切换。

abaalei

@laobenxiong 感谢捉虫！刚特意上机确认了一下我们实际编译的状态，供参考：

我用的 commit 73678fa，实际情况跟你说的不完全一致——取决于版本差异：

dflash/ vs server/：我们两个目录都有，但 server/ 下没有 CMakeLists.txt，实际编译仍在 dflash/ 下正常进行。cd server 可能需要更新的 commit 才是强制的。
USE_HIP=ON 与 GPU_BACKEND=hip：我们 CMakeCache 里两个 DFLASH27B_USE_HIP:BOOL=ON 和 DFLASH27B_GPU_BACKEND=hip 并存，都能过。旧 flag 没有"不存在了"。
CMAKE_HIP_ARCHITECTURES vs DFLASH27B_HIP_ARCHITECTURES：我们用的前者，正常编译。
ROCM_PATH：-DROCM_PATH=/opt/rocm-7.2.0 也能用，不一定要环境变量。
FA_ALL_QUANTS=ON 已开。
prefix_cache.cpp 确实不需要手改了。

我们实测 FA_ALL_QUANTS=ON + Huihui Q4_K_M 能跑到 81.38 tok/s（bench_he.py），高于原帖的 68.80。所以整体思路没问题，只是一些 cmake flag 的改法在不同版本间不是唯一的。感谢补充！

abaalei

@5ccccc 45 跟我们的 MTP n=3 成绩（47.3）差不多，正常。DFlash 没跑通可以把报错贴出来帮你看看，常见原因就几个：

fattn.cu:312 崩溃 → 主模型必须是 64层（65层带MTP头的GGUF不兼容），编译时加 -DDFLASH27B_FA_ALL_QUANTS=ON 重建，启动加 --fa-window 0
草稿模型 → 必须用 Lucebox 官方的 Q8 GGUF，Q4 草稿在 RDNA3 上反量化反而拖慢
Budget=8 是甜点，再大验证树填不满 GDDR6 的 wavefront

我们用 Huihui 无审查版 + FA_ALL_QUANTS=ON 跑到了 81.38 tok/s，比原帖 68.80 还高 18%，AMD 这卡在 DFlash 上确实能打。（我让我家agent回你）

abaalei

@CHIA-AN-YANG 炸显存排查几个点：

启动时有没有加 --fa-window 0？不加的话长上下文 KV cache 预填会炸
主模型确认是 64层版本吗？65层（带MTP头）的GGUF在DFlash下不兼容
--max-ctx 设了多少？建议先设 16384 起步
Hermes 的 max_tokens 别设太大，建议先 2048

把启动命令和模型路径贴出来帮你看看。

abaalei

@williamlouis
46 tok/s 不错，几个思路？：

FA_ALL_QUANTS=ON 重新编译：我们开了这个之后 bench_he.py 从 68.80 直接升到 81.38 tok/s（+18%），因为 VEC kernel 能匹配到正确的量化模板了。
--ddtree-budget 8：RDNA3 上 budget 太大验证树反而拖慢，8 是甜点
API 模式 26 tok/s 偏低，检查有没有设 --tokenizer Qwen/Qwen3.6-27B，缺这个会导致 token 计数偏差
中文对话接受率 15% 正常，代码场景会更高

启动命令参考（我们已稳跑）：

cd /home/peter/lucebox-hub/dflash
python3 scripts/server.py
--target Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf
--draft models/dflash-draft-3.6-q8_0.gguf
--budget 8 --fa-window 0
--tokenizer Qwen/Qwen3.6-27B
--host 0.0.0.0 --port 11435

abaalei

@kenshin 我家agent给你的一点小意见（仅供参考，不确定有没有幻觉哈，我也是菜鸡，只会按遥控器）：
这套配置跑 Qwen3.6 27B 稳定 50 t/s 确实不错，Vulkan 下的调优很有针对性。--cache-type-k/v q8_0 和 --no-mmap 在 Vulkan 后端确实是正优化，放对位置了

几个技术建议：

1️⃣ --spec-draft-n-max 2 → 3（最直接的白嫖）
我们在 7900 XTX 上实测：

n=2: 43.3 t/s
n=3: 47.3 t/s （+4 t/s）
n=4: 40.7 t/s（过度投机反降）

RDNA3 上 n=3 是 MTP 甜点，接受率最高。你换到 n=3 应该能从 50 提到 52-54。

2️⃣ 双卡确认（如果你有 NVIDIA 卡）
你用的 VK_ICD_FILENAMES 可以隐藏 NVIDIA 卡，但 Vulkan 仍有可能给另一张卡分配显存（~6.9GB），跨卡 PCIe 带宽瓶颈会拖慢。建议 rocm-smi 看一眼确认。如果是双卡机器，ROCm 后端能天然隔离 NVIDIA，是更干净的方案。

3️⃣ 掉速分析（50→40+）
大概率不是参数问题，排查方向：

KV cache 积累：长时间对话后上下文涨了，MTP 窗口被挤占
热降频：跑久了 RDNA3 热点温度一超就降频，rocm-smi 看温度
并发排队：cont-batching 下多请求排队，单请求吞吐必然下降

4️⃣ 进阶路线

--no-mmap + --mlock 在 Vulkan 下没问题，但以后切 ROCm 时必须去掉，否则 OOM
如果追求更高速度，可以试 DFlash 路线（需 64 层模型，不能用你现在这个带 MTP 头的 GGUF）。我们 7900 XTX + ROCm + DFlash 跑到 81.38 t/s，比 MTP 快 60%+

期待你的调试结果！

Colt

同为7900XTX，想抄作业，ubuntu26.04，之前已安装了ROCm 7.2.3，并编译llama.cpp 正常运行。这次在编译和运行test_dflash 遭遇不少挫折，最终通过如下命令编译成功：

cmake -B server/build -S server   -DCMAKE_BUILD_TYPE=Release   -DDFLASH27B_GPU_BACKEND=hip   -DCMAKE_HIP_ARCHITECTURES=gfx1100   -DROCM_PATH=/opt/rocm-7.2.3   -DDFLASH27B_HIP_SM80_EQUIV=ON   -DCMAKE_C_STANDARD=11   -DCMAKE_CXX_STANDARD=17   -DGGML_CCACHE=OFF
cmake --build server/build --target test_dflash -j$(nproc)

但是跑bench全部失败，单独运行test_dflash，错误信息如下：

LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH HSA_OVERRIDE_GFX_VERSION=11.0.0 DFLASH27B_DRAFT_SWA=2048 DFLASH27B_PREFILL_UBATCH=32 /home/user/lucebox-hub/server/build/test_dflash /data/models/Qwen/Qwen3.6-27B-Q4_K_M.gguf /data/models/Lucebox/dflash-draft-3.6-q8_0.gguf /tmp/dflash_bench/he_prompt_Qwen_Qwen3.5-27B_00.bin 128 /tmp/out_test.bin --fa-window 0 --ddtree --ddtree-budget=8
[cfg] seq_verify=0 fast_rollback=1 ddtree=1 budget=8 temp=1.00 chain_seed=1 fa_window=2048 draft_swa=2048 draft_ctx_max=4096 draft_feature_mirror=0 peer_access=0 target_gpu=0 draft_gpu=0
ggml_cuda_init: found 1 ROCm devices (Total VRAM: 24560 MiB):
  Device 0: Radeon RX 7900 XTX, gfx1100 (0x1100), VMM: no, Wave Size: 32, VRAM: 24560 MiB
[loader] eos_id=248046 eos_chat_id=-1
[target] target loaded: layers [0,64) output=1, 850 tensors on GPU 14.99 GiB, tok_embd 682 MiB CPU-only (q4_K)
[draft]  loaded
[draft]  SWA layers: 4/5 (window=2048)
[prompt] 125 tokens
[prefill] token-seg ubatch=32
Segmentation fault         (core dumped) LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH HSA_OVERRIDE_GFX_VERSION=11.0.0 DFLASH27B_DRAFT_SWA=2048 DFLASH27B_PREFILL_UBATCH=32 /home/colt/lucebox-hub/server/build/test_dflash /data/models/Qwen/Qwen3.6-27B-Q4_K_M.gguf /data/models/Lucebox/dflash-draft-3.6-q8_0.gguf he_prompt_Qwen_Qwen3.5-27B_00.bin 128 /tmp/out_test.bin --fa-window 0 --ddtree --ddtree-budget=8

dmesg 错误日志

traps: test_dflash[35252] general protection fault ip:755a83ab097f sp:7ffd64484780 error:0 in libamdhip64.so.7.2.70203[2b097f,755a83823000+481000]

问遍AI，不得其解。目前尚无头绪，不确定是否为ROCm的版本导致。我看楼主也是7.2版本，请教楼主是否曾经遇到类似问题。不到万不得已，实在不想折腾退回ROCm 6.3。

CS6

@abaalei 大佬要不也嘗試下虛擬化方案？我是走 PVE 顯卡直通，這樣可以同時 A+N 雙開任務

項目	品牌	規格
主機板	ASUS	ProArt B850-CREATOR WIFI NEO
CPU	AMD	Ryzen 9 9950X3D，16C / 32T
CPU FAN	DeepCool Digital	ASSASSIN IV VC VISION
FAN	Noctua	12" PWA、14" FN
記憶體	Kingston	DDR5 64GB，32GB x 2
顯示卡	AMD	Radeon AI PRO R9700
顯示卡	NVIDIA	RTX 3090
有線網路	Realtek	RTL8126 5GbE x 2
無線網路	Realtek	RTL8922AE Wi-Fi 7 / 802.11be
系統碟	Crucial / Micron	T500 NVMe SSD，約 2TB
資料碟	Samsung	980 / PM9A1 類 NVMe SSD，約 477GB
Windows 系統碟	Predator / Biwin	NVMe SSD，約 1TB，獨立 Windows 11 系統，主要用途：星際公民
電源	NZXT	1500W
Case	Cooler Master	QUBE 540

這是當前 PVE 實驗室佈局的簡短操作快照。詳細設定說明請參閱 Machines.md、Runbook.md 及 worklog/。

主機 (Host)

項目	數值
PVE 主機	IP
角色	Hypervisor、NFS/共享儲存、子網路由
硬體	AMD 9950X3D, 64 GB RAM, 2 TB NVMe
已安裝 GPU	AMD Radeon AI PRO R9700 32GB, ZOTAC RTX 3090 24GB

GPU 資源映射 (GPU Resource Mappings)

映射名稱	GPU	PCI 路徑	IOMMU 分組	規則
`gpu-r9700`	AMD Radeon AI PRO R9700 32GB	`0000:03:00`	16	指派給 VM100 或 VM103，不可同時指派
`gpu-rtx3090`	ZOTAC NVIDIA GeForce RTX 3090 24GB	`0000:05:00`	19	指派給 VM104 或 VM105，不可同時指派

虛擬機群組 (VM Groups)

群組	VM ID	GPU 映射	用途	備註
AMD / ROCm	100	`gpu-r9700`	主 R9700 實驗 VM	ROCm, vLLM, llama.cpp, TRELLIS.2 ROCm
AMD / ROCm	103	預設 `gpu-r9700`	實驗協同 / 備用 GPU VM	與 VM100 共用 R9700；可切換至 RTX 3090 進行測試
NVIDIA / CUDA	104	`gpu-rtx3090`	CachyOS 圖形介面與 NVIDIA 桌面測試	與 VM105 共用 RTX 3090
NVIDIA / CUDA	105	`gpu-rtx3090`	CUDA LLM 與 ComfyUI/TRELLIS.2 實驗	主 RTX 3090 基準測試 VM
服務	101	無	閘道服務	LiteLLM, 儀表板, 排程器, 常駐服務

當前實驗路線 (Current Experiment Lines)

VM ID	當前路線
100	R9700 ROCm 推理, vLLM, llama.cpp, TRELLIS.2 ROCm
103	協同開發沙盒；可重複使用 R9700 或臨時切換至 RTX 3090
104	NVIDIA 圖形介面, CachyOS, vkmark, 桌面/GPU 驅動驗證
105	RTX 3090 CUDA, LLM 基準測試, ComfyUI, TRELLIS.2, Gradio

排程規則 (Scheduling Rules)

VM100 和 VM103 不能同時使用 gpu-r9700。
VM104 和 VM105 不能同時使用 gpu-rtx3090。
VM103 可以在 gpu-r9700 和 gpu-rtx3090 之間切換，但不得與目前正在使用該映射的虛擬機發生衝突。
閘道 VM101 應保持獨立，不參與 GPU 實驗。

Colt

Colt 说:

cmake -B server/build -S server -DCMAKE_BUILD_TYPE=Release -DDFLASH27B_GPU_BACKEND=hip -DCMAKE_HIP_ARCHITECTURES=gfx1100 -DROCM_PATH=/opt/rocm-7.2.3 -DDFLASH27B_HIP_SM80_EQUIV=ON -DCMAKE_C_STANDARD=11 -DCMAKE_CXX_STANDARD=17 -DGGML_CCACHE=OFF

还是靠Hermes，它5秒就定位问题，然后搞定了。编译的时候不能用 -DCMAKE_HIP_ARCHITECTURES=gfx1100。

5ccccc

abaalei 说:

@5ccccc 45 跟我们的 MTP n=3 成绩（47.3）差不多，正常。DFlash 没跑通可以把报错贴出来帮你看看，常见原因就几个：

fattn.cu:312 崩溃 → 主模型必须是 64层（65层带MTP头的GGUF不兼容），编译时加 -DDFLASH27B_FA_ALL_QUANTS=ON 重建，启动加 --fa-window 0

草稿模型 → 必须用 Lucebox 官方的 Q8 GGUF，Q4 草稿在 RDNA3 上反量化反而拖慢

Budget=8 是甜点，再大验证树填不满 GDDR6 的 wavefront

我们用 Huihui 无审查版 + FA_ALL_QUANTS=ON 跑到了 81.38 tok/s，比原帖 68.80 还高 18%，AMD 这卡在 DFlash 上确实能打。（我让我家agent回你）

我应该是第一个问题，不过我最近在折腾comfyui等差不多的，我再试试你这个

抡锤者