メインコンテンツへスキップ
Kimi K3は利用可能だが、現時点では自己ホスティングはできない。Moonshot AIは17月2026日にホスティング型モデルを公開しており、ダウンロード可能な重みデータは27月中にリリースされる予定だ。それまでは、ローカル環境で利用するためにはインストールコマンドではなく計算処理が必要となる。本記事ではその計算方法を説明しており、Kimi K3モデルページでは利用可能性の変化に応じてローカル環境でKimi K3を実行できるかどうかが記載されている。 The headline conclusion: 7 or 8 DGX Sparks cannot hold K3’s native weights. K3 has 2.8T total parameters with ~50B active per token through MoE routing (16 of 896 experts). Eight Sparks provide 1 TB of unified memory. The 2.8T total parameters require about 1.4 TB at a theoretical 4-bit weight-only floor, before the model-format scales and every other part of inference.

現時点で確認済みの事項と未確定事項

この区別は重要です。3はオープンモデルと表記されることもありますが、将来的に重みデータが公開されるという約束と、現時点でダウンロード可能な重みデータは別物です。

What changed from Kimi K2

K3は、K2が持っていた1兆パラメーターから2.8兆パラメーターへと規模を拡大し、コンテキストの長さを256Kトークンから1Mトークンへと増加させます。さらにアーキテクチャも四つの重要な点で変更されています。

Kimi Delta Attentionは長いシーケンスの処理にも対応

Kimi Delta Attention(KDA)はKimi Linearファミリーに属する線形アテンション方式です。このハイブリッド型アーキテクチャにより各レイヤーで完全な二次関数的アテンション処理を行う必要がなくなります。特にサーバーが最初のトークン生成前に長大なプロンプトを読み込む際に効果を発揮します。 KDAは単なる速度向上用の設定項目ではありません。対応するカーネルやキャッシュ仕様も必要となります。Moonshot社によれば従来のプレフィックスキャッシュ方式はKDAにそのまま適用できず、同社が開発したvLLM用プリフィルキャッシュ機能は重みデータと共に提供される予定です。したがって汎用トランスフォーマーモデルの重みを読み込めるランタイムでも自動的に3と互換性があるとは限りません。

アテンション・リザイダルは深層ネットワーク内で情報を適切にルーティングする

Standard PreNorm residual connections repeatedly add layer outputs with fixed unit weights. Attention Residuals let a layer attend over preceding representations and select what to reuse. The Attention Residuals paper describes a block variant that reduces memory and pipeline-communication overhead while keeping most of the gain. これは深層方向のルーティング処理であり、トークン間のアテンションとは別物だ。KDAがトークン位置間の相互作用を決定し、AttnResがどの過去のレイヤー表現が有用かを判定する。

スタブル・ラテントMoEによりスパース性が向上する

K3 uses Stable LatentMoE and routes 16 of 896 experts. Sparse activation cuts per-token computation relative to a dense 2.8T model. It does not cut the stored checkpoint to the active-expert size: all experts still need to be resident across the cluster. この規模になると、エキスパートの配置や負荷分散がスループットに大きく影響する。ムーンショットではクォンタイル・バランシングや完全に均一なエキスパート並列学習手法も提案しているが、実装詳細は技術レポートで未公開だ。

QATはデプロイ前から実施される

ムーンショットによれば、MXFP4重みおよびMXFP8活性化値を用い、教師ありファインチューニング段階から量子化対応学習が行われた。これはリリース後に適用されるコミュニティ製量子化手法ではない。本モデルはサービス提供時の精度水準に耐えうるよう訓練されたのだ。 MXFP4は4ビット精度で値を保存し、共通のブロックスケール情報も保持する。したがって下記の4ビット計算結果は厳密なチェックポイント予測値ではなく、あくまで下限値にすぎない。

DGX Sparkにおけるメモリ計算方法

NVIDIAによれば、DGX Sparkでは 128 GBのLPDDR5x統合メモリ が利用可能だ。このメモリはGPUとCPUで共有される。これは重み用の128 GB分のメモリと別途システムRAMが存在するという仕様ではない。 At exactly four bits per parameter:
つまりK3の実質的な使用可能メモリ量は 1.4 TB 程度、すなわち約 1.27 TiB となります。さらに以下の要素も加算する必要があります:
  • MXFP4ブロックのスケーリング情報およびテンソルメタデータ
  • ランタイム時の割り当て用メモリおよび通信用バッファ
  • 活性化値の保存用メモリおよび一時作業用ワークスペース
  • 選択されたコンテキストに必要なKVキャッシュまたは再帰的状態情報
  • マルチモーダルリクエスト用のビジョンエンコーダ状態情報
  • DGX OSおよびサービングプロセスが利用するメモリ量

スパークカウントテーブル

Fourteen or sixteen is not a recommendation to buy that many Sparks. It only shows where aggregate capacity stops being obviously impossible. NVIDIA currently documents production-style Spark scaling through four nodes, and Moonshot recommends K3 on a supernode with 64 or more accelerators.

なぜ合計メモリ量だけでは不十分なのか

仮に16-Sparkクラスターが存在したとしても、三つの実用的な問題に直面することになる。

サポートされるトポロジーの数は四つまでです

NVIDIA’s current multi-node guidance supports up to four DGX Spark nodes. It positions that 512 GB cluster for models up to about 700B parameters. K3 is four times that parameter count. NVIDIA publishes two-node, three-node ring, and four-node switched examples, not a 14- or 16-node K3 recipe.

LLM推論処理は常に同期化が行われる

各Sparkユニットは273ギガバイト毎秒のローカルメモリ帯域幅と200ギガビットイーサネットのConnectX-7ネットワークインターフェースを備えています。ただし200ギガビットのリンクではプロトコルオーバーヘッドを除いて最大でも25ギガバイト毎秒程度の転送しかできず、ローカルメモリ帯域幅に比べて著しく低い数値となります。 分散型LLM推論ではレイヤーごとに処理が行われ、部分的な結果が繰り返し交換されます。NVIDIAはこのような細かな通信処理がノード数増加に伴いスケーリング効率を低下させると明確に警告しています。ノード数を増やせば処理能力は向上しますが、生成される各トークンがより大規模な通信ネットワークを待機する状況も生じ得ます。

K3はスーパーノード構成を想定している

Moonshot社では64個以上のアクセラレータを備えたスーパーノードを推奨しており、これにより高度な並列処理が広帯域通信環境下で実行可能となります。この推奨事項は単にファイル容量が収まるかどうかではなく、スループットやトポロジー構成に関するものです。 Sparkユニットはクライアント開発やプロンプト作成、ツールスキーマ設計、小規模なローカルモデルの運用にも有用です。ただしK3推論処理用の本格的なプラットフォームとしては想定されていません。

Moonshot社のベンチマーク表の読み方

Moonshot社の報告によれば、コーディング、エージェント型ワークフロー、推論処理、画像認識といった分野で優れた初期性能が確認されています。代表的なK3のスコア(max)は以下の通りです: ここに記載されているのは ベンダー側が報告した結果 であり、独立した検証結果ではありません。Moonshot自身の注釈にもあるように、各モデルは必ずしも同一のエージェント用テスト環境で評価されていません。例えば K3 では Kimi Code が使用され、別のモデルでは Claude Code が用いられ、GPT系モデルでは Codex が利用されている可能性もあります。テスト環境の品質やツールのポリシー、コンテキストの圧縮処理、フォールバック挙動などがエージェントベンチマークの結果に大きく影響するのです。 実際の解釈としては、K3 は本格的にテストする価値があるほど競争力があると見なせますが、公開された情報だけでは実際の実行環境で同様の結果が得られるかどうかは証明されていません。今後公開される重みデータやプロンプト、テスト環境の詳細、第三者による評価結果を待つべきです。

API behavior is not drop-in K2

K3 は現在 Moonshotが提供する OpenAI互換のチャット補完 API上で kimi-k3 として利用可能ですが、K2 の設定と完全に同じではありません。思考処理機能は常に有効化されており、reasoning_effort が thinking パラメータの代わりとなり、ストリーミング処理では reasoning_content と content が分離されます。また複数回の対話を再現する際にはアシスタントからのメッセージ全体を維持する必要があります。APIのテストや自前の実行環境の検証を行う際には、Kimi K3 モデルページ に記載されているプロトコル上の詳細事項を必ず確認してください。

現時点で知られている制限事項

Moonshotは主に以下の三つの制限を挙げています:
  1. 履歴情報の依存性 K3 は思考処理の履歴情報が維持されることを前提としています。対話履歴の再現が正しく行われない場合やセッション中にモデルが切り替わると出力結果が不安定になる恐れがあります。
  2. 過剰な能動性 長時間にわたるタスクで曖昧な指示が含まれる場合、モデルが予期せぬ判断を下す可能性があります。そのため明確な許可設定や停止条件、編集範囲の指定が不可欠です。
  3. 体験面での差異 Moonshotによれば、個別のベンチマークでは競争力があるものの、全体的なユーザー体験の面では K3 は依然として有力な商用モデルに及ばない状態です。
こうした注意点は特にコーディング用エージェントにおいて重要です。AGENTS.md 内に具体的な制限範囲を設定し、破壊的処理や外部リソースへのアクセスには必ず承認を求め、長時間の自動実行を信頼する前にセッション圧縮処理のテストも行うべきです。

重みデータが公開されるまでの対応策

Moonshot自体が提供するアーティファクトを待ち、類似した名称のコミュニティリポジトリは利用しないようにしてください。その後で実際のチェックポイントマニフェストに基づき再計算を行い、それから購入を検討するべきです。Kimi K3モデルページには、公式アーティファクトの検証、対応クラスターでのサービス実装、そしてTokiosを通じたデプロイ接続といった段階的な準備手順が記載されています。当面は、Kimi K3の代替として実行可能なモデルが現時点でご使用のハードウェアに最適な選択肢となります。

主要な情報源

Kimi K3

公式ウェイトが公開され次第、K3の利用可否、必要なハードウェア要件、およびTokios経由での導入手順を確認してください。

Kimiシリーズの各モデル

Compare K3 with the downloadable K2.6 and K2.7-Code you can self-host today.

What to run instead of K3

ご使用のハードウェアに最適なコーディング用および汎用モデルを、各デプロイガイドと共にご紹介します。

DGX Spark

Spark環境に適合するモデルを実行し、プライベートなTokiosエンドポイントを構築できます。

モデルの提供とスケーリング

テンサー並列化、パイプライン並列化、エキスパート並列化 — これらがスーパーノード構成の要件の根底にある概念です。

よくある質問

About 1.4 TB at the native MXFP4 precision (4 bits per parameter, 2.8T parameters), before block scales, runtime buffers, activations, and KV cache. In practice, a serving cluster needs significantly more — Moonshot recommends 64+ accelerators in a supernode configuration.
最低限では、11台のSparkで1.4 TB相当の重みデータを保持できます(11掛ける128GBで1,408GBとなります)。ただし、この場合OSやCUDAのオーバーヘッド、KVキャッシュ、推論状態用のメモリは確保できません。現実的な見積もりとしては14台から16台程度が必要です。ただしNVIDIAが公開しているSparkクラスターの構成例は最大で4ノード(総容量512GB)までであり、K3をSpark上で動作させるための構成も現時点ではサポートされていません。
MoEのスパースな活性化処理はトークンごとの計算量を削減するだけで、保存されるチェックポイントのサイズには影響しません。サービングクラスター全体で896個分の全エキスパートの重みデータが常に保持される必要があります。実際の推論速度(トークンごとのFLOPs)は約50B個の活性化パラメータによって決まりますが、メモリ要件は合計2.8兆パラメータの規模によって決定されます。
Moonshot社では、64個以上のアクセラレーターを備えたスーパーノードの利用を推奨しています。これは専門的な並列処理が効率的に行えるよう高帯域幅の相互接続が可能な環境です。一般向けGPU(24ギガバイト)、プロシューマー向け統合メモリ(128から192ギガバイト)、さらには4ノード規模のSparkクラスター(512ギガバイト)ですら、K3の要件を満たせるレベルには達していません。
Moonshot社は27月2026日までにダウンロード可能なモデル重みを公開すると約束している。ただしライセンスやモデルカード、チェックポイントのマニフェスト、自己ホスティング手順などはまだ公開されていない。vLLM社によれば、Moonshot社からKDAプレフィックスキャッシュ機能に関する貢献が寄せられており、これが0日に正式リリースと共に実装される予定だ。