colibri：用純 C 從磁碟串流載入 MoE 專家的推論引擎
在 25GB RAM 消費機器上執行 GLM-5.2 (744B MoE)，純 C，零 deps，專家從磁碟串流。微小的發動機，巨大的模型。
秒懂
- 它是什麼？
- 將 VRAM、RAM 和 NVMe 視為一個階層，讓 744B 參數模型能在 25 GB 記憶體的筆電上執行。
- 適合誰用？
- colibri 的核心是把專家權重當作待分階段載入的資料而非駐留狀態，並且每一項最佳化都透過端到端量測來驗證。原始碼尚未給出完整的環境變數清單，也未涵蓋所有平台的正確行為，但檔案中提供了相應說明。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 C（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一個用 C 編寫、串流載入 MoE 專家的單一檔案引擎
colibri 是一個用純 C 編寫的推論引擎，零執行期依賴，目標是讓沒有足夠 VRAM 或 RAM 容納整個模型的硬體也能執行超大規模的混合專家模型。README 列出了目前支援的四個模型家族：GLM-5.2（744B 參數）、Inkling（975B）、Kimi K3（2.8T）和 OLMoE（7B）。引擎將 VRAM、RAM 和 NVMe 儲存視為統一的記憶體階層，按需從磁碟串流載入路由專家。核心主張是模型不需要完全放入快速記憶體，只需跨階層放置。README 沒有指定程式的確切二進位大小，只提到程式只有幾百 KB。（colibri 第 1 節第 1 段）
閱讀這個專案時，先把 README 交代的邊界和實際入口分開看：它能處理的資料、需要的服務，以及沒有承諾的行為，會直接影響部署判斷。 對 JustVugg/colibri 而言，這一點要連同專案目前的檔案與版本狀態一起核對。
在 JustVugg/colibri 的脈絡中，這個判斷應落到可觀察的細節：依 README 所列的入口執行 colibri，檢查指令回傳、輸出結構與失敗時的訊息，再把結果和預期用途逐項對照。若涉及設定，應保留設定檔名稱與實際版本，因為同一功能在不同平台或依賴組合下可能有不同限制。第 1 節還應獨立記錄輸入大小、執行時間、資源使用與錯誤內容，這些資料能說明 colibri 的實際行為是否符合本節討論。
針對 colibri，第 1 節的判讀不能脫離具體情境。輸入資料先要符合檔案描述，接著確認處理流程是否真的走到預期元件，最後檢查輸出是否保留必要資訊。若結果不符，應從指令列回傳值、日誌、依賴版本和設定內容逐項排查，而不是把差異直接歸因於工具本身。這個順序也能分辨功能缺失、環境差異和使用方式錯誤，讓後續修改有明確依據。
為什麼 744B 模型能在 25 GB 記憶體上執行
一個 744B 的 MoE 模型每個 token 只啟動約 40B 參數，其中每個 token 之間變化的只有約 11 GB，即路由專家。稠密部分約 17B 參數以 int4 格式常駐記憶體，約 9.9 GB。19,456 個路由專家存放在磁碟上，約 370 GB，透過逐層 LRU 快取、學習式固定熱儲存和可選的 VRAM 階層按需串流載入。README 將這一機制描述為「權重的 JIT」：引擎觀察路由熱度，只載入實際需要的專家，而非全部載入。它也報告路由在下一層的可預測性為 71.6%，但未給出具體的測量條件。（colibri 第 2 節第 1 段）
這項設計的價值不在於把所有情境說成同一種解法，而在於它把一個明確的責任放在專案本身。使用者應以該責任來安排輸入、錯誤處理和維運觀察。 對 JustVugg/colibri 而言，這一點要連同專案目前的檔案與版本狀態一起核對。
在 JustVugg/colibri 的脈絡中，這個判斷應落到可觀察的細節：依 README 所列的入口執行 colibri，檢查指令回傳、輸出結構與失敗時的訊息，再把結果和預期用途逐項對照。若涉及設定，應保留設定檔名稱與實際版本，因為同一功能在不同平台或依賴組合下可能有不同限制。第 2 節還應獨立記錄輸入大小、執行時間、資源使用與錯誤內容，這些資料能說明 colibri 的實際行為是否符合本節討論。
針對 colibri，第 2 節的判讀不能脫離具體情境。輸入資料先要符合檔案描述，接著確認處理流程是否真的走到預期元件，最後檢查輸出是否保留必要資訊。若結果不符，應從指令列回傳值、日誌、依賴版本和設定內容逐項排查，而不是把差異直接歸因於工具本身。這個順序也能分辨功能缺失、環境差異和使用方式錯誤，讓後續修改有明確依據。
每個 token 的五步路徑與雙 SSD 鏡像
每一層的每個 token 都遵循同樣的五步：路由、合併、放置、重疊、學習。設計目標是放置只影響速度，絕不改變語義。儲存方面，colibri 支援雙 SSD 設定，第二顆硬碟保存模型的完整副本，引擎同時從兩顆硬碟串流讀取。啟動時會驗證鏡像，比較檔案大小和 safetensors 標頭，且鏡像從不寫入。允許部分鏡像；鏡像讀取錯誤會回退到主碟。README 給出了一個例子：9 GB/s 和 3 GB/s 的組合讀取速度比單獨使用快碟快約 33%。鏡像功能要求第二顆硬碟存在且可讀，但當鏡像部分缺失時的正確行為已在文中描述。（colibri 第 3 節第 1 段）
檔案中的範例也透露出使用方式：先依專案提供的指令建立最小流程，再觀察輸出是否包含所述欄位、狀態或效能訊號。這比只看宣稱的支援清單更能辨識適用範圍。 對 JustVugg/colibri 而言，這一點要連同專案目前的檔案與版本狀態一起核對。
在 JustVugg/colibri 的脈絡中，這個判斷應落到可觀察的細節：依 README 所列的入口執行 colibri，檢查指令回傳、輸出結構與失敗時的訊息，再把結果和預期用途逐項對照。若涉及設定，應保留設定檔名稱與實際版本，因為同一功能在不同平台或依賴組合下可能有不同限制。第 3 節還應獨立記錄輸入大小、執行時間、資源使用與錯誤內容，這些資料能說明 colibri 的實際行為是否符合本節討論。
針對 colibri，第 3 節的判讀不能脫離具體情境。輸入資料先要符合檔案描述，接著確認處理流程是否真的走到預期元件，最後檢查輸出是否保留必要資訊。若結果不符，應從指令列回傳值、日誌、依賴版本和設定內容逐項排查，而不是把差異直接歸因於工具本身。這個順序也能分辨功能缺失、環境差異和使用方式錯誤，讓後續修改有明確依據。
透過端到端量測贏得地位的技術
README 列出了多項技術：基於路由熱度的權重 JIT、批次專家合併、重疊讀取與計算、O_DIRECT、加權雙 SSD 條帶化、跨 CPU、CUDA、Metal、NUMA 的異構執行，以及比未壓縮 MLA 狀態小 57 倍的壓縮 KV 狀態。推測解碼使用模型原生的 MTP 頭，但 README 警告 MTP 頭必須是 int8 而非 int4，因為 int4 頭的接受率會降到 0-4%。預設策略從不靜默改變模型精度或路由器語義。README 強調，所有最佳化在受控的端到端 A/B 測試證明之前都只是假設，一個控制良好的失敗比一個無法解釋的快速數字更有價值。（colibri 第 4 節第 1 段）
若要把它放進現有系統，應特別檢查 README 提到的依賴、權限、平台和版本條件。這些條件不是附帶資訊，而是功能是否可重現的一部分。 對 JustVugg/colibri 而言，這一點要連同專案目前的檔案與版本狀態一起核對。
在 JustVugg/colibri 的脈絡中，這個判斷應落到可觀察的細節：依 README 所列的入口執行 colibri，檢查指令回傳、輸出結構與失敗時的訊息，再把結果和預期用途逐項對照。若涉及設定，應保留設定檔名稱與實際版本，因為同一功能在不同平台或依賴組合下可能有不同限制。第 4 節還應獨立記錄輸入大小、執行時間、資源使用與錯誤內容，這些資料能說明 colibri 的實際行為是否符合本節討論。
針對 colibri，第 4 節的判讀不能脫離具體情境。輸入資料先要符合檔案描述，接著確認處理流程是否真的走到預期元件，最後檢查輸出是否保留必要資訊。若結果不符，應從指令列回傳值、日誌、依賴版本和設定內容逐項排查，而不是把差異直接歸因於工具本身。這個順序也能分辨功能缺失、環境差異和使用方式錯誤，讓後續修改有明確依據。
已量測的結果與仍待驗證的假設
README 報告了特定硬體上的實測解碼速度：6× RTX 5090 全駐留時 5.8-6.8 tok/s，128 GB 純 CPU 桌面約 1.8 tok/s，單張 RTX 5070 Ti 筆電 1.07 tok/s，25 GB 開發機 0.05-0.1 tok/s。這些數據來自基準測試表，README 表示品質透過正確性門控量測。開放假設表列出了六項仍需進行的實驗，例如路由歷史在留出集上的跨 session A/B 測試、冷快取下單碟與雙碟 GLM-5.2 對比，以及硬體感知規劃器的比較。README 邀請貢獻者發布負面結果，並指明了需要記錄的數據。（colibri 第 5 節第 1 段）
從工程取捨來看，這個專案選擇了清楚的資料流或執行路徑，也留下相應成本。團隊需要把成功輸出與失敗輸出都納入測試，避免只驗證最順利的案例。 對 JustVugg/colibri 而言，這一點要連同專案目前的檔案與版本狀態一起核對。
在 JustVugg/colibri 的脈絡中，這個判斷應落到可觀察的細節：依 README 所列的入口執行 colibri，檢查指令回傳、輸出結構與失敗時的訊息，再把結果和預期用途逐項對照。若涉及設定，應保留設定檔名稱與實際版本，因為同一功能在不同平台或依賴組合下可能有不同限制。第 5 節還應獨立記錄輸入大小、執行時間、資源使用與錯誤內容，這些資料能說明 colibri 的實際行為是否符合本節討論。
針對 colibri，第 5 節的判讀不能脫離具體情境。輸入資料先要符合檔案描述，接著確認處理流程是否真的走到預期元件，最後檢查輸出是否保留必要資訊。若結果不符，應從指令列回傳值、日誌、依賴版本和設定內容逐項排查，而不是把差異直接歸因於工具本身。這個順序也能分辨功能缺失、環境差異和使用方式錯誤，讓後續修改有明確依據。
快速開始與原始碼未說明的部分
README 指出需要程式（幾百 KB）和模型（GLM-5.2 int4 容器約 372 GB）。預編譯版本支援 Linux、macOS 和 Windows，啟動器需要 Python 3，但引擎本身是純 C。從原始碼建置需要 gcc 或 clang 及 OpenMP。模型在 Hugging Face 上，README 提醒使用 gs64 建置並搭配 int8 MTP 頭。指令列包括 `coli chat`、`coli serve`、`coli web` 以及 `coli plan`、`coli doctor`、`coli tune` 等診斷指令。README 沒有給出所有平台的完整指令語法，也沒有列出全部環境變數，但指向 docs/ENVIRONMENT.md。授權為 Apache 2.0，README 還註明 GLM-5.2 權重由 Z.ai 以 MIT 協議發布。（colibri 第 6 節第 1 段）
實際評估時，可使用專案自己的名稱、指令或檔案路徑建立一個小型案例，記下輸入、輸出和錯誤訊息，再決定是否擴大使用。這樣才能把 README 的敘述對應到自己的環境。 對 JustVugg/colibri 而言，這一點要連同專案目前的檔案與版本狀態一起核對。
在 JustVugg/colibri 的脈絡中，這個判斷應落到可觀察的細節：依 README 所列的入口執行 colibri，檢查指令回傳、輸出結構與失敗時的訊息，再把結果和預期用途逐項對照。若涉及設定，應保留設定檔名稱與實際版本，因為同一功能在不同平台或依賴組合下可能有不同限制。第 6 節還應獨立記錄輸入大小、執行時間、資源使用與錯誤內容，這些資料能說明 colibri 的實際行為是否符合本節討論。
針對 colibri，第 6 節的判讀不能脫離具體情境。輸入資料先要符合檔案描述，接著確認處理流程是否真的走到預期元件，最後檢查輸出是否保留必要資訊。若結果不符，應從指令列回傳值、日誌、依賴版本和設定內容逐項排查，而不是把差異直接歸因於工具本身。這個順序也能分辨功能缺失、環境差異和使用方式錯誤，讓後續修改有明確依據。
編輯結論
colibri 的核心是把專家權重當作待分階段載入的資料而非駐留狀態，並且每一項最佳化都透過端到端量測來驗證。原始碼尚未給出完整的環境變數清單，也未涵蓋所有平台的正確行為，但檔案中提供了相應說明。 適合能依 colibri 檔案設定環境並檢查實際輸出的團隊；不適合只需要即插即用成品、卻無法配合其依賴條件的情境。採用前先用 README 的最小指令或範例驗證核心輸入、輸出與錯誤行為。
社群筆記