Kimi API は従量課金を採用しており、サブスクリプション制はありません。価格比較で「100 万 Token あたりいくらか」だけを見ると選び間違えやすくなります。請求を実際に決めるのは、モデル、コンテキスト長、キャッシュヒット率、出力長です。K2 シリーズは 262,144 Token のコンテキストを提供し、K3 はさらに 1,048,576 まで拡大します。長コンテキストは強力ですが、入力側でコストが累積しやすいという意味でもあります。
本記事では K2 シリーズの課金構造、長コンテキストのコスト要因、再現可能な試算方法、コスト削減の順序を分解します。単価は固定値として書きません。具体的な価格は公式ドキュメントおよびサイト内のモデル価格を基準にしてください。
注記：Moonshot、Kimi は各権利者の商標です。モデル、コンテキスト長、課金ルールは変更される可能性があります。本記事は 2026 年 10 月時点の一般的な状況を例にしているため、購入前に公式ページを再確認してください。
一、K2 シリーズの役割分担
| モデル | 位置付け | コンテキスト | 適したタスク | コスト上の注目点 |
|---|---|---|---|---|
kimi-k2.6 |
汎用 | 262,144 | 会話、抽出、カスタマーサポート、文書処理 | キャッシュヒット率 |
kimi-k2.7-code |
コード | 262,144 | コード生成、リポジトリに関する質問応答、Agent | 入力が長く、ツール結果が多い |
kimi-k2.7-code-highspeed |
コード高速版 | 262,144 | 低遅延の補完、対話的なコーディング | 単価とスループットのバランス |
kimi-k3 |
新世代 | 1,048,576 | 超長文書、複雑な多段タスク | 長コンテキストとキャッシュ書き込み |
モデルは世代交代し、K2 シリーズにも今後新しいバージョンが追加される可能性があります。購入時は公式のモデル一覧とサイト内のモデル価格を基準にし、本記事のモデル名を永続的な約束事として扱わないでください。
汎用タスクでは、既定で最大コンテキストを使う必要はありません。資料全体を 1M コンテキストに詰め込むと、入力コストがターン数に応じて急速に累積します。まず検索で範囲を絞り、モデルに重要な断片を読ませる方が通常は有利です。コードタスクは逆で、リポジトリ構造やツールの戻り値を保持する必要が多く、安定したプレフィックスとキャッシュヒットの向上が重要になります。
二、請求は 3 つの部分で構成される
K2 シリーズは「キャッシュヒット入力、キャッシュミス入力、出力」の 3 項目で課金されます。K3 はさらにキャッシュ書き込みを 5 分と 1 時間の 2 つの TTL で個別に課金するため、平均単価に総 Token を掛ける計算はできません。
| 課金項目 | 発生するとき | コストへの影響 | 制御手段 |
|---|---|---|---|
| キャッシュミス入力 | 初めて現れるプロンプト、文書、ツール結果 | コンテキストに比例して増加 | 検索、要約、履歴の切り詰め |
| キャッシュヒット入力 | 繰り返される system prompt、固定プレフィックス | 通常はミスより明確に低い | プレフィックスの安定化、ツール順序の固定 |
| 出力 Token | モデルが生成する内容と思考 | 長い出力は請求を膨らませる | max_completion_tokens の制限 |
| キャッシュ書き込み（K3） | キャッシュプレフィックスへの書き込み | TTL の階層ごとに課金 | 安定して再利用する内容だけをキャッシュ |
1 回のリクエストを分解すると、コスト式は次のようになります。
1 回のリクエストコスト =
ミス入力 Token × ミス単価
+ ヒット入力 Token × ヒット単価
+ 出力 Token × 出力単価
K3 ではキャッシュ書き込みの項目も加わります。レスポンスの usage は prompt_tokens、completion_tokens、prompt_tokens_details を返します。キャッシュヒットとキャッシュ書き込みはいずれも prompt_tokens に含まれるため、未キャッシュ部分は総数からこの 2 項目を引いて計算します。
三、長コンテキストが高くつきやすい理由
| シナリオ | 典型的な Token 構造 | 主なコスト | 最適化の方向 |
|---|---|---|---|
| 長文書の質問応答 | 入力が大きく出力が中程度 | 文書を繰り返し送る | 検索とキャッシュ |
| コードリポジトリ Agent | 入力も出力も大きい | ツール結果と履歴 | 要約、切り詰め、キャッシュ |
| マルチターンのカスタマーサポート | 入力がターン数に応じて累積 | 履歴メッセージの重複 | ローリング要約 |
| バッチ抽出 | 入力が中程度で出力が短い | 文書の繰り返し読み込み | バッチ処理と小型モデル |
差は通常 5 つの点から生まれます。
- 入力がターン数に応じて累積する：毎ターン全文を再送すると、請求はターン数にほぼ比例して増えます。
- キャッシュヒット率：固定プレフィックスは再利用できますが、毎回変わるタイムスタンプ、ランダム ID、動的な並べ替えはキャッシュを無効にします。
- ツール出力：1 回の検索やコード実行が長いログ全体を返し、次のターンでそのまま持ち回されるとコストが積み上がります。
- 出力長：開放的な「詳しく分析してください」は長い出力を生みやすく、出力は通常キャッシュヒット入力より高価です。
- モデルのミスマッチ：単純な分類に大型モデルを使う、または複雑なタスクに不適切なモデルを使って何度もリトライすると、コストが膨らみます。
四、再現可能な試算を行う
- 実際のタスクを 20〜50 件選び、単純、中程度、複雑の 3 段階をカバーし、受け入れ基準を明確にします。
- まず Token 見積もり用のインターフェースで入力を定量化し、文字数から推測しないでください。
- 同じタスク群を
kimi-k2.6とコード向けモデルでそれぞれ実行し、品質、遅延、手戻り回数を記録します。 - レスポンスの
usageから入力、出力、キャッシュヒット、キャッシュ書き込みを読み取ります。 - 100 万 Token あたりの表示価格ではなく、「合格したタスク 1 件あたり」のコストで比較します。
- リトライ、失敗リクエスト、キャッシュ書き込みも含めて 1 タスクあたりのコストに算入します。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.cn/v1",
)
resp = client.chat.completions.create(
model="kimi-k2.6",
messages=[{"role": "user", "content": "この契約書を JSON に抽出してください：……"}],
max_completion_tokens=1024,
)
u = resp.usage
print("入力", u.prompt_tokens, "出力", u.completion_tokens)
print("キャッシュ内訳", getattr(u, "prompt_tokens_details", None))
ストリーミング呼び出しでは stream_options={"include_usage": True} を追加します。完全な使用量は最後のチャンクでのみ返されます。金額は契約または料金ページの実際の単価を掛けて計算し、数か月前のスクリーンショットを流用しないでください。
五、コストを下げる順序
- まずキャッシュ：system prompt、ツール定義、ナレッジベースのプレフィックスを固定し、
cached_tokensで実際にヒットしているか検証します。 - 次に入力を減らす：検索では関連する断片だけを取得し、履歴メッセージは要約し、ライブラリ全体をコンテキストに入れないでください。
- 出力を制限する：適切な
max_completion_tokensを設定し、JSON や固定フィールドを要求して、挨拶や前置きを減らします。 - モデルをルーティングする：汎用タスクは
kimi-k2.6、コードタスクは K2.7 コード版、超長文の資料は K3 を検討します。 - 長いリクエストはストリーミングに：ストリーミングは単価を直接変えませんが、タイムアウトや切断によるリトライを減らせます。
- 監視とアラート：プロジェクト、モデル、シナリオごとに使用量を見て、予算上限を設定し、毎週消費ランキングを振り返ります。
順序を逆にしないでください。まずキャッシュと入力の整理を行い、その後でより安いモデルへの切り替えを検討します。そうしないと、間違った回答をより安く作るだけになります。
六、予算と請求の管理方法
- 1 プロジェクトに 1 Key とし、プロジェクトごとに日次予算を設定して、1 つの業務が全割当を使い切らないようにする。
- 毎月「プロジェクト、モデル、シナリオ」の 3 軸で照合し、最も伸びている呼び出しを見つける。
- キャッシュヒット率、リトライ回数、平均出力長は個別に記録する。そうしないと最適化の効果を証明できない。
- 人民元での支払いと請求書が必要なチームは、国内 AI ゲートウェイで複数モデルの請求を統一できます。具体的な価格と請求書のルールはモデル価格を基準にしてください。
よくある質問
K2 と K3 はどちらが割安ですか？
タスクによります。K2 シリーズはコンテキストが 262,144 で、多くの文書・コードシナリオをカバーします。K3 はコンテキストがさらに大きく、超長文の資料に適しています。「合格したタスク 1 件を完了する」総コストで比較し、単価だけを見ないでください。
キャッシュでどれくらい節約できますか？
プレフィックスの再利用率とヒット率によります。キャッシュヒット入力は通常ミスより明確に低く、ヒットするとキャッシュの有効期間も延びます。ただしプレフィックスが毎回変わる場合や短すぎる場合はヒットしません。
ストリーミング出力は安くなりますか？
単価は直接変わりません。価値は、長いリクエストのタイムアウト、接続切断、リトライによる隠れたコストを減らせることです。
請求が見積もりより高いのはなぜですか？
よくある見落としには、履歴メッセージ、ツールの戻り値、文書全文、リトライ、長い出力、キャッシュミスがあります。リクエストログと usage を照合してこそ、差異を特定できます。
国内チームはどうやって人民元で決済しますか？
人民元チャージと請求書を提供する AI ゲートウェイ経由で Kimi を呼び出し、複数モデルの請求を統一できます。具体的な利用可能モデル、価格、請求書のルールはモデル価格を基準にしてください。
次のステップ
まずZSQH AI Gateway でテスト用 Key を作成し、kimi-k2.6 とコード向けモデルでそれぞれ実際のタスク群を実行して、Token、キャッシュヒット、品質を記録します。その後で主力モデルを決めてください。モデルの可用性と価格はモデル価格を基準にしてください。
関連記事：
