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

[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，实际情况跟你说的不完全一致——取决于版本差异：

1. dflash/ vs server/：我们两个目录都有，但 server/ 下没有 CMakeLists.txt，实际编译仍在 dflash/ 下正常进行。cd server 可能需要更新的 commit 才是强制的。
2. USE_HIP=ON 与 GPU_BACKEND=hip：我们 CMakeCache 里两个 DFLASH27B_USE_HIP:BOOL=ON 和 DFLASH27B_GPU_BACKEND=hip 并存，都能过。旧 flag 没有"不存在了"。
3. CMAKE_HIP_ARCHITECTURES vs DFLASH27B_HIP_ARCHITECTURES：我们用的前者，正常编译。
4. ROCM_PATH：-DROCM_PATH=/opt/rocm-7.2.0 也能用，不一定要环境变量。
5. FA_ALL_QUANTS=ON 已开。
6. 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 没跑通可以把报错贴出来帮你看看，常见原因就几个：

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

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

[abaalei]

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

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

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

[abaalei]

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

1. FA_ALL_QUANTS=ON 重新编译：我们开了这个之后 bench_he.py 从 68.80 直接升到 81.38 tok/s（+18%），因为 VEC kernel 能匹配到正确的量化模板了。
2. --ddtree-budget 8：RDNA3 上 budget 太大验证树反而拖慢，8 是甜点
3. API 模式 26 tok/s 偏低，检查有没有设 --tokenizer Qwen/Qwen3.6-27B，缺这个会导致 token 计数偏差
4. 中文对话接受率 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 没跑通可以把报错贴出来帮你看看，常见原因就几个：

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

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

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

[abaalei]

@Colt 哈哈，我家的agent也在帮你看问题，然后我滚下来之后就看到你解决了
然后反正token都耗了，我也扔出来给你、或者其他人参考下吧

这位老哥的 Segmentation fault 崩溃非常经典，在预填充阶段（[prefill] token-seg ubatch=32）直接炸在 libamdhip64.so 里面，说明他在编译或者环境加载上中了这四个暗箭：

致命诊断与排坑指南

1. 动态链接库“张冠李戴” ️ (最可能导致 segfault 的根源)

• 病因：看他的命令里写的是 LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH。但是他的编译参数指定的是 -DROCM_PATH=/opt/rocm-7.2.3！

• 危害：如果系统里的 /opt/rocm 是一个软链接，但其实指向了另外一个版本的旧 ROCm (比如 6.x 或 7.1)，那么运行 test_dflash 时加载的动态库与编译时的头文件就会发生 ABI 冲突。只要跑 GPU 算子，必报 general protection fault 闪退！

• 解药：运行时必须显式指定与编译路径完全一致的 7.2.3 库文件目录：

  export LD_LIBRARY_PATH=/opt/rocm-7.2.3/lib:$LD_LIBRARY_PATH

2. 去掉“毒药参数” -DDFLASH27B_HIP_SM80_EQUIV=ON 🧪

• 病因：这个参数是用于把 NVIDIA Ampere (SM80) 的指令在 AMD 硬件上做等效处理的。但在我们 7900 XTX (Navi 31 / gfx1100) 这种消费级显卡上，ROCm 7.2 自身的 HIP 编译器其实已经能非常优秀地进行原生编译了。盲目开启 SM80 转换，反而容易在 GPU prefill 跑算子时产生不兼容的硬件指令。
• 解药：在 7900 XTX 纯 A 卡环境的编译中，直接把这个参数去掉！

3. 显式开启全量化，且必须彻底清除缓存 🧼 (我们踩出来的超级大坑)

• 病因：他用的是 Q4_K_M 这种 K-quant 模型。如果 DFlash 编译时缺省没有开启所有的 KV-quant 模板，计算注意力时就会找不到匹配，要么直接 abort，要么因为 fallback 到在 HIP 上极不稳定的 TILE kernel 导致 segfault！
• 解药：重新 cmake 时显式指定 -DDFLASH27B_FA_ALL_QUANTS=ON。而且最重要的一点：必须使用 --clean-first！如果直接 build，cmake 不会重编 HIP 核心，老代码还是会原地爆炸。

  • 正确的编译步骤：

    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_FA_ALL_QUANTS=ON
    -DCMAKE_C_STANDARD=11
    -DCMAKE_CXX_STANDARD=17
    -DGGML_CCACHE=OFF

    彻底清理并重编

    cmake --build server/build --target ggml-hip --clean-first -j$(nproc)
    cmake --build server/build --target test_dflash -j$(nproc)

4. 参数没有喂饱，换用环境变量卡死 ️

• 病因：看他的日志输出 [cfg] ... fa_window=2048 ...。这说明他在命令行传的 --fa-window 0 根本没有被解析成功！DFlash 还在用 2048 窗口，所以在 prefill 时发生了越界。

• 解药：在运行命令前直接用环境变量卡死它，最稳妥：

  export DFLASH27B_FA_WINDOW=0

  或者把命令最后的参数改成用等号连接：

  --fa-window=0

[abaalei]

@CS6
感谢大佬的安利！看着大佬的 Ryzen 9 9950X3D + R9700 32G + 3090 24G 豪华 PVE 实验室，我的眼泪直接从嘴角流了出来……（虽然这段是AI打的，但是完全说中了我的真心话，我在买7900xtx之前的这段时间，基本上把从mi50~4080super都意淫了一个遍，最后迫于压力只能选择7900xtx，毕竟目前加卡对我来说还只是玩具，不详版主那么厉害，都能拿来当生产力赚钱了）这套 A+N 双 VM 直通隔离和 gateway 独立调度的架构设计，简直是生产力用户的终极梦幻装！

关于 PVE 显卡直通方案，我之前在规划这台算力节点时也深度考虑过（我之前在HP Gen8也有玩过pve，但是目前对我来说不太合适），但结合我目前的硬件现状，最终还是选择了 Ubuntu 物理机直驱 + 进程分流 的软隔离路线。主要出于以下几点折腾痛点：

1. 双路 E5 的“单核瓶颈”与 NUMA 跨 Socket 延迟
   我的 CPU 是老旧的双路 E5-2682 v4，这代 Broadwell 核心的单核性能放到今天真的非常弱（主频低、单核 IPC 差）。跑大模型推理时，尤其是 DFlash / llama.cpp 的 Prefill 预填充阶段，对 CPU 单核性能和内存延迟极其敏感。如果走 PVE 虚拟化，在弱鸡单核上再剥离一层虚拟化损耗，再加上双路 NUMA 架构下虚拟机跨物理 CPU 调度的延迟，很容易在 Prefill 阶段被卡死，把 GPU 的高速带宽白白浪费掉。

2. X99 主板的 IOMMU 分组玄学
   华南这类寨板的 ACS 隔离和 IOMMU 划分往往非常狗血，经常会把 PCIe 插槽和板载 SATA、USB 控制器划分在同一个 Group 里，强行直通可能需要打 pcie_acs_override 内核补丁，稳定性难以保障（我们昨晚刚在华南 X99-6Plus 上翻过车。把 7900 XTX 塞进 5 槽（CPU0通道），系统加载后，板载网卡和 3 槽的 2.5G 独立网卡（RTL8125，插在pciex8插槽）直接物理掉线（PHY 灯全灭）。最后根本跑不通，只能退回折腾了5小时，最终在加 pcie_aspm=off 并写 systemd 脚本开机强行重载 r8169/r8125 驱动才把网卡拉起来。这种寨板在 PCIe 分配和硬件兼容性上全是玄学，玩 PVE 直通随时都会面临 Host 彻底失联的灾难，所以只能物理机直驱加 pm2 分流软隔离了……）。

3. 物理机层面的“软分流”隔离 ️
   好在双路 X99 最大的优势是 PCIe lanes（通道数）多到用不完。目前我的 7900 XTX 和 3080 Ti 都跑在全速槽上。在软件层面：
   • 大模型推理：走 ROCm 后端，ROCm 天然就不认 NVIDIA 显卡，所以大模型推理自动锁死在 7900 XTX 上，吃满 24G 显存。
   • 视频后处理 / 变声 (VoxCPM)：我直接在 pm2 启动脚本里用 CUDA_VISIBLE_DEVICES 将 3080 Ti 隔离出来专门处理。
     通过 pm2 进程管理，基本做到了“物理不拆卡，环境不污染，带宽不冲突”，算是压榨这台老 X99 主板剩余价值最省心的路子了。

顺便同步一下进度，我用 bench_he.py（10 HumanEval）在 DFlash 完整编译（FA_ALL_QUANTS=ON + --fa-window 0）下，跑 Huihui 真无审查 Q4_K_M 模型，7900 XTX 实测已经飚到了 81.38 tok/s！（在我的另一个贴上发了，虽然上下文只有32K）物理通道和驱动潜力几乎被榨干了。

大佬的那块 AI PRO R9700 32GB 实在太香了，32G 显存跑 vLLM 的 KV cache 简直可以横着走，未来如果有什么好玩的工作流或测试数据，求大佬多发帖分享，让我也饱饱眼福！

[Colt]

@abaalei

我是昨天git clone的最新版本，编译的时候不能用
DCMAKE_HIP_ARCHITECTURES=gfx1100
换成
DDFLASH27B_HIP_ARCHITECTURES=gfx1100 编译就ok了。

但是我bench速度只有不到50t/s，还不如llama.cpp+Vulkan。还在研究怎么进一步优化。

[abaalei]

@Colt 你看看我另外的这个贴 https://lcz.me/topic/501/lucebox-dflash-huihui-7900-xtx-上真-无审查-极速推理完全折腾纪实/29

我昨晚又调了一下参数，下面是agent给你的总结

分享一下针对单卡 7900 XTX 跑 Qwen3.6-27B（DFlash 投机推理）的最新极限调优成果！昨晚经过反复压榨，成功把生成速度推上了新高峰：

7900 XTX 单卡 DFlash 实测成绩：

• 平均生成速度 (Decode MEAN)： 84.47 tok/s（在 HumanEval 10-prompt 串行高压测试下跑出，单题峰值突破 108.05 tok/s）
• 平均投机接受长度 (AL)：6.29（接受率约 40.8%）

️ 终极黄金启动参数：

bash
python3 scripts/server.py
--target '/mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf'
--draft models/dflash-draft-3.6-q8_0.gguf
--budget 8
--max-ctx 32768
--fa-window 0
--cache-type-k q8_0
--cache-type-v q8_0
--no-mmap
--tensor-split 0
--tokenizer Qwen/Qwen3.6-27B

核心调优心得（无痛白嫖 4% 速度的秘密）：

1. 压榨 KV Cache 带宽（关键！）：显式加上 --cache-type-k q8_0 和 --cache-type-v q8_0 后，虽然在 GPU 内部多了一步反量化计算，但由于量化让 KV 缓存的数据量直接减半，极大地缓解了 RDNA3 架构在投机树匹配时的显存带宽压力。实测速度从默认 F16 状态下的 81.19 tok/s 直接飙升到了 84.47 tok/s！而且在 32K 极限上下文下能省下一半的 KV 显存，极大幅度降低了 OOM 的风险！
2. 配合 --no-mmap：在 Linux 原生 ROCm 驱动下，关闭内存映射可以避免文件 I/O 阻塞首字加载，对于首字延迟（Prefill）有可见的加载优化。
3. 配合 --tensor-split 0：强制绑定单卡槽位算子，防止并发时发生莫名其妙的 CPU 回退（Fallback）。

[Colt]

此主題已被删除！