Kolibri 是什麼?Aleph Alpha 開放 78B 模型,百萬 Token 與本機部署限制一次看
Aleph Alpha 開放 Kolibri 權重:78B 總參數、3.46B 啟用參數,支援百萬 Token。解析德英語定位、官方評測、Apache 2.0 授權與本機部署所需硬體。
Kolibri 是德國 AI 公司 Aleph Alpha 在 2026 年 10 月 3 日推出的語言模型,主打德文與英文工作,並開放模型權重,也就是訓練後決定模型如何處理輸入的數值檔案。企業可以下載這些檔案,在自己管理的設備上運行模型。
這次發布值得關注,因為它把長文件處理、可調整的推理能力與自主部署放在同一個產品裡。對需要處理內部資料的團隊,模型能放在哪裡、能否接上既有系統,會直接影響導入方式。
但貼文上的「78B 總參數、3.46B 啟用參數、百萬 token」需要分開理解。B 代表十億,token 是模型拆解文字後使用的處理單位,可能是一段字詞或符號,不能直接換算成中文字數。低啟用參數也不代表只需存放一個小模型。
本文會說清楚 Kolibri 的用途、規格對成本的影響、官方評測能支持哪些判斷,以及有設備的開發團隊如何開始部署。我的判斷是:它值得有德英語文件需求、也有伺服器維運能力的團隊試用。以繁體中文為主要工作語言的一般使用者,則應先做自己的任務測試。
Kolibri 的定位:讓德英語文件工作能在自己的系統裡完成
Kolibri 的核心用途是文字工作。依 Aleph Alpha 官方產品頁,它面向需要多步推理、文件資訊擷取與工具使用的助手及工作流程。「推理」在這裡指模型投入額外計算來處理需要分步解決的問題,例如從數份文件整理出一致的答案。
如果團隊要整理德文技術文件,再用英文向其他部門說明結果,這種語言定位就有實際意義。這是本文用來說明用途的假設情境,並非官方公布的客戶案例。模型是否能完成工作,仍要看文件內容、專業詞彙與驗收標準。
自行部署也讓企業可以選擇資料處理的位置。團隊能把模型接到自己的文件系統,並設計誰能查閱哪些內容。這些安排需要由部署者完成,下載權重本身不會自動建立完整的資料管理機制。
對台灣讀者,語言範圍是第一個篩選條件。官方以德文和英文為主要支援語言,這次發布沒有提供足以判斷繁體中文表現的完整證據。因此,中文合約摘要、台灣公文理解或在地客服,都應納入獨立測試,而不能從德英語成績直接推導。
78B 與 3.46B 的差異:計算量降低,完整權重仍要存放
Kolibri 使用混合專家架構(Mixture-of-Experts,MoE),將部分運算交給多組專家網路,每次處理文字時只選用其中一部分。因此,總參數描述整個模型的規模,啟用參數描述每個 token 實際動用的規模。
可以把它想成一個有許多專業小組的組織,每項任務只調動部分成員,但所有小組都必須有地方待命。這個比喻只用來解釋計算與存放的差異,專家網路並不等於人類職務分類。
依 官方模型卡,Kolibri 約有 781 億總參數,每個 token 啟用約 34.6 億參數。下載版 FP8 權重的模型記憶體占用約 78 GB。FP8 是以較少位元表示數值的格式,可降低儲存與運算負擔。
官方列出的最低硬體配置包括兩張 A100 80 GB、兩張 H100 SXM5,或單張 H200、B200、B300 等資料中心 GPU,也就是用來大量平行運算的圖形處理器。這些配置顯示,「在自己的硬體執行」主要對應有大型設備的團隊。
| 容易混淆的數字 | 它回答的問題 | 部署時的意義 |
|---|---|---|
| 約 78B 總參數 | 完整模型有多大? | 要存放所有權重 |
| 約 3.46B 啟用參數 | 每個 token 動用多少參數? | 有助於降低每次運算負擔 |
| FP8 權重約 78 GB | 模型本身占多少記憶體? | 還需評估上下文與執行時的額外空間 |
因此,選設備時應先確認完整權重能否載入,再測實際文件長度與同時使用人數。只拿啟用參數去估算記憶體,會低估部署需求。能載入模型與能穩定服務多位使用者,也要分別驗收。
延伸閱讀:Kimi K3 開放權重下載:2.8 兆參數、100 萬 Token,真的能在本機執行嗎?
百萬 Token 是容量上限,工作長度要按任務選擇
長上下文讓模型能在一次處理中參考較多內容。「上下文」包含使用者提供的文件、對話及其他輸入資料,長度增加有助於保留跨段落線索,但也會增加處理負擔。
Kolibri 支援的上限是 1,048,576 tokens。官方建議對服務效率敏感或較複雜的任務,使用不超過 262,144 tokens 的上下文。部署團隊應把這個建議納入設定,而不必從第一天就把每次請求推到上限。
依 Kolibri 技術報告,模型結合局部與全域注意力。注意力是模型判斷哪些文字彼此相關的機制,局部注意力集中處理鄰近內容,全域注意力則能參考整段上下文。這種設計用來降低長文件處理的負擔。
容量足夠仍需要檢查答案品質。以跨文件比對為例,團隊可以把相互矛盾的條款放在不同位置,測試模型是否找得到、能否引用正確段落,以及文件變長後是否遺漏重要資訊。這些結果比單一最大長度更接近實際需求。
若系統每次都加入大量無關文件,模型也會花資源處理它們。先選出相關內容,再讓模型回答,往往是值得比較的另一種流程。長上下文與文件搜尋可以搭配使用,團隊應用同一組問題測試速度、成本和正確性。
官方評測有亮點,選型仍要看自己的任務
Aleph Alpha 公布的結果顯示,Kolibri 具備值得測試的推理與工具使用能力。下表摘錄 官方發布文章 的成績,全部是開發者公布的評測,並非本文實測。
| 評測項目 | Kolibri | 測試內容 |
|---|---|---|
| AIME 2026 | 96.0 | 數學競賽題解題能力 |
| LiveCodeBench v6 | 85.9 | 程式解題能力 |
| BFCL v4 overall | 61.4 | 選擇與呼叫工具的能力 |
| LongBench Pro | 64.5 | 長上下文任務能力 |
同一份比較裡,Kolibri 的數學與程式成績有競爭力,但 Qwen3.6-35B-A3B 在 BFCL v4 和 LongBench Pro 的分數較高。這支持把 Kolibri 放進候選名單,也顯示不同任務會得到不同排序。
數學題的高分無法直接回答客服系統是否能正確查詢訂單,工具呼叫成績也無法保證每個內部工具都能順利使用。實際部署還會受到提示內容、工具說明、文件品質與系統設定影響。
我會優先測三類題目:日常工作中最常出現的問題、容易答錯但影響大的問題,以及文件沒有答案的問題。第一類看效率,第二類看可靠性,第三類看模型是否會把缺少資訊的地方補成看似合理的答案。
這樣的驗收能讓選型回到具體結果。例如,同一份測試資料分別交給現有系統與 Kolibri,記錄正確率、處理時間及人工修改量。若更換模型後節省的時間不足以抵銷維運負擔,單靠公開評測的亮點就不足以支持轉換。
開放權重與 Apache 2.0:能取得模型,仍要看授權範圍
Kolibri 權重與儲存庫內的設定檔採用 Apache 2.0 授權。依 Apache 官方條款,這類授權允許在符合條款的情況下使用、修改與散布作品,並沒有把用途限制為非商業研究。
散布時仍有附上授權、保留適用聲明及標示修改等要求。官方模型卡也明確限制授權範圍,儲存庫以外的其他素材不能一併視為獲得相同授權。模型發布頁的圖片、品牌與影片,需要各自看其使用條件。
對團隊而言,開放權重提供了自行部署與調整的選擇。這也意味著團隊需要負責版本管理、設備、更新與服務品質。下載不等於取得一套已完成維運的服務,評估預算時應把這些工作算進去。
有合適硬體的團隊,如何開始部署 Kolibri
官方提供 aleph-alpha-inference 套件,讓 vLLM 支援 Kolibri。vLLM 是用來載入模型並提供推論服務的軟體,推論就是模型接收輸入並產生回答的過程。依 官方 GitHub 儲存庫,2026 年 10 月 5 日查詢時,套件支援 vLLM 0.29。
在具備合適 GPU 與執行環境的伺服器上,官方安裝及啟動方式如下。這段是官方部署範例,本文沒有在上述硬體上實際運行。
pip install aleph-alpha-inference
vllm serve Aleph-Alpha/Kolibri-1 \
--kv-cache-dtype fp8 \
--reasoning-parser kolibri1 \
--tool-call-parser kolibri1 \
--enable-auto-tool-choice
這些選項讓服務能解析推理內容與工具呼叫。工具呼叫指模型提出要使用哪個外部功能,以及所需的輸入參數,後續仍需由應用程式執行工具並處理結果。
Kolibri 可調整推理投入程度,包含關閉、低、中、高四種設定。團隊可以先用簡單文件擷取題建立基準,再比較較高推理程度是否改善複雜問題。驗收應同時記錄答案品質與回應時間,避免只看其中一項。
接上文件或工具之前,先讓服務完成固定測試題,有助於區分模型問題與系統整合問題。之後再逐項加入文件搜尋、權限控制與外部工具,便能看出是哪個環節影響結果。
Kolibri 常見問題
Kolibri 免費嗎?
權重可以下載,使用與散布需遵守 Apache 2.0 及適用條件。自行運行仍有硬體、電力與維運成本,模型可取得與服務免費是兩件不同的事。
一般筆電適合部署嗎?
官方列出的配置以資料中心 GPU 為主。本文建議依這些配置規劃測試環境,其他部署方式則需要另外驗證,不能只從 3.46B 啟用參數判斷。
Kolibri 適合繁體中文工作嗎?
它的主要語言定位是德文與英文。以繁體中文為核心的團隊,應先建立自己的測試題,再決定是否導入,尤其要涵蓋在地詞彙與文件格式。
可以把所有文件一次交給模型嗎?
長上下文提供較大的輸入空間,但仍受設備、處理時間與任務品質影響。先測相關文件的選取方式與引用正確性,再擴大長度,會更容易找出合適設定。
哪些團隊值得把 Kolibri 放進候選名單
Kolibri 最有吸引力的使用情境,是德英語文件工作加上自主部署需求。已有伺服器與維運團隊的組織,可以從一個明確任務開始,比較答案品質、速度與維護成本,再決定是否擴大使用。
對以繁體中文為主、尚未準備大型設備的團隊,我會先保留現有工作流程,將 Kolibri 視為研究與評估對象。能改變這個判斷的證據,是它在團隊自己的中文題目中表現穩定,而且整體成本符合預算。
準備測試的開發者,可以從 Kolibri 官方下載頁 與 官方部署套件 開始。先完成一組可比較的驗收題,才有足夠依據決定它是否適合進入日常工作。
資料來源
- Aleph Alpha:Kolibri 官方產品頁
- Aleph Alpha:Kolibri Has Landed 官方發布文章
- Aleph Alpha:Kolibri 技術報告
- Aleph Alpha:Kolibri-1 官方模型卡
- Aleph Alpha:aleph-alpha-inference 官方儲存庫
- Apache Software Foundation:Apache License 2.0
產品資料查詢日期:2026 年 10 月 5 日。