Kimi K2.7-Code: トークン効率が改善されたオープンソースのコーディングモデル
(huggingface.co)- 長期的なコーディング作業と複雑なソフトウェアエンジニアリングのワークフローを扱うエージェント型コーディングモデルで、Kimi K2.6をベースにエンドツーエンドのタスク完了能力とトークン使用効率を高めた
- Kimi K2.6比で思考トークン使用量を約30%削減し、Kimi Code Bench v2は50.9から62.0、MCP Mark Verifiedは72.8から81.1へ向上
- モデル構造はMoEベースで、総パラメータ数1T、アクティブ32Bパラメータ、256Kコンテキスト長、MoonViTビジョンエンコーダを備える
- デプロイは公式APIとvLLM、SGLang、KTransformersを対象とし、Kimi-K2.5/Kimi-K2.6と同じアーキテクチャのため既存のデプロイ方法を再利用できる
- 使用時はThinkingモードとpreserve_thinkingが強制され、画像入力をサポートし、動画入力は現在公式APIでのみ実験的にサポートされる
モデル概要
- Kimi K2.7-CodeはKimi K2.6ベースのコーディング中心エージェントモデルで、現実的な長期コーディング作業で改善されている
- 複雑なソフトウェアエンジニアリングのワークフロー全体におけるエンドツーエンドのタスク完了能力を強化
- Kimi K2.6と比べて思考トークン使用量を約**30%**削減し、トークン効率を高めた
- 画像・テキスト入力、Transformers、Safetensors、conversational、custom_codeなどのタグ付きで提供される
モデル要約
- アーキテクチャは**Mixture-of-Experts(MoE)**で、総パラメータ数は1T、アクティブパラメータ数は32B
- レイヤー数はDenseレイヤーを含めて61で、Denseレイヤーは1つ
- Attention Hidden Dimensionは7168、MoE Hidden Dimensionはエキスパートごとに2048
- Attention Headは64、Expertは384、トークンごとに選択されるExpertは8、Shared Expertは1
- 語彙サイズは160Kで、コンテキスト長は256K
- AttentionメカニズムはMLA、活性化関数はSwiGLU
- ビジョンエンコーダはMoonViTで、ビジョンエンコーダのパラメータ数は400M
評価結果
-
コーディングベンチマーク
- Kimi Code Bench v2ではKimi K2.6は50.9、Kimi K2.7 Codeは62.0、GPT-5.5は69.0、Claude Opus 4.8は67.4を記録
- Program BenchではKimi K2.6は48.3、Kimi K2.7 Codeは53.6、GPT-5.5は69.1、Claude Opus 4.8は63.8を記録
- MLS Bench LiteではKimi K2.6は26.7、Kimi K2.7 Codeは35.1、GPT-5.5は35.5、Claude Opus 4.8は42.8を記録
-
エージェントベンチマーク
- Kimi Claw 24/7 BenchではKimi K2.6は42.9、Kimi K2.7 Codeは46.9、GPT-5.5は52.8、Claude Opus 4.8は50.4を記録
- MCP AtlasではKimi K2.6は69.4、Kimi K2.7 Codeは76.0、GPT-5.5は79.4、Claude Opus 4.8は81.3を記録
- MCP Mark VerifiedではKimi K2.6は72.8、Kimi K2.7 Codeは81.1、GPT-5.5は92.9、Claude Opus 4.8は76.4を記録
-
評価条件
- 別途明記がない限り、Kimi K2.7 CodeとK2.6はKimi Code CLIでThinkingモードを有効にし、temperature 1.0、top-p 0.95、262,144トークンのコンテキスト長でテストされた
- GPT-5.5はCodexのxhighモードで実行され、Opus 4.8はClaude Codeのxhighモードで実行された
- そのほかの差異を除けば、すべてのベンチマークは同じ条件で評価された
-
ベンチマーク構成
- Kimi Code Bench V2は現実的なタスクでコーディングエージェントを評価する内部ベンチマークで、10以上の主要プログラミング言語とプロダクション技術スタック全体を扱う
- Kimi Code Bench V2は社内エンジニアリングのユースケース、プロダクション障害、実際のオープンソースプロジェクトのタスクを含む
- Program Benchはコンパイル済みバイナリと文書だけでプログラムの動作を再現することを要求し、200件のタスクと248,000件以上のファズ生成動作テストを使用する
- MLS-BenchはAIシステムが汎化可能でスケーラブルなML手法を作れるかを評価し、MLS-Bench-Liteは公式30タスクのサブセット
- Kimi Claw 24/7 Benchは継続的な複数日共同作業における長期エージェント性能を評価する内部ベンチマークで、17の専門シナリオと610の評価ポイントを扱う
- MCP-AtlasはスケーラブルなMCPを通じて現実的なツール使用タスクでのLLM性能を評価する
- MCPMark-VerifiedはMCPMarkの人手検証版で、Notion、GitHub、Filesystem、Postgres、Playwrightなど5つの実際のサーバー環境でMCPツール使用を評価する
Native INT4量子化
- Kimi-K2.7-CodeはKimi-K2-Thinkingと同じnative int4量子化方式を採用
デプロイ
- Kimi-K2.7-Code APIは https://platform.moonshot.ai で利用できる
- 公式APIはOpenAI/Anthropic互換APIを提供する
- 推奨推論エンジンはvLLM、SGLang、KTransformers
- Kimi-K2.7-CodeはKimi-K2.5/Kimi-K2.6と同じアーキテクチャのため、デプロイ方法をそのまま再利用できる
transformersのバージョン要件は>=4.57.1, <5.0.0- デプロイ例はModel Deployment Guideで確認できる
使い方
-
API呼び出しの基本条件
- 利用デモは公式API呼び出し方式を基準とする
- Kimi-K2.7-CodeはThinkingと
preserve_thinkingをTrueに強制する - vLLMまたはSGLangでデプロイしたサードパーティAPIでは、動画コンテンツチャットは現在公式APIでのみサポートされる実験機能
- Thinkingモードの推奨
temperatureは1.0、推奨top_pは0.95 - Instantモードはサポートされない
-
Chat Completion
- Chat Completionの例ではK2.7-Code APIをThinkingモードで呼び出す
- サンプルコードは
openaiクライアントでclient.chat.completions.createを呼び出し、max_tokens=4096を設定する - 応答では
response.choices[0].message.reasoningとresponse.choices[0].message.contentを出力する
-
視覚コンテンツ入力
- K2.7-Codeは画像と動画入力をサポートする
- 画像入力の例では画像をbase64でエンコードして
image_urlに渡し、max_tokens=8192で応答を生成する - 動画入力の例ではmp4ファイルをbase64でエンコードして
video_urlに渡す - 動画チャットは現在、公式APIでのみサポートされる実験機能
-
Preserve Thinking
- Kimi K2.7 Codeは
preserve_thinkingモードを強制し、マルチターンのやり取りで完全なreasoningコンテンツを保持する preserve_thinkingはコーディングエージェントのシナリオで性能を高める- この機能はデフォルトで有効化されており、無効にはできない
- 一部のAPIは
reasoning_contentをサポートしない場合があり、その場合はreasoningを試せる
- Kimi K2.7 Codeは
-
Interleaved Thinkingと多段階ツール呼び出し
- K2.7-CodeはK2 Thinkingと同じInterleaved ThinkingおよびMulti-Step Tool Call設計を共有する
- 利用例はK2 Thinking documentationを参照
-
コーディングエージェントフレームワーク
- Kimi K2.7-CodeはエージェントフレームワークとしてKimi Code CLIと併用したときに最もよく動作する
- Kimi Code CLIは https://www.kimi.com/code で提供される
ローカル実行例
-
Transformers
- Transformersでは
pipeline("image-text-to-text", model="moonshotai/Kimi-K2.7-Code", trust_remote_code=True)方式で高水準パイプラインを作成できる - モデルの直接読み込みは
AutoModel.from_pretrained("moonshotai/Kimi-K2.7-Code", trust_remote_code=True, dtype="auto")方式で可能
- Transformersでは
-
vLLM
- vLLMは
pip install vllmでインストールし、vllm serve "moonshotai/Kimi-K2.7-Code"でサーバーを起動する - 呼び出し例ではOpenAI互換APIエンドポイント
http://localhost:8000/v1/chat/completionsを使用する - Docker Model Runnerでは
docker model run hf.co/moonshotai/Kimi-K2.7-Codeで実行する
- vLLMは
-
SGLang
- SGLangは
pip install sglangでインストールし、python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K2.7-Code"でサーバーを起動する - 呼び出し例ではOpenAI互換APIエンドポイント
http://localhost:30000/v1/chat/completionsを使用する - Docker実行例ではGPU、共有メモリ、Hugging Faceキャッシュ、
HF_TOKEN環境変数を設定する
- SGLangは
ライセンス
- コードリポジトリとモデル重みはModified MIT Licenseで配布される
1件のコメント
Hacker Newsの意見
修正されたライセンス条項を読んで笑ってしまった。実質的にはMITライセンスに昔のBSDにあった広告条項を1つ足した形で、月間アクティブユーザー数や売上に関係なく、製品で使うなら自分たちを「宣伝」してほしいという要求に近い
正直、合理的な要望に見える
Kimi K2.7-codeにかなり単純な指示だけを与えて、Fil-C OpenSSLパッチを3.3.1から3.5.7へリベースしたが、うまくいったように見える
パッチサイズは177KBで小さな変更ではなく、最初はきれいに適用されなかったので、エージェントがかなり実質的な作業をする必要があった
3.3.1向けのパッチ、ビルドコマンド、3.5.7のパス、変更ドキュメントのリンク(https://fil-c.org/constant_time_crypto)だけを渡した
ただし独自のコーディングエージェントであるT800を使っており、公開されているものではなく、以前にK2.5向けとして十分にテストしチューニングしていた状態だった
API利用料は**$5〜$10**の間だったと思う。訂正: OpenSSHではなくOpenSSL
個人的にはオープンコードやルーターを使うとき、あるレベルを超えるとモデル差はあまり大きく感じない。高価で微妙なGeminiのようなモデルは例外だ
そういう意味では、中国製モデルはかなり良い。たいてい関数やメソッド単位でコードを書かせ、その後に設計して組み立てる形で使っている
GPT系のほうがより丁寧で優れてはいるが、差がものすごく大きいかというとよく分からない。ワークフロー次第だろうが、十分に厳格に扱えば本当に大差があるのか疑問だ
MacBook M1 Proを暖房パッドにしながらQwen 3.6 35B A3B MTPを回してみたのは、ある程度うまくいった
Geminiモデルを「ローカル」のように使おうとすると、努力量を短く刻むためミスが増え、ターン数が増えるという似た問題があった
逆にFableがしつこく「先回りしてくれる」と言われているのを見ると、強いブランディングと効果的な課金があれば、正反対の方向も可能に見える
一貫した設計がすでにあれば、それが難しい部分なのだが、かなり小さいモデルに入れてもほぼ同じ品質が得られる
一発で完成はしないが、より速くて安いので、結局は有利に働く。しかもローカルでも可能だ
そのため、コメントアウトされたテストがビルドを壊すよう明示的にしておく必要がある。AnthropicやOpenAIのモデルでは、個人的にはそういう問題を経験していない
昔、車を「日本車」と呼んでいたのに近いが、今ではほとんど意味がなく、単にToyota、Honda、Lexusと呼ぶようなものだ
opencode + Kimi K2.6/2.7をClaude Codeと比較して使ってみた人がいたら、本当に気になる。何が良くて何が悪いのか、コスト比較がどうなのか知りたい
今は5x Maxプランに$100払っているが、Fableが使用上限をかなり早く消費するし、Opusと比べて昼と夜ほどの差があるとも言い切れない
主にサイドプロジェクトで使っているので、$100の請求でもかなり大きく感じるし、これ以上払いたくはない
Claude Codeのほうが優れてはいる。だが、opencode + Kimi 2.6も十分実用になるという点が大きい
やりたいことを正確に把握していて単純なコード作成だけをさせるなら、DeepSeekやKimiのような人気モデルもたいてい問題なく、Anthropicのモデルと大差ないように感じる
一方でOpusは、DeepSeekより意図をはるかによく理解する。DeepSeekを使うときはプロンプトをずっと正確に書く必要があり、雑に書くとしばしば見当違いの方向へ進む
Kimiはその中間だ。"緩いプロンプト"の流れをある程度取り戻してくれて、DeepSeekよりも計画を信頼できる
Claude Codeに近い作業フローは可能だが、全体的には少しずつ劣る。コンテキスト長、エラー数、意思決定、提案、デバッグ能力のすべてがやや弱い
利用量の面では、$100のClaudeプランは実際かなりコスパが良い。トークン単価ではKimiのほうがずっと安いが、Claudeのサブスクはかなり補助されているようで、$100でAPIで買えるよりずっと多くのトークンを受け取れる
結局、似たような利用パターンならopencode + KimiとClaude Codeのコストは近くなる可能性がある
DeepSeekはさらに安く、キャッシュトークンが信じられないほど安いが、Claude Codeから移る場合は、慣れに応じて作業の仕方を調整する必要があるかもしれない
サイドプロジェクトなら、$10 Opencode GoプランにOpenRouterのような場所でDeepSeek v4クレジット $10を足す構成がかなり実用的だと思う
Kimiは面接を受ける開発者のような感じで、より面白い。問題を推論していく過程を見るのが、ホワイトボードセッションで自分が説明するやり方に似ている。"wait"をあまりに頻繁に言うので笑ってしまう
Claudeは、すでに採用された社員や社員チームに近い。最初から長い説明をあまりせず、必要なときだけ質問して、その後で総合的なレポートや計画を出してくる
OpenCodeはより良いハーネスだと思う。コストについては、同じプロンプトを両方で正確に回したことがないので直接比較はできない
最近KimiにZenCプログラミング言語向けのlibpqラッパーを作らせた(https://github.com/nobleach/zenc-postgres)が、約1時間かかり、コストは約$4だった
DeepSeek-V4-Proは十分に良く、HaikuやSonnetに任せそうな作業や小さな作業にはDS4-Flashを使えばいい。$10前払いで登録すればよい
OpenCode Goは月$5で契約して、Qwen-3.7-Maxを設計、計画、アーキテクチャ、難しい問題解決に使えばいい。DeepSeekよりもOpus 3.6や3.7に近い感じで、見つけた中では最も近かった
OpenAI Codexは月$20プランでGPT-5.5をAPIとして設計、計画、アーキテクチャ、問題解決、コミット作成に使える。本当に難しい問題は$100を払ってGPT-5.5-Proチャットにコピーして貼り付けることもできる
Xiaomi MiMo-2.5-Proは、友人から$2の紹介コードをもらって72セントの無料クレジットを受け取れる。価格はDeepSeekと同じで、SonnetとOpusの中間あたりのかなり有能なモデルだ。UltraSpeedベータにも申し込む価値がある
OpenCodeやohmypiでこれらのモデルをその場で切り替えながら、自分にいちばん合うものを見つければいい。CodexBarでほぼリアルタイムの使用量を確認している
軽いユーザーやプログラミング初心者には、Cursorの$20プランがComposer-2.5とComposer-2.5-Fastで始めるのに向いている。API割り当てもあるので、Cursor自体以外にOpenCodeやohmypiからOpus-4.xやGPT-5.5-Proにもアクセスできる
GrokやTwitterを使うなら、月$30のSuperGrokに良いビジョンモデルがあり、フロントエンドの自動テストに使っていた。ただ、今は一般的なMacでローカルQwen-3-VLへ移行中だ。技術にあまり慣れていないなら、unreachがMacでのローカルモデルホスティングを簡単にしてくれる
RTX 5090のような強力なGPUがあるなら、Qwen-3.6もローカルで試す価値がある。ollamaやllama-swapを使えば比較的簡単だ
新しいKimiはまだ使っていないが、プロの開発者3人、MidjourneyとGrok Imagineをよく使うグラフィックデザイナー1人、要件収集と実装追跡にohmypiを使う非技術ユーザー1人のチームを運営しながら、従業員1人あたり月**$200以下**にコストを抑えている
もう少し工夫すれば、従業員1人あたり月$75にさらに近づけると思う
動かない唯一の機能はwebfetchとウェブ検索だが、ddg MCPとウェブ取得/検索のpre-hookでエージェントを迂回させて置き換えた
メモリ、キャッシュなど他は問題なく動作している
Qwenは計画立案ではOpusに近いが、Fableのほうが明らかに優れている
コーディングは、Opusが計画を書いてくれればKimiとDeepSeekの結果はOpusとほとんど見分けがつかない
最大の違いは出力のリズムだ。たとえばKimiは長く考えたあと、多くのテキストを素早く出力する
今は調査と計画にFable、コーディングにDeepSeek v4 flashを試している。結果はOpus + DeepSeek v4 proに近く、全体コストはもっと低くなりそうだ
良いし、投げた大半の作業はうまく処理するが、認知的に複雑な作業は失敗する。頻繁に詰まる。それでも月約$6だ
「最高」のモデルが重要でなくなる臨界点があり、そこまでは遠くないと思う。Fable は今本当に良いが、1年ほど後に Kimi が追いつけば、Fable6 がはるかに良くても価格が 1/10 なら Kimi を使う気がする
以前 Opus 4.5 を見て、「これほど良ければ 6〜12か月以内に中国モデルがここまで良くて安くなるだろうから、そちらを使うだろう」と思っていたが外れた。今でも Opus 4.7/8 と Fable にプレミアムを払っている
それでも、いつかは単にやりたい仕事をこなせる水準になり、その時点からは 値下げ競争 が始まるだろう
いまや中国企業も非常に優れた Fable トークンにアクセスできるのだから、その競争が加速してほしい
だからトークン単価が高くても、より良いモデルのほうが実際には安いこともある
Opus が Kimi K2.6 や他の中国モデルより 5倍高い のに、ほんの少し良い程度だとしたら、Anthropic のような企業がどうやって競争力を維持しているのか不思議だった
私の仮説は、米国企業はデータを中国側に送れないということだが、それは理解できる。とはいえ、それは本当に「堀」なのだろうか?
Kimi モデルをかなり頻繁に使っていて、概ね気に入っている立場から言っている
まだゲーム化されていない DeepSWE のようなベンチマークでは、Kimi K2.6 は Claude Sonnet 4.6($3/$15) に大きく劣り、GPT 5.4 Mini($0.75/$4.50) にもやや劣る
Kimi モデルが多くのコーディング作業で非常に優れており、オープンウェイトモデルの中で品質が最も高いのは確かだ
しかし Sonnet/Opus と同等の全体的な結果を得るには、平均してはるかに多くのトークンを使い、モデルをより多く管理しなければならない
トークン単価ではなく、プロセス全体にいくら払うかを見るべきだ
また多額の費用を使うケースでは、評価を回す合理的な主体が十分にいるので、「少し良い」が純粋な感覚だけではない可能性も高い
ただ、私が直接見られる評価スイートは一部だけだ。全員が非合理で、Anthropic がそれを利用しているだけかもしれない
Kimi や他のオープンソースモデルは SWE-bench のような場では高得点を出せるかもしれないが、実際に使うと差を体感する
奇妙なことに、誰もが API 価格を根拠に Claude のサブスクリプションは補助金付きだと言うが、実際の Claude 推論コストを知っている人はいないし、中国の提供者も安価な推論を提供できる。だとすれば、なぜ Claude にはそれができないと考えるのか不思議だ
企業顧客向けには公開されていない別の API 価格契約があるのかもしれない。私たちが見ているのは高い表示価格だけなのかもしれない
そうしたタスクでは差が崖のように大きい
きちんとテストしてみると、かなり良い改善に見える。同じ作業で 使うトークンが少ない というだけでも、オープンモデルが必要なときに K2.6 の代わりに使う十分な理由になる
DeepSeek v4 より 20〜30% ほど明確に優れていない新モデルが、DeepSeek よりトークン単価が高いなら、ほぼ自動的に 低利用モデル に押しやられると思う。計画立案用くらいには使えるかもしれないが
まだ オープンウェイト／オープンソースモデル にはあまり慣れていない。仕事で本格的に使っている人がいたら、設定や性能について聞いてみたい。組織を Anthropic 製品から移行することを検討している
モデル品質の面では大きな差はないが、コスト差は信じられないほど大きい。少なくとも自分のエージェントの使い方ではそうだ。
昨日の例では、複雑な技術文書を検索するための小さな DSL を開発していて、小さな演算子を追加しようとして Fable を試した。
Fable は $13 を消費し、解決策は出したが、同じ作業を DeepSeek v4 が $1.7 でやったものより客観的に優れているわけではなかった。
ただし自分はエージェントに細切れの作業を任せている。DSL の場合、演算子は自分で設計し、エージェントには 1 つずつ実装させた。
複雑な文書から始めて全体を設計しろと頼んでいたなら、Fable が輝いたかもしれない。
しかしエージェントにより広い範囲の作業を与えるたびに何百万トークンも消費し、怪しいコードを生成するので、結局自分が時間をかけて理解しなければならなかった
たとえば https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r... のようなファイルを見ると、使ったモデルを明記してある。
4.7 は
goコードにはあまり向いておらず、そのため attribution にGemini 3 Flashが見え始めた。4.7 は Cerebras が提供しているモデルで、自分にとっては反復速度のほうがずっと重要だ。
MiMo v2.5.0-Pro を使ってみた結果、Gemini 3 Flash がやったことは 100% こなせただろうと確信している。
何度か詰まったときは Sonnet に説明してもらう必要があったが、Anthropic と OpenAI が言わない汚い秘密は、コーディングができるならモデルは正直もう十分に良いということだ。
MiMo の経験と GLM 5.1 に対する他の人たちの評価を見ると、もう ハードウェア競争 に入ったと思う。
プログラミングができて、AI で自分の知識を増幅したい人にとって、中国モデルは Claude の 100% 代替になる。
これからは、どのプロバイダが最速の推論を提供するかを見ることになるだろう。
MiMo-v2.5.0-Pro-Ultraspeed は良い結果を素早く生成し、同時にお金も素早く燃やす
主な例外は 30B パラメータ前後のモデルで、これらはまだ民生用 GPU で動かせる。
ただし民生用 GPU もここ数年でどんどん高価になっており、正当化しにくくなっている
GPT もずっと試しているが、かなり堅実だ。非常に速く、デバッグも優れている。ただコードはしばしば妙に賢すぎて頭が痛くなる。
プロンプトで直せるのかもしれない。中国モデルには少し効果があった。昔の画像 AI 時代の「+good -bad」みたいに、エレガントにやれと言えばよい。
今のところ、やはり人間がコードを理解できなければならず、その要件を一貫して満たしているのは Claude だけだ。
それでも、いつか中国の研究所のどこかが特別な秘訣を見つけてくれることを願っている。
小さな修正には DeepSeek Flash がとても良い。ほとんど無制限の AI がすぐ横についているような感覚で素晴らしい
128GB メモリの M4 Max MacBook Pro で動かしている。
たいていはサーバーとして動かし、コーディングマシンからは Tailscale で接続して Pi コーディングエージェントを使う。
Qwen モデルを使っていた頃より大きな飛躍だが、ビジョン機能はないので、ビジョンが必要なときは今でもそちらのモデルを動かす。
以前は GLM 4.7 flash をコーディングの主力にしていたが、ビジョン以外のすべての作業は完全に DeepSeek に移した
中国製オープンウェイトモデルから CCP 要素 を除去してみた人がいるのか気になる。皮肉ではなく、ウェイトの耐性検査や概念活性化のような手法で徹底的に調べたのかを聞いている。
たとえば、CCP が実際に文脈依存の振る舞いを埋め込もうとしていたなら、欺瞞的または悪意ある行動を誘発しうる入力にどう反応するかを見る、といった形だ。
米国政府向けアプリケーションで使われると脆弱なコードを生成するという疑惑のようなものが、実際に立証されたのかはわからない。
地政学的競争が激しい時代には、こうした問いは不合理ではない。どの国に住んでいても当てはまる問いだ
ドイツのコンサルティング会社で、DeepSeek モデルをチューニングしてバイアスを除去するという発表を見たことがある。かなり興味深かった。
https://www.tngtech.com/en/about-us/news/release-of-deepseek...
心配すべきなのはコードだけでなく、潜在的なメッセージングのような他のものもある
https://github.com/p-e-w/heretic