開源社群今（11）日迎來一項重磅成果：獨立開發者 JustVugg 釋出 Colibrì，一個僅約 2,400 行程式碼的純 C 推論引擎，能在配備 25 GB RAM 的消費級筆電上，運行 Zhipu AI（智譜）甫於六月開源的 744B 參數 Mixture-of-Experts 模型 GLM-5.2。專案自 2026 年 7 月 1 日上線十天內便累積近 3,000 顆星、衝上 Hacker News 榜首第 8 名，並在 r/LocalLLaMA 拿下 805 票、258 則留言，一舉成為本地 LLM 圈最熱門的話題。
編按：本文綜合整理自 GitHub: JustVugg/colibri、Hacker News Show HN 討論串、Z.ai GLM-5.2 官方部落格，並加入 Siami 編輯部觀點與分析。
技術核心：把 RAM 不夠的問題「外包給 SSD」
Colibrì 的設計哲學相當激進——GLM-5.2 雖然總共有 744B 個參數，但因為是 MoE 架構，每生成一個 token 實際只啟動大約 40B 參數，其中真正會切換的 routed expert（路由專家）只有約 11 GB。其餘 21,504 個專家層（75 層 × 256 個 experts，加上 MTP 預測頭，總計約 370 GB）平常就靜靜躺在硬碟上，需要時才以 mmap 串流讀進來。
實作細節包括：
- MLA 壓縮 KV cache：每個 token 只需 576 個浮點數（壓縮比達 57 倍，因為 GLM-5.2 沒有 GQA、64 個 head）
- DSA 稀疏注意力：每層只保留 top-2048 的鍵，把記憶體與頻寬壓在能負擔的範圍
- MTP 投機解碼：int8 的多 token 預測頭在社群實測下可達 2.2–2.8 token / forward 的接受率
- Async expert readahead：kernel 計算當下，I/O 已經把下一批 experts pread 進來
- byte-level BPE tokenizer in C：連 tokenizer 都自己刻，零相依
README 強調：「This is not fast.」冷啟動時 SSD 隨機讀取受限於消費級硬碟的 ~1 GB/s 速度，大約只能產生 0.05–0.1 token / 秒——一杯咖啡的時間大概只能生成一個句子。
為什麼這件事重要
MoE 模型的硬體門檻正在崩解。 在 Colibrì 出現之前，跑一個前沿級 MoE 模型通常意味著「你需要 8 張 H100 或 256 GB 統一記憶體的 Mac Studio」，這對絕大多數開發者、研究者、新興市場工程師都是天文數字的開支。Colibrì 用一份約 370 GB 的 int4 量化權重加上 25 GB RAM，把這道牆從「資料中心等價」拉低到「中階工作站可負擔」。
這對整個開源 LLM 生態有三層意義：
- 離線 / 隱私應用變得可行：企業內部部署可以不再依賴 OpenAI、Anthropic 或 Z.ai 的 API，特別是在資料落地需求強的金融、醫療、國防場景
- 研究可重現性：學術界終於能在自己的機器上跑前沿模型做消融實驗，不用排隊等雲端 GPU
- 地緣政治平衡：Colibrì 與 GLM-5.2 同樣為 Apache-2.0 / MIT 開源，這代表非美國開發者第一次能用「不經美國雲端」的方式接觸接近前沿的能力
更值得注意的是 Z.ai 對 GLM-5.2 的授權選擇——MIT license、無地區限制、無技術訪問壁壘（官方原文：“no regional limits, technical access without borders”）——與 Colibrì 的 Apache-2.0 形成雙重保障，幾乎沒有任何商業部署的法律障礙。
數據解讀：哪些數字值得質疑
作者在 README 提供了誠實到近乎自白的基準數據：
- 模型在 int4 磁碟佔用約 370 GB，光這點就排除了絕大多數筆電（典型 1 TB NVMe 還勉強放得下，但會嚴重擠壓其他用途）
- 冷解碼每個 token 約 11 GB 的硬碟讀取，這對 SSD 的持續讀取壽命是個真正考驗（雖然 SSD 的讀取磨損極低，但 60°C+ 的高溫是個實務問題）
- Strix Halo + Optane 905p 暖快取的數據從 0.16 → 0.40 tok/s，在五次連續運行後達到——這代表了「真實可用」的下限，但仍遠低於即時對話所需的 ~15 tok/s
社群在 Reddit r/LocalLLaMA 的留言也點出關鍵限制：跑得起不代表跑得順，0.05 tok/s 的速度對程式開發輔助、批次翻譯這類非同步任務才有意義；對即時聊天仍不實用。Strix Halo 暖快取達 0.40 tok/s 是目前最樂觀的情境，但前提是要搭 Optane 這類極低延遲的儲存設備。
另一個值得追蹤的數據點：作者 MarkA 約 86% 的 ML 框架「多出來的複雜度」是解釋給自己聽的安慰話——HN 留言指出 llama.cpp、vLLM 等框架加了大量為分散式訓練與多 GPU 同步服務的程式碼，對「單機串流」這個場景其實是過度設計。Colibrì 用 2,400 行 C 就抵達可用狀態，這暗示 MoE + SSD-streaming 這條技術路線可能催生一個全新的推論框架類別。
社群回應與後續發展
Colibrì 的社群迴響相當兩極但正面。在 Hacker News 的 Show HN 討論串中，最熱門的一則留言直接寫道：「看到一個 2,400 行的 C 檔就跑得起 744B MoE，真的會懷疑現代 ML 框架到底解決了什麼」拿到最高票。r/LocalLLaMA 的開發者則興奮於「在我的硬碟上跑一個會講義大利文的前沿模型」的體驗——多語言 benchmark 在這台 colibri 跑出的成績逼近 Claude 等閉源模型的早期版本。
專案十天內已經出現多個有意義的社群貢獻：
- nalepy 提交 Windows 11 原生移植（Phase 1：MinGW-w64 靜態編譯 + compat shims），讓不裝 WSL 的 Windows 用戶也能跑
- 0xhis 改進量化 matmul 與 MoE 路由的執行緒分配，把 allocation overhead 壓下來
- 社群成員 matey-0 開了一個 Hugging Face 分支把 MTP head 從 int4 升回 int8——這是因為 int4 的接受率會崩到 0–4%、投機解碼根本跑不起來
M3 Ultra Mac Studio 上則已經出現另一條對比路線：1-bit GGUF 量化版的 GLM-5.2 達到 ~21.6 tok/s，證明「極限量化」也是一條可行道路，但代價是模型品質的可測量下降。
現實限制與下一步
不諱言，Colibrì 還在 Phase 1。README 列出的未完成項目包括：
- O_DIRECT 繞過 OS page cache（Phase 2）——對 NVMe 的低延遲存取會是個關鍵優化
- GPU 支援（Phase G0-G2）——透過
LoadLibrary("coli_cuda.dll")的 opt-in 路徑，目前還沒實作 - 完整的 full-model validation（對應讀者最有感的指標還沒補上）
若你是 Linux / WSL2 用戶、有 ~400 GB 可用硬碟空間、有耐心等一個句子 30 秒，現在就能 clone 下來玩玩：
git clone https://github.com/JustVugg/colibri
cd colibri/c && ./setup.sh
COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat轉換工具會自動一個 shard 一個 shard地下載 GLM-5.2 FP8 權重（756 GB），就地轉成 int4 container——整個過程永遠不需要 756 GB 的空間同時存在。對想體驗「開源前沿模型在自己機器上跑」的開發者來說，這可能是 2026 年最值得花一個週末試試的專案。
網友熱門留言 (5)