ハクソク

世界を動かす技術を、日本語で。

Kimi K3-256k

2026年7月30日原文(kimi.com)

概要

  • Kimi Code は、複数のモデルを提供し、用途やプランに応じて切り替え可能
  • k3-256k と k3 (1M) など、異なるコンテキストウィンドウを持つモデルを用意
  • モデル切り替え時は セッション管理 や コンテキスト圧縮 が重要
  • プランによる制限 やエラー発生時の対処法も明確
  • 各種クライアント・サードパーティツールでの 設定方法 も案内

Kimi Code モデル概要

  • Kimi Code は、 Kimi K3 と Kimi K2.7 Code の2種類のモデルを提供
    • それぞれに対応する 4つのModel ID を用意
  • k3-256k は新たにリリースされた推奨モデル
    • 256kコンテキスト 内で高精度な結果を実現
    • k3 (1M) はk3-256kの約2倍のクオータを消費
  • 日常的なQ&A、コード補完、機能開発、小規模ファイル編集向け
    • 動画入力は非対応
  • モデル切り替え時は セッションのコンテキストサイズ に注意
    • 256k超過時は compact機能 で圧縮推奨
  • 動画ファイル を含む場合、k3-256kへは直接切り替え不可
    • 圧縮後に切り替えが必要

モデルID・バージョン・特徴

  • Model ID一覧
    • k3 ：フラッグシップ（1Mコンテキスト、2.8Tパラメータ）
    • k3-256k ：消費量削減版（256k固定）
    • kimi-for-coding ：K2.7 Code（256k）
    • kimi-for-coding-highspeed ：K2.7 Code高速版（256k、出力6倍速、クオータ3倍消費）
  • Thinking（推論） 設定でK3やK2.7 Codeを利用可能
    • OFFの場合、K2.6へルーティング
  • 利用可能プラン
    • k3・k3-256k ：Moderato以上
    • 1Mコンテキスト ：Allegretto以上
    • HighSpeed ：Allegretto以上
    • K2.7 Code ：全プラン対応

モデル切り替え時の注意点

  • モデル切り替え時は新規セッション推奨
    • コンテキストキャッシュが無効化されるため、トークン消費増加を防止
  • Model IDは正確に入力
    • モデルバージョン名ではなく Model ID を指定
  • 推論モード（reasoning effort） を頻繁に切り替えるとキャッシュが無効化
    • セッション内で一貫した設定推奨
  • HighSpeedが速く感じられない場合
    • Model IDのミス（kimi-for-coding-highspeed以外は標準にフォールバック）
    • ツールやスクリプト処理がボトルネックの場合、速度向上を実感しにくい

エラー・利用制限と対処法

  • 401エラー の主な原因
    • プランが Moderato未満 ：k3/k3-256k利用不可
    • 1Mコンテキスト 未対応プラン：k3で256kまで
    • HighSpeed 未対応プラン：Allegretto以上が必要
  • 新モデル利用開始直後に消費量が増える理由
    • 旧モデルのキャッシュが新モデルでは無効化されるため再プリフィルが発生
    • 新セッション開始で消費量と精度の最適化
  • 詳細なエラー内容・対応方法は Error Reference を参照

モデル切り替え方法

  • 公式クライアント
    • Kimi Code CLI ：/modelで切り替え、最新モデル未表示時は/logout→/login
    • Kimi Code for VS Code ：入力バーのドロップダウンから選択、未表示時はVS Code再起動または拡張再インストール
  • サードパーティツール
    • API Key をKimi Code Consoleで発行
    • Base URL と Model ID をツールに設定
      • OpenAI互換：https://api.kimi.com/coding/v1
      • Anthropic互換：https://api.kimi.com/coding/
  • K3利用時の注意点
    • 一部ツールはデフォルトで1M未満のコンテキスト設定
      • context-windowフィールド を1048576に手動設定
    • reasoning effort はlow / high / maxに対応
      • 未定義や不正値はエラー（推奨：high）

まとめ

  • Kimi Code は用途・プランに応じて最適なモデル選択が可能
  • モデル切り替え時のセッション管理 や エラー対策 が重要
  • 公式・サードパーティ両対応で柔軟な運用が可能

Hackerたちの意見

それはいいね！普段は200k以下に抑えるようにしてるよ。

└

私にとってのベストな範囲は、500k以下かな。どれだけ詳しくやりたいかによるけど。Claudeを使えば、50万トークンでかなりの規模のプロジェクトが作れるし、最初から最後までの文脈を持ってるからね。

└

「256kは誰にでも十分だろう」

└

このコメント、ニュースのredditスレッドで一番上にあるやつだね。https://www.reddit.com/r/kimi/s/BFa1TR9vNg

これはAPIレベルの変更だけだよね？モデル自体は同じだと思うけど。

k3-256kが利用可能になりました。256kの文脈内では、同じ結果を出します。k3（1M）はk3-256kの約2倍のクォータを消費します。

これは量子化されてないよね？ただ文脈が小さいだけ？

└

256kの文脈ウィンドウだよ。量子化は別の話だからね。直接的にはわからないから、量子化されてる可能性もある。

これ、38分前に投稿されたんだけど、20分前にはいくつかのAnthropicサービスが「大規模障害」として指定されてる。これが関係してるとは思わないけど、ちょっと笑っちゃった。

└

Anthropicのサービスは、yで終わる日にはいつも障害があるね。

これは、OpenAIが特定のコンテキスト長を超えると価格が段階的に上がるのと機能的には似てるね（272k、つまり2^18、つまり256kでも）。アクティブなコンテキストが多いと、トークンごとのコストが増えるから、そのコストをユーザーに転嫁するのは理解できる。実際、スムーズなグラデーションじゃなくて、ハードカットオフで実装されてるのには驚いたよ。

└

ハードカットオフなのは驚かないな。おそらく、2つの最大シーケンス長に対して、2つのインフラ構成があるんだろうね。インスタンスごとにプレフィル用のノードが少なくて、KVキャッシュを高くサポートする必要がないから、全体のノードも少なくなる。分散推論のおかげで、プレフィルとデコードに専念する計算のバランスを別々に調整できるし。

Hacker Newsで議論の続きを見る