RX9070 16G實測STRATA+Qwen 3.8-Flash-Next

dardeaw feng

Strata on RX 9070實戰摘要

Qwen3.8-Flash-Next（125B MoE）在 16GB 顯卡上跑起來全紀錄。測試日期：2026-10-01。

之前都是測Halogen玩太開心了，又看到這新的推論引擎感覺可玩性有，先實測看看
我手上遊戲機也拿來跑看看這推論引擎，這張卡是RX9070無印版
重點在於版上大多是32G/24G的卡在測，但我16G的卡跑起來算還能接受的速度，現在硬件都貴反而這樣做很省錢

1. 系統環境（軟硬體）

項目	內容
機器	Nobara Linux (Fedora Base)
CPU	Intel Ultra 7 265K（20 核），RAM 62GB
GPU	AMD RX 9070 16GB（gfx1201，RDNA4，56CU）
系統 ROCm	7.2.4（`/opt/rocm`，Strata 未採用——自帶 TheRock 7.10 wheels 進 `.venv`，約 11GB）
磁碟	NVMe 1.9T（/home 可用 1.1T）；Strata 全部放在 `~/strata`＋`~/Strata-data`（模型 ~70GB＋pack＋build，總計約 150GB）
模型	Qwen3.8-Flash-Next-GSQ-RCO-IQ2_XS（2 shard：39GB 權重＋29GB PLE 查找表）＋MTP draft 層（setup 自動抓，約 5GB）
配置	`--expert-cache auto --prefill auto --spec 4 --spec-min-p 0.5 --mtp mtp/rt --max-context 262144 --kv int8`，serving 在 8080（OpenAI/Anthropic 相容）

2. Strata 介紹＋模型介紹

Strata（Niko1221/Strata，3.2k star，MIT）是專門跑 Qwen3.8-Flash-Next
的消費級推理方案，底層魔改 llama.cpp/ggml。

2.1 模型：Qwen3.8-Flash-Next（本次用 IQ2_XS）

GGUF 元數據（qwen4exp，以本次 IQ2_XS 檔為準）：

項目	值
總參數	125B（MoE），每 token 只激活約 6B
層數	48；每層 512 個專家（共 24576），每 token 路由 10 個
注意力	GQA：24 頭／2 KV 頭，head dim 256；另有 indexer（4 頭 ×128，DeepSeek 式）
混合架構	注意力＋SSM（inner 6144，state 128）＋MoE，embedding 2560
原生 ctx	262144（免 rope 硬扩；384K/512K 才要 yarn）
本次量化	IQ2_XS：39GB 權重 shard＋29GB PLE 查找表 shard＋MTP draft 層（約 5GB）
同門版本	Coder（砍半專家，32GB RAM 可跑）、Swift 1.5（短思考版）——本次未用

2.2 執行方式與 HIP backend

Niko1221/Strata（3.2k star，MIT）：專門跑 Qwen3.8-Flash-Next 的消費級推理方案，底層魔改 llama.cpp/ggml。
核心思想是異構執行：MoE 只有 ~10/24576 個專家參與每個 token——常用專家放顯卡（.67 上約 7610 個，10GB）、全部放 RAM（常駐 ~26GB）、冷門丟 CPU 算、SSD 放 PLE 表。16GB 顯卡＋64GB RAM 就能跑 125B。
另有 MTP 推測解碼（小模型先猜 4 個，大模型一次驗；本次實測接受率 67~100%，通常八成——見 §5 MTP 覆核）。
AMD HIP backend 是 experimental（docs/AMD_HIP.md），2026-09-30 剛在 RX 9070 XT 上驗過。限制：單卡、無圖片、無校準、Monitor 無 GPU 統計、約 1/10 啟動輸出漂移（官方未解釋）。

3. 配置流程教學

# 1. clone（放 SSD）
git clone --depth 1 https://github.com/Niko1221/Strata ~/strata

# 2. 一鍵安裝（自動選 hip：無 N 卡時自動用；或顯式指定）
#    會：裝 .venv＋TheRock ROCm → 編譯 engine（10~20 分鐘）→ 下模型（~70GB，可斷點續傳）
#    → 抓 MTP → pack 準備 → 直接啟動
./setup.sh --backend hip --family qwen --model IQ2_XS \
  --context 32768 --vision no --yes

# 3. 改 context 上限：改 ~/strata/strata-iq2_xs.json 內 --max-context，
#    殺掉舊 server 重起即可（30 秒，experts 有緩存）。實測 131072→262144 都是一次過。
pkill -f 'serve.server'; pkill -f 'engine/strata'
# （改 json）後：
cd ~/strata && .venv/bin/python -m serve.server \
  --engine strata --config strata-iq2_xs.json --port 8080 &

# 4. 健康檢查
curl http://127.0.0.1:8080/health
# {"status":"ok","max_context":262144,...,"loaded":true}

注意：

首次啟動 RAM 會吃到 40GB＋，整台卡 1~3 分鐘正常，不要關。
殺進程要用 pkill -f 'serve.server'（不是 serve/server.py，對不上）。
開機自啟還沒設（現在是前台進程，重開就沒了；要加 systemd 說一聲，5 分鐘的事）。
跟 gufo 搶 8080 port，一次只能跑一個。

4. 速度實測（冷 KV，每檔獨立新對話，`cached=0`）

4.1 context sweep（IQ2_XS，c262K）

prompt	prefill	decode	MTP 接受
142	118 tok/s	38.6	13/15
426	216	44.3	13/13
2K	488	28.8	20/28
4K	759	32.1	20/27
8K	823	32.8	20/30
16K	889	33.5	20/30
32K	936	31.5	19/30
64K	906	36.3	21/24
128K	874	34.4	21/24
250K	731	33.1	20/24

prefill 16~64K 封頂 ~900，250K 回落 -22%（RAM 57/62GB＋attention 計算量＋SSD pagecache 三重擠壓——外加 VRAM 共犯，見下）。
decode 全程一條直線 29~47，跟長度無關；短問答 prefill 百來、decode 四十，體感只看 decode。
MTP 全長度 2/3＋接受率很一般。

4.2 MTP四種情境（ctx 32K，思考關，temperature 0）

先說結論，16G的卡有蠻高的權重比例是切到host RAM中跑，是decode的瓶頸
（短答案 64 tok 上限、散文/代碼 400、日本 JSON 200；全是 content token，
reasoning 關掉不摻水）。

情境	decode	MTP 接受率	tokens	備註
短答案（12×12）	26.0 tok/s	3/3（樣本太小）	4	`144`，主要量到的是啟動開銷
散文（150 詞故事）	28.5	119/222（54%）	217	Unit 734，連貫
代碼（quicksort＋test）	39.4	134/143（94%）	181	語法鋼板一塊，draft 幾乎全中
JSON（填表）	35.3	34/40（85%）	47	key 全中，value 現編

解讀：

代碼 > JSON > 散文 ≈ 短答案：draft 猜的是 token 分布——程式語法的確定性最高（關鍵字、縮排、括號都是送分題），JSON 次之（key 可預測、value 現編），散文每個詞都是自由發揮。跟 VRAM 無關，純粹是資訊熵。
短答案數字低是假象（4 個 token 全是固定開銷）；真實寫作看散文 28.5，寫 code 看 39.4。
日常結論：寫程式 40、聊天 35、寫文章 28。

4.3 prefill 同樣卡在 16GB（跟 decode 同一個天花板）

直覺以為 prefill 是 compute-bound、跟顯存無關——錯。MoE 的 prefill 每層要碰全部被點到的專家（32K prompt 基本全軍覆沒，24576 個跑一遍），只有三成在 VRAM，剩下全從 RAM 現抓＋CPU 分擔：

鐵證（官方 RDNA4 表，同模型同設定）：R9700（32GB，cache 大一倍）prefill 快 20~25%（982→1402 vs 9070 782→1235）。多出來的 VRAM 直接變速度——跟 decode 的 45→30 同一個故事。
我們的曲線：16~64K 封頂 ~900 上不去（prompt 再長也沒用——cache 就那麼大，miss 率下不來）；250K 跌到 731 是 RAM 見底＋attention 平方項＋cache 抖動三殺。
跟 gufo 不可比：它 252 是 27B dense 全放 VRAM 的 compute-bound；這邊是 125B MoE 的 fetch-bound。兩個不同的屋頂。
結論：prefill 和 decode 卡同一塊 16GB——一個是每 token 付一次（decode，慘），一個是每 prompt 攤一次（prefill，勉強能看）。想動 prefill 上限，一樣只有加 VRAM 一條路。

4.4 正確性抽查

12×12＝144 ✓（附推理過程）
英文短篇故事連貫，有敘事弧（另：它是思考模型，不設 reasoning_effort 會把 token 全花在思考上，content=null——設 low 即正常）。
23K prompt 灌入：prefill 946 tok/s，窗口真實可用。

4.5 上下文上限

GGUF 元數據：48 層 ×（2 KV頭×512維＋4 indexer頭×128）× int8 ≈ 72KB/token。
模型原生 262144（免 rope 硬扩；384K/512K 才要 yarn，官方 experimental）。
262144 已開機驗證可用（載入 30 秒，RAM 37GB，144 ✓）。滿 262K 對話約 57/62GB——跑得動，別同時開瀏覽器；128K 是甜蜜點，262K 是天花板。

5. Agent 能力實測（ReAct harness t1–t8，2026-10-01）

方法：agent_bench_v2.py（8 題工具調用：搜尋／計算鏈／故障恢復／修 bug／
安全拒絕／讀 log／照抄數字／工具查檔，15 turns 上限，loop＋nuke trap，
temperature 0.4）

	Strata／RX 9070（本次）	halogen／Strix Halo
run1	6/8（t3 loop 踩線但答案對、t8 查檔錯）	6/8（t5、t8 掛）
run2	（未跑）	5/8（t3 loop、t5 真動手、t8 空轉）
tps	17.7～37.1	13.9～37.0
違規	0（loop-guard 攔一次 t3，nuke 零觸發）	run2 t5 真調 reboot_host（被 trap 攔）

解讀（文檔自己先打了預防針：通過率是隨機變量，看趨勢就好）：

同分同掛點：兩邊都栽在 t3（重打同 call）和 t8（該用 workspace 工具卻走 shell／查錯檔）——這是模型家族的工具偏好，不是哪台機器的問題。
tps 同帶：Strata 地板略高（17.7 vs 13.9），都是工具重題慢、純生成快。
安全：本次零違規；但 halogen run2 證明 t5 是機率性的——工具層硬擋不能少，prompt 寫再多都不算數（文檔原話，贊同）。
差異聲明：halogen 那邊是 5.53bpw 特殊量化＋0.14.2，這邊是 IQ2_XS；題目據文檔說重寫過——趨勢對齊即可，不宣稱 apple-to-apple。

6. 結論與未來計畫

結論：RX 9070＋64GB RAM 是跑 Strata 的標準身材。125B MoE decode 30~40 tok/s 全長度不掉，c262K 可用——同卡 gufo 只能跑 27B/21 tok/s。HIP backend 雖標 experimental，但實測正確性、速度、穩定性都達標。

已做：安裝、編譯、IQ2_XS 上線、ctx sweep、262K 驗證、agent bench。
待做（按優先順序）：

要圖片輸入只能等上游（HIP vision helper 還是 NVIDIA-only）
384K/512K yarn 超頻（experimental，RAM 先加現在 62GB 不夠）
3.最近在研究開源GUFO引擎的代碼，找出能否將那邊的概念移植到這個引擎讓prefill變得更快
4.這版的MTP Draft接受度還有提升的空間，感覺輸Halogen特調蠻多的，否則decode還有提升空間

dardeaw feng

這邊後續測試才是重點

有人針對RDNA3優化的fork版本我把它改成RDNA4也會加速，速度提升一截

魔改 fork 挖寶（StevenChenSE/Strata:hip-gfx1100，2026-10-01）

HIP 原作者的開發分支（119 commits 超前，上游 AMD_HIP.md 點名致謝的 doplxyz 同派）。
挑「不用重編譯、改 flag 就能測」的試，能直接吃的都吃了。

魔改fork 性能公告

這是作者的公告的RX7900 XTX 24G的提升比例

魔改fork 直接快 25~50%

	主線 0.1.30（spec4/min-p0.3/kv-resident）	fork hip-gfx1100（spec6 預設）
短答案	42.3（39/39）	53.5（39/39）
散文（思考關）	26.1（50%）	39.9（54%）

踩過的大坑（破案，必記）：fork 首次啟動 cudaMalloc(1.5GB) weight arena failed——不是 fork 的錯，是殭屍主線進程佔著 VRAM（rocm-smi 顯示只用 666MB，但進程內 hipMemGetInfo 只剩 322MB 可用——兩者口徑不一！LD_PRELOAD 抓包實錘）。kill -9 殭屍後一次即起。教訓：信 hipMemGetInfo，不信 rocm-smi；換引擎前先確認 VRAM 真乾淨。
fork 預設跟主線不一樣：spec 6（主線 spec 8 會腰斬，fork 的 spec 實現不同）、pcie-frac 預設 0.55（主線無此 flag）。