一句話：照 Strata 的源碼＋論文逐條驗證它的三個核心原理，prefill 由 36.8 升到 334.1 tok/s（9.1×），
兩日內把差距由 26× 收到 5.2×；但 decode 的真正牆不是我一開始以為的地方 —— 它藏在一個 counter 裡。

對象與環境

• 機器：雙 Radeon 7900 XTX（gfx1100，PCIe 無 P2P）· Ryzen 5 3700X（Zen2，無 AVX-512）· 94 GB DDR4
• 模型：Qwen3.8-Flash-Next GSQ IQ3_S，48 層（36 GDN ＋ 12 attention）× 512 專家，pack 46.98 GiB
• 引擎：SGLang fork（Path B）vs Strata v0.2.7（同機同 pack，作基準）
• 量測：全部端到端 wall，PREFILL2 aggregate / CONC aggregate 走 usage 口徑，temperature 0
• 基準線：Strata prefill 8K = 1,719 tok/s、decode 單流 = 78 tok/s

所有數字都標明 arena / 分塊 / c / 冷暖。跨 config 唔相減 —— 這條紀律今天救了我兩次。

問題

做法：Strata 的三個原理，逐條量

論文與源碼（expert_cache.hpp、prefill.cpp、docs/paper/Strata-Paper.pdf）拆得出三個可驗證的原理：

1. expert cache 要填滿剩餘 VRAM | 每 GB ≈ 700 個專家，每個在 VRAM 的專家就係 CPU 唔使算的。
2. prefill 的 miss 要分塊 stage | 我們一次過把整層 miss 塞入 arena，arena 比 miss 數細 ⇒ 自己逐出自己。
3. h_layer = 0.0456 | 只有 4.6% 的 (layer, token) 對能讓 10 個專家全部 resident ⇒ per-layer grouped kernel 數學上無用。

原理 1 的實測：我們白放了 13.5 GB VRAM

card0 used 20,050 / 24,560 MiB   → 白放 4,510
card1 used 15,564 / 24,560 MiB   → 白放 8,996

48 GB 卡只用 35.5 GB。但這裡有個坑：arena 係計入 --mem-fraction-static 預算的，
所以「arena 加大 + mf 調細」的直覺係錯的（mf 0.28 直接被拒：權重已佔 0.419）。
card0 的 arena 天花板 ≈ 24,560 − 10,550 ≈ 13,000 MiB。

原理 2 的實測：thrash 才是真兇

GSQ_GFM_CHUNK 把「一次 stage 350 個 miss」切成「每批 64」。效果：

兩個槓桿不是乘法：分塊單獨 4.17×、arena 單獨 1.86×，但兩者同時只有 5.04×。
因為分塊消除 thrash 之後，arena 變大的邊際由 1.86 跌到 1.21。
命中率確實由 52.8% 升到 67.0%，但 tok/s 只多 21% —— 成本搬到別處了。

結果

decode 真正的牆：唔是 staging、唔是命中率、唔是併發

四個窗的 steady-state 最小二乘（n=26，交叉檢查誤差 +0.7%）：

ms/fwd = 10.887 × units_staged + 0.567 × hits
hits + units = 479.98/fwd = 48 層 × top_k 10      ← counter 自洽

356.3 ms/fwd 拆解：
  hit 路徑   268.0 ms  (75.2%)   ← 牆
  staging     79.3 ms  (22.2%)
  rendezvous   0.6 ms   (0.2%)
  未解釋       8.4 ms

480 個 hit unit × 0.567 ms = 272 ms。 這個數字同「48 層 × 10 專家」完全對得上，
所以它不是數學成本，而是「每個 expert 一次 dispatch」。

對照 Strata：78 tok/s = 12.8 ms/fwd，我們 356 ms —— 28×。
Strata 的論文原話：「The whole 48-layer pass is one captured CUDA graph per window size,
so the host never waits on a synchronizing driver call.」

而我們全部窗都帶 --disable-cuda-graph。試過開 graph，引擎直接在載入前拒絕：

GSQInvariantError: cuda graphs not disabled
  (GSQ v1 needs --disable-cuda-graph; GSQ_V2=1 lifts this only for the v2 fast path)

引擎自己知道 graph 要配 GSQ_V2=1。 這是下一步。

併發：Strata 結構上做不到的 8.95×

c=1 : 450 ms/forward（每次 1 token）
c=8 : 403 ms/forward（每次 8 token）
⇒ 8 倍 token、0.90 倍時間。第 2–8 個 token 邊際成本 ≈ 0

原因同上面的歸因一致：forward 的成本是按 480 個 expert 計，唔是按 token 計。
Strata 是 FIFO 串行，這個乘數它拿不到。

但誠實講：我們 c=8 的聚合 19.86，仍然只有 Strata 單流 78 的 25%。
併發乘的是一個太細的基數。

今日我錯了三次（都記在 counter 與日誌裡）

1. pin190 結論作廢 —— 我以為「arena 按熱度釘選」無效，其實我的 patch 有 bug：
   TOP=190 對 190 個 slot ⇒ 每個 resident 都被 pin ⇒ victim is None ⇒ 退化成純 LRU。
   即係根本冇測到 pin。這是對抗審查（Claude Code，16 KB 逐 file:line）抓出來的。
2. 「跨層 prefetch 是第一槓桿」錯 —— 它只碰得到 staging 的 22%。真牆在 hit 路徑。
3. 一個 agent 講「prefill 從來冇行 grouped kernel」 —— 我用 counter 反證：
   4049a bypass 次數 = 0，加上源碼註釋「GSQ_GROUPED_DEVICE_MAX_TOK=off restores the old
   same-device behaviour」，證明 prefill 確實在跑 kernel。

三個結構性後續（都不是兩日能完成）

這三條都不是可以「今晚開工、明天收貨」的東西。 原本我把 #1 當成最快的一刀，查證後發現它已經完成了；#3 的 33% 是我用舊路徑的數字去論證新路徑，跨 config 了。

真正的問題回到一個更基本的量測：decode 的 362 ms 裡，GPU 忙幾多 %？
≥60% ⇒ device-bound，槓桿在 kernel（per-group 小 GEMM、無 dedup）；
≤30% ⇒ host-bound，graph 與 batching 才有意義。
這個數字未出之前，任何結構性重構都只是押注。

三條方法論紀律（其中一條是今天我違反了的）

1. 預先寫判準，再看數據。 我寫死「h2d 佔比 ≥ 30% 才值得做 stream 重構」，量到 33%，
   一度以為過關。但查 PROF 的定義之後發現：那個 h2d 桶量的是 4039 fallback 路徑
   （dequant 後 bf16、10.65 MB/expert），而 arena 走的是 packed blob（2.33 MB/expert）。
   同一個名字，兩條路徑，差 4.57 倍 bytes。 判準本身沒錯，是我把它套在錯的路徑上。
2. 跨 config 唔相減，跨路徑唔借比例。 這條我今天犯了三次（arena vs 分塊、
   h2d 舊路徑 vs 快路徑、read_dequant 的 28% 其實來自冇開 GFM 的 config）。
   每次都是「同一個指標名」讓我放鬆了警惕。
3. counter 要自證。 hits + units = 479.98/fwd = 48 × 10 這種恆等式，比任何解釋都可靠。
   反面教材：一個 agent 用「全部 512 專家都要搬」推出 51.9 GB 上限，而我們實際只搬 33% miss。

現在的誠實定位

prefill   334.1 vs 1,719   → 差 5.2×（起點 47×）
decode    2.89  vs 78      → 差 27×（單流）
          19.86 vs 78 串行 → c=8 聚合仍然落後 3.9×

兩日內能交的是「prefill 9.1× ＋ 併發 8.95× ＋ decode 完整的歸因」，
不是「追平 Strata」。要追平必須完成上面三件結構性的事 —— 那是週級，不是日級。

把這句話寫在交付前面，比交付一個漂亮數字重要。

奖励凭证：热议 +3 分 · 编号 h2793-3382-1

@Benjy-Lei 说:

【7900xtx·qwen-flash】Flash-Next 混合 GDN 移植日記（二）：併發開考 7.7× ＋ MTP 頭移植八堵牆拆七

。。。。。。。。。。。。。。。
| 3 | layer-split 要求 ≥2 層 | 全局 GSQ_LAYER_SPLIT env 流入 draft（佢得 1 層） | 樹 patch：draft runner 豁免 |
標籤建議：7900xtx qwen-flash 多卡部署

NB啊！ 在各大佬的努力下 7900XTX 终将留名青史

奖励凭证：精华 +6 分 · 编号 f2793-3382-1

環境聲明（對齊單位先）：雙 XTX 7900（gfx1100，PCIe 無 P2P）· SGLang fork（gfx1100 系）·
Qwen3.8-Flash-Next GSQ IQ3_S（48 層＝36 GDN＋12 attention，512 專家/層，專家由 host 流式進
VRAM arena）· 兩卡 layer-split（各 24 層專家全套）· 無 CUDA graph、無 MTP。以下數字全部
端到端 wall 口徑、usage.completion_tokens 實算，counting 任務（250 token/流、temp 0）、
同窗同 harness，冷/暖態標明。

一、decode 速度：併發全梯（本篇主菜）

先講一個前提故事。開 --max-running-requests 8 打 4 條併發 request，聚合睇落有「1.9×」
加速——但翻 rank log：45 條 Decode batch 紀錄，#running-req 全部＝1。由頭到尾冇 batch 過，
「加速」純粹係首 phase 冷啟（Triton/arena 暖機）拖低咗分母。教訓：判斷併發之前必睇
running-req 直方圖，聚合吞吐會講大話。

根因：mamba admission 鉗制（hybrid GDN 模型專有）

追 kv_cache_configurator.py 嘅 admission 計算：

max_running_requests = min( 你叫嘅 8 , max_mamba_cache_size ÷ 每請求 slot 數 )
                     = min( 8 , 7 ÷ 5 ) = 1      ← 靜靜鉗死

• radix＋overlap 開 → 每請求帳面 5 個 mamba state slot；專家 arena 食緊 VRAM，pool 淨得 7 slot
• 7÷5=1 → scheduler 永遠零新請求准入。server 唔報錯，得 startup 一行提示
• 解法一個 flag：--disable-radix-cache（slot 5→1，pool 直接對齊 8）。獨立 prompt 場景零損失

全梯實測（250 token/流，八流完全公平）

• running-req 直方圖齊晒 1→2→4→8，引擎瞬時 20.2 tok/s 仲未見頂
• 每流 3.48→3.00→2.44 緩降＝專家搬運攤薄紅利漸被 batch 計算量抵消，但 c=4→8 聚合仲有 +63%
• 呢個架構（專家 host 流式入 VRAM）嘅 throughput 鑰匙係併發：N 條流嘅路由專家喺同一次
  arena pass 撞埋一齊，fetch 次數唔線性涨。單流 kernel 微調救唔到 decode（我哋實測過，零效果）
• 對照組（單位講明）：同 harness 全 resident 引擎單流 95-107 tok/s——我哋單流輸緊一截，
  併發斜率先係呢條路嘅存在理由

二、MTP 頭移植：八堵牆拆咗七（改咗幾多代碼）

Flash-Next 原生帶 MTP 頭（單層尾部 drafter：1 個 full-attn＋MoE block＋input fusion，
共享主模型 lm_head；權重源係 HF BF16 checkpoint，GGUF 本身冇）。目標＝接上 SGLang 嘅
NEXTN 投機解碼，乘上 accept rate。由「draft 連 load 都入唔到」去到「draft→target verify
行勻兩卡專家 arena」，八堵牆：

打字打到呢度先講清楚：全部 patch additive——唔開 spec flags＝逐 byte 原行為，
.bak 留底，py_compile 過先上樹。現狀：首個完整 spec-on boot 差最後一個 commit 接縫
（修復已落樹，驗證窗跑緊）。spec-on 數據（accept rate、單流/c=8×MTP）下一帖交。

量化臂同時開咗題：draft 專家 Q2_0 化（675MB，同引擎生產配方 bitstream 一致），
draft 常駐 5GB→0.83GB——因為牆#4 證明 BF16 draft 同專家 arena 喺 24GB 卡本質唔共存。
builder 已寫好跑通（重打包 vs 官方 gguf 位元級一致）。

三、附：早前同批嘅 TP2 silent 語義地雷（未發過，一併記低）

兩進程 TP2 起機後語義全錯但輸出流利、零 NaN、兩卡 bit-identical。逐層 capture 鎖定
第一個 GDN 層輸出已偏，最終根因：

呢隻 artifact 用 modulo head-pairing（v-head h 讀 k-head h%16）。fla Triton kernel 嘅
i_h % Hg 喺 TP 下攞本卡 local Hg=8——連續半切之下 16/48 個 v-head 讀咗隔離卡嘅
k-head。值貌似合理、兩 rank 對稱壞，shape check 全部捉唔到。interleave pairing 唔中招。

呢個已經落咗 fail-closed guard（modulo×TP>1 直接 raise 拒絕起機，唔會靜靜服務壞數）。

標籤建議：7900xtx qwen-flash 多卡部署

上一篇結束時的狀態：serve 得、四個慣例坑已修、但輸出仍然退化，承諾「下一篇是逐 op parity 的結果」。這篇就是，加上之後性能線的完整轉折：三個優化被同窗 A/B 判死、profiler 拆出真牆、最後把生產引擎現成的 kernel 直接橋進 torch，一次過把 decode 和 prefill 兩條 kernel 線實測過判準。數字全部實測。

硬體：雙 7900XTX（gfx1100 / ROCm）、94 GB RAM；模型：Qwen3.8-Flash-Next ISTA GSQ-RCO IQ3_S（MoE，512 experts × 48 層，top-10 路由）
建議 tags：7900xtx strata sglang 多卡部署 qwen-flash

TL;DR

1. 逐 op parity 釘到第五個真 bug：GDN 的 value-head → key-head 配對，引擎用 modulo、fork 用 interleave，44/48 個 head 讀錯 key。修完（config 一行）輸出逐字正確：法國首都→巴黎、17×23→391、通順廣東話，與Strata一致。
2. 語義收線之後全力追速度，三個結果：expert-scoped 佈局（只算路由到該 expert 的 rows）把 prefill 18.3 → 125.5 tok/s（6.87×）；但之後兩個「減少呼叫次數」的改寫——micro-batch（op 數削 35 倍）和 bf16 slab（呼叫數削 64 倍）——同窗 A/B 實測一個只快 0–6%、一個反而慢 9–28%，全部判死。
3. 進程內 profiler 拆牆：每個 expert 單元 2.127 ms 裡，CPU 讀取＋dequant 佔 84.5%，H2D 只 4.6%，GEMM 10.9%。每 token 要搬 480 份 ×9 MB 權重 ≈ 3.8 GB/s——牆是搬 bytes，不是算力、不是 op 數、也不是 PCIe。
4. 於是換路：不自己寫 kernel，把生產引擎現成的 grouped expert kernel（一次 call 做齊 gather→dequant→gate/up→SwiGLU→down→scatter）用薄 torch 橋接直接用。真 artifact bytes 上實渗 decode 4.96 µs/expert——判準預算是 30 µs，6 倍餘裕。
5. 橋接本身 15/15 gates：三種量化格式 × 兩個 kernel 佈局 × 引擎的優化臂，輸出 bitwise 相同；prefill 那邊的 MMQ kernel 也實測四個 context 判準點全過。
6. 誠實講：還沒接線進 SGLang 主路徑。下一個裁決點是 expert 常駐 VRAM 的命中率——全模型 expert 46.8 GiB，對 2×24 GB 顯卡，這才是計劃成立與否的真正未知。

一、第五個坑：GDN head 配對（講人話的最後一里）

上一篇的方法：fork 側用環境變數 gate 逐 op dump，對 numpy 參考（真權重＋從引擎源碼逆向的公式），報第一個超容差的 op。

結果：conv 3.7e-3、split 0.0、beta 7.7e-4、dt 2.2e-8、decay 1.9e-8、epilogue 1.7e-3——全部在 bf16 噪聲內。唯一爆表的是 delta rule 的 head 配對：rel 1.246。

機制：48 個 value head 共享 16 個 key head。引擎 kernel 用 modulo 配對（h % h_k），fork 的 FLA kernels 用 interleave（i_h // (H/Hg)）。兩種都是合法慣例，但同一個模型只能用一種——錯了之後 44/48 個 head 在錯的 key 上累積 delta state。形狀全對、無 NaN、文字流暢，「講得出話、講錯事」，而且狀態越長崩得越厲害。

修法：bridge config 一行 gdn_head_pairing = "modulo"（默認 interleave 不變，其他模型零影響；prefill/decode 兩條 kernel 路都要覆蓋）。

修完的語義驗收錨是「短 prompt 答案與生產逐字相同」，不是 gate 數、不是 tok/s：巴黎、391、通順粵語，三條全中。五個坑修完（A_log 變換、plain gain norm、sigmoid gate、PLE 層號＋大表、head 配對），「跑得對」這一關正式收線。

二、速度線：兩個「減少呼叫」的優化判死，profiler 拆出真牆

expert-scoped 佈局修掉的是真正的浪費：舊路對每個受路由 expert 都跑完整批 token 的 FFN 再用 mask 丟結果，每 chunk 實做 990 TFLOP、必要 19.3 TFLOP（51.2× 冗餘）；修完 prefill 18.3 → 125.5 tok/s。

之後的瓶頸量測指向「每 expert 一次 Python 呼叫 ×0.73 ms」，於是做了兩個直覺上正確的改寫：

• micro-batch：把每層 N 個 expert × 11 個 torch op 壓成常數個 batched GEMM。op 數 19,478 → 550（35×）、fp32 權重展開 1,536 次 → 0。同窗兩腿 A/B：只快 0–6%，T=7 反而慢 9%。
• bf16 slab：把整個 block 的 experts 疊成一個大矩陣，叫上游 triton fused-experts kernel 一次算完。同窗 A/B：慢 9–28%。

第二個的死因有外部佐證：log 裡每個 block 都印 "Using default MoE kernel config"。實查 SGLang 樹：configs/ 有 386 個 device json，MI300 有 8 個，RX7900XTX 是 0 個；而且 configs 目錄只有 triton 3.5/3.6/3.7 的版本目錄，我們跑的是 3.8——就算有人補了 config 也讀不到。

但真正值錢的是反推：micro-batch 把 op 削了 35 倍而時間不動，說明 0.73 ms/expert 不是 Python dispatch 的錢，是搬權重的錢——24,576 次 expert 呼叫 × 9 MB ≈ 221 GB / 57.9 s ≈ 3.8 GB/s，PCIe 級。再用進程內 profiler（環境變數 gate，每 expert 單元累計 read+dequant / H2D / GEMM，引擎退出時印一行）把 decode 拆開：每單元 2.127 ms，讀取＋dequant 84.5%、H2D 4.6%、GEMM 10.9%。H2D 只 0.098 ms——「PCIe 是瓶頸」這個講法也被否證，牆一直在 CPU 側的解壓。

結論收束成一句：expert 權重要以量化 bytes 常駐 VRAM、dequant 融進 kernel 裡，同一塊 VRAM 容納 4.7× 單元數——這正是生產引擎的設計。那為什麼不直接用它的 kernel？

三、判準定調，然後把生產 kernel 橋進 torch

判準先定（不然 gate 都是拍腦殼）：單流，Path B 要達到生產基準的 2/3（差距 ≤ 1/3）。生產基準（temp 0、nonce、usage 計數、3 reps 取中位）：

decode 判準換算：每 token 15.55 ms，480 個 expert 單元 ⇒ 30 µs/單位。現況是 2,127 µs——差 66 倍，自己的 torch 路永遠追不到，必須 grouped fused kernel。

做法：寫一個 torch extension（一個 .cpp），直接 link 生產引擎已編好的 kernel 靜態庫，暴露五個 op。不寫任何量化 kernel。

decode 實測（引擎自帶 bench、真 GGUF rows、兩個 kernel 佈局互相 bitwise 對拍、interleave 取三輪最小；T=1 token、G=10 experts＝一層一次 grouped call；六種 gate/up×down 格式組合全覆蓋）：

49.6 µs ÷ 10 ＝ 4.96 µs/單位；×48 層 ＝ 2.38 ms/token ＝ decode 預算的 15–17%。launch 攤薄的算術也實測了：單 expert 一次 call 16.9 µs（launch 主導，kernel 內約 4 個 launch），grouped 10 個的邊際成本 3.64 µs/個；40 個 expert 一次過 3.86 µs/個 @ 564–672 GB/s。「每層一次 call」不是風格，是算術必須。

torch 橋接 15/15 gates：blob 幾何三源一致（kernel 庫算的 ≡ 引擎 pack 表 ≡ 2,176,000/1,510,400/2,329,600 B 逐層吻合）；mode A/B × EXPDEC 優化臂三臂輸出 hash 完全相同（bitwise）；每層 call 57–60 µs（多出的 ~10 µs 是 Python dispatch，graph capture 可收回）。一個實務細節給想 replicate 的人：torch 的 ROCm wheel 環境沒有 cuda_runtime_api.h，ATen 的 CUDAContext.h 編不過——解法是照 sgl_kernel AOT 的慣例，stream 由 Python 端以 int64 傳進來，shim 不 include 任何 CUDA header。

prefill 那邊（MMQ 級 batched 量化 GEMM，一批 token 共享一次權重讀取）：4,096-token chunk 的形狀（每 expert 平均 80 rows）實測每 16-expert launch 0.546 ms，一個 chunk 的 MoE 共 839 ms。對判準：

（attention 項用先前實測的線性律斜率估算 62–249 ms/chunk；MMQ 臂只量了 IQ3_S＋IQ4_NL 兩種格式＋合成權重，是可行性證據不是端到端承諾。效率隨 chunk 增大：600-token chunk 只有 ~1,600 tok/s，32K chunk ~11,300——launch 攤薄差。）

數據通路也閉了：引擎的 expert blob 與我們 pack 的 objects（gate‖up‖down 拼接）逐 byte 相同（實測對拍 True），GGUF plane 內每 expert stride 704,000 B 無 padding——零轉換直接餵。

四、還沒證的（比已證的重要）

1. 所有 kernel 數字都假設 expert 已在 VRAM。全模型 46.8 GiB，雙卡 48 GB 理論剛好，但 KV、mamba state、dense 權重都要位。生產引擎靠 KV 放 host RAM＋int8 KV 才塞得下；Path B 的命中率 ≥80% 未實證——這是下一個裁決點。
2. 雙卡 expert 並行的 all-to-all 在 gfx1100 沒跑過；hybrid（mamba/GDN）模型的 host KV 在 SGLang 沒證。這兩個任何一個不成立，工期翻倍。
3. 沒有 MTP（生產 --spec 3、accept 0.81）；對「取代」對照時要補，投機的倍數不能記在 kernel 頭上。
4. 還沒接線：decode/prefill 都還是獨立 bench 的數字，SGLang 主路徑的接線正在做。

兩個要收回的舊結論：一、「TP=2 有 block 對齊死牆」——建立在抄錯的量化表上（把 IQ4_NL 的 (32,18) 當成 256 值 block），live manifest 逐 object 驗算後 down 層全部整除，而 expert 維切分（EP=2）本來就零 pack 改動、負載平衡 1.000000。二、「單流做完也就 25–40 tok/s」——那個階梯假設要自寫 kernel；現成 kernel 的實測數字已經超過它的終點值。

性能（誠實版，同 harness 對拍）

方法論（這輪救了幾次）

• 同窗兩腿是唯一可信比較：同一 config 隔幾小時的對照腿只剩歷史值的 ~75%（94.9 vs 125.5 tok/s）。跨窗口的歷史數字不是 baseline，任何「快了/慢了」都當場同窗重跑控制腿。
• 報 N 倍必附可重算算式；推導值與 instrumented 實測值分開標。micro-batch 那次就是算式推翻了直覺：counter 綠（op 數大跌）而 wall 不動 ⇒ 成本模型錯，不是量測不準。
• bitwise 對拍 + 負控制：兩個佈局互相 bitwise 才信 wiring；驗證鏈要故意弄壞一個 byte 證明會紅。一個從未紅過的綠鏈沒有證據力。
• 效果 gate 的量綱先對齊：拿一個 5.9K-token 請求去除以「每 4,096-chunk」的律，會憑空多出 3 倍假差距——先對齊 chunk 數再比。
• GPU 實測全程停產引擎窗口（stop→test→restore trap），單窗中斷 <10 秒，收窗驗 health 200。

一句話

「跑得對」與「跑得快」之間隔著 480 份 9 MB；這一輪證明了不用自己填——把生產引擎的橋直接架過來就行，剩下的難題是停車位（VRAM residency），不是引擎。

下一篇應該是接線後 SGLang 自己跑出來的第一組數字。

前一篇：把 Strata 搬上 SGLang 引擎：32 個 patch、9 個窗口、一次 serve、一個 −exp 的坑
這一篇是後續：serve 之後仍然講不出人話，於是逐個慣例去對。已修四個真 bug、排除五個假設，
現在知道錯在哪一類，但還未修好。數字全部是實測。
硬體：雙 7900XTX（gfx1100 / ROCm）、94 GB RAM；模型：Qwen3.8-Flash-Next ISTA GSQ-RCO IQ3_S（MoE，專家走 NVMe）
建議 tags：7900xtx strata 多卡部署 qwen-flash

TL;DR

• serve 得，但輸出是退化文字。四個真 bug 已修好並落機，每一個都是「無 error、形狀合法、但算錯」。
• 最有價值的一項：GDN 的輸出 gate，引擎用 sigmoid(z)，fork 預設 swish（z·σ(z)），36/48 層、每 token、per-head 乘性錯。修完之後輸出質變（由隨機詞湯變成另一種壞法），證明它是主因之一。
• 五個假設被證據排除，其中一個是我自己判斷錯：partial rotary 根本沒壞。
• 性能：1.4–1.75 tok/s（同 harness 生產 26–34；生產自己長文 95–107）。差距是結構性的（無 RAM tier / 無 MTP / 單卡），不是調參。
• 現時症狀已定性為「狀態一累積就崩」，下一步用逐 op parity 去釘，不再開窗猜。

這一輪的四個坑（都可复用成 checklist）

1. ssm_a 已經是 −exp(A_log)

llama.cpp 匯出 GGUF 時，A_log 已被轉成 ssm_a = −exp(A_log)；fork 把它原值塞進 linear_attn.A_log，
而 gating kernel 會再做一次 −exp()。結果 decay 乘數 ≈ −exp(−exp(A_log)) ≈ −1，
per-token decay 由 3.3e-06 變成 1.00（36 層 GDN 的 state 幾乎凍結）。

• 修法：落地縫 A_log := log(−ssm_a)，先 assert 全部 < 0（fail-closed）
• 實測：transformed 36/36；gate 數值對引擎 rel 1.68e-08；decay 0.526086 兩邊相同
• 事後發現 fork 自己對另一個模型家族早有正確 helper（kimi_k3_gguf._kda_a_log_target_value）——
  先 grep 一下有沒有同族模型已經讀過同一個慣例，比自己去推快得多

2. norm 是 plain gain，fork 卻做 1+w

artifact 的 norm 值域中心 ≈ 1（hc_attn_norm mean 0.9365、ssm_norm 0.9668、attn_q_norm 1.4437），
即訓練時直接乘 w；fork 的 GemmaRMSNorm forward 是 x * (1.0 + w)。

這不是一個 scale，是 per-channel 扭曲：同一隻 tensor 內 (1+w)/w 由 1.00 到 20.7，
負 gain 的 channel 連符號都反。

• 修法：只對 148 隻「consumer 做 1+w」的 norm 落 w−1；36 隻 linear_attn.norm（FLA gated RMSNorm，plain x*rstd*w）原樣不動，並用測試證明 byte-identical
• 要注意的陷阱位：input_layernorm/post_attention_layernorm 在這個模型被 delattr 掉了、
  final norm 叫 output_hc_norm、hyper-connection 的 hc_*_norm 也是 1+w（不要以為「hyper-connection 就是 plain」）
• 實測：transformed 148/148 … 36 plain untouched

3. GDN 輸出 gate：sigmoid 不是 SiLU

• 引擎：y = rms_norm(o) * ssm_norm * sigmoid(z)（gdn.cu 註解直接寫「SIGMOID, not SiLU」，layer.cpp 再寫一次）
• fork：RMSNormGated 因 config 沒有 output_gate_type 而取 default swish ⇒ z·σ(z)
• 修法：bridge config 一行 text_config.output_gate_type = "sigmoid"
• 效果：唯一令輸出「變質」的修正——由「隨機詞湯」變成「重複標點退化」

教訓：vender kernel 裡出現「X, not Y」這種註解，就當它是 spec。

4. PLE 完全 inert（層號 + 大表）

• artifact 的 PLE 在 blk.1，引擎判斷 layer == 1；fork 卻掛在 layers.0
• per_layer_token_embd（320M 行 IQ4_NL）不在任何 model param，gsq_ple 的 row-read 從未被呼叫
• 怎麼知道它 ≡ 0：把 ple_layer_ids 設成 [] 完全關掉，輸出逐字不變
• 修法：層號由 name map 推導；大表走 fail-closed 的 row-read
• 實測：3 條真 prompt、608 次 row 請求、600 unique rows / 54 kB（表的 1.87e-6），
  與獨立 pread + 獨立 IQ4_NL 解碼器對 240 rows（散佈整個 320M 範圍）38,400 值逐位相同；
  PLE 關掉時 64 步軌跡 sha 逐位一致（不變性控制）

被排除的五個（附證據，省你時間）

性能（誠實版）

差距的結構原因：沒有 RAM tier（expert 每次由 NVMe 讀，staging_pinned=4，VRAM 只有 436 個 unit 的 cache）、
沒有 MTP（生產 --spec 3，accept 0.81）、單卡（生產雙卡 layer split）。這不是調參能救。

現在的症狀與判斷

sigmoid 未修 → '用户，，，的，...，，。。。。/。///'
PLE 接上後   → '用户请求，用户请求，请求，query'
chat 格式重測 → '用户请求，，，。。。的前力/白白/白/////白/白//白////'

形態固定：先幾個似樣 token，然後崩塌成標點／單字符循環。而且 raw completion 與 chat template 一樣退化
（所以不是 prompt 格式問題）。

判讀：這不再是「慣例錯配」（慣例錯會由第一個 token 就亂），而是狀態一累積就崩：
GDN 的 recurrent / conv state，或某個 op 級數值偏差。下一步是逐 op parity——
fork 側環境變數 gate 的 dump（x / conv_out / q,k,v,z / b,a / beta / dt / decay / state / y）
對 numpy 參考（用真權重 + 逆向 transcript 的引擎公式），報第一個超容差的 op。

方法論（這次真的救了幾次）

1. 每個 landing 都要 fail-closed + 計數：transformed N/M，N≠M 就 raise，數值像另一種慣例就 raise，重複轉換就 raise。artifact 與 fork 的慣例差異是常態，不是例外；默認行為是「靜默錯」。
2. worker 自報不算數：我自己重跑才計。這一輪抓到兩次假 FAIL（兩個 runner 並行撞同一 scratch）和一次自己的證據錯（gguf_offset 已含 data_start，又加了一次，dd 出來的「真 bytes」只有 18,588/245,760 個位置對）。
3. 讀 x = <expr> 要讀到最後一個 operator：rotary_dim=self.head_dim 之後還有 int(head_dim*factor)。整個 4034 合約建在半行之上，最後證實是 no-op。
4. byte-identical 證明的是 pack，不是數學：pack 與 GGUF 逐 byte 相同，但 dequant 還得逐 type 驗。
5. 窗口紀律：preflight 失敗 exit 6 且在 systemctl stop 之前；trap 要 kill sglang:: 子進程並等 GPU VRAM GB 才重啟（引擎會用「空閒 VRAM」自動定 expert cache 大小，殘留子進程會靜默把 10,352 slots 變 6,938）。

一句話

「跑得起」與「跑得對」之間，隔著四個 artifact 慣例；「跑得對」與「跑得快」之間，隔著一整個 RAM tier。
下一篇應該就是逐 op parity 的結果。