Kimi K2.6: かつてGonkaが提供していたモデル

Kimi K2.6は、北京の企業Moonshot AIが開発したKimiシリーズの大規模言語モデル（LLM）です。Moonshot AIは中国を代表するAIラボの一つで、2023年にYang Zhilin氏率いる研究者チームによって設立されました。AlibabaやTencentなどの大口投資家から資金を調達し、アジアのAI開発を牽引する「中国のAIタイガー」の一社に数えられています。

Kimiシリーズが知られるようになったのは2024年からです。初期バージョン（K1、K1.5）は、1回のリクエストで最大200,000トークンという極めて長いコンテキストウィンドウで早くも注目を集めました。これはリリース当時、一般公開されているモデルとしては記録的でした。長いコンテキストとは、1回のリクエストで一冊の本、中規模のコードベース、あるいは法律文書の束を丸ごと分析できるという実用性を意味します。Kimiの登場時点で、この特性は強力な競争優位性でした。

K2は2025年に登場し、根本的なアーキテクチャの飛躍をもたらしました — MoE（Mixture of Experts）への移行です。このアーキテクチャはQwen3-235BやDeepSeek-R1の基盤でもあり、2025〜2026年の最大級モデルにおける事実上の標準となりました。MoEでは「全体」で数千億のパラメータを持ちながら、リクエストごとに一部（通常5〜10%）のみを活性化するため、同等の品質を保ちつつ推論（inference）の計算コストを劇的に削減できます。

K2.6は本記事執筆時点でのK2シリーズ最新のイテレーションです。Moonshot AIの公開発言によると、このバージョンではreasoning（論理的推論）、コード生成、ネイティブなツール呼び出し（tool calling）の能力が向上しています。かつてGonkaのネットワークで稼働していた頃、このモデルは識別子moonshotai/Kimi-K2.6で利用可能でした。現在この識別子はゲートウェイに受け付けられません — 最新のモデル一覧は常にGET /v1/modelsが返します。

両モデルとも中国の主要なAI研究所によるフラッグシップ開発成果です。ネットワークによって提供されていた間は、統一されたOpenAI互換インターフェースJoinGonka Gatewayを通じてアクセスできましたが、現在このペアのうちゲートウェイを通じて利用可能なのはMiniMax M2.7のみです。ただし、両者は強みや背景が異なるため、どちらが優れているかではなく、どのタスクに適しているかという視点で選択することが重要です。

推論ベンチマーク（MATH-500、GSM8K、AIME）において、Kimi K2シリーズは歴史的にopen-weightsモデルの上位グループに位置し、DeepSeek-R1やo1スタイルのモデルと競合してきました。コード生成タスク（HumanEval、MBPP）では、両モデルとも同水準を維持しています。MiniMax M2.7の強みは、超長文シーケンスのための効率的（線形）なAttentionであり、Kimiシリーズは強力な推論能力と長いコンテキストで知られています。

2026年のベンチマークに関する重要な注意点として、公開テストにおけるトップモデル間の差は数パーセントまで縮まっており、この差はベンチマーク自体の統計誤差の範囲内であることが多いです。実用上の意味を持つのは「MMLUでどちらが2%高いか」ではなく、モデルにどのようなコンテキストを渡すか、論理の連鎖がどれほど複雑か、長い対話履歴が必要か、どの言語を使用するか、といったタスクの性質です。したがって、上記の表はモデルのランク付けではなく、それぞれのモデルがどのようなタスクプロファイル向けに最適化されているかを素早く把握するためのものです。

現在実用的な選択として、Kimi K2.6のニッチであった「長いコンテキスト（大規模な文書の分析、膨大なコードベースの読み込み、履歴を保持した長い対話）」および「複雑な推論タスク」は、現在はネットワーク内の2つのモデルがカバーしています。推論についてはGLM-5.3 Flashが担います。このモデルは回答の前に思考を行うため、複雑な論理が必要な場合に推奨されます。また、同モデルはネットワーク内で最も長いコンテキスト（390K）を持っています。推論を必要としない大規模なプロンプトや長いエージェントセッションには、DeepSeek V4 Flash（380K、2番目に長いコンテキスト）が適しています。非常に長い入力シーケンスやストリーミングデータの高速な処理が優先される場合は、効率的なAttentionを備えたMiniMax M2.7が適しています。プロダクションにおける優れた戦略に変更はありません。コード内で複数のモデルを保持することです。modelパラメータによる迅速な変更により、アプリケーションのアーキテクチャを変更することなく、タスクに応じてそれらを切り替えることが可能です。

2026年春まで、Gonkaネットワーク全体はわずか1つのモデル——Qwen3-235B——だけを動かしていました。アーキテクチャの観点ではこれは理にかなった判断でした。DiLoCoによる分散推論では、ネットワークの全参加者が同じモデルをVRAM上に保持していなければ、どのノードでも任意のリクエストを処理できる保証はありません。FP8形式のフルQwen3-235Bは約640GBのVRAMを占有し、それ自体が各MLノードにとって巨大な負担でした。

マルチモデルネットワークへ移行するには、複数のモデルを同時に保持でき、かつ各ホストにすべてを動かすことを求めない仕組みが必要でした。それがDevShards——それぞれが1つのモデルに特化した個別のシャードです。同じシャード内のノードは同一モデルを扱い、ネットワークのルーターがリクエストを該当モデルのシャードへ振り分けます。

このアイデアは突然生まれたものではなく、2026年春にコミュニティ投票にかけられたGonka Improvement Proposal #800「Multi-Model PoC」で正式化されました。提案はネットワークの参加者とバリデータの支持を得て、2026年4月〜5月に実装されました。Kimi K2.6は別のDevShardで稼働した最初のモデル、つまり新しいアプローチの事実上のテスト実装でした。この試みは成功し、続いてMiniMax M2.7、DeepSeek V4 Flash、GLM-5.3 Flashがそれぞれのシャードに登場し、各々が独自のホスト群と独自の経済圏を持ちました。同じ仕組みは逆方向にも働きます。ホストがサポートしなくなったモデルは投票によってネットワークから外されます——2026年9月にKimi K2.6自身が去ったのもまさにこの方法でした。

これがユーザーと開発者にとって意味するもの:

• 1つのAPIで複数のモデル。 JoinGonka Gateway経由なら、エンドポイントもキーも変える必要はありません。リクエストボディのmodelを別のものに指定するだけです。OpenAI互換フォーマットは完全に維持されます。
• 価格は同じ。 Kimi K2.6は稼働中、MiniMax M2.7と同じレートで課金されていました。ネットワークの統一料金は現在のモデルにも適用され、Gateway経由で100万トークンあたり$0.0069です。統一プライシングは、ユーザーがモデル間を移行しやすくするための意図的な判断です。
• 安定性はシャードの負荷次第。 初期段階では新しいモデルのシャードはホストが少ないため、リクエストが集中すると一時的に429 too many concurrent requestsが返ることがあります。これは新しいモデルの正常なフェーズです。関心が高まるにつれてホストがシャードに参加し、制限は拡大します。逆もまた真で、ホストがシャードを離れればモデルはキャパシティを失います——Kimi K2.6のネットワークでの顛末もまさにこれでした。
• ツール呼び出しはモデルごとに異なる。 Gonkaネットワーク上のKimi K2.6では、開始時にツールの自動選択（tool_choice: "auto"）に関する細かい問題が記録され、後にノードのアップデートで解消されました。教訓はネットワーク上のどのモデルにも当てはまります。ツール呼び出しのフォーマットは、特定のノード上の特定のモデルの特性です。そのため本番クリティカルなシナリオでは、選んだモデルの挙動を自分のリクエストで事前にテストしてください。

結論から言うと、Gonkaネットワーク経由でKimi K2.6を利用することはできなくなりました。ホストは2026年9月初旬にその提供を停止し、ガバナンス提案 #101 によってこのモデルはネットワークのモデル一覧から正式に除外されました——model: "moonshotai/Kimi-K2.6" を含むリクエストはゲートウェイが拒否します。モデルの重みは公開されているため、サードパーティのopen-weightsモデルホスティング（たとえばOpenRouter経由）で引き続き入手することも、自分でデプロイすることも可能です。

一方、Gonkaに期待するあの安価な分散型inferenceが必要な場合、それは消えていません。現在のネットワークの稼働モデル上で動いているだけです。JoinGonka API Gatewayでは、OpenAIおよびAnthropic互換APIを通じて3つのモデルが利用可能で、それぞれがKimiで評価されていた要素の一部をカバーしています：

• GLM-5.3 Flash（zai-org/GLM-5.3-Flash）——Z.aiのreasoningモデル：回答前に推論するため、複雑な論理、コード解析、「考える」タスクに最適です。ネットワーク最長のコンテキスト（390K）も備えています。推論は応答の上限に含まれるため、max_tokensは余裕を持って設定し、streamを有効にしてください。
• DeepSeek V4 Flash（deepseek-ai/DeepSeek-V4-Flash-0731）——ネットワーク内でも最長クラスのコンテキスト（380K）、最長の出力、強力なエージェント型コーディング：大規模リポジトリ、長いツール呼び出しチェーンに適しています。
• MiniMax M2.7（MiniMaxAI/MiniMax-M2.7）——ゲートウェイのデフォルトモデル：日常的なタスク、長文ドキュメント、ストリーミング処理で高速かつ安定した回答を返します。

Kimi K2.6からの移行は一行の置き換えです。OpenAI向けに書かれたコードはそのまま動作します：URL、APIキー、モデル名を置き換えるだけで十分です。

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [{"role": "user", "content": "Explain the difference between MoE and dense models"}]
  }'

開発ツールでもルールは同じです：設定にmoonshotai/Kimi-K2.6があった箇所すべてで、稼働モデルのいずれかのIDに置き換えてください。CursorではCustom Modelフィールド、Claude Codeでは環境変数ANTHROPIC_MODELまたは--modelフラグ、OpenClaw、Cline、Continue.devではプロバイダー設定内のモデル名、LangChainとn8nではクライアント初期化時のmodelパラメータです。インストーラーnpx @joingonka/setupを使えば、ゲートウェイと最新モデルをツールの設定にコマンド一つで書き込めます。利用可能なモデルの一覧は常にGET /v1/modelsエンドポイントで最新の状態を確認できます——ここからアプリのUIに動的に取り込めば、モデルの提供終了や追加がプロダクトを壊すことはありません。

登録なしで試すには、/tryページの無料チャットが便利です——そこでネットワークの稼働モデルを利用できます。JoinGonka Gatewayに登録すると、ネットワークのあらゆるモデルをテストできる無料の3Mトークンがもらえます——3つのモデルそれぞれで自分のタスクを流し、納得してから代替を選ぶのに十分な量です。

Kimi K2.6の一件がGonkaネットワークに示したこと：DevShardsの仕組みは双方向に機能しました。ネットワークを止めずにモデルを追加でき——Kimiに続いてMiniMax M2.7、DeepSeek V4 Flash、GLM-5.3 Flashが加わり——ホストがサポートをやめたモデルも痛みなく除外できました。単一モデルに縛られたネットワークは根本的に脆く、投票で構成を変えられるネットワークは緩やかに継続的に進化します。開発者にとっての教訓はシンプルです：「永遠のモデルを選ぶ」のではなく、モデル名を設定に置き、生きた一覧を確認し続けることです。