Kimi K3 のセルフホスティングは、2026年7月27日に Moonshot AI が 2.8兆パラメータモデルの重みを本番向け推論サポートとともに公開したことで、技術的に可能になりました。多くの組織はそのニュースを読み、これでフロンティア級の推論を自社ハードウェアで動かし、トークン単位の支払いをやめられると結論づけました。

その結論はたいてい間違っていますが、多くの人が思う理由によってではありません。エンジニアリングは達成可能です。大半のプロジェクトを打ち負かすのは計算のほうであり、しかも予算承認から数か月後に静かに打ち負かします。

端的な答え: MXFP4 精度では、2.8兆パラメータはキーバリューキャッシュを数える前に約 1.4TB を占めます。H100 8基のノードは 640GB なので、このモデルをそもそも提供できません。現実的な導入は約 1.7TB の VRAM から始まり、これは 288GB アクセラレータを使う現世代ノード、または前世代の 16 基構成を意味します。Moonshot は本番利用者に対しアクセラレータ 64 基以上のクラスタを推奨しています。

オープンウェイトが実際にもたらすもの

ハードウェアより先に、まずライセンスです。これが計画全体に検討する価値があるかどうかを決めるからです。

公開された重みには、モデルカードが Kimi K3 License と名付ける独自ライセンスが付いています。これは通常の MIT や Apache の許諾ではなく、そう説明する第三者の要約を鵜呑みにすべきではありません。ライセンス本文を自分で読み、商用導入を確定する前にレビューを受けてください。とくに帰属表示の要件と、特定の利用規模で発動する条件に注意してください。半日で済み、後日の厄介な話し合いを防げます。

重みが実際に買ってくれるのは統制です。データが自社の外に出ることはありません。誰かがモデルを打ち切ったり価格を変えたりすることもありません。ファインチューニングも、追加の量子化も、API では決して許されない形での提供動作の変更も可能です。データ主権の義務がある組織にとっては、これらの性質こそが本題であり、コストは副次的です。

一方で重みが買ってくれないのは、API がすでに行っていることをより安く行う手段です。この区別こそ、誰かがハードウェアを仕様化する前に確定しておくべき最も有用な事項です。

Kimi K3 セルフホスティングのハードウェア計算

重みから出発して外側へ広げてください。ほかのあらゆる要件はそこから導かれます。

2.8兆パラメータをパラメータあたり 4 ビットで持つと約 1.4TB の容量になり、妥当な速度でリクエストを処理するにはその全部がアクセラレータのメモリに常駐している必要があります。この数字だけで、多くのチームが想定する構成は除外されます。80GB の H100 を 8 基そろえても 640GB であり、重みが要求する量の半分にも届きません。

さらにキーバリューキャッシュを加える必要があります。100万トークンのコンテキストをうたうモデルは、同時リクエストごとにアテンション状態を保持する場所を必要とし、その割り当てはコンテキスト長とバッチサイズの双方に比例して増えます。公開されている vLLM のメタデータは最小の提供フットプリントを約 1,680GB としており、これは重みに控えめなキャッシュを足し、積極的なバッチ処理の余裕はない水準と整合します。

実際に取りうる構成

実務上は次のいずれかの形になります。288GB のアクセラレータ 8 基、NVIDIA B300 でも AMD MI355X でも、単一ノードで約 2.3TB を確保でき、最も素直な選択肢です。B200 や GB200 クラスを 16 基でも、より大きな設置面積で同程度の総量に達します。概念実証ではなく持続的な本番スループットを狙うなら、Moonshot 自身の指針はアクセラレータ 64 基以上のスーパーノード構成を示しています。

密なモデルを導入した経験のある人がつまずく細部を一つ強調しておきます。これは各トークンを 896 のうち 16 のエキスパートにルーティングする Mixture of Experts アーキテクチャであり、異なるエキスパートを保持するデバイス間で相当量の全対全通信を発生させます。ここでのインターコネクト帯域は「あれば嬉しい」ものではありません。総メモリは足りていてもインターコネクトが弱い構成は、仕様書が示唆するよりはるかに低いスループットしか出さず、購入後にそれを診断するのは高くつく教訓になります。

実際に動かす

ソフトウェア面は 1 年前より落ち着いており、この点は助けになります。

モデルカードは vLLM、SGLang、TokenSpeed を対応推論エンジンとして挙げています。重要なのは、Kimi Delta Attention のサポートが後追いではなく重みと同時に出荷された点で、最新の vLLM ビルドにはこのアーキテクチャが必要とするカーネルが含まれています。古いインストールには含まれておらず、デプロイが起動に失敗したときに最初に確認すべきはここです。

エンジン以外にも段取りを計画してください。1 テラバイトを超える重みを取得して保管するので、高速なローカルストレージを用意し、初回のダウンロードとロードには数分ではなく実質的な時間がかかると見込んでください。リクエストあたりの最大コンテキスト長に上限を設けてください。すべての呼び出し元に 100万トークンを許せば、同時利用者が数人いるだけでキャッシュ割り当てを使い切ります。レイテンシとスループットのどちらを最適化するかを早めに決めてください。積極的なバッチ処理は毎秒トークン数を改善し、最初のトークンまでの時間を悪化させます。両方を同時に得ることはできません。

最後に、これを研究用の配備ではなく本番インフラとして扱ってください。監視、キャパシティプランニング、ドライバとカーネルのバージョン管理、そして止まったときに連絡がつく担当者が必要です。この運用負荷こそ、事業計画から最も抜け落ちやすい部分です。

誰もやらないコスト比較

ここに大半のプロジェクトを決する計算があります。ハードウェアの議論の後ではなく前にやる価値があります。

K3 を提供できるノードは、提供事業者・地域・契約期間により幅がありますが、現世代ハードウェアなら月あたり 25,000〜50,000 ドルという数字が妥当な計画レンジです。買い切りは初期費用がはるかに大きく、複数年の見通しがある場合にのみ意味を持ちます。

ここで API と比べてみましょう。出力 100万トークンあたり約 15 ドルなら、月 30,000 ドルのインフラ費用はホスト型サービスで 20億トークンの出力を買えます。月 20億の出力トークンは 1 日あたり約 6,600万トークンです。典型的な応答が 1,500 トークンなら、セルフホスティングがコストだけで損益分岐に達する前に、毎日およそ 44,000 件の応答を継続的に処理する必要があります。

さらに悪いことに、この比較はクラスタを 24 時間フル稼働させる前提です。多くのワークロードはそうではありません。業務時間帯にピークを迎え、夜間はアイドルであり、アイドル時間にも稼働時間とまったく同じ費用を払います。社内ツールでよくある実効稼働率 30% なら、トークンあたりの実効コストはおよそ 3 倍になり、損益分岐点はさらに手の届かない場所へ遠のきます。

結論は居心地が悪いものですが一貫しています。圧倒的多数の組織にとって、Kimi K3 のセルフホスティングは API を使うより高くつきます。事業計画がコスト削減に立脚しているなら、誰かが発注書に署名する前に、実際の見積もりと実際の数量予測でこの計算を回してください。

セルフホスティングが本当に正しい場合

コストは間違った理由です。正しい理由は次のとおりです。

データが自社インフラから出ることを禁じる規制上または契約上の義務があるなら、判断はすでに決まっており、どれほど有利な API 価格もそれを変えません。防衛、医療、金融サービスの一部は定期的にこの立場にあり、彼らにとっての計算は単にコンプライアンスにいくらかかるかという話です。日本でも金融機関や公共部門では、データの国内保管や外部接続の制限が判断を左右する場面が少なくありません。

本当に高い持続的な処理量は計算をひっくり返します。安定した稼働率で月に数十億トークンを消費しているなら固定費モデルが勝ち、量が増えても線形にコストが増えないため勝ち続けます。

予測可能性と自由度

予測可能性そのものにも価値があります。導入を自社で所有するということは、提供終了の通知も、契約途中の価格改定も、他社のキャパシティ計画によるレート制限もないということです。中核機能がモデルに依存する製品なら、この安定性だけで費用を正当化できることもあります。

最後に、ファインチューニング、提供動作の改変、あるいは外部接続を遮断した環境での運用を意図しているなら、API はいくら払っても助けになりません。

一方で、間違った選択となる場合も正直に見てください。断続的または小規模な処理量、GPU 運用の経験がないチーム、そして主にコスト削減に立脚した事業計画です。Kimi K3 API のガイドがホスト型の経路を扱っており、多くの組織にとって妥当な順序は、まず API 上で構築し、数量と要件が正当化した時点で自社インフラへ移行することです。

妥当な中間の道

全か無かの答えを必要とする組織はごくわずかで、ハイブリッド構成が最も強力であることが多いです。

大半のトラフィックは、使った分だけ支払うホスト型 API にルーティングしてください。セルフホスト環境は、本当に自社の外に出せないデータを扱う特定のワークロードのために取っておいてください。K3 は両方の経路の背後で同じモデルを提供するため、能力ではなくデータ分類によってリクエストを振り分けられ、アプリケーションはどちらを通ったかを知る必要すらありません。

このやり方には、OpenAI API 統合ガイド で説明したのと同じ抽象化層が必要です。認証情報とルーティング、計測を所有するプロキシを置き、提供元と設置場所をアーキテクチャではなく設定にするのです。一度作れば、両方の選択肢が開いたまま残ります。

実際にやったことのある人間と導入を計画する

Mecanik は、ホスト型・セルフホスト型・ハイブリッドの言語モデル導入を扱う AI 統合サービス を提供しており、そこにはどちらが自社のワークロードにとって実際に妥当かを示すキャパシティモデリングが含まれます。

実際のトラフィックに対して稼働率と損益分岐の計算を行い、ハードウェアを正直に仕様化し、API のほうが良い答えであるときにはそう申し上げます。実際その場合は少なくありません。セルフホスト導入が妥当な場合には、カスタムソフトウェア開発サービス がその周辺の提供スタック、ルーティング層、監視、データ分類ロジックを担当します。完全な仕様は Kimi K3 モデルカード で公開されています。

関連記事: 真のAIは存在するのか？神話と現実を解き明かす 、検索拡張生成（RAG）を解説 2026 、OpenAI ChatGPT 5 vs Grok 4 - どちらがより良いPythonコードを作成するか？ 、AIエージェンシーか自社開発か：2026年の英国におけるAI導入 、Tiny BPE Trainer – 高速で軽量なC++製BPEトレーナー 。

よくある質問

Kimi K3 をセルフホストするにはどんなハードウェアが必要ですか？ MXFP4 精度では重みが約 1.4TB を占め、キーバリューキャッシュを含めた現実的な提供には約 1.7TB の VRAM が必要です。これにより 640GB の H100 8 基ノードは除外され、288GB の現世代アクセラレータ 8 基、前世代の 16 基構成、あるいは本番スループット向けのより大きなクラスタが選択肢になります。

Kimi K3 のセルフホスティングは API より安いですか？ たいていは違います。適したノードは月およそ 25,000〜50,000 ドルで、これはホスト型 API で約 20億トークンの出力を買える金額です。その処理量を 24 時間高い稼働率で維持しない限り、API のほうが安くつきます。セルフホスティングはコストではなくデータ主権と統制によって正当化されます。

Kimi K3 の重みはどのライセンスですか？ モデルカードは、標準的な MIT や Apache の許諾ではなく Kimi K3 License という独自ライセンスを明示しています。これを標準的なオープンソースライセンスとして説明する第三者の要約は信頼できないため、商用導入の前にライセンス本文を直接読み、法務レビューを受けてください。

どの推論エンジンが Kimi K3 に対応していますか？ モデルカードは vLLM、SGLang、TokenSpeed を挙げています。モデルの Kimi Delta Attention 機構のサポートは重みと同時に出荷されたため、それらのカーネルを含む最新のビルドが必要です。古いインストールではモデルの読み込みに失敗します。

Kimi K3 を 1 台のマシンで動かせますか？ ハイエンドのマルチアクセラレータサーバーでのみ可能です。288GB のカードを 8 基備えたノードならモデルを収容できますが、コンシューマ向けハードウェアや単一 GPU のワークステーションでは到底届きません。また Mixture of Experts のルーティングにより、アクセラレータ間のインターコネクト帯域が実効スループットの主要な要因になります。