第 5 章 · 01 双 SSD 镜像与确定性哈希路由

第 5 章 · 01 双 SSD 镜像与确定性哈希路由

本节摘要:解码在多数机器上是磁盘瓶颈,而专家读取是只读的——所以如果有第二块 SSD,放一份完整模型副本,引擎就能从两块盘同时流式读取。COLI_MODEL_MIRROR 指向副本目录,每个专家由确定性哈希按带宽比(COLI_DISK_WEIGHTS=9,3)路由到一块盘。readahead/PILOT 预取和 demand read 总命中同一盘,不会重复缓存。聚合带宽是两盘之和,9+3 GB/s 比单 9 快约 33%。启动校验 byte-identical,部分镜像也行,读取错误回退主盘,mirror 永不写。

内容来源:原项目源码 README.md(L186-209)

⚠️ 注意:本节是 Colibrì I/O 工程的总览,后两节深潜 io_uring 和 O_DIRECT。核心思路只有一句:既然专家读取是只读的,镜像就永远不需要同步——两份副本启动时一致,运行期都不写,所以可以放心地按确定性哈希分流,把两块盘的带宽叠加起来。

学习目标

1. 理解解码磁盘瓶颈 + 专家读取只读是镜像可行的两个前提。
2. 说清确定性哈希按 COLI_DISK_WEIGHTS 带宽比路由的机制。
3. 理解启动校验和部分镜像的容错。
4. 理解读取错误回退主盘、mirror 永不写的语义。
5. 理解 MIRROR: 统计行的含义。

一、两个前提:为什么镜像能"零同步成本"

绝大多数存储系统的镜像(RAID-1、分布式副本)都面临同步难题:主副本写完要同步到镜像,延迟和一致性都棘手。Colibrì 的双 SSD 镜像完全绕开这个难题,因为它满足两个前提。

前提一:解码在多数机器上是磁盘瓶颈。 decode 阶段每个 token 都要按路由读取若干专家权重,这部分 I/O 占了延迟大头。如果能并行从两块盘读,带宽翻倍,瓶颈直接松开。

前提二:专家读取是只读的。 MoE 的专家权重在推理期间永远不变,既不会因为前向结果而修改,也不会累积状态。这意味着镜像副本一旦在启动时和主盘一致,运行期就永远一致,不需要任何同步。

这两个前提合起来,让镜像变成了一个纯粹的"带宽叠加"问题:两块盘各放一份,运行期都只读,谁也不写谁。配置非常简单:

COLI_MODEL=/fast/glm52_i4 COLI_MODEL_MIRROR=/second/glm52_i4 ./coli chat
COLI_DISK_WEIGHTS=9,3 ...   # 可选:primary,mirror 带宽比(否则启动时实测)
​

二、确定性哈希按带宽比路由

如果两块盘带宽相等,均匀哈希就够了。但现实中常见的是一块快盘 + 一块慢盘(比如 9 GB/s NVMe + 3 GB/s SATA SSD),均匀分流会让快盘空等慢盘。Colibrì 用确定性哈希按带宽比路由解决:

每个专家被一个确定性哈希函数映射到一个盘,映射的概率与该盘的带宽比成正比。COLI_DISK_WEIGHTS=9,3 意味着主盘拿到 9/(9+3)=75% 的专家,镜像拿 25%——和它们的带宽比一致,两块盘同时跑满,谁也不空等。

关键设计在于"确定性":同一个专家在每次运行、每次访问、无论 readahead 预取还是 demand read,都被哈希到同一块盘。这样有两个直接好处:

专家 E  →  hash(E) mod 12  →  落在主盘 或 镜像
                                ↓
        readahead 预取命中同盘
        PILOT 路由预取命中同盘
        demand read 命中同盘
        → 不会在两块盘各缓存一份(无重复缓存)
​

第一,readahead/PILOT 预取和最终的 demand read 总是命中同一块盘,缓存利用率最高,不会出现"预取在主盘、需求读在镜像"导致同一份权重在两块盘的页缓存里各占一份。第二,聚合带宽是两盘之和——9+3 GB/s 这对组合读专家比单用 9 GB/s 那块快约 33%,因为慢盘的 3 GB/s 也被用上了。

如果不指定 COLI_DISK_WEIGHTS,引擎在启动时实测两块盘的带宽,自动确定路由比。

这里有一个工程细节值得注意:哈希函数必须是确定性的、跨运行稳定的。也就是说,同一个专家在这次运行哈希到主盘,下次运行、换台机器、换次编译,都必须仍然哈希到主盘。否则预取和需求读会错盘,页缓存命中率崩盘。Colibrì 用基于专家身份(层号+专家 id)的稳定哈希,不依赖运行时随机种子,保证跨一切边界都确定。

三、启动校验:byte-identical,部分镜像也行

镜像必须在启动时校验,确保两份副本一致。Colibrì 的校验粒度是 per-file:

• 每个文件的 size 必须和主盘一致。
• 每个文件的 safetensors header 必须 byte-identical。

只要这两条满足,引擎就认为该 shard 在镜像上可用,会把路由到该 shard 的专家读分发到镜像盘。这里有一个非常重要的容错设计:divergent 或 missing 的文件静默落回主盘。

也就是说,如果第二块 SSD 比主盘小,放不下整个模型,只能放一部分 shard——这部分 shard 走镜像加速,放不下的 shard 自动落主盘,整个机制照样工作。这就是"部分镜像也行"的含义:一块 200GB 的第二盘装不下 370GB 的全专家集,但只要把热点 shard 拷过去,热点专家照样享受带宽叠加。

这个容错设计背后有一个关键观察:专家热度是高度倾斜的(expert atlas 热图证明),少数热点专家贡献了大部分路由访问。所以一块装不下全模型的小盘,只要装下那 20-30% 的热点 shard,就能拿到 70-80% 的带宽加速收益。这是"部分镜像"在工程上有意义的根本原因——边际收益递减,装热点 shard 性价比最高。

coli mirror plan/stage/verify 子命令会读 .coli_usage 专家历史,只把最热的 shard 拷到第二盘,在预算内最大化加速——这是学习型缓存和镜像规划的协同。

stage 子命令的安全设计值得专门提一句:它通过临时文件拷贝(不直接覆盖)、保留请求的 free-space reserve、每个 shard 用 SHA-256 校验、永不删除已存在的镜像 shard、只在选定镜像就绪后才原子发布 receipt。这意味着 stage 中途崩溃不会损坏主盘模型,也不会留下半成品镜像——重启后可以从 receipt 续传。这是把"部分镜像"做成生产级可用功能的关键工程。

verify 子命令则做最终校验:遍历镜像里所有 shard,逐个比对 size 和 safetensors header,确保和主盘 byte-identical。任何 divergent 的 shard 会被标记,运行时自动落回主盘。这是一个"信任但验证"的设计——stage 写完不假定正确,运行前用 verify 兜底,运行中还有读取错误回退兜底,三层防护确保镜像永远不会产出错误结果。

四、镜像永不写,读取错误回退主盘

镜像的语义有两条铁律,保证它"永远是一份干净的副本"。

铁律一:mirror 永不被写。 所有副作用文件——.coli_usage(专家访问历史)、.coli_kv(KV 持久化)、各种 sidecar——一律落在主盘。镜像只承担读流量,内容在运行期永不变化。这就是镜像零同步成本的根源。

铁律二:读取错误回退主盘。 如果镜像盘某次读失败(比如运行中被拔掉),引擎打印一条警告,然后从主盘重读该 expert,不崩溃。这意味着拔盘降级而不是杀服务:用户感觉不到中断,只是带宽回到主盘单盘水平。

每轮运行结束时,引擎打印一条 MIRROR: 统计行,显示每块盘分别 served 了多少 GB。这是验证路由比是否按预期工作的最直接指标——如果带宽比设得不对,会看到一块盘 served 远多于另一块。

值得强调的是,镜像路由永不改变 token。两份副本启动时 byte-identical,运行期都只读,所以无论一个专家从哪块盘读,出来的权重字节都完全一样,前向结果不受任何影响。这是"只读镜像"哲学的最终保证:它纯粹是性能优化,对语义零影响,关掉镜像功能输出一个 token 都不变。

💡 深潜要点:双 SSD 镜像不是 RAID,不是分布式副本,而是一个"只读带宽叠加器"。它的全部巧妙在于利用了 MoE 推理的两个不变性——专家只读、启动后内容不变——把同步难题直接绕过。确定性哈希保证预取和需求读不重复缓存,部分镜像保证小第二盘也有用,错误回退保证拔盘不杀服务。

本节要点回顾

1. 两个前提:解码磁盘瓶颈 + 专家读取只读,让镜像零同步成本。
2. 确定性哈希按 COLI_DISK_WEIGHTS=9,3 带宽比路由,预取和需求读命中同盘不重复缓存。
3. 聚合带宽 = 两盘之和,9+3 比单 9 快约 33%。
4. 启动校验 per-file size + safetensors header byte-identical,divergent/missing 落主盘,部分镜像也行。
5. mirror 永不写(.coli_usage/.coli_kv 落主盘),读取错误回退主盘一警告不崩,MIRROR: 行报每盘 GB served。

下一节:带宽叠加讲完了,我们深潜 uring.h——Linux io_uring 异步 I/O,看清 Colibrì 如何用 SYS_io_uring_setup + mmap 共享内存 + __atomic_load_acquire/__atomic_store_release 内存序,实现批量定位读 + 收割 CQE 无自旋。