25G 内存跑 GLM-5.2?

说实话我看到这个最开始感觉是不是假的, GLM-5.2 总计 744B 激活参数 40B. 8bit量化光激活参数部分就需要40G内存.

即使 4bit 量化只加载那40B激活参数也要20G内存, 而且要是这么搞, 内存需要疯狂加载每个token推理时需要的参数, 那可就不是卡内存带宽而是卡硬盘带宽了.

按照现在NVME也就1-4GB/s的读取速度, 加载20G才能完成一个token的推理, 那么最快也就5秒吐一个字了.

但是这个框架能做到 2.2-2.8 tok/forward! 虽然也很慢, 但是思路很值得借鉴:

他们把 GLM-5.2 的激活细节分析了一波. 发现 744B 的 MoE 每个 token 确实激活了 40B, 但是 token 推理的时候真正会变的只有路由专家那一块, 大约 11GB (int4), 有优化空间!

所以只需要动态加载这部分. 注意力、共享专家、embedding 这些稠密部分约 17B, 常驻内存也就 9.9GB. 剩下 21,504 个路由专家 (~370GB) 全扔磁盘, 按需流式加载.

流式加载采用的是 per-layer LRU + 热点 pin + 系统页缓存当 L2. 将优化做到了极致.

最终变成了冷启动大概每个 token 读 ~11GB (75 层 × 8 专家), 官方数据冷启动的时候大概 0.05–0.1 tok/s. 热起来之后命中缓存, 磁盘压力下来速度就上升了.

除此之外他们还搞了个实验性的 router-lookahead (PILOT), 就是用当前层的 post-attention 状态猜下一层路由进行预加载, 实测可预测性达到了 71.6%, 效果拔群. 然后再加上 GLM 自带的 MTP 投机解码头, 接受率能到 39–59%, 一次 forward 就能输出 2.2–2.8 个 token了.

如果你的确没显卡, 但是有磁盘阵列或者NVME阵列, 那么这个框架是完全可以试一试的.

#HOW I AI##colibri##glm52#

链接: github.com/JustVugg/colibri