在过去几天里，我偶然发现了一个项目，它让我停下手中的一切工作去深入理解其运作原理。它不仅仅是另一个用于运行语言模型的框架，也不是另一种基于图形处理器的优化方案。它是与众不同的。
这个项目名为科利布里（Colibri）。
乍一看，这似乎几乎是不可能的。其理念简单却极为大胆：仅使用中央处理器和固态硬盘，在普通计算机上运行庞大的混合专家模型，且仅在每一步加载实际需要的专家模块到内存中。
当我第一次读到这一点时，我的反应可能和其他人一样：
“这怎么可能行得通？”
在研究了其架构后，我意识到科利布里的真正创新之处并不仅仅在于它能够运行一个巨大的模型。真正的突破在于它彻底改变了我们对推理过程的思考方式。
视角的转变
多年来，我们一直被灌输这样一种观念：运行模型意味着将整个模型加载到内存中。
需要更多的显存。
需要更多的内存。
需要更多的图形处理器。
科利布里挑战了这一假设。
它不再让数千亿个参数常驻内存，而是将模型视为一个活的系统。
路由器选择所需的专家模块。
这些专家模块从固态硬盘加载。
它们执行计算任务。
一旦不再需要，它们就可以被丢弃。
这是一种极其优雅的方法。
在实践中，存储不再仅仅是存放模型权重的地方——它成为了推理过程中的积极参与者。
这是一个既简单又绝妙的想法。
瓶颈不在于架构
一旦我理解了它的工作原理，另一个问题浮现在脑海中。
如果真正的问题不在于算法呢？
因为架构本身是完全合理的。
瓶颈出现在其他地方。
每当需要一个专家模块时，都会发生一个不可避免的顺序：
固态硬盘 → 内存 → 中央处理器
在单次生成过程中，这个过程会发生数千次。
换句话说，真正的限制不再是计算能力，而是等待数据从存储移动到内存所花费的时间。
就在那时，我开始思考这种架构的下一步可能是什么。
如果科利布里能够预测未来？
现代中央处理器已经在这样做。
它们尝试预测下一条将被执行的指令。
操作系统会这样做。
数据库会这样做。
网页浏览器缓存也会这样做。
那么，为什么混合专家推理引擎不能做同样的事情呢？
想象一下，在处理了数千个词元之后，系统发现了如下模式：
专家 15
↓ 92%
专家 48
专家 48
↓ 87%
专家 102
专家 102
↓ 95%
专家 211
在这种情况下，引擎无需在加载下一个专家模块之前等待下一个词元。
当中央处理器正在计算当前专家模块时，另一个线程可以已经预先加载最有可能需要的下一个专家模块。
当需要它们时，它们已经驻留在内存中。
等待时间几乎消失殆尽。
存储将不再是瓶颈
如今，固态硬盘的使用是被动的。
首先，路由器做出决策。
然后，固态硬盘响应。
但是，如果我们反转这一逻辑呢？
系统不再对请求做出反应，而是开始预判它们。
这将把存储从一个被动组件转变为一个
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
