抡锤者

@terry 明白的，我的数据都是实测的，只是测试过程跟文章都是ai写的而已

@kos or 好问题，我来逐一解答： 1. 无审查模型会不会"幻想然后直接Format"？ 不会。无审查（abliterated/uncensored）只是移除了模型输出层的拒绝机制（refusal suppression），不影响模型本身的底层行为控制。模型仍然有"对齐"（instruction following）能力，仍然会遵循你的指令。格式化硬盘这种操作需要明确的用户指令和执行环境配合，模型本身不会凭空产生这种越界行为。打个比方：一个有审查的模型就像戴着口枷——它连"可以这样做"都不会说；而无审查模型只是摘掉了口枷，你说什么它回应什么，但不会主动去做你没让它做的事。 2. 无审查会不会降低LLM的服从性（compliance）？ 恰恰相反，无审查通常提高服从性。有审查模型的"不服从"往往是因为安全过滤器（safety filter/SLMs）拦截了你合法的技术请求（比如写渗透测试脚本、分析恶意代码原理）。无审查模型会忠实执行你的所有指令，不会因为内容安全策略擅自拒绝。所以对技术用户来说，无审查模型的compliance是更高的。 3. 模拟对话差异 假设我问"如何从内存中dump出某个进程的数据？" 有审查模型会回答："抱歉，我无法提供可能用于非法目的的技术细节……" 无审查模型会直接回答：使用 /proc/pid/mem 或 ptrace 等系统调用……然后详细解释原理和限制，最后加上"这些技术仅用于合法的调试和逆向工程场景，请遵守当地法律法规。" 核心区别在于：无审查模型把你的主动判断能力放在第一位，有审查模型替你做判断。在技术讨论场景中，前者更有价值。 补充提醒：无审查模型仍然有"拒绝"能力——如果模型技能不足或不确定，它仍然会说不知道。去除的只是基于内容策略的硬编码拒绝。

@abaalei 你好啊 晚安喔, 我的cc努力了一天 把hermes調用工具修好了,但速度只有22左右,暫時修到這,,,對齊你給你的資訊後,他最後一次改的,調用工具又失敗了,等額度恢復再繼續折騰 ,分享我的進程 @colt 也同步給你喔 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 尚未測試但可能有效的方向 pflash mode（在 server_main.cpp 裡有 --pflash 選項） 是一種「persistent flash prefill」，可能完全換掉 chunked prefill path 需查 pflash 在 qwen35/32k context 的 VRAM 需求和 API DFLASH27B_PREFILL_UBATCH 調大（如 1024 或 2048） 減少 GPU dispatch 次數：5219/1024 = 5 次 vs 5219/512 = 10 次 代價：gallocr scratch 增大，需確認 tq3_0 KV 下能否容納 GPU 電源模式確認 腳本用 card1，但 7900 XTX 可能是 card0 若 power level 沒設到 high，decode 會慢數倍 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） init() 第 232 行：detect tq3_0 KV → cfg_.kq_stride_pad = 256 do_ar_decode loop：ar_with_mask = (cfg_.kq_stride_pad > KQ_MASK_PAD) → with_mask=true for tq3_0 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 填充 目前修改清單 檔案 修改內容 src/server/http_server.cpp chat format tool_memory miss fallback：從 JSON 重建 <tool_call> dflash_oai_v2.sh --fa-window 0、換 Huihui 模型、移除 --cache-type-k/v tq3_0、移除 HSA_OVERRIDE_GFX_VERSION src/qwen35/qwen35_backend.cpp Fix 3 tq3_0 fattn crash（kq_stride_pad + ar_with_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 對我們是安全的 verify 的 state 不影響最終輸出： snapshot_kv() 在 verify 前保存 SSM state restore_kv() 在 verify 後立刻恢復（qwen35_dflash_target.cpp:107） Replay 步驟重新跑接受的 tokens 來建立正確 state → chunked verify 的 state 誤差從來不被保留 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 精度 → 接受率略降，但預計影響甚微 「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_HIP_SM80_EQUIV OFF ✓ DFLASH27B_FA_ALL_QUANTS ON ✓ ROCm 版本 7.2.0（非 7.2.3 but same ABI）✓ LD_LIBRARY_PATH /opt/rocm/lib = /opt/rocm-7.2.0/lib 同一個 ✓ 速度優化行動項 已套用：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 大降。 仍未做的優化（備用） 前綴快取 --prefix-cache-slots 4： 快取系統提示 ~3000 tokens → prefill 12s 降到 ~6s 不影響 decode 速度，但降低 Hermes 感受的首 token 延遲 先測 CHUNKED 效果，如果 prefill 仍是瓶頸再考慮 增大 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

楼主讲的是粤语阿。。香港朋友

395来交作业，跟MTP比没有大的区别，两者速度相差在1~2t/s

@david-zhang 请问，你这个7900xtx 256k上下文方案能跑多并发吗？还是只能一个。如果不能，你推荐买哪个显卡可以跑多并发？谢谢

@pangfat [image: ebceb77c-7927-42ad-9595-269c97215b48.png]