X99（BD3） DDR3 四通道 + 7900 XTX 24G：Strata 跑 Qwen3.8-Flash-Next 無審查版 IQ3_XXS 實測（131K 上下文 / int8 KV / MTP / 解碼 65–75 tok/s）
-
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_xxsAPI http://10.42.0.109:8080/v1（LAN 監聽 0.0.0.0）＋ Tailscale100.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之後緊接著missing ...gguf→ 是路徑問題不是網路問題。修法：--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 3276867.5 1229 1280 ＋ --conversation-cache-mib 819270.7 1203 1270 ＋ --pool-workers 1568.1 1229 1280 ＋ --spec 667.1 1226 1276 ＋ --kv-resident 6553668.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 四通道平台）。
-
-
-
-
我也是ddr3 pve里的Ubuntu 也能到70多了 参数优化下 就一下从50上到70
