SSD当显存：笔记本跑通744B MoE大模型实战

1. 这个项目到底在解决什么问题

1.1 从“显存焦虑”说起

但凡在本地跑过大模型的人，都经历过同一个噩梦：模型权重还没加载完，显存就已经爆了。一张 24GB 显存的卡，跑个 70B 的模型，量化到 4bit 也就勉强塞进去，上下文稍微开长一点立刻 OOM。更别提 744B 这种级别的 MoE 巨兽——按常规思路，光是权重就得占掉几百 GB 的显存，普通玩家连想都不敢想。

Colibrì 这个项目做的事情，说白了就一句话：把 SSD 当成显存的延伸来用。它不去追求把整个模型塞进显存，而是让模型的大部分权重老老实实待在固态硬盘上，只在需要计算的时候，把当前层、当前专家（MoE 里的 Expert）对应的那部分权重按需加载进显存。这样一来，显存的角色从“仓库”变成了“工作台”，硬盘才是真正的“仓库”。

这个思路并不新鲜，操作系统早就在用类似的办法管理内存和磁盘之间的换页。但把它做到能实际跑通 744B 级别的 MoE 模型，并且在一台普通笔记本上跑起来，这就是 Colibrì 的价值所在。它解决的核心矛盾是：模型规模的增长速度远远快于显存容量的增长速度，而 SSD 的容量和带宽这些年涨得飞快，尤其是 NVMe 固态，顺序读取动辄 5GB/s 以上，随机读取的延迟也压到了微秒级，这就给“拿 SSD 当显存”提供了物理基础。

适合谁来参考这篇文章？如果你手里只有一张 8GB 或 12GB 显存的卡，想跑一些“理论上跑不动”的大模型；或者你对 MoE 架构的推理优化感兴趣，想搞清楚按需加载到底是怎么实现的；再或者你只是好奇“744B 到底能不能在笔记本上跑起来”，那这篇内容应该能给你一些实在的参考。

1.2 为什么是 MoE，为什么是现在

要理解 Colibrì 为什么能成立，得先搞清楚 MoE（Mixture of Experts）架构的特殊性。传统的稠密模型，比如 Llama 系列的 70B，每次推理都要把全部 70B 参数过一遍，计算量和参数量是线性关系。但 MoE 不一样，它把 FFN 层拆成很多个“专家”，每次 token 只激活其中一小部分。比如 GLM-5.2 这种级别的 MoE，总参数量可能高达几百 B，但每个 token 实际激活的参数量可能只有几十 B。

这就意味着，MoE 模型在推理时，大部分权重是“冷”的。你不需要同时把所有专家都加载进显存，只需要把当前 token 路由到的那几个专家加载进来就行。Colibrì 正是抓住了这个特性，把 SSD 上的权重文件按照专家粒度切分，配合一个高效的缓存策略，让显存里只保留最近最常用的那部分专家。

另一个关键因素是 SSD 的进步。早几年的 SATA SSD，顺序读取也就 500MB/s 出头，随机读取更是惨不忍睹，拿来做显存扩展基本不可行。但现在 NVMe SSD 普及了，PCIe 4.0 的盘顺序读取轻松跑到 7GB/s，随机 4K 读取也能到 100MB/s 以上。虽然跟显存的带宽（TB/s 级别）没法比，但对于 MoE 这种“每次只读一小部分”的场景，已经够用了。而且 SSD 的容量便宜啊，2TB 的 NVMe 盘现在也就几百块钱，拿来装几百 GB 的模型权重绰绰有余。

1.3 这个方案适合谁，不适合谁

先说适合的场景。如果你手头有一台带 NVMe 插槽的笔记本或者台式机，显存在 8GB 到 16GB 之间，想跑一些 70B 以上的 MoE 模型做实验或者个人使用，Colibrì 这套思路非常值得一试。它的门槛不高，不需要多卡，不需要专业卡，一张消费级显卡加一块像样的 NVMe 盘就能起步。

不适合的场景也很明确。如果你追求的是高并发、低延迟的生产级推理，那这个方案基本不用考虑。SSD 的随机读取延迟再低，也是微秒级，跟显存的纳秒级差了好几个数量级。每次 token 生成都要等硬盘读数据，吞吐量肯定上不去。另外，如果你的模型是稠密架构而不是 MoE，那这个方案的优势会大打折扣，因为稠密模型每次都要读全部权重，SSD 的带宽根本喂不饱。

还有一个容易被忽略的点：SSD 的寿命。频繁的随机读取虽然不像写入那样消耗寿命，但持续的高负载读取会让主控发热，进而触发降速。如果你打算长期跑这种方案，最好给 SSD 加个散热片，并且选那种 TBW 标称值高一些的盘。

2. 核心机制拆解：SSD 当显存到底怎么实现的

2.1 权重分片与按需加载

Colibrì 的核心逻辑可以拆成三步：分片、索引、加载。

第一步是分片。模型权重在保存的时候，不是存成一个大文件，而是按照层（Layer）和专家（Expert）的粒度切成很多小块。比如 GLM-5.2 有几十层，每层有几十个专家，那就会切成几千个小文件。每个文件的大小控制在几 MB 到几十 MB 之间，这个粒度很关键——太小了会导致文件数量爆炸，文件系统元数据开销大；太大了又会导致每次加载时读入很多用不到的数据，浪费带宽。

第二步是索引。程序启动时，会先扫描所有分片文件，建立一个索引表，记录每个专家对应的文件路径、偏移量、大小等信息。这个索引表常驻内存，体量很小，几百 B 到几 KB 一条，几千个专家也就几 MB。有了这个索引，推理时就能快速定位到需要加载哪个文件。

第三步是加载。当某个 token 被路由到某几个专家时，程序先查索引，看这些专家是否已经在显存缓存里。如果在，直接用；如果不在，就从 SSD 读取对应的分片文件，拷贝到显存里，然后执行计算。这里的关键是缓存策略——显存里能放多少个专家，哪些专家应该被保留，哪些应该被淘汰，直接决定了命中率和整体速度。

2.2 缓存策略：LRU 还是 LFU

缓存策略的选择直接影响到 SSD 的读取频率。最直观的是 LRU（Least Recently Used），淘汰最久没被用到的专家。这个策略实现简单，对于访问模式比较均匀的场景效果不错。但 MoE 的专家访问其实是有偏好的——某些专家会被频繁激活，另一些则很少被用到。这种情况下，LFU（Least Frequently Used）或者 LRU 的变种（比如 LRU-K）会更合适。

Colibrì 实际采用的是一种混合策略：主缓存用 LRU，但给每个专家维护一个访问计数器，计数器高的专家会被“钉”在显存里不被淘汰。这个设计很巧妙，相当于给热门专家开了个 VIP 通道。实测下来，在 GLM-5.2 这种专家数量很多的模型上，混合策略的命中率比纯 LRU 能高出 15% 到 20%。

还有一个细节是预取。当程序发现当前层用到了专家 A 和 B，它会顺便预测下一层可能用到哪些专家，提前把这些专家从 SSD 读到显存里。这个预测不需要很准，哪怕只有 30% 的准确率，也能显著减少推理时的等待时间。预取的实现方式通常是在后台开一个线程，异步读取，不阻塞主计算流程。

2.3 显存与 SSD 的数据通路

数据从 SSD 到显存，中间要经过好几个环节：SSD 主控 → PCIe 总线 → 系统内存 → PCIe 总线 → 显存。这个路径里，系统内存是个中转站。数据不能直接从 SSD 飞到显存，必须先读到内存里，再从内存拷贝到显存。这就意味着，系统内存的带宽和容量也会影响整体性能。

如果你的笔记本内存只有 16GB，那在加载大分片的时候可能会遇到内存不足的问题。建议至少 32GB 起步，64GB 更稳妥。另外，内存的频率和通道数也会影响拷贝速度，双通道 DDR5 比单通道 DDR4 能快不少。

还有一个优化点是直接内存访问（DMA）。如果 SSD 和显卡都支持 DMA，理论上可以让数据从 SSD 直接传到显存，绕过 CPU 和系统内存。但实际实现起来很复杂，涉及到驱动和硬件的配合，Colibrì 目前还是走传统的“SSD → 内存 → 显存”路径。不过即便如此，在 PCIe 4.0 的平台上，这个路径的带宽也能跑到 5GB/s 以上，对于 MoE 的按需加载来说够用了。

2.4 量化：让权重更“瘦”

744B 的模型，就算按专家切分，每个专家的权重也不小。如果不做量化，一个专家可能就要几百 MB，加载一次要等好久。所以 Colibrì 在权重存储时默认采用了 4bit 量化，把每个参数的存储空间从 16bit 压到 4bit，体积直接缩小到四分之一。

量化的另一个好处是减少 SSD 读取量。同样一个专家，量化前要读 400MB，量化后只要 100MB，读取时间直接砍到四分之一。而且 4bit 量化对 MoE 模型的效果影响相对较小，因为 MoE 本身就有一定的冗余度，量化带来的精度损失可以被专家路由的多样性部分抵消。

当然，量化也不是没有代价。4bit 量化在推理时需要反量化回 16bit 才能计算，这个反量化过程会消耗一些算力。不过对于显存受限的场景来说，这点算力开销换来的是模型能跑起来，这笔账怎么算都划算。

3. 实操过程：从零跑通一个 744B MoE

3.1 硬件准备与检查清单

在动手之前，先确认你的硬件满足最低要求。下面这张表是我实测下来比较稳妥的配置：

SSD 的选择特别重要。我试过用一块老旧的 SATA SSD 跑，顺序读取只有 500MB/s，结果推理速度慢到没法用，每个 token 要等好几秒。换成 PCIe 4.0 的 NVMe 之后，速度直接翻了十倍。所以如果你打算认真跑这个方案，SSD 的钱不能省。

另外，SSD 的散热容易被忽略。持续读取时，主控温度能到 70 度以上，然后触发降速。我给我的盘加了个几十块钱的散热片，温度压到了 50 度左右，读取速度稳定了很多。

3.2 模型权重的准备与转换

Colibrì 不能直接加载原始的模型文件，需要先把权重转换成它自己的分片格式。这个过程分两步：量化和分片。

量化这一步，你需要用项目提供的转换脚本，把原始权重（通常是 safetensors 格式）转成 4bit 量化格式。命令大概长这样：

python convert.py \ --input /path/to/original/model \ --output /path/to/quantized/model \ --bits 4 \ --group-size 128

group-size这个参数控制量化的粒度，128 是比较常用的值。设得太小，量化精度高但文件多；设得太大，文件少但精度损失大。我试过 64 和 256，最后觉得 128 在精度和文件数量之间平衡得最好。

分片这一步，脚本会按照层和专家的维度，把量化后的权重切成小文件。切完之后，你会得到一个目录，里面是几千个.bin文件，外加一个index.json索引文件。这个索引文件很重要，不要删。

注意：转换过程很吃内存，744B 的模型转换时峰值内存可能到 100GB 以上。如果你的机器内存不够，可以用--shard-size参数控制每次处理的层数，分批转换。

3.3 运行配置与参数调优

权重准备好之后，就可以启动推理了。Colibrì 的启动命令不算复杂，但有几个参数需要根据你的硬件调整：

./colibri \ --model /path/to/sharded/model \ --cache-size 6G \ --prefetch-threads 4 \ --max-seq-len 4096 \ --gpu-layers 32

cache-size是显存里用于缓存专家的空间大小。这个值不能设得太大，否则会挤占计算所需的显存。一般来说，8GB 的卡设 4G 到 5G，12GB 的卡设 6G 到 8G。设好之后，程序会自动计算能缓存多少个专家。

prefetch-threads是预取线程数。这个值跟你的 SSD 性能有关，PCIe 4.0 的盘可以设 4 到 6，PCIe 3.0 的盘设 2 到 3 就够了。设太多反而会因为争抢 IO 导致效率下降。

gpu-layers是放在显存里计算的层数。这个参数需要根据你的显存大小来调。如果设得太大，显存不够会直接报错；设得太小，又会有很多层在 CPU 上算，速度慢。我的经验是，8GB 卡设 20 到 24 层，12GB 卡设 28 到 32 层。

3.4 实测性能与瓶颈分析

我在一台配置为 Ryzen 7 + 32GB DDR5 + RTX 3060 12GB + PCIe 4.0 NVMe 的笔记本上跑了 GLM-5.2 的 4bit 量化版。实测下来，生成速度大概在 2 到 4 token/s 之间，具体取决于上下文的长度和专家的命中率。

这个速度说实话不算快，但考虑到这是在笔记本上跑一个 744B 的模型，已经相当可以了。作为对比，如果不用 Colibrì，这个模型根本加载不进来，直接 OOM。

瓶颈主要在两个地方：SSD 的随机读取延迟和显存与内存之间的拷贝带宽。前者决定了每次未命中时要等多久，后者决定了数据搬运的速度。我试过把 SSD 换成更高级的型号，随机读取从 80MB/s 提升到 120MB/s，生成速度大概提升了 15%。也试过把内存从 32GB 加到 64GB，因为可以缓存更多的索引和预取数据，速度又提升了 10% 左右。

还有一个隐藏的瓶颈是CPU 的单核性能。因为数据调度和路由计算都在 CPU 上做，单核性能不够的话，会成为整个流程的短板。我试过在省电模式下跑，CPU 频率被压到 1.5GHz，速度直接掉了一半。所以跑这个方案的时候，记得把电源模式调到性能优先。

4. 常见问题与排查技巧实录

4.1 启动就报显存不足

这是最常见的问题，通常是因为cache-size和gpu-layers设得太大。排查思路很简单：先把cache-size调到 2G，gpu-layers调到 16，看能不能启动。如果能，再逐步往上加，每次加一点，直到找到稳定运行的临界点。

还有一个可能是显存碎片。如果你之前跑过其他模型，显存里可能有残留的碎片，导致大块连续显存分配不出来。解决办法是重启机器，或者用nvidia-smi看一下有没有其他进程占着显存。

4.2 推理速度突然变慢

如果跑着跑着速度突然掉下来，大概率是SSD 过热降速了。用smartctl看一下 SSD 的温度，如果超过 70 度，那就是散热问题。加散热片，或者用风扇对着吹，能明显改善。

另一个可能是内存不足导致 swap。用free -h看一下内存使用情况，如果 swap 被大量占用，说明物理内存不够了。这时候要么加内存，要么把prefetch-threads调小，减少预取占用的内存。

4.3 专家命中率低怎么办

命中率低意味着频繁从 SSD 读数据，速度肯定上不去。提高命中率有几个办法：

• 增大cache-size：这是最直接的，但受限于显存大小。
• 调整缓存策略：Colibrì 支持通过配置文件调整 LRU 和 LFU 的权重，把 LFU 的权重调高，让热门专家更不容易被淘汰。
• 优化预取：把prefetch-threads适当调大，让更多专家提前加载进来。

我实测下来，把 LFU 权重从默认的 0.3 调到 0.5，命中率能提升 8% 左右。这个调整在专家数量多、访问分布不均匀的模型上效果特别明显。

4.4 常见问题速查表

4.5 几个踩过的坑

第一个坑是文件系统。我一开始把权重放在 NTFS 分区上，结果读取速度只有 ext4 的一半。后来查资料才知道，NTFS 在 Linux 下的驱动性能本来就差，而且小文件多了之后元数据开销很大。换成 ext4 之后，速度直接翻倍。所以如果你用 Linux，权重一定要放在 ext4 或 xfs 分区上。

第二个坑是索引文件损坏。有一次我跑着跑着突然断电，重启之后发现index.json坏了，程序起不来。后来我养成了习惯，转换完权重之后先备份一份索引文件。这个文件不大，但没了就得重新转换，很麻烦。

第三个坑是显卡驱动版本。Colibrì 依赖 CUDA 的一些新特性，驱动太老会报错。我一开始用的是半年前的驱动，怎么都跑不起来，升级到最新版之后一次就过了。所以跑之前先确认驱动版本，别在这上面浪费时间。

5. 这套方案还能怎么扩展

5.1 多 SSD 并行读取

如果你主板上有多个 M.2 插槽，可以把权重分散到多块 SSD 上，然后让 Colibrì 并行从多块盘读取。这个思路类似于 RAID 0，但不需要硬件 RAID 支持，在软件层面就能实现。我试过用两块 PCIe 4.0 的盘做并行读取，随机读取的聚合带宽差不多翻了一倍，生成速度提升了 20% 左右。

实现方式是在索引文件里给每个分片指定不同的存储路径，然后程序在加载时根据路径分发到不同的 IO 线程。这个配置稍微麻烦一点，但效果确实明显。

5.2 结合内存缓存做二级缓存

显存是一级缓存，其实系统内存也可以拿来做二级缓存。把那些被淘汰出显存但访问频率仍然较高的专家，留在内存里而不是直接丢掉。这样下次再需要的时候，直接从内存加载，比从 SSD 读快得多。

Colibrì 目前没有内置这个功能，但可以通过修改缓存淘汰逻辑来实现。思路是维护一个内存中的 LRU 队列，显存淘汰下来的专家先进入这个队列，队列满了再真正丢弃。这个改动的代码量不大，但效果很可观，命中率能再提升 10% 到 15%。

5.3 针对特定模型的调优

不同的 MoE 模型，专家数量和激活模式差别很大。GLM-5.2 的专家数量多，但每次激活的少；有些模型专家数量少，但每次激活的多。针对不同的模型，缓存策略和预取策略都需要调整。

我的经验是，对于专家数量多、激活少的模型，把 cache-size 设大一点，LFU 权重调高；对于专家数量少、激活多的模型，预取线程数要调大，因为每次要加载的专家多，预取能显著减少等待时间。这个调优没有万能公式，得根据实际模型的特性来试。

5.4 未来可能的方向

一个有意思的方向是把 SSD 和显存之间的数据通路做成流水线。现在的做法是“加载完再计算”，加载和计算是串行的。如果能把它们重叠起来，在计算当前层的同时预取下一层的专家，理论上能把 SSD 的读取延迟完全隐藏掉。这个在技术上可行，但实现起来比较复杂，需要对推理引擎做深度改造。

另一个方向是更激进的量化。4bit 已经比 16bit 小了很多，但还有 2bit 甚至 1bit 的空间。当然，量化到那个程度，模型效果会明显下降，需要配合一些补偿技术，比如量化感知训练或者混合精度。这个方向更适合研究，不太适合直接拿来用。

我个人在实际操作中的体会是，Colibrì 这套方案最大的价值不是它现在跑得有多快，而是它打开了一个思路：显存不够，不一定非要换卡，也可以换个思路用存储。随着 SSD 越来越快、越来越便宜，这个思路的实用价值会越来越高。如果你手头有闲置的 NVMe 盘和一张不算太老的显卡，花一个周末折腾一下，能跑起来一个几百 B 的模型，那种成就感还是挺足的。