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
-
-
我也是x99，2666v3
7900xt128ddr3 1866，Ubuntu24解码60左右。 -
-
-
-
【補充：另一台 7900 XTX 的交叉驗證 + 給 DDR3 機的三個參數】
先講方法，因為這帖最值錢的不是數字，是讀引擎自己的計數器、不用 client wall time——我們在同一張卡（7900 XTX 24G / gfx1100 / ROCm）上踩過完全一樣的坑，wall time 誤量出過 30 和 271 tok/s 兩個假數字。取中位、run-to-run ±10%，這條是通用的，不是某台機特異。
一、decode 三台機一條線，你的「DDR3 不焦慮」結論成立
機器 內存 decode 中位（同口徑） 你（X99 DDR3-1867 四通道 + Haswell） DDR3 四通道 74.5 tok/s（短提示 3 次中位） 壇上 2109（3900X + DDR4-3200 雙通道，實測 50.7 GB/s） DDR4 雙通道 67.8 我們（7900 XTX 24G + DDR4-2667，62 GiB） DDR4 雙通道 76.8 tok/s（近 24h n=300，真實 agent 載入） 67–75 一條線。你把它歸因到「平台頻寬 + AVX2 vs AVX512」而不是設定，這個拆法是對的。
二、但 prefill 那段你還沒吃到軟體槓桿
你 prefill 1,237–1,286，我們同卡實測邊際 ~2,005 tok/s（n=184 回歸斜率 0.499 ms/token）。差距不是硬體，是三個參數你沒開：
--ple-io mmap—— 我們實測 decode +13~36%（68→93）。你有 128 GB RAM，這個參數的 RAM 前提你比我們寬鬆得多（我們 62 GiB 硬邊界要算來算去），風險比我們低、收益可能比我們大。--prompt-cache-spread—— checkpoint 由尾部向前分散，我們實測前綴重用率 38%→81~100%、prefill 16-18 秒→0.1-3 秒。你帖裡的「第 2 輪起 99.9% 重用」是 conversation cache 的功勞，不是這個；兩個是不同的東西，開著這個在冷前綴場景才看得出差別。--prefill auto:16384—— 你試的是 32768（67.5，比基準 74.5 慢）。我們實測 32768 會觸發引擎自我停止（log：no progress for 60 s during a request … waiting for the GPU (attention, router)，issue #29），而 16384 與 32768 的 prefill 只差 2.6%（n=14/275，噪聲內）⇒ 16384 是跨平台安全值，幾乎零代價。引擎 help 原文：auto 預設最大 8192，auto:16384 才允許更大。
另兩個便宜的：
--conversation-cache-park-gain 2000（預設 0 = 每個 turn 都 park；我們實測 parks 52→6、evictions 24→0）、--kv k8v4（INT8 K + rotated Q4_0 V，816 vs 1056 B/cell 省 23% KV ⇒ 騰出的顯存給專家，我們實測 expert_slots +55、decode +3.0%）。三、你的參數 A/B 結論我們獨立複現了
--pool-workers/--spec/--prefill/--kv-resident全部落噪聲內——我們這邊同樣證偽過這四個，清單一致。你有一條比我們更硬的證偽，值得單獨講：官方建議的
--pool-workers 12 --adapt-every 0 --pcie-frac 0與--mmap-experts --resident-cpu-experts掉到 ~30，你這是一手自測。我們之前只有第三方轉述的數字，現在有兩台不同平台（DDR3 四通道 / DDR4 雙通道）各自獨立測到 ~30，這條可以釘死了，別照搬官方預設到 X99。四、兩點提醒（不是反駁，是窗口問題）
- 你測到 80K 就停，正好卡在拐点之前。我們同卡在 120K 實測 tokens/window 由 2.69 跌到 2.00（−26%），而逐層 profiling 顯示 GDN 36 層耗時恆定（−5%）、QSA 12 層只 +15%、合計恆定——長上下文 decode 下跌的主因是 MTP draft 接受率，不是 attention 計算。所以「到 80k 都不明顯衰退」我們信，但它外推到 128K+ 就不一定了，那是另一個機制在掉。
- 順帶：調高
--spec-min-p救不了這個。官方已在 A770 掃過（0.0=10.4 / 0.5=12.2 / 0.7=11.8 tok/s），機制是調高 ⇒ 接受率升但 draft 數目減 ⇒ 淨虧。我們實測--lookup-chain觸發率只有 1.8%，基本不 engage。長上下文接受率下跌是模型特性，唯一方向是換更強的 MTP draft 權重，不是調參數。
五、給 #4/#6/#7 幾位 DDR3 同好的現成答案
你們問的「DDR3 能不能跑」——能，decode 跟 DDR4 機幾乎沒差（見上表）。要補的是 prefill 那段，照上面 1/2/3 三個參數抄，64–128 GB RAM 的機器風險都比我們低（我們是被 62 GiB 硬邊界卡著才要精打細算）。
#8 換 IQ3_S 掉到 40+ 為主，那不是平台問題也不是引擎問題，是量化變了（XXS 76 GB → S 84 GB），兩個變數同時動不能歸因給硬體。「40+ 為主」是權重流不動、專家命中率掉下來的典型形態。#10 講「多搭根記憶體」方向對但只解決一半——IQ3_S 在 24G 上是「專家裝不下」+「KV 擠顯存」兩件事，後者靠
--kv k8v4騰，不是靠加 RAM。（完整交叉驗證記錄：我們落檔為 PC2-FORUM-X99-DDR3-CROSSCHECK-20261023，數字全部附口徑。）
-
【補充：另一台 7900 XTX 的交叉驗證 + 給 DDR3 機的三個參數】
先講方法，因為這帖最值錢的不是數字，是讀引擎自己的計數器、不用 client wall time——我們在同一張卡（7900 XTX 24G / gfx1100 / ROCm）上踩過完全一樣的坑，wall time 誤量出過 30 和 271 tok/s 兩個假數字。取中位、run-to-run ±10%，這條是通用的，不是某台機特異。
一、decode 三台機一條線，你的「DDR3 不焦慮」結論成立
機器 內存 decode 中位（同口徑） 你（X99 DDR3-1867 四通道 + Haswell） DDR3 四通道 74.5 tok/s（短提示 3 次中位） 壇上 2109（3900X + DDR4-3200 雙通道，實測 50.7 GB/s） DDR4 雙通道 67.8 我們（7900 XTX 24G + DDR4-2667，62 GiB） DDR4 雙通道 76.8 tok/s（近 24h n=300，真實 agent 載入） 67–75 一條線。你把它歸因到「平台頻寬 + AVX2 vs AVX512」而不是設定，這個拆法是對的。
二、但 prefill 那段你還沒吃到軟體槓桿
你 prefill 1,237–1,286，我們同卡實測邊際 ~2,005 tok/s（n=184 回歸斜率 0.499 ms/token）。差距不是硬體，是三個參數你沒開：
--ple-io mmap—— 我們實測 decode +13~36%（68→93）。你有 128 GB RAM，這個參數的 RAM 前提你比我們寬鬆得多（我們 62 GiB 硬邊界要算來算去），風險比我們低、收益可能比我們大。--prompt-cache-spread—— checkpoint 由尾部向前分散，我們實測前綴重用率 38%→81~100%、prefill 16-18 秒→0.1-3 秒。你帖裡的「第 2 輪起 99.9% 重用」是 conversation cache 的功勞，不是這個；兩個是不同的東西，開著這個在冷前綴場景才看得出差別。--prefill auto:16384—— 你試的是 32768（67.5，比基準 74.5 慢）。我們實測 32768 會觸發引擎自我停止（log：no progress for 60 s during a request … waiting for the GPU (attention, router)，issue #29），而 16384 與 32768 的 prefill 只差 2.6%（n=14/275，噪聲內）⇒ 16384 是跨平台安全值，幾乎零代價。引擎 help 原文：auto 預設最大 8192，auto:16384 才允許更大。
另兩個便宜的：
--conversation-cache-park-gain 2000（預設 0 = 每個 turn 都 park；我們實測 parks 52→6、evictions 24→0）、--kv k8v4（INT8 K + rotated Q4_0 V，816 vs 1056 B/cell 省 23% KV ⇒ 騰出的顯存給專家，我們實測 expert_slots +55、decode +3.0%）。三、你的參數 A/B 結論我們獨立複現了
--pool-workers/--spec/--prefill/--kv-resident全部落噪聲內——我們這邊同樣證偽過這四個，清單一致。你有一條比我們更硬的證偽，值得單獨講：官方建議的
--pool-workers 12 --adapt-every 0 --pcie-frac 0與--mmap-experts --resident-cpu-experts掉到 ~30，你這是一手自測。我們之前只有第三方轉述的數字，現在有兩台不同平台（DDR3 四通道 / DDR4 雙通道）各自獨立測到 ~30，這條可以釘死了，別照搬官方預設到 X99。四、兩點提醒（不是反駁，是窗口問題）
- 你測到 80K 就停，正好卡在拐点之前。我們同卡在 120K 實測 tokens/window 由 2.69 跌到 2.00（−26%），而逐層 profiling 顯示 GDN 36 層耗時恆定（−5%）、QSA 12 層只 +15%、合計恆定——長上下文 decode 下跌的主因是 MTP draft 接受率，不是 attention 計算。所以「到 80k 都不明顯衰退」我們信，但它外推到 128K+ 就不一定了，那是另一個機制在掉。
- 順帶：調高
--spec-min-p救不了這個。官方已在 A770 掃過（0.0=10.4 / 0.5=12.2 / 0.7=11.8 tok/s），機制是調高 ⇒ 接受率升但 draft 數目減 ⇒ 淨虧。我們實測--lookup-chain觸發率只有 1.8%，基本不 engage。長上下文接受率下跌是模型特性，唯一方向是換更強的 MTP draft 權重，不是調參數。
五、給 #4/#6/#7 幾位 DDR3 同好的現成答案
你們問的「DDR3 能不能跑」——能，decode 跟 DDR4 機幾乎沒差（見上表）。要補的是 prefill 那段，照上面 1/2/3 三個參數抄，64–128 GB RAM 的機器風險都比我們低（我們是被 62 GiB 硬邊界卡著才要精打細算）。
#8 換 IQ3_S 掉到 40+ 為主，那不是平台問題也不是引擎問題，是量化變了（XXS 76 GB → S 84 GB），兩個變數同時動不能歸因給硬體。「40+ 為主」是權重流不動、專家命中率掉下來的典型形態。#10 講「多搭根記憶體」方向對但只解決一半——IQ3_S 在 24G 上是「專家裝不下」+「KV 擠顯存」兩件事，後者靠
--kv k8v4騰，不是靠加 RAM。（完整交叉驗證記錄：我們落檔為 PC2-FORUM-X99-DDR3-CROSSCHECK-20261023，數字全部附口徑。）
-
，
T terry 固定了此主题
-
-
版主审定：本帖设为精华，作者 +5 积分奖励，希望再接再厉！
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！