作者： Kolibri-1 自行託管需要多少硬體與費用？
Kolibri-1 採 Apache 2.0 授權，但約需 78 GB FP8 權重，官方建議 1 張 H200 或 2 張 80 GB H100。本文解析歐元成本，以及何時選小型模型更合適。
Kolibri-1 自行託管：簡短答案
Kolibri-1 可以自行託管，但無法在一般 VPS 上執行。來自海德堡的 Aleph Alpha 以 Apache 2.0 授權發布此模型。FP8 格式的模型權重約為 78 GB。官方方式是在至少 1 張 H200，或 2 張各具備 80 GB 記憶體的顯示卡上使用 vLLM。目前沒有 CPU、GGUF、llama.cpp 或 Ollama 的官方方式。
對德國的許多讀者而言，最重要的問題是：資料是否能留在自己的場所？使用 Kolibri-1 可以做到，而且授權不會妨礙這件事。真正的門檻是硬體。
資料狀態：本文內容均以 Aleph-Alpha/Kolibri-1 的 Model Card 第 e52eb4627d11516b0c01de49210ab5a4e4061444 修訂版（Hugging Face，2026 年 10 月 3 日）及 aleph-alpha-inference 套件 1.0.0 版為依據。最後檢查日期為 2026 年 10 月 10 日。後續修訂版可能會列出不同數字。在租用或購買硬體前，請先確認最新內容。
Model Card 對 Kolibri-1 的規範
- 架構：MoE（Mixture of Experts）。模型由許多子網路，也就是專家組成。每個 Token 只會執行其中少數專家。
- 規模：總計 78 billion 個參數，每個 Token 會啟用其中 3.46 billion 個參數。模型有 50 層，每層包含 384 個專家，每個 Token 會選取 6 個專家。
- 上下文：原生支援 262.144 Token。根據 Model Card，品質已驗證至 1.048.576 Token。
- 權重：使用 FP8（8-bit 浮點數）格式
float8_e4m3fn，區塊大小為 128×128。Embedding 與 LM-Head 使用 bfloat16。根據 Model Card，合計約 78 GB。Repository 本身大小為 78.9 GB。 - 訓練資料：62.5% 為英文、23.9% 為德文、13.6% 為程式碼，預訓練資料共 20 trillion Token。此外還使用了依德文詞彙結構調整的 Tokenizer。
- 授權：Apache 2.0。Repository 未設存取限制。因此不需要提出存取申請。
最重要的資訊在前兩行。每個 Token 啟用 3.46 billion 個參數，代表每個 Token 所需的計算量不高。但記憶體需求取決於全部 78 billion 個參數。Router 會為每個 Token 選取不同的專家。因此，所有專家都必須隨時載入顯示卡記憶體。MoE 模型的計算量如同小型模型，但記憶體占用量如同大型模型。
Tokenizer 也會產生實際影響。Tokenizer 會將文字拆分為 Token。若 Tokenizer 不適合該語言，較長的德文單字會被拆成許多小片段，因而增加上下文與計算時間。針對德文調整的 Tokenizer，處理相同文字時需要較少 Token。
Model Card 的基準測試數據
Aleph Alpha 為微調後的模型提供兩個總分。這些數字來自製造商自行評估，不是獨立測試的結果。
此圖表背後的資料
[
{
"label": "Deutsch (Overall DE)",
"overall": 70.8
},
{
"label": "Englisch (Overall EN)",
"overall": 75.5
}
]根據 Model Card，Kolibri-1 在德文的得分為 70.8，在英文的得分為 75.5。因此，這個模型在英文上的表現也略強。它是否足以應付你的工作，只能透過使用你自己的文件進行測試確認。
與 Pharia 相比的變更
Aleph Alpha 先前的模型系列稱為 Pharia。Pharia-1-LLM-7B-control 的 Model Card 採用 Open Aleph License。此授權允許非商業研究與教學使用。若要用於商業用途，必須直接聯絡 Aleph Alpha。Kolibri-1 則採用 Apache 2.0。因此，你可以在企業內使用模型，也可以修改後再發布，但必須一併提供授權條款文字與相關聲明。
Kolibri-1 需要哪種 GPU？
該 Card 列出兩個等級。最低需求：2× A100 80 GB、2× H100 SXM5、1× H200、1× B200 或 1× B300。建議配置：2× H100 SXM5、2× H200、1× B200 或 1× B300。
為什麼單張 H100 不足？計算方式很簡單。從顯示記憶體，也就是 VRAM（video random access memory）中扣除模型權重。剩餘空間主要供 vLLM 存放 KV cache。KV cache 會為上下文中的每個 token 儲存 Attention 層的鍵和值（keys 和 values）。沒有 KV cache，模型就無法保留上下文。
此圖表背後的資料
[
{
"config": "1\u00d7 H100 80 GB",
"vram_gb": 80,
"gewichte_gb": 79,
"rest_gb": 1
},
{
"config": "1\u00d7 H200",
"vram_gb": 141,
"gewichte_gb": 79,
"rest_gb": 62
},
{
"config": "2\u00d7 A100 80 GB",
"vram_gb": 160,
"gewichte_gb": 79,
"rest_gb": 81
},
{
"config": "2\u00d7 H100 SXM5",
"vram_gb": 160,
"gewichte_gb": 79,
"rest_gb": 81
},
{
"config": "2\u00d7 H200",
"vram_gb": 282,
"gewichte_gb": 79,
"rest_gb": 203
}
]H100 有 80 GB，模型權重占用 79 GB。理論上剩餘 1 GB。這不足以支援實用的上下文長度。H200 可剩餘 62 GB，兩張 H200 可剩餘 203 GB。實際可用餘裕更小。vLLM 預設只使用 92% 的顯示記憶體（--gpu-memory-utilization，vLLM 0.29.0 的預設值為 0.92），而且 activation 也需要空間。這些數值是四捨五入後的概算，不是實測結果。
此架構的兩項特性可降低 KV cache 的負擔。第一，根據 Card，Kolibri-1 以 4:1 的比例混合使用 Sliding-Window-Attention 層與完整 Attention 層。Sliding-Window 層只會儲存固定視窗中的 token。因此，其 cache 不會隨完整上下文長度成長。第二，Card 建議 --kv-cache-dtype fp8。如此一來，每個 cache 項目只占用 16 位元格式一半的記憶體。不過，完整 Attention 層仍會隨每個 token 增加而成長。當上下文長度達到 262.144 個 token 時，單張 H200 仍會十分吃緊。
為什麼一般 VPS 無法執行 Kolibri-1
Aleph Alpha 只發布了透過搭配 GPU 的 vLLM 執行的方法。該模型卡未提及 CPU 執行，也未提及 GGUF、llama.cpp 或 Ollama。一般的 CPU VPS 沒有顯示記憶體，因此缺少這條路徑所需的基礎。
不過，Hugging Face 上仍有社群製作的 GGUF 轉換版本。搜尋「kolibri-1 gguf」時，截至 2026 年 10 月 6 日會列出 8 個 Kolibri-1 儲存庫，且數量持續增加。Q4_K_M 檔案約為 47.5 GB，從計算上看可放入配備 64 GB RAM 的伺服器。不過，我們在 2026 年 10 月 6 日檢查的儲存庫都明確指出：一般的 llama.cpp 不認得 kolibri1 架構。你需要使用特定 commit 的修補版本。作者依其說明只測試過短時間的執行，通常使用 4,096 到 8,192 Token 的上下文長度。較長的上下文，以及與原始模型相比的品質，都尚未驗證。這不足以作為處理企業資料的依據。這只是實驗。
模型在不同量化設定下需要多少 RAM，說明 LLM 可容納於你的 RAM 中的大小會逐步計算。Ollama 與 vLLM 的比較則說明了為什麼這裡應使用 vLLM：vLLM 是為 GPU 上的大量平行請求所設計，Ollama 則適合以簡單方式開始使用量化模型。
安裝 Kolibri-1 與 vLLM
你需要一台配備相容 NVIDIA GPU 且已安裝驅動程式的 Linux 伺服器。租用時應注意的事項，請參閱GPU VPS 概覽。先確認機器實際具備哪些硬體：
nvidia-smi --query-gpu=name,memory.total --format=csv輸出會列出每張卡的名稱與 MiB 記憶體容量。H100 應回報約 81,000 MiB，H200 則約 143,000 MiB。如果指令沒有回報驅動程式，表示尚未安裝 NVIDIA 驅動程式。此時 vLLM 也找不到 GPU。
接著建立獨立的 Python 環境。這個套件會在固定版本範圍內安裝 vLLM 與 PyTorch。使用獨立環境不會影響伺服器上的其他程式。
sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/kolibri
source ~/kolibri/bin/activate
pip install 'aleph-alpha-inference==1.0.0'
pip show vllm aleph-alpha-inferenceCard 會寫入 pip install 'aleph-alpha-inference>=1'。這裡將版本固定為 1.0.0。之後的版本就不會在你未察覺的情況下變更設定。1.0.0 需要 Python 3.10 或更新版本，以及 0.29.0 以上但低於 0.30.0 的 vLLM。pip show 應顯示 0.29.x 版本的 vLLM。這個套件是 vLLM 的外掛程式。它會註冊用於推理與工具呼叫的剖析器 kolibri1。沒有此外掛程式時，vLLM 不認識這些名稱。
Aleph Alpha 也提供容器映像：ghcr.io/aleph-alpha/aleph-alpha-inference。使用容器管理 GPU 伺服器時，可以採用這種方式。
停用 vLLM 遙測
vLLM 預設會傳送匿名使用統計。如果要求任何資料都不能離開伺服器，請在啟動前停用此功能：
export VLLM_NO_USAGE_STATS=1
export DO_NOT_TRACK=1啟動伺服器
此指令依照 Card 執行，另外加入固定修訂版本，並繫結至 localhost。
vllm serve Aleph-Alpha/Kolibri-1 \
--revision e52eb4627d11516b0c01de49210ab5a4e4061444 \
--host 127.0.0.1 --port 8000 \
--kv-cache-dtype fp8 \
--reasoning-parser kolibri1 \
--tool-call-parser kolibri1 \
--enable-auto-tool-choice--revision 指定要載入哪個權重版本。如果沒有這個選項，vLLM 會從 main 載入最新版本。Aleph Alpha 修改 Repository 後，模型會在下次下載時變更。--host 127.0.0.1 會讓 API 只能從本機存取。沒有這個選項時，vLLM 會監聽所有網路介面。只要防火牆允許，8000 埠就會對外開放。
使用兩張 GPU 時，加入 --tensor-parallel-size 2。這個選項會將每一層分配到兩張卡上。沒有這個選項時，vLLM 只會使用一張 GPU，而權重無法放入單張 80-GB 卡。
第一次啟動時，vLLM 會從 Hugging Face 下載約 79 GB 到 ~/.cache/huggingface。請為此下載以及 Python 環境預留足夠的磁碟空間。首次成功下載後，可以使用 export HF_HUB_OFFLINE=1 阻止後續與 Hugging Face 的所有連線。之後權重只會從本機快取載入。
如果記憶體不足以容納完整的 262,144 Token 上下文，vLLM 將無法啟動。錯誤訊息會指出，KV cache 不足以支援最大序列長度。此時請設定較小的上限，例如 --max-model-len 65536。Card 會使用 --max-model-len 1048576 與 --hf-overrides '{"max_position_embeddings": 1048576}' 啟動最多 1,048,576 Token 的延伸上下文。這需要更多記憶體，應使用建議的設定。
確認模型能否回應
日誌顯示伺服器已在 8000 埠執行後，測試與 OpenAI 相容的 API：
curl http://127.0.0.1:8000/v1/models
curl http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "Aleph-Alpha/Kolibri-1", "messages": [{"role": "user", "content": "Was ist die Hauptstadt von Frankreich?"}], "chat_template_kwargs": {"enable_thinking": false}}'第一個呼叫應將 Aleph-Alpha/Kolibri-1 列為模型。第二個呼叫應傳回 JSON，並在其中由 choices[0].message.content 指出 Paris。enable_thinking: false 會停用這次請求的推理模式。此模式預設為啟用。根據 Card，reasoning_effort 也會使用值 none。Card 建議的 Sampling 設定為 temperature=1.0、top_p=0.97 與 top_k=128。
從你的電腦存取時，不需要開放埠。建立 SSH 通道即可：
ssh -L 8000:127.0.0.1:8000 user@dein-server之後可在你的電腦上透過 http://127.0.0.1:8000 存取 API。如果網路中的其他服務也需要存取，請另外設定 --api-key，並在前方配置使用 TLS（transport layer security）的反向代理。
Kolibri-1 每小時的歐元成本是多少？
GPU 租用價格會因供應商與地區而有很大差異。以下計算採用截至 2026 年 10 月的兩項假設：H200 每小時 3.50 歐元，以及 H100 SXM5 每小時 2.50 歐元，兩者皆為隨選價格，且未含加值稅。專門的 GPU 供應商有時價格更低，EU 地區的 hyperscaler 通常明顯更高。請代入你取得的報價。計算方式不變。
此圖表背後的資料
[
{
"plan": "1\u00d7 H200, rund um die Uhr",
"eur_pro_stunde": 3.5,
"stunden_pro_monat": 730,
"eur_pro_monat": 2555
},
{
"plan": "2\u00d7 H100 SXM5, rund um die Uhr",
"eur_pro_stunde": 5,
"stunden_pro_monat": 730,
"eur_pro_monat": 3650
},
{
"plan": "1\u00d7 H200, nur B\u00fcrozeit",
"eur_pro_stunde": 3.5,
"stunden_pro_monat": 176,
"eur_pro_monat": 616
}
]一個月平均有 730 小時。若 H200 全天候執行，每月成本為 2555 歐元。建議使用兩張 H100 的方案，每月成本為 3650 歐元。若只在辦公時間執行，也就是每天 8 小時、每月 22 個工作日，共 176 小時，成本為 616 歐元。但每次啟動都必須將模型權重重新載入 GPU 記憶體，這需要幾分鐘。
何時相較於 API Token 更具成本效益？
截至 2026 年 10 月，該 Card 未列出 Kolibri-1 的託管 API。因此，與 Token 價格比較，實際上是將自有 GPU 上的 Kolibri-1，與透過 API 使用的其他模型相比較。以下計算採用每百萬 Token 的兩項假設價格，並混合計算輸入與輸出：平價模型為 0.50 歐元，較昂貴的模型為 2 歐元。
此圖表背後的資料
[
{
"plan": "1\u00d7 H200, rund um die Uhr",
"mio_token_bei_0_50_eur": 5110,
"mio_token_bei_2_eur": 1277.5,
"token_pro_sekunde_bei_0_50_eur": 1944
},
{
"plan": "2\u00d7 H100 SXM5, rund um die Uhr",
"mio_token_bei_0_50_eur": 7300,
"mio_token_bei_2_eur": 1825,
"token_pro_sekunde_bei_0_50_eur": 2778
},
{
"plan": "1\u00d7 H200, nur B\u00fcrozeit",
"mio_token_bei_0_50_eur": 1232,
"mio_token_bei_2_eur": 308,
"token_pro_sekunde_bei_0_50_eur": 1944
}
]若每百萬 Token 的價格為 0.50 歐元，H200 持續執行時，必須每月處理 5110 百萬 Token 才能達到損益兩平。這相當於每秒平均處理 1944 個 Token，日夜不停且不中斷。若每百萬 Token 的價格為 2 歐元，辦公時間方案的損益兩平門檻會降至 308 百萬 Token。單張 GPU 是否能以你的 Prompt 長度與回應長度組合達到這項吞吐量，必須實際測量。這項計算只能說明必須達到多少使用量，才值得進一步考慮這個問題。
詳細的計算方法，包括使用率與閒置時間，請參閱 GPU 伺服器與 API Token 的損益兩平計算。對 Kolibri-1 而言，還有一項表格無法呈現的因素。若因為資料因素而想自行託管 Kolibri-1，通常根本不會拿它與 API 比較。如果文件不得離開組織，API 就不適用。此時真正的問題是：在 EU 資料中心租用具備資料處理協議（AVV）的 GPU，還是購買自有硬體。租用的 GPU 同樣位於第三方環境。依據 GDPR（一般資料保護規則），這屬於委託處理，而不是在自有場所執行。
何時較小的本地模型才是誠實的選擇
如果你需要 Kolibri-1 的優勢，使用它才值得。根據 Card，這些優勢包括工具呼叫與長上下文的文件處理。262.144 個 Token 可在單一請求中容納整個合約資料夾。如果你的工作內容較短，成本計算就會不同。
整理電子郵件或產生簡短摘要時，7 到 14 billion parameters 的模型通常已經足夠。經過 4 bit 量化後，這類模型可透過 Ollama 在配備 16 到 32 GB RAM 的 CPU VPS 上執行。速度比 GPU 慢，但每天處理幾百個請求通常已經足夠。這份教學說明如何自行在 VPS 上代管 Ollama。這樣的成本是一般伺服器月租，而不是 GPU 按小時計費。
同一個開發團隊旗下，最直接的小型模型是 Pharia-1-LLM-7B-control。不過，根據授權文字，其授權條款 Open Aleph License 僅允許非商業及非管理用途。因此，它不適合企業使用。
只有透過測試，才能做出務實的決定。從日常工作中挑選 50 個實際任務。讓 Kolibri-1 在按小時租用的 GPU 上處理這些任務，再讓小型模型在 CPU VPS 上處理。接著比較兩者的回答。租用幾小時進行測試的費用，通常遠低於錯誤購買硬體的成本。
如何自行代管 Kimi K3可協助你了解，同一個問題在另一個開放模型上的表現。這項比較有助於判斷定位：Kolibri-1 的權重約為 78 GB，屬於仍可在單張卡上執行的模型。
FAQ
我可以將 Kolibri-1 用於商業用途嗎？
可以。根據 Model Card，Kolibri-1 採用 Apache 2.0 授權。你可以在企業中使用，也可以修改後再散布，但必須附上授權文字與相關聲明。這使 Kolibri-1 不同於較早的 Pharia 系列：Pharia-1-LLM-7B-control 的 Card 採用 Open Aleph License，根據授權文字，該授權僅允許非商業及非行政用途。
Kolibri-1 能搭配 Ollama 或在 CPU 上執行嗎？
官方不支援。Aleph Alpha 只發布透過 vLLM 在 NVIDIA GPU 上執行的方式，並使用外掛程式 aleph-alpha-inference。多個社群儲存庫提供 GGUF 檔案，例如 47,5 GB 的 Q4_K_M 檔案。這些檔案需要經過修補的 llama.cpp，因為一般的 llama.cpp 不支援 kolibri1 架構。作者也表示，相關品質與長內容功能尚未經過驗證。
單張 80 GB 的 H100 足以執行 Kolibri-1 嗎？
不行。僅 FP8 權重就約占用 78 GB。留給保存內容的 KV-cache 的空間幾乎所剩無幾。Card 將兩張 H100 SXM5 或一張 H200 列為最低需求之一。使用兩張 GPU 時，請以 --tensor-parallel-size 2 啟動 vLLM。
如何關閉 Kolibri-1 的思考模式？
思考模式預設為啟用。你可以在每次請求的 JSON body 中使用 "chat_template_kwargs": {"enable_thinking": false} 將其關閉。根據 Card，reasoning_effort 搭配值 none 也能達到相同效果。模式啟用時，--reasoning-parser kolibri1 會將思考文字與實際回答分隔開來。