护城河:从真实推理到跨架构

引擎能跑了、能导出真实轨迹了,第 4 章那个合成结果就能换成真的。这一章是整个项目的兑现点

1. 把真实推理接进 M2 策略

BuildMoe 里那个 selected(每 token 每层选中的专家)加了个可选出参暴露出来;generate.ccGreedyGenerateCachedTrace 每步把它读出、按 token→layer 序填成一条 RoutingTrace。生成结果与不导 trace 时逐 token 一致(trace 是旁路)。

olmoe_trace 工具把这条真实轨迹喂给第 4 章的三种策略。真实 OLMoE 推理上,learned-pin 稳定赢 LRU/OS 6~9pp。 M2 的模拟结论,在真实推理路径上复现了。

2. 曲线 + 跨领域:预算越紧,优势越大

trace_sweep 提供了 model-free 的 trace_replay——读一条轨迹、秒级扫多个预算(不重载 4GB 模型)。跨 story / fact / code 三种 prompt,learned − LRU 的优势:

每层预算(共 64 专家) story fact code
4 (6%) +17.5 +15.5 +24.2
8 (12%) +9.1 +9.4 +15.7
16 (25%) +6.4 +8.4 +10.6
32 (50%) +8.1 +11.4 +7.9

关键规律:预算越紧,优势越大。 budget=4 时,OS 全局缓存直接 0% 命中(整个 64 槽全局池彻底 thrash)、per-layer LRU 也只有 3~5%,而 learned 靠钉住热专家仍有 20~29%(+15~24pp)。也就是——内存越受限(正是流式最该用的场景),朴素缓存越崩,学习缓存越值钱。 三个领域一致成立。

3. pin/lru 配比:数据否掉了我的假设

SweepPinRatio 固定总预算,把 learned 的 pin 槽数从 0(≈纯 LRU)扫到 budget(全静态最热)。我原以为最优在中间(钉一部分、留几格 LRU 兜临时热点)。实测(OLMoE,预算 16)却是单调向上:pin=0 命中 48.0%,pin=16 命中 57.8%——越静态越好

原因:OLMoE 的专家使用不仅偏斜、而且稳定(热专家从头热到尾),LRU 的”最近使用”几乎不加值,静态钉全局最热即最优。

数据否掉直觉时,信数据。 同时如实标注一个诚实的注脚:这里的 usage 直方图是从被重放的同一条轨迹建的(in-sample),pin=budget 因而偏乐观;真实部署应从一次校准跑建直方图、用到新输入——那时 LRU 兜分布漂移会更有价值。”跨输入迁移”是更严谨的后续问题。

4. 跨架构:granite,而非 26GB 的 Mixtral

最后一个质疑:这会不会是 OLMoE 专属?于是换一个完全不同的 MoE 验证。

Mixtral 8x7B 即便量化也 ~26GB,而且 nuthatch 引擎不支持它的架构。但验证缓存结论并不需要把它跑进 nuthatch——只要它的路由轨迹。于是选了 821MB 的 IBM granite-moe:1b(24 层 / 32 专家,与 OLMoE 迥异):给 llama.cpp 的 eval-callback 打个小补丁,把 ffn_moe_topk 张量 dump 成文本轨迹(提取法见 docs/cross-arch-trace.md,轨迹附在 data/granite3moe.trace.txt),再 trace_replay --text:

granite 预算/层(共 32) learned LRU OS learned − LRU
4 (12.5%) 22.4% 4.7% 0.0% +17.7 pp
8 (25%) 40.1% 30.4% 30.2% +9.7 pp
16 (50%) 71.6% 62.7% 61.5% +8.8 pp

同一规律,异构模型上成立——learned 赢 +8.8~17.7pp,同样”预算越紧越赢”。护城河不是 OLMoE 专属。

5. 一条证据链

到这里,护城河从一个假设变成了一条可复现的证据链:合成轨迹(第一个信号)→ 真实 OLMoE 推理(6~9pp)→ 曲线 + 跨领域(6~24pp,预算越紧越赢)→ 跨架构 granite(+8.8~17.7pp)。每一环都有数据,每一步引擎的正确性都用对拍或 parity 锚住。

但这一切还是在全常驻的引擎上测的——命中率结论不需要物理搬运专家。要让”流式”名副其实、真省内存,还差一步。

下一章:物理流式:选择性加载与两段式前向


This site uses Just the Docs, a documentation theme for Jekyll.