Kimi K3-256k リリース: コスト効率の高いハイコンテキストコーディング
Kimi は K3-256k を導入しました。これは、フル 1M トークンのコンテキストウィンドウを必要としない開発者向けに、クオータ消費を削減することを目的とした、フラッグシップの K3 コーディングモデルの特殊バージョンです。256k の制限内のタスクに対しては、K3-256k はフル K3 モデルと同一の結果を提供しながら、クオータを約半分に抑えます。
Kimi コーディングモデル比較
Kimi は現在、K3 と K2.7 Code の 2 つの主要モデルファミリーを提供しており、4 つの異なるモデル ID が利用可能です。K3 シリーズはフラッグシップ製品で、2.8 兆パラメータを備えています。
| Model ID | Model Version | Context Window | Key Characteristics | Availability |
|---|---|---|---|---|
k3 |
Kimi K3 | 最大 1M | フラッグシップ機能; 画像・動画入力に対応。 | Moderato+ (Allegretto+ 用 1M) |
k3-256k |
Kimi K3 | 256k | K3 と同等の結果; クオータ消費削減; 画像入力のみ。 | Moderato+ |
kimi-for-coding |
Kimi K2.7 Code | 256k | 日常的な開発とコード補完に最適化。 | 全メンバー |
kimi-for-coding-highspeed |
K2.7 Code HighSpeed | 256k | 標準 K2.7 の 5–6 倍高速出力; クオータ使用は 3 倍。 | Allegretto+ |
コンテキスト管理と切り替え
K3 の 256k バージョンと 1M バージョンを切り替えることで、開発者はコストと容量のバランスを取れます。Kimi は「バースタブルコンテキスト」ワークフローをサポートしており、ユーザーはセッションの即時ニーズに応じてコンテキストウィンドウをスケールできます。
K3 (1M) から K3-256k への切り替え
コンテキストウィンドウをダウングレードする際は、現在のセッションが 256k トークンを超えていないことを確認する必要があります。超えている場合、Kimi Code CLI や Claude Code などのツールが「コンパクト」操作を実行します。Kimi は、重要なタスクポイントを保持しセッションの整合性を保つために、切り替え前に手動でコンパクトコマンドを実行することを推奨しています。
K3-256k から K3 (1M) への切り替え
256k バージョンから 1M バージョンへはキャッシュに影響を与えずに直接切り替え可能です。これは、256k 限界に近づいたセッションで、情報を圧縮せずに追加のスペースが必要な場合に最適です。
キャッシュ無効化
モデル ID を変更したり reasoning_effort 設定を変更したりすると、既存のコンテキストキャッシュが無効化されます。これによりモデルはコンテキストを再度プリフィルする必要が生じ、トークン消費が増加し、一時的な使用量スパイクが発生する可能性があります。オーバーヘッドを最小化するため、Kimi はモデル切り替え時に新しいセッションを開始するか、セッション全体で一貫した推論努力を維持することを推奨しています。
技術設定と API 統合
Kimi Code API は OpenAI と Anthropic の両プロトコルをサポートしています。サードパーティツールで K3 を使用する場合、フル 1M 容量を利用するためにコンテキストウィンドウを 1048576 に手動で設定する必要があります。多くのツールはデフォルトで小さめのウィンドウを使用しています。
推論努力マッピング
K3 は 3 つの推論努力レベルをサポートしています。サードパーティツール経由で統合する際のマッピングは以下の通りです:
- Max:
ultra、max、またはxhighによってトリガーされます。 - High (Default):
high、medium、またはnull/undefinedによってトリガーされます。 - Low:
low、minimum、またはlightによってトリガーされます。 - Disabled:
noneによってトリガーされ、K2.6 にルーティングされます。
コミュニティの洞察と分析
業界関係者や Hacker News のユーザーは、K3-256k の導入がコンテキスト長に基づく階層型価格設定の広がりを示すものだと指摘しています。これは OpenAI で見られる実装と類似しています。
"大量のアクティブコンテキストはトークンあたりのコスト（トークンあたりのフロップスとバイト読み取り）を増加させるため、そのコストをユーザーに転嫁するのは理にかなっています。"
一部のユーザーは、256k の制限が実用的な価値を持つと指摘し、ほとんどのコーディングタスクはこの閾値を超えないため、1M ウィンドウは「贅沢」だが日常開発には必ずしも必要ではないと述べています。別のユーザーは、米国拠点の AI ラボと競争するために、低コストで高性能モデルを提供する戦略的重要性を強調しています。