Colibri（JustVugg/colibri）：纯 C 的三层专家放置引擎，把 744B MoE 塞进 25GB 内存的笔记本

一、导读

colibri 是一个用纯 C 写成的 MoE（混合专家）分层推理引擎，它把 VRAM、系统内存和 NVMe 硬盘当成同一条存储层级来调度，让 744B 乃至 2.8T 参数的前沿 MoE 模型跑在只有 25GB 内存、没有独立显卡的普通机器上。2026-11-03 它单日涨星 803，总星 47,201，是当日 GitHub daily 榜上排名最高、且为本站近 14 天未发布过的大模型类项目。本文不写「又一个本地跑大模型」的泛泛介绍，而是聚焦它真正的技术内核：五步专家流水线（route / union / place / overlap / learn）、把权重当 JIT 编译产物的缓存策略、71.6% 的一层路由可预测性、以及「慢内存只应该损失速度、绝不允许改变语义」这条硬约束背后的工程账。

二、项目速览

项	值
仓库	JustVugg/colibri（colibrì，意大利语「蜂鸟」）
主语言	C（内容主体为 C 引擎 + Markdown 文档）
Star 总数	47,201
当日涨星	803（daily 榜第 6 位）
Fork / Watcher	5,459 / 378
Open issues	169
License	Apache-2.0（Copyright 2026 Vincenzo Fornaro）
首次发布	2026-07-01（仓库 `created_at`），首个 Release v1.0.0 于 2026-07-19
最新版本	v2.1.0（2026-10-31）
活跃度	最近推送 2026-11-03；21 个 Release；v2.1.0 距 v2.0.0 之间合并 387 个 PR，其中 208 个来自 35 位外部贡献者

数字取自 GitHub REST API、github.com/trending?since=daily 与仓库 README，抓取日期 2026-11-03。仓库仅约 43MB 体积，但所服务的模型权重在 137GB（DeepSeek V4 Flash）到 1.6TB（Kimi K3）之间——「引擎几百 KB，模型几百 GB」是理解这个项目的第一把钥匙。

三、为什么是它：问题背景与定位

被打破的那堵墙是显存，而不是内存。 前沿开源模型几乎已经全线 MoE 化：GLM-5.2 总计 744B 参数，但每个 token 只激活约 40B，真正逐 token 变化的只有约 11GB；Kimi K3 总计 2.8T 参数，激活约 104B。也就是说，模型的「体积」和「每次真正用到的体积」之间隔着一到两个数量级。作者把这条观察推到极致：既然 94.6% 的专家在任一瞬间都是闲置的，为什么要把它们全部锁在又贵又小的 VRAM 里？

于是 colibri 的定位非常明确——它不是最快的引擎，它是让「本来跑不了」变成「跑得慢但跑得对」的引擎。README 用一句话概括：Tiny engine, immense model。它复现了 2026 年 7 月那篇爆红的 Show HN（「Getting GLM 5.2 running on my slow computer」，>900 分），当时作者在 12 核 / 25GB 内存的笔记本上把 744B 模型跑了起来，速度只有 0.05–0.1 tok/s——冷缓存下单 token 要从硬盘读约 11GB，一个短回答要等好几分钟。

涨星动因可拆三层。 表层是时机：v2.1.0 刚在 10 月 31 日发布，带来「每个引擎都能原生读 GGUF」「CUDA 设备链」「256k 上下文按 64k 速度跑」等一批实质更新，并在 11 月初持续被社区转发。中层是叙事张力：「25GB 笔记本跑 744B」天然是一个反直觉的故事，它把「显存墙」重新表述为「存储带宽问题」，这个框架很容易被复述。深层是工程诚实：README 把 0.05 tok/s 的底线数字放在最显眼位置，把所有短板（Qwen3.8-Flash-Next 只有 CPU 后端、DeepSeek V4 不支持语法约束、投机解码默认关闭）逐条列出，这种「不吹」的姿态在同类项目里稀缺，反而建立了信任。

需要说明的是，项目把自身定位为研究平台而非产品：它明确鼓励贡献者发布「负面结果」，并要求记录硬件、提交、模型、命令、提示、缓存状态、吞吐、首 token 时间、专家命中率、读取字节与质量检查。这种口径也解释了它为什么能在一个高度拥挤的赛道里持续吸引贡献者。

四、【重点】架构原理

4.1 整体架构：把三种存储当成一条层级

colibri 没有调度器、没有分布式编排引擎，它的「架构」就是一条数据流与一组分层缓存：

graph TD
    Q[用户请求 / agent 调用] --> R["Router 路由<br/>每层每 token 选出激活专家"]
    R --> U["Union 联合<br/>一个 batch 内每个专家只读一次"]
    U --> P["Place 放置<br/>热->VRAM / 温->RAM / 冷->NVMe"]
    P --> O["Overlap 重叠<br/>loader 池在驻留专家计算时预读缺失专家"]
    O --> L["Learn 学习<br/>.coli_usage 记录热度，热集固定到 RAM"]
    L --> OUT[token 输出]
    subgraph M["存储层级（同一寻址空间）"]
        V["VRAM 层<br/>CUDA / Vulkan / Metal · 最热专家"]
        A["RAM 层<br/>int4 常驻稠密部分 9.9GB + 温专家 LRU"]
        S["NVMe 层<br/>路由专家 ~370GB · pread / O_DIRECT"]
    end
    P --> V
    P --> A
    P --> S
    S -.->|COLI_MODEL_MIRROR| S2[第二块 SSD 镜像]

三条并行的支撑线跑在这条主流程上：引擎层（c/，每个模型家族一个 .c 文件 + 共享头文件，无 BLAS、运行时无 Python）、服务层（coli serve 提供 OpenAI 兼容 /v1/chat/completions 与 Anthropic 兼容 /v1/messages，另有决策 API /v1/systemone）、界面层（coli web 仪表板、coli ui 聊天界面、Tauri 桌面壳、docker/ 容器、内建 MCP 服务器）。

4.2 分层模块拆解

引擎层是整个项目的重心。 每个模型家族独占一个 C 文件——c/colibri.c 对应 GLM-5.2，约 2,400 行；c/glm.c 是更早的约 1,300 行版本。所有引擎共享头文件（tok.h 分词器、tier.h 分层策略、st.h 存储抽象、dsv4_quant.h 量化格式等），CLI 统一。这种「一模型一文件」的组织方式刻意放弃了抽象：新增一个模型家族意味着写一个新文件，而不是配置一份 YAML。代价是不能像 KTransformers 那样用几行规则就替换算子；收益是每个引擎都能针对该模型的注意力结构（GLM 的 MLA、Qwen3.6 的 DeltaNet、DeepSeek 的 NSA）做极致特化，且没有 Python/框架层的运行时开销。

分层放置层由 tier.h 承载。 它定义的是「一个专家应该住在哪一级」，而不是「哪些专家必须住哪一级」——这是全项目的核心契约。VRAM 层可选（CUDA / Vulkan / Metal 三种后端，其中 Vulkan 甚至能让被厂商停止支持的 RX 580 跑起来）；RAM 层是必需项，常驻稠密部分（注意力、共享专家、嵌入，GLM-5.2 约 17B 参数，int4 下约 9.9GB）；NVMe 层存放路由专家（GLM-5.2 约 370GB），按需 pread 读取。

量化与转换层放在 Python 侧，只在一次性转换和可选的 API 网关里出现。这里有一条被血泪验证的规则：MTP（多 token 预测）头必须是 int8，用 int4 会让草稿接受率崩到 0–4%；而本体权重用 int4 容器（gs64），早期版本用旧的 per-row int4 镜像质量差约 9 个百分点，正是「思考停不下来」死循环的根因——README 直接把这件事写在明面上。

验证层是每个引擎在 CI 中对齐其模型参考实现（HuggingFace transformers）的小型 fixture，token 级比对，teacher-forcing 命中 30–32/32。

4.3 核心机制：五步流水线（route / union / place / overlap / learn）

每一层的每一个 token 都走同样五步，这是 colibri 最值得读的部分：

route    → 路由器选出本 token 激活的专家（GLM-5.2: 75 层 × 每层 8+1）
union    → 一个 batch 内所有位置的路由结果取并集，每个专家只读一次
place    → 按热度把专家分配到 VRAM / RAM / NVMe
overlap  → loader 池在「驻留专家正在计算」的同时，读取「缺失专家」
learn    → 把本轮的专家命中写进 .coli_usage，下一轮据此固定热集

「权重的 JIT」是理解 place 与 learn 的钥匙。 编译器 JIT 从不编译整个程序，它观察实际执行的热路径再即时编译；colibri 对 744B 的参数空间下同样的赌注：权重不是常驻状态，而是跨存储层级暂存的数据。每层一个 LRU 缓存，外加一个从你自己对话历史学出来的固定热集（.coli_usage，每轮更新）。它越用越快——这不是营销话术，而是缓存命中率随使用上升的必然结果。这套机制之所以成立，前提是路由具有可测量的结构：GLM-5.2 下一层的路由有 71.6% 可预测，所以「一层前瞻预取」才划得来。项目甚至开了一个 Expert Atlas 的 issue（#175）专门可视化专家热度图。

「绝不两次等磁盘」是 overlap 的全部意义。 具体做法有四条：一个专家的三个矩阵用一次 pread 读回；一个 loader 池在驻留专家计算时并行读取缺失专家；一个 batch 的多个位置每个专家只读一次（batch-union）；一个 router-lookahead 线程预取下一层专家。DIRECT=1（O_DIRECT）绕过页缓存在快 NVMe 上常有大幅提升，但在某些盘（尤其 QLC）上反而更慢——README 明确要求「在你的盘上实测」。

多盘与多机是纵向扩展的出口。 COLI_MODEL_MIRROR=/second/glm52_i4 让引擎从第二块盘的副本读取；两块独立控制器的 NVMe 实测解码 +37.5%；放不下全量的第二块盘可以做「按热区部分镜像」。再往上，COLI_NUMA=1 把常驻权重摊到多路主机的各内存控制器上，本地集群模式可以把路由专家跑在其它机器上。

4.4 投机解码：只用「赚得回来」的那部分

colibri 的投机解码有一条罕见的纪律——只在对的地方开。GLM-5.2 的 int8 MTP 头在划算时每 forward 草拟 2.2–2.8 个 token；Qwen3.8-Flash-Next 的 MTP 头默认开启，输出完全一致的前提下带来 16–20% 提升，代码编辑场景再叠 6–7% 的 prompt lookup；Qwen3.6 的 MTP 头（Q36_MTP=1）把 RTX PRO 4000 上的解码从 99.7–104.5 提到 115.8–120.1 tok/s（CUDA），Vulkan 上从 83.2–83.8 提到 99.9–109.3。而 DeepSeek V4.1 的 DSpark 头「按置信度说多深就草拟多深」，并用一个门控跳过赚不回来的草稿；对于草拟成本高于收益的 DeepSeek V4，投机解码默认关闭。

配套的是 MLA 注意力对 KV 状态的压缩：GLM-5.2 每 token 的 KV 状态被压到 576 个浮点（而非 32,768 个，小 57 倍），且跨重启持久化——重开一段对话无需重新 prefill。

4.5 性能取舍：为什么这么做，代价是什么

设计选择	收益	代价（作者明写的）
专家放磁盘、按需流式	25GB 机器也能跑 744B	冷缓存 0.05–0.1 tok/s，一个短回答要等几分钟
一模型一个 C 文件	针对注意力结构极致特化、零运行时依赖	无 YAML 注入式的灵活替换；新模型=新代码
LRU + 学习型热集	越用越快，热缓存延迟可降约 73%（第三方实测）	冷启动慢；需要 `.coli_usage` 预热
O_DIRECT 绕过页缓存	快盘上某机 +34%	盘相关，QLC 可能更慢，必须实测
双 SSD 镜像	独立控制器实测 +37.5%	需要双倍磁盘空间
MTP 头必须 int8	接受率不崩	int4 头接受率掉到 0–4%，等于白开
放置只影响速度、不影响语义	快内存不够只损失速度，模型行为不变	需要严格的 CI 参考实现对齐来担保

最后一条是整套架构的地基。README 原文：「内存快不够可能降低速度，但默认策略绝不悄悄改变模型精度或路由语义。」同一个专家无论从 VRAM、RAM 还是磁盘应答，路由决策一致、权重精度一致、输出一致。这也正是它敢于把「慢」放在标题里的底气。

4.6 与其他架构路线的差异

同为「MoE 专家 offload」，不同项目把层级切在了不同的深度：llama.cpp 的 --n-cpu-moe 是分层加载（把若干层或专家放到 CPU 内存）；KTransformers 把专家放进 RAM 并用 AMX 内核加速；colibri 则再往下压一层，把专家放进磁盘。三者的速度台阶非常大——KTransformers 在 671B 上报出的 prefill 可达约 286 tok/s，colibri 的 744B 冷缓存只有 0.05–0.1 tok/s。差异不在工程水平，而在目标函数不同：前者要「可用的推理服务」，后者要「在你已有的机器上让模型活下来」。这一点在下一节的横向对比里会更清楚。

五、【重点】应用场景

场景一：隐私敏感场景下的本地「持有」而非「租用」

痛点：医疗记录、法务卷宗、企业内部文档不适合发往云端 API；而本地部署前沿模型又要求多张 H100 或数百 GB 显存，成本与运维门槛都高。解法：用一块大 NVMe + 一台 16–32GB 内存的机器，把模型权重「持有」在本地，按需从磁盘流式加载，全程不联网（除一次性下载权重）。

# 一次性转换（需要 Python + huggingface_hub，按分片拉权重）
git clone https://github.com/JustVugg/colibri && cd colibri/c && ./setup.sh
# 启动（默认提供 OpenAI 兼容 :8000/v1）
COLI_MODEL=/nvme/deepseek_v4_flash_i4 ./coli chat

收益与量化：DeepSeek V4 Flash（284B / 13B 激活）磁盘占用约 137GB，最低 16GB 内存即可运行；在 RTX PRO 4000 上 CUDA 解码 104.8 tok/s（Qwen3.6-35B-A3B 口径），大模型流式（Mistral-Large-4）1.34–1.36 tok/s。适用边界：适合批式文档处理与离线总结，不适合交互式对话——0.05–0.1 tok/s 意味着一个短回答要等几分钟；不建议把冷缓存路径直接接到多轮 agent 循环上，长系统提示会导致长时间静默 prefill（第三方集成文档已明确把 colibri 标为「冒烟测试通过后仅作机械执行器」）。

场景二：成本敏感型 SaaS 的「零边际成本」批处理

痛点：批量语料分析、OCR 后处理、离线摘要这类任务，按 token 计费的云 API 在规模上去以后成本线性增长，且受配额与限流约束。解法：用 colibri 自托管一个前沿开源模型，边际成本压到电费。把 coli serve 暴露为 OpenAI 兼容端点后，现有工具链几乎零改动即可切换。

./coli serve --host 127.0.0.1 --port 8000
# OpenAI 兼容： http://127.0.0.1:8000/v1
# Anthropic 兼容：http://127.0.0.1:8000
# 多会话：--kv-slots N（最多 16 个独立 KV 缓存）

收益与量化：v2.0.0 起每个文本引擎可同时服务最多 16 路会话，每个 decode step 把各活跃请求的下一 token 合成一个 batch，于是本步读取的权重与专家被所有请求共享——这正是磁盘流式引擎提高性价比的关键。适用边界：多槽位开启时不启用投机解码，且稠密链关闭；不建议在高并发低延迟场景使用（此时 vLLM / SGLang 更合适）。

场景三：拥有一块被丢弃的旧显卡 / 一台老笔记本

痛点：CUDA 工具链新版本已经不再为 Maxwell / Pascal / Volta（例如 V100）编译；很多人手里的旧卡或集成显卡被主流栈判了死刑。解法：colibri 的 Vulkan 后端能在任何支持 Vulkan 1.2 的 GPU 上运行路由专家层，集成显卡（共享 CPU 内存）对 Qwen3.6、Qwen3-Coder、Qwen3.8-Flash-Next 默认启用；Apple Silicon 走 Metal（COLI_METAL=1）。

./start-here.sh --backend vulkan     # 或 --backend cpu / --backend cuda
# 旧卡的 CUDA：CUDA_ARCH=portable-pre-ampere NO_TC=1
# Qwen3.6 的 DeltaNet 层上卡（opt-in）：Q36_DN_GPU=1

收益与量化：Qwen3.6 的 30 个 DeltaNet 层此前每 token 要在卡与 CPU 间来回拷贝 4 次，开启后整个层在卡上执行、循环状态常驻 VRAM，在 RTX 3070 上解码从 25.4 → 30.0 tok/s；两张 8GB 卡（RTX 3070 + Quadro RTX 4000）带热历史实测 11.3 tok/s。适用边界：无 Resizable BAR 的老卡需要经过 staging buffer 拷贝，路径已测但尚无该配置的独立实测数字（待确认）。

场景四：把 colibri 当作「推理系统研究平台」

痛点：学术与工程团队想研究「专家放置策略、路由可预测性、磁盘 I/O 与计算的 overlap」这类问题，但主流引擎的调度逻辑埋在框架深处，难改难测。解法：colibri 把引擎做到「小到任何人都能来优化」——每模型一个 C 文件、无 BLAS、无运行时 Python，并公开一张研究假说表，明确要求贡献者也要发布负面结果，并记录硬件、提交、模型、命令、提示、缓存状态、吞吐、首 token 时间、专家命中率、读取字节与质量检查。

# 研究与诊断入口
./coli plan      # 资源规划（可检查的内存计划 dry-run）
./coli doctor    # 环境诊断
./coli tune      # 调参
./coli logs      # 日志

收益与量化：开放问题清单本身就是可发表的课题——路由历史能否比 LRU 更好地放置专家？多 SSD 能否把独立带宽转化为解码速度？硬件感知规划器能否自动逼近最优配置？路由感知的投机解码能否在接近满驻留之前就获益？适用边界：这是给愿意亲手调度存储层级的人用的工具，不建议只想「装完就能聊天」的用户使用——那种场景下 Ollama 这类一键封装更省心。

六、快速上手：三条命令跑到第一个 token

# 1) 一键脚本（自动探测硬件 → 推荐能装下的模型 → 构建引擎 → 断点续传下载 → 启动并打开仪表板）
git clone https://github.com/JustVugg/colibri
cd colibri
./start-here.sh          # Windows：解压后双击 START-HERE.bat

# 2) 手动构建（源码路径，需要 gcc/clang + OpenMP）
cd c && ./setup.sh
make qwen36 VK=1         # 例：为 Qwen3.6 构建 Vulkan 后端

# 3) 运行
COLI_MODEL=/nvme/qwen36_i4 ./coli chat
./coli serve             # 提供 OpenAI( /v1 ) 与 Anthropic 兼容端点
./coli web               # 浏览器仪表板（聊天 / System One / Brain / Profiling 四页）

启动后会打印两个可用地址，其它应用按「OpenAI 兼容供应商」接入即可：

Starting colibri
  Browser:             http://127.0.0.1:8000/
  OpenAI base URL:     http://127.0.0.1:8000/v1
  Anthropic base URL:  http://127.0.0.1:8000

硬件底线与「能装下」的定义：最低 8GB 内存（推荐 16GB+）、22GB 空闲磁盘（最小模型）、可选显卡。setup 的判据是——常驻内存的稠密部分 + 最小专家缓存 + 下载体积必须分别装进 RAM 与磁盘，否则会在 --list 里给出「为什么不合适」。常用参数：--list、--model ID、--yes、--dir DIR、--backend vulkan|cuda|cpu、--reconfigure。故障排查：./coli doctor 逐项报告缺什么；下载中断直接重跑续传；GPU 构建失败会自动回退（CUDA → Vulkan → CPU）。

七、横向对比：与同类方案的能力差异

维度	colibri	KTransformers	llama.cpp（`--n-cpu-moe`）	vLLM / SGLang
层级切在哪	专家放磁盘（VRAM/RAM/NVMe 三层）	专家放 RAM（GPU 持有注意力与 KV）	分层加载 / 专家放 CPU 内存	全部驻留 VRAM（含 CPU offload）
引擎形态	纯 C，一模型一 `.c`，无 BLAS、无运行时 Python	C++（约 11K 行）+ Python，HuggingFace 兼容	C/C++ GGML 生态	Python + CUDA 栈
关键加速	LRU + 学习型热集（`.coli_usage`）、71.6% 一层路由前瞻、一次 `pread`、双 SSD 镜像	Intel AMX + AVX-512 内核、单 CUDA Graph、Expert Deferral	成熟的量化与生态	PagedAttention、连续批处理、张量并行
典型规模	744B–2.8T（GLM-5.2、Kimi K3、Mistral-Large-4 等 13 个引擎）	DeepSeek-V3/R1 671B 等	覆盖面最广	生产级多租户
硬件门槛	8GB RAM + 22GB 磁盘起，GPU 可选	单张 24GB 卡 + 数百 GB RAM	视模型而定	多卡 GPU 集群
速度量级	冷缓存 0.05–0.1 tok/s；热缓存/多卡 1–9 tok/s	671B prefill 最高约 286 tok/s；AMX 内核约为 llama.cpp 的 27.8×	中等	最高吞吐
目标函数	让跑不了的模型跑起来，语义不变	低并发本地可用推理	通用本地推理底座	高并发服务
License	Apache-2.0	Apache-2.0	MIT	Apache-2.0

怎么读这张表：colibri 与其它三者不是替代关系，而是在层级上多压了一级。llama.cpp 停在「分层加载」，KTransformers 把专家下沉到 RAM，colibri 再下沉到磁盘，因此它换来了最低的硬件门槛与最低的速度。选型的第一问不是「哪个快」，而是「你的模型必须常驻吗？」——如果模型能装进 RAM，KTransformers / llama.cpp 会快得多；只有当模型装不下时，colibri 的价值才显现。

八、局限、风险与社区观察

性能的真实边界。 README 自己承认：「在慢盘上可能每秒不到一个 token」。25GB 开发机冷缓存 0.05–0.1 tok/s；Apple M5 Max（128GB 统一内存、Metal）约 1.06–1.83 tok/s；Ryzen 9 9950X + PCIe 5.0 NVMe 约 0.28–1.23 tok/s；128GB 纯 CPU 约 1.8 tok/s；单张 RTX 5070 Ti 笔记本约 1.07 tok/s；6× RTX 5090 全驻留才到 5.8–6.8 tok/s（NUMA 交错 9.0–9.2）。这是一个把「能跑」放在「快」之前的项目，误当作推理服务会失望。

明确的未完成项（作者写在 README 里）。 Qwen3.8-Flash-Next 目前只支持 CPU、不支持 GPU；DeepSeek V4 分支不支持语法约束、投机解码默认关闭；4-bit 量化精度损失的完整测量与长上下文稀疏注意力的实现，在爆红时点仍「尚未完成」（Gigazine 2026-07-10 报道口径）；浏览器端 WebGPU worker 仍是后续计划。

容器版本是最大的坑。 README 明确警告要用 gs64 容器，旧版 int4 镜像质量差约 9 个百分点，正是早期「思考停不下来」死循环的元凶；MTP 头若误用 int4 会让草稿接受率掉到 0–4%。

维护集中度是主要风险。 仓库由 JustVugg 单人主导（contributors 首位 3,085 次提交，其后依次 218 / 156 / 139 / 102），watcher 仅 378。好处是设计品味统一、决策快（v2.1.0 一个周期合并 387 个 PR）；代价是单点依赖——作者时间被挤占或兴趣转向，项目就会放缓。同时 169 个 open issues 与 13 个引擎的维护面提示：这是一个快速演进、但不适合无脑上生产的项目。

License 的层次要注意。 引擎本体 Apache-2.0，但各模型权重保留其作者许可：GLM-5.2 权重为 MIT，而 Qwen-Image-2.1 仅限非商业用途——商用前必须逐个模型核对权重许可，不能只看引擎的 Apache-2.0。

「慢」不等于「不安全」。 纯 C、无运行时 Python、无 BLAS 意味着攻击面小；但它同样不做沙箱隔离，模型的输出未经审查，把它接到能执行代码的 agent 循环上仍需自行加护栏。

九、小结与行动建议

先量存储带宽，再谈模型选型。 colibri 的吞吐由磁盘决定而非显卡。装之前先测你的 NVMe 顺序读带宽（GLM-5.2 冷缓存下每 token 要读约 11GB），并考虑用两块独立控制器的盘做镜像——实测可换来约 +37.5% 解码。
用学出来的热集换取可用速度。 前几轮对话会很慢，这是正常的。坚持用同一类任务跑几轮让 .coli_usage 收敛（第三方实测冷启动延迟在四轮会话后降约 73%），再把固定热集视作「你的个人配置」备份。
务必用 gs64 int4 容器 + int8 MTP 头。 这两条是 README 用踩坑换来的硬规则，违反任意一条，收益会直接归零甚至为负。
按目标函数选引擎，而不是按热度。 模型能装进 RAM → KTransformers / llama.cpp；要生产级并发 → vLLM / SGLang；模型装不下、又必须本地「持有」→ colibri。批处理与隐私场景是它的甜区，交互式低延迟不是。
把它当研究平台用，别当黑盒用。 它的价值一半在「跑通」，一半在「可改」——每模型一个 C 文件、一张公开假说表、一个鼓励发布负面结果的贡献文化。如果你的团队在做 MoE 服务化，这是当下最值得读源码的样本之一。

数据来源：GitHub REST API（api.github.com/repos/JustVugg/colibri）、仓库 README 与 docs/benchmarks.md、KTransformers SOSP 2025 论文与项目文档、Gigazine / Oflight / Flowtivity / Dev.to 等第三方报道，均于 2026-11-03 抓取；文中标注「待确认」的条目为公开信息不足、无法独立核实的内容。