負結果：試過但沒留下的最佳化
記錄在 8 GiB 上量過、放棄的選項。每一項都有原始資料在
bench/results/strict_prefetch.json 與 bench/results/strict_threads.json。
1. 預取（關閉）
pager 可以從上一個 token 的路由預測下一層會用到哪些 expert，在本層計算的時候 先把資料讀好。三種設定各 6 輪，交錯執行：
| 設定 | 平均 tok/s | 單輪標準差 | 單輪全距 |
|---|---|---|---|
| 關閉（預設） | 6.03 ± 0.44 | 0.44 | 5.55 – 6.68 |
跨層預取 SDQ_PREFETCH_LAYER_AHEAD=1 |
5.95 ± 0.37 | 0.37 | 5.38 – 6.29 |
僅 end_token SDQ_PREFETCH=1 |
5.78 ± 0.33 | 0.33 | 5.45 – 6.27 |
三者差異遠小於單輪抖動，統計上無法分辨。 而且預取開著時 SSD 讀取量 在多數輪次是上升的（預測不夠準，多讀的全是白讀）。
更嚴重的是正確性問題：預取佔用的槽位（busy）會讓 acquire() 偶爾拿不到槽位，
而舊版的失敗處理是靜默跳過一個 expert。預測率不到 1% 的最佳化不應該
承擔這個風險。
預設關閉。 程式碼保留（SDQ_PREFETCH_LAYER_AHEAD=1 可以重現），
免得後人重新發明。
2. 執行緒數（預設 8，但 12 更好）
| threads | 平均 tok/s | 單輪標準差 |
|---|---|---|
| 4 | 4.65 ± 0.22 | 0.22 |
| 8 | 5.96 ± 0.45 | 0.45 |
| 10 | 6.16 ± 0.48 | 0.48 |
| 12 | 6.35 ± 0.51 | 0.51 |
| 16 | 6.27 ± 0.35 | 0.35 |
這個結論與參考實作相反。 參考的 Qwen3.6-35B-A3B 是純 transformer， 每層每 token 只有 8 個 expert 可以平行，加執行緒只是在搶同一批 CPU， 實測 8 → 12 → 16 是下降的。
MiniCPM-V-4.7-35B-A3B 是混合架構：40 層裡只有 10 層是全注意力，
其餘 30 層是 SSM 層（見 DESIGN.md §1）。SSM 層的計算不受序列維度限制，
可以吃滿更多執行緒，所以 12 執行緒比 8 快約 6.5%。
這是本模型與參考實作最實際的一個行為差異，也說明「執行緒數」這種設定 不能從上一個模型照抄。 8 保留為預設（與標配量測一致），12 是建議值。
4 → 8 是真實且顯著的提升（4.65 → 5.96，+28%）。8 之後的差異（8/10/12/16） 都在單輪抖動之內，不足以支撐更細的宣稱。
3. 單一尺寸槽位（放棄）
把所有槽位都配成最大的那種（SDQ_FORCE_UNIFORM_SLOT=1）最簡單，代價是
同樣的 arena 少掉約 18% 的槽位。本模型兩種 expert 大小相差 15%
（2,039,808 vs 1,769,472 B），所以分級槽位的收益比參考實作小，但仍然是免費的。
驗證用的 prefetch_stress_check 兩種配置都跑，確保分級槽位的配置器正確。
4. 端到端 A/B 對照（做不到）
需要把整個 21.17 GB 模型常駐 RAM 作為對照組。在 8 GiB 上不可能，
這正是本專案存在的理由。見 STRICT_8GIB.md §3。