抄作業抄得很順利

X99 DDR3 四通道 + 7900 XTX 24G：Strata 跑 Qwen3.8-Flash-Next 無審查版 IQ3_XXS 實測（131K 上下文 / int8 KV / MTP / 解碼 65–75 tok/s）

格式照壇上 1987 / 2109 的寫法：只寫這台機器的配置、踩過的坑、驗證到哪一步。

一、硬體與前提

項目	值	是否影響結論
GPU	AMD RX 7900 XTX 24G（Navi31 / gfx1100）	是，必須 gfx1100
CPU	Intel Xeon E5-2673 v3 @ 2.40GHz（Haswell，12C/24T，只有 AVX2）	影響解碼，見 §5
記憶體	128GB DDR3-1867 四通道（4×32GB，ECC）	見 §5，這是本機瓶頸
系統盤	HP SSD S700 500GB（SATA）	模型 71G + pack 1.5G，容量要算進去
作業系統	Ubuntu 26.04.1 LTS（kernel 7.0.0-38）
ROCm	10.0.0（amdrocm metapackage，裝在 /opt/rocm）	setup 偵測到系統 ROCm 就不抓 TheRock wheels
引擎	Strata 82f46a8（2026-10-06）
權重	SC117/…abliterated-GGUF 的 IQ3_XXS 純文字版，約 76 GB	無審查（abliterated）版
模型 ID	swift-1.5-iq3_xxs
API	http://10.42.0.109:8080/v1（LAN 監聽 0.0.0.0）＋ Tailscale 100.124.7.105
上下文	131072 tokens；KV int8；--spec 4；MTP runtime

三個必要條件（照壇上共識，本機全中）：

1. 記憶體 ≥ 96GB：本機 128GB，載入後 RAM 約 47–52/123 GB，VRAM 25.7/25.8 GB。
2. 已有 /opt/rocm 且含 hipcc / libhipblaslt.so：本機是 amdrocm 10.0，setup 直接複用，省 10GB 下載。
3. 單卡獨佔：Strata 吃滿 24GB 顯存，不能跟 ComfyUI 並行（見 §6）。

二、會卡住的坑（★ 本機實際踩過的）

坑 1 ★ --gguf-dir 指向預設路徑時 setup 會自己把目錄改名。
[ok] model files moved to .../data 之後緊接著

→ 是路徑問題不是網路問題。修法：--gguf-dir 指向它不會動的目錄，用軟連結放模型。
坑 2 ★ 模型檔名兩邊不一致（最耗時）。
setup 期望 Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-0000N-of-00002.gguf；HF 實際是 IQ3_XXS/…-abliterated-IQ3_XXS-0000N-of-00002.gguf（多子目錄＋abliterated）。下載後重命名對齊，並校驗位元組數（斷點續傳可能造成尾部偏差）：

• shard1 39,771,812,960 / shard2 36,056,143,040 / mmproj 907,542,944 / mtp-q2_0 889,017,216
• head -c 4 <檔> | xxd 必須是 47475546（"GGUF"）
  坑 3：繞過 setup.sh 直接跑 setup.py → PEP 668 拒絕（externally-managed-environment）。 走 setup.sh，或手動建 venv（python3-venv 要先裝好）。
  坑 4：aria2 接手舊控制檔會重新驗證區塊。 本機 shard2 曾缺 1,233,037,287 bytes，aria2c 續傳時顯示已滿長度但內部約 9% 區塊要重抓——ETA 會跳，不是卡住。

三、啟動方式（本機用正式 unit，開機自啟）

壇上 1987 用 transient unit（systemd-run，不會隨開機自啟）。本機改成正式持久 unit /etc/systemd/system/strata.service：

ExecStart=/home/yuyen/Strata/.venv/bin/python /home/yuyen/Strata/serve/server.py \
  --engine strata --config /home/yuyen/Strata/strata-swift-iq3_xxs.json \
  --host 0.0.0.0 --port 8080
Restart=on-failure / TimeoutStartSec=1200

載入約 100 秒。config args 重點：--pack、--native/--ple-gguf 指 shard1、--expert-profile、--expert-cache auto、--prefill auto、--spec 4 --spec-min-p 0.5、--mtp .../mtp/rt、--max-context 131072、--kv int8、--kv-resident 32768、--conversation-cache-mib 8192（見 §5）。

四、驗證（2026-10-12，全部用引擎自己的計數器）

量測方法先講：必須讀引擎日誌每 request 的計數器，不要用 client wall time。 短 prompt 固定開銷佔大半、思考 token 會混進輸出速率，wall time 會量出假數字（本機曾因此誤量成 30 / 271 tok/s）。取 3 次中位數，run-to-run 約 ±10%。

指標	實測
解碼（短提示，中位數）	74.5 tok/s（80.0 / 74.5 / 64.2）
prefill @ 8k / 32k / 48k / 80k tokens	1237 / 1286 / 1242 / 1149 tok/s
解碼 @ 8k / 32k / 48k / 80k 上下文	51 / 61 / 74 / 64 tok/s（到 80k 都不明顯衰退）
VRAM / RAM	25.7 GB / 48 GB（不吃緊）
多輪對話提示重用	第 2 輪起 99.9% 重用（4078/4083 tok）

五、跟壇上 3900X 帖（2109）的落差 & 參數調校結論

落差來自硬體平台，不是設定。 2109 是 DDR4-3200 雙通道（實測 50.7 GB/s）＋ Ryzen 9 3900X；本機是 DDR3-1867 四通道 ＋ Haswell（只有 AVX2）。重新用引擎計數器量後，本機解碼 65–75、prefill 1100–1290，跟 2109 的 67.8 / 900–1330 幾乎一致。
參數 A/B（每組重啟服務、同方法量，跑完自動還原）——全部落在雜訊內：

參數組	decode	prefill 8k	prefill 32k
現行（基準）	74.5	1237	1286
＋--prefill 32768	67.5	1229	1280
＋--conversation-cache-mib 8192	70.7	1203	1270
＋--pool-workers 15	68.1	1229	1280
＋--spec 6	67.1	1226	1276
＋--kv-resident 65536	68.5	1230	1279

官方建議的 --pool-workers 12 --adapt-every 0 --pcie-frac 0 與 --mmap-experts --resident-cpu-experts 在 X99 DDR3 上反而更慢（解碼掉到 ~30），不要照搬到這平台。
唯一真正有感的優化：--conversation-cache-mib，但只在「多對話交錯」時。 模擬兩個對話 A/B 交錯問 7 輪：沒開時每輪整段重讀（0% 重用）；開了之後從第 3 輪起每輪重用整個前綴（~100%）。單一對話本來就 ~99.9% 重用、不需要旗標。本機常同時開多個 Hermes 對話打同一台，所以永久開著。

六、共用顯卡的注意事項

與 ComfyUI（:8188）共用 24GB VRAM，一次只能一個。 算圖前要 sudo systemctl stop strata 讓出顯卡；那時候接 Hermes 的 client 會自動退回雲端備援，不會斷線。

七、一句話總結

X99 DDR3 四通道 ＋ Haswell 這平台，跑無審查 IQ3_XXS 的解碼天花板就是 65–75 tok/s、prefill 1100–1290 tok/s，跟壇上 DDR4 機幾乎沒差；軟體參數已壓到頂，想再快只剩換硬體（DDR4 四通道平台）。