HiAPI
kimi-k3 模型详情页顶部 21:9 宽幅 Hero 图:左侧柔光留白,右侧虹彩玻璃文档层叠延展,kimi-k3 名以发光立体字融入其中,奶油、冰蓝与珊瑚色渐变。

Moonshot AI

Kimi K3

kimi-k3

Moonshot AI のオープンウェイトのフロンティアモデル。テキスト・画像・動画の理解をネイティブにサポートし、100 万トークンのコンテキストを持ち、長期的なコーディングやツール呼び出しの反復を得意とする

kimi-k3
コンテキスト長
1,000,000
入力
最大出力
131,072 トークン
リリース日
2026-07-17
ストリーミング 構造化 JSON

料金

kimi-k3 /1M tokens

仕様 単価
入力 $2.320
キャッシュ入力 $0.232
出力 $11.600

概要

位置づけ概要

Kimi K3 は Moonshot AI が提供するオープンウェイトの推論モデルで、長距離コーディング、ナレッジワーク、複雑な推論を主眼としています。テキスト・画像・動画理解をネイティブにサポートし、コンテキストウィンドウは 100 万トークンに達します。大規模なコードリポジトリでのファイル横断的な特定と修正、ログやテストフィードバックに基づく複数ターンの反復、長文ドキュメント分析など、継続的なコンテキストを必要とするテキスト生成タスクに適しています。純粋なテキスト出力で長いコンテキストと多段階推論の作業を処理したい開発者は、主力候補として採用できます。

主な特長

  • 100 万トークンの長コンテキスト——1 回の呼び出しで超長文ドキュメントや大規模コードベースの断片を収容でき、ファイル横断タスクでの分割・結合を削減します。
  • ネイティブなマルチモーダル入力——テキスト・画像・動画を同一モデル内で統一的に処理し、外部の視覚モジュールを必要としません。
  • 長距離タスク向けの反復能力——ツール呼び出しやログ・テスト結果・実行フィードバックに基づく繰り返しのデバッグを重視し、多段階のエージェントフローに適しています。
  • 高スパース MoE アーキテクチャ——896 個のエキスパートのうち 16 個を活性化し、公式によれば全体の拡張効率は Kimi K2 比で約 2.5 倍に向上しています。

能力の説明

長コンテキストのテキスト処理:100 万トークンのコンテキストウィンドウにより、長文ドキュメントの通読、ファイル横断的なコード理解、複数ターンタスクでの事前情報の継続保持が可能で、入力の繰り返し切り詰めに伴うエンジニアリングコストを削減します。

マルチモーダルコンテンツの理解:画像と動画の入力をネイティブにサポートし、スクリーンショット、グラフ、動画素材を組み合わせてテキストの結論を生成できます。視覚素材から情報を抽出するテキスト出力タスクに適しています。

ツール呼び出しと反復デバッグ:長距離タスク向けに設計され、多段階のツール呼び出しをサポートし、ログ・テスト・実行フィードバックに基づいて後続の動作を調整できるため、自律型エージェントのワークフロー構築に適しています。

構造化されたナレッジワークの出力:詳細な調査レポート、インタラクティブな可視化、ダッシュボードなどのエンドツーエンドの成果物を生成でき、出力はテキスト形式であるため、下流でのレンダリングや二次加工が容易です。

適用シーン

  • 大規模コードベースを保守する開発者——リポジトリの複数ファイルと要件記述を入力し、リファクタリング方案とファイル横断的な修正提案を生成して、コミット前のコードレビューや移行計画に活用します。
  • エージェントワークフローを構築するバックエンドチーム——タスク目標とツール一覧を入力し、多段階の呼び出し計画を生成して実行フィードバックに基づき反復し、自動運用や開発支援プロセスに活用します。
  • 長文ドキュメント分析を必要とするナレッジワーカー——契約書やレポートなどの長文を入力し、構造化された要約と要点抽出を生成して、社内ナレッジベースの整理や意思決定支援に活用します。
  • 画像とテキストが混在する素材を扱うプロダクトチーム——スクリーンショット、グラフ、動画クリップを入力し、説明テキストと分析結論を生成して、プロダクトドキュメントやコンテンツ運用に活用します。

制限と選定のアドバイス

モデルのパラメータ規模は 2.8T に達し、推論演算能力と応答遅延に対して高い要件があるため、低遅延・高頻度・軽量な単純テキストタスクには適していません。現時点の接続側では出力タイプがテキストであることのみが示されており、マルチモーダル入力の具体的なインターフェース形態は実際のパラメータサポートに準じる必要があります。100 万級のコンテキストの有効利用率は検索とアテンションの挙動に影響されるため、長文ドキュメントのタスクではまず小規模サンプルで検証することを推奨します。短いコンテキストと低コストの推論のみが必要なタスクでは、より小さなモデルを優先的に検討できます。

  • Kimi K3 の Low、High、Max はどう選べばよいですか?

    日常的な抽出、書き換え、短い質疑応答ではまず low を試してください。多段階の分析が必要な場合は high を試してください。難しい問題や複雑なコードタスクでは、さらに max の効果を比較してください。reasoning_effort のデフォルトは max で、low、high、max の3段階のみが提供され、medium や none はありません。より高い段階ではより多くの思考 Token が生成され、待ち時間が長くなる可能性があるため、回答品質と usage を踏まえて選択してください。

  • 思考の無効化と温度調整のスイッチがないのはなぜですか?

    Kimi K3 は現在の接続では常に思考が有効になっており、コストを下げるにはまず low を試すべきで、thinking.type=disabled を渡すべきではありません。このページでは thinking、temperature、top_p を送信しません。他のモデルから移行する場合も、これらの制御フィールドを削除し、トップレベルの reasoning_effort でレベルを選択してください。

  • 回答が短いのに、なぜ依然として多くの出力Token費用がかかるのですか?

    モデルが生成する思考内容も出力Tokenとして課金されるため、最終回答の文字数は総出力量を表すものではありません。usage.completion_tokens には既に思考Tokenが含まれています。completion_tokens_details.reasoning_tokens が返される場合、それはその内訳であり、二重に加算しないでください。費用は通常入力、キャッシュ読み取り、出力の3項目ごとに計算し、各項目のToken数を100万で割り、このページの対応する米ドル単価を掛けます。

  • マルチターン対話で最終回答だけを保存してもよいですか?

    推奨されません。次のターンの messages は必要な履歴を順番に含めて返す必要があり、API が返した完全な assistant メッセージを保持してください。これには content、返された reasoning_content、および存在する可能性がある tool_calls が含まれます。最終的なテキストだけを保存すると、Kimi が思考を継続したりツールを続行したりするために必要なコンテキストが失われます。このページの Playground は返された思考内容を保持します。

同タイプ