抡锤者

MSHAVL

@kk-hh 目前掛在我ai max395上切VRAM/RAM 64/64gb下用IQ4xs搭配dsh也非常舒服，＠41k上下文深度下pp200多/tg 20-30token/s開192k上下文，目前已經利用goal然後入睡前讓它大型專案開發，隔天早上起來收割。是確定可以做出前沿模型那種質量。但速度響應上就不苛求了。目前pp可能還有提升的空間應該會更好。
替代文字

MSHAVL

隨帖建議，可否開放會員朋友們的裝備登錄系統，還有技能登錄系統，如同網遊那樣大家使用什麼裝備學會什麼技能。如此一來站內就會生成一個有價值的資訊就是什麼設備主流或是開始遷移。什麼設備配什麼模型。功力如何若要防止洗文虛報設立個驗證機制。這樣登錄上也可以看自己從初出茅廬到決戰光明頂的一步步過程

MSHAVL

我是利用提示詞將鏡頭轉場的每一cut為一次生成，然後透過抽卡來快速過濾有問題的毛片，但就不適合一鏡到底需要依賴尾禎相接的片段了！

MSHAVL

算圖抽卡只要工作流定案，提示詞流水線就開工了，不太需要人介入，這邊的介入主要是有時間成本的任務例如一個小時後需要繳出的成果，如此一來整個選擇更偏向晚上睡覺時r9700替你流水線抽卡生片白天起來收割，而7900xtx更用在需要人機協作並且有時間壓力的任務上，剛好利用7900xtx的顯存帶寬跟27b的模型質量

MSHAVL

Qwen3.8-Flash-Next 180B 在 Strix Halo 單機:一個旗標換到 prefill +22%

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

一、硬體與軟體配置


CPU / iGPU	AMD Ryzen AI MAX+ 395 w/ Radeon 8060S(gfx1151),16C/32T
記憶體	128 GB LPDDR5X,BIOS 切 64/64(iGPU carve 64 GB,OS 可見 63.6 GiB)
OS	Windows 11 Home 26200
後端	Vulkan(AMD 專有驅動)
build	apepojken/llama.cpp `qwen4exp-spec-mtp` @ 843d575
模型	Qwen3.8-Flash-Next 180B-A6B,unsloth UD-IQ4_XS(87.3 GiB)
投機解碼	自編 MTP sidecar `mtp-ape-Q8_0.gguf`(4.14 GB)

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

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 固定生成量、全程記憶體取樣。

A/B 計時

記憶體取樣

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

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

深度掃描

prompt tokens	`-lm mmap` pp	`-lm dio` pp	Δ
9,815	200.01	260.01	+30.0%
40,477	171.09	190.70	+11.5%
80,943	—	164.53	—

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

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

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

項目	實測
`-ub 2048`	pp −3.3%
`--cache-ram` 加大	預設 8192 MiB 本來就在命中(41k 重送 269s → 34s,7.9×),16384 完全無差異
`-c` 減半	mmap 下看似 +7.9%,是記憶體壓力的假象;dio 下 c98304 反而略快
KV `q4_0` / `f16`	−2.5% / −4.7%,見上
MTP `n_max` 改值	3~6 之間無可測量差異,見下
`-sm row`	Vulkan 後端未實作 split buffers
`-sm tensor`	qwen4exp 的 GDN / hyper-connection / indexer 都不在切分邏輯的正規式裡
`--spec-type ngram-*`	`ngram-mod` 接受率全 0;`ngram-cache` 有 24% 接受率卻慢 34%
DFlash	Flash-Next 沒有對應 drafter(只有 Qwen3.8-27B / 3.6-27B / Coder-Next 有)

關於 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完成圖截圖

MSHAVL

無印或pro記憶體頻寬鳥樣!似乎只能看MAX或ultra

MSHAVL

@terry 说:

日常对话，问问代码应该问题不大，带宽天生残疾，跑Agent不太现实，但是可以跑122B Qwen，或许3.8更新的时候会有这个玩意。3.5的就挺好了，知识面大。跑Agent的话用35B A3B，体验不如27b。帖子质量很高，还是要实拍图，屏幕截图。

確實，一開始用AI max+395時很有耐心都可以等。購入5090才被行雲流水的tps炸了腦。玩到現在越能體現這句話：「可跑不代表質量好，質量好不代表跑得快，跑得快不代表撐的久」。在眾多知識類AI媒體中只有版主能讓我駐足。這邊也小小的分享自身的經驗。

MSHAVL

Strix Halo（gfx1151）本地部署 DeepSeek V4 Flash — 環境、失效、可行與技術總結

引言：從 Loose Box 影片到真實部署

Loose Box 專案的影片與官方技術文件展示了令人印象深刻的成果：同樣的 Strix Halo（gfx1151）、同樣的 128GB LPDDR5X，用客製 ROCmFPX 量化模型 + DSpark 投機解碼，decode 達到 32.0 tok/s，sparse prefill 達到 ~250 tok/s。

我在同樣的硬體（Asus ROG Flow Z13 GZ302EA，Ryzen AI Max+ 395，Radeon 8060S，128GB）上用 同樣的 Loose Box 專案（Claude Code 協助部署）實作，結果有幾個關鍵差異，值得完整記錄。

核心結論（先看這裡）：

decode 29.7 tok/s，已達官方紀錄的 91%，對話式使用體驗良好。
prefill 與官方差距大，原因不是設定錯誤，是量化版本不同：
- 官方 250 tok/s sparse prefill 建立在 ROCmFPX 客製量化（平均 2.88 bits/parameter）+ 專屬 kernel 之上。
- 我用標準量化版本，exact prefill 實測 20–32 tok/s，與官方 exact prefill 數據（22.5 tok/s）吻合——這才是 Strix Halo 沒有客製量化下的真實表現。
因 RTX 5090 eGPU 在 Linux 下無法成功啟動，不再嘗試跑客製量化版本。
接 agent 前務必算清楚： 如果你的系統提示超過 2K tokens，exact prefill 會花 1–3 分鐘。

以下從完整技術紀錄中節錄 Strix Halo 部署 DS4 的環境、失效、可行、技術總結。

環境

項目	規格
機器	ASUS ROG Flow Z13 (GZ302EA)
SoC	AMD Ryzen AI MAX+ 395 (Strix Halo)
iGPU	Radeon 8060S, gfx1151 (RDNA 3.5), 40 CU
記憶體	128 GB LPDDR5X 統一記憶體 (~270 GB/s)
SSD	WD_BLACK SN770M 2TB (DRAM-less, HMB)
OS	Ubuntu 26.04 LTS, kernel 7.0.0-14
ROCm	7.1.1 (Ubuntu 內建)
模型	DeepSeek V4 Flash, 95.3 GiB, 256 experts MoE

BIOS carve 調整

Strix Halo 的 BIOS 把 128 GB LPDDR5X 切成「RAM 側」與「VRAM carve」兩塊。部署 DS4 必須把 carve 調到最小（512 MB），讓 ROCm 改用 GTT 借主記憶體。

如果 carve 還在 96/32 就開 Ubuntu： 系統 RAM 只剩 32 GB，DS4 的 95.3 GiB 載不進去。GTT 是 pinned、OOM killer 殺不掉 → 整台凍結，不是乾淨報錯。

失效路線

路線	結果	原因
`amdgpu.gttsize` 不調	載入失敗	iGPU 預設只能借用約一半系統記憶體（實測 61 GiB）
`ttm.pages_limit` 未與 `gttsize` 對齊	載入失敗	TTM 另外卡住
`amd_iommu=on iommu=pt`	decode 從 29.10 掉到 0.60 tok/s（1/48）	統一記憶體分頁遷移每次都要過 IOMMU 位址轉換
earlyoom 預設值	模型載入完成就被殺	預設「可用記憶體低於 10% 就動手」，模型正常就佔 88%
`/opt/rocm/lib → /usr/lib/x86_64-linux-gnu` symlink	cmake 找不到 amd_comgr	`amd_comgr-config.cmake` 從自身剝 4 層推算前綴，symlink 層數不對

可行設定

GRUB 開機參數（關鍵）：

amd_iommu=off amdgpu.gttsize=126976 ttm.pages_limit=32505856 ttm.page_pool_size=32505856

gttsize=126976 (MB) = 124 GiB
ttm.pages_limit 必須與 gttsize 對齊（32505856 × 4KiB = 124 GiB）
驗證：dmesg | grep GTT 應出現 126976M of GTT memory ready

反直覺的發現：模型其實不住在 GTT 裡

ggml_cuda: device 0 integrated, alloc 94.9 GiB (> 45% of 124.9 GiB RAM)
           -> unified (managed) memory

mem_info_gtt_used  = 12,020 MiB    ← GTT 只用了 12 GiB
dflash_server RSS  = 99.7 GiB      ← 模型在一般系統記憶體

模型走 hipMallocManaged 統一記憶體路徑，124 GiB GTT 上限並不是實際約束條件。

Ubuntu 26.04 的佈局差異：

套件名稱：libhipblas-dev、librocwmma-dev（不是 hipblas-dev）
/opt/rocm 正確做法：sudo ln -sfn /usr /opt/rocm
rocWMMA 標頭不完整，必須手動從 GitHub rocm-7.1.0 branch 補上

earlyoom 修正：

EARLYOOM_ARGS="-m 3 -r 3600 --avoid '(^|/)(dflash_server|llama-server)$'"

實測效能

指標	數值
decode（有投機解碼）	29.7 tok/s（命中率 0.957）
prefill（644 tokens）	20.2 s（31.9 tok/s）
prefill（10,422 tokens）	527.5 s（19.8 tok/s）
溫度	從 60°C 衝到 91–94°C，長 prefill 可達 101°C

比對 Loose Box 官方數據：

項目	Loose Box 官方	我實測
decode（有投機解碼）	32.0 tok/s	29.7 tok/s（91%）
decode（無投機解碼）	25.3 tok/s	~20 tok/s
exact prefill（短 prompt）	22.5–23 tok/s	31.9 tok/s
exact prefill（8K tokens）	16.46 tok/s	19.8 tok/s（10K）
sparse prefill（8K tokens）	251.79 tok/s（ROCmFPX 客製）	未用客製量化

️ 因 RTX 5090 eGPU 在 Linux 下無法成功啟動（Blackwell + USB4 + Linux CUDA 運算必崩，見第二篇），未能嘗試在 5090 上跑 Loose Box 客製量化版本。

技術總結

記憶體很夠，GTT 設定正確就能載入接近 100 GiB 的模型。
decode 表現超出預期， 29.7 tok/s 已達 Loose Box 紀錄的 91%，對話式使用體驗良好。
prefill 是硬傷， LPDDR5X ~270 GB/s vs 960 GB/s，參數調不動。接 agent 前先算清楚系統提示要多久才能消化完。
散熱是真實限制， 平板形態的機身在持續滿載下必然降頻，長時間使用考慮外接散熱。
IOMMU 開著不能用， 會讓 decode 掉到 1/48。
sparse prefill 的 250 tok/s 需要客製 ROCmFPX 量化 + 專屬 kernel， 標準版本做不到。

MSHAVL

Asus ROG Flow Z13（Strix Halo）透過 USB4 外接 RTX 5090 eGPU，Linux 下 CUDA 運算必崩

️ TL;DR（先看這裡）

Blackwell（RTX 5090）+ TB4/USB4 eGPU + Linux = 任何 CUDA 運算都會讓整機瞬間斷電。

這是 NVIDIA GSP 韌體 RPC 心跳在隧道延遲下逾時，NVIDIA 尚未修復。

換驅動版本無效。同一組硬體在 Windows 下完全正常。

確認方式只要 30 秒： 接上 → 載入驅動 → 跑任何 CUDA kernel。活著 = 修好了，斷電 = 還沒。

在那之前，雙開機用 Windows 是完全合理的答案，不是妥協。

環境

項目	規格
主機	Asus ROG Flow Z13 (GZ302EA)
SoC	AMD Ryzen AI MAX+ 395 (Strix Halo)
USB4 埠	USB4 40Gbps（PCIe 隧道封裝）
eGPU	GIGABYTE AORUS RTX 5090 AI BOX (TB5)
OS	Ubuntu 26.04 LTS, kernel 7.0.0-14

症狀

GPU 正常初始化、nvidia-smi 閒置時完全正常、模型能載入 VRAM。

但任何 CUDA 運算都會讓整機瞬間斷電 —— 無 kernel panic、無 Xid、無 AER、SysRq 無反應，journald 連一行都來不及寫。

決定性的二分測試

我寫了一支 CUDA 程式把「PCIe 傳輸」與「GPU 運算」分開：

測試	結果
PCIe 傳輸 150 GB 來回（64 MiB → 4 GiB 五級）	全數存活，實測 0.78 GB/s
GPU 運算核心	立即整機斷電，無一次例外

傳輸沒問題，運算必死。 這一刀切下去，後面所有的猜測都可以停止。

已排除的假設（每項都有實測數據）

假設	排除依據
記憶體不足 / OOM	崩潰時 available 120 GiB
與 iGPU 模型共存衝突	主模型未執行仍崩潰
amdgpu SVM 分頁風暴	相關 kernel worker 計數全程 0
eGPU 盒經 USB4 反向供電	主機使用自己的充電器
顯卡功耗尖峰	崩潰時僅 85W（上限 575W）
PCIe 錯誤 / 掉線	無 AER、無 Xid、無 Link Down
過熱	GPU 43°C
DRAM-less SSD (HMB)	零 NVMe 錯誤

真正的原因

這是 NVIDIA 的已知且未修復問題：

核心錯誤：

GPU1 _kgspRpcRecvPoll: LibOS heartbeat timed out
kgspInitRm_IMPL: SET_GUEST_SYSTEM_INFO failed

Blackwell 把大量工作交給 GPU 上的 GSP 韌體，主機與 GSP 之間靠 RPC 溝通並有心跳逾時。

透過 TB4/USB4 隧道時延遲過高 → 心跳逾時 → 硬鎖。

上游歸納的模式：TB5 主機正常，TB4/USB4 主機必崩。

Z13 的埠是 USB4 40Gbps，AORUS 盒是 TB5 —— 協商後降為 USB4，正中此模式。

這也解釋了為什麼同一組硬體在 Windows 下可以正常推論：驅動架構不同，沒有這條 RPC 路徑。

試過但無效的所有方法

嘗試	結果
`nvidia-driver-595-open`	崩潰
`nvidia-driver-595`（專有版）	無法使用 —— GB202 強制要求 open kernel modules
`nvidia-driver-610-open`（論壇唯一有成功先例）	崩潰 ×2
`pcie_ports=native pcie_aspm=off pcie_port_pm=off`	無效
`pci=assign-busses,realloc,hpmmiosize=...`	弄壞了 iGPU
換 USB4 埠	PCIe 鏈路改善，仍崩潰

️ 坑：pci=assign-busses 會重新編號整台機器的 PCI 匯流排

從 eGPU 論壇抄了一組核心參數一次全加，結果：
iGPU 位址 c4:00.0 → 06:00.0
amdgpu 載入了但綁不上去
rocminfo 找不到 gfx1151
GTT 消失
在一台整個 LLM 部署都靠 iGPU 的機器上，我把 iGPU 弄壞了。

教訓：PCIe 參數要一次只加一個，每次都驗證既有裝置仍正常。

附帶發現

USB4 埠的選擇會影響 PCIe 鏈路

Z13 有兩個 USB4 埠，對應不同橋接器，鏈路品質差很多：

埠	下游鏈路
`00:01.2`	2.5 GT/s (Gen1)
`00:01.1`	16.0 GT/s x4 (Gen4)

同一台機器、同一條線、同一個盒子，換個孔差 6 倍。

如果你的 eGPU 慢得莫名其妙，先試另一個埠。

每次硬鎖後，eGPU 盒必須實體斷電

單純重開機救不回來。未斷電就重開時：

nvidia-smi          → 讀得到基本資訊
cudaSetDevice()     → CUDA-capable device(s) is/are busy or unavailable
                    → 而且一試就再次弄掛驅動

️ 驅動卡死後不要重複執行 nvidia-smi —— 每次都會多一個 D state 且 kill -9 無效的進程，nvidia_uvm 引用計數只增不減。

給後來者的建議

如果你想用 Strix Halo + USB4 + RTX 5090：

Windows 側： 正常可用，沒問題。
Linux 側： 目前（2026-08）任何 CUDA 運算必崩，NVIDIA 尚未修復。
確認方式只要 30 秒： 接上 → 載入驅動 → 跑任何 CUDA kernel。活著 = 修好了，斷電 = 還沒。
在那之前，雙開機用 Windows 是完全合理的答案，不是妥協。

如果你要在 Z13 上玩 eGPU（不管用不用 AI）：

兩個 USB4 埠鏈路品質差 6 倍，務必接 00:01.1 那側（16 GT/s x4）。
PCIe 核心參數要一次只加一個，不要一次全加。
每次硬鎖後，實體斷電 eGPU 盒再重開。
驅動卡死後不要重複執行 nvidia-smi。

抡锤者

MSHAVL

帖子