Kimi K3 vs K2:何が進化したか、今すぐ乗り換えるべきか

Moonshot の Kimi K3 が登場した瞬間、すでに K2 / K2.x を使っているチームの第一反応はほぼ同じでした。乗り換える価値はあるのか?答えは「無条件でアップグレード」ではなく、あなたのユースケースが K3 の新機能を実際に活かせるか、そしてより高い出力価格に耐えられるか次第です。以下で両世代の違いを並べて比較し、シーンごとに結論を出します。

一枚の表で両世代の違いを把握

項目	Kimi K2 / K2.x	Kimi K3
コンテキストウィンドウ	256K トークン	1M(1,048,576)トークン
視覚能力	なし / 外付け	ネイティブ視覚(画像 + 動画)
推論	K2-thinking の専用モデル	常時推論、reasoning_effort で制御
アーキテクチャ	MoE、約 1T 総パラメータ	MoE 2.8T、896 エキスパートから 16 を起動
アテンション	標準的な MoE アテンション	KDA + Attention Residuals
スケーリング効率	ベースライン	K2 の約 2.5×
出力価格(公式参考)	約 ¥8–16 / 1M	¥100 / 1M

K3 の強みはどこにあるのか

コンテキストが 256K から 1M へ。 これが最も直感的なアップグレードです。中規模コードベース全体、長文契約書一式、数十ページの PDF を一度のリクエストに丸ごと詰め込めるようになり、苦労してチャンク分割し RAG を組む必要がなくなります。長い一連のツール呼び出しを走らせ長い履歴を保持する長期エージェントでは、その差が特に顕著です。

ネイティブ視覚が一等市民に。 K2 の時代は画像を見るのに基本的に外付け OCR か別の視覚モデルを呼ぶ必要がありましたが、K3 は画像と動画を直接取り込むため、「デザインカンプを見てフロントエンドを書く」「ゲーム / CAD のスクリーンショットを見てコードを直す」といったタスクをネイティブにサポートします。視覚入力はオブジェクト配列を使い、base64 か ms:// のファイル参照で渡す必要があり、公開の画像 URL には対応していない点に注意してください。

推論はデフォルトで常時オン。 K2 で深い思考が欲しければ kimi-k2-thinking のような専用モデルに切り替える必要がありましたが、K3 は推論を主モデルに組み込み、reasoning_effort で強度を調整します(現状は max のみ)。複雑な推論や多段階の計画がそのまま使えます。

新アーキテクチャがもたらす効率。 2.8T の MoE に KDA(Kimi Delta Attention)+ Attention Residuals を組み合わせ、公式によれば全体のスケーリング効率は K2 の約 2.5 倍。つまり同じ計算予算でより経済的に訓練 / 推論でき、これこそがコンテキストを 1M まで引き上げる裏付けになっています。

代償:出力価格は明らかに高い

K3 はフラッグシップの位置づけで、価格もフラッグシップです。公式参考価格では 出力が ¥100 / 1M と高く、入力はキャッシュミス時 ¥20、ヒット時 ¥2。数元の出力価格だった K2 シリーズと比べると、純粋な大量処理のシーンではコスト差が大きくなります。ただし K3 は デフォルトでコンテキストキャッシュを有効化 しており、長い system prompt や固定文書を繰り返し呼ぶ際には入力を一割まで圧縮でき、長期エージェントはむしろ恩恵を受けます。価格は常に変動するため、発注前にリアルタイム価格を確認してください。GetModel 上の Kimi 全シリーズのリアルタイム単価は価格ページで確認できます。

シーン別の結論:どちらを使うべきか

K2 / K2.x を使い続ける場合:

• 純粋な大量処理・高並行の汎用タスク(分類、抽出、リライト、カスタマーサポート)で、能力の上限を極限まで求めない場合 —— K2 の単価は圧倒的に低い;
• コンテキストが 256K を超えることがほとんどなく、視覚も不要;
• コストが厳しい制約になっている。

K3 にアップグレードする場合:

• コードベース全体 / 超長文ドキュメント を一度に飲み込む必要があり、256K では手狭になっている;
• 画像を見てコードを書く / マルチモーダル のニーズがある(フロントエンド、ゲーム、CAD、デザインカンプの再現);
• 長期エージェント を走らせ、強い推論と長い履歴での安定性が必要;
• prompt の繰り返しが多く、キャッシュ割引が効いてフラッグシップ価格を薄められる。

現実的な折衷案:一つの集約ゲートウェイに K2 と K3 を同時に接続 し、安いタスクは K2、難しいタスクは K3 に流し、コード上は model フィールドを変えるだけで切り替える。GetModel のような集約インターフェースを使えば、一つの Key で両世代の間を自由に配分でき、ついでに GPT や Claude とも比較できます。

移行のポイント(K2 → K3)

本当にアップグレードするなら、コード上で三つの落とし穴を避けましょう:

• thinking パラメータを削除 —— K3 は代わりに reasoning_effort を使う(現状は max のみ);
• マルチターン / ツール呼び出しでは 完全な assistant message をそのまま返送 —— content だけを残さない;
• コンテキスト予算は 4 倍に増えたが、無条件で満杯にしないこと —— 長いほど高く、遅くなる。

完全な接続コード、curl / Python の例、エラーの切り分けは、Kimi K3 API 接続チュートリアルを参照してください。K2、K3、他社のモデルを一つのコードベースで同時に使いたいなら、GetModel コンソールで Key を取得するのが最も手軽です。