実測 Kimi K3 API 料金：「常時オン」の推論を止める
目次
Kimi K3 のドキュメントには、思考は無効化できず、reasoning_effort は "max" しか受け付けないと書かれている。ところが実測してみると、API は "none" も受け付けるし、ちゃんと機能する。デフォルトの推論込みだと $0.00179 かかる同じ他愛ない質問が、推論なしなら $0.000285 で済む。差は 6.3 倍だ。K3 は 2026-07-16 にリリースされ、入力 100 万トークンあたり $3、出力 100 万トークンあたり $15 という価格設定になっている。中国のラボが出したものとしては最も高い定価で、Claude Sonnet 5 と同じ値札だ。この出力価格では、モデルがデフォルトで消費する推論トークンがそのまま請求額になる。だからこそ、ドキュメントに載っていないこのオフスイッチを正確に理解しておく価値がある。
TL;DR
- Kimi K3 はデフォルト設定だと出力トークンの 69〜93% を推論に費やす。120 語の段落で出力トークンは 2,289、$0.0346 の請求になった。
reasoning_effort: "none"はドキュメントの記載に反して受け付けられ、単純なクエリのコストを 6.3 倍削減できた。ただし複数ステップの計算問題では正解率が 3/3 から 0/6 に落ちた。- Kimi K3 の prompt cache は、おおよそ 256 トークンのプレフィックスから、256 トークン単位でヒットする。読み取りレートは $0.30/M。
- CJK の中では中国語が K3 の最安レーン。100 文字あたり実質 52 トークンで、GLM-5.2 と DeepSeek の 58 を下回る。
以下の内容はすべて 2026-07-20 に、Moonshot の定価で Synthorai ゲートウェイ上に稼働している kimi-k3 に対して実測したものだ。レスポンスキャッシュを回避するためにプロンプトには salt を加えて繰り返し送り、挙動に関する主張は 2 本目の独立したリクエスト経路でクロスチェックしている。すべての数値の裏付けとして生の usage レコードが残っている。
Kimi K3 はデフォルトで1回の回答にいくらかかるか
送信したすべてのタスク形状で、回答コストの大半を reasoning が占めた。reasoning が不要なタスクでも同様だ。デフォルト設定での1回の回答あたりのコストは以下の通り。
| タスク | 出力トークン | reasoning の割合 | 1回の回答コスト |
|---|---|---|---|
| 単純な算術（17×23） | 99 | 84% | $0.0018 |
| 事実の一文回答 | 80 | 79% | $0.0015 |
| 小さなコード関数 | 119 | 69% | $0.0009 |
| 複数ステップの文章問題 | 139 | 87% | $0.0025 |
| 120語の段落 | 2,289 | 93% | $0.0346 |
このチャートの狙いはモデル間の対比にある。GPT-5.6 は適応的に reasoning する（単純な問題や事実問題では thinking トークンがゼロ、数学と文章生成では 65〜70%）。Claude Sonnet 5 は thinking をオフにして出荷される。GLM-5.2 は相対的に見て K3 よりもさらに深く thinking する。ただし GLM の出力価格は $4.40/M、K3 は $15/M だ。同じ 17×23 の回答は、GLM-5.2 で $0.00078、GPT-5.6 で $0.00027、Sonnet 5 で $0.0001、K3 で $0.0018 という請求になった。この差は出力が長くなるほど広がる。同じ 120語の段落は、K3 で $0.0346、GLM-5.2 で $0.0186、GPT-5.6 で $0.0072、Sonnet 5 で $0.0024 で、セット内でもっとも平凡なタスクで 15倍の開きがある。税率は他の中国製 reasoning モデルと同程度だが、税額は違う。
予算に織り込むべきデフォルトモードの事実がもう2つある。1つ目、thinking モードはすべてのリクエストに約 67トークンの隠れた前置きを挿入する。同一の1語メッセージが、reasoning オンで 86 プロンプトトークン、オフで 19 トークンの請求になった。初期のテスターが気づいた「隠れシステムプロンプト」がこれで、reasoning が消えると一緒に消える。2つ目、K3 は現時点で遅い。単純な問題の呼び出しは、reasoning オンでエンドツーエンド約 19〜24秒、オフで 3〜8秒かかった（ローンチ週のサービング状況を含む）。ドルだけでなくレイテンシも予算に入れておくこと。
Kimi K3 の推論はオフにできるのか？
ドキュメントの記述に反して、答えはイエスだ。公式の API リファレンス には、K3 は「常に thinking が有効」で、reasoning_effort は "max" しか受け付けないと書いてある。ところが実際には、エンドポイントは "none"、"low"、"medium"、"high" をエラーなく受け付け、しかもその指定どおりに動いた。別の独立したリクエスト経路でも同じ挙動を確認している。複数ステップの文章題で試すと、このダイヤルは確かに効くが、粒度は粗い。
reasoning_effort | 推論トークン（平均） | 正答率 |
|---|---|---|
none | 0 | 0/6 |
low | 78 | 3/3 |
medium | 94 | 3/3 |
high | 105 | 3/3 |
max / デフォルト | 100-121 | 3/3 |
目立つ点が 2 つある。まず中間の設定は団子状態だ。low から max までトークン数はほぼ同じで、このタスクでの正答率も変わらない。つまり意味のある切り替えは二値でしかない。次に none には明確な断崖がある。複数ステップの計算問題を簡潔に答えるよう強制すると、K3 は 6 回中 6 回間違えた。しかも一貫した誤りではなく、バラバラの誤答だった。簡潔な形式を強制しなかった場合、モデルは簡潔さを無視して、目に見える回答の中でステップを追って解くことがあった。答えは正しいが、トークンが消えたわけではなく、推論フィールドからテキストフィールドへ移動しただけだ。
レイテンシの変化はトークン数から予想されるほど大きくない。同じ問題をすべての effort レベルで streaming したところ、最初のバイトまでの時間は 6-24 秒で、各レベルの範囲は大きく重なった。考えることが何もない none でさえ 12-13 秒待たされている。つまりこのタスク規模では、time to first token の大半をサービング側が占めている。このダイヤルが実際に変えるのは、最初のバイトから最初の回答トークンまでの間隔、すなわちユーザーが待たされる thinking フェーズの長さだ。
実用的な読み方はこうだ。none は、検索・整形・単一ステップのタスクではコストを本当に下げるレバーになるが、中間ステップを要するものには地雷になる。このパラメータが動き続けるという保証はドキュメントに一切ない。あくまで実測された挙動として扱い、自分の usage フィールドで検証し、ドキュメントが追いついた時点で正式化されるか削除されるかもしれないと考えておくべきだ。
エージェント処理で推論をオンのままにすべきなのはいつか？
K3 を、エージェント的な 5 つのシナリオでそれぞれ 2 回ずつ走らせた。デフォルトと reasoning_effort: "none" の比較で、どちらの構成でも完全に通る同一のシンプルなタスクを使った。
| シナリオ | thinking の割合（デフォルト） | none でのコスト | none での TTFT |
|---|---|---|---|
| ツール呼び出しループ | 8% | −10% | −35% |
| RAG 応答 | 71% | −37% | −53% |
| 構造化ツーリング | 29% | −16% | −31% |
| バッチ抽出 | 80% | −15% | −11% |
| 長い対話（15 ターン） | 34% | −13% | −25% |
意外なのは最初の行だ。ツール呼び出しループでは、K3 はデフォルト設定でもほとんど考えない（割合 8%）ので、削れる余地が少ない。モデルはツール選択を熟慮ではなく反射として扱っている。節約が集中するのは、thinking の割合が高く、しかもタスクが機械的な場合（RAG のルックアップとバッチ抽出）だ。ここはまさに、固定の常時オン課金が最も不要な場所でもある。本当に複数ステップを踏むエージェントの計画については、前節の正答率の断崖がそのまま当てはまる。推論はオンのままにして、トークンを使えばいい。
単発の呼び出しはばらつくものの、スケールすればレイテンシの効果は確かに現れる。これらのシナリオを通じて、最初のトークンはデフォルト設定で 10-19 秒、none で 8-13 秒で届き、実質的な出力での生成速度は中央値で毎秒 35 トークンだった。この数字は、ローンチ週のサービングを含んでいることを踏まえても、今の対話用途よりは非同期やバッチの形態に合っている。
返してあげた reasoning は入力として再課金されるのか？
される。トークン単位でそのまま課金される。Kimi のドキュメントは、各 assistant ターンの reasoning_content を改変せずにメッセージ履歴に残すよう指示している。そのコストを実測した。1 ターン目の思考連鎖を付けて送った 2 ターン目は prompt token 599、同じリクエストを思考連鎖なしで送ると 198 だった。差分の 401 token は、1 ターン目の reasoning token 402 とほぼ一致する。つまり保持した思考は、以降のすべてのリクエストに $3/M の入力レートそのままで再投入され、長い会話では毎ターン、蓄積した reasoning の分を払い直すことになる。
ただし、削除すれば自動的に安くなるわけではない。直前の思考連鎖がないと、K3 はフォローアップをゼロから推論し直した。2 ターン目の reasoning token は 31% 増えた（343 → 449）。入力 $3/M に対して出力 $15/M なので、今回の検証では CoT を残すほうが正味で安かった。ドキュメントの助言は品質面だけでなくコスト面でも成り立つ。ここで実際に効いてくるのは次のセクションで扱う prompt cache だ。保持した履歴は安定した prefix になり、安定した prefix は満額での課金が止まる。
Kimi K3 は prompt をキャッシュするのか、何 token から効くのか？
K3 の prompt cache は自動で動き、しきい値が低い。ヒットは共有 prefix がおよそ 256 token から始まり、256 token 単位で進む（303 token の prompt は 256 がキャッシュされ、153 token の prompt は繰り返し試しても一度もキャッシュされなかった）。キャッシュ済み入力の課金は $0.30/M で、新規レート $3/M に対して一律 90% 引き。今回発行したどのコールにも cache-write の上乗せはなかった。ウォームアップには最初のヒットまで同一コールが 2〜5 回必要だったので、1 回のリトライではどちらとも判断できない。複数回で計測すること。
参考までに、このしきい値は OpenAI がドキュメントに記載する最小 1,024 token の 4 分の 1 で、ブロックサイズは別の場所で実測した 64 token 粒度より粗い。有効期間は固定 TTL ではなくベストエフォートだ。今回の検証では、キャッシュ済みエントリは 4 分と 15 分のアイドル間隔を生き延びたが、8 分の間隔で 1 回ミスした。したがって、有効期限は負荷次第の eviction とみなし、コールごとに usage でキャッシュの内訳を確認すること。もう 1 つ計算しておく価値のある料金上の事実がある。1M token のコンテキストウィンドウは一律料金で、価格表に長コンテキスト用のティアはない。ウィンドウを使い切ると新規入力は 1 コールあたり $3.00、prefix が温まっていれば $0.30 になる。大コンテキストのワークロードは、表示価格よりもキャッシュで生死が決まる。数百 token 程度の system prompt でも再利用するトラフィックなら、他の多くのプロバイダーがまだ効き始めない領域で K3 のキャッシュは動く。仕組みと usage からヒットを確認する方法は prompt caching ガイド と 実測したキャッシュ最小値 の調査で扱っている。
Kimi K3 で中国語は本当に割高なのか？
そんなことはない。K3 のトークナイザーは、他モデルと比べて中国語で最も効率が良い。ローンチ週の議論で何度も出てきた疑問への答えがこれだ。意味的に揃えた文章での 100 文字あたりの正味トークン数（エンベロープのオーバーヘッドを差し引いたもの）は次のとおり。
| Model | en | zh | ja | ko | hi | Python |
|---|---|---|---|---|---|---|
| kimi-k3 | 19.7 | 51.9 | 87.5 | 83.2 | 62.8 | 26.5 |
| glm-5.2 | 19.7 | 58.4 | 75.7 | 76.9 | 91.3 | 25.6 |
| deepseek-v4-flash | 19.7 | 58.4 | 70.6 | 69.2 | 60.7 | 26.7 |
| claude-sonnet-5 | 32.3 | 114.3 | 94.1 | 106.3 | 70.9 | 41.1 |
K3 は中国語を 100 文字あたり 52 トークンで課金する。これは GLM-5.2 や DeepSeek より 11% 低く、Sonnet 5 の半分以下だ。弱いのは日本語で、他のオープンウェイトモデルより 16〜24% 多く払うことになる。トークナイザーがファミリー全体で変わっていないことも確認した。K3、K2.7-code、K2.5 は、揃えた 23 サンプルすべてで同一のカウントを出したので、K2 向けに組んだ言語ごとの予算がそのまま使える。トークナイザーの密度が 9 言語にわたってトークン単価とどう掛け合わさるかは、言語別の最安 LLM の調査で扱っている。
FAQ
Kimi K3 のオープンウェイトはいつ公開されるのか？
Moonshotは2026年7月27日までにModified MITライセンスの下で完全な重みを公開すると約束していますが、この投稿の時点でK3はAPIのみです。「史上最大のオープンウェイトモデル」という表現はコミットメントであって、まだダウンロードリンクではありません。この重みが加わることになるオープンウェイトエコシステム全体でキャッシュがどのように振る舞うかは、オープンウェイトLLMのためのプロンプトキャッシングで解説されています。
K2 ファミリーと比べて K3 で実際に新しいのは何か？
課金面で計測したのは 3 点。まず価格（K3 の $3/$15 に対し K2.7-code は $0.95/$4 で、3.2〜3.75 倍の跳ね上がり）、常時オンの thinking（K2.5 は一切 reason せず、K2.7-code はトグルあり）、そしてそれ以外は変わらない。トークナイザーは K3、K2.7-code、K2.5 で、揃えた 23 サンプルすべてにわたりバイト単位で同一なので、K2 時代のトークン予算がそのまま通用する。スペックシート上は、Moonshot によると次のとおり。Kimi Delta Attention を備えた新しい 2.8T パラメータの MoE（896 エキスパート、トークンごとに 16 がアクティブ）、K2.7-code の 256K に対し 1M トークンのコンテキストウィンドウ、そしてネイティブの画像入力。計測したのは課金に関する主張であって、アーキテクチャの主張ではない。
Kimi K3 は構造化出力に対応しているか？
対応している。json_schema を指定した response_format は、検証したところスキーマに準拠した正しいオブジェクトを返した。ただし下では依然として reasoning が走っている。その抽出呼び出しの出力 97 トークンのうち 66 が reasoning だった。つまりスキーマ制約付きの呼び出しも、reasoning_effort: "none" を併せて設定しない限り、他と同じように thinking の税金を払うことになる。
reasoning をオフにすると見える内容は変わるのか？
変わる。デフォルト設定では K3 は思考の連鎖全体を reasoning_content に返し、マルチターンの履歴では改変せずそのまま戻すようドキュメントは勧めている。reasoning_effort: "none" にするとこのフィールドは完全に消え、約 67 トークンの thinking の前置きもプロンプトの請求から一緒に消える。
2026-07-20 に kimi-k3 をローンチ週の表示価格（入力 $3/M、キャッシュ $0.30/M、出力 $15/M）で計測。応答レベルのキャッシュを避けるため、繰り返しのプロンプトにはソルトを付けた。正解率のカウントは検証可能な単一の答えを持つタスクを使用。挙動に関する主張は、2 つ目の独立したリクエスト経路で再現した。リリースが成熟するにつれて価格や挙動は変わりうるので、ここの数値に頼る前に自分の usage 記録で確認してほしい。