**colibri 是一套用純 C 寫成的開源 MoE 推論引擎，讓你在 16GB RAM 的普通電腦上跑 744B 參數的 GLM-5.2 這類前沿模型。**它不靠 GPU 堆料，而是把「模型必須塞進記憶體」這個前提拆掉：注意力與共享專家留在 RAM，19,456 個路由專家放在 NVMe 上串流讀取，用類似 JIT 的思維——只載入路由證明會用到的那幾個。
專案位置：https://github.com/JustVugg/colibri（截至 2026-09-13：29,504 stars、3,215 forks、Apache-2.0、建立於 2026-07-01，持續日更）。官網與文件：https://justvugg.github.io/colibri
為什麼這個專案值得看？
大部分人的推論引擎選擇是 Ollama（好用）、llama.cpp（CPU 友善）、vLLM（GPU 吞吐）。但這三個工具都有同一個隱含前提：模型的權重放得下。當模型進入「744B 稀疏 MoE」這個量級，前提就不成立了——就算你有 24GB 顯卡，也裝不下 372GB 的權重。
colibri 解的是這個問題：它把儲存、RAM、VRAM 當成同一個推論階層（README 稱之為 AI memory multitiering），並把放置決策（placement）與模型語意嚴格切開。它反覆強調一句話，這也是我覺得整個專案最值得信任的地方：
記憶體不足只會降低速度，不會偷偷改動模型精度或 router 語意。
以 744B 的 GLM-5.2 為例：每個 token 只啟動約 40B 參數，而其中真正「每 token 都在變」的只有約 11GB 的路由專家。所以模型不需要「裝得下」，它只需要被擺對位置：
| 部位 | 參數量 | 放哪裡 | 大小（int4） |
|---|---|---|---|
| 稠密部分（attention、共享專家、embedding） | ~17B | 常駐 RAM | ~9.9 GB |
| 路由專家（75 層 × 256 + MTP head，共 19,456 個） | ~763B | NVMe，依路由串流 | ~370 GB |
| 熱門專家快取 | 動態 | RAM / VRAM 分層 | 依你的記憶體自動規劃 |
引擎處理每一個 token、每一層時都走同一條五步路徑。放置決策只決定速度，不改變 router 的決策或權重精度——這是這個專案最重要的設計約定：
flowchart TD
A["使用者送出 token"] --> B["Router 選出本層需要的專家"]
B --> C["Batch-union：同一層只讀一次"]
C --> D["專家住在哪一層？"]
D --> E["VRAM 命中：GPU 直接計算"]
D --> F["RAM 命中：CPU 從記憶體計算"]
D --> G["磁碟未命中：非同步 pread 載入"]
G --> H["寫入 LRU 快取與學習式 hot-store"]
H --> F
E --> I["輸出並更新路由熱度"]
F --> I| 步驟 | 發生什麼事 | 誰在決定 | 你可以調的旋鈕 |
|---|---|---|---|
| 1. Route | Router 選出這一層要用的專家（top-k） | 模型本身（語意不可改） | — |
| 2. Union | 同一批次的位置一起路由，同一個專家只讀一次（batch-union） | 引擎 | PIPE=1 |
| 3. Place | 判斷專家現在住在哪一層：VRAM → RAM → NVMe | 引擎的放置規劃器 | --ram、CUDA_EXPERT_GB、PIN_GB |
| 4. Overlap | 磁碟未命中時，非同步 pread 與已常駐專家的計算重疊；PILOT=1 以前視預取下一層專家（路由具 71.6% 可預測性） | 引擎 | DIRECT=1、PILOT=1 |
| 5. Learn | 把路由熱度寫進 .coli_usage，更新 per-layer LRU 與學習式 pinned hot-store | 引擎（用得越久越快） | ./coli tune |
核心技術：把權重當成可以「即時編譯」的資料
colibri 的設計類比是「權重的 JIT」：編譯器不會編譯整支程式，只編譯實際跑到的熱路徑；同樣地，這個引擎不用把 744B 參數全部常駐，而是靠可量測的路由結構來決定誰該進哪一層快取。主要機制：
- 三層放置：VRAM、RAM、NVMe 只是同一份權重的不同層級；放到哪一層只影響速度。
- 學習式快取：引擎會記錄「你的工作負載」路由到哪些專家（
.coli_usage，每輪更新），自動把最熱的專家 pin 在快記憶體——用得越久越快。 - Router lookahead（
PILOT=1）：實驗量測路由在一層之前有 71.6% 可預測性，用這一層的前置時間去預取下一層的專家。 - I/O 當第一級公民：專家的三個矩陣相鄰存放、一次
pread讀完；有界的非同步 I/O pool（PIPE=1）讓讀取與計算重疊；O_DIRECT（DIRECT=1）繞過 page cache，在 DRAM 快取的磁碟上實測 decode +34%（某台 GB10 上 iobench 由 4.25 GB/s 提升到 9.69 GB/s）。 - 雙 SSD 鏡像：專家讀取是唯讀的，所以你可以把模型複製一份到第二顆 SSD，引擎以確定的 hash 依兩顆磁碟實測頻寬分配讀取。9 GB/s + 3 GB/s 的組合，讀取速度比只用快的那顆快約 33%。
- 壓縮的 KV 狀態：MLA attention 的 KV 狀態從每 token 32,768 個 float 壓到 576 個（縮小 57 倍），而且會持久化到
.coli_kv，重開對話不必重新 prefill。 - 投機解碼（MTP）：GLM-5.2 原生 MTP head 每輪可賺到 2.2–2.8 tokens/forward；前提是 head 必須是 int8（int4 head 的接受率會掉到 0–4%）。
支援哪些模型？
目前有九個家族、每個家族各自是一支 C 檔（c/colibri.c、c/kimi_k3.c…），共用同一組 header 與 coli chat / serve / web 前端：
| 模型家族 | 總參數 / 啟用 | 磁碟需求 | RAM 需求 | GPU |
|---|---|---|---|---|
| OLMoE（AI2） | 7B / 1B | ~7 GB | 8 GB | 不需要 |
| GLM-5.2 / 5.3（Z.ai） | 744B / 40B | ~372 GB | 16 GB 起，24 GB 舒適 | 不需要 |
| GLM-5.3-Flash（含視覺） | 321B / 40B | ~195 GB | 25 GB | 不需要 |
| Inkling（Thinking Machines） | 975B / 41B | ~469 GB | 25 GB（int4 稠密版） | 不需要 |
| Kimi K3（Moonshot） | 2.8T / 104B | ~1.6 TB | 32 GB+ | 不需要 |
| DeepSeek V4 Flash | 284B / 13B | ~167 GB（REAP 150B 版 ~85 GB） | 16 GB 起，32 GB 舒適 | 選配（GTX 10 系列以上即可） |
| DeepSeek V4.1 Flash（含視覺） | 552B / 16B | ~203 GB | 24 GB 級 | 選配 |
| Qwen3.8-Flash-Next | 125B + 51B n-gram / 6B | ~185.5 GB | 16 GB 起 | 不支援（僅 CPU） |
| Qwen3.6-35B-A3B | 35B / 3B | ~20 GB | 24 GB | 選配（兩張 8GB 卡實測 7 倍加速） |
重點：沒有一個模型需要 GPU。 GPU 只會讓它更快，真正的速度上限是你的磁碟——專家是從磁碟串流出來的。
實測速度對照表（官方 benchmark）
同一顆引擎、同一個 int4 容器，差別只在「專家住在哪一層」：
| 硬體 | decode 速度 | 備註 |
|---|---|---|
| 6× RTX 5090（專家全常駐） | 5.8–6.8 tok/s | TTFT ~13 秒；另一份實驗記錄 6.84 tok/s |
| 128 GB RAM 純 CPU 桌機 | ~1.8 tok/s（暖機後） | 沒有 GPU |
| 單張 RTX 5070 Ti 筆電 | 1.07 tok/s | 走 GPU 常駐管線 |
| 25 GB 開發機（原始開發環境） | 0.05–0.1 tok/s（冷啟動） | 誠實的底線：磁碟 1 GB/s、每 token 讀 ~11 GB |
| Qwen3.6-35B-A3B + 兩張 8GB 卡 | 1.44 → 10.05 tok/s（7.0×） | CUDA 專家分層，輸出與 CPU 路徑 bit-identical |
參考值：模型在磁碟上 ~370 GB、常駐 RAM 9.9 GB、載入約 30 秒、聊天時峰值 RSS ~20 GB（自動上限）、冷啟動每 token 讀約 11 GB。
先講清楚：這不是「快」。 這是一台成本不到一顆 H100 風扇的機器，正確回答一個 744B 前沿模型的問題。接受了這件事，這個專案才看得懂。
安裝：兩條路
路線 A：下載預編譯檔（不用編譯器）
到 Releases 頁面 抓符合平台的壓縮檔（Linux / macOS / Windows 都有）：
mkdir colibri && tar xzf colibri-v1.8.0-linux-x86_64.tar.gz -C colibri && cd colibri
python3 coli info # 顯示 engine ready ✓ 就完成
只需要另外安裝 Python 3（coli 啟動器與 API gateway 是 Python 腳本），引擎本身是純 C、零相依。Windows 使用者解壓後雙擊 coli.cmd 即可。
路線 B：從原始碼編譯（想榨出本機 CPU 極限，或要改引擎）
# Ubuntu / Debian
sudo apt update && sudo apt install -y build-essential git python3
git clone https://github.com/JustVugg/colibri.git && cd colibri/c
./setup.sh
setup.sh 會檢查 gcc／OpenMP、編譯並跑自我測試，看到 engine self-test: 32/32（或 30–32/32）就是正常。ARM64（AWS Graviton、Ampere、Raspberry Pi 64-bit）可直接編譯，沒有 ARM 專屬旗標；macOS 需要 xcode-select --install 加 brew install libomp。
取得模型：務必用 gs64 容器
官方預轉好的 GLM-5.2 int4 容器在 Hugging Face，約 372 GB，請放在快的磁碟：
# 建議：mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp
# 注意兩件事：
# 1) 一定要用 group-scaled (gs64) 版本，舊的 per-row int4 容器品質差約 9pp，
# 而且會造成 think-mode 迴圈與永不停止的生成（issue #455）
# 2) MTP head 必須是 int8，int4 會讓投機解碼接受率掉到 0~4%（issue #8）
想自己轉也行，而且是「可中斷續跑」的單一指令，過程不需要同時放下 756 GB：
./coli convert --model /nvme/glm52_i4 # 逐 shard 下載＋轉換，只跑一次
跑起來：常用指令
COLI_MODEL=/nvme/glm52_i4 ./coli doctor # 唯讀健檢：環境、模型檔、權限
COLI_MODEL=/nvme/glm52_i4 ./coli plan # 先看它打算怎麼擺放 VRAM/RAM/磁碟
COLI_MODEL=/nvme/glm52_i4 ./coli chat # 進入 TUI 對話
COLI_MODEL=/nvme/glm52_i4 ./coli chat --topp 0.85 # 磁碟瓶頸機器推薦：少讀、品質不變
./coli serve --model /nvme/glm52_i4 # OpenAI 相容 API + 網頁儀表板（無瀏覽器）
./coli web --model /nvme/glm52_i4 # 同上，並自動開瀏覽器
COLI_MODEL=/nvme/glm52_i4 ./coli tune # 量測並存下這台機器最快的安全參數
網頁儀表板值得一看：它會顯示即時的 tok/s、TTFT、每輪時間拆解，以及 VRAM／RAM／disk 三層的比例。它還有個「Brain」頁，把 19,456 個專家畫成即時皮質——顏色代表存放層級、亮度代表路由熱度，被路由到的專家會閃白光。要理解這個引擎在幹什麼，看那張圖比讀十頁文件快。
效能調校：五個真正有用的開關
| 參數 / 環境變數 | 作用 | 什麼時候用 |
|---|---|---|
--ram N | 專家快取預算 | 最划算的旋鈕，只影響速度、不影響輸出；給越多越快 |
--topp 0.85 | 每 token 讀更少專家位元組 | 磁碟受限的機器，品質無損 |
DIRECT=1 | O_DIRECT 繞過 page cache | 有 DRAM 快取的 NVMe；QLC／無 DRAM／虛擬磁碟可能反而變慢，實測再決定 |
PIPE=1 / PILOT=1（預設開） | 非同步 I/O 重疊＋路由前視預取 | 大多數機器保持預設即可 |
COLI_MODEL_MIRROR= | 第二顆 SSD 鏡像 | 你有第二顆 SSD，且願意放一份模型副本 |
雙 SSD 的完整流程（先跑幾輪代表性 prompt 讓 .coli_usage 反映你的工作負載，再規劃鏡像）：
./c/coli mirror plan --model /fast/glm52_i4 --mirror /second/glm52_i4 --budget-gib 200
./c/coli mirror stage --model /fast/glm52_i4 --mirror /second/glm52_i4 --budget-gib 200
./c/coli mirror verify --model /fast/glm52_i4 --mirror /second/glm52_i4
規劃器會直接讀 safetensors header，優先複製「最熱路由專家」所在的 shard，每個 shard 都用 SHA-256 驗證，而且永不刪除既有的鏡像 shard——所以第二顆 SSD 只放得下一部分也有效。
跟 Ollama、llama.cpp、vLLM 怎麼選？
| 工具 | 主要場景 | 記憶體策略 | 適合誰 |
|---|---|---|---|
| colibri | 744B–2.8T 稀疏 MoE 在消費級硬體 | VRAM/RAM/NVMe 三層串流，學習式專家快取 | 想在本機跑前沿量級模型、能接受每秒不到幾個 token 的人 |
| Ollama | 一鍵跑 7B–70B 級量化模型 | 全部權重進 RAM／VRAM | 想快速開始、要穩定互動速度的人（Ollama 介紹） |
| llama.cpp | GGUF 生態、CPU／Metal 友善 | 全量載入為主，部分 offload | 需要最大模型支援度與社群量化資源 |
| vLLM | 伺服器端高吞吐、多併發 | PagedAttention，重度依賴 GPU VRAM | 服務多用戶、追求吞吐與併發（vLLM 介紹） |
| Twinny | 在 VS Code 裡接本機模型 | 取決於你接的後端 | 想要 IDE 內補全與對話（Twinny 介紹） |
一句話區分：colibri 不是要取代 Ollama，而是處理 Ollama 根本跑不動的那些模型。
常見問題
colibri 需要 GPU 嗎？
不需要。九個模型家族都能純 CPU 執行，GPU 只是加速選項；DeepSeek V4 系列甚至支援 Pascal／Turing 老卡（CUDA_ARCH=portable-pre-ampere NO_TC=1）。
只有 16GB RAM 的筆電真的跑得動 744B 模型嗎？
可以，但會很慢。官方的最低配置是 16GB RAM 加約 380GB 磁碟空間；25GB 的開發機跑 GLM-5.2 冷啟動約 0.05–0.1 tok/s。想先感受這個引擎，建議從 OLMoE（7B，8GB RAM、~7GB 磁碟） 或 Qwen3.6-35B-A3B 入門。
為什麼大家都說「磁碟決定速度」？
因為路由專家是從磁碟串流進來的。744B 模型冷啟動時每個 token 要讀約 11GB，你的磁碟有多少 GB/s，就大致決定了每秒幾個 token。
跑這種東西會不會把 SSD 操壞？
專家讀取是唯讀的，官方說法是不會有意義的耗損。真正要注意的是兩件事：一是 RAM 不足時的 swap 寫入（--ram 預算就是為了避開它），二是長時間滿載讀取的溫度。
這可以拿來當多人服務的 API 嗎？
可以，./coli serve 提供 OpenAI 相容 API，引擎還支援叢集模式（coordinator 產生 token，其他機器上的 worker 執行被路由到的 FFN）。但它的定位是「能力展示與研究平台」，官方明確說不對速度提供 SLA，只保證語意一致。
我的觀察：這個專案最不尋常的地方
多數開源專案的 README 是行銷文件；colibri 的 README 更像一份實驗紀錄。它自己列出六個「尚未被證實的假設」，每一條都寫明「目前證據」與「還需要什麼實驗」，甚至寫下負面結果（例如 MTP 在專家命中率約 85% 時曾量測到 32% 的損失、投機解碼在 V4 上因為重播成本太高而預設關閉）。
它也歡迎你貢獻失敗的實驗：「一個控制良好的失敗，比一個無法解釋的快數字更有價值。」在充斥著 tok/s 幻覺的本地模型圈，這種態度比任何 benchmark 數字都值得參考。
延伸閱讀
- Ollama：以類 Docker 簡潔風格在本機執行開源 LLM
- vLLM：具備 PagedAttention 的高吞吐量 LLM 推論引擎
- Twinny：在 VS Code 內使用本機 LLM 的免費 Copilot 替代方案
- Kimi K3 開源：Moonshot 推出 2.8T 參數模型（colibri 已支援）
- Proxmox VE 9 完整指南：自架虛擬化環境
資料來源
- colibri GitHub 儲存庫與 README：https://github.com/JustVugg/colibri
- colibri Quick Start 指南：https://github.com/JustVugg/colibri/blob/main/docs/quickstart.md
- colibri Benchmarks（實測數據）：https://github.com/JustVugg/colibri/blob/main/docs/benchmarks.md
- 官方網站：https://justvugg.github.io/colibri