著者 Matt Connor
Kolibri-1のセルフホストに必要なGPUと費用
Kolibri-1はApache 2.0ですが、FP8重みは約78 GBです。H200 1台または80 GB GPU 2枚が必要な理由と、ユーロ換算の費用、小型モデルで足りる条件を解説します。
Kolibri-1をセルフホストする: 短い回答
Kolibri-1のセルフホストは可能ですが、一般的なVPSでは実行できません。HeidelbergのAleph Alphaは、このモデルをApache 2.0ライセンスで公開しています。FP8形式の重みのサイズは約78 GBです。公式の方法は、少なくとも1台のH200、またはそれぞれ80 GBのメモリを搭載した2枚のGPUでvLLMを実行することです。CPU、GGUF、llama.cpp、Ollama向けの公式な方法はありません。
ドイツの多くの読者にとって、最も重要なのは次の点です。データを自社内に保持できるでしょうか。Kolibri-1なら可能で、ライセンスも妨げにはなりません。障壁となるのはハードウェアです。
記載内容の基準日: ここで説明する内容は、Aleph-Alpha/Kolibri-1のModel Cardのe52eb4627d11516b0c01de49210ab5a4e4061444改訂版（Hugging Face、2026年10月3日）と、バージョン1.0.0のaleph-alpha-inferenceパッケージに基づいています。最終確認日は2026年10月13日です。その後の改訂版では数値が変更されている可能性があります。ハードウェアをレンタルまたは購入する前に、必ず確認してください。
Model Card が Kolibri-1 について定めていること
- アーキテクチャ: MoE（Mixture of Experts）。モデルはエキスパートと呼ばれる多数のサブネットワークで構成されます。1 トークンの計算では、そのうち少数だけを使用します。
- サイズ: パラメーターは合計 78 billion で、1 トークンあたり 3.46 billion がアクティブになります。384 個のエキスパートを持つ層が 50 層あり、1 トークンあたり 6 個が選択されます。
- コンテキスト: ネイティブでは 262.144 トークンです。Card によると、品質は 1.048.576 トークンまで検証されています。
- 重み:
float8_e4m3fn形式の FP8（8-bit 浮動小数点数）で、128×128 のブロック単位です。Embedding と LM-Head は bfloat16 です。Card によると、合計で約 78 GB になります。Repository 自体のサイズは 78,9 GB です。 - 学習データ: 事前学習では 20 trillion トークンを使用し、英語が 62,5 %、ドイツ語が 23,9 %、Code が 13,6 % を占めます。さらに、Card によると、ドイツ語の語構造に合わせた Tokenizer が使われています。
- ライセンス: Apache 2.0。Repository は gated ではありません。そのため、アクセス申請は必要ありません。
最も重要なのは、最初の 2 行に示されている点です。3.46 billion のアクティブパラメーターは、1 トークンあたりの計算量が少ないことを意味します。ただし、必要なメモリ容量は 78 billion 個すべてのパラメーターで決まります。Router はトークンごとに異なるエキスパートを選択します。そのため、すべてのエキスパートを常に GPU メモリ上に配置しておく必要があります。つまり、MoE モデルは小型モデルのように計算し、大型モデルのようにメモリを使用します。
Tokenizer にも実用上の効果があります。Tokenizer はテキストをトークンに分割します。言語との適合性が低いと、長いドイツ語の単語が多数の小さな断片に分割されます。その分、コンテキストと計算時間を消費します。ドイツ語に合わせた Tokenizer なら、同じテキストに必要なトークン数を減らせます。
Card のベンチマーク結果
Aleph Alpha は、追加学習済みモデルについて 2 つの総合値を示しています。これらはメーカー独自の評価による数値であり、独立したテストの結果ではありません。
このグラフのデータ
[
{
"label": "Deutsch (Overall DE)",
"overall": 70.8
},
{
"label": "Englisch (Overall EN)",
"overall": 75.5
}
]Card によると、Kolibri-1 はドイツ語で 70.8 点、英語で 75.5 点を達成しています。このモデルも英語のほうがやや強い結果です。自分の用途に十分かどうかは、自分のドキュメントを使ったテストでのみ確認できます。
Pharia からの変更点
Aleph Alpha の以前のモデルシリーズは Pharia という名称でした。Pharia-1-LLM-7B-control の Card では Open Aleph License が指定されています。このライセンスは、非商用の研究と教育を許可します。商用利用には Aleph Alpha への直接の問い合わせが必要でした。一方、Kolibri-1 は Apache 2.0 の下で提供されています。そのため、ライセンス文と通知を添付する限り、社内でモデルを使用でき、変更したモデルを再配布することもできます。
Kolibri-1 にはどの GPU が必要ですか？
Card には 2 段階が記載されています。最小構成は、2× A100 80 GB、2× H100 SXM5、1× H200、1× B200、または 1× B300 です。推奨構成は、2× H100 SXM5、2× H200、1× B200、または 1× B300 です。
H100 1 枚ではなぜ不十分なのでしょうか。計算は単純です。グラフィックスメモリ、つまり VRAM（video random access memory）から重みの容量を差し引きます。残った容量は、主に vLLM が KV キャッシュに使用します。KV キャッシュには、コンテキスト内の各トークンについて、Attention 層のキーと値（keys と values）が保存されます。これがなければ、モデルはコンテキストを保持できません。
このグラフのデータ
[
{
"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 1 枚の容量は 80 GB で、重みが 79 GB を占有します。計算上の残りは 1 GB です。実用的なコンテキストを確保するには不十分です。H200 1 枚では 62 GB、H200 2 枚では 203 GB が空きます。実際に使える余裕は、これより小さくなります。vLLM はデフォルトでグラフィックスメモリの 92 % しか使用せず（--gpu-memory-utilization、vLLM 0.29.0 のデフォルト値は 0.92）、アクティベーションにも容量が必要です。これらは丸めた概算であり、実測値ではありません。
アーキテクチャには、KV キャッシュの負荷を軽減する 2 つの特徴があります。1 つ目は、Card によると、Kolibri-1 は Sliding-Window-Attention の層と完全な Attention の層を 4:1 の比率で組み合わせていることです。Sliding-Window 層は、固定されたウィンドウ内のトークンだけを保存します。そのため、キャッシュはコンテキスト長全体に比例して増加しません。2 つ目は、Card が --kv-cache-dtype fp8 を推奨していることです。これにより、各キャッシュエントリが占有する容量は 16 ビットの場合の半分になります。ただし、完全な Attention の層はトークンが増えるたびに拡大します。262.144 トークンでは、H200 1 枚では容量が厳しくなります。
通常の VPS で Kolibri-1 を実行できない理由
Aleph Alpha が公開している手順は、GPU 上で vLLM を使用する方法だけです。Card には CPU での実行、GGUF、llama.cpp、Ollama についての記載がありません。一般的な CPU VPS には GPU メモリがありません。そのため、この方法を実行する前提がありません。
それでも Hugging Face には、コミュニティによる GGUF 変換版があります。「kolibri-1 gguf」で検索すると、2026 年 10 月 6 日には Kolibri-1 用のリポジトリが 8 件表示され、2026 年 10 月 13 日には 11 件になっています。Q4_K_M ファイルは約 47.5 GB あり、計算上は RAM 64 GB のサーバーに収まります。ただし、2026 年 10 月 6 日に確認したリポジトリ自身が、通常の llama.cpp はアーキテクチャ kolibri1 を認識しないと説明しています。特定のコミットから作成したパッチ適用済みのバージョンが必要です。2026 年 10 月 13 日になっても状況は変わっていません。llama.cpp には Kolibri-1 に関する未解決の Feature Request が 1 件あるだけです。一部の作者は長いコンテキストもテストしています。Prompt48 は、A100 上の Q4_K_M で、テスト情報（Needle）を 195.935 Token で正確に再取得できたと報告しています。コンテキストを拡張した場合は 718.803 Token で再取得できています。Hob-forge は -c 262144 を使用した実行で、最大 253.646 Token までに 3 つの隠し事実を再取得しています。これは検索テストであり、ベンチマークではありません。Prompt48 と Hob-forge は、FP8 オリジナルとのベンチマーク比較がないことを明記しています。企業データに使用する根拠にはなりません。これは実験です。
モデルが量子化方式ごとに必要とする RAM 容量は、LLM を RAM に収めるためのサイズを計算するガイドで手順を追って説明しています。ここで vLLM を使用する理由は、Ollama と 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 には vLLM 0.29.x のバージョンが表示されます。このパッケージは 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 がリポジトリを変更すると、次回のダウンロード時にモデルも変わります。--host 127.0.0.1 を指定すると、API はローカルからのみアクセス可能になります。このオプションを指定しない場合、vLLM はすべてのネットワークインターフェースで待ち受けます。ファイアウォールで許可すると、ポート 8000 が公開されます。
GPU が 2 枚ある場合は --tensor-parallel-size 2 を追加します。このオプションにより、各層が 2 枚のカードに分散されます。指定しない場合、vLLM は 1 枚の GPU だけを使用します。80 GB のカード 1 枚には重みを格納できません。
初回起動時に、vLLM は約 79 GB を Hugging Face から ~/.cache/huggingface にダウンロードします。この容量と Python 環境に必要な空きディスク容量を確保してください。初回のダウンロードが正常に完了した後、export HF_HUB_OFFLINE=1 を指定すると、Hugging Face への以後の通信をすべて禁止できます。その後は、重みをローカルキャッシュからのみ読み込みます。
262,144 Token の完全なコンテキストを保持するメモリが不足している場合、vLLM は起動しません。エラーメッセージには、最大シーケンス長に対して KV キャッシュが小さすぎることが示されます。その場合は、例えば --max-model-len 65536 のように、上限を小さくします。1,048,576 Token の拡張コンテキストを使用する場合は、Card で --max-model-len 1048576 と --hf-overrides '{"max_position_embeddings": 1048576}' を指定します。より多くのメモリが必要なため、推奨構成で使用してください。
モデルが応答することを確認する
ログにサーバーがポート 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}}'1 つ目の呼び出しでは、モデルとして Aleph-Alpha/Kolibri-1 が一覧に表示されます。2 つ目の呼び出しでは、choices[0].message.content が Paris を示す JSON が返ります。enable_thinking: false を指定すると、このリクエストでは推論モードが無効になります。デフォルトでは有効です。Card によると、reasoning_effort も none の値で有効です。サンプリングには、Card で 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 の 1 時間あたりの料金はユーロでいくらですか？
GPU レンタル料金は、プロバイダーと地域によって大きく異なります。以下の計算では、2026 年 10 月時点の 2 つの前提を使用します。H200 は 1 時間あたり 3.50 ユーロ、H100 SXM5 は 1 時間あたり 2.50 ユーロです。いずれもオンデマンドで、付加価値税は含みません。GPU 専門プロバイダーではこれより安い場合があります。一方、EU リージョンのハイパースケーラーでは大幅に高くなることがよくあります。実際の見積もり料金に置き換えてください。計算方法は変わりません。
このグラフのデータ
[
{
"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
}
]1 か月の平均時間は 730 時間です。H200 を 24 時間稼働させると、1 か月あたり 2555 ユーロかかります。推奨構成の H100 2 枚では、3650 ユーロになります。業務時間だけ、つまり 22 営業日に 8 時間ずつ稼働させて 176 時間に抑える場合は、616 ユーロです。ただし、起動するたびに重みを GPU メモリへ再読み込みする必要があり、数分かかります。
API トークンとの比較で、いつ元が取れますか？
2026 年 10 月時点で、Card には Kolibri-1 のホステッド API は記載されていません。したがって、トークン料金との比較は、専用 GPU 上の Kolibri-1 と、API 経由の別モデルとの比較になります。計算では、入力と出力を合わせた 100 万トークンあたりの料金として、安価なモデルは 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
}
]100 万トークンあたり 0.50 ユーロの場合、H200 を常時稼働させる構成でコストを回収できるのは、1 か月あたり 5110 百万トークンからです。これは、昼夜を問わず休みなく平均 1944 トークン/秒を処理する計算です。100 万トークンあたり 2 ユーロの場合、業務時間のみ稼働させる構成の損益分岐点は 308 百万トークンまで下がります。1 枚のカードで、プロンプトの長さと応答の長さの組み合わせに対してこのスループットを実現できるかは、実測が必要です。この計算で分かるのは、比較を検討する意味が生じる処理量だけです。
稼働率とアイドル時間を含む詳しい方法は、GPU サーバーと API トークンの損益分岐点計算に記載しています。Kolibri-1 では、表では扱えない点もあります。データを理由に Kolibri-1 を自前でホストしたい場合、API と比較しないことも少なくありません。文書を組織外へ持ち出せない場合、API は選択肢から外れます。その場合の本当の問いは、データ処理契約（AVV）を締結した EU のデータセンターで GPU をレンタルするか、自前のハードウェアを購入するかです。レンタルした GPU も第三者の設備上にあります。GDPR（一般データ保護規則）上、これは委託処理に該当し、自社施設内での運用ではありません。
小規模なローカルモデルを選ぶのが正直な判断になる場合
Kolibri-1 は、その強みが必要な場合に有用です。Card によると、ツール呼び出しと長いコンテキストを使った文書処理が強みに含まれます。262.144 Token により、契約書一式を1回のリクエストに収められます。タスクが短い場合は、費用対効果が変わります。
メールの分類や短い要約であれば、7 から 14 billion parameters のモデルで十分なことが多くあります。4 Bit に量子化すれば、16 から 32 GB RAM の CPU VPS 上で Ollama を使って動かせます。GPU より低速ですが、1日に数百件のリクエストであれば対応できます。具体的な方法は、VPS で Ollama を自分でホストする手順で説明しています。費用は GPU の時間単位の料金ではなく、通常のサーバー月額料金で済みます。
同じ開発元の小規模モデルとして自然な候補は Pharia-1-LLM-7B-control です。ただし、そのライセンスである Open Aleph License では、ライセンス本文によると非商用かつ非管理目的の利用だけが認められています。そのため、企業での利用には適しません。
正しく判断するには、テストするしかありません。日常の実際のタスクを50件用意します。時間単位で借りた GPU 上で Kolibri-1 に処理させ、CPU VPS 上では小規模モデルに処理させます。そのうえで回答を比較します。数時間分のテスト料金は、誤ったハードウェアを購入する費用と比べればわずかです。
別のオープンモデルで同じ質問を処理した場合の結果は、Kimi K3 を自分でホストするために必要なもので確認できます。この比較は位置付けを判断するのに役立ちます。Kolibri-1 は、重みが約 78 GB で、1枚のカードに収まるモデルに分類されます。
FAQ
Kolibri-1を商用利用できますか？
はい。Model Cardによると、Kolibri-1は Apache 2.0 の下で提供されています。企業で利用でき、ライセンス文と通知を添付すれば、変更したものを再配布することもできます。この点が、以前の Pharia シリーズとの違いです。Pharia-1-LLM-7B-control の Card では Open Aleph License が指定されています。このライセンスは、ライセンス文によると非商用かつ非行政目的の利用だけを認めています。
Kolibri-1はOllamaまたはCPUで動作しますか？
公式には対応していません。Aleph Alphaが公開しているのは、NVIDIA GPU上で vLLM とプラグイン aleph-alpha-inference を使用する方法だけです。複数のコミュニティリポジトリから GGUF ファイルも提供されています。たとえば、Q4_K_M では 47,5 GB です。通常の llama.cpp はアーキテクチャ kolibri1 に対応していないため、パッチを適用した llama.cpp が必要です。一部の作者は、700.000 Tokenを超える長いコンテキストで取得テストに合格したと報告しています。ただし、本人たちの説明によると、FP8版のオリジナルとのベンチマーク比較はありません。
Kolibri-1には80 GBのH100 1台で十分ですか？
いいえ。FP8の重みだけで約78 GBを使用します。コンテキストを保持するKVキャッシュ用の空きは、実質的に残りません。Cardでは、最低構成として2台のH100 SXM5または1台のH200などが挙げられています。カード2台の場合は、--tensor-parallel-size 2 を指定して vLLM を起動します。
Kolibri-1の思考モードを無効にするにはどうすればよいですか？
思考モードはデフォルトで有効です。リクエストごとに、JSONボディで "chat_template_kwargs": {"enable_thinking": false} を指定して無効にします。Cardによると、値 none の reasoning_effort も有効です。モードが有効な場合、--reasoning-parser kolibri1 が思考テキストと実際の回答を分離します。