Kimi K2.6のセルフホストにGPUは何枚必要か？API、vLLM、ハードウェア要件を整理

先に結論：最低GPU枚数は、まだ断定しないほうがいい

現時点で確認できる公開情報では、Kimi K2.6に公式のモデルページやデプロイ資料はありますが、調達仕様としてそのまま使える「最低GPU型番」「最低枚数」「最低VRAM容量」は確認できません。

そのため、「RTX 4090を何枚なら足りるのか」「Mac Studioで動くのか」「単体サーバー1台でproduction運用できるのか」といった問いに、確定情報として答えるのは危険です。

現実的な判断は次の通りです。試用、アプリ連携、coding agent、社内ツールへの組み込みが目的なら、まずprovider/APIを使う。どうしても閉域網、データ管理、独自serving stackなどの理由で自前運用が必要なら、サーバー級の多GPU案件としてPoC、つまり事前検証を行い、その結果でクラウドGPUを借りるか、ハードウェアを購入するかを決めるべきです。

確認できること：自前運用の入口も、APIの入口もある

Kimi K2.6はHugging Faceにmoonshotai/Kimi-K2.6のモデルページがあり、同リポジトリ内にdocs/deploy_guidance.mdというデプロイ文書があります。 また、vLLM RecipesのKimi K2.6ページでは、モデルが1T / 32B active · MOE · 256K ctxと表記されています。

ここでいうvLLMは、大規模言語モデルをサーバーで配信するためによく使われる推論・serving系のフレームワークです。vLLM Recipesに掲載されていることは、自前運用を考える際の出発点にはなります。

ただし、CloudPriceのKimi K2.6ページには3つのproviderが掲載されているため、自前運用だけが利用方法ではありません。 providerの有無、価格、制限は変わり得るため、本番導入前には各providerの最新ページを確認する必要があります。

K2.6を「ローカル小型モデル」扱いしないほうがいい理由

vLLM RecipesはKimi K2.6を1Tパラメータ、32B activeのMoEモデル、かつ256K contextとして示しています。 この表記だけでも、K2.6は小型のローカルLLMのように「手元のGPU 1枚に載せて終わり」と考えるより、大規模モデルのserving設計として扱うべきだと分かります。

注意したいのは、vLLMのKimi K2 usage guideが対象としているのはmoonshotai/Kimi-K2-Instructであり、Kimi K2.6そのものではない点です。そのため、このガイドからK2.6の最低ハードウェア要件を逆算することはできません。

ただし、その例ではRayをnode 0とnode 1で起動し、--tensor-parallel-size 8、--pipeline-parallel-size 2、--dtype bfloat16、--quantization fp8、--kv-cache-dtype fp8などの設定が使われています。 これは少なくとも、Kimi K2系のserving例がparallelism、量子化、多GPU／多ノード構成を前提にした設計に近いことを示しています。

第三者情報にも同じ方向のシグナルがあります。AllThingsHowの記事では、moonshotai/Kimi-K2.6-INT4をvLLMで起動する例として、--tensor-parallel-size 4と--max-model-len 131072を含むコマンドが紹介されています。 また、別のself-hosting guideは、Kimi K2.6 INT4モデルが約594GBで、少なくとも4枚のH100 GPUで動かせると述べています。

ただし、これらはPoCの目安にはなっても、Moonshot AIの公式最低ハードウェア保証ではありません。社内稟議や購買仕様にそのまま貼り付けるには不十分です。

APIか、自前運用か：まずこの表で切り分ける

自前運用前に確認したいPoCチェックリスト

1. モデル名とバリアントを固定する

moonshotai/Kimi-K2.6、moonshotai/Kimi-K2.6-INT4、moonshotai/Kimi-K2-Instructを同じものとして扱わないことが重要です。K2.6のモデルページ、K2.6 INT4の第三者vLLM例、vLLMのK2-Instruct usage guideは、それぞれ異なるモデルまたはバリアントを指しています。

2. context lengthを固定する

vLLM RecipesではKimi K2.6が256K contextと示されています。 一方、AllThingsHowのK2.6 INT4 vLLM例では--max-model-len 131072が設定されています。 131K contextで動いた結果を、256K contextでのVRAM消費、スループット、レイテンシにそのまま当てはめることはできません。

3. 量子化とKV cache設定を固定する

vLLMのKimi K2-Instruct例にはFP8 quantizationとFP8 KV cacheが含まれています。 一方、AllThingsHowのK2.6例はINT4モデル名を使っています。 量子化方式、KV cache dtype、batch size、同時実行数が変わると、必要なGPUメモリも性能も変わります。

4. parallelism設定を記録する

vLLMのK2-Instruct例はtensor parallelとpipeline parallelを使っています。 AllThingsHowのK2.6 INT4例も--tensor-parallel-size 4を使っています。 検証ログには、tensor parallel、pipeline parallel、ノード数、各ノードのGPU枚数を必ず残すべきです。ここが抜けると、別環境との比較がほぼできません。

5. 買う前に借りて試す

H100、H200、RTX 4090、あるいは別のGPU構成を検討している場合でも、最初から購入前提にしないほうが安全です。対象のモデル版、context長、量子化方式、同時実行数、servingフレームワークを固定し、クラウドGPUやレンタル環境でPoCしてから判断すべきです。現時点の公開情報だけでは、「この枚数なら必ず快適に動く」と言い切る根拠が不足しています。

最終判断：Kimi K2.6は多GPU前提で検証、ただしAPIから始められる

Kimi K2.6について実務上いちばん安全な結論は、次の一文に尽きます。使うだけならAPI／providerから始められる。自前運用するなら、Hugging Faceのデプロイ文書とvLLM Recipesを起点にしつつ、第三者のハードウェア例を公式最低要件として扱わないことです。

調達やアーキテクチャ判断では、Kimi K2.6のセルフホストをサーバー級の多GPUプロジェクトとして扱うべきです。公式の最低GPU枚数や最低VRAM容量が明示されていない以上、単体GPU、民生GPU、または特定枚数のH100で「必ず足りる」と前提を置くのは避け、同一モデル・同一量子化・同一context・同一同時実行条件で検証してから決めるのが現実的です。