我一直觉得 2026 年最搞笑的一件事是：大模型是”开放”的，但你要用得起它，还得先有八张 H100。
于是这三个月冒出来一批项目，思路一模一样——既然显存不够，那就把硬盘、内存、显存当成同一层内存使。一个在意大利，一个在巴基斯坦，都是用纯 C 写的，连 Python 都不需要。
colibri：把硬盘当显存用的 MoE 引擎
colibri 7 月 1 日建的仓库，现在是 38969 星 / 4271 fork，纯 C 零依赖，Apache 2.0。作者 Vincenzo Fornaro，2438 个提交，还在活跃更新（最近一次 9 月 21 日）。
它现在能跑 九个模型家族：GLM-5.2/5.3（744B 总参数 / 40B 激活）、Inkling（975B）、Kimi K3（2.8T）、DeepSeek V4 Flash（284B）、DeepSeek V4.1 Flash（552B，带视觉）、Qwen3.8-Flash-Next、Qwen3.6（35B-A3B）以及 OLMoE（7B）。前端就三个命令：./coli chat、./coli serve、./coli web。
关键机制叫 AI memory multitiering——显存、内存、存储不是三级，而是同一层。每个 token 只激活一小部分专家，这些专家的权重按需从 NVMe 流进来。项目里最直白的自嘲是：25GB 内存的开发机上，冷启动只有 0.05–0.1 tok/s，他们管这叫”项目的起点，也是诚实的基线”。
但数据往上走很猛：
- 128GB 纯 CPU 台式机：约 1.8 tok/s
- 单张 RTX 5070 Ti 笔记本卡：1.07 tok/s
- 6 张 RTX 5090 全驻留：5.8–6.8 tok/s，TTFT 约 13 秒
- Qwen3.6（35B-A3B）挂两张 8GB 卡开 VRAM 专家层：1.44 → 10.05 tok/s，7 倍加速，输出和 CPU 路径逐比特一致
有几点我觉得比速度更重要。它把 safetensors 容器、tiktoken 的 BPE、llama.cpp 的 GBNF 语法子集全在 C 里重写了一遍，CI 拿 transformers 当预言机，逐 token 对拍随机初始化模型。它甚至有个 COLI_EXACT_VERIFY=1 环境变量，专门验证浮点近似在近似平局时会不会翻转——代价是掉到 0.6 倍速度。还有 Brio 模式：你给它一个文档和有限几个候选答案，它不生成文本，只读每个选项的概率，completion_tokens 为 0，答案永远跑不出你的列表，还附带一个熵值告诉你模型有多不确定。官方实测比”生成再比对”快 2.4 到 5.7 倍。
作者在 README 里写了一句我觉得该抄给所有做推理引擎的人的话：“快没有 SLA，语义有硬保证——内存不够可以慢，但绝不能悄悄重新定义模型。”
kimi-k3-in-c：2.78 万亿参数塞进 8.24GB 内存
kimi-k3-in-c 是另一个极端。作者 Fareed Khan 在 8 月 1 日建的仓库，8834 星 / 1438 fork，Apache 2.0，可移植 C99。
README 开头那张表基本就是行为艺术：
| 指标 | 数值 |
|---|---|
| 参数量 | 2.78T |
| 磁盘上的 checkpoint | 1.56 TB |
| 实测峰值 RSS | 8.24 GB |
| 引擎自身体积 | 176 KB |
| 需要的 GPU | 0 |
8GB 内存的笔记本，每个 token 26.5 秒；32GB 高端本是 24.2 秒；64GB 台式机 19.8 秒；128GB 以上工作站 5.6 秒——因为整个模型终于装进内存，不用等盘了。
这里最值得注意的是另一个数字：作者说 从最小机器到最大机器，输出是逐字节完全一致的，只有时钟在变。这跟 colibri 的 “语义硬保证” 是同一个执念，只是实现方式不同——colibri 靠可复现的端到端测量和逐位置对拍 vLLM，kimi-k3-in-c 靠把浮点累加顺序固定下来。1.0.0 版本让每 token 的数学运算轻了约 8 倍，聊天里的追问快 3.9 倍，长 prompt 的成本砍掉一半。
支持 Linux、macOS（含 NEON）、Windows，AVX2 路径，MXFP4 量化内核，77 个提交。它还诚实标注了 demo 录像来自较慢的硬盘，所以时钟读数偏高。
讲点实在的
两个项目加一起 4.7 万星，但我不打算假装你明天就能用上。
Kimi K3 的 checkpoint 是 1.56 TB，GLM-5.2 的 int4 容器是 372GB。 你得先有一块放得下、能读得动的盘。README 里那句”速度由你的硬盘决定，慢盘上是每几秒一个 token，快盘缓存热了才是每秒几个”不是营销话术，是物理事实。
26.5 秒一个 token 和 5.6 秒一个 token，差的是 4.7 倍，但都远慢于任何云 API。 本地推理赢的不是速度，是隐私、成本和”模型不会被下架”。你要是就想快点拿到答案，这俩都不如开个 API。
它们是研究平台，不是产品。 colibri 自己写着 “no SLA on speed”，2438 个提交里大量是边界探索和精度争议。你要是想要稳定吞吐，去用 vLLM 或 llama.cpp。
我的真实看法是：这俩的价值不在于”我可以用 744B 模型聊天了”，而在于把三个通常被藏起来的成本摊在桌面上——权重从哪来、每个 token 到底要读多少专家、浮点数在哪一步会骗你。colibri 那个 7 倍加速的数字之所以有说服力，是因为它附了一句”输出逐比特一致”；kimi-k3-in-c 那个 26.5 秒之所以有说服力，是因为它列了从 8GB 到 128GB 的完整阶梯。愿意公布最难看那个数字的项目，通常在做的事更真。
真要上手，我会先跑 colibri 的 Qwen3.6（35B-A3B，约 20GB），它是这堆里唯一你我真的有机器能跑的；744B 以上的项目，留给有 128GB 内存和 NVMe 阵列的人去折腾。
by 数码罗记 · godsun.pro
参考
– colibri — https://github.com/JustVugg/colibri
– kimi-k3-in-c — https://github.com/FareedKhan-dev/kimi-k3-in-c
本文实测数据均取自两个项目官方 README 与仓库元数据（2026-10-02 核实），非本人复现。
