TL;DR
2026年時点で Kimi K3 はセルフホスティング可能ですが、公開ウェイトリポジトリは約1.56 TBで、公式の vLLM レシピは開始要件としてNVIDIA GB300 GPU 8基またはAMD MI355X/MI350X GPU 8基からです。Moonshot は本番推論の効率化のため、スーパーノード構成で64基以上のアクセラレータを推奨しています。多くのチームにとっては、まずはホステッド API がリスクの低い出発点です。
Kimi K3 のセルフホスティング vs API の概観
Kimi K3 のセルフホスティングは、Moonshot の公開モデルウェイトをダウンロードし、自社のチームまたはクラウドアカウントで管理するインフラ上で実行することを意味します。GPU キャパシティ、モデル提供、スケーリング、セキュリティ、アップグレード、監視、信頼性は組織側の責任となります。
Kimi K3 の API アクセスは、基盤となる GPU クラスタを運用することなく、プロバイダー管理のエンドポイントにリクエストを送ることを意味します。プロバイダーがモデル提供とキャパシティを管理し、チームは利用量に応じて支払い、主にアプリケーション統合に注力します。
Moonshot は 2026年7月16日に公式テクニカルブログで Kimi K3 を紹介し、7月27日までにフルウェイトを公開しました。現在、モデルはオープンウェイトのチェックポイントとして利用可能ですが、「オープンウェイト」は「ローカルで簡単に動く」とは同義ではありません。機能とベンチマークの幅広い概要については、CometAPI のKimi K3 アクセスガイドを参照してください。
実務面での違いはモデルへのアクセスだけではありません。インフラの所有、キャパシティ計画、アップグレード、運用リスクを誰が負うかです。
| 意思決定要因 | Kimi K3 のセルフホスティング | Kimi K3 のホステッド API |
|---|---|---|
| モデルアクセス | 公開ウェイトと提供構成へのフルアクセス | プロバイダー管理のエンドポイント経由のアクセス |
| ウェイト容量 | 公開モデルリポジトリで約 1.56 TB | モデルのダウンロードや保存は不要 |
| 公式最小要件 | 8x NVIDIA GB300、または 8x AMD MI355X/MI350X | GPU 調達不要 |
| 本番運用ガイダンス | 高帯域の通信ドメインを持つマルチノード | プロバイダーがキャパシティとスケーリングを管理 |
| コスト構造 | 固定インフラ＋エンジニアリングと運用 | 変動する従量課金 |
| 稼働率リスク | アイドル時でもコストが発生 | 支出は一般的に実利用に追随 |
| アップグレード責任 | ランタイム、ウェイト、提供の変更をチーム側で検証 | プロバイダーが提供スタックの更新を管理 |
| データ経路の制御 | デプロイ、ログ、保持に対するより強い制御 | プロバイダーのアーキテクチャと条件に依存 |
| ライセンス確認 | Kimi K3 License がウェイトの利用を直接規定 | ホステッドアクセスはプロバイダー規約が適用 |
| 最適な適合 | 持続的な負荷、分散推論の既存知見、厳格な制御要件 | 評価、需要の変動、迅速な導入、インフラ担当が限られる場合 |
中心的な問いは、セルフホスティングが技術的に可能かどうかではありません。必要なインフラを十分に稼働させ、信頼性をもって運用し、受理タスクあたりの総コストでホステッドアクセスを上回れるかどうかです。
Kimi K3 をセルフホストできますか？
はい。Moonshot は公式 Kimi K3 リポジトリで、カスタムのKimi K3 Licenseの下、フルウェイトを公開しています。公開のデプロイ経路としては、vLLM、SGLang、TokenSpeedがあります。
ただし、Kimi K3 はワークステーションクラスのモデルではありません。これは 2.8 兆パラメータの Mixture-of-Experts モデルで、トークンごとに有効化されるパラメータは 1040 億、896 のルーティング済みエキスパート、ネイティブなマルチモーダル機能、MXFP4 ウェイト、MXFP8 アクティベーション、最大 1,048,576 トークンのコンテキストウィンドウを備えています。
「104B の有効化パラメータ」は、各トークンステップで使用されるモデル容量を示します。これは、104B のパラメータだけを保存すればよいという意味ではありません。生成中にルーターが異なるエキスパートを選択できるため、デプロイされたモデルには完全なエキスパート集合が必要です。
Kimi K3 のセルフホスティング vs API：インフラ要件
Kimi K3 のセルフホスティングには大規模な分散 GPU 環境が必要であり、ホステッド API アクセスでは基盤となるモデル提供クラスタの運用は不要です。2026年時点の公式セルフホスティングのベースラインは、NVIDIA GB300 または AMD MI355X/MI350X の 8 基から開始で、API ユーザーは標準的なアプリケーションインフラだけで済みます。
違いは GPU の所有者だけではありません。セルフホスティングでは、モデル保存、マルチノードネットワーキング、キャパシティ計画、デプロイ、スケーリング、監視、アップグレード、障害復旧もチームの責任になります。ホステッド API では、その大部分がプロバイダー側に移ります。
セルフホスティングのハードウェア要件
現在の公式 vLLM レシピは、フル Kimi K3 チェックポイントを稼働させる前提条件として以下を挙げています。
- NVIDIA：少なくとも GB300 GPU を 8 基
- AMD ROCm：少なくとも MI355X または MI350X GPU を 8 基
- 本番トラフィック：マルチノードデプロイ推奨
- vLLM：Kimi K3 イメージとドキュメント化されたデプロイプロファイルを用い、0.27.0 以降のバージョン
これらの要件は、公開された提供フロアを示すものであり、8 基の GPU システムがすべての本番ワークロードを満たすことを保証するものではありません。
Moonshot のローンチドキュメントはさらに踏み込み、高い推論効率のために、64 基以上のアクセラレータを備えたスーパーノード構成でのデプロイを推奨しています。この推奨は、とくに高い同時実行、長いコンテキストのワークロード、負荷下での予測可能なレイテンシを目指すチームに当てはまります。
ボトルネックは総 GPU メモリだけではありません。Kimi K3 はトークンごとに 896 のルーティング済みエキスパートのうち 16 を有効化するため、エキスパート並列デプロイではアクセラレータ間で大きな全対全通信が発生します。
公式の vLLM レシピは、RDMA 環境向けの deepep_v2 や、ノード間 NVLink ベースのクロスノード通信向けの flashinfer_nvlink_one_sided などの通信バックエンドを推奨しています。結果として、低速ネットワークで接続された 8 基の GPU は、高帯域で密結合されたシステム内部の 8 基の GPU と運用上同等ではありません。
セルフホスティングに必要な保存容量とランタイムメモリはどのくらい？
公開されている Kimi K3 チェックポイントは、公式 Hugging Face リポジトリによれば、約1.56 TBです。
2.8 兆パラメータを 1 パラメータ 4 ビットで保存する場合の理論上の下限計算は以下の通りです。
2.8 trillion parameters × 4 bits ÷ 8
= 1.4 trillion bytes
= about 1.4 TB, or 1.27 TiB
Kimi K3 が標準モデルより提供が難しいのはなぜ？
Kimi K3 は分散型の MoE アーキテクチャにより、全対全のエキスパート通信、長コンテキストのキャッシュ計画、モデル特有の推論履歴、ツールコールの検証が組み合わさるため、提供が難しくなります。単一ノードのモデルエンドポイントのように扱うのではなく、インターコネクト性能、並列化、プレフィルとデコードの挙動、同時実行、リトライ処理をベンチマークする必要があります。
公式 vLLM レシピは、いくつかの本番上の考慮点を強調しています。
- ノード間トラフィックには、適切な全対全バックエンドと高帯域の通信ファブリックが必要。
- MoE バックエンドは、並列化戦略とハードウェアトポロジによって変わる。
- テンソル並列、エキスパート並列、文書化されたプレフィル/デコードの分離プロファイルは、実際のワークロードに対してベンチマークが必要。
max-model-len、同時実行、メモリ使用率は、デフォルト値ではなく明示的なチューニングが必要。- K3 は稀に自前のパーサが想定しないツールコール形式を出力することがあるため、スキーマ検証とリトライ処理が推奨される。
1M トークンのコンテキストは自由に使えるのか？
いいえ。Moonshot は、長いコンテキストを使ったという理由だけでトークン単価の上位ティアを適用しませんが、長いプロンプトは入力トークンを消費し、プレフィル作業、KV キャッシュ需要、レイテンシ、同時実行の圧力を増加させます。最大値をデフォルトで有効化するのではなく、実際に提供するワークロードに合わせて max-model-len を設定してください。
アプリケーション互換性も重要です。Moonshot のKimi K3 API クイックスタートによると、K3 は常に推論を行い、reasoning_effort の値として low、high、max をサポートし、デフォルトは max です。これにより生成トークン量が増える可能性がありますが、オーバーヘッドはタスクや設定によって異なります。固定の倍率を仮定せず、独自の評価セットで推論と出力トークンを測定してください。マルチターンの会話やツールコールでは、可視の回答だけでなく、reasoning_content と tool_calls を含むアシスタントメッセージ全体を引き継いでください。
ホステッドエンドポイントはクラスター単位の作業の多くを取り除きますが、アプリケーションレベルの検証、リトライロジック、レイテンシ測定、マルチターン状態管理を取り除くわけではありません。
Kimi K3 API の料金はどのくらい？
2026年7月時点で、Moonshot はキャッシュヒットの入力 100 万トークンあたり $0.30、キャッシュミスの入力 100 万トークンあたり $3.00、出力 100 万トークンあたり $15.00を請求します。実効コストはプレフィックスキャッシュの再利用と出力長に大きく依存するため、見出しの入力単価だけを比較するのではなく、本番に近いリクエストで課金実績を測定してください。
Moonshot の公式 Kimi K3 料金ページには以下が記載されています。
| API 利用区分 | 公式の 100 万トークンあたりの価格 |
|---|---|
| キャッシュヒット入力 | $0.30 |
| キャッシュミス入力 | $3.00 |
| 出力 | $15.00 |
直接的なリクエストコストの計算式は次の通りです。
API コスト =
(cache-hit input tokens ÷ 1M × $0.30)
- (cache-miss input tokens ÷ 1M × $3.00)
- (output tokens ÷ 1M × $15.00)
例えば、30 万の入力トークンと 3 万の出力トークンを持つリクエストのコストは以下の通りです。
- すべての入力がキャッシュミスとして課金される場合は**$1.35**
- すべての入力がキャッシュヒット価格となる場合は**$0.54**
実際のワークロードは通常、この 2 つのケースの間に収まります。キャッシュ性能は、アプリケーションがどれだけ一貫して変更のないプレフィックスを再利用するか、およびプロバイダーのキャッシュ実装に依存します。
ホステッド価格はプロバイダーによっても異なります。2026年7月時点で、CometAPI は Kimi K3を入力 100 万トークンあたり $2.40、出力 100 万トークンあたり $12.00 と掲載しています。これは Moonshot の標準的なキャッシュミス単価（入力 $3.00、出力 $15.00）より 20% 低い設定です。しかし、これは普遍的な 20% の節約を意味しません。Moonshot はキャッシュヒットの入力に対しては 100 万トークンあたり $0.30 しか請求しないため、キャッシュヒット率の高いワークロードでは公式 API の方が安くなる可能性があります。
最新の価格情報としてはライブの CometAPI モデルページを使用し、費用の例についてはKimi K3 API 料金ガイドを参照してください。キャッシュヒット、推論出力、リトライ、受理タスク率を含む同一の評価セットで、両ルートの実際の課金実績を比較しましょう。
Kimi K3 のセルフホスティング費用はどのくらい？
Kimi K3 のセルフホスティングには普遍的な価格はありません。総コストは、クラスタ規模、契約条件、生産的稼働率、ネットワーキング、ストレージ、エンジニアリング、信頼性目標に依存します。8 基構成の計画シナリオでも、インフラだけで月額 $58,000 を超える可能性があり、Moonshot が推奨する 64 基以上の本番トポロジでは、さらに大きなコストモデルが必要になります。
完全な月次モデルを使用してください。
月次セルフホスティングコスト =
アクセラレータまたはクラスタ費用
- プラットフォームエンジニアリング
- 推論オペレーション
- ネットワーキングとストレージ
- オブザーバビリティとセキュリティ
- 冗長性とアイドル余力
8 基 GPU の参考インフラシナリオ
以下の表は、月 730 時間と 3 つの仮想的な時間単価を用いた、常時稼働の最小構成クラスタの例です。これらの数字は計画の入力であり、見積ではありません。また、Moonshot の 64 基以上という本番推奨を表すものでもありません。
| 想定クラスタ時間単価 | 月次インフラコスト | $1.35/件に等しいリクエスト数 | $0.54/件に等しいリクエスト数 |
|---|---|---|---|
| $80/hour | $58,400 | 43,300 | 108,100 |
| $120/hour | $87,600 | 64,900 | 162,200 |
| $160/hour | $116,800 | 86,500 | 216,300 |
エンジニアリング、監視、冗長性、ネットワーキング、アイドルキャパシティを加味すると、セルフホスティングの閾値は上がります。より大きな本番トポロジでは、さらに上がります。
稼働率は重要だが、普遍的な閾値はない
セルフホスティングが安くなる GPU 稼働率の普遍的なパーセンテージは存在しません。必要レベルは、測定されたスループット、ハードウェアコスト、レイテンシ目標、冗長性、ハードウェアが新規費用か既存資産かによって変わります。
代わりに生産的稼働率を追跡してください。
生産的稼働率 =
受理されたワークロードに費やしたクラスタ時間
÷ 供給したクラスタ総時間
高い稼働率であっても、リクエストがレイテンシや品質目標を外せば不十分です。逆に、ハードウェアが他のワークロードで既に拘束されている場合は、低い数値でも許容されることがあります。稼働率は TCO モデルの入力として用い、単独の意思決定ルールにしないでください。
最も有用な分母は生のリクエスト数ではなく、受理された同等の作業です。
損益分岐の受理タスク数 =
月次セルフホスティング総コスト
÷ 受理同等タスクあたりのホステッド API コスト
失敗、リトライ、レイテンシ違反、人によるレビュー、品質劣化を両側で含めてください。同じウェイトを使う 2 つのエンドポイントでも、アプリケーションの信頼性や品質目標を満たすかどうかで経済性は同等ではありません。
Kimi K3 ライセンスで許可されていることは？
カスタムの Kimi K3 License は、ソフトウェアおよびモデルウェイトの使用、複製、変更、ファインチューニング、デプロイ、配布、サブライセンス、販売に関して広範な権利を付与します。同時に、大規模な Model-as-a-Service 事業や大規模商用プロダクトに関わる条件も含まれます。
| ライセンス上の問い | 公開されている条件 |
|---|---|
| 企業はウェイトを利用・変更できるか？ | はい。ライセンス条件および適用法に従うことが前提 |
| 「Model as a Service」とは？ | 入力、パラメータ、学習データに対する実質的な制御を第三者に与える推論またはファインチューニング提供 |
| その定義から除外されるものは？ | 組み込み製品機能、他社ホストモデルへの単なる中継 |
| MaaS 合意が必要となるトリガーは？ | ライセンシーおよび関連会社の合算で、連続する 12 カ月間に $20M 超の収益を伴う MaaS 事業の運営 |
| 閾値超過時にはどうなる？ | ソフトウェアまたは派生物の商用利用前に Moonshot との別途合意が必要 |
| いつ可視のクレジット表記が必要？ | 月間 1 億 MAU 超または月間 $20M 超の収益を持つ商用製品/サービスは「Kimi K3」を目立つ形で表示 |
| 第2条・第3条の適用除外となる利用は？ | 社内利用、および Moonshot の公式プロダクトまたは認定推論パートナー経由のアクセス |
多くの社内デプロイや一般的な商用アプリケーションについては、ライセンスが既定で禁止しているわけではありません。モデルへの直接アクセスを販売する、モデル API を運用する、または上記の閾値に近づくチームは、正確な製品設計と企業構造について法務確認を行ってください。
「オープンソース」よりも「オープンウェイト」という表現が適切です。なぜなら利用は標準的な寛容ソフトウェアライセンスではなく、このカスタムライセンスにより規定されているためです。
API とセルフホストの Kimi K3：どちらを選ぶべき？
2026年においては、多くのチームにとってホステッド API アクセスが最初の一歩として適しています。需要、キャッシュ挙動、受理タスクあたりのコストがまだ不確実だからです。持続的な稼働率、データ制御要件、またはランタイムのカスタマイズが、同等の信頼できる本番デプロイの完全コストと比較して測定可能になった場合のみ、セルフホスティングを選びましょう。
ホステッド API を選ぶべきケース：
- トラフィックが新規、変動的、または予測が難しい。
- GPU 調達なしで本番アクセスが必要。
- 分散 MoE 推論の運用経験がない。
- 利用量が算出した損益分岐点を大きく下回る。
- ランタイム制御よりも、マネージドなスケーリング、更新、キャパシティが価値を持つ。
- プロバイダーのデータ取扱いとサービス条件が要件を満たす。
セルフホスティングを選ぶべきケース：
- 需要が持続的かつ予測可能で、クラスタを高稼働で保てる。
- 組織に分散 GPU インフラと推論エンジニアが既にいる。
- 制御されたデータ経路、専用環境、カスタム保持ポリシーが必須。
- モデルバージョン、スケジューリング、ランタイム設定、ファインチューニング済みウェイトを直接制御する必要がある。
- 測定されたホステッド費用が、同等の信頼できる内部デプロイの完全コストに近づく。
- 法務確認により、意図する利用が Kimi K3 License に適合すると確認できる。
ハイブリッドデプロイを検討すべきケース：
- ベースライン需要は予測可能だが、トラフィックのバーストが大きい。
- 自前キャパシティで平常時を処理し、API でオーバーフローを吸収する。
- メンテナンスやリージョン障害時のマネージドなフォールバックが必要。
- プロンプト、ツールスキーマ、受理基準、モデル挙動を両ルート間で可搬に保てる。
ハイブリッド戦略はルーティングと可観測性の複雑性を増すため、単なるアーキテクチャの好みではなく、測定されたキャパシティまたはレジリエンス上の課題を解くために採用すべきです。
API とセルフホスティングの損益分岐のテスト方法は？
同じ本番形状の評価セットをホステッドと自主管理の両ルートで実行し、生のトークン単価や GPU レンタルだけでなく、受理タスクあたりのコストで比較してください。信頼できるテストでは、少なくとも代表的な運用期間にわたり、キャッシュヒット、出力トークン、レイテンシ、リトライ、品質、同時実行、エンジニアリング工数、アイドルキャパシティ、障害復旧を測定する必要があります。
- 代表的な評価セットを作成する。実際のミックス（コーディング、長コンテキスト、ビジョン、ツールコール）をカバーする 30〜50 タスクを含める。
- 少なくとも 1 週間はホステッドの利用を測定する。入力トークン、キャッシュヒットトークン、出力トークン、レイテンシ、リトライ、エラー、受理タスク率を記録する。
- 提案するセルフホストのトポロジをテストする。意図するコンテキスト上限、同時実行、並列化、信頼性設定を用い、単一ユーザーのデモにしない。
- 完全な月次コストを算出する。クラスタ時間、エンジニアリング、可観測性、冗長性、ストレージ、ネットワーキング、セキュリティ、アイドル余力を含める。
- 受理タスクの経済性を比較する。品質、レイテンシ、信頼性が同等であることを確認してからコスト比較を行う。
- 障害シナリオを実行する。ノード喪失、デプロイのロールバック、キュー増加、長コンテキストのバースト、形式の不正なツールコールを試験する。
- 運用上の根拠が測定可能になったときにのみセルフホスティングを承認する。戦略的な制御が高コストを正当化することはあり得るが、そのトレードオフは明示的であるべき。
ホステッドのベースラインとしては、CometAPI クイックスタートが OpenAI 互換のルートを提供します。別のプロバイダーやセルフホストのエンドポイントをテストする際は、プロンプト、ツール、受理基準を変更せずに維持してください。
FAQ
Kimi K3 は単一 GPU で動作しますか？
公式のフルモデル提供ガイダンスの範囲では動作しません。vLLM レシピは、NVIDIA GB300 GPU 8 基または AMD MI355X/MI350X GPU 8 基から開始し、実運用トラフィックではマルチノードインフラを推奨しています。最終的なトポロジは、コンテキスト長、同時実行、レイテンシ、冗長性目標に依存します。
Kimi K3 のセルフホスティングにはどれくらいのストレージが必要ですか？
公開の Hugging Face リポジトリは約 1.56 TB です。ランタイムのメモリ要件はさらに高く、提供には量子化メタデータ、アクティベーション、KV キャッシュ、通信バッファ、同時実行の余裕が必要です。
Kimi K3 はオープンソースですか？
Kimi K3 は、カスタムの Kimi K3 License の下にあるオープンウェイトと表現するのが最も適切です。ウェイトは公開され、変更やデプロイが可能ですが、大規模 MaaS 事業者や非常に大規模な商用プロダクトには追加条件があります。
Kimi K3 のセルフホスティングは API アクセスより安いですか？
高く持続的な稼働率では安くなる可能性がありますが、普遍的な損益分岐点は存在しません。同等の信頼できる本番デプロイの完全な月次コストと、キャッシュ挙動、リトライ、レイテンシ、アイドルキャパシティを含む受理タスクあたりのホステッド費用を比較してください。
どの推論エンジンが Kimi K3 をサポートしていますか？
Moonshot は現時点で vLLM、SGLang、TokenSpeed を推奨しています。vLLM レシピが最も明確な公開ハードウェアのベースラインを提供しますが、いずれのエンジンもワークロード固有の検証が必要です。
インフラを購入する前にホステッドルートを試す
Kimi K3 のオープンウェイトにより、セルフホスティングは現実的な選択肢になりましたが、チェックポイントサイズと分散提供の要件により、これは日常的なモデルデプロイではなくインフラプロジェクトです。
固定の評価セットから始めてください。ホステッドエンドポイントで、トークン使用量、キャッシュ挙動、レイテンシ、リトライ、受理品質を測定します。その結果を、完全な月次コスト（GPU 代だけでなく）を用いて、負荷試験済みのセルフホストトポロジと比較してください。
CometAPI は、そのベースライン確立のために OpenAI 互換のルートを提供します。実装の詳細はHow to Use Kimi K3 API ガイド、移行手順はCometAPI クイックスタート、最新の提供状況と料金はライブのKimi K3 モデルページおよび料金ページを参照してください。