RX 7900 XTX 24GB 跑 125B MoE：X99 舊平台的 Strata 實測（prefill 934–1,483 t/s、decode 60–81 t/s，含失敗與回滾）

硬件：Xeon E5-2686 v4（36 threads，無 AVX-512）＋ RX 7900 XTX 24GB ＋ 62 GiB DDR3-1866 ECC REG
底板：HUANANZHI X99-CD3 GAMING V2.1（dmidecode 實測，最大 128GB）
引擎：Strata 0.1.45.3｜模型：Qwen3.8-Flash-Next（125B MoE，IQ3_XXS）
測試日期：2026-10-20 至 10-21｜全部數字為本機實測；引用社群數據逐項標來源

---

0. TL;DR

項目	開始	調完
Prefill（32K prompt）	506 t/s（--prefill auto）	1,483 t/s
Prefill（12K prompt）	~850	934–952 t/s
Decode（暖機）	34.2 t/s	59.9–81 t/s
專家駐留槽（IQ3_XXS）	9,549	10,325
量化	Q2_0（權重 37.6GB）	IQ3_XXS（權重 47.0GB）

最有效：--prefill auto:32768（506→878，+73%）、STRATA_ROUTE_TAIL_SKIP=7（冷啟 decode 34.8→51.3）、五個 prefill-path env（19K +50%）、--short-read 512 ＋ --pool-affinity auto（32K +20%）。
最反直覺：--resident-experts 在 Q2_0 完全無效，換 IQ3_XXS 後 +46%。
總花費：零採購，全部用現有硬件。

數字口徑：本機實測。短期冷啟與暖機差異可達 ±10–20%，所以每個數字都是同條件跑兩次以上；「+X%」指同條件 A/B，不是跨 prompt 長度的比較（第 6 節分開兩張表）。

---

1. 為什麼要試 125B MoE

原本跑 llama.cpp 的 27B dense：prefill 807 t/s、decode 57.9 t/s，質素夠用但已到頂。

Strata 的做法是專家串流：只常駐熱門專家於 VRAM，其餘留在 RAM／SSD，按 routing 即時搬。所以 VRAM 需求由「整個模型」降到「熱專家集合」。

官方門檻（實測對得上）：VRAM ≥12GB、RAM ≥32GB、磁碟 ~80GB、CPU 要 AVX2。我這部機剛好卡在門檻：24GB VRAM、62 GiB RAM、2016 年的 Xeon。

---

2. 硬件（含查證方法）

項目	實測值	來源
CPU	Intel Xeon E5-2686 v4 @2.30GHz，36 threads／1 socket	lscpu
AVX-512	無（/proc/cpuinfo 冇任何 avx512*）	grep
RAM	62 GiB（可用 ~15 GiB、buff/cache 51 GiB）	free -g
RAM 模組	32GB DDR3 1867 MT/s，Hynix HMT84GL7AMR4C-RD，4Rx4 ×2	dmidecode -t 17
底板	HUANANZHI X99-CD3 GAMING V2.1，最大 128GB	dmidecode -t 2/16
GPU	RX 7900 XTX 24GB，0000:09:00.0 16.0 GT/s ×16（Gen4，無降速）	sysfs

兩個實測陷阱：

1. DMI 只報到 1 條 RAM，OS 實見 62 GiB（即實際 2×32GB）——這塊 Huananzhi 板韌體描述不全，dmidecode 要同 free 對照。
2. prefill 不是純 GPU 工作，是 CPU＋GPU 混合（專家搬運、routing、冷專家在 CPU 上算）。所以本機天花板主要由 CPU 單核決定。

---

3. 模型檔案與口徑（先講清楚，免得數字對不上）

同一量化有兩個「大小」，網上文章經常混用：

量化	shard1（transformer 權重）	shard2（n-gram 表）	合計下載
Q2_0	37.62 GB	28.80 GB	66.42 GB
IQ3_XXS	47.04 GB	28.80 GB	75.84 GB
IQ3_S	54.80 GB（官方）	28.80 GB	83.60 GB

以上 shard1／shard2 為本機 du -b 實測（Q2_0、IQ3_XXS），IQ3_S 取官方 docs/MODELS.md。

對購買 RAM 的意義：

• 佔 RAM＋VRAM 的主要部分是 shard1（37.6／47.0／54.8 GB）
• shard2 是 28.8 GB 的 n-gram 表，可以放 SSD 用 mmap 讀，不需要全部駐留
• 所以「62 GB RAM 夠不夠」要看你講的是哪個數：以 shard1 計 IQ3_XXS 47.0GB 很寬鬆；以合計 75.8GB 計就要靠 mmap

本機實測：跑 IQ3_XXS 時 OS 層 RAM 使用 41–43GB（Q2_0 同樣 41–43GB），與「shard1 ＋ cache」相符。

---

4. 安裝：六個會撞到的坑

按官方流程 setup.sh --backend hip --model <quant> --data-dir <dir> --port <port>，實測撞到以下六個。

坑 1：cmake 連結失敗（strata-vision）

relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object

setup.sh 跑到 275/275 步死在 strata-vision 連結階段。
解法：在該 build 目錄的 CMakeCache.txt 設 CMAKE_EXE_LINKER_FLAGS:STRING=-no-pie，再單獨 cmake --build . --target strata-vision -j 18，然後重跑 setup.sh。

坑 2：系統 ROCm 太舊，且會靜靜回落

系統只有 ROCm 7.2.4，hipBLASLt 冇 fallback path，部分 GEMM 直接失敗。

做法：裝 TheRock preview（rocm 7.10.0a20251120）入 venv，不覆蓋系統：

export LD_LIBRARY_PATH=$VENV/lib/python3.12/site-packages/_rocm_sdk_libraries_gfx110X_dgpu/lib:$LD_LIBRARY_PATH

ROCM_PATH 指向不存在的路徑（/opt/rocm-nonexistent）強制使用 venv wheels；export HIP_PLATFORM=amd 否則 cmake 報 Unexpected HIP_PLATFORM。

最陰險的一點：不帶 LD_LIBRARY_PATH 直接跑 server.py，引擎會無聲無息用回 /opt/rocm-7.2.4——不報錯、不 crash，只是慢。所以驗證要看 runtime，不是 build log：

grep -o '/[^ ]*libhipblaslt[^ ]*' /proc/$(pgrep -f serve/server.py)/maps | sort -u

見到 venv 內那條路徑才算成功。這一步實測令 prefill 由 400–475 升到 502–504 t/s。

注意：這證明「載入了哪個函式庫」，不等於證明所有速度改善都由它造成。跨版本要有受控測試（本機只做了單向驗證）。

坑 3：綁 0.0.0.0 被拒絕

[strata] a non-loopback bind requires an inference API key

只綁 127.0.0.1 不需要 key；要給區網用就要在 config 加 32 hex api_key。

坑 4：--vision 食 2–3GB VRAM

純文字用途直接刪走 --vision（--vision no 不支援）。另外開 vision build 會撞同一個 PIE 連結錯誤，修法同坑 1。

坑 5：一張卡只可以有一個引擎

舊 llama.cpp 未停會撞：

cudaMalloc(...) for the weight arena failed (out of memory): 1238 MiB of 24560 MiB VRAM free

本機用兩支腳本處理：start-strata.sh <port>、stop-strata.sh --restore（後者會起回 llama.cpp 並等 /health）。

坑 6：模型下載與 config 陷阱

setup.sh 只認 ~/Strata-data/models/<MODEL>/ 內的原始檔名；已下載過的模型要先 ln -f hardlink 進去，否則會重新下載 60–70GB。另外新 config 不繼承舊設定，換模型要重新加齊 host、reasoning_effort、reasoning_budget_tokens。

---

5. 量化怎麼揀：升量化反而更快

量化	權重（shard1）	官方評級	我的實測
Q2_0	37.6GB	良好／最快	prefill 400–475（3.2K）、decode 40（冷）–100（熱）、RAM 41–43GB、六題 6/6
IQ2_XS	39.2GB	更好	未測
IQ3_XXS	47.0GB	很好	prefill 502–1,483、decode 59.9–81、六題 6/6
IQ3_S	54.8GB	最好（≈原模型）	未上（本機 62 GiB 會緊）

Q2_0 六題全對，但 prefill 只有 400–475 t/s，比 27B dense 的 807 更慢。
原因不是「細模型快」這種直覺，而是 2-bit 專家在 AVX2 CPU 上 dequantize 效率差：熱專家上 GPU，冷專家要在 CPU 解包。

換 IQ3_XXS 之後：prefill 502–504、短答 decode 85–94（暖），RAM 需求仍然是 41–43GB。

結論：24GB VRAM 直接由 IQ3_XXS 起步；Q2_0 只適合 RAM 真的很緊（<48GB）。64GB+ RAM 可以考慮 IQ3_S，但質素差距我未實測（社群說只比最輕檔慢約 10%）。

---

6. 量測方法（唔講方法，數字冇意義）

• Prefill 一定要連 prompt 長度：32K → 1,483 與 7.5K → 611 是同一個引擎，短 prompt 天生慢（expert cache 冷、只跑一兩 chunk）
• Decode 分冷啟／暖機：冷啟（引擎剛起）與暖機（同 session 第二次之後）可以差一倍
• 短答／長答分開：短答看 tok/s，長答看完成時間
• 質素：固定題組，每次改設定都重跑；PF flags 會改 rounding，輸出不再 byte-identical，所以質素題不是可選項
• 每項至少兩跑：同一設定兩次冷啟實測可差 44.6 vs 54.6 t/s（±10%），單跑差異 <25% 一律當噪音

工具：streaming Python bench（量 TTFT 與 tok/s）＋ curl /v1/chat/completions 讀 timings。

---

7. 調優（A/B 與整體歷程分開）

7.1 同條件 A/B（每次只改一項，重啟後測）

改動	前	後	判定
--prefill auto:32768	506	878（+73%）	保留
STRATA_ROUTE_TAIL_SKIP=7	冷啟 decode 34.8	51.3	保留（剔除測試：暖機 51.0→48.1，效果確認）
五個 prefill-path env	19K ~850／39K ~850	1,275（+50%）／1,192（+40%）	保留
--short-read 512 ＋ --pool-affinity auto	32K 1,192／12K 847	1,436（+20%）／934–952	保留
--kv-resident 32768	槽 9,549、命中 87.3%	10,325、96.2%（暖 decode 69.2）	保留
--resident-experts（IQ3_XXS）	暖 decode 35、命中 74.8%	51（+46%）、87.8%	保留
--vram-reserve-mib 1536（原 700）	VRAM 餘 650MiB，觸發 paging、速度掉到個位數	1,432MiB，穩定	保留
--spec-min-p 0.7、--adapt-async 1	—	+4%／adapt 2.84→0.38 ms/window	保留（社群數據，本機未獨立 A/B）

五個 prefill-path env（來源：GitHub issue #2274 ＋ PR #3436）：

STRATA_PF_FUSED=1            # prefill 融合 kernel
STRATA_PF_GEMM=1             # prefill 走 GEMM
STRATA_PF_SWITCH_MIN_T=4096  # <4096 token 不走新路徑
STRATA_HIP_WMMA=1            # HIP WMMA 指令
STRATA_PA_FAST=1             # paged-attention 快速路徑

驗證 env 真的進了引擎進程：

tr '\0' '\n' < /proc/$(pgrep -f serve/server.py)/environ | grep STRATA_

7.2 噪音（測過，差異在量測漂移內）

• --pool-workers 16 vs 9：暖機 69.2 vs 65.2／78.8；同一設定兩次冷啟已差 ±10%，判定為漂移，保留 9
• 關 vision：prefill 878 → 879、decode 無變化
• --spec 3（社群量到 −3.8%）／--kv k8v4（社群報不穩）：我未獨立測

7.3 穩定後整體基線（現用配置，非單項 A/B）

prompt	prefill（t/s）	decode 暖機（t/s）
7.5K（session 第一發）	611	44.7
12K	934–952	59.8
15K	1,169	62.2
24K	1,436	77.2
32K	1,483	59.9

這張表是「累積調優後」的整體表現，不能當成單一參數的效果。單項效果看 7.1。
短 prompt 天生慢（expert cache 未熱），所以 611 與 1,483 不可直接比較。

專家駐留槽 10,325；arena 33,650 MiB、expert cache 17,145 MiB（/metrics 實測）。

---

8. 失敗與回滾（本節最有參考價值）

8.1 --ple-io ram：prefill 暴升，decode 死

把 PLE 表（27GB）搬入 RAM：冷 prefill 3,453 t/s，但冷 decode 15.3 t/s。對話式使用會等到死，已回滾。
適合場景：一次性讀大量文件、不追求回覆速度。（參數出處：社群 topic/2224，配合 128GB RAM 用出 22→65 t/s）

8.2 --resident-experts：Q2_0 無效，IQ3_XXS 有效

Q2_0：prefill 502（零改善）、暖機 decode 34.6 → 回滾。
IQ3_XXS：暖機 decode 35 → 51（+46%）、命中率 74.8% → 87.8% → 保留。
教訓：參數效果依量化而變，換量化之後之前否決過的 flag 要重測。

8.3 --kv-resident 131072（全 KV 駐留）：專家槽被搶

設定	專家槽	32K prefill	冷啟 decode
32768	10,325	1,436	59.8
131072	9,612	1,423	50.9

→ 回滾 32768。KV 全駐留換走 713 個專家槽，得不償失。（社群 issue #3383 用 131072 只得 7,831 槽，方向一致）

8.4 專家槽數字要講清楚是哪個量化

本機 Q2_0 時期可放 14,042 個專家槽；IQ3_XXS ＋ --kv-resident 32768 是 10,325（加 kv-resident 前為 9,549）。
同一篇文章出現兩個數不是矛盾，但必須標明時期與配置，否則讀者無法比較。

8.5 社群實測過的負面結果（引用社群：issue #2523）

--kv k8v4 不穩、--spec 3 比預設 −3.8%、--adapt-every/decay/swaps 無額外增益。

8.6 其他兩個會浪費時間的坑

• vision build 連結失敗：同坑 1，-no-pie 解決
• 靜默回落舊 ROCm：見坑 2，調完參冇反應先 ldd／/proc/*/maps 確認

---

9. 與同型號社群對照

對照對象	硬件	Prefill	Decode
社群 R9700 32GB（引用社群）	32GB ＋ 12700K／7900X3D	1,158–1,191	61.7
社群 issue #2274（7900XTX）	24GB ＋ 較新 CPU ＋ PF env	16K 1,848／32K 2,093	未報
社群 topic/2298（7900XTX 單卡）	24GB	—	中位 117
我（7900XTX 24GB）	24GB ＋ E5-2686 v4	19K 1,275／39K 1,192	59.9–81

目前結果支持的解釋（不是已被證實的定論）：

1. VRAM 容量限制專家駐留：24GB 只放得落 10,325 槽（Q2_0 時期為 14,042），3.2K prompt 時約 18% 專家工作要交 AVX2 CPU（Q2_0 時期量測）
2. CPU 單核較慢：12700K／7900X3D 單核約 E5-2686 v4 兩倍以上，而 prefill 是 CPU＋GPU 混合負載

未做的對照（要講清楚，否則就是過度推論）：

• 同一部機、同一腳本、只換 VRAM 駐留策略的受控測試
• 同一模型同一引擎、跨 CPU 平台的對照

可以肯定的部分：加 RAM 不會提升 prefill 上限（本機 Q2_0 與 IQ3_XXS 的 RAM 使用都是 41–43GB，速度差異來自量化與參數，不是 RAM 總量）。

---

10. 質素實測（範圍與限制）

每次改配置都重跑同一組題：

題型	答案	結果
時鐘 3:15 夾角	7.5°
3 紅 2 藍抽兩紅	3/10
17×23	391
86.5K 字文件＋「正式 vs 二手報價」陷阱（6 題）	全中	6/6

IQ3_XXS 跑 86.5K 字：6/6、單次 call 111 秒、prefill 544 t/s（6.2K prompt）、decode 42–61。

這組測試的局限（老實講）：

• 只覆蓋數學、概率、長文引用，未覆蓋程式碼生成、指令遵從、多輪一致性
• PF flags 會改 rounding，輸出不再 byte-identical，所以「六題過」只代表基本能力未退化，不代表整體質素等同
• 要比較兩個量化，應該同題目、同生成參數、多次重複，再比整體結果

另外（27B 上的實測，非 Strata）：reasoning_effort 由 xhigh 降到 medium，token 少三成而質素不變；關掉思考反而答錯邊界題（時鐘題答 75 而非 7.5）。

---

11. 結論

適合

• 有 24GB 卡 ＋ ≥64GB RAM，想用 125B 級質素
• 主要做長文件／長對話（prefill 1,200–1,483 很夠用）
• 接受 decode 60–80、短對話第一發慢
• 願意花一兩晚調參、自己 build

不適合

• 追求 1,000+ 穩定 prefill（要 32GB VRAM 或更快 CPU）
• 要 vision（食 2–3GB VRAM，專家槽直接縮）
• 同時要出片／跑其他 GPU 工作（一張卡一個引擎）
• 只要「裝完即用」

下一步（未做，屬推論）

1. 加 RAM 到 128GB → 上 IQ3_S（質素優先），速度不會提升
2. 換 CPU 平台（12700K／7900X3D）→ prefill 有機會翻倍，但我未做同機對照
3. 加第二張 24GB 卡 → 專家槽翻倍，decode 受惠（要先解決 RAM）

---

附錄 A：現用設定

--prefill auto:32768
--spec 4  --spec-min-p 0.7
--kv int8  --kv-resident 32768
--max-context 131072
--vram-reserve-mib 1536
--conversation-cache-mib 4096  --conversation-cache-slots 4
--expert-cache auto
--resident-experts
--adapt-async 1
--pool-workers 9
--short-read 512
--pool-affinity auto
（無 vision）

env（7 個）：

STRATA_HIPBLASLT_TUNING=<hipblaslt tuning txt>
STRATA_ROUTE_TAIL_SKIP=7
STRATA_PF_FUSED=1
STRATA_PF_GEMM=1
STRATA_PF_SWITCH_MIN_T=4096
STRATA_HIP_WMMA=1
STRATA_PA_FAST=1

附錄 B：啟動／回滾紀律

1. LD_LIBRARY_PATH 指向 venv 內 ROCm 子目錄；起機前 ldd engine/strata | grep /opt/rocm 自檢
2. 停機腳本要順手起回原本的 llama.cpp 並等 /health
3. 升級前保留舊引擎：mv 不要 rm，回滾就是 mv 返
4. 只綁 127.0.0.1 不需要 api_key；綁 0.0.0.0 要自己生成 32 hex key

參考

• Strata repo（Niko1221/Strata）；官方 DETAILS.md／MODELS.md／INSTALL.md
• GitHub issue #2523（7900XTX、IQ3_S 調優）
• GitHub issue #2274 ＋ PR #3436（prefill-path env）
• lcz topic/2032、2189、2224（安裝與極致優化）、topic/2046（同款 CPU）、topic/2084（IQ3_S vs IQ3_XXS）、topic/2298（7900XTX 單卡 decode）

---

後記：最花時間的不是調參，是量測紀律——同一設定跑兩次可以差 20%，所有比較都要固定 prompt、固定題組、分冷啟暖機，每次只改一個變量。文中每個本機數字至少跑兩次；引用社群數據一律標明來源，未做的對照也明寫未做。