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 |
三個必要條件（照壇上共識，本機全中）：
- 記憶體 ≥ 96GB：本機 128GB，載入後 RAM 約 47–52/123 GB，VRAM 25.7/25.8 GB。
- 已有 /opt/rocm 且含 hipcc / libhipblaslt.so：本機是 amdrocm 10.0，setup 直接複用，省 10GB 下載。
- 單卡獨佔：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 四通道平台）。