为什么我显示只有29G，这样就成功了吗？

修改前（平均值）：
预填充：5078.53
解码：124.986

修改后（平均值）：
预填充：5316.73
解码：186.566

预填充提升：4.69%
解码提升：49.27%

预填充几乎没有变化，解码速度提升近50%，这有点惊人了。

run2
• 改前 4KB（line 651-661）: 36.8
• 改後大頁（剛跑，line 864-886）: 50.5

run3
• 改前 4KB（line 651-661）: 37.0
• 改後大頁（剛跑，line 864-886）: 52.2

run4
• 改前 4KB（line 651-661）: —
• 改後大頁（剛跑，line 864-886）: 51.5

run5
• 改前 4KB（line 651-661）: —
• 改後大頁（剛跑，line 864-886）: 52.4

中位數
• 改前 4KB（line 651-661）: 36.8
• 改後大頁（剛跑，line 864-886）: 52.2

提升：+41.8%（36.8 → 52.2 tok/s）

對3060這工業拉機來說....這已經是神蹟了 我5090可以拿去賣了

· Windows 上这个权限叫 SeLockMemoryPrivilege；log 里的 error 1314（ERROR_PRIVILEGE_NOT_HELD）就是没拿到锁页权限，拿到后引擎会打 using large pages。
· 4KB→大页那 9% 在长上下文/大 MoE 上更明显（TLB 未命中集中在每个 expert 的 matvec），短 prompt 聊天几乎测不出来；对比时固定 ctx 和 batch 才有意义。

Linux 侧对应的是 THP / MAP_HUGETLB，不是开个开关就完事，得看 allocator 是否真用上——/proc/<pid>/smaps 里的 AnonHugePages 可验证。

贴子里引的源码，我逐条查了你本地 0.1.41 的代码，全部对得上：
include/strata/core/pinned.hpp:9-14 —— 原话就是「33.97 GB at 4 KB pages is 8.3 million TLB entries, which does not fit in any TLB, so every block of every expert matvec takes TLB misses」，并把 4 KB 退回称为 "the common case and not an error path"。你机器是 42.9 GB，TLB 条目只会更多。
src/core/pinned.cu:101-105 —— 官方自己把三个错误码分开注释：1314 是权限未 assign、1450 是大页池碎片、87 是大小非 2 MB 倍数。贴子让你别把它们当同一个 bug，这点是照抄上游注释，说明作者真读了码。
docs/DETAILS.md:510, 515 —— 官方文档本来就有 "Large pages need a new logon (#1412)" 一节，明确说 secpol.msc → 用户权限分配 → 锁定内存页，必须重新登录（token 在会话启动时才生成）。
STRATA_NO_LARGEPAGES=1 这个 A/B 开关确实存在于 pinned.cu:88-89，注释写着 "same run, same boot" —— 作者做单变量验证的办法是真能跑的。
所以你不是在被安利一个玄学调参，是在补一个上游已知、文档有写、但默认没帮你开的 Windows 特权。
️ 一个容易踩的细节：我核对源码时发现 "resident without a lock" 不是病症，是治愈的标志——pinned.cu:416/444/487 那句是 #779: large pages cannot be paged out: nothing to lock，只有大页成功时才会打。贴子把它和 error 1314 并列让读者去搜，容易让人误判。
你今天能做的（一行命令，零风险）
以管理员开 cmd：
secpol.msc
本地策略 → 用户权限分配 → 锁定内存页 → 加入你的账号 → 注销并重新登录（或重启）​。
然后重起 Strata，再看日志那行。变成 large pages (2097152 B) 就成了。

我怎麼排除記憶體升速的干擾

同日我把 RAM 從 4800 換到 5200，兩件事一起變，所以 5090 那組分不開。引擎在 pinned.cu:88 留了一個開關 STRATA_NO_LARGEPAGES=1，註解寫「same run, same boot」，所以我用閒置的 5080 跑了一次同開機、同記憶體速度、只差這個變數：

每輪快 31.1%，差異 92% 落在「GPU 等專家串流」那項。最有力的是 pool 那行：關大頁那邊每層 CPU 專家只有開那邊的三分之一（1.23 對 3.92），做少三倍的事，時間還更高（40.623 對 37.910）。

而 prefill 兩邊一模一樣。prefill 是整台最吃記憶體頻寬的階段，如果 4800→5200 有實質幫助它一定動 —— 它没動。所以 5090 那 8.9% 基本全部是大頁。

限制：兩邊專家路由發散了（每層 CPU 專家 3.92 對 1.23），所以 −31% 只取方向不取倍數；而且 5080 只有 12% 專家常駐（5090 是 35%）、x4 連結、卡本身慢，都是只取方向的理由。

同一個設定的擺幅

同一個設定（spec 8、fetch 開、大頁開）一天內量五次：131.2 / 129.9 / 114.9 / 120.3 / 121.3，擺幅 11.5%。真實 agent 流量的上下文長短自己會變。所以這篇所有對比只用前後接著跑的兩組，5% 以內一律當沒發生過；跌 15% 以上的才站得住。

被否決的參數（前後接著跑）

--pool-workers 24 值得講：log 印「24 pool workers on logical processors 2,4,...,30」，24 個 worker 只列了 15 個邏輯核心。超出核心數的 worker 不綁核，會跟做 GPU 交接的主執行緒搶位置。想加 worker 之前先確認自己的核心數。

--pcie-frac 從預設 0.25 提到 0.35 完全沒分別（121.3 對 120.8），接受率升 2.6 個百分點但多出來的串流成本剛好抵消 —— 平台區，作者的預設值在我這台也對，雖然我是 Gen5 x16。

--spec 8 對 --spec 6 係 +4.6%，兩個唔同記憶體條件下重複出同一個倍數。這跟 2038 §9「--spec 4 才是最佳值」相反，但量化、記憶體容量、pcie_frac 都變了，兩篇都別外推到對方的條件。另外 kMaxT = 8 是硬上限（draft_policy.hpp:24、verify_kernels.hpp:21），構造時 std::clamp 就夾住，所以 --spec 12 靜默變回 8，不報錯、不變慢，就是沒效果。

我撤回的三個結論

一、--spec-split「重疊本身賠 17.9%」。 早期量到 92.0 tok/s，對當時基準 −29.9%，我就當成重疊的鍋。後來連續跑三組設定、中間不隔時間重測才拆開：PCIe fetch 開對關 +7.3%（中位數 +18.7%），重疊開對關（fetch 都關）只有 −3.5%（中位數 −0.5%）。那個 −30% 大部分是流量自己變了。 一個看起來很紮實的 −30%，重測變成 −3.5%。

順帶講為什麼我最後沒改引擎的碼：--spec-split 預設關閉並關閉 fetch 不是保守，是正確性 —— fetch 靠逐出另一個專家來收新的，逐出規則是「本視窗沒用到的才逐出」（expert_source.cpp:3390），而 split 把視窗切兩半，第一半看不到第二半需要誰。修法存在，但用上面的分解算，把 fetch 接回去也只是從落後 10% 變回打平。

二、「流量擺幅只有 0.5%」。 我只看了頭兩次採樣（差 0.5%）就以爲這台很穩定，拿那個 0.5% 去判所有對比。實際擺幅 11.5%。連帶影響：--suffix-draft 8、--lookup-chain 3、--spec 6 這三項改列「還不能確定」，不是出局。

三、「prefill 撞到的是電，557 W 對 600 W」。 這個是在寫這篇的過程中被推翻的。

用 1 秒取樣抓了 15 分鐘、798 個樣本（同一台 5090、同一個設定、真實流量）：

形狀：功率是尖峰型的，不是平台型的。 它會瞬間衝到 592 W 貼住上限，但 GPU 忙著的時候中位數只有 295 W —— 多數時間離上限還有 300 W 的餘裕。而供電限制旗標和降速旗標，798 個樣本一次都沒亮。

所以「撞到供電牆」沒有直接證據。剩下唯一的線索是時脈：最高 2940 MHz，從來沒碰到 3090 的最大加速值。這符合供電受限的樣子，但也可能只是那 15 分鐘的溫度和負載就停在這裡。正確說法是「長 prompt 那段有一道我沒證明到的牆」，不是「供電牆」。

想自己抓一份，這條就夠：

nvidia-smi --query-gpu=timestamp,power.draw,power.limit,utilization.gpu,clocks.sm,clocks_throttle_reasons.sw_power_cap,clocks_throttle_reasons.hw_slowdown --format=csv,noheader,nounits -i 0

關鍵是最後兩個 clocks_throttle_reasons.*。只看 power.draw 會跟我一樣，被一個尖峰騙成一堵牆。

未測項目與已知限制

長 context 的品質（YaRN accuracy）完全沒測，這篇全部是速度和容量。大頁和記憶體速度沒做最嚴格分離，5080 那組是替代證據。STRATA_ADAPT_FETCH 另外兩個子參數沒測，因為 --pcie-frac 已經是平台區，同一條曲線上其他旋鈕大概率也在平台上。

三組格式的對照不是同一時期：引擎 0.1.31→0.1.41、記憶體 61.4→192 GiB、速度 6000→4800→5200、pcie_frac 0.55→0.25、--spec 4→8，而且大頁只有最後一組開了。所以那是三個完整設定的對比，不是單變量實驗；凡是我把差異歸給格式本身的地方，都是推論。

流量沒按 client 分開，18081 上所有請求混在一起算。這批 98.5% 在 60K context 以上（120–200K 佔 63.6%），所以 131.5 是長上下文 agent 的數字；短 context 只有 0.4% 的樣本（10 個），方向清楚但數量不足，實測 151.8。