Kimi K3 API の料金を実測：「常時オン」の reasoning は無効化できる

Kimi K3 のドキュメントには、thinking は無効化できず、reasoning_effort に指定できるのは "max" だけと書かれている。しかし実測では、API は "none" も受け付け、実際に機能した。同じ単純な質問でも、デフォルトの reasoning では $0.00179 かかったのに対し、無効化すると $0.000285 で済んだ。差は 6.3 倍だ。K3 は 2026-07-16 に、入力 100 万 token あたり $3、出力 100 万 token あたり $15 でリリースされた。中国の AI ラボが提供したモデルとしては過去最高の定価で、Claude Sonnet 5 と同額だ。この出力単価では、モデルがデフォルトで消費する reasoning token がコストの中心になる。ドキュメントにない無効化方法を正確に把握する価値は大きい。

TL;DR

• Kimi K3 はデフォルト設定で、出力 token の 69-93% を reasoning に使う。120 語の段落では出力 2,289 token として課金され、$0.0346 だった。
• ドキュメントの記載に反して reasoning_effort: "none" は受け付けられ、単純なクエリのコストは 6.3 分の 1 になった。ただし多段階の算術問題では、正答率が 3/3 から 0/6 に落ちた。
• Kimi K3 の prompt cache は、およそ 256 token の prefix から 256-token block 単位で hit する。cache 読み取り単価は $0.30/M。
• CJK の中では中国語が K3 で最も安い。100 文字あたりの正味 token 数は 52 で、58 の GLM-5.2 と DeepSeek を下回る。

以下はすべて、2026-07-20 に kimi-k3 を対象として実測した結果だ。このモデルは Synthorai gateway で Moonshot の定価どおりに提供されている。繰り返し使う prompt には salt を加えて response cache を回避し、挙動に関する結果は独立した別の request path でも確認した。すべての数値は raw usage record で裏付けている。

Kimi K3 はデフォルトで回答 1 件あたりいくらかかるのか？

reasoning が不要なタスクも含め、試したすべてのタスクで reasoning が料金の大半を占めた。デフォルト設定での回答 1 件あたりの結果は次のとおりだ。

このグラフで注目すべきはモデル間の違いだ。GPT-5.6 は必要に応じて reasoning を使う。単純な質問と事実確認では thinking token がゼロで、数学と文章作成では 65-70% だった。Claude Sonnet 5 はデフォルトで thinking が無効になっている。GLM-5.2 は割合で見ると K3 以上に reasoning を使う。しかし 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 の割合は他の中国系 reasoning model と同程度でも、請求額は同程度ではない。

デフォルトモードでは、予算に織り込むべき事実がもう 2 つある。まず thinking mode では、request ごとに約 67 token の非表示 preamble が追加される。同じ 1 語の message でも、reasoning がオンだと prompt token は 86、オフだと 19 だった。初期の利用者が指摘していた「hidden system prompt」はこれで、reasoning を無効化すると消える。次に、現時点の K3 は遅い。単純な質問でも、reasoning がオンなら end-to-end で約 19-24 秒、オフなら 3-8 秒かかった。リリース週の serving 状況を含む数値だ。料金だけでなく latency も見積もる必要がある。

Kimi K3 の reasoning は無効化できるのか？

できる。ドキュメントの記載とは異なる。公式の API リファレンス には、K3 は「常に thinking を有効にする」とあり、reasoning_effort が受け付けるのは "max" だけと書かれている。実際には endpoint は "none"、"low"、"medium"、"high" をエラーなしで受け付け、設定どおりに動作した。独立した別の request path でも同じ挙動を確認している。多段階の文章問題で見ると、設定は効いているが調整幅は粗い。

目立つ点は 2 つある。まず中間設定の差が小さい。low から max までは token 数が近く、このタスクでは正答率も同じだった。実質的に意味があるのはオンとオフの切り替えだ。次に、none では性能が急落する。多段階の算術問題に短く答えるよう強制すると、K3 は 6 回すべて誤答した。誤答は特定のパターンに偏らず、ばらついていた。短い形式を強制しなかった場合、モデルが簡潔さを無視して、回答本文で途中の計算を進めることもあった。その場合は正答したが、token が消えたのではなく、reasoning field から text field に移っただけだ。

latency の変化は token 数の差ほど大きくない。同じ問題を各 effort level で streaming したところ、first byte までの時間は 6-24 秒で、各設定の範囲は大きく重なった。thinking する内容がない none でも 12-13 秒待ったため、この規模のタスクでは serving が time to first token を支配している。設定によって実際に変わるのは、first byte から最初の回答 token までの間隔だ。ここがユーザーを待たせる thinking phase にあたる。

実運用では、none は検索、formatting、単一ステップのタスクに対して有効なコスト削減策になる。一方、中間ステップが必要なタスクでは危険だ。この parameter が今後も動作する保証はドキュメントにない。実測された挙動として扱い、自分の usage field で確認する必要がある。ドキュメントが実装に追いついた時点で、正式仕様になるか削除される可能性もある。

agent workload では、どのような場合に reasoning をオンのままにすべきか？

agent に近い 5 つの scenario で、デフォルト設定と reasoning_effort: "none" を比較した。どちらの設定でも、同一の単純なタスクをすべて完了できた。

意外なのは最初の行だ。tool-call loop では、デフォルト設定でも K3 はほとんど thinking せず、割合は 8% にとどまる。そのため削減余地は小さい。モデルは tool の選択を熟考ではなく反射的な処理として扱っている。削減効果が大きいのは、thinking の割合が高く、かつ処理が機械的なケースだ。具体的には RAG lookup と batch extraction が該当する。常時オンの固定コストが最も不要な領域でもある。本当に多段階の plan が必要な agent では、前節で示した正答率の急落が起きる。reasoning はオンのままにして token を使うべきだ。

単発の call にはばらつきがあるが、規模が大きくなると latency の差は明確になる。これらの scenario では、最初の token が到着するまでデフォルト設定で 10-19 秒、none で 8-13 秒だった。内容のある出力の生成速度は中央値で毎秒 35 token。リリース週の serving 状況を含めると、現時点では対話用途より asynchronous や batch の workload に向いている。

返送した reasoning は入力として再課金されるのか？

される。しかも token 単位でそのまま課金される。Kimi のドキュメントでは、各 assistant turn の reasoning_content を変更せずに message history へ残すよう案内している。そのコストを実測した。最初の turn の chain of thought を付けて 2 turn 目を送ると、prompt token は 599 だった。付けない同一 request では 198 だった。差は 401 token で、最初の turn に含まれていた 402 reasoning token とほぼ一致する。保持した thinking は後続の request ごとに再び入力され、通常の入力単価 $3/M で課金される。長い conversation では、蓄積した reasoning の入力コストを turn ごとに繰り返し支払うことになる。

ただし削除すれば必ず安くなるわけではない。前の chain of thought がない場合、K3 は follow-up を最初から reasoning し直した。2 turn 目の reasoning token は 31% 増え、343 から 449 になった。入力が $3/M、出力が $15/M なので、今回の検証では CoT を残すほうが最終的に安かった。ドキュメントの推奨は品質だけでなくコスト面でも妥当だ。ここで本当に効果があるのは次節の prompt cache だ。保持された history は安定した prefix になるため、cache が効けば通常料金での課金を避けられる。

Kimi K3 は prompt を cache するのか？何 token から有効になるのか？

K3 の prompt cache は自動で動作し、下限も低い。共有 prefix がおよそ 256 token に達すると hit し始め、256-token block 単位で増えた。303-token の prompt では 256 token が cache され、153-token の prompt は繰り返し試しても cache されなかった。cache 済み入力の料金は $0.30/M で、新規入力の $3/M に対して一律 90% 引きになる。今回発行した call では cache write の追加料金はなかった。最初の hit までに同一 call が 2-5 回必要だったため、1 回の retry だけでは cache の有無を判断できない。複数回で測定する必要がある。

この下限は、OpenAI が公開している 1,024-token minimum の 4 分の 1 だ。一方、block size は別の環境で実測した 64-token granularity より粗い。寿命は固定 TTL ではなく best-effort だ。今回の検証では、4 分と 15 分の idle gap 後にも cache entry が残った一方、8 分の gap で miss したケースもあった。expiry は負荷に依存する eviction と考え、call ごとに cache 済み token の内訳を確認すべきだ。料金についてもう 1 点ある。1M-token context window の料金は一律で、price list に long-context tier はない。window を最大まで使うと、call 1 回あたりの新規入力は $3.00、prefix が warm なら $0.30 になる。large-context workload の採算は、定価以上に cache の成否で決まる。traffic が数百 token 程度の system prompt を再利用するだけでも、K3 では他の多くの provider が cache を開始しない長さから有効になる。仕組みと usage から hit を確認する方法は、prompt caching ガイドと実測した cache minimumで解説している。

Kimi K3 では中国語のほうが本当に高いのか？

高くない。peer と比べると、K3 の tokenizer は中国語で最も効率がよい。リリース週に繰り返し話題になった疑問への答えでもある。意味をそろえた文章について、envelope overhead を差し引いた 100 文字あたりの正味 token 数は次のとおりだ。

K3 の中国語は 100 文字あたり 52 token で課金される。GLM-5.2 と DeepSeek より 11% 少なく、Sonnet 5 の半分未満だ。弱いのは日本語で、他の open-weight model より 16-24% 多くなる。family 内で tokenizer が変わっていないことも確認した。K3、K2.7-code、K2.5 は、対応をそろえた 23 sample すべてで同じ token 数になった。そのため K2 向けに作った言語別予算をそのまま使える。9 言語において tokenizer density と token 単価がどう組み合わさるかは、言語別で最も安い LLMの調査で扱っている。

FAQ

Kimi K3 の open weight はいつ公開されるのか？

Moonshot は 2026 年 7 月 27 日までに、Modified MIT license で全 weight を公開すると約束している。この記事の公開時点では K3 は API でしか利用できない。「史上最大の open-weight model」という説明は現時点では公開予定を示すもので、download link はまだない。weight の公開後に加わる open-weight ecosystem 全体の caching の挙動は、open-weight LLM の prompt cachingにまとめている。

K2 family と比べて、K3 の何が新しいのか？

料金面で実測できた違いは 3 点だ。1 つ目は価格で、K3 の $3/$15 に対し、K2.7-code は $0.95/$4。3.2-3.75 倍の値上げになる。2 つ目は常時オンの thinking で、K2.5 は reasoning を一切使わず、K2.7-code には toggle がある。3 つ目は、それ以外に違いがないことだ。K3、K2.7-code、K2.5 の tokenizer は、対応をそろえた 23 sample すべてで byte 単位まで同一だった。そのため K2 世代の token 予算をそのまま引き継げる。spec sheet 上では、Moonshot によると Kimi Delta Attention を採用した新しい 2.8T-parameter MoE で、expert は 896、token ごとに 16 が active になる。context window は K2.7-code の 256K に対して 1M-token で、image input にも native 対応する。今回実測したのは料金に関する主張であり、architecture に関する主張ではない。

Kimi K3 は structured output に対応しているか？

対応している。json_schema を含む response_format を指定したところ、schema に準拠した有効な object が返った。ただし内部では reasoning が動作する。この extraction call の出力 97 token のうち 66 token は reasoning だった。schema で制約した call も、reasoning_effort: "none" を同時に指定しない限り、他の処理と同じように thinking のコストがかかる。

reasoning を無効化すると、確認できる内容は変わるのか？

変わる。デフォルト設定では、K3 は完全な chain of thought を reasoning_content で返す。ドキュメントでは、multi-turn history に変更せず返送するよう案内している。reasoning_effort: "none" を指定すると、この field 自体がなくなる。同時に、約 67-token の thinking preamble も prompt の請求から消える。

2026-07-20 に kimi-k3 で実測。リリース週の定価は入力 $3/M、cache 済み入力 $0.30/M、出力 $15/M。繰り返し使う prompt には salt を加え、response-level cache を回避した。正答率は正解を一意に確認できるタスクで集計した。挙動に関する結果は、独立した別の request path でも再現している。リリースが成熟するにつれて、価格や挙動は変わる可能性がある。ここに記載した数値を利用する前に、自分の usage record で確認してほしい。

← ブログに戻る