Kimi K3.1 Pro 必要スペック早見表

Kimi K3.1 Proは、Moonshot AIが2026年10月23日（米国時間）に発表した約2.8T（2.8兆）パラメータのMoE（Mixture of Experts）モデルで、7月に公開されたKimi K3のポストトレーニング強化版である。自前でホストする場合、4bit量子化でも重みだけで約1.4TB（推定）⏳重み公開待ち が必要で、実質的に複数ノードのGPUクラスタが前提になるため、ほとんどの利用者にとって現実的な選択肢は公式APIであり、料金は入力$2／出力$10（100万トークンあたり）である。

この記事で ⏳重み公開待ち と付けた値は、K3の公開値をもとにした推定であり、11月4日までに予定されている重みとモデルカードの公開後に確定値へ差し替える。一方、API料金やMoonshot自身が報告したベンチマークは公式発表の値で、マーカーは付けていない。前世代の整理は Kimi K3とは と Kimi K3 のweights公開と自前ホストの条件 も参照してほしい。

上記はパラメータ数2.8Tから算出した理論値で、実際にはKVキャッシュ、ルーティング、バッファ、画像エンコーダの分が加わる。

手元のGPU・Macで動くかをすぐ確かめたい場合は、モデル・量子化・コンテキスト長を選ぶだけで必要VRAMを試算できるVRAM計算ツール（無料・登録不要）も用意している。Kimi K3.1 Proもモデル一覧から選択できる（数値は重み公開前の推定）。

発表と同時に、Kimiアプリ、Kimi Code、APIですぐ利用できる。APIにはゼロデータ保持（Zero Data Retention）オプションがあり、無料プランは利用量に制限がある。Highspeedの利用にはKimi CodeのProプラン以上、100万トークンのコンテキストもKimi CodeではProプラン以上が条件である。

K3.1 Proは、K3に対してポストトレーニングの計算量を大幅に増やし、コーディング、ナレッジワーク、エージェントタスクに焦点を当てた強化学習を追加したものとされる。なお、Moonshotはオープン公開に先立ち、悪用を抑えるためサイバー攻撃関連のデータを学習から除外した。除外前は同テストで90.5%だったが、公開版は81.0%である。ここで重要なのは、K3のリポジトリとK3.1 Proのチェックポイントは別物であり、K3のファイルは流用できない点である。

ベンチマークの多くはMoonshot自身の計測値で、独立した検証はArtificial Analysisの数値が中心である。サイバー関連のベンチマークはClaude Opus 5.5やGPT-6 Astraに及ばない。また、VentureBeatは、一部のインフルエンサーが有償関係を開示せずにこのモデルを宣伝していたという指摘を報じている。こうした点からも、導入判断には自社の業務データでの検証と、独立ベンチマークの参照が欠かせない。出力速度は現時点でKimi API上で毎秒約57.5トークン、最初のトークンまで約3.07秒（10月26日時点）である。

単位は100万トークンあたり、Kimi公式API。

K3.1 ProはK3より約1/3安い。Artificial Analysisの試算では、ブレンド価格（入力・キャッシュ・出力を7:2:1とした場合）が100万トークンあたり$1.54、Intelligence Indexの1タスクあたりの費用が$2.11である。ただしこのモデルは冗長で、同指標で出力が約1億5,000万トークンと、中央値の約8,700万トークンを大きく上回る。出力が多い用途では、表の単価から想像するより実コストが膨らむ点に注意したい。Highspeedは入出力とも2倍の単価で、Moonshotは2〜3倍高速としている。対話型のコーディング支援など待ち時間が体験に直結する用途に限定し、バッチ処理は通常版を使うのが妥当である。

MoEモデルは、トークンごとに896個のうち16個のエキスパートしか使わないため、計算量はアクティブパラメータ数で決まる。しかし、どのエキスパートが選ばれるかは入力次第なので、メモリには全エキスパートを常駐させる必要がある。つまりアクティブパラメータの少なさは計算コストを下げるが、必要なメモリは減らさない。2.8Tパラメータを4bit（0.5バイト）で持てば約1.4TBになる、というのが推定の根拠である。K3は量子化を考慮した学習（QAT）でMXFP4重みを前提にしており、約1.4TBの配布サイズもこの形式による。K3.1 Proが同じMXFP4形式で配布されるかは ⏳重み公開待ち であり、別形式なら実際のサイズは大きく変わる。

MoonshotはK3で、エキスパート並列とテンソル並列を組み合わせた64基以上のアクセラレータからなる「スーパーノード」構成を推奨し、InfiniBandやNVLink級の相互接続を前提としていた。K3.1 Proでも同様と見るのが自然だが、これも ⏳重み公開待ち である。

M3 Ultraの512GBメモリでも、1.4TB（推定）⏳重み公開待ち の4bit重みは載らない。512GBのMacを2台つないだ合計1TBでも、4bitには足りない。2bit相当（約700GB）なら2台に収まる可能性はあるが、その品質や速度は未知であり、実用になるかは公開後の検証を待つ必要がある。現時点では、MacでK3.1 Proをローカル実行する現実的な道はないと考えるのが妥当である。

K3の際は、MoonshotがKDAの実装（prefillキャッシュを含む）をvLLMコミュニティに提供し、重みと併せて出す形をとった。K3.1 Proも同じ注意機構を使うなら同様に動く可能性が高いが、対応バージョンの確認が必須である ⏳重み公開待ち。KDAに対応していないエンジンでは、起動はしても出力が不正になる危険がある。また、K3のチェックポイントとK3.1 Proのチェックポイントは別物なので、K3用に用意した変換済みファイルや設定をそのまま使い回すことはできない。公開直後はエンジン側の対応が追いつかない場合もあるため、リリースノートとイシューを確認してから構成を決めたい。

自前ホストを選ぶ最大の理由はデータ主権であり、コストではない。64基級のGPUクラスタの調達・運用費は、API利用料と比べて桁違いになりやすい。データを外部に出せない事情がなければ、まずAPIで品質と実コストを検証し、そのうえで自前運用の必要性を判断する順序が現実的である。

ローカルで動かすことが目的なら、手元のVRAMに収まるモデルを選ぶのが近道である。量子化の選び方は GGUF量子化の選び方 にまとめた。参考として、WASTE推論エンジン はSSDからのストリーミングでK3を29GBのRAMで動かした実験的な取り組みだが、速度は非常に遅く、本番利用には向かない。K3.1 Proで同様に動くかは ⏳重み公開待ち である。

- ライセンス全文（商用利用の可否、再配布、利用制限の条件）
- アクティブパラメータ数（約104Bか、K3並みの約50B相当か）
- 重みの形式とファイルサイズ（MXFP4か、他の形式か）
- vLLM・SGLangのKDA対応バージョン
- 公開初日にホスティングを提供するプロバイダの顔ぶれ
- 画像エンコーダのサイズと、画像入力時の追加メモリ

- ロード時にOOM（メモリ不足）になる場合: 重みが合計メモリに収まっているかを先に確認する。KVキャッシュと画像エンコーダの分の余裕も必要で、コンテキスト長を短くして再試行する
- KDA非対応のエンジンで出力がおかしい場合: エンジンのバージョンを確認し、KDA対応版へ更新する。K3用の設定やチェックポイントは流用しない
- ノード間帯域が足りず遅い場合: エキスパート並列の通信がボトルネックになる。InfiniBandやNVLink級の相互接続を前提に構成を見直す
- 冗長な出力でコストが膨らむ場合: 出力長の上限を設け、プロンプトで簡潔な回答を指示する。出力トークン数を計測して実コストを把握する
- 無料プランで制限に当たる場合: 利用量の上限に達している。Highspeedや100万トークンのコンテキストはKimi CodeのProプラン以上が必要

社内で中国系モデルのAPIを使う際のデータの扱いや、オープンウェイトモデルの自社運用を検討する場合は、AIコンサルティングでも相談を受け付けている。