DFlash Hermes Server — 現況紀錄

核心需求（不可談判）

• Context: 32k 先跑通，後上 64k
• 用途：Hermes agent 接 Telegram 任務請求
• 速度目標：decode 45 tok/s 以上
• 舊腳本 q4_64k_telegram.sh 可 30-40 tok/s，DFlash 要超越它
• 8k/16k context 不算完成

硬體

• GPU: AMD Radeon RX 7900 XTX 24GB，ROCm/HIP，gfx1100 (RDNA3)
• ComfyUI 在 port 8188（第二張 GPU 路徑），不能動
• 現有 production fallback: q4_64k_telegram.sh，不能覆蓋

目前主腳本

/home/jaran/dflash_oai_v2.sh

現在的參數：

• Binary: /home/jaran/src/lucebox-hub/server/build-hip-7900xtx/dflash_server
• Target: Qwen3.6-27B-Q4_K_M.gguf（14.99 GiB GPU）
• Draft: dflash-draft-3.6-q4_k_m.gguf（Q4，request-scoped）
• --max-ctx 32768
• --fa-window 2048
• --cache-type-k tq3_0 --cache-type-v tq3_0
• --chunk 256
• --ddtree --ddtree-budget 8
• --draft-residency request-scoped
• --default-max-tokens 1024 --hard-limit-reply-budget 1024
• env: DFLASH27B_PREFILL_UBATCH=512

目前狀態：能跑，但完全不可用

觀察到的 log 數字（tq3_0 KV + Q4 draft）

prefill=9.0s  for 5219 tokens
decode=1.6s  speed=13.1 tok/s
total: 10.8s for 21 tokens output → 1.9 tok/s overall

• 9 秒 silent prefill → Hermes/Telegram 等不了，直接當掉
• Decode 本身 13 tok/s，離 45 tok/s 目標還差 3 倍多
• 腳本沒 crash，是從 Hermes bot 角度「沒回應」

速度比較

• 預期（文章 bench）：68 tok/s（test_dflash + 短 HumanEval prompt）
• 現在 dflash_server：13 tok/s decode，580 tok/s prefill（9s/5k tokens）
• 差距：prefill 慢 5x，decode 慢 5x

已試過、失敗的方向

tq3_0 → q4_0 KV（我的改法，已還原）

• 目的：以為 tq3_0 會強制 CHUNKED FA kernel（無 MMA），換 q4_0 開 MMA
• 結果：速度完全沒變（prefill 仍然 9.0s，decode 仍然 13.1 tok/s）
• 副作用：第 2 次 request OOM（ggml_gallocr_reserve_n_impl: failed to allocate 480.95 MiB）
• 結論：KV quantization 類型對速度無影響；q4_0 KV 比 tq3_0 多 0.5 GiB，讓第 2 request 的 gallocr 配不到
• 已還原回 tq3_0

fa-window 0 → 2048

• 沒有解決 OOM（Q8 draft 還是爆）
• 但有助省顯存（codex 改的，保留）

Q8 draft → Q4 draft

• 解決了 [unpark] draft restored OOM
• 代價：draft quality 降，acceptance rate 只有 10-23%，avg_commit 2.5-4.75

已知但未解的問題

問題 1：prefill 為何慢 5x？

• 5219 tokens / 9s = 580 tok/s，預期應該 3000+ tok/s
• --chunk 256 傳給 ServerConfig，但 qwen35 backend 的 do_prefill 讀的是 DFLASH27B_PREFILL_UBATCH env var
• DFLASH27B_PREFILL_UBATCH=512 在 script 裡已設，backend 實際用 512 token/chunk
• --chunk 256 和 DFLASH27B_PREFILL_UBATCH 是否同一件事、--chunk 到底控制什麼，尚未查清

問題 2：gallocr OOM 在第 2 request

• 只有 q4_0 KV 會出現，tq3_0 KV 不會
• 480.95 MiB 配置失敗 (ggml_gallocr_reserve_n_impl)
• 原因不明——VRAM 估算應該夠，但實際不夠

問題 3：decode 為何慢 5x？

• 每個 spec-decode step 約 183ms，bandwidth-limited 應該 15ms
• GPU 是否在 high performance mode？card1 是否是正確的 DRM card？尚未確認
• 可能是 ROCm 小 kernel dispatch 累積 overhead

尚未測試但可能有效的方向

1. pflash mode（在 server_main.cpp 裡有 --pflash 選項）

   • 是一種「persistent flash prefill」，可能完全換掉 chunked prefill path
   • 需查 pflash 在 qwen35/32k context 的 VRAM 需求和 API

2. DFLASH27B_PREFILL_UBATCH 調大（如 1024 或 2048）

   • 減少 GPU dispatch 次數：5219/1024 = 5 次 vs 5219/512 = 10 次
   • 代價：gallocr scratch 增大，需確認 tq3_0 KV 下能否容納

3. GPU 電源模式確認

   • 腳本用 card1，但 7900 XTX 可能是 card0
   • 若 power level 沒設到 high，decode 會慢數倍

4. prefix cache

   • 目前 --prefix-cache-slots 0（關閉）
   • 啟用後可快取 system prompt + tools（~2000 tokens），下次 request 只 prefill 新 tokens
   • 代價：每個 slot 佔 ~full KV size VRAM

2026-06-12 最新修改（已 rebuild）

Fix 1：F16 → Q8_0（lazy rollback path）

• 檔案：src/qwen35/qwen35_target_graph.cpp line 364
• migrate_prefill_cache 的 ssm_intermediate 用 F16，而 eager path 用 Q8_0
• 修正後節省 ~540 MiB VRAM

Fix 2：DFLASH27B_DRAFT_CTX_MAX=512 env var

• 新增 env var 支援到 qwen35_backend.cpp init() 開頭
• 根本原因：draft_ctx_max=4096（預設）→ feature_mirror cap=4096 → 400 MiB VRAM
• 更重要：每個 decode step，draft 要處理 min(committed, 4096) tokens
  • 5000+ token Hermes 系統提示後，draft 處理 4096 tokens 每步
  • 文章 HumanEval bench = 300 tokens（短 prompt）→ 13.6x 差距
  • draft_compute: 4096 token = ~160ms >> verify 52ms，這是 183ms/step 的根本原因
• 設 512：feature mirror 400 MiB → 50 MiB，draft_compute ~20ms
• 預估：total step ~82ms，avg_commit ~4.5 tokens → ~55 tok/s

Script 變更

• 加了 DFLASH27B_DRAFT_CTX_MAX=512
• 已換 Q8 draft（上次就換了）

2026-06-12 Fix 3：fattn.cu:312 crash root cause + fix（已 rebuild）

Root cause

• do_ar_decode 在 temperature>0（needs_logit_processing()=true）時被呼叫
• do_ar_decode hardcode with_mask=false、n_tokens=1
• 對 tq3_0 KV：win_len_padded = round_up(win_len, 256) → always divisible by 256
• can_use_vector_kernel = K->ne[1]%256==0 = true → dispatch VEC kernel
• HIP: tq3_0 excluded from VEC (#ifndef GGML_USE_HIP) → GGML_ABORT at line 312

為何 Request 1 不 crash

• Request 1 有 tools → temperature=0 → needs_logit_processing()=false → 走 spec-decode
• Spec-decode verify/replay n_tokens≥2 → need_mask = (n>1) = true → CHUNKED → OK

為何 Request 2 crash

• Request 2 無 tools，temperature>0（預設）→ AR decode
• do_ar_decode n_tokens=1, with_mask=false → VEC → CRASH

Fix（已應用到 qwen35_backend.cpp）

1. init() 第 232 行：detect tq3_0 KV → cfg_.kq_stride_pad = 256
2. do_ar_decode loop：ar_with_mask = (cfg_.kq_stride_pad > KQ_MASK_PAD) → with_mask=true for tq3_0
3. do_ar_decode loop：mask 填充 code（build_causal_mask + ggml_backend_tensor_set）

2026-06-12 Tool call 調查與修復（進行中）

問題現象

• Tool call 失敗：server log tool_call parse failed; suppressing buffered tool text bytes=11
• 11 bytes = <tool_call>（token 248058），model 生了 <tool_call> 後立刻 EOS
• 26 tokens 總輸出，finish=stop，0 個 tool call

發現的根本原因

原因 1：--fa-window 2048 截斷 attention 視窗（最關鍵）

• Hermes 請求 prompt_tokens=6025，--fa-window 2048 → decode 時只看最近 2048 tokens
• 系統提示（含 tool format 指令）在 token 0~4000，完全在 window 外
• Model 想調 tool 但看不到格式指令 → 生 <tool_call> 後不知道放什麼 → EOS
• Fix: --fa-window 0（無限窗口，完整 attention）

原因 2：tool_memory miss → 歷史 tool call 渲染為空（次要）

• Server 重啟後 in-memory tool_memory 清空
• normalize_chat_messages 對 role=assistant + tool_calls 的訊息查不到原始文字
• RESPONSES format 有 fallback，chat format 沒有 → 歷史 tool call 變成空 content
• Model 看到「空的 assistant turn + tool_response」，context 不完整
• Fix: http_server.cpp 加 fallback：從 tool_calls JSON 重建 <tool_call> 格式

原因 3（原始）：tq3_0 KV + fattn.cu:312 crash（已修復）

• temperature>0 時走 AR decode，tq3_0 觸發 VEC kernel，HIP 不支援 → ABORT
• Fix: kq_stride_pad=256 + ar_with_mask=true + mask 填充

目前修改清單

作者建議參數（已對齊）

• 模型：Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf
• draft：dflash-draft-3.6-q8_0.gguf（Q8）
• --fa-window 0
• --ddtree-budget 8
• KV cache：q4_0（default，無 tq3_0 的 HIP 問題）
• 不設 HSA_OVERRIDE_GFX_VERSION（ROCm 自動識別 gfx1100）

目前狀態

• 服務重啟中，等待測試 Hermes BSB tool call

2026-06-12 速度分析（第二輪）

測量基準

[spec-decode] tokens=84 time=3.938s speed=21.33 tok/s steps=25 accepted=60/400 (15%) avg_commit=3.36
prefill=12.0s decode=3.9s(21.3tok/s)

目標：45+ tok/s，目前差 2.1x。

模型架構（從 GGUF metadata 讀出）

qwen35.block_count: 64
qwen35.full_attention_interval: 4      ← 每 4 層才有一個全 attention 層
qwen35.embedding_length: 5120
qwen35.ssm.inner_size: 6144
qwen35.ssm.state_size: 128

• 64 層中：16 層 = 全 attention（KV cache + FlashAttn）
• 48 層 = SSM（DeltaNet / gated_delta_net）— 無 KV cache，純矩陣遞推

Draft 模型 (dflash-draft-3.6-q8_0.gguf

• block_size: 16 — 每步生成 16 個投機 token
• block_count: 5 — 5 層 attention-only 模型（很小）
• n_target_layers: 5 — 從 target 取 5 層 hidden state 作輸入

瓶頸根本原因：SSM 串行 kernel

spec-decode verify 步驟呼叫 verify_batch()（qwen35_dflash_target.cpp:27），其中：

• build_target_step(... capture_delta_intermediate=false ...)
• → parent_ids = nullptr（非 DDTree tree 路徑）
• → cap_ptr = nullptr（無 rollback capture）

這滿足啟用 chunked DeltaNet 的全部條件：

// qwen35_target_graph.cpp line 800
if (!parent_ids && !cap && n_seq_tokens > 1) {
    if (const char * s = std::getenv("DFLASH27B_CHUNKED")) use_chunked = true;
}

但預設關閉，原因：

"port produces correct shape but slightly wrong final state, causing AL degradation and loopy output."

為何 DFLASH27B_CHUNKED=1 對我們是安全的

1. verify 的 state 不影響最終輸出：

   • snapshot_kv() 在 verify 前保存 SSM state
   • restore_kv() 在 verify 後立刻恢復（qwen35_dflash_target.cpp:107）
   • Replay 步驟重新跑接受的 tokens 來建立正確 state
   • → chunked verify 的 state 誤差從來不被保留

2. n_tokens=16 ≤ CS=64 → n_chunks=1 → 無跨 chunk 誤差：

   • chunked bug 發生在 n_chunks > 1（即 n_tokens > 64）時的跨 chunk state 傳播
   • 我們的 block_size=16 永遠只有 1 個 chunk，算法正確
   • 唯一影響：output logits 精度 → 接受率略降，但預計影響甚微

3. 「loopy output」 可能是在不同測試條件（n_tokens > 64 或沒有 restore）下觀察到的

DRM 電源模式確認

• card1（vendor=0x1002:0x744c，25.7 GB）= RX 7900 XTX #1 → power_dpm=high ✓
• card2（vendor=0x1002:0x744c，25.7 GB）= RX 7900 XTX #2 → power_dpm=auto（ComfyUI）
• HIP_VISIBLE_DEVICES=0 = card1 = DFlash 用的 GPU ✓
• ROCm: /opt/rocm → /etc/alternatives/rocm → /opt/rocm-7.2.0 → 一致，無 ABI 問題

Build 狀態確認（作者建議已對比）

速度優化行動項

已套用：DFLASH27B_CHUNKED=1（dflash_oai_v2.sh）

• 預期效果：SSM 2-3x 加速 → step time 157ms → ~55ms
• 預期 tok/s：3.36 avg_commit / 0.055s = ~61 tok/s（超過 45 目標）
• 無需 rebuild，直接重啟生效

待測試：啟動後觀察

[spec-decode] tokens=? time=? speed=? avg_commit=?

預期 speed > 45 tok/s，avg_commit 可能略降但 step_time 大降。

仍未做的優化（備用）

1. 前綴快取 --prefix-cache-slots 4：

   • 快取系統提示 ~3000 tokens → prefill 12s 降到 ~6s
   • 不影響 decode 速度，但降低 Hermes 感受的首 token 延遲
   • 先測 CHUNKED 效果，如果 prefill 仍是瓶頸再考慮

2. 增大 DFLASH27B_DRAFT_CTX_MAX（例如 1024）：

   • draft 看更多 context → 接受率提升
   • 代價：draft 步驟略慢
   • 目前 CHUNKED 應已足夠，此項備用

不要再做的事

• 不要再調 KV quantization 當速度 fix（已確認無效，SSM 75% 主導）
• 不要把 max-ctx 縮到 8k/16k
• 不要動 q4_64k_telegram.sh
• 不要動 ComfyUI port 8188

药方一：检查并修正运行时的 LD_LIBRARY_PATH（最有可能的罪魁祸首！）

• 问题所在：Colt 编译时使用的是 -DROCM_PATH=/opt/rocm-7.2.3。但是他运行时的命令行里写的却是 LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH。

• 根因：如果他系统里的 /opt/rocm 软链接指向的是旧版本（比如 ROCm 6.x 或其他版本），那么程序在运行时就会加载错误的 libamdhip64.so，导致 ABI 不兼容，进而在 prefill 阶段发生核心转储崩溃！

• 解决方案：让他把运行时命令中的 /opt/rocm/lib 明确修改为与编译一致的绝对路径：

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

药方二：去掉不兼容的英伟达等效编译参数 -DDFLASH27B_HIP_SM80_EQUIV=ON

• 问题所在：他在 CMake 命令中显式开启了 -DDFLASH27B_HIP_SM80_EQUIV=ON。
• 根因：这个参数是强行把英伟达的 SM80（Ampere）架构指令转换映射到 AMD 架构。在 7900 XTX (Navi 31 / gfx1100) 的 ROCm 7.x 原生环境下，开启此转换极易生成不兼容的显卡底层硬件指令，导致 prefill 崩溃。
• 解决方案：重新编译时，直接删掉 这个参数，走纯原生的 HIP 编译。

药方三：强力建议开启 -DDFLASH27B_FA_ALL_QUANTS=ON 进行干净的重编

• 问题所在：如果他没有显式开启这个参数（默认是 OFF），DFlash 在面对 Q4_K_M 这种量化格式的 KV Cache 时会匹配不到对应的 VEC dispatch 模板，导致闪退或崩溃。

• 解决方案：让他清理编译缓存（这步极度重要，ROCm 编译必须 --clean-first），并用下面的命令重新编译：

  1. 彻底清理旧编译缓存

  rm -rf server/build

  2. 干净地进行全量化重新编译

  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 test_dflash --clean-first -j$(nproc)

额外避坑提醒：
运行 test_dflash 时，他的 --fa-window 0 可能会因为参数解析问题被丢弃。建议他把命令行参数改写成带等号的 --fa-window=0，或者干脆在运行前加一句：
export DFLASH27B_FA_WINDOW=0

啟動參數：

• --fa-window 0
• --max-ctx 16384
• --cache-type-k q8_0
• --cache-type-v q8_0
• draft: dflash-draft-3.6-q8_0.gguf
• Hermes 預設 max_tokens = 2048

實際啟動：
/home/jaran/src/lucebox-hub/server/build-hip-7900xtx/test_dflash
/home/jaran/models/qwen36std/Qwen3.6-27B-Q4_K_M.gguf
/home/jaran/models/draft/dflash-draft-3.6-q8_0.gguf
--daemon
--max-ctx=16384
--fast-rollback
--ddtree
--ddtree-budget=8

補充：

• target loaded: layers [0,64)，不是 65 層
• GPU 是 7900 XTX 24GB
• fa_window=0 已確認生效
• q8_0/q8_0 已確認生效

Hermes 打進來後實際請求：

• prompt=5319
• n_gen=2048

結果：

• 直接在 do_prefill() OOM
• 還沒出第一個 token 就掛

log 關鍵行：

• [server] req=1 prompt=5319 n_gen=2048 attempt=1
• ROCm error: out of memory
• #11 dflash::common::Qwen35Backend::do_prefill(...)

如果你要更短版，也可以只貼這段：

我照你說的改成：
--fa-window 0
--max-ctx 16384
--cache-type-k q8_0
--cache-type-v q8_0
draft q8_0
Hermes max_tokens 2048

主模型是 64 層，log 顯示 layers [0,64)。
但 Hermes 第一筆請求 prompt=5319 / n_gen=2048 就在 do_prefill() OOM，第一個 token 都沒出來。

這樣你看還要再查哪個點？
折騰了兩天 出動 codex 跟cc都搞不定 ....心累 再拜託大神了
或是能提供64K上下文hermes能用速度又不錯的的啟動腳本給我 感謝

我今天的进展是终于能跑通 bench.py 了，之前都是2个failed。 解决方法是加一个--max-ctx 16384，而且速度在 45-69 之间。

但运行server还是不行。可能是版本问题，现在git clone下来的lucebox 已经没有server.py脚本了，而是编译的时候来一个target dflash_server。我尝试在64K上下文（配合hermes）下各种参数组合，最多聊到第二句就爆显存了，暂时无解，只能先用回llama.cpp。

我昨晚又调了一下参数，下面是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）。

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

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

关于 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 简直可以横着走，未来如果有什么好玩的工作流或测试数据，求大佬多发帖分享，让我也饱饱眼福！

这位老哥的 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 说:

@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等差不多的，我再试试你这个

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。

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

主機 (Host)

GPU 資源映射 (GPU Resource Mappings)

虛擬機群組 (VM Groups)

當前實驗路線 (Current Experiment Lines)

排程規則 (Scheduling Rules)

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

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。

几个技术建议：

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%+

期待你的调试结果！

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

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

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

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回你）

我用的 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 的改法在不同版本间不是唯一的。感谢补充！

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 原来的模型名


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