Kimi K3のトークン効率：速度、レイテンシ、成功タスク当たりコスト
「効率」に含まれる4つの質問
| 質問 | 指標 | 意味 |
|---|---|---|
| いつ応答を開始するか | Time to First Token | 体感応答性と停止して見える時間。 |
| どれだけ速く生成するか | 1秒当たり出力トークン | 長い回答と推論の所要時間。 |
| 何トークン使うか | 入力、キャッシュ、推論、出力 | モデル呼び出し部分のコスト。 |
| どれだけ仕事を完了するか | 受け入れ率、再試行、レビュー時間 | 消費が実用価値を生んだか。 |
生成速度が速くても初期推論が長い場合、単価が安くても出力が多い場合、1リクエストが高くても再試行を避けて成功単価が低い場合があります。「速い」「安い」の一語にまとめないでください。
確認済みのKimi K3コスト要素
2026年7月17日時点のMoonshot直接料金：
| トークン区分 | 100万トークン当たり価格 | 計画用途 |
|---|---|---|
| キャッシュ入力 | $0.30 | 実際にヒットする安定したリポジトリ、指示、文書セット |
| 非キャッシュ入力 | $3.00 | 再利用できない新規Promptと文脈 |
| 出力 | $15.00 | 現行チャネル規則で課金される生成 |
Moonshotは1,048,576トークン文脈と常時推論を文書化しています。大規模難題に有効ですが、文脈選択と出力制御が重要になります。これはEvoLink料金ではありません。
リリース直後に出力トークンが議論される理由
Artificial Analysisの初期測定は約62出力トークン／秒で、K3を非常に多出力と分類し、Intelligence Index実行の総コストを約$2,690.80と報告しました。
単価だけでは誤解する理由を示しますが、普遍的な速度・コスト保証ではありません。
- 1つの第三者環境；
- 設定とPromptで推論・出力が変わる；
- APIプロバイダーごとに待ち時間、スループット、キャッシュが違う；
- 本番処理はベンチマークより入力が多く出力が少ない場合がある；
- 1回で受け入れられる結果は、短い失敗を複数回出すより価値が高い。
この値は出力と経過時間を記録する理由であり、最終ルート判断ではありません。
リスト価格を正しく計算する
model_call_cost =
cached_input_mtokens * cached_input_rate
+ uncached_input_mtokens * uncached_input_rate
+ output_mtokens * output_rate安定リポジトリ250K、新規指示・検索25K、出力40Kの例：
| シナリオ | キャッシュ入力 | 新規入力 | 出力 | 直接価格合計 |
|---|---|---|---|---|
| ヒットなし初回 | $0.00 | $0.825 | $0.600 | $1.425 |
| 250K接頭部がヒットする反復 | $0.075 | $0.075 | $0.600 | $0.750 |
キャッシュ時でも出力がモデル費用の80%です。失敗後に同等の再試行をすると、レビュー前に倍増します。
本番の式：成功タスク当たりコスト
successful_task_cost =
initial_model_calls
+ retry_calls
+ fallback_calls
+ tool_costs
+ human_review_cost
+ defect_repair_costcost_per_success = total_workload_cost / accepted_tasks| 挙動 | 1リクエストの見え方 | 成功単位の実態 |
|---|---|---|
| 短く安いが検証に失敗 | 効率的 | 再試行／fallback後は高い |
| 長いが1回で合格 | 高い | 高難度では効率的な場合あり |
| キャッシュ長文脈と制御出力 | 中程度 | 反復リポジトリ作業で有効 |
| 遅く対話製品を止める | Tokensは許容 | 運用上は不可 |
| 簡単なタスクにプレミアム | 高品質 | 小型モデルで足りるなら無駄 |
K3を要約、タグ、単純変換の自動標準にしないでください。難易度、文脈、視覚入力、または高い受け入れ率で価値を示す必要があります。
速度：ワークフロー全体を測る
| 時間指標 | 開始 | 終了 | 分かること |
|---|---|---|---|
| Queue／接続 | リクエスト発行 | 応答受理 | プロバイダー／ネットワーク遅延 |
| First Token | リクエスト発行 | 最初のStream Token | 体感待ちと初期推論 |
| 生成時間 | First Token | Final Token | 継続的な出力速度 |
| ツールループ | 最初のModel Call | 最後のTool Result | オーケストレーション費用 |
| 候補まで | タスク開始 | モデルが完了宣言 | 素の生産性 |
| 受け入れまで | タスク開始 | テストとレビュー合格 | 実際の本番価値 |
最後が最重要です。高速Streamingでも3回修復すれば、初期待機が長く1回で正しいモデルより遅くなります。
対話製品では、最初の進捗、ツール停止、総時間、timeout／fallback、最大修復ループを別々に設定してください。
コーディングエージェントのトークン効率
通常チャットにない消費源は、リポジトリ再送、古いツール出力、長い推論、巨大ログ、不正引数の再試行、ファイル全体書き直し、失敗後の高価なfallbackです。
| Funnel段階 | 数 | 効率シグナル |
|---|---|---|
| 開始タスク | 全件 | 需要の基準 |
| 候補生成 | 回答／パッチまで到達 | 生の完了 |
| 自動Check合格 | テストと検証合格 | 技術的有用性 |
| 人手Review合格 | 大幅書き直しなしで受け入れ | 本番品質 |
| 出荷／利用 | 実際の製品価値 | 最終効率 |
リクエスト当たりTokensだけを減らし、途中で成果を失うのは偽の効率化です。
K3トークン効率の同条件テスト
少なくとも4種類、20～50件の実タスクを使います。
| ワークロード | 内容 | 受け入れ指標 |
|---|---|---|
| フロントエンド | スクリーンショット／要件とリポジトリ制約 | 視覚・技術Rubric合格 |
| 不具合修正 | 再現可能な不具合とテスト | 根本原因修正、回帰なし |
| リポジトリ分析 | 大規模コードと明確な質問 | 正しいファイル根拠と有用回答 |
| ツール集約Agent | 検索、編集、Terminal、Test | 正しいツール利用と無介入完了 |
| 文書統合 | 反復利用する大規模参考資料 | 根拠付き結論と正しい引用 |
task_id
model_route
prompt_version
cached_input_tokens
uncached_input_tokens
output_tokens
time_to_first_token
total_elapsed_time
retry_count
fallback_route
automated_pass
human_acceptance
review_minutes他モデル比較ではPrompt、タスク状態、ツール、timeout、受け入れRubricを固定してください。
キャッシュで最適なルーティング役割が変わる
適した対象は、リポジトリ規約と設計、安定した製品要件、反復利用する大規模資料、共通システム指示／ツール文書、永続Agent Workspaceです。
毎回文脈や接頭部が変わる場合は価値が下がります。見た目が似たRequestではなく、実際にキャッシュ課金されたTokensを確認してください。
| 文脈パターン | K3への示唆 |
|---|---|
| 大きく安定した接頭部、多数タスク | Hitと受け入れが高ければ強い候補 |
| 接頭部が毎回変化 | 予定より入力節約が小さい |
| 短い独立タスク | 小型ルートの方が安く速い可能性 |
| 古い履歴を持つ長い会話 | 文脈追加前に圧縮 |
| 大きなツール一覧 | 毎回すべて送らず動的ロード |
推奨EvoLinkコストポリシー
| トラフィック | 初期方針 | 昇格条件 |
|---|---|---|
| 簡単な大量変換 | 小型低価格モデル | K3で受け入れが大きく改善した場合のみ |
| 難しいコード／ビジュアル | K3を直接テスト | 成功タスクコストと遅延が目標内 |
| 大規模文脈の反復 | キャッシュ測定付きK3 | 実Hitで総コストが低下 |
| 高リスク | K3対GPT-5.6 Sol／Claude Opus 4.8 | 受け入れ結果の経済性が最良のモデル |
| Timeout／検証失敗 | 1回の制御fallback | 定義した再試行予算で停止 |
EvoLinkの統一APIゲートウェイなら、アプリのアクセス層を保ちながらモデル、fallback、処理割り当てを設定できます。
よくある測定ミス
| ミス | 問題 | 改善 |
|---|---|---|
| 出力単価だけ比較 | 多出力、再試行、レビューを無視 | 受け入れ結果当たりコスト |
| 目立つPrompt 1件 | ばらつきと失敗を隠す | 代表タスクと複数試行 |
| Tokensだけで時間なし | 安くても遅延目標を外す | First Tokenと受け入れ時間 |
| 反復入力は全てCacheと仮定 | 規則と接頭部変更が影響 | 課金Cache Tokensを確認 |
| Tool／Budgetが違う | リソース差で不公平 | 主比較の環境を固定 |
| Reviewer工数を無視 | 修正費用がModel費用を上回る | Review分数と大幅書き直しを記録 |
よくある質問
Kimi K3はトークン効率が高いですか？
ワークロード次第です。直接単価とキャッシュ割引は有利ですが、初期第三者測定は出力量の多さも示します。受け入れタスク当たりコストを測ってください。
Kimi K3が遅く感じるのはなぜですか？
常時推論にQueue、First Token、生成、ツール、再試行、検証が加わります。原因を決める前に各段階を記録します。
Kimi K3の出力速度は？
Artificial Analysisは初期環境で約62出力トークン／秒を報告しました。プロバイダー、地域、タスク全体の保証ではありません。
Kimi K3はトークンを使いすぎますか？
初期の第三者・コミュニティ議論ではその懸念があります。本番では、そのTokensが受け入れ結果を作るか、再試行を減らすかで判断します。
Kimi K3の1タスク料金は？
普遍的な金額はありません。キャッシュ、新規入力、出力、再試行、fallback、ツール、レビューを合計し、受け入れ件数で割ります。
キャッシュでKimi K3は大幅に安くなりますか？
大きな安定接頭部が実際にHitする場合は可能です。出力、再試行、変化する文脈は残るため、課金データを確認してください。
Kimi K3を標準モデルにすべきですか？
すべてには向きません。難しいコード、ビジュアル、Agent、大規模文脈から試し、簡単な大量処理には小型モデルを残します。
EvoLinkで他モデルとどう比較しますか？
同じタスク、Prompt、ツール、timeout、基準を使い、Tokens、First Token、総時間、再試行、レビュー、受け入れコストを記録します。
EvoLinkでK3を測定する
Kimi K3製品ページから代表タスクを実行し、エビデンスが揃うまでフォールバックを設定可能に保ちます。
EvoLinkでKimi K3を確認関連記事：
- EvoLinkでKimi K3を使う方法
- 出典付き Kimi K3 プロンプトと活用例
- Kimi K3フロントエンドレビュー（英語）
- Kimi K3 vs GPT-5.6 Sol
- Kimi K3 vs Claude Opus 4.8
出典
- Kimi：Kimi K3技術発表
- Kimi Platform：直接API料金
- Kimi Platform：クイックスタート
- Artificial Analysis：Kimi K3の性能、速度、価格
- Simon Willison：Kimi K3とタスク当たりコスト
第三者測定は時点付きスナップショットであり、現在のEvoLinkルート性能や課金の証明には使用していません。
