<![CDATA[[實測IV] Strata / Qwen3.8 Flash IQ2_XS 單卡跑到 424K 155t/s — parking 能留幾條對話：含三個不利發現]]>這篇是 2026-10-01/02 我跑完整個 campaign 的記錄，承接前三篇 1228、1462、1967。

問題一開始很簡單：兩張空閒的卡有沒有用。跑著跑著變成另一件事——單卡把 context 從 256K 推到 1M 時，KV pool、parking 和能同時保留的對話數量會撞到哪裡。

cover.png

先給結論：256K 上，本機 Strata 與 NInfer 在無投機口徑下基本打平。真正的差別在 parking（Strata 單卡獨有）、記憶體（61.4 GiB 是硬限制）和投機窗口（--spec 4 優於 --spec 8）。

Phase 1–5 的數字有 summary.json、results.json、startup.txt 可核對。Phase 6 是即時執行，數字來自引擎 log 原文，沒有 benchmark.py 的 artifact，下面都標明。

0. 結論

chart0_conclusions.png

圖裡的六格是可量化的結論：256K 的 prefill、256K 的 decode、各 context 的 parking 上限、兩個 instance 的 batch wall time、available RAM、WS private。下面六條是圖表達不了、但同樣屬於這篇的結論：

  • Remote expert cache 是錯誤用法。它只分配第一張卡還沒 claim 的 cold tail：一次 request 的 1,057 次 layer launch 裡 2,919 個 entry、28.5 MiB、等待 368 ms、GPU 使用率 0–12%。第一張卡已經持有約 99.4% 的 routed mass。
  • KV offload 關不掉。--kv-resident N 的意義是「在 VRAM 保留 N 個 cell/QSA layer 的鏡像，其餘完整的 K/V 留在 pinned host RAM」。提高 N 不會縮小 pinned pool，只改變 VRAM mirror、streaming 命中率和 expert cache 大小。
  • Parking 只支持單 GPU。generate.cpp:1220-1223 拒絕 --layer-split，所以 B3 的 4,993 tok/s 與 parking 互斥。圖第 3 格的全部數字都是單卡配置。
  • --spec 8 比 --spec 4 慢（§9）。每 round 多產出 token，但每秒少做 round，decode 淨輸 2–8%。引擎自己的 cost model 也算出 window 4 是 optimum。
  • YaRN 延伸的 quality 我沒測。1.5–4.0× factor 沒有 needle 或 perplexity 測試。這篇的長 context 數字是速度與容量，不是 accuracy。
  • 跟 NInfer 比（同一張 5090，詳見 §8）：Strata 能在 32 GB 卡上跑 125B-A6B 到 256K，NInfer 不能（expert 文件 34 GB 超出 VRAM，且沒有 CPU expert tier）。用本機自己的記錄、口徑對齊後：無投機 decode 兩邊基本相同（Strata 在 64K/128K/256K 略勝）；真實 agent 流量 Strata 155.1 優於 NInfer MTP3 143.6、不及 DFlash2 183.4。NInfer 的優勢在小 prompt prefill、C=1–8 真 batching，和 DFlash2 這類 Strata 沒有的 drafter。

Standing config：424K + --resident-experts + parking 26,624 MiB / 4 slots / 1,024 MiB floor。3 條對話在滿格 context 下同時保留，prefill 是 256K 的 91–92%。

1. 環境與測法

  • 卡：RTX 5090 32,607 MiB（Gen5 x16，PCIe probe 51.9–52.4 GB/s，pcie_frac 0.55）、RTX 5080 16,303 MiB（Gen4 x4，probe 6.5 GB/s）、RTX 5060 Ti 16,311 MiB（Gen4 x4，6.5 GB/s）。
  • CPU / 記憶體：Ryzen 9 9950X3D；2 × 32 GiB DDR5，實跑 6000 MT/s（G.Skill F5-6400J3239G32G，BIOS 報 ConfiguredClockSpeed 6000，Windows 可見 61.4 GiB）。沒有 ECC、沒有注冊記憶體——所有容量與帶寬的結論都受這 61.4 GiB 限制。
  • SSD：模型 GGUF、pack 與 MTP draft layer 都在同一張 Samsung SSD 9100 PRO 4 TB NVMe（C:），跟 DDR5 同一個消費級平台；另有一張 GIGABYTE 1 TB NVMe（F:，IQ3 用）和 SATA 860 EVO（D:）。專家權重以 mmap 讀入，路徑是 NVMe → OS file cache（同一组 DDR5）→ PCIe → VRAM，所以 SSD 這一層跟 --resident-experts 爭同一份 61.4 GiB。實測引擎 working set 約 37 GiB、系統 free RAM 只剩約 1.2 GiB——parking 的准入檢查用的就是這個 free 口徑。
  • 模型：qwen3.8-flash-next-iq2_xs（48 layers × 512 experts = 24,576 個 expert pair，native context 262,144）。12 層 QSA 持有 KV，36 層 GDN 持有 running state。
  • 系統：Windows，engine 0.1.31，port 18081。

測法：

  • Phase 1–5：未修改的 bench/results/2026-09-30-community-rtx-5090/benchmark.py。每次執行用新的 nonce prompt（跨執行不重用）、greedy、256 token 輸出上限、streaming、--targets 4096,32768,128000,256000 --runs 3。TTFT 與 decode 速率取自引擎 /metrics 的 per-request 記錄，RAM 用 Windows counter。Run-to-run 離散約 5%（256K）、15%（4K）。
  • Phase 6：固定 filler prompt（12 個單字循環，實測 4.562 chars/token），每條對話用獨立 seed，一次輸入至接近 context 上限，max_tokens 400。TTFT 由 client 的第一個 delta 計算，parking 事件讀引擎 log 原文，RAM 用 Win32_OperatingSystem.FreePhysicalMemory——就是引擎准入檢查所用的同一個「free」口徑。

2. Phase 1–3：多卡

每加一張卡便损失 decode：136.7 → 120.7 → 98.9。256K 的 prefill 只有 B3 贏（4,993 對 4,079），但 B3 跟 parking 互斥。

Configs（可與 summary.json 核對）：

# config VRAM 中的 experts 备注
A "gpu": 0 16,640（68%） 只有 5090，48 層
B "gpu": [0,1]，--layer-split auto 18,139 auto 選了 K=47（5080 只得 1 層、0.72 GiB）
B2 "gpu": [0,1]，--layer-split ""，--expert-cache-device1 7000 23,920（97.3%） 5080 作為纯 remote cache
B3 "gpu": [0,1]，--layer-split 36 24,208（98.5%） 5090 為 0–35、5080 為 36–47（6,144 slots / 8.48 GiB）
C "gpu": [0,1,2]，--layer-split 28,42 24,576（100%） 5090 為 0–27、5080 為 28–41、5060 Ti 為 42–47

Decode tok/s（3 次的中位數）：

prompt A 5090 B auto K=47 B2 remote 7000 B3 K=36 C 3-GPU
4,096 144.8 — 141.5 160.9 129.7
32,768 165.5 — 156.6 157.0 123.8
128,000 153.7 — 143.2 142.2 108.3
256,000 136.7 — — 120.7 98.9
~31,000（probe） 173.7* 125.0 113.7 183.1 —

* 第一輪 A（2026-10-01-5090-only）在 4K/32K/128K 是 170.3 / 173.7 / 153.7；同一方法重跑（-4targets）是 144.8 / 165.5 / 153.7。4K 的離散約 15%，所以單次差異小於 10% 沒有統計意義。

chart2_decode_by_config.png

Prefill tok/s / TTFT：

prompt A 5090 B3 K=36 C 3-GPU
4,096 2,857 / 1.5 s 1,893 / 2.2 s 1,278 / 3.2 s
32,768 4,187 / 7.9 s 4,136 / 8.0 s 2,298 / 14.3 s
128,000 4,257 / 30.3 s 5,017 / 25.7 s 2,886 / 44.5 s
256,000 4,079 / 63.2 s 4,993 / 51.7 s 2,773 / 92.8 s

我看到的東西：

  1. 256K 以下，prompt-heavy 工作的最佳配置是 B3。256K prompt 加 1–8K 輸出時整体較快；但 pure long-decode 仍然以單 5090 為佳。
  2. 每加一個 stage 便损失 decode：136.7 → 120.7 → 98.9。第三張卡雖然持有 100% 的 experts，卻是全部分段最差。
  3. Remote cache 是第二張卡的錯誤用法（remote_experts.cpp:140-148：只分配第一張卡尚未 claim 的 pairs）——1,057 次 layer launch 裡 2,919 個 entry、28.5 MiB（unpacked 388.3 MiB）、等待 368 ms、GPU 使用率 0–12%。第一張卡已經持有熱的 68%（約 99.4% 的 routed mass）。
  4. 手动 split 才真正用到第二張卡。K=36 時 5080 擁有 12 層、cache 其全部 6,144 個 pairs，request 期間 GPU 使用率 38–99%，24,208/24,576（98.5%）的 experts 在 VRAM。較窄的 split 較差：auto 按预測的 window 時間選了 K=47，讓 5080 有 9.87 GiB 閒置。
  5. 代价是 x4 PCIe link 和每個 verify window 一次 hand-off。兩張 helper 卡 probe 為 6.5 GB/s；三個 stage 增加第二次 hand-off，所以 32K prefill 從 4,136 掉到 2,298 tok/s。
  6. CPU 是設計上必須工作，不是 cache miss。engine 的 idle CPU 是 0%，但 256K request 期間 strata.exe 是 950–1,040%（約 10 個核心）——QSA/GDN/rope 的 host-side path，除非啟用 --native-qsa、--native-gdn、--native-rope。decode 期間的 expert hit rate 測得 99.9%。
  7. RAM 是 256K 的真正上限。3-GPU 的 256K 執行用掉 58.9 / 61.4 GB（96%）。
  8. Warm-up 要算進去。啟动後第一條 request 較慢（B3 的 4K prefill 在 ladder 裡是 1,893，後续 probe 是 3,155）。

3. Phase 4：記憶體與速度 flags（同一台機器、同一條 256K request，以 B3 為主）

--mmap-experts 在速度上是免費的，而且把 25.6 GiB 的 locked arena 換成可被 OS 回收的 file-backed pages。

variant prefill tok/s decode tok/s TTFT available RAM strata WS WS private
B3（resident arena，int8 KV） 4,945 114.8 52.2 s 3.0–3.4 GB 37.4 GB ~37 GB
B3 + --kv q4_0 4,047 115.6 63.6 s 5.1–5.4 GB 40.0 GB 39.9 GB
B3 + --mmap-experts 4,850 119.4 53.2 s 3.2–3.6 GB 42.1 GB 8.0–8.2 GB
A 5090 only + --resident-experts 3,929 116.3 65.6 s 23.0 GB 17.8 GB 15.2 GB
A 5090 only，resident arena（control） 4,079 136.7 63.2 s 未取樣 — —

三件事值得講：

  • --mmap-experts 速度不變，但 lock 消失了：25,626 MiB 的 VirtualLock arena 變成 file-backed pages（clean、可被 OS 回收）。Windows 的「available」counter 仍然偏低，因為 mapped GGUF pages 仍 resident，但它们跟 locked arena 不是一回事。
  • --resident-experts = --mmap-experts --resident-cpu-experts + resident_pin + resident_soft + resident_headroom = 4 GiB（generate.cpp:1177-1187）。環境變量可覆盖：STRATA_RESIDENT_PIN=0、STRATA_RESIDENT_HEADROOM_GIB=N。--resident-cpu-experts 要求 --mmap-experts 與 static --expert-profile，並且拒絕 layer split 與 remote cache（1279-1288）。
  • --shared-expert-arena 是 Linux-only，這裡用不了。

順帶一條：這就是為什麼 §1 說 SSD 那一層跟 --resident-experts 爭同一份 RAM。26.6 GiB 的 parking 预算把可用 RAM 壓到 13.58 GiB，减去 4 GiB headroom 只剩 9.58 GiB，而 resident complement 需要 10.53 GiB——所以引擎報 warning、fallback 到 mmap。兩個 arm 都在這個條件下跑，所以 §9 的 A/B 仍然成立。

4. Phase 5：兩個獨立 instance（真正的 C=2）——兩次都不可行

平行效率 0.33×（C:）和 0.17×（F:）。瓶颈是 VRAM，不是磁盤帶寬。

Instance 1（5090，port 18081，--resident-experts，16,920 slots / 23.2 GiB，15 pool workers）跟 instance 2（5080，port 18082，--mmap-experts，6,503 slots / 8.71 GiB = 26.5%，8 pool workers，無 vision），兩者 context 都是 262,144。Workload：一條 23,523-token prompt、greedy、128 輸出 token、streaming。

lane TTFT total decode expert hit VRAM
5090（18081） 7.00 s 8.42 s ~90 tok/s 94.3% 31.1 GB used
5080（18082，C:） 48.55 s 53.10 s ~28 tok/s 56.9% 14.8 GB used，445 MiB free

兩條 request 的 batch：在 5090 排隊是 14.27 s，兩條 lane 平行是 42.62 s → 0.33×。

第二次我把 pack、兩個 GGUF shard 與 MTP head（72.1 GB、74 個文件）用 robocopy 複制到空閒的 F: NVMe（GIGABYTE GP-ASM2NE6100TTTD，Gen4，397 GB free），耗時 18 s（4.2 GB/s），instance 2 改讀 F:，flags 跟先前相同（--mmap-experts、6,503 slots、262K context）。測試結束後那份複制已删除，F: 目前不含任何 Strata 文件。

lane TTFT total engine prefill engine decode
5090（C:，--resident-experts） 8.61 s 9.36 s 2,799 tok/s 162.3 tok/s
5080（F:，--mmap-experts） 72.56 s 77.27 s 325 tok/s 26.9 tok/s

兩條 request 的 batch：排隊 12.86 s，平行 73.55 s → 0.17×。先前 😄 版本（0.33×）之所以較快，只因為 😄 已有 26.4 GB 的 warm standby cache，而 F: 從冷狀態開始。

  • 2 秒取樣：C: 讀取 0–26 MB/s（完全沒有 contention），F: 讀取 0.8–1.3 GB/s、約 70% disk time → 磁盤帶寬不是瓶颈。
  • Available RAM 從 10.9 GB 掉到 0.31 GB 並維持：file-backed pages 消耗 RAM 的方式跟 😄 相同。
  • Per-token cost：5080 lane 是 3.01 ms/token prefill、19.75 ms/token decode；5090 lane 是 0.25 與 4.07 ms/token。
  • 結論：第二條 lane 由 VRAM 決定。16 GB 卡需要約 7.9 GB 用於非 expert 部分，剩下 8.71 GiB 只能容納 24,576 個 expert pair 中的 26.5%；其餘 73.5% 走 mmap + CPU pool，即使 page cache 已 warm 仍需約 20 ms/token（引擎自身把 warm mmap 估為 34.78 ms/token）。第二條 262K lane 要快，必須用能容納 experts 的卡（也就是另一張 32 GB 級卡），或者用較小的模型。把文件搬到第二個 NVMe 不改變結果。

5. Phase 6：KV pool、parking 與 context ladder

能同時保留的對話：256K 4 條、384K 3 條、424K 3 條、448K 2 條、512K 以上 0 條。checkpoint 約 118 MB 跟 context 長度無關，真正的成本是 positional KV，約 17–19 KB/token。

5.1 Parking 的記憶體模型

SavedConversation 複制 ConversationKv（k、v、k_scale、v_scale、pooled rows；bytes() 用 .capacity()）與 ConversationCheckpoint（gdn、ple、tails、dead、block_pos）：

  • checkpoint（running state）約 118 MB，跟 context 長度無關（generate.cpp:804-815）：36 個 GDN recurrence、conv history、per-QSA indexer tail 與 PLE history。Positional KV 不由 checkpoint 複制，它被 rewind。
  • 真正的 parking 成本是 positional KV，約 17–19 KB/token（int8、12 個 QSA layer）。
  • 准入规则（generate.cpp:4009）：只有 needed + --conversation-cache-min-free-mib <= physically free RAM 才 park。「physically free」不含 Windows standby 與 file cache。
  • Parking 只支持單 GPU：generate.cpp:1220-1223 拒絕 --layer-split（"conversation parking does not yet support --layer-split"）。所以 B3 的 4,993 tok/s 與 parking 互斥。

diagram_memory.png

5.2 Context ladder（全部實測；parking budget 26,624 MiB / 4 slots / floor 1,024 MiB，256K 使用 18,432）

context YaRN factor KV pool（pinned RAM） expert cache resident arena cold prefill 相對 256K park/條 同時 parked
256K 1.0 2.32 GiB 16,982 / 22.77 GiB 通過，13.10 GiB 4,431 100% 4.20 GiB @241K 4
384K 1.5 4.64 GiB 16,815 / 22.56 通過，11.56 4,079–4,173 92–94% 6.19 GiB @380K 3
424K 1.65625 5.12 GiB 16,767 / 22.49 通過，11.52 4,010–4,083 91–92% 6.71 GiB @417K 3
432K 1.6875 5.22 GiB 16,757 / 22.47 通過，11.23 3,966–4,081 90–92% 6.82 GiB @425K 3，但需要 floor 512
448K 1.75 5.41 GiB 16,738 / 22.45 通過，11.13 3,946–4,024 89–91% 7.04 GiB @440K 2
512K 2.0 6.19 GiB 16,652 / 22.33 差 290 MiB 不通過 3,516–3,693 79–83% 需要 8,079 MiB 0（被拒）
1M 4.0 12.38 GiB 13,965 / 18.71 不通過 2,578–2,724 58–61% 需要 15,781 MiB 0（被拒）
  • Pool 由 boot 時可用的 RAM 決定，不由 context 固定。同一個 256K 與 --kv-resident 32768，三次 boot 報 2.32 GiB，另一次報 3.09 GiB。從 384K 往上是線性（4.64 → 5.12 → 5.22 → 5.41 → 6.19 → 12.38）。
  • Arena 與 parking 爭用同一份 RAM。512K 的 log 是 resident complement 10.69 GiB exceeds available RAM (14.40 GiB) minus the 4 GiB safety headroom，所以不通過、fallback 到 mmap、page cache 消耗 RAM，parking 被拒。1M 是 14.31 GiB exceeds available RAM (10.33 GiB) minus the 4 GiB headroom。
  • 1M 有兩個 variant，兩者都不可行：--kv-resident 32768（cache 15,974 / 21.44 GiB，arena 不通過：11.58 GiB 對 7.56 − 4.00）與 --kv-resident 262144（cache 13,965 / 18.71 GiB，arena 不通過：14.31 對 10.33 − 4.00）。上表的 1M 列用第二個 variant。512K 也測過 --kv-resident 262144，pool 仍是 6.19 GiB。

diagram_parking.png

chart1_context_ladder.png

5.3 各 context 的 log 原文

  • 256K（4 條 × 241K）：parked 241123 tokens ... parked=3 bytes=13536720828 evictions=0，四條全部命中，restored 241112 tokens (checkpoint) in 341.7 ms。
  • 384K（3 條 × 380K）：parked=3 bytes=19918823816 evictions=0；第 4 條被拒：skip parking (need 6332 MiB plus 1024 MiB floor)，當時 free 是 4,289 MiB（差 3,067 MiB）。重访是 2.38 / 1.90 / 2.15 s 命中，第 4 條 MISS（91.4 s 重新 prefill）。
  • 424K（3 條 × 417K，默認 floor 1,024 MiB）：沒有 skip 記錄；parked 417308 tokens ... bytes=7205814172、restored 416901 tokens (checkpoint) ... parked=2 bytes=20781436496（live 6.36 GB + 2 × 7.21 GB，即 3 條在 pool 中）。重访是 4.63 / 2.24 / 2.38 s 命中；decode 是 174.8 / 196.9 / 196.0 tok/s（accepted 299–300 / 400）。
  • 432K（3 條 × 425K）：floor 1,024 MiB 時第 3 條被拒：need 6986 MiB plus 1024 MiB floor，free 是 7,727 MiB（差 283 MiB）。改成 floor 512 MiB 後，同一组對話 3 條全部 park，重访是 4.72 / 2.19 / 2.30 s 命中，結束時 free 是 1,774 MiB。
  • 448K（2 條 × 440K）：bytes=7557571128（每條 7.04 GiB）、evictions=0、重访 4.68 / 2.56 s 命中；第 3 條需要 8.0 GB，而 free 只有 7.8 GB。
  • 512K / 1M：parking 被拒（need 8079 MiB plus 1024 MiB floor、need 15781 MiB plus 1024 MiB floor）。同一條對話的連续 turn 仍可通過 live checkpoint chain 重用（512K：TTFT 1.41 s、prefill 55 ms），但換對話便要重新 prefill（512K 的 A/B 交錯 → MISS、137 s；1M 命中 107.8 tok/s、cold 61.7 tok/s）。

6. 三個不利但重要的發現

縮短對話換不到第 4 個 slot；424K × 3 耗尽 headroom；slots 與 bytes 是兩件事。

1. 縮短對話無法換取第 4 個 slot。

380K、340K、330K 三次測試，3 條 park 完成後的 free RAM 都約 5.6 GB（4,289 / 5,585 / 5,615 MiB），第 4 條每次都差 1.0–3.0 GiB。省下來的 RAM 進入 file cache，而准入檢查只計 physically free RAM。要保留 4 條必須實際增加 RAM，或者接受 floor 接近 0（也就是沒有安全邊際）。

chart3_ram_headroom_384k.png

2. 424K × 3 會耗尽 headroom。

3 條 park 後 free 只剩 2.5 GB。當同時存在另一條 live 對話（真實 agent 流量，prompt 83–90K、hit rate 98%）時，RAM 達到 54.6 / 61.4 GiB，restore 從 1.4 s 變成 25.9–27.0 s（restored 416901 tokens (checkpoint) in 25918.3 ms）。

「可保留 3 條」和「hit path 仍然快」是兩件事。

機制尚未證明（最可能是 parked blob 需經 page cache），但觀察是實測。

3. Slots 與 bytes 是兩件事。

上面的上限指「每條對話接近完整 context」。同一個 424K config 在真實 agent 流量下，4 條 118–138K token 的對話可同時 parked（parked=4 bytes=20315885712、evictions=0），第 5 條才觸發一次 eviction（evictions=1）。所以「424K 可保留 3 條」指 3 條接近滿滿；如果每條約 130K，4 個 slot 仍可使用。

7. 配置建議（整個 campaign）

要 4 條就留在 256K；要 3 條就 424K。prefill 為主且不需要 parking 才用 B3。

  • 長 context 且同時保留 3 條對話：424K（--max-context 434176 --rope-scaling yarn --rope-scale 1.65625）加 --conversation-cache-mib 26624 --conversation-cache-slots 4 --conversation-cache-min-free-mib 1024。這是目前的 standing config。
  • 需要 4 條：維持 256K（每條 4.20 GiB，mib ≥ 18,432）。
  • 需要 432K 以上：432K 需要 floor 512；448K 只能 2 條；512K 需要 96 GB RAM 才有 headroom。
  • 如果 prefill 是主要工作（單次 256K prompt、不需要 parking）：B3 --layer-split 36，4,993 tok/s / TTFT 51.7 s。但它與 parking 互斥。
  • 投機窗口：--spec 4（§9）。--spec 8 沒有數據支持。
  • RAM budget：兩條 262K instance 約需 57 GB → 64 GB 是 practical floor，96 GB 較充裕，128 GB 有餘裕。

8. Strata 對 NInfer（同一台機器，全部用本機實測過的數字）

chart4_ninfer_compare.png

這一節第一版我寫錯了兩次：用了官方表，又把 Strata 含投機的 decode 直接對 NInfer 的 MTP0 列。下面全部改用本機自己的記錄——前三篇 1228、1462、1967 和本地 campaign 記錄（out/campaign_0902_mirror/、out/dflash3/campaign/、out/dflash3/campaign_v4/），並且把投機與否分開算。

8.1 真實 agent 流量（同一台機器、同一類工作、兩邊都開投機）

NInfer MTP3 era NInfer DFlash2 K=7 era Strata --spec 4
期間 / 樣本 09-04 → 09-07，12,479 req 09-07 → 09-08，5,879 req 10-01 → 10-02，282 個 agent request（prompt ≥30K）
prompt 中位 72,062 72,492 167,244
cache 命中 79.8%（加權）/ 97–99%（per req） 82.3% / 97–99% 98.9%（per req）
decode 中位 143.6 183.4 155.1
decode p95 / max 192.1 / 342.9 282 / 436.9 191.9 / 216.7
acceptance（加權） 60.7% 33.0% 77.5%
tokens/round 2.82 3.31 3.07
並發 C=3（真 batching） C=3 C=1（一次一個 request）

口徑相同時 Strata 155.1 介於 NInfer 兩代之間：優於 MTP3（+8.0%），不及 DFlash2（−15.4%）。

但 NInfer 那兩栏是 C=3 真 batching，Strata 是單 request 一條 lane。所以這裡比的是單條 lane 的 per-request 速度，不是吞吐。

另外 Strata 的 prompt 中位數（167K）比 NInfer（72K）大得多，樣本也小得多（282 對 12,479）。這一點我要講清楚，不然數字會誤導。

8.2 無投機口徑（prompt 長度對齊）

prompt Strata（無投機等价，下限） NInfer MTP0（09-02 本地 run）
8K 61.1 69.3
64K 69.8 63.7
128K 62.0 58.5
256K 55.5 50.3

Strata 那一列不是我直接量的。引擎在 native (IQ) pack 上拒絕 --spec < 2（generate.cpp:1738-1743、generate.cpp:3611），所以 Strata 沒有真正的 MTP0 數字。它由 log 中每個 request 的投機統計推算：rounds = 生成 token − 被接受 draft，round rate = rounds ÷ decode 時間。因為 verify window 比單 token 前推更贵（suffix_drafter_test.cpp:3：每 token 約多 10 ms），這個數是下限。

口徑對齊後兩邊基本相同，Strata 在 64K/128K/256K 略勝。原本「NInfer decode 快 1.6 倍」是口徑不對齊造成的。

8.3 Prefill（不受投機影響）

prompt Strata NInfer（post 1462 solo prefill，本機） NInfer（09-02 本地 MTP0 run）
4K / 8K 2,857（4,096） — 8,621（7,680）
32K / 47K 4,187（32,768） 6,004（47k） 5,316（64,512）
105K / 128K 4,257（128,000） 4,096（105k） 3,635（130,048）
143K / 157K — 3,403 / 3,174 —
210K / 256K 4,079（256,000） 2,587（210k） 2,224（260,096）

小 prompt 的差距（3–6 倍）是真實的：Strata 的 prefill 受 PCIe expert streaming 限制（probe 52 GB/s、pcie_frac 0.55）。但到 105K 以上兩者已經接近甚至反轉（Strata 4,257 對 NInfer 4,096；256K 4,079 對 2,224）。

TTFT 也一樣：NInfer 09-02 run 在 128K/256K 是 35.8 / 117.0 s，Strata 是 30.3 / 63.2 s。只有 8K 時 NInfer 更快（0.90 s 對 1.5 s）。

8.4 DFlash

Strata 沒有 DFlash 等价。它的投機是 MTP window 加 suffix lookup（--suffix-draft 3、--mtp-max-t）。NInfer 的 DFlash2 是 5 層 draft（約 1.6B 參數），每 round draft 7 token 再 verify；本機實測 K=7 C=1 corpus 198.7 tok/s、acceptance 36.6%、每 round 3.31 token（post 1967）。Strata 的 MTP+lookup 每 round 3.07 token（真實流量加權），量級接近 MTP3（2.82），達不到 DFlash2 的 3.31–6.5。

架構上的分別：NInfer 支持 C=1–8 真 batching 與 context cache（prefix reuse、anchors、host KV tier）；Strata 的 serve 一次只處理一個 request，跨對話重用要靠 parking，而 parking 只支持單 GPU。NInfer 跑不了 IQ2_XS（expert 文件 34 GB 超出 32 GiB VRAM，且沒有 CPU expert tier）——這裡是引擎對引擎，不是同一個 model。

9. 投機窗口：--spec 4 對 --spec 8（實測 A/B）

同一台機器、同一個配置、同一方法，只改 --spec。
--spec 8 贏在每 round 的 token 數，輸在每秒的 round 數——淨結果是 decode 慢 2–8%。

prompt spec 4 decode spec 8 decode Δ tokens/round（4 → 8） round/s（4 → 8）
4K 148.9 145.2 −2.5% 2.44 → 3.01 61.1 → 48.2
32K 165.0 151.3 −8.3% 2.53 → 2.84 65.1 → 53.2
128K 146.0 142.8 −2.2% 2.53 → 2.88 57.6 → 49.6
256K 127.8 124.0 −3.0% 2.35 → 2.81 54.4 → 44.1

兩邊都是 3 runs 取中位數、同一配置（424K + parking 26,624 MiB / 4 slots / 1,024 MiB floor）、同一 --spec-min-p 0.5。
4K 的第一輪是冷 cache（prefill 536 / 544 tok/s），中位數不受它影響。

為什麼輸

接受率下降：spec 4 是 65–72%，spec 8 是 46–65%。窗口越深，條件接受率越低——第 4 個 draft 之後的 token 不值得 verify。

spec 8 每 round 多產出 0.4–0.6 個 token，但每秒少做 12–17 個 round。
多出來的 draft 要付 verify 時間，換回的 accepted token 抵不上成本。

這個結果跟引擎自己的 cost model 吻合。controller.hpp 的常數（2026-09-23 三場測量）在 0.86 prior 下算出 optimum 是 k=3 drafts（window 4），也就是 --spec 4；用 draft_policy_test.cpp 那條實測 cost 曲線（19.0 + 10.5·(t−1) ms）算，optimum 是 k=2–3。而 log 顯示 spec 4 實際使用的窗口是 2.2 drafts/round——policy 自己選的就是 optimum。spec 8 把 cap 抬到 8，policy 開始 over-draft。

--spec 的硬上限是 8（kVerifyMaxT）。--spec 4 實際 effective cap 是 6（--suffix-draft 3 加 2），MTP window 上限 4；--spec 8 是 cap 8、MTP window 8。

所以：--spec 4 是這台機器的最佳值，--spec 8 沒有數據支持。 想再往上只有靠 lookup window，而 policy 已經逐 case 自己選。

10. 沒測和沒做完的

  • IQ3（ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF）的速度 A/B（5090-only 與 5090+5080 K=36 兩個 config）還沒跑。文件已下載完成，四份都跟 HF API 逐 byte 核對：IQ3_S 54,817,524,224 / 28,800,138,432；IQ3_XXS 47,039,860,096 / 28,800,138,432。
  • YaRN 延伸的 quality 我沒測。1.5–4.0× factor 完全沒有 needle 或 perplexity 測試。這篇所有長 context 數字是速度與容量，不是 accuracy。
  • 沒試的 candidates：--kv k8v4（816 對 1,056 B/cell，不能與 --kv-resident 並用）、--kv-resident 的 cell 數、--expert-cache-per-layer（參考測量的 2.97% → 21.4% hits at 8K）、--prefill CHUNK（auto = 8192）、--ple-io mmap|ram、--pool-workers / --no-host-worker，以及 MTP knobs（--mtp-max-t、--spec-min-p、--suffix-draft；--spec 已測，見 §9）。
  • --shared-expert-arena（Linux-only）沒試。

11. 複現

Phase 1–5：benchmark.py --targets 4096,32768,128000,256000 --runs 3，每個 config 一份 config-used.json、metrics.json、summary.json、results.json、raw per-request JSON 與 startup.txt。

Phase 6：改 --max-context 與 --rope-scaling yarn --rope-scale <factor>，boot 後發送 3–4 條接近上限的獨立對話，看引擎 log 的 conversation cache: 記錄（parked=N bytes=B evictions=E、skip parking (physical RAM admission; need X MiB plus Y MiB floor)）與 /metrics 的 conversation_cache_mib / slots / min_free_mib。准入檢查用的「free」跟 FreePhysicalMemory 是同一口徑，差額可直接核對。

Phase 8（§9）：同一 config 跑兩次，只改 --spec，artifacts 在 2026-10-02-spec8/ 與 2026-10-02-spec4/。

Artifacts：2026-10-01-5090-only/、-5090-only-4targets/、-5090plus5080/、-5090plus5080-remotecache/、-layersplit-K36/、-layersplit-K36-256k/、-layersplit-K36-256k-r3/、-3gpu-K28-42/、-memctl-B3/、-kvq4-B3-256k/、-mmapexperts-B3-256k/、-residentexperts-A-256k/。Phase 6 沒有 artifact 目錄（即時執行，僅有引擎 log）。

12. 參考

]]>https://lcz.me/topic/2038RSS for NodeMon, 12 Oct 2026 13:30:10 GMTThu, 01 Oct 2026 21:14:31 GMT60<![CDATA[Reply to [實測IV] Strata / Qwen3.8 Flash IQ2_XS 單卡跑到 424K 155t/s — parking 能留幾條對話：含三個不利發現 on Sat, 10 Oct 2026 04:04:10 GMT]]>能上IQ3_S 肯定用它了，基本上我只考虑IQ4 XS，还有UNSLOTH UD Q4 XL，这几个的KLD PPL最漂亮。

]]>https://lcz.me/post/23683https://lcz.me/post/23683Sat, 10 Oct 2026 04:04:10 GMT<![CDATA[Reply to [實測IV] Strata / Qwen3.8 Flash IQ2_XS 單卡跑到 424K 155t/s — parking 能留幾條對話：含三個不利發現 on Fri, 09 Oct 2026 13:11:57 GMT]]>@stxpnet 我在dsh上跑了上跑了一周(1/10 -6/10)高強度的用也沒發生也沒發生循環問題

現在用IQ3_S也沒問題

IQ3_S 在 DSH 上的實際平均速度

資料來源：strata-iq3_s-5090.log，涵蓋 2026-10-06 16:09 → 2026-10-09 12:52（2.85 天），11,241 個 request、12,502,938 個 generated tokens、26.56 小時的 decode 時間。

指標 值
decode（加權平均，總 token ÷ 總時間） 130.8 tok/s
decode 中位數 129.4 tok/s
decode 算術平均（每 request） 128.4 tok/s
p10 / p90 109.7 / 146.2 tok/s
min / max 7.8 / 237.2 tok/s
prefill（加權平均） 2,832 tok/s
含 prefill 的端到端 113.6 tok/s
平均每 request 1,112 generated tokens，prompt 129,900 tokens
prefix reuse 97.2% 的 prompt tokens

按 context 大小（加權 decode）：

prompt tokens n decode
60K–100K 2,383 131.4
100K–140K 3,298 130.6
140K–170K 2,568 131.9
170K–300K 2,439 127.1

幾乎平的 —— 到 170K 以上才掉 3.3%。

跟 IQ2_XS 同一張卡、同樣真實流量的對比

strata-iq2_xs-5090-maxslot.log（10-04 → 10-07，10,153 requests、8,780,547 tokens）：

IQ2_XS IQ3_S 差
decode 加權 167.8 130.8 −22.0%
decode 中位 168.4 129.4 −23.2%
p10 / p90 143.4 / 193.8 109.7 / 146.2
含 prefill 136.4 113.6 −16.7%
prefill 2,407 2,832 +17.7%（IQ3_S 較快）
prefix reuse 97.9% 97.2%

一個跟我之前 benchmark 不一致的地方（要講清楚）

我之前那輪受控測試（4,096 token 隨機 prompt、greedy、128 tokens）量到 IQ3_S 比 IQ2_XS 慢 34.4%。真實使用只有 22.0%。原因是 benchmark 用隨機 token 檔 + greedy，draft acceptance 很低（50 of 92）；真實文字好預測得多，加上 97% 的 prefix reuse 讓 expert hit rate 不同。所以真實懲罰比 benchmark 小，兩個數字我都留著。

這組數字的限制

  • log 是 engine 的 serve log，18081 就是 DSH 的 backend，所以這些是 DSH 打的 request；但我無法把 DSH 跟其他打同一個 port 的 client（例如 chat 網頁）分開。
  • DSH 自己的 dsh-token-usage\index.json 是舊的（writtenAt 2026-08-20，而且完全沒有 strata 那列），所以無法交叉驗證。
  • serve log 的行沒有時間戳，所以做不出每日分解。
  • 這個窗口包含 10-06 16:09 那個 18085 實驗（短暫共存）和 10-07 16:18 用 bat 啟動的那次 —— 都算在 11,241 個 request 裡。

4/10 加ram了(64GB -> 192GB) 中間速度(3600-4800 MT/s)有浮動不太準 現在穩定在4800 MT/s

image.jpeg

]]>https://lcz.me/post/23591https://lcz.me/post/23591Fri, 09 Oct 2026 13:11:57 GMT<![CDATA[Reply to [實測IV] Strata / Qwen3.8 Flash IQ2_XS 單卡跑到 424K 155t/s — parking 能留幾條對話：含三個不利發現 on Tue, 06 Oct 2026 02:36:38 GMT]]>@stxpnet 所以跑分和实际开发还是完全不同的。

]]>https://lcz.me/post/22721https://lcz.me/post/22721Tue, 06 Oct 2026 02:36:38 GMT<![CDATA[Reply to [實測IV] Strata / Qwen3.8 Flash IQ2_XS 單卡跑到 424K 155t/s — parking 能留幾條對話：含三個不利發現 on Sun, 04 Oct 2026 05:19:16 GMT]]>IQ3_S循环也很厉害，暂时没有找到解决方案， 要跑实际真实的项目。

]]>https://lcz.me/post/22254https://lcz.me/post/22254Sun, 04 Oct 2026 05:19:16 GMT<![CDATA[Reply to [實測IV] Strata / Qwen3.8 Flash IQ2_XS 單卡跑到 424K 155t/s — parking 能留幾條對話：含三個不利發現 on Sat, 03 Oct 2026 14:41:27 GMT]]>Q2量化是不是太严重了，IQ3_S就差不多了。

]]>https://lcz.me/post/22134https://lcz.me/post/22134Sat, 03 Oct 2026 14:41:27 GMT