第 3 章 · 03 学习型固定热存与工作负载记录


文档摘要

第 3 章 · 03 学习型固定热存与工作负载记录 本节摘要:本节深潜 Colibrì 的"学习型"缓存——比 LRU 更进一步,让引擎越用越快(literally gets faster the more you use it)。机制是 文件:每 turn 更新,记录哪些专家被路由到;pinned hot-store(固定热存)根据历史自动把最热专家钉到 RAM/VRAM,常驻不驱逐。 的洞见是"路由结构可缓存"(structure is cacheable)——专家有可测量的主题亲和性(expert atlas),所以一个工作负载的热专家集合是可学习的。

第 3 章 · 03 学习型固定热存与工作负载记录

本节摘要:本节深潜 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.hc/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。

学习目标

阅读完本节,你应当能够:

  1. 解释 .coli_usage 文件的作用与更新时机(每 turn)。
  2. 描述 pinned hot-store(固定热存)与 LRU 缓存的差别(钉死不驱逐 vs LRU 顺序驱逐)。
  3. 复述"越用越快"(literally gets faster the more you use it)的机制链条。
  4. 解释"路由结构可缓存"(structure is cacheable)与 expert atlas 的关系。
  5. 说清学习型缓存 vs 纯 LRU 的权衡(改进重复工作负载 vs 过拟合 prompt)。
  6. 读懂 PIN=auto/PIN_GB=all 等开关各自控制什么。
  7. 理解为什么"路由历史可放置专家"是开放假设表第一行,以及 held-out 跨会话 A/B 的要求。

一、.coli_usage:每 turn 更新的路由历史

.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)都在主盘。

二、pinned hot-store:钉死最热专家

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 集合就稳定,命中率收敛到上限(由工作负载本身的专家分散度决定)。第一次跑的冷启动速度,和第十次的暖启动速度,差几个数量级是常见的。

四、路由结构可缓存:expert atlas

学习型缓存为什么有效?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ì 钉热点专家,前提是"路由有热点"——两者都依赖"执行有结构"这个统计事实。

五、学习型缓存 vs 纯 LRU:开放假设表第一行

学习型缓存这么好,为什么不总是开?答案是 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 的核心权衡:

  • 学习型缓存的优势:对重复性工作负载(你天天写 Python),钉热决策基于历史,命中率高,快。
  • 学习型缓存的劣势:对变化工作负载(你从 Python 切到古诗),历史钉热的专家是错的,占着 RAM 挡住新工作负载的真正热专家,反而慢。
  • 纯 LRU 的优势:无状态,自动适应当前工作负载(无论你写什么,LRU 都跟着当前访问模式走)。
  • 纯 LRU 的劣势:冷启动慢(无历史),且容易"刚用过但本 turn 没用"的专家被驱逐。

Colibrì 的态度是两者并存,可证伪,默认受控:PIN=auto.coli_usage 历史驱动(学习型);可以关掉退化成纯 LRU;要不要默认开,等跨会话 A/B 拍板。

六、PIN 开关族:控制钉热行为

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ì 的态度:

  1. 明示失败模式:README.md 假设表第一行就写"can overfit a prompt"——主动暴露自家机制的失败模式。
  2. 要求严格验证:不是"看起来对就默认开",而是要 held-out、跨会话、跨工作负载(编码/聊天/多语言/长上下文)的 A/B。
  3. 可关:PIN=auto 可退化为纯 LRU;不强制。
  4. 可观测:ColiExpertStoreStats(第 3 章 02 节)的命中率/预取命中率/bytes_read 让用户能自己测——钉热有没有效,看命中率有没有提升、bytes_read 有没有下降,数据说话。

这套态度贯穿第 3 章。LRU、一层前瞻预取、学习型热存三层缓存,各自都是"已实现、可证伪、可关"的策略。Colibrì 把"什么时候用哪一层"留给用户和 A/B 数据,而不是替用户拍板。这是它作为"开放研究平台"的根本特征。

⚠️ 注意:学习型缓存的"过拟合 prompt"风险在长上下文工作负载里尤其明显。一篇长文档可能让某些专家高度活跃(被钉热),但下一个完全不同的长文档可能路由到完全不同的专家集合——之前的钉热就成了"占着 RAM 挡路"。所以假设表第一行的待做实验特别提到"long-context workloads"——长上下文是学习型缓存最可能失败的边界,需要专门验证。

本节要点回顾

  1. .coli_usage:每 turn 更新,记录 (layer, expert) 路由命中,跨会话累积,始终在主盘。
  2. pinned hot-store:根据 .coli_usage 排最热专家,预加载钉死,永不驱逐(区别于 LRU 顺序驱逐)。
  3. 越用越快:正反馈循环——用得越多,历史越准,钉热越准,命中率越高,bytes_read 越低。
  4. 路由结构可缓存:expert atlas 揭示 MoE 路由有主题亲和性(代码/诗歌/中文/SQL),结构稳定可学。
  5. 学习型 vs 纯 LRU 权衡:学习型改进重复工作负载,但可能过拟合 prompt;纯 LRU 无状态自适应但冷启动慢。
  6. PIN 开关族:PIN=auto 历史驱动、PIN_GB=all 全驻留、PIN=0 退化为纯 LRU。
  7. 诚实假设:开放假设表第一行,明示过拟合失败模式,要求 held-out 跨会话 A/B,长上下文是关键边界。

第 3 章结束。你已掌握 Colibrì 权重 JIT 的全部缓存层(lease 契约 + LRU + 一层前瞻预取 + 学习型热存)。下一章(第 4 章)我们离开"单层缓存",上升到"多层级存储放置"——c/tier.h 怎么把 VRAM/RAM/NVMe 当成同一个三级层级来调度。


作者与出处
原作者: 灏天文库
整理: 灏天文库整理
本站整理收录,版权归原作者/开源协议所有;欢迎通过原文链接访问源仓库。
发布者: 作者: 灏天文库 转发
评论区 (0)
U