> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Colibri 推理引擎： 权重流式传输 - URL: https://www.hubwiz.com/blog/colibri-inference-engine-weight-streaming/ - Published: 2026-08-09T13:07:39.000Z - Updated: 2026-10-13T14:49:08.000Z - Description: Colibri 将 VRAM、RAM 和 NVMe 视为一个推理层级。这使得前沿规模的混合专家（Mixture-of-Experts）模型可以在较小的机器上运行，但延迟和存储的权衡比头条数字更重要。 - Author: admin - Tags: TOOL, COLIBRI, #Import 2026-10-14 14:41 一个 7440 亿参数的模型在只有约 25GB RAM 的机器上报告自己已就绪。 这听起来像一个压缩的故事。很容易想象 Colibri 以某种方式将完整模型缩小到能装进一台笔记本电脑，但它并没有。 该模型在存储上仍然占用数百 GB。Colibri 改变的是更根本的东西：**哪些权重必须同时位于快速内存中**。 这一区别正是该项目在技术上引人入胜的原因。它也*解释了为什么这个结果是真实的，但又比"不再需要 GPU"或"办公笔记本现在可以取代推理服务器"之类的说法要狭窄得多*。 有用的问题不是 Colibri 是否终结了 GPU 服务。而是： > **我们能否通过仅在需要时将其活跃权重在 VRAM、RAM 和 NVMe 之间移动，来运行一个大规模稀疏模型？** Colibri 表明我们可以。代价是存储带宽和延迟成为推理引擎的一部分。 ## 1、Colibri 实际上是什么 [Colibri](https://github.com/JustVugg/colibri?ref=hubwiz.com) 是一个 Apache-2.0 开源推理运行时，主要用 C 编写。其参考模型是 GLM-5.2，一个 7440 亿参数的混合专家模型，每个 token 约有 400 亿参数处于活跃状态。 该项目可以在没有 GPU 的情况下运行。它还支持 CUDA、Metal、Vulkan、NUMA 感知的放置，以及在硬件更强大时支持部分或全部专家常驻内存。 同一个前端提供了： - 一个终端聊天界面； - 一个兼容 OpenAI 的 API； - 一个 Anthropic Messages API 转换层； - 一个带有延迟、缓存、存储层级和专家路由指标的浏览器仪表盘。 但这些界面并不是核心贡献。重要的是它们底下的内存模型。 大多数推理引擎从一个棘手的问题开始： > 模型能否装进 GPU 内存，或者至少装进 RAM？ Colibri 改变了这个问题： > 现在需要哪些权重，它们应该放在哪里，以及我们能以多快的速度移动它们？ ## 2、为什么混合专家架构让这成为可能 稠密模型对每个 token 都使用几乎全部参数。混合专家模型包含一个庞大的专家前馈网络库，但一个路由器为每个 token 只选择一小部分。 GLM-5.2 总共有 7440 亿参数，而一个 token 约有 400 亿处于活跃状态。Colibri 将该活跃工作分为两大类。（[官方模型卡](https://huggingface.co/zai-org/GLM-5.2?ref=hubwiz.com)） **稠密部分**包括注意力、嵌入、共享专家以及其他需要反复使用的组件。在该项目的 int4 布局中，这个常驻集合约为 9.9 GB。 **路由专家**作为一个集合要大得多，但每一层只需要被选中的专家。Colibri 将约 19,456 个路由专家保存在存储中，并在路由器选中它们时进行分阶段加载。（[架构说明](https://github.com/JustVugg/colibri?ref=hubwiz.com)） int4 版本的 GLM-5.2 容器仍然约为 **372 GB**。模型并没有变小。只是它的快速内存工作集变得可控了。（[快速入门](https://github.com/JustVugg/colibri?ref=hubwiz.com)） 一个有用的心智模型是： ``` VRAM -> 最热门的专家和 GPU 常驻计算 RAM -> 稠密权重、温专家和缓存 NVMe -> 冷专家库 ``` 放置方式改变的是性能，而不是路由器的决策或模型的目标精度。这是一个重要的设计边界。低内存机器应该变得更慢，而不是悄悄运行一个不同的模型。 ## 3、每个 token 的路径 当模型生成一个 token 时，每个 MoE 层大致遵循相同的序列： 1. 稠密部分计算路由器得分。 2. 路由器选择该 token 所需的专家。 3. Colibri 检查这些专家是否已经在 VRAM 或 RAM 中。 4. 缺失的专家从 NVMe 读取，尽可能进行异步加载和预取。 5. 被选中的专家运行，其输出被组合，执行进入下一层。 这就是为什么该项目将其设计比作**权重的即时编译器**。 编译器 JIT 不会预先优化每条可能的代码路径。它观察哪些路径被执行，并把资源花在热路径上。Colibri 记录路由活动，维护每层 LRU 缓存，固定经常使用的专家，并可以提前一层预取。 这个类比很有用，但它有一个边界。程序分支通常比专家路由更可预测。缓存也可能过拟合某个提示或工作负载。Colibri 当前的文档将学习式放置和前瞻视为可度量的策略，而非普适的胜利。 这种工程上的诚实很重要。一旦模型权重分布在三个存储层级上，任何优化都只是把瓶颈移到别处。 ## 4、存储成为推理的一部分 在 GPU 服务器上，我们通常讨论计算吞吐量、HBM 容量、KV 缓存压力、批处理和内核效率。 有了磁盘流式专家，我们还必须讨论： - NVMe 带宽和随机读取行为； - 页缓存压力； - 直接 I/O 与缓冲 I/O； - 异步读取； - 专家复用和缓存命中率； - 存储与计算之间的重叠； - 第二块 SSD 是否能提供独立的带宽。 Colibri 将专家的矩阵存储在一起，以便一次操作即可读取。它将缺失专家的读取与常驻专家的计算重叠，对一批位置每个唯一专家只加载一次，并支持在两个独立驱动器上的两份逐字节相同的模型副本之间进行加权分布。 这创造了一种不寻常的推理架构：存储子系统不再只是启动时的问题。它位于 token 生成的关键路径之内。 这才是真正的权衡。 > **Colibri 通过接受推理过程中的权重移动，来降低快速内存需求。** ## 5、可能不等于实用 基准数字使边界变得清晰。 #### 25 GB 开发机 - **解码速度：** 0.05–0.1 token/秒 - **含义：** 模型可以运行，但性能被冷磁盘流式传输所主导。 #### 128 GB 纯 CPU 台式机 - **解码速度：** 预热后约 1.8 token/秒 - **含义：** 可用于耐心的本地实验。 #### RTX 5070 Ti 系统 - **解码速度：** 约 1.07 token/秒 - **含义：** 部分 GPU 常驻有帮助，但完整模型仍然装不进 GPU 内存。 #### 六块 RTX 5090 GPU - **解码速度：** 5.8–6.8 token/秒 - **含义：** 全部专家常驻消除了解码路径中的磁盘访问。 在每秒 0.1 token 的情况下，100 个输出 token 需要约 **16 分 40 秒**。（[报告的输入速度](https://github.com/JustVugg/colibri/blob/main/docs/benchmarks.md?ref=hubwiz.com)） 在每秒 1.8 token 的情况下，同样的 100 个 token 需要约 **56 秒**。（[报告的输入速度](https://github.com/JustVugg/colibri/blob/main/docs/benchmarks.md?ref=hubwiz.com)） 这是非常不同的用户体验，尽管两台机器运行的是同一个模型容器。 因此，25 GB 的结果最好被理解为**可行性下限**。它证明了总参数数量不再必须等于快速内存容量。它并不能证明最小内存推理是舒适、经济或适合交互式智能体的。（[项目基准边界](https://github.com/JustVugg/colibri?ref=hubwiz.com)） 该仓库还报告说，同样的层级可以向上扩展。如果所有专家都常驻在多个 GPU 上，磁盘就从解码中消失，吞吐量随之上升。 > 因此，Colibri 并非纯粹的 CPU 运行时。它是一个根据机器改变放置方式的引擎。 ## 6、Colibri 和 vLLM 解决的是不同的问题 人们很容易直接将 Colibri 与 vLLM 比较，因为两者都运行语言模型。除非我们明确每个系统在优化的约束条件，否则这种比较会产生误导。 [vLLM](https://docs.vllm.ai/en/stable/?ref=hubwiz.com) 是为模型能够放在 GPU 基础设施上时的高效服务而设计的。它的优势包括连续批处理、高效的 KV 缓存管理、并行服务，以及在并发请求下的高吞吐量。 ***Colibri*** 是为完整权重无法留在快速内存中的模型而设计的。它优先考虑异构放置、专家流式传输、缓存学习，以及用延迟换取更低硬件需求的能力。 一个服务许多用户的生产级 API 通常看重可预测的延迟和吞吐量。在那里，vLLM 是更自然的运行时类别。 一个想要检查专家路由、在本地运行前沿规模的开源权重 MoE，或实验内存放置的研究人员，可能看重不同的东西。 > Colibri 使这类工作成为可能，而无需先构建一个大型 GPU 集群。 两者都不会让另一个过时。 ## 7、设计现在已超越单一模型 GLM-5.2 仍然是参考实现，但该仓库现在包含针对 Inkling、OLMoE 和 Kimi K3 的姊妹引擎。（[当前模型列表](https://github.com/JustVugg/colibri?ref=hubwiz.com)） Kimi K3 让内存论点更加明显。其检查点包含约 **2.8 万亿参数**，其中 1040 亿处于活跃状态。 路由专家已经以 MXFP4 格式进行了量化感知训练，占约 1.5 TB 纯文本容器的大部分。（[Kimi K3 引擎说明](https://github.com/JustVugg/colibri/blob/main/docs/kimi%5Fk3.md?ref=hubwiz.com)） Colibri 直接流式传输这些原生专家字节，而不是展开并重新量化它们。该引擎的文档报告称，直接 I/O 和流水线读取将一个全模型路径从每 token 约 21 秒改善到 9.4 秒。（[Kimi K3 存储测量](https://github.com/JustVugg/colibri/blob/main/docs/kimi%5Fk3.md?ref=hubwiz.com)） 这是一个有意义的系统改进。但距离生产级服务延迟仍然很远。 教训不是每个巨大的 MoE 都能突然在笔记本电脑上运行良好。而是：同样的放置问题出现在不同的模型家族中，一个运行时可以系统地解决它，而不是把 VRAM 不足当作立即停止的条件。 ## 8、实际的本地环境需要什么 运行时二进制很小。模型不是。 对于 GLM-5.2 参考路径，我们大约需要： - 一个 372 GB 的 int4 模型容器； - 足够的空闲 RAM 来容纳常驻稠密集合、运行时状态和操作系统； - 快速的 NVMe 存储； - 与未命中热层级的专家数量成正比的耐心。 官方的快速入门流程很直接： ``` git clone https://github.com/JustVugg/colibri cd colibri/c ./setup.sh COLI_MODEL=/nvme/glm52_i4 ./coli doctor COLI_MODEL=/nvme/glm52_i4 ./coli plan COLI_MODEL=/nvme/glm52_i4 ./coli chat ``` `doctor` 检查就绪状态，而 `plan` 在完整运行前显示预期的 VRAM、RAM 和磁盘放置。 我们没有在本评测环境中执行 372 GB 模型，因此这些命令是经过源码验证的，而非在此处亲手验证的。 任何评估该运行时的人都应记录确切的提交、模型容器、存储设备、缓存状态、提示、上下文长度和每秒 token 数。 对于这种架构，一个无法解释的速度数字是不够的。（[基准协议](https://github.com/JustVugg/colibri/blob/main/docs/benchmarks.md?ref=hubwiz.com)） ## 9、Colibri 在哪里有用 当我们的目标是以下时，Colibri 很有吸引力： - 在本地研究非常大的开源权重 MoE 模型； - 理解专家路由和复用； - 对隐私敏感、低吞吐量的推理； - 测试权重放置、存储调度或量化选择； - 利用现有的 RAM 和 NVMe，而不是为偶尔的实验租用大型 GPU 集群。 当我们需要以下时，它就不合适： - 在最低硬件上实现低延迟交互式聊天； - 高吞吐量的多用户服务； - 可预测的智能体循环延迟； - 成熟的生产级 SLA； - 无需数百 GB 或数 TB 模型存储的简单部署。 该项目本身将 Colibri 描述为既是推理引擎又是开放研究平台。这正是正确的预期。它今天的价值，既在于它生成的 token，也在于我们可以检查和修改的架构。 ## 10、更广泛的教训 我们常常把模型大小当作容量问题： > 我们需要多少 GPU 内存来容纳权重？ 稀疏模型把它变成了调度问题： > 哪些权重是活跃的，它们放在哪里，我们能否在不使延迟不可接受的情况下移动它们？ Colibri 并没有消除前沿推理的硬件成本。它只是将该成本重新分配到存储容量、I/O 带宽、RAM、缓存行为和时间上。 这就是为什么"NVIDIA 杀手"的说法不得要领。 有用的结果更精确： > **一个前沿规模的稀疏模型不必完全驻留在 GPU 内存或系统 RAM 中。它的权重可以分阶段部署在异构内存层级上，只要我们接受并管理由此产生的延迟。** 这不是 GPU 服务的替代品。它是一个新的、有价值的系统设计点，位于"模型装得下"和"模型跑不了"*之间*。 --- 原文链接: [Colibri Runs a 744B Model on 25 GB of RAM. The Real Breakthrough Is Weight Streaming](https://medium.com/@pankaj%5Fpandey/colibri-runs-a-744b-model-on-25-gb-of-ram-the-real-breakthrough-is-weight-streaming-aacbd4ae2e3d?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「AI 基建 / 评测 / 安全」专题的一部分。**完整地图见：[AI 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/)