Kimi K3 API：1M コンテキストがモデルルーティングを変える理由

Kimi K3 は 2.8T パラメータ、1M コンテキスト、スパース MoE、API アクセスを兼ね備える。料金、キャッシング、ルーティング、デプロイのトレードオフを解説します。

Kimi K3 は、見出しになるべくして生まれた 2 つの数字を引っ提げて登場した：2.8 兆パラメータと 100 万トークンのコンテキストウィンドウだ。

しかし本番チームにとって、より有用な数字は 10 である。

Moonshot の公式 Kimi K3 API では、キャッシュミス入力トークンのコストはキャッシュヒット入力トークンの 10 倍になる。さらに重大な要件は、そもそも数字ですらない：マルチターンおよびツール呼び出しアプリケーションは、推論とツール状態を含む完全なアシスタントメッセージを保持しなければならない。

これにより、Kimi K3 は単なる新しいモデル ID 以上の存在になる。コンテキストレイアウト、キャッシュの安定性、セッションの永続化、タスク境界でのルーティングが、本番アーキテクチャの一部になるのだ。

TL;DR

Moonshot は Kimi K3 を、ネイティブビジョンと 1,048,576 トークンのコンテキストウィンドウを備えた 2.8T パラメータのオープンな 3T クラスモデルと説明している
確認時点で K3 は Kimi 製品と Moonshot の API を通じてすでに利用可能だったが、完全なウェイトは 2026 年 7 月 27 日までにリリース予定とされていた
このモデルは 896 のエキスパートのうち 16 を活性化するため、総パラメータ数はトークンあたりのアクティブな計算量と同じではない
公式 API 料金は、キャッシュヒット入力 1M トークンあたり $0.30、キャッシュミス入力 1M トークンあたり $3.00、出力 1M トークンあたり $15.00
現時点で K3 は常に max で推論し、マルチターンおよびツール呼び出しループでは完全なアシスタントメッセージの保持を要求する
Moonshot は、思考履歴の欠落や、既存セッションの K3 への切り替えが品質を不安定にし得ると警告している
本記事の確認時点で、K3 は Velokey のライブカタログには掲載されていなかった。モデル ID を推測せず、まずライブでの利用可否を確認すること

Kimi K3 のステータス：確定、保留、未提供

大型モデルのローンチをめぐる情報は、いくつもの異なる状態を「リリース済み」という 1 語に押し込めてしまいがちだ。

Kimi K3 については、それらの状態を分けて扱う必要がある。

項目	2026 年 7 月 17 日時点のステータス
Kimi のアプリと製品	利用可能
公式 Moonshot API モデル `kimi-k3`	利用可能
完全なモデルウェイト	2026 年 7 月 27 日までに予定
最終的なオープンウェイトライセンス	確認したローンチ資料では未検証
Kimi K3 の完全なテクニカルレポート	公開待ち
Velokey 経由の Kimi K3	確認時点で未掲載

Moonshot の Kimi K3 リリースページは、これを 3T クラス初のオープンモデルと呼んでいる。これはプロバイダー側の位置づけである。現時点での実務的な違いは、開発者はすでに Moonshot の API 経由で K3 を呼び出せる一方、ローカルデプロイを計画するチームには実際のウェイト、ライセンス、モデルカード、テクニカルレポートがまだ必要だという点だ。

本記事を 7 月 27 日以降に更新する場合は、ウェイトのリリース状況を再確認すべきだ。リリース予定と、ダウンロード可能でライセンスの確定した成果物は同じものではない。

2.8T パラメータは実際に何を意味するか

Kimi K3 は Kimi Delta Attention、Attention Residuals、そして Stable LatentMoE アーキテクチャを組み合わせている。Moonshot によれば、モデルは 1 リクエストにつき 896 のエキスパートのうち 16 を活性化する。

これは、パラメータ数という見出しの読み方を変える。

Kimi K3 の主要スペック：総パラメータ 2.8 兆、896 エキスパート中 16 が実効的に活性化、1,048,576 トークンのコンテキストウィンドウ、ネイティブビジョン

*Moonshot は総パラメータ 2.8T、896 エキスパート中 16 の実効的な活性化、1,048,576 トークンのコンテキストウィンドウ、ネイティブビジョンを報告している。*

総パラメータ数 2.8T はモデル全体の容量を表す。すべてのトークンですべてのパラメータがアクティブになるという意味ではない。スパースなエキスパート活性化は、超大規模モデルが毎ステップで密モデル並みの計算コストを支払うことなく、より大きな容量を提供できるようにする仕組みだ。

Moonshot はまた、Kimi K2 のおよそ 2.5 倍という全体的なスケーリング効率を報告している。これはプロバイダーが報告するアーキテクチャ上の結果であり、独立した本番環境での測定ではないが、本当のエンジニアリング目標を指し示している：単に大きくするのではなく、超大規模モデルを長期ホライズンの作業で使えるものにすることだ。

K3 はネイティブの視覚理解も備え、コーディング、ナレッジワーク、推論、画像、動画向けと位置づけられている。これらの能力は可能な API ワークロードの幅を広げるが、どのワークロードが経済的かをチームに教えてはくれない。

その答えは、コンテキスト、出力、レイテンシ、ツール挙動から導かれる。

1M トークンウィンドウでもコンテキストエンジニアリングが不要にならない理由

Kimi の公式料金ページには、1,048,576 トークンのコンテキストウィンドウが記載されている。

これは大きな容量だ。しかし、すべてのリクエストを満杯にせよという指示ではない。

長時間稼働するコーディングやリサーチのエージェントには、次のものが蓄積し得る：

システム指示
権限と安全性のルール
ツール定義
リポジトリのファイルとドキュメント
取得したエビデンス
ユーザーメッセージ
アシスタントの推論
ツール呼び出しとツール結果
リトライ、修正、放棄されたブランチ

コンテキストには収まっていても、タスクは遅く、高価になり、制御しづらくなり得る。

ロングコンテキストは、主要な問いを「これは収まるか？」から「何をライブに残す価値があるか？」へと変える。

本番セッションは 4 つのレイヤーを分離すべきだ：

安定プレフィックス： 恒久的な指示、固定された知識、頻繁に再利用されるツール定義。
タスクワーキングセット： 現在の目標に必要なファイル、エビデンス、画像、ツール。
完全なセッション状態： 推論とツールの連続性を保つために必要なメッセージ。
再開可能なチェックポイント： 失敗したブランチをすべて永久に持ち回らなくてもタスクを復旧できる、検証済みのサマリー。

Kimi K3 の 4 層コンテキストアーキテクチャ：安定プレフィックス、タスクワーキングセット、完全なセッション状態、再開可能なチェックポイント

*ロングコンテキストが運用上有用になるのは、安定した指示、アクティブなワーキングセット、完全なセッション状態、再開チェックポイントが別々に管理されているときだ。*

100 万トークンのウィンドウはチームに余裕を与える。しかし、リトリーバル、コンパクション、チェックポイント、トークンバジェットの代わりにはならない。

Kimi K3 の料金はプロンプトアーキテクチャをどう変えるか

Moonshot の公式 K3 料金は次のとおり：

キャッシュヒット入力： 1M トークンあたり $0.30
キャッシュミス入力： 1M トークンあたり $3.00
出力： 1M トークンあたり $15.00

価格は諸税を含まず、変更される可能性がある。調達前に公式ページの最新情報を確認せよ。

基本的なコストモデルは次のとおり：

input cost = cache-hit MTok x $0.30 + cache-miss MTok x $3.00
output cost = output MTok x $15.00

Kimi K3 公式 API 料金の比較：キャッシュヒット入力 100 万トークンあたり $0.30、キャッシュミス入力 100 万トークンあたり $3.00、出力 100 万トークンあたり $15.00

*2026 年 7 月 17 日に確認した料金では、キャッシュヒットとキャッシュミスの入力レートに 10 倍の差があり、プレフィックスの安定性がコスト管理の仕組みになる。これは公式 Kimi API のレートであり、Velokey の料金ではない。価格は変更される可能性がある。*

入力価格の 10 倍の差は、プロンプト構造をコストアーキテクチャの一部にする。

Kimi のコンテキストキャッシングは自動だ。手動で管理するキャッシュ ID や TTL はない。API は、システムプロンプト、ナレッジドキュメント、ツール定義といった繰り返し現れる先頭コンテキストの再利用を試みる。

だが、自動は保証を意味しない。

アプリケーションが呼び出しのたびにプロンプトの先頭を変更したり、ツールを並べ替えたり、プレフィックスにタイムスタンプを注入したり、同じ知識を異なる順序でシリアライズしたりすると、再利用可能なコンテキストがキャッシュミスに変わり得る。

Moonshot は、公式 API がコーディングワークロードで 90% 超のキャッシュヒット率を達成したとしている。これはプロバイダー報告の結果として扱い、別のアプリケーションへの約束と見なさないこと。本番チームが信頼すべき数字は、自分たちのトラフィックで測定したものだ。

少なくとも次を追跡せよ：

キャッシュヒット入力トークン
キャッシュミス入力トークン
推論および最終回答の出力トークン
最初のトークンまでの時間
総レスポンスレイテンシ
ツール呼び出し回数
リトライ率
完了タスクあたりのコスト

エージェントにはリクエスト単位の料金だけでは不十分だ。1 つのユーザー目標が、数十のモデル呼び出し、ツール呼び出し、リトライ、検証ステップを引き起こし得る。

保持される思考がモデルルーティングを変える理由

Kimi K3 は常に推論する。API は現在 reasoning_effort="max" のみをサポートし、レスポンスには最終的な content に加えて reasoning_content が含まれることがある。

マルチターン会話とツール呼び出しについて、Kimi のドキュメントは、完全なアシスタントメッセージを次のリクエストに追加しなければならないとしている。開発者は目に見える回答だけを保持すべきではない。返されたメッセージには、連続性に必要な推論フィールドやツール呼び出しフィールドも含まれ得るからだ。

これはコストとルーティングの両方に影響する。

過去の推論はコンテキストウィンドウを占有し続け、トークン消費に寄与する。したがって長いエージェントセッションは、ユーザーメッセージとドキュメント以外の要因でも成長する。

これはまた、モデル選択が安全にステートレスではいられないことも意味する。

Moonshot は、ハーネスが完全な思考履歴を返さない場合や、別のモデルで進行中のセッションを K3 に切り替えた場合、K3 の品質が非常に不安定になり得ると警告している。

より安全な本番ルールはシンプルだ：

> タスクまたはセッションの境界でルーティングし、意図的なチェックポイントまで選択したモデルを固定する。

タスクの途中でモデルやプロバイダーが失敗した場合は、検証済みの事実、完了したアクション、現在のファイル、未決の判断、残りの目標を含む再開パッケージを作成する。同じツールループの中で黙ってモデル ID を変えるのではなく、その明示的な状態から代替モデルを開始せよ。

タスク分類とモデル選択から、セッション固定、安定コンテキスト、完全な状態の保持、ツールループ、テレメトリ、チェックポイントを伴うモデル変更までのセッション対応モデルルーティング

*タスク境界でモデルを選択し、ツールループの間は固定し、モデルの変更は意図的なチェックポイントの後か新しいセッションでのみ行う。これは本番向けの推奨であり、公式の Kimi ルーティングアーキテクチャではない。*

これがリクエストルーティングとセッションルーティングの違いである。

マルチモデルスタックにおける Kimi K3 の位置づけ

K3 の最大推論モードは、初日からワークロードの分離を重要にする。

ワークロード	Kimi K3 の適合度	本番での判断
リポジトリ規模のコーディング	有力候補	安定したハーネスを使い、状態を保持し、ツール成功率を測定する。
複雑なマルチツールリサーチ	有力候補	リトライ、エビデンス品質、コンテキストの成長を監視する。
ビジュアルエンジニアリングタスク	候補	実際の画像、動画、UI、CAD、デバッグのワークフローでテストする。
高価値なナレッジ統合	候補	回答の価値が長い推論と出力コストに見合うときに使う。
分類とタグ付け	デフォルトには不向き	多くの場合、より安価なモデルの方が効率的。
抽出と単純な書き換え	デフォルトには不向き	最大推論はたいてい不要なオーバーヘッド。
低レイテンシチャット	不明	最初のトークンまでの時間と総レイテンシをベンチマークする。
自律的な本番アクション	条件付き	狭い権限、サンドボックス、承認ゲート、ログを追加する。

Moonshot は現在の制限事項として、過剰な積極性を挙げている。長いタスクが曖昧さや小さな障害に遭遇したとき、K3 は予期しない判断を下すことがある。

だからこそ、権限設計はプロンプト設計と同じくらい重要になる：

読み取りアクセスと書き込みアクセスを分離する
API キーと本番クレデンシャルはサーバーサイドに保持する
破壊的なアクションや外部へのアクションには承認を必須にする
明示的な停止条件を定義する
要求されたすべてのツールアクションと結果をログに残す
成功した実行だけでなく、復旧時の挙動も評価する

最も高性能なモデルに、自動的に最も広い権限を与えるべきではない。

Kimi K3 API とセルフホスティングの比較

オープンウェイトのリリース予定により、ローカルデプロイも議論の対象に入ってくる。しかし、それでローカルデプロイが自動的に勝者になるわけではない。

Moonshot によれば、K3 は MXFP4 ウェイトと MXFP8 アクティベーションによる量子化認識トレーニングを使用している。同社はデプロイに、64 基以上のアクセラレータを備えたスーパーノード構成を推奨している。

これは推奨であって公表された最低要件ではないが、フルスケールの K3 サービングがクラスタレベルのインフラプロジェクトであることを示すには十分だ。

次の場合、マネージド API アクセスが現実的な最初の選択肢になる：

トラフィックが初期段階または変動的である
インフラを購入する前に品質を検証したい
デプロイ速度が重要である
チームが大規模な分散推論スタックを運用できない
プロダクトが K3 を他の複数モデルと比較する必要がある

次の場合、セルフホスティングの妥当性が高まる：

最終的なライセンスが想定する用途を許可している
データ主権の要件によりローカルでの管理が必要である
専用キャパシティを正当化できるほど負荷が持続している
組織がすでに大規模モデルのインフラを運用している
チームが稼働率、バッチング、キャッシング、アップグレード、障害復旧を管理できる

オープンウェイトであっても、ハードウェア、ネットワーク、遊休キャパシティ、可観測性、エンジニアリング時間が無料になるわけではない。

最も安全な順序は、まず API で評価し、その後にインフラへ投資することだ。

Kimi K3 エージェントの本番チェックリスト

K3 に本番トラフィックを送る前に、次の質問に答えておくこと。

ワークロード適合

タスクは長期ホライズンの推論、大きなコンテキスト、ビジョン、複雑なツールを必要とするか？
結果は最大推論と出力トークンコストを正当化できるほど価値があるか？
一次的な分類、抽出、書き換えは、より安価なモデルで処理できないか？

セッション設計

モデルはタスクの存続期間にわたって固定されているか？
完全なアシスタントメッセージが保存され、リプレイされているか？
ワークフローは失敗後にチェックポイントから再開できるか？
ツール定義は必要なときにだけロードされているか？

コストとレイテンシ

入力トークンのうちキャッシュヒットは何 % か？
推論履歴はどれくらいの速さで成長するか？
最初のトークンまでの時間と総タスク所要時間はどれくらいか？
リトライと失敗したツール呼び出しによる支出はどれくらいか？
リクエスト単位だけでなく、受け入れられた成果 1 件あたりのコストはいくらか？

安全性と運用

どのアクションに人間の承認が必要か？
クレデンシャルはサーバーのみに保存されているか？
破壊的なアクションはデフォルトでブロックされているか？
ツール呼び出し、エラー、トークン使用量、レイテンシ、支出は可観測か？

評価

K3 は実際のワークロードで強力なベースラインを上回るか？
より安価なベースラインを、コストを正当化できるだけ上回るか？
タスクを別のモデルで再開したとき何が起きるか？
モデルはどれくらいの頻度で人間の修正を必要とするか？

評価の成果物は、単一のベンチマークスコアではなく、品質・コスト・レイテンシのフロンティアであるべきだ。

モデル ID をでっち上げずに OpenAI 互換クライアントを準備する方法

本記事の確認時点で、Kimi K3 は Velokey のライブカタログにはなかった。利用可否は変わり得るため、統合コードを書く前にライブのモデルカタログを確認し、models エンドポイントに問い合わせること。

ブログ記事からモデル ID を推測してはならない。

次の例は、Velokey アカウントで現在利用可能なモデル ID を一覧表示する。K3 が存在することを前提にはしていない。

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["VELOKEY_API_KEY"],
    base_url="https://api.velokey.ai/v1",
)

for model in client.models.list().data:
    print(model.id)

API キーはサーバーサイドの環境変数に保持する。Kimi K3 のモデル ID が GET /v1/models に現れない場合、そのアカウントでは Velokey 経由でまだ利用できない。未掲載の ID をハードコードするのではなく、利用可能と確認済みのモデルか公式 Kimi API を使い続けること。

新しいモデルが利用可能になれば、OpenAI 互換クライアントは移行作業を減らしてくれる。それでもアプリケーションには、モデル固有の評価、セッションルール、テレメトリが必要だ。インターフェースの互換性は挙動の違いを消してはくれない。

Kimi K3 が支出に見合うのはいつか

Kimi K3 が最も魅力的なのは、タスクが人間にとって高コストで、分割が難しく、長い推論トレースを正当化できるだけの価値があるときだ：大規模なリファクタリング、マルチツールのリサーチ業務、マルチモーダルなエンジニアリングワークフロー、持続的な統合を要する複雑なドキュメント群などである。

万能なデフォルトとしての魅力は薄い。分類、抽出、タグ付け、単純な書き換え、定型的なサポートは、マルチモデルスタックで予算を守るべき領域だ。

本番導入の判断は 2.8T という数字だけから下すべきではない。キャッシュヒット率、完了タスクあたりのコスト、セッション安定性、ツール成功率、レイテンシ、復旧挙動、人間による修正の頻度から下すべきだ。

これが Kimi K3 API の本当のストーリーだ。モデルは巨大だが、それが有用かどうかを決めるのは周囲のセッションアーキテクチャである。

Kimi K3 API に関するよくある質問

Kimi K3 は現在、完全にオープンソースか？

2026 年 7 月 17 日時点で、Moonshot は完全なモデルウェイトを 7 月 27 日までにリリースするとしていた。K3 は Kimi 製品と公式 API を通じてすでに利用可能だった。後続の記事でダウンロード可能と記述する前に、リポジトリ、ライセンス、モデルカード、テクニカルレポートを確認せよ。

Kimi K3 のコンテキストウィンドウは？

Moonshot は 1,048,576 トークンと記載している。大きなウィンドウは容量を増やすが、リトリーバル、キャッシング、履歴管理、チェックポイントの必要性をなくすわけではない。

Kimi K3 の公式 API 価格は？

Moonshot は、キャッシュヒット入力 1M トークンあたり $0.30、キャッシュミス入力 1M トークンあたり $3.00、出力 1M トークンあたり $15.00（諸税別）と記載している。

Kimi K3 はすべてのトークンで 2.8T パラメータ全部を使うのか？

いいえ。Moonshot によれば、Stable LatentMoE アーキテクチャは 896 のエキスパートのうち 16 を活性化する。総パラメータ数は容量を表し、スパースな活性化がアクティブな計算量を抑える。

Kimi K3 のセッション途中でモデルを切り替えられるか？

慎重に行うこと。Moonshot は、不完全な思考履歴や、別モデルで進行中のセッションの K3 への切り替えが生成を不安定にし得ると警告している。セッション境界でルーティングするか、検証済みのチェックポイントから再開せよ。

Kimi K3 は Velokey 経由で利用できるか？

2026 年 7 月 17 日の本記事確認時点では掲載されていなかった。アカウント単位の最新の利用可否は、ライブのモデルカタログと GET /v1/models で確認すること。静的なブログの記述に依存してはならない。

出典

開示：本記事は Velokey が公開しており、Velokey は複数プロバイダーのモデルに対する OpenAI 互換の API アクセスレイヤーを提供している。レビュー時点で、Kimi K3 は Velokey のライブカタログには掲載されていなかった。

ID をでっち上げることなく、現在および将来のモデル選択肢に備えた 1 つのクライアントを準備したいなら、[Velokey クイックスタート](https://docs.velokey.ai/quickstart) に従い、GET /v1/models が返すモデルだけを選択しよう。