第 3 章 · 03 学习型固定热存与工作负载记录 本节摘要:本节深潜 Colibrì 的"学习型"缓存——比 LRU 更进一步,让引擎越用越快(literally gets faster the more you use it)。机制是 文件:每 turn 更新,记录哪些专家被路由到;pinned hot-store(固定热存)根据历史自动把最热专家钉到 RAM/VRAM,常驻不驱逐。 的洞见是"路由结构可缓存"(structure is cacheable)——专家有可测量的主题亲和性(expert atlas),所以一个工作负载的热专家集合是可学习的。
本节摘要:本节深潜 Colibrì 的"学习型"缓存——比 LRU 更进一步,让引擎越用越快(literally gets faster the more you use it)。机制是
.coli_usage文件:每 turn 更新,记录哪些专家被路由到;pinned hot-store(固定热存)根据历史自动把最热专家钉到 RAM/VRAM,常驻不驱逐。README.md的洞见是"路由结构可缓存"(structure is cacheable)——专家有可测量的主题亲和性(expert atlas),所以一个工作负载的热专家集合是可学习的。但学习型缓存也是 Colibrì 开放假设表的第一行("路由历史能比纯 LRU 放得更好"——已知"学习型钉热改进了重复工作负载,但可能过拟合某个 prompt"),所以 PIN=auto 用.coli_usage历史驱动,且默认受 held-out 跨会话 A/B 验证管制。读完本节,你完成了第 3 章,理解了权重 JIT 的全部缓存层(LRU + 预取 + 学习型热存)。
内容来源:原项目源码
c/expert_store.h、c/route_trace.h(遥测,本节概念性引用)、README.md("The idea"/"Core techniques"/"Open hypotheses" 段)。
⚠️ 注意:学习型缓存可能过拟合 prompt——这是
README.md开放假设表第一行明示的失败模式。如果一个用户的工作负载是"写 Python 代码",.coli_usage会把代码相关专家钉热;但换一个"写古诗"的工作负载,那些钉热专家反而占着 RAM 挡路。Colibrì 的诚实态度是:学习型钉热是"已实现、可证伪"的策略,需要 held-out 跨会话 A/B 才能进默认路径。PIN=auto是开关,可以关掉退化成纯 LRU。
阅读完本节,你应当能够:
.coli_usage 文件的作用与更新时机(每 turn)。PIN=auto/PIN_GB=all 等开关各自控制什么。.coli_usage 是 Colibrì 的工作负载记录文件。README.md "How it works" 段说:"the engine records which experts your workload routes to (.coli_usage, updated every turn) and pins the hottest ones automatically"。
关键三句:(1) 记录"哪些专家被路由到"——不是抽象统计,是具体的 (layer, expert) 命中记录;(2) 每 turn 更新——一个 turn = 一次完整的对话回合(用户发一句、模型回一句),每个 turn 把这一回合的所有路由命中累加进 .coli_usage;(3) 文件长期累积——跨会话保留,所以下次启动时引擎已经知道"这个用户的工作负载大概路由到哪些专家"。
.coli_usage 始终写在主盘——README.md 双 SSD 段明说 "the mirror is never written: .coli_usage, .coli_kv and all sidecars stay on the primary"。这与第 2 章 01 节"镜像永不写"的约束一致:镜像只是读副本,所有派生数据(sidecar)都在主盘。
LRU 缓存(第 3 章 02 节)的问题是:冷启动时所有专家都不在缓存,前几个 turn 必须大量读磁盘;且 LRU 顺序驱逐会让"刚才用过但本 turn 没用"的专家被挤走。pinned hot-store(固定热存)解决这两个问题:
启动时: 读 .coli_usage → 排出最热专家 top-N 把这 N 个专家预加载到 RAM(或 VRAM),钉死 pinned slot 永不驱逐(无论 LRU 顺序如何) 运行时: lookup 命中 pinned slot → 零 I/O,且不会被驱逐 lookup 未命中 → 走 LRU 路径(可能驱逐 LRU 里的,绝不驱逐 pinned)
pinned hot-store 与 LRU 缓存的关键差别是钉死不驱逐。LRU 缓存的 slot 可以被驱逐(按访问顺序);pinned slot 一旦钉死,无论后续访问模式如何,都常驻。这让"已知最热"的专家永远在高速层,降速风险最小。
pinned hot-store 是 ColiExpertStore 抽象的第二个具体实现——它和 LRU 实现都遵循同一套 lease 契约(expert_store.h:40-58),只是内部驱逐策略不同(pinned 实现里,pinned slot 不参与 LRU 驱逐)。引擎代码用 ColiExpertStore * 抽象指针,不需要知道底层是 LRU 还是 pinned。
README.md "The idea" 段有一句口号:"colibrì literally gets faster the more you use it"(Colibrì 字面上越用越快)。机制链条是:
你跑了一回合对话 ↓ .coli_usage 累积了本回合的路由命中 ↓ 下次启动,pinned hot-store 把最热专家预加载钉死 ↓ 下次跑同样/类似工作负载时,这些专家已在 RAM,零 I/O ↓ 命中率高 ↑,bytes_read ↓,tok/s ↑ ↓ 你用得越多,.coli_usage 越准,钉热越准,越快
这是个正反馈循环:用得越多,历史越准,缓存越准,越快。它依赖一个关键前提:工作负载有可学习的路由结构——也就是下一节讲的"路由结构可缓存"。
注意 literally(字面上)这个词。它不是营销——Colibrì 的确会随着 .coli_usage 累积而单调提速(对相同工作负载)。但这个提速有上限:当 .coli_usage 收敛到稳定的工作负载画像,pinned 集合就稳定,命中率收敛到上限(由工作负载本身的专家分散度决定)。第一次跑的冷启动速度,和第十次的暖启动速度,差几个数量级是常见的。
学习型缓存为什么有效?README.md "The idea" 段给出关键洞见:"It works because routing has measurable structure (see the expert atlas) — and structure is cacheable." 翻译:"它有效是因为路由有可测量的结构(见 expert atlas)——而结构是可缓存的。"
什么是 expert atlas(专家图谱)?README.md "See it running" 段描述:13,260 个已特征化的专家,1,041 个复制的专家,按主题聚类(诗歌、法律、中文、SQL...)。位置是测得的路由亲和性,不是学习出的嵌入。 也就是说,MoE 的路由器并不是随机把 token 分配给专家——某些专家专门处理代码,某些专门处理诗歌,某些专门处理中文。这种主题亲和性是可测量的(通过大量 prompt 的路由命中统计),且跨会话稳定(代码专家不会突然变成诗歌专家)。
正因为路由有这种结构,学习型缓存才有效:如果你昨天写了一堆 Python,你的 .coli_usage 里"代码专家"高度活跃;今天你再写 Python,那些专家依然是热的,pinned hot-store 钉死它们,你就快了。这就是"structure is cacheable"——路由结构(哪些专家属于哪个主题)是稳定可学的,所以可以基于历史钉热。
💡 深潜要点:expert atlas 的存在揭示了一个深洞见——MoE 的稀疏性不仅是"每 token 激活 5.4%",更是"路由有主题结构"。Colibrì 的学习型缓存把这条结构信息提炼成
.coli_usage,再变成 pinned hot-store 的钉热决策。这与第 1 章 01 节"权重 JIT"形成闭环:JIT 编译器编译热点代码,前提是"代码有热点";Colibrì 钉热点专家,前提是"路由有热点"——两者都依赖"执行有结构"这个统计事实。
学习型缓存这么好,为什么不总是开?答案是 README.md 开放假设表第一行:"Routing history can place experts better than plain LRU"——已知"learned pins improve repeated workloads, but can overfit a prompt",还需要"held-out, cross-session A/Bs across coding, chat, multilingual, and long-context workloads"。
把假设表第一行展开:
| 字段 | 内容 |
|---|---|
| 假设 | 路由历史能比纯 LRU 放得更好 |
| 已有证据 | 学习型钉热改进了重复工作负载 |
| 已知失败模式 | 可能过拟合某个 prompt(工作负载变了,钉热的反而占 RAM) |
| 待做实验 | 留出集、跨会话 A/B,覆盖编码/聊天/多语言/长上下文 |
学习型缓存 vs 纯 LRU 的核心权衡:
Colibrì 的态度是两者并存,可证伪,默认受控:PIN=auto 用 .coli_usage 历史驱动(学习型);可以关掉退化成纯 LRU;要不要默认开,等跨会话 A/B 拍板。
README.md 提到的几个 PIN 相关开关:
PIN=auto:用 .coli_usage 历史驱动 pinned hot-store——排最热专家自动钉死。PIN_GB=all:把整个专家集合钉到 RAM/VRAM(全驻留)。README.md "How it works" 段:"on a large host the entire expert set becomes resident (CUDA_EXPERT_GB=auto PIN_GB=all) and disk drops out of the decode path entirely"——大内存机器上,所有 19456 个专家全驻留,磁盘退出解码路径。CUDA_EXPERT_GB=auto:GPU 上自动决定专家驻留多少。这些开关让用户按硬件配置选策略:小内存机器用 PIN=auto(只钉最热几个);大内存工作站用 PIN_GB=all(全驻留,磁盘退出);中等内存可能用纯 LRU(PIN=0)。这是 Colibrì "同一引擎跨整个硬件范围"的体现——25GB 笔记本到 6× RTX 5090 大机器,只是 PIN 配置不同。
本节的最后,回到 Colibrì 的诚实研究风格。学习型缓存是典型的好心办坏事的候选——它"看起来"显然有效(钉热专家,谁不觉得对?),但实际可能过拟合,在跨工作负载时反而拖慢。Colibrì 的态度:
README.md 假设表第一行就写"can overfit a prompt"——主动暴露自家机制的失败模式。PIN=auto 可退化为纯 LRU;不强制。ColiExpertStoreStats(第 3 章 02 节)的命中率/预取命中率/bytes_read 让用户能自己测——钉热有没有效,看命中率有没有提升、bytes_read 有没有下降,数据说话。这套态度贯穿第 3 章。LRU、一层前瞻预取、学习型热存三层缓存,各自都是"已实现、可证伪、可关"的策略。Colibrì 把"什么时候用哪一层"留给用户和 A/B 数据,而不是替用户拍板。这是它作为"开放研究平台"的根本特征。
⚠️ 注意:学习型缓存的"过拟合 prompt"风险在长上下文工作负载里尤其明显。一篇长文档可能让某些专家高度活跃(被钉热),但下一个完全不同的长文档可能路由到完全不同的专家集合——之前的钉热就成了"占着 RAM 挡路"。所以假设表第一行的待做实验特别提到"long-context workloads"——长上下文是学习型缓存最可能失败的边界,需要专门验证。
.coli_usage:每 turn 更新,记录 (layer, expert) 路由命中,跨会话累积,始终在主盘。.coli_usage 排最热专家,预加载钉死,永不驱逐(区别于 LRU 顺序驱逐)。PIN=auto 历史驱动、PIN_GB=all 全驻留、PIN=0 退化为纯 LRU。第 3 章结束。你已掌握 Colibrì 权重 JIT 的全部缓存层(lease 契约 + LRU + 一层前瞻预取 + 学习型热存)。下一章(第 4 章)我们离开"单层缓存",上升到"多层级存储放置"——
c/tier.h怎么把 VRAM/RAM/NVMe 当成同一个三级层级来调度。