結論先講:在 128GB 的 Ryzen AI MAX+ 395 上跑 180B-A6B,把 -lm mmap 換成 -lm dio,
prefill 從 171 提到 209 tok/s,載入時間從 111 秒降到 53 秒,tg 不變。
前提是 Windows 的 pagefile 初始值要調大。

一、硬體與軟體配置

模型本身的結構值得先記住,因為後面的優化跟它直接相關:

• 48 層 = 12 層 QSA(稀疏注意力,帶 indexer)+ 36 層 Gated DeltaNet(線性注意力,狀態固定大小)
• 512 experts / 10 active
• 一張 51.2B 參數的 n-gram / PLE 查表:per_layer_token_embd.weight,shape [160, 320001536],在 IQ4_XS 下佔 26.82 GiB
• 原生 262144 context

二、思維目標

一開始我在調的是運算面的旋鈕:-ub、-tb 執行緒數、KV 量化型別、投機解碼的 draft 深度、要不要移植上游還沒合併的 Vulkan FA 修正。

這些方向掃完之後,pp 仍卡在 170 上下。

轉折點是加上記憶體取樣之後看到的一行:

\Memory\Available Bytes = 0.29 GiB

不是 commit 快滿,是實體可用記憶體真的見底。 而且不論 context 開多大都會發生。

追下去才理解這台機器的記憶體模型:

iGPU carve 已配置    63.3 GiB    (carve 總量 64 GB)
行程私有記憶體峰值   70.99 GiB   (純 iGPU)
OS 可見實體 RAM      63.6 GiB

63.3 + 71 = 134 GiB,在一台 128 GB 的機器上。原因是 WDDM 對每一筆 GPU 配置都會在系統 commit 上保留等量額度,所以放進 carve 的 63 GiB 同時也向 63.6 GiB 的實體 RAM 記一筆。64/64 的切分讓兩邊剛好都貼死。

在這個前提下,-lm mmap 的問題就浮出來了:那張 26.8 GiB 的 engram 查表是 file-backed,它的檔案頁會把 standby list 吃光。模型在跟自己的 page cache 搶記憶體。

所以真正的目標從「怎麼算得更快」變成 「怎麼讓它不要在分頁」。

三、最佳化參數

llama-server \
  -m Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
  -dev Vulkan0 -sm layer -ngl 99 --fit off \
  -lm dio \
  --no-repack \
  -md mtp-ape-Q8_0.gguf -devd Vulkan0 -ngld 99 \
  --spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-p-min 0.75 \
  -fa auto -ctk q8_0 -ctv q8_0 \
  -c 98304 --ubatch-size 1024 -b 2048 \
  -t 2 -tb 8 \
  --parallel 1 --cont-batching --no-warmup

環境變數:

GGML_VK_VISIBLE_DEVICES=0
LLAMA_ARG_CHAT_TEMPLATE_KWARGS={"enable_thinking":false}

系統前提 —— 沒做這個,上面的組態會慢 9.4%:

pagefile 初始大小 32768 MB  ->  98304 MB
（系統內容 > 進階 > 效能設定 > 進階 > 虛擬記憶體 > 自訂大小 > 一定要按「設定」）

-lm dio 會把 commit 需求推到約 119 GiB。若 pagefile 初始值太小,Windows 得邊跑邊擴,commit 餘裕會壓到只剩 0.56 GiB,prefill 因此掉到 190.70。預先配置好之後是 208.65。

幾個參數的理由

• -t 2 -tb 8 — decode 只給 2 執行緒、prefill 給 8。CPU 使用率只有 8%,加執行緒是空轉搶 LPDDR5X 頻寬。-tb 12/16/20/32 全部更差。這一項在 41k 值 tg +40.7%。
• -ngl 99 --fit off — --fit on 會照 iGPU 回報的假 free 值(carve+shared 顯示 108 GiB)分配,配 -ts 時甚至直接放棄 fitting。
• --ubatch-size 1024 — 2048 實測 pp −3.3%。注意 -ub 和 -b 是兩回事,-b 不影響顯存。
• -ctk/-ctv q8_0 — q4_0 是 pp −0.9% / tg −2.5%,f16 是 pp −4.7% 而且在 98304 裝不下(37.4 + 44.3 > 63.3 carve)。q8_0 在這台機器上就是最佳解,沒有量化 KV 的 dequant 稅。
• --spec-draft-n-max 3 — 見下方「已排除」。

四、實測

協定:code prompt、每組獨立行程冷啟、ignore_eos 固定生成量、全程記憶體取樣。

Available Bytes 從 0.29 → 18.50 GiB,這是整個優化的關鍵指標。有趣的是 dio 讓行程私有記憶體反而增加 28 GiB(71.87 → 99.83,約等於 engram 的大小)—— 它把 engram 讀進私有記憶體而不是靠 page cache,分頁決策交回給 OS 的一般機制,結果是可用記憶體大幅回升。

載入時間 111s → 53s 也是同一個原因:mmap 要逐頁 fault,dio 是大塊循序讀。

深度掃描

淺 context 的增益反而更大。 直覺上 prefill 越短、engram 被查得越少,壓力應該越低;實際相反。推測 mmap 的逐頁 fault 是固定成本,在短 prefill 上佔比更高。

tg 幾乎不隨深度衰減:10k 23.99 / 41k 24.4–26.2 / 80k 23.53。

五、已排除的項目(附數字,省得別人重跑)

關於 MTP n_max:一個量測陷阱

我掃了 n = 2/3/4/5/6/8。在 temperature 0.7 下最佳是 n=4(tg 25.77)、最差是 n=5(20.97)。
換成 temperature 0 貪婪解碼重跑,最佳變成 n=5(23.53)、n=4 幾乎墊底。

兩個協定的最佳與最差完全對調,而貪婪那組自己的 pp 就在 196.9–205.2 之間跳(4.2%)。

結論是 n 在 3~6 之間沒有可測量的差異。 但更值得分享的是背後的原因:MTP 的 acceptance 取決於 draft 猜的 token 跟 target 抽到的 token 一不一致 —— 取樣一開,acceptance 就跟著隨機。實測 acceptance 會在 0.72–0.94 之間跳動,那不是模型特性,是取樣造成的量測誤差。

要比較投機解碼的參數,請務必用貪婪解碼 + ignore_eos 固定生成量,否則量到的是隨機數。

附1:量測方法

• 每組獨立行程冷啟,啟動前確認 llama-server 行程數為 0(用 Stop-Process,Git Bash 的 pkill -f 殺不掉 Windows 行程)
• mkdir 原子鎖確保同時只有一個 bench 在跑（模型佔 63 GiB，兩個實例會直接互相排擠）
• prompt 對齊的是 token 數不是字元數(程式碼 3.57 字元/token,散文 5.56,同字元數會差 50% token)
• 全程取樣 \Memory\Committed Bytes、\Memory\Commit Limit、\Memory\Available Bytes、行程私有記憶體
• prompt 最前面插 nonce,避免 prefix cache 讓 pp 造假

附2:

• 附上Pelican ride bicycle svg經典題＠dsh監控
  

• Deepseek Harness跑完畫面
  

• 最後svg完成圖截圖