Kimi K3-256k

 (kimi.com)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • Kimi K3-256k は、K3 の結果品質を 256k コンテキストで維持しつつ、1M コンテキストの k3 より 割り当てを約半分しか消費しない 日常的なコーディング向けモデル
  • Kimi Code は K3 と K2.7 Code を 4 つのモデル ID で提供しており、k3 は 2.8T パラメータと最大 1M コンテキストをサポートし、kimi-for-coding-highspeed は約 5〜6 倍速い出力 の代わりに割り当てを 3 倍使用
  • k3 から k3-256k に切り替える際、既存のコンテキストが 256k を超えているか動画が含まれている場合は、まず compact を実行することで中核情報を保持しながら互換性を維持できる
  • モデルまたは reasoning_effort を変更すると、既存の コンテキストキャッシュが無効化 されて再度プリフィルが必要になるため、使用量が増える可能性があり、新しいセッションで切り替える方法が推奨される
  • 利用可能なモデルとコンテキストは料金プランによって異なり、権限を超えると 401 が返される。サードパーティーツールでは 正確なモデル ID とコンテキストサイズ・推論強度を直接設定する必要がある

Kimi Code のモデル構成

  • Kimi Code は Kimi K3 と Kimi K2.7 Code を 4 つのモデル ID で提供
    • k3: 2.8T パラメータのフラッグシップコーディングモデルで、上位プランでは最大 1M コンテキストをサポート
    • k3-256k: Kimi K3 の 256k コンテキスト版で、消費量削減に重点を置く
    • kimi-for-coding: コード補完と日常的な開発作業に適した Kimi K2.7 Code
    • kimi-for-coding-highspeed: 同じコーディング能力で約 5〜6 倍速い出力 を提供する K2.7 Code HighSpeed
  • モデルごとの仕様と利用条件は以下のとおり
    • k3
      • 通常速度で動作し、上位会員には最大 1M コンテキスト を提供
      • reasoning_effort は low, high, max をサポートし、デフォルトは high
      • Moderato 以上で利用でき、1M コンテキストは Allegretto 以上で提供
      • 画像と動画を入力できる
    • k3-256k
      • 通常速度で動作し、コンテキストは 256k 固定
      • reasoning_effort は low, high, max をサポートし、デフォルトは high
      • Moderato 以上の会員が利用可能
      • 画像のみ入力可能で、動画はサポートしない
    • kimi-for-coding
      • 通常速度と 256k コンテキストを提供し、すべての会員が利用可能
      • Thinking:ON で動作し、画像と動画をサポート
    • kimi-for-coding-highspeed
      • 256k コンテキストで約 6 倍速く出力するが、割り当てを 3 倍使用
      • Allegretto 以上で利用可能で、Thinking:ON、画像・動画入力をサポート

K3-256k の用途とモデル切り替え

  • k3-256k は 256k コンテキスト範囲で k3 と同じ結果を提供しながら、1M 版より割り当て消費を約半分に抑える
  • 日常的な質疑応答、コード補完、一般的な機能開発、単一ファイルまたは小規模ファイルの編集に適しているが、動画入力はサポートしない

  • K3 から K3-256k へ切り替え

    • 現在のセッションコンテキストが 256k を超える場合、Kimi Code CLI や Claude Code など一部のツールは自動で compact を実行する
    • エージェントツールごとに処理方式が異なるため、切り替え前に compact を手動で一度実行し、コンテキストを 256k 以内に圧縮することが推奨される
    • これにより、作業の中核内容を保持しながらセッションを維持できる
    • 切り替え後は割り当てをより長く使える
    • 会話履歴に動画ファイルがある場合、k3-256k に直接切り替えられないため、先に compact を実行する必要がある

  • K3-256k から K3 へ切り替え

    • k3-256k が 256k 上限に近く、compact による情報損失を避けたい場合は、k3 1M に直接切り替えられる
    • 現在のバージョンでは、256k から 1M への切り替えでもキャッシュに影響しない

キャッシュと使用量の管理

  • モデルを変更すると、前のモデルで構築した コンテキストキャッシュがヒットしなくなり、そのコンテキストを再度プリフィルする必要がある
  • このため、切り替え直後は使用量が増えたように見えることがある。新しいモデルを使うときは、新しいセッションを開始するほうが、より良い結果と低い消費量につながる

  • 推論強度切り替えコスト

    • reasoning_effort を変更しても既存のコンテキストキャッシュが無効化され、再度プリフィルが必要になる
    • 作業に合った推論強度を選んだら、1 つのセッション内では一貫して維持することが推奨される
    • 別の推論強度が本当に必要なら、長いセッションで繰り返し切り替えるのではなく、新しいセッションを開始 するほうがよい

料金プラン権限と 401 エラー

  • 正しいモデル ID を使っても、要求した機能が料金プランの権限を超えるとサーバーは 401 を返す
    • K3 アクセス権限なし: Moderato 未満のプランでは k3 と k3-256k を呼び出せない
    • 1M アクセス権限なし: Moderato では k3 は最大 256k まで対応し、最大 1M は Allegretto 以上で利用可能
    • k3-256k のコンテキスト上限はプランに関係なく 256k 固定
    • HighSpeed アクセス権限なし: kimi-for-coding-highspeed の利用には Allegretto 以上が必要
  • 完全なエラーメッセージと対処方法は Error Reference で確認できる

HighSpeed が速く感じられない理由

  • HighSpeed のモデル ID は正確に kimi-for-coding-highspeed でなければならない
    • 誤って入力すると、エラーなしで標準の kimi-for-coding に置き換えられ、速度向上が現れない
  • HighSpeed は モデル出力のみを高速化 する
    • ファイルの読み書き、コマンド呼び出し、スクリプト実行は速くならない
    • 1 回の作業でツールやスクリプト実行の比重が高い場合、全体の速度向上は小さく感じられることがある

クライアントでモデルを切り替える

  • モデル ID を変更するとコンテキストキャッシュが無効化される。追加トークン消費を避け、最適な利用体験を得るには、新しいセッションを開始 することが推奨される
  • 呼び出し時にはモデルのバージョン名ではなく、次のいずれかのモデル ID を入力する必要がある
    • k3
    • k3-256k
    • kimi-for-coding
    • kimi-for-coding-highspeed
  • Kimi K3 や K2.7 Code のようなバージョン名を入力すると呼び出しに失敗する
  • K3 または K2.7 で Thinking をオフにすると、リクエストは K2.6 にルーティング されるため、K3 や K2.7 Code を使うには Thinking をオンにする必要がある

  • 公式クライアント

    • Kimi Code CLI では /model を入力して設定変更なしでモデルを切り替えられる
    • 最新モデルが一覧にない場合は、/logout の後に /login で再ログインする必要がある
    • Kimi Code for VS Code では、入力欄のドロップダウンメニューからモデルを選択する
    • モデルが表示されない場合は、VS Code を再起動するか拡張機能を再インストールする必要がある

サードパーティーツール設定

  • Kimi Code Console で API Key を作成した後、ツールに Base URL とモデル ID を入力する
  • Kimi Code API は OpenAI 互換プロトコル と Anthropic 互換プロトコル の両方をサポート
  • ツールごとの設定方法は以下のドキュメントで確認できる
    • Claude Code: Anthropic のコマンドラインコーディングアシスタント
    • OpenCode: ターミナルベースのコーディングエージェント
    • Codex: OpenAI のコーディングエージェント

  • K3 コンテキスト設定

    • 一部のサードパーティーツールのデフォルトコンテキストは、K3 の最大値である 1M より小さい
    • 最大 1M コンテキストを使うには、context-window フィールドを 1048576 に手動設定する必要がある

  • K3 推論強度マッピング

    • K3 は low, high, max をサポートし、ツールが送信した値は次のようにマッピングされる
    • null または undefined: デフォルト値 high
    • 不明なその他の値: HTTP 400 エラー
    • ultra, max, xhigh: max
    • high, medium: 推奨レベルの high
    • low, minimum, light: low
    • none: thinking.type が無効化される

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsのコメント

  • Codexは256kコンテキストを非常にうまく活用している。1Mは余裕があるが、依然として高価で、デフォルトとしては不要に思える

  • LLMは急速に汎用コモディティになりつつあり、OpenAIのような米国のAI研究所の堀は弱まりつつある。最終的には安価なトークンを販売できるハイパースケーラーやデータセンター所有者が勝つ可能性が高い

    • 他の製品はあまり使っていないが、Codexハーネスは乗り換えが難しいほど魅力的だ。このレベルの品質のハーネスを提供しているところが他にもあるのか気になる
    • 個々のモデルに莫大な資本と複雑な研究開発を投入してきたフロンティアAI企業には深く感謝している。ここまで来るのにどれほど大きなコストがかかったのか、もう忘れがちなくらいだ

  • k3-256kがリリースされ、256kコンテキスト内では同じ結果を提供する。k3 (1M)はk3-256kよりクォータをおよそ2倍消費する

  • いい変更だ。普段はコンテキストを200k以下に保つようにしている

    • このニュースのRedditスレッドでもまったく同じ文がトップコメントだ
      https://www.reddit.com/r/kimi/s/BFa1TR9vNg
    • 作業範囲によるが、適切なポイントは500k以下だと思う。Claudeでは50万トークンあれば、最初から現在までのすべての文脈を維持しつつ、かなり大規模なプロジェクトを構築できる
    • 「256kで誰にでも十分なはずだ」

  • ということは、すべてのユーザーはコンテキストが256kに達するまで、Kimiを突然半額で使えることになるのだろうか。本当なら大きな変化だ

    • 別モデルなので、k3-256kを使っていて256kで1Mモデルに切り替えるとキャッシュが無効化され、既存の256kトークンも1Mモデル価格で再度支払うことになると思っていた
      しかしこれは誤りで、コンテキスト上限に近づいたときにキャッシュ無効化なしで1Mモデルへ切り替えられる。現行バージョンではk3-256kからk3 (1M)に変えてもキャッシュには影響しない
    • そうではないと理解している。コンテキストウィンドウが小さいと、時間とともに蓄積される入力トークンが減るので、一般的にはより安くなるという意味だと思う

  • この投稿から38分が経っていて、20分前からAnthropicの複数のサービスが大規模障害として表示されている。関係はないだろうが、少し面白かった

  • モデル自体は同じで、APIレベルの変更にすぎないようだ

  • 一定のコンテキスト長を超えると価格帯が変わるOpenAIの方式と、機能的には似ている。基準も約272k、つまり2^18または256k付近だ
    アクティブコンテキストが大きくなるほど、出力トークンあたりに必要な計算量と読み込むべきバイト数が増えるため、そのコストをユーザーに転嫁するのは合理的だ。ただ、段階的なしきい値ではなく、なだらかな価格曲線を使っていないのは意外だ

    • 最大シーケンス長に応じて2種類のインフラ構成を運用している可能性が高いので、段階的なしきい値は不思議ではない
      短いコンテキスト構成では、インスタンスごとのプリフィル専用ノードが少なくて済み、大きなKVキャッシュをサポートする必要もないため、全体のノード数も減らせる。分離推論を使えば、プリフィルとデコーディングに割り当てる計算比率もそれぞれ調整できる

  • 今回の変更でインフラ負荷が軽くなることを願う。最近のモデルはどれも明らかに鈍くなっていて、サポートチームも対応していない。リクエストのかなりの部分を量子化モデルで処理しているのではないかと疑っている

    • 根拠のない陰謀論は、RedditならともかくHNにはふさわしくない

  • 量子化されたモデルではなく、単にコンテキストウィンドウだけを256kに縮小しただけなのか気になる

    • 256kコンテキストウィンドウと量子化の有無は別問題だ。外部から直接確認するのは難しいので、実際に量子化されている可能性も排除はできない