Kimi K3 のweightsが公開 — 2.8T MoEを自前で動かす条件（MXFP4・約1.4TB）

Kimi K3 のweightsは公開されましたが、個人のGPUやMacでは動きません。 2.8兆パラメータをネイティブのMXFP4（4bit）で持っても重みだけで約1.4TB、KVキャッシュと活性化の余裕を見ると実質的に80GB級GPUを数十基まとめたクラスタが必要です。「オープンウェイト＝手元で動かせる」が成り立たないサイズ帯であり、現実的な選択肢は API・day-0のホスティング事業者・自社クラスタの3つに絞られます。この記事では、何が公開されたのか、ハードウェアの計算、推論スタックの前提、そして小型モデルとの棲み分けを整理します。

モデルそのものの位置づけ（アーキテクチャ・ベンチマーク・API料金・K2との違い）はKimi K3とは — 2.8T MoEの実力・API料金・ローカル実行の現実で先に扱っています。本記事は weights 公開を受けた「実際に自前で動かせるのか」に絞った続編です。

Moonshot AI は、事前に告知していた2026年7月27日の目標より前倒しで、2026年7月26日（米東部時間の夜／日本時間7月27日朝）に Kimi K3 のweightsを無償公開しました。APIの提供開始（7月16日）から約10日遅れのリリースになります。公開と同時に Together AI・Modal などが day-0 のホスティング提供を発表しており、weights を落とさずに叩ける経路が初日から用意されました。

注意点として、MXFP4は後付けの量子化ではなく、SFT段階からの量子化認識学習（QAT）で作られていると説明されています。つまり1.4TBが「劣化版」ではなくネイティブの配布形態であり、これをさらに落として小さくするという発想が素直には成立しません。ダウンロードサイズについては公開直後の情報で数値の揺れがあるため（分割配布やシャード構成の数え方の差と思われます）、実際の取得前に配布ページのファイル一覧で確認してください。

重み1.4TBは下限であって、実運用にはそのままでは足りません。加算されるのは主に次の3つです。

- ブロックスケール等のメタデータ: MXFP4はブロック単位のスケール係数を持つため、4bit×パラメータ数の計算値より実サイズは増える
- KVキャッシュ: 1Mコンテキストを謳うモデルで、長文を実際に流すと支配的な要因になる。同時実行数に比例して膨らむ
- 活性化とランタイムバッファ: MXFP8の活性化、通信バッファ、フラグメンテーションの余裕

Moonshot 側は分散推論について、エキスパート並列（EP）とテンソル並列（TP）を組み合わせた64アクセラレータ以上のスーパーノード構成を推奨しています。単に総メモリが1.4TBあればよいという話ではなく、896エキスパートのルーティングに耐えるノード間帯域（InfiniBand/NVLink級）が前提になります。ここが、同じ「オープンウェイト」でもDeepSeek V4やGLM-5.2のような数百B級モデルと決定的に違う点です。

「MoEだからアクティブは50B、それなら動くのでは」という期待は成立しません。MoEでアクティブなのは計算量であって、メモリではないからです。どのトークンがどのエキスパートに飛ぶかは事前に分からないため、896エキスパート全体を即座にアクセスできる場所に置いておく必要があります。使わないエキスパートをディスクに置くオフロード構成は技術的には可能ですが、SSDからの読み出しがトークンごとに発生し、実用的な速度にはなりません。

M3 Ultra の512GB統合メモリ機であっても、1.4TBの重みには届きません。手元のマシンでローカルLLMを動かしたい目的なら、K3は対象外と割り切って、7B〜70B帯のモデルをGGUF量子化で回すほうが目的に合います。必要VRAMの見積もりはVRAM計算ツールで確認できます。

K3は新アーキテクチャ（KDA＋Attention Residuals）を採用しており、weightsを読み込めることと、K3として正しく高速に動くことは別問題です。Moonshot は prefill キャッシュを含む KDA 実装を vLLM コミュニティに提供し、weights と併せて出す形をとっています。

- vLLM: 公式が実装を寄せている本命。MoE対応のスケジューリングと prefill キャッシュが前提
- SGLang: MoE対応の実績があり、エキスパート並列の構成で候補になる
- TensorRT-LLM: NVIDIA環境で最適化を詰める場合の選択肢。ビルドの手間は大きい
- llama.cpp / Ollama / LM Studio: 単機を前提とした設計であり、この規模のマルチノード推論の対象外

実際に立ち上げる場合は、まず使う推論エンジンのバージョンがKDAに対応しているかを確認するところから始めてください。対応前のバージョンでは、読み込めても出力品質が壊れるか、そもそもルーティングで落ちます。

weights公開の最大の意味は「誰でも家で動かせる」ことではなく、「必要ならデータを外に出さずに動かせる経路が理論上ある」ことです。 中国系モデルのAPI利用でデータ経路が懸念になる組織にとって、自社クラスタという選択肢が存在すること自体が価値を持ちます。ただしその実行には8ノード級の設備と運用体制が要るため、実際に取れるのは相応の規模の組織に限られます。

クラウドGPUで時間課金する場合も、H100 80GB を64基確保し続ける単価を考えると、常時稼働の負荷がない限りAPIのほうが安く収まります。自前ホストが経済的に成立するのは、トークン消費量が大きく、かつ稼働率を高く保てる場合に限られる、というのが素直な結論です。

- ライセンス本文を読む: 「修正MIT系」と報じられていても、商用利用・再配布・出力の扱いは配布物のLICENSEが正
- ベンチマークは公表値: GPQA-Diamond 93.5、SWE Marathon 42.0 などの数値は開発元の公表ベース。自社タスクでの評価は別途必要
- 1Mコンテキストのコスト: 長文を投げるほどKVキャッシュとレイテンシが効く。実運用の入力長で計測する
- 公開直後の数値は動く: サイズ・推奨構成・対応ランタイムは、コミュニティ検証が進むと更新される

Kimi K3 の weights 公開は、史上最大級のオープンウェイトモデルが誰でも取得できる状態になったという意味で節目です。一方で、その1.4TBを実際に動かせるのは8ノード級の設備を持てる組織に限られ、多くの開発者にとっての実務的な入口は依然としてAPIかホスティング事業者です。

「ローカルで動かす」という目的でモデルを探しているなら、K3ではなく手元のVRAMに収まる帯のモデルを選ぶほうが確実に目的に届きます。K3の価値は、必要になったときにデータを外に出さない経路を選べる、という選択肢が残ることのほうにあります。数値と推奨構成は公開直後で動きうるため、導入判断の際は配布ページと推論エンジンのリリースノートを直接確認してください。