一个人,一台12核笔记本,25GB内存,跑通了一个744B参数的大模型GLM-5.2。这不是实验室里的展示,是开源项目colibri这几天放出来的实测:纯C写的推理引擎,零第三方依赖,把21504个专家参数全丢在磁盘上,现用现取。但先别急着兴奋——它冷启动的速度,只有约0.05到0.1 tok/s,慢到你打完一句话的功夫,模型可能还没吐出半个词。
内存里只放骨架,专家全丢给硬盘
GLM-5.2是MoE(专家混合)架构,总参数744B,但每个token真正参与计算的只有约40B,分布在75层MoE、每层256个专家里,外加3层稠密层和1层MTP预测头。这套架构规格,官方文档和colibri的实现基本对得上,没有明显出入。
colibri的做法很直接:把不随token变化的稠密部分(注意力、共享专家、embedding,约17B参数)常驻内存,int4量化后只占9.9GB;剩下21504个路由专家,合计约370GB,全部丢在磁盘上,配合LRU逐层缓存、可选的pinned热存储、加上操作系统自带的页缓存当免费二级缓存,按需读取。这就是"25GB内存"的来源——真正吃内存的部分被压缩到极小,巨兽的躯体被外包给了硬盘。
"诚实数字"背后:能跑,但慢得像证明题
作者自己给出的数字很坦白:冷启动下每个token大约要读11GB磁盘数据,受限于磁盘随机读取上限,速度落在0.05-0.1 tok/s。配合int8精度的MTP投机解码头,能拿到2.2-2.8 tokens/forward的加速比,但同一份测量也老实交代:缓存冷的时候,每验证一个草稿反而会多路由出更多专家,读盘量从约660涨到约1100 expert-loads/token,投机解码在缓存预热之前可能是净时间损失。
社区实测印证了这份坦诚:一台24核WSL2机器默认跑出0.07 tok/s,调参数后到0.11 tok/s;一台配了128GB统一内存的Apple M5 Max,跑到1.06 tok/s——这是目前能查到的实测上限。README里给出的PCIe5、RAID0、AVX-512等更快硬件的预测速度,作者自己也标注是估算,还没人拿真实硬件跑出来验证。
不是发明新范式,是把老思路做绝
"专家常驻磁盘、按需调入"这个打法,不是colibri凭空发明的。llama.cpp的--cpu-moe参数配合mmap,把专家权重交给操作系统分页管理,首次访问从磁盘读入,之后靠页缓存留在内存里——早就在做类似的事。colibri的不同,是把这套思路写成一个不到1300行的纯C引擎,手动做逐层LRU缓存、pinned热专家、异步预读,把这条路走到极限。
另一条路线是vLLM,方向完全相反:多GPU专家并行,面向数据中心和工作站级吞吐,压根不考虑消费级CPU加SSD这种组合。两条路线服务的是不同的人——本地玩家要的是能跑起来,数据中心要的是扛得住吞吐。
能跑不等于跑得对
colibri仓库里自带HellaSwag、ARC Challenge、MMLU的评测框架,已经写好接好,但作者自己承认:还没有人跑完整套测试。官方FP8精度的GLM-5.2在这几项基准上大概能拿到85%到95%的分数,int4量化压缩之后到底掉了多少,至今是空白。
- 风险.int4量化后的模型准确率至今没有权威benchmark验证,能跑不代表答得对。
一个能在25GB内存里把744B参数的巨兽喂出一句"你好"的引擎,和一个回答准确率经得起基准检验的引擎,完全是两回事。这类项目最容易被架构复杂度冲昏头,却把最基础的一件事漏掉。
参数搬进磁盘,答案的靠谱程度还留在原地。
0.05到0.1 tok/s的冷启动速度,更像一份工程可行性证明,而不是一份能日常使用的产品——它证明了物理上可以做到,却还没证明这样做值得。等DSA稀疏注意力补完,等社区拿更快的NVMe跑出真实数据,等质量基准也补上分数,这个项目才算真正跨过"能跑"和"好用"之间那道坎。