【2026 最新】Colibrì 744B 怎麼驗收？429GB 下載決策 6 關檢查

一台只有 24GB 或 32GB RAM 的電腦，真的能跑 744B 模型？Colibrì 744B 的答案是「能執行」，但這四個字很容易被誤讀成「模型放進記憶體、速度可互動、品質等同官方服務」。截至 2026 年 9 月，官方推薦的 GLM-5.2 Colibrì 容器在 Hugging Face 實際列為 429.276GB；專案 dev-box 的 cold 自報基線則只有約 0.05～0.1 tok/s。下載前，先別問能不能啟動，要問你是否願意等。

這篇不假裝 AlphaLab 已下載 429GB 模型跑過；本文用固定版本的官方程式、目前容器檔案清單、專案測量協議與可追溯的社群紀錄，教你做一套可重跑的六關驗收。最後你會得到明確的繼續／停止門檻，也會知道何時改用較小的 GGUF 模型或雲端 API 更合理。

先說結論：Colibrì 744B 能跑，不等於值得跑

• 容量先改成 429.276GB：目前推薦 revision 的 142 個 safetensors 與其他檔案合計 429,276,220,139 bytes，約 399.795GiB；現有 Quickstart 的約 372GB 已不足以規劃這一版磁碟。
• 24GB 的公開紀錄是技術展示，不是速度保證：2026 年 7 月一筆舊版 per-row 容器的 24GB WSL2 社群紀錄約 0.07 tok/s；生成 100 tokens 依速率換算約要 24 分鐘。
• 快 SSD 只是必要條件之一：Colibrì 讀的是隨機位置、約 expert 大小的大區塊；廣告上的循序讀取與 4KB IOPS 都不能單獨預測 tok/s。
• 暖機必須拆開記：頁面快取、RAM expert cache、VRAM 常駐、.coli_usage 與 KV/prefix cache 是不同東西；只重跑相同 prompt 會高估新任務速度。
• 先設定停損：若你的重點是日常聊天、程式輔助或批次工作，先以同一組任務對照小模型與 API；只有隱私、離線、研究或已有硬體等收益勝過等待時間，才值得保留 429GB 容器。

Colibrì 744B 是什麼？先記住一條可用性公式

可用性 ＝ 放得下 × 讀得動 × 等得起 × 答得對。

Colibrì 是一套讓超大型稀疏 MoE（Mixture of Experts，混合專家）模型分層存放的推論引擎。GLM-5.2 的專案標示為 744B 總參數、每個 token 約啟用 40B；Colibrì 把約 9.9GB 的 dense 核心常駐記憶體，把大部分 routed experts 留在 NVMe。在本文的單機 faithful routing 路徑中，引擎直接計算 RAM／VRAM 命中的 experts，並從磁碟補入未命中區塊；開啟 speculation 或 prefetch 時，也可能預先讀取額外 experts。

把它想成「倉庫型餐廳」：櫃台與廚房在 RAM，數百位專家食材放在 NVMe 倉庫。點單後只取這一餐需要的食材，所以不必把整座倉庫塞進廚房；但每道菜都得反覆叫貨，磁碟延遲自然進入每個 token 的時間。這與一般 LLM 推論引擎把多數權重常駐 RAM／VRAM 的路徑不同，也和DRIFT-LLM 用多台機器接力模型層不同：Colibrì 的主角是同一台主機上的分層快取與磁碟串流。

下載決策六關：任何一關紅燈就先停

六關不是六個跑分，而是一條順序。第一、二關不必下載權重；確認來源、容量、環境與 I/O 初篩都值得繼續後，才下載 pinned 容器，第三關開始做模型相依檢查。每關都把輸出存成文字或 JSON，日後換 SSD、RAM、版本或旗標時才有可比較的基線。

第 1 關：容器身分與空間——你要下載的真是那一包嗎？

痛點：「GLM-5.2 int4」不足以辨識檔案，不同量化、MTP head 與 mirror 會有不同尺寸與相容條件。解法：固定 repo、完整 revision、格式與檔案數。本文驗收的是 mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp，Hugging Face revision 6bbb01ed3e515a8730b694dfae73aadfd6774581；頁面在 2026 年 9 月 14 日列為 429.276GB、142 個 safetensors。

curl -fsS 'https://huggingface.co/api/models/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp/revision/6bbb01ed3e515a8730b694dfae73aadfd6774581?blobs=true' \
  | jq '{sha, lastModified,
         bytes: ([.siblings[].size // 0] | add),
         tensors: ([.siblings[] | select(.rfilename | endswith(".safetensors"))] | length)}'

預期關鍵值是 bytes: 429276220139 與 tensors: 142。接著對預定資料夾跑 df -h /你的/NVMe/路徑；注意 429.276GB 十進位約為 399.795GiB，而 df -h 常顯示二進位單位。不要只留剛好容器大小：下載暫存、檔案系統保留空間、編譯產物與後續快取都要空間。若剩餘容量連完整容器加作業餘裕都容不下，直接停；不要靠 swap 假裝多出磁碟與 RAM。

第 2 關：執行環境——先固定版本，再讓 doctor 說話

痛點：主分支會更新，今天的指令與日後的二進位不一定是同一份。解法：先以最新非 prerelease GitHub release v1.11.0 建立可重現環境；pyproject.toml 明列 Python 3.10 以上，專案 metadata 仍標為 Beta。Linux／WSL2 可照官方路徑執行，其他平台則改走專案對應文件。不要把不明來源的預編譯檔與模型 mirror 混進同一輪驗收。

python3 --version  # 需要 3.10+
git clone --branch v1.11.0 --depth 1 \
  https://github.com/JustVugg/colibri.git /path/to/colibri
cd /path/to/colibri/c
./setup.sh
./coli --version

所有指令中的 /path/to/colibri 與 /nvme/glm52_i4 都是佔位路徑，先換成你實際的程式與模型目錄；後續每段都從完整路徑開始，避免終端機工作目錄不同而跑錯。

這一步先確認 Python、編譯器與引擎版本；doctor 與 plan 都需要模型目錄，不能在權重下載前假裝完成模型相依驗收。完整權重到位後，再執行 COLI_MODEL=/nvme/glm52_i4 ./coli doctor --deep；依 v1.11.0 launcher，deep 模式會檢查每個 safetensors layout、核心 tensors、分片完整性、model index 與 mirror admission。它不是整包 payload 的密碼學雜湊，也不載入推論引擎，所以綠燈只代表「結構通過載入前檢查」，不代表「答案可靠」。

只有初篩過線、並確定要繼續，才執行 pinned 下載；以下命令需要約 429.276GB 傳輸與足夠作業空間：

python3 -m pip install --upgrade huggingface_hub
hf download mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp \
  --revision 6bbb01ed3e515a8730b694dfae73aadfd6774581 \
  --local-dir /nvme/glm52_i4

第 3 關：RAM／VRAM 計畫——看三層，不只看總容量

痛點：24GB、64GB、128GB 只說明硬體上限，沒有告訴你多少 experts 在 VRAM、RAM 或磁碟。解法：完成模型後輸出 planner 結果，保留 hot／warm／cold 三層配置與作業系統餘裕。

cd /path/to/colibri/c
COLI_MODEL=/nvme/glm52_i4 ./coli plan --json | tee plan.json

官方 --ram 0 自動策略會依可用記憶體規劃，不必一開始就手動塞滿。你的停止條件應寫成：「引擎啟動後，系統仍不持續 swap、不把桌面或其他服務擠到失去回應，且 cold backing 符合我願意承受的延遲。」2026 年 7 月舊版 per-row 容器的 24GB WSL2 紀錄約 3～4% expert hit；相反地，部分 128GB 配置可接近或超過 1 tok/s，但硬體、後端、旗標與快取狀態不同，不能把數字直接套到你的主機。

第 4 關：NVMe——測 expert 大區塊，不看包裝盒

痛點：SSD 標示的「最高 7GB/s」多半是理想循序讀取；Colibrì 卻反覆從不同 offset 取約 expert 大小的區塊。解法：照官方 benchmark 協議測 19MB 隨機區塊，Linux 再比較 buffered 與 O_DIRECT。

cd /path/to/colibri/c
gcc -O2 -fopenmp iobench.c -o iobench
./iobench /nvme/glm52_i4/out-00069.safetensors 19 64 8 0
./iobench /nvme/glm52_i4/out-00069.safetensors 19 64 8 1

最後一個參數 1 是繞過 page cache 的 O_DIRECT。macOS 以 F_NOCACHE 近似，但不能驅逐先前已進入快取的頁面；因此不要先跑 buffered 再把下一個數字叫「cold」，應重開機或換一個未讀過的 shard。更重要的是，磁碟跑分只是一道門：一筆 i5-13600K、62GB RAM、RTX 5070 Ti、Samsung 980 Pro 的社群紀錄中，19MB O_DIRECT 約 5.9GB/s；首個僅 32-token run 為 0.46 tok/s，較長 untuned run 為 0.56，後續 tuned 為 0.98、peak 1.07。CPU、記憶體頻寬、命中率與資料搬移還會接手成為瓶頸。

第 5 關：冷、暖與 TTFT——用三種 prompt 拆穿漂亮數字

痛點：同一句 prompt 第二次可能因 page、expert 或 prefix cache 變快，也可能幾乎不變；無論哪種結果，都不能代表新問題。解法：把測量拆成 eviction-confirmed cold、完全相同的暖請求，以及四個輪替 prompt；只有 log 確認 eviction 成功才把第一項標成 cold，主要決策看輪替中位數。官方工具可在同一個 SERVE process 內完成：

cd /path/to/colibri/c
python3 tools/datapoint.py \
  --snap /nvme/glm52_i4 \
  --shard /nvme/glm52_i4/out-00000.safetensors

python3 -m pip install tokenizers datasets
COLI_MODEL=/nvme/glm52_i4 ./coli bench

每輪至少記錄版本／commit、prompt tokens、輸出 tokens、載入時間、TTFT（第一個 token 等多久）、decode tok/s、整體 wall time、磁碟 GB/s、expert hit、RSS、後端與旗標。也要註明是新程序、同程序、相同 prompt、輪替 prompt，以及 .coli_usage 如何處理；datapoint 不會自動把它清空。專案一份受控實驗中，同一配置在被單一重複 prompt 專門化的 .coli_usage 下量到 5.46 tok/s；改成每個 configuration 前都 byte-for-byte 還原固定 mixed-use profile、固定 warmup 後只量到 2.78 tok/s，作者因而撤回 5.46 作為可重現數字。

把速度翻成等待時間更直覺：0.05 tok/s 生成 100 tokens 約 33 分 20 秒；0.1 tok/s 約 16 分 40 秒；0.3 tok/s 約 5 分 33 秒；1 tok/s 仍約 1 分 40 秒。這些是單純除法，不含載入與 TTFT。若你的任務需要來回對話，請先寫下能接受的 100-token 完成時間，例如 120 秒；輪替中位數超標就停。

第 6 關：答案與替代方案——同一份考卷才公平

痛點：token-exact 測試能證明引擎符合某個量化參考，不能證明 gs64 int4 與官方 FP8／BF16 在所有任務等質。v1.11.0 bench 的預設協議是 HellaSwag、ARC Challenge、MMLU 各 40 題 0-shot；這只描述預設小樣本。早期 n=40 分數曾受 prompt prefix 缺漏影響，後續雖有 HellaSwag n=200 與 grouped／per-row 比較，也不是目前 gs64 對官方 FP8／BF16 的同條件三任務 A/B。解法：準備三類你真的會做、且有判分規則的題目，例如「依規格產生可執行程式」「從長文件抽取 12 個欄位」「遵循格式限制完成分析」。每題固定 prompt、輸出上限與成功條件，分別跑 Colibrì、小型本機 GGUF 與 GLM-5.2 API。

小模型基線可用 llama.cpp 官方 llama-bench：./llama-bench -m /path/to/model.gguf -p 0 -n 128 -r 5 -o json。它不含 tokenization 與 sampling，故仍要另記同一題的端到端 wall time。量化怎麼挑，可先讀GGUF Q4／Q6／Q8 與品質懸崖指南；若你正在考慮添購主機，再把結果帶進本機 LLM、租 GPU 與 API 成本損益表。

雲端成本也要以同一輸入／輸出量計算。截至 2026 年 9 月 14 日，Z.ai 官方價目列 GLM-5.2 每百萬 input／cached input／output tokens 分別為 US$1.40／0.26／4.40；2,000 個非快取 input 加 1,000 output 依表計算約 US$0.0072，不含額外工具費。API 與 Colibrì 量化容器也不應假設為 bit-identical。

一套可直接照做的 60 分鐘預檢流程

1. 前 10 分鐘：查 Hugging Face API 的 revision、bytes、檔案數，並確認最新非 prerelease GitHub release。容量或來源不符就停止。
2. 第 10～25 分鐘：clone 固定 release、建置引擎與 iobench，確認 Python、編譯器與引擎版本，記錄 CPU、RAM／VRAM 與檔案系統資訊。
3. 第 25～40 分鐘：用目標磁碟上的足夠大、非 sparse 既有檔案跑 iobench 初篩；若只能看 buffered 就清楚標記，下載後再用實際 shard 複驗。
4. 第 40～50 分鐘：先用既有小模型完成同一組三題，取得可互動的時間與品質底線；可參考MoE offload／hybrid／llama.cpp 路徑比較。
5. 最後 10 分鐘：用目前 API 價格估算一個月相同工作量，寫下你的硬門檻：可用空間、最大 TTFT、100-token 完成時間、一次成功率，以及願意付出的 API 金額。

預檢不是在 60 分鐘內跑完 744B，而是在下載前排除明顯不合格的主機。真正下載後，再跑 doctor --deep、plan --json、datapoint 與品質 A/B。若你只是想學本機模型，不必用最大模型當入場券；從能在現有硬體流暢運作的 GGUF 開始，學到的量測方法完全相同。

若你希望先把 AI 工具與工作流的基本功補齊，再回來做效能工程，也可從 AlphaLab 的線上課程選一條較短的學習路徑。

常見坑：最容易把數字看錯的五件事

• 把下載成功當驗收成功：429GB 只證明檔案落地，後面還有 layout、記憶體、I/O、延遲與品質。
• 把 buffered GB/s 當實體磁碟：大 RAM 主機可能只是在讀 page cache；保留 O_DIRECT／F_NOCACHE 的限制註記。
• 把 identical warm 當日常工作：相同 prompt、已學習的 expert 排序與 prefix cache 都會讓結果變漂亮；主判斷看 rotating prompts。
• 只看 tok/s：短問答最在意 TTFT，長生成才更在意穩態 decode；兩者加上完整 wall time 才是使用者等待。
• 以為 GPU 一定救得了 I/O：若 experts 餵不進來，GPU 會等資料；先看 profile 中的 disk、matmul、attention 與 transfer，再決定升級哪個零件。

FAQ：Colibrì 744B 新手最常問的 8 題

1. 24GB RAM 真的能跑 GLM-5.2 744B 嗎？

官方宣稱的低記憶體路徑可進入推論流程，但公開數字要綁定版本。2026 年 7 月一筆舊版 per-row 容器的 24GB WSL2 社群紀錄約 0.07 tok/s、RSS 14.1GB、expert hit 3～4%；它證明低記憶體串流可執行，不能當成目前 429GB gs64 容器的速度保證。

2. 到底要預留 372GB、380GB，還是 429GB？

若下載本文指定的目前容器，就按 429GB 檔案清單規劃。372GB 是現有 Quickstart 的近似舊數字；不同容器、格式與 revision 可以不同，所以每次都以 HF API 的 exact bytes 為準，另留下載與系統餘裕。

3. 有 RTX 4090／5090 就一定比較快嗎？

不一定，先看瓶頸在哪。小 RAM 讓大量 experts 留在磁碟時，GPU 可能等 I/O 或資料搬移；只有 profile 顯示 compute 是主牆，升 GPU 才較可能直接改善。

4. SSD 循序讀取 7GB/s 夠不夠？

那個規格不能單獨回答。請跑 19MB、隨機 offset、適當 queue depth 的 iobench，Linux 優先看 O_DIRECT，再用端到端 datapoint 確認 tok/s。

5. doctor --deep 通過就安全嗎？

它是模型結構與載入前檢查，不是完整信任證明。你仍要固定來源與 revision，保留取得路徑；deep 也不替代惡意程式風險評估、payload hash 或答案品質測試。

6. warm tok/s 可以拿來估每天工作速度嗎？

只有工作分布相似時才有參考性。請另外看 rotating-prompt median，並記錄頁面快取、expert cache、usage history 與 prefix cache；完全相同 prompt 的 warm 數字只當上界。

7. gs64 int4 代表品質和原模型一樣嗎？

不能從格式名稱推出等質。截至 2026 年 9 月 14 日，v1.11.0 benchmark 頁把三任務、各 40 題列為預設小樣本協議；另有修正後 HellaSwag n=200 與量化格式比較，但頁面沒有給出目前 gs64 對官方 FP8／BF16 的同條件完整三任務 A/B。請用你的真實任務、盲評與硬性成功條件判斷。

8. 哪些人最適合繼續下載？

需要離線、資料主權、引擎研究，且已擁有足夠磁碟與耐心的人。若目標是快速完成日常任務，先比較小型本機模型與 API；不必因為 744B 數字較大，就把它當成預設答案。

給新手的 6 個重點

1. 先查容器 revision 與 exact bytes；本文指定版本是 429GB，不是 372GB。
2. 把 24GB 看成「經公開量測的小記憶體案例」，別自動翻譯成目前容器的互動速度。
3. 用 expert-sized O_DIRECT 測試 NVMe，再用端到端 tok/s 驗證。
4. 分開記 TTFT、decode、wall time，以及每一層 cache 狀態。
5. 品質門檻用你自己的真實任務；token-exact 不等於高精度模型全面等質。
6. 最終只問公式：放得下、讀得動、等得起、答得對，四項是否同時成立？