744B MoE 模型能跑在普通桌面上的工程原理

大多数"在家里跑大模型"的项目，本质上都是压缩项目。更激进地量化、剪枝、蒸馏，最终一个披着大模型外衣的小模型塞进你的 VRAM。

Colibri 走了另一条路，这个思路值得弄懂，哪怕你永远不跑它。这是一个纯 C 写的推理引擎，一个文件，不依赖 BLAS，运行时不需要 Python，也不需要 GPU。它能在你已有的硬件上跑 7440 亿到 2.8 万亿参数的 MoE（混合专家）模型。

不要压缩模型，要放置模型

一个 744B 的 MoE 模型并不是每个 token 都动用 744B 参数。它实际激活约 400 亿，约占 5.4%，而这其中真正从一个 token 变到下一个 token 的只有约 11 GB。

所以模型从来不需要塞进快取内存。它需要的是被合理放置：

密集部分——注意力层、共享专家和 embedding，约 170 亿参数，以 int4 精度常驻 RAM，约为 9.9 GB。

19,456 个路由专家，每个约 19 MB，放在磁盘上约 372 GB，按需流式加载，每层有 LRU 缓存和一个学出来的热点专家固定层。

项目自己的类比最让人茅塞顿开：JIT 编译器，但是针对权重的。

JIT 编译器从来不编译整个程序。它只观察实际跑了什么，然后即时编译热路径。Colibri 对 744B 参数空间做了同样的赌注。参数不是需要持有的驻留状态，而是需要被分阶段调入的数据——恰好在需要的时候。路由器提前跑一层，让预取隐藏延迟，而路由热度决定哪些专家晋级到哪一层缓存。

它能work，是因为专家路由有可度量的结构，而结构是可以缓存的。

数字，才是最诚实的部分

这才是"我能在家里跑 744B 模型吗"的真实答案：能，大约每秒一到两个 token。

这不是坑，只是取舍。交互式对话没法用；批量分析、通宵任务，或者隐私敏感的工作（这类工作的替代方案是把数据送到 API），完全没问题。

大多数人会遇到的瓶颈不是 GPU（GPU 是可选的），而是 372 GB 的高速 NVMe——因为专家流式读取是 IO 密集型的。

完整的放置机制说明、与 llama.cpp 和 Ollama 的对比、以及清掉那么多磁盘之前值得了解的注意事项：Colibri：在你已经拥有的硬件上自托管一个 744B LLM。

如果你在之后要整理模型输出，一个 Markdown 转换器能省掉你手动修复每个代码围栏的麻烦。