Kolibri 只啟用 3.46B 參數，為什麼模型仍要約 78 GB？

看到「每次只啟用 3.46B 參數」，很容易以為 Kolibri 是一個輕巧的小模型。但翻到部署規格，官方又寫著約 78 GB。兩個數字都對，回答的卻是不同問題：每一步要算多少，以及整套權重要放在哪裡。

3.46B 是這一步動用的參數

Aleph Alpha 在 2026 年 10 月 3 日推出 Kolibri，主打德文與英文。它採用 MoE（混合專家）架構：模型內有多組參數，處理每個 token，也就是文字切成的小單位時，由路由機制挑選部分專家參與計算。總參數約 78.1B（781 億），每個 token 啟用約 3.46B（34.6 億）。官方發布說明

可以把它想成一間有很多專業書的工作室。每次解題只翻其中幾本，工作量會減少；書架卻還得容納整套書。下一個問題可能需要另一本，不能因為這一步沒翻到，就把其餘書架從容量估算中刪掉。

這個比喻也有界線：少啟用參數，不保證回覆速度等同同樣參數量的小模型。資料搬移、硬體與推論軟體都會影響等待時間。拿 3.46B 當成速度保證，或拿它直接估計下載大小，都跳過了部署條件。

約 78 GB 是 FP8 權重，不是整台機器的需求

官方模型卡將約 78 GB 明確標為 FP8 權重的記憶體占用。FP8 是用較低精度儲存數值的格式；權重則是模型訓練後留下的參數。權重採 Apache 2.0 授權。

這個數字不能解讀成「有 78 GB RAM 或顯存就一定能跑」。 顯存是 GPU 使用的記憶體；一般 RAM 與顯存也不能不看部署方式就直接相加。完整服務還有推論運算的暫存、軟體開銷，以及對話的 KV cache。

KV cache 可以理解為模型讀過前文後留下的計算筆記，避免每產生一小段文字都重算。Hugging Face 文件指出，快取可能占用大量記憶體，長上下文尤其需要考慮；把快取移到 CPU 可省顯存，但搬移本身有成本。不同注意力與快取策略的增長方式也不同，不能只用文章字數推算。快取策略文件

若改用其他量化版本，權重大小可能改變，因此 78 GB 也不是所有版本的固定門檻。要比較的是你準備下載的那個檔案、推論引擎是否支援，以及該配置的輸出品質。這裡沒有實測其他量化版本，不能給出它們的最低硬體保證。

百萬上下文，先別當成日常設定

Kolibri 原生上下文為 262,144 tokens；廠商表示已驗證延伸至 1,048,576 tokens，但對複雜任務及重視延遲、吞吐量的服務，仍建議使用不超過 262,144 tokens。這些是廠商模型卡的能力與建議，並非本文完成的獨立測試。上下文說明

對想做文件問答的團隊，最長能塞多少資料，和讀完後能否找對條款，是兩個驗收項目。假設只是查一份文件中的付款期限，先放相關段落就能測基本能力；接著才逐步加入無關附件，觀察答案是否開始混用日期、漏掉例外，或找不到依據。不要第一天就把最大上下文設滿，然後把變慢或出錯全部歸因於模型。

用同一份工作，檢查四筆帳

我會把 Kolibri 放進「需要自架、且以德英語工作為主」的候選清單。對主要處理繁中的團隊，先做自己的語言測試更重要；目前這些資料不足以把它推薦為中文模型的直接替代品。

初步選型可以從一份去識別化的真實工作開始，例如從供應商文件找出交期、付款條件及違約例外。先由人寫好正確答案及對應原文，再按以下順序記錄：

1. 權重帳。 寫下完整模型名稱、版本、精度、檔案大小和使用的推論引擎。載入後量測實際 RAM／顯存占用，保留運行空間。不要拿某個量化版的容量，配上另一版本的品質分數。
2. 上下文帳。 從平常會用的文件長度開始，同時限定回答長度。再測較長文件，以及預計同時使用的人數，記錄記憶體峰值、開始回覆前的等待時間和整體完成時間。這是待執行的測試方法，本文沒有量測結果。
3. 品質帳。 逐項核對答案是否有原文支持；刻意保留一題文件沒寫的問題，看看模型是否承認找不到。若工作包含繁中，就直接用繁中資料驗收，不能用德文成績代替。
4. 成本帳。 把租用或購置硬體、維運工時、失敗後重跑及人工覆核一起計入，再除以通過驗收的工作數。省下權重授權費，仍可能增加部署和校對支出。

這樣比較，就能看見選項的取捨：某個配置雖能載入，卻可能在多人使用時等太久；另一個回答快，但漏掉例外條款，需要更多人力檢查。這些差異比單看啟用參數量，更接近一個團隊最後會付出的代價。

可自行部署，仍要算得過來

Hacker News 討論呈現兩種關心：有人重視訓練說明與自行部署的選擇，也有人質疑硬體門檻。這些留言反映使用者的優先順序，不能當作效能測試。

我的判斷是，Kolibri 的價值應放在「多了一個可評估、可自行掌握部署的選項」，而不是看到小啟用參數就預設它適合每台個人電腦。先驗收自己那份工作，再決定要不要為它準備硬體。

若工作本來就只是把文件分到有限的類別，也可參考 AIng 的 Clef 分類教學，先確定是否需要長篇生成模型。該文提供流程示範，並非 Kolibri 的性能比較。

查核日期：2026 年 10 月 4 日。本文依官方文件分析，未執行 Kolibri 推論、繁中能力或部署效能實測。

封面：Hugovanmeijeren，〈Cern datacenter.jpg〉，2010 年 CERN 資料中心實景，採 CC BY-SA 3.0 授權。使用 Wikimedia 縮圖，網站轉為 WebP 並移除中繼資料；列表可能置中裁切，照片及其衍生版本沿用相同授權。僅為機房示意，非 Kolibri 部署照片，無作者或 CERN 背書。