近日一位獨立開發者打造了一套名為 Colibri（colibrì）的純 C 語言推理引擎，成功在僅有 25GB RAM 的消費級筆電上執行 GLM-5.2，一個擁有 7,440 億參數（744B）的開源 MoE（混合專家）模型。這項專案在 Hacker News 上獲得超過 730 分與 180 則討論，被社群譽為「駭客精神的極致展現」。Colibri 的核心只有約 2,400 行 C 語言程式碼，完全零依賴，執行時不需要 Python、不需要 GPU、不需要 BLAS 數學函式庫。開發者表示：「速度不是重點，達成這個目標的旅程才是。我只是想讓它跑起來，即使很慢也沒關係。」
Colibri：讓 7,440 億參數的 GLM-5.2 在 25GB RAM 筆電上運行
GLM-5.2 是什麼？為什麼能在低記憶體上跑？
GLM-5.2 是由中國 AI 團隊 Z.ai 開發的開源大型語言模型，也是目前為止能力最強的開源模型。擁有 7,440 億個參數，訓練資料量達 28.5 兆 tokens，在多項基準測試中達到頂尖水準。若以傳統的密集模型（Dense Model）架構，光是將模型載入記憶體就需要超過 1.5TB 的 RAM，遠非一般消費硬體所能負擔。
但 GLM-5.2 採用 MoE（Mixture of Experts）架構，這是它能在低記憶體環境下運作的關鍵。MoE 模型的核心概念是：雖然總共有 7,440 億個參數，但每次處理一個 token（文字單位）時，只會啟動其中約 400 億個參數（約 5%）。其餘的參數以「專家」（expert）的形式存在，只有在被路由器（router）選中時才會被呼叫。
Colibri 的開發者正是抓住了這個特性：每次 token 處理時，會改變的權重只有約 11GB（即被選中的 routed experts）。其餘的密集層（注意力機制、共享專家、嵌入層等，約 170 億個參數）可以在記憶體中常駐。這讓 Colibri 得以在 25GB RAM 的機器上運作。
I managed to run GLM-5.2 (744B MoE) on a humble 25 GB RAM laptop — pure C, experts streamed from disk
byu/Just_Vugg_PolyMCP inLocalLLM
Colibri 的技術實作
Colibri 的運作策略非常直觀：將模型分為兩部分處理。密集部分（注意力層、共享專家、嵌入層等約 170 億個參數）以 int4 量化後常駐在 RAM 中，約佔 9.9GB。而其餘 21,504 個 routed experts（來自 75 個 MoE 層 × 256 個專家，加上 MTP 預測頭）則存放在硬碟上，總計約 370GB，每個專家約 19MB，按需串流載入。
為了提升效率，Colibri 實作了多項最佳化技術：每層的 LRU 快取機制讓常用的專家留在記憶體中；非同步專家預讀（async expert readahead）讓磁碟讀取與矩陣運算重疊進行；路由器前瞻預取（router-lookahead prefetch）利用相鄰層之間 71.6% 的路由可預測性，提前載入下一層可能需要的專家。
Colibri 也實作了 GLM-5.2 原生的 MTP（Multi-Token Prediction）投機解碼功能。模型第 78 層的 MTP 頭會先草擬多個候選 token，再由主模型批次驗證。在 int8 量化的 MTP 頭下，草稿接受率可達 39% 到 59%，每次前向傳播可產生 2.2 到 2.8 個 token。不過開發者坦承，在冷快取狀態下，投機解碼反而會因為需要載入更多專家而變慢。
此外，Colibri 還實作了 MLA 注意力機制（含壓縮 KV 快取，每個 token 只需 576 個浮點數而非 32,768 個，縮小 57 倍）、DSA 稀疏注意力（每層只選 top-2048 的因果鍵）、以及 int8/int4 整數矩陣運算核心（AVX2 指令集加速）。KV 快取還支援跨重啟持久化，對話可以在引擎重啟後無縫接續。
實際效能資料
開發者在自己的機器上（WSL2、12 核心、25GB RAM、NVMe 透過 VHDX）測得的資料如下：模型載入時間約 30 秒，常駐記憶體 9.9GB，聊天時峰值 RSS 約 20GB（自動上限）。冷啟動時每次 token 需要讀取約 11GB 的磁碟資料（75 層 × 8 個專家），在 VHDX 隨機讀取約 1GB/s 的限制下，冷推理速度約為每秒 0.05 到 0.1 個 token。
當快取暖機後，加上 MTP 投機解碼與熱專家釘選，實用回應延遲會顯著降低。社群回報在更快的 NVMe 與更多 RAM 的配置下，可達到每秒 1 個 token 以上的速度。開發者強調：「我沒有更好的硬體，所以無法在更強大的機器上測試。」
Colibri GitHub 專案網址
Colibri 的限制與挑戰
Colibri 雖然技術上令人驚嘆，但離實用化仍有相當距離。首先是速度問題：冷啟動時每秒僅 0.05 到 0.1 個 token，意味著生成一段 100 個 token 的回覆需要 15 到 30 分鐘。即使在最佳條件下，暖快取搭配 NVMe 也僅能達到約每秒 1 個 token，遠低於雲端 API 或 GPU 推理的體驗。
其次是儲存空間需求：int4 量化後的模型仍需約 370GB 的磁碟空間，而原始 FP8 模型更高達 756GB。雖然轉換工具可以逐個 shard 下載轉換，不須一次佔滿 756GB，但 370GB 的模型檔案對多數消費者的 SSD 來說仍是可觀的空間佔用。
第三是 SSD 壽命與散熱問題。開發者在 README 中坦承，冷啟動時每次 token 需要約 11GB 的隨機讀取，雖然讀取不會像寫入那樣磨損 SSD，但長時間滿載讀取會導致較低階的 SSD 溫度升高。此外，若系統 RAM 不足而觸發 swap 寫入，則會影響 SSD 壽命。
第四是 MTP 投機解碼的實用性限制。MTP 頭必須使用 int8 量化（int4 下草稿接受率僅 0% 到 4%），且在冷快取狀態下，每次驗證草稿需要載入更多專家（從約 660 個增加到約 1,100 個），反而可能導致淨時間損失。開發者提供了 DRAFT=0 的選項來關閉此功能。
第五是缺乏 GPU 加速。雖然 Colibri 有實驗性的 CUDA 分層支援，但核心引擎完全依賴 CPU 運算，無法利用 GPU 的大規模平行運算能力。對於擁有 GPU 的用戶，llama.cpp 等成熟框架可能是更實際的選擇。
結語
Colibri 的價值在於它證明了 MoE 模型的架構特性可以被極致利用到何種程度，而非它的速度或實用性。一位 Hacker News 使用者精準總結，這個專案證明了 MoE 推理可以在消費硬體上實現。開發者也在訪談中提到，他的靈感來自 Redis 作者 antirez 的 ds4 專案，同樣在探索以磁碟串流方式執行 GLM-5.2。對於需要本地執行大型模型的場景，更實際的選擇可能是使用 256GB 以上的 Mac Studio、多 GPU 工作站，或直接使用雲端 API 比較實際。