Kimi K3：2.78兆パラメータのオープンモデルが示す企業利用の現実

問題はここからです。オープンモデルはこの第2の軸では急速に進歩した一方で、第1の軸では歩みが遅く、多くのモデルが1兆パラメータ程度にとどまってきました。

そのため、同程度の規模のモデルの上に、いくら第2の軸の推論（reasoning）を洗練させていっても、オープンモデル同士の進歩は似たような性能へと収束してしまいます。一方で、潤沢な資産とインフラを持つ非公開モデル（プロプライエタリ）は、巨大な脳（第1の軸）に深い思考力（第2の軸）を掛け合わせ、両方の軸を同時に引き上げ続けています。このままでは、オープンと非公開モデルの実力差は開く一方になります。

この構造的な限界を打破すべく、2つの軸を同時に押し上げる狙いで開発されたのが、中国のAI開発企業Moonshot AIのKimi K3です。2.78兆のパラメータを持ち、高度な強化学習と推論、そして100万トークン（文庫本にして数冊分）に及ぶ長い対話を融合させました。

Kimi K3はKimi K2と比べ、モデルの構成を大幅にスケールアップさせたことで、「学習の効率（スケーリング効率）」を約2.5倍に向上させることに成功しています。

そもそも、オープンモデルが1兆パラメータ級で頭打ちになってしまうなら、データの秘匿性やセキュリティの観点から「オンプレミスでの高度な内製化」を志向する企業にとって重大な制約となります。

社外にデータを出せない以上、オープンモデルを使うしか選択肢がないにもかかわらず、その実力が頭打ちになれば、高度な専門業務を自社の安全な環境で自律処理させるという未来が、技術的な制約により閉ざされてしまうからです。結果として、利便性をとってリスクを冒しながら商用APIを頼るか、安全性を取って性能の劣るモデルで妥協するかという二者択一を迫られます。

Kimi K3が2.78兆パラメータのオープンモデルとして公開されたことは、単なる性能表の順位争いを超えた意味を持ちます。それは、巨大な最先端モデルを自社のオンプレミス環境で検証するという選択肢を与えたことです。ただし、後述するように、モデルの重みや技術詳細が公開されていることと、それを自社のインフラで実際に動かせることは別の問題です。

100万トークンを、商用サービスとして成立させるインフラと設計

レポート第5章は、Kimi K3が単一のモデルで同時に抱えた3つのシステム課題を挙げています。それは、「ハイブリッドな注意機構」「2.78兆パラメータの疎なマルチモーダル学習と推論」、そして「100万トークン規模のエージェント作業負荷」を、いかにインフラを破綻させずに現実的なコストで商用サービスとして成り立たせるかという高い障壁です。

長文脈と視覚に寄せて設計されたアーキテクチャ

従来のAIは、文脈が長くなるたびに「どこに何が書かれていたか（位置情報）」を見失うため、いわば「その場しのぎの延命措置（チューニング）」を重ねて長い文脈に対応していました。Kimi K3はこの限界を、記憶と処理のハイブリッド設計で根本から解決しました。

技術のすごさ（KDA 3層 ＋ Gated MLA 1層のハイブリッド）

伸び続ける記憶（キャッシュ）の代わりに、固定サイズのメモ帳（再帰状態）で情報を混ぜ合わせる「KDA」を69層。そして、キーとバリューの表現を極限まで低次元に圧縮して保持する「MLA」を24層配備しました。

これによって、位置情報について自己解決できるようになりました。MLA層には、位置を表す情報を別途持たせていません。順に処理して状態を更新し、チャネルごとに減衰をかけるKDAの構造そのものに「順序と近さ」が自然に埋め込まれているためです。

結果として、従来のような位置情報の修正（RoPE）に頼ることなく100万トークンの長文へ適応できる設計を実現しました。実際の訓練では、短い文書から段階的に文脈を伸ばす手順が必要になります。ただし、文脈を伸ばすたびに生じていたアーキテクチャ上の挙動の不安定さは解消されました。

モダリティの事後統合を廃止

次に特徴的なのが、マルチモーダルモデルの訓練方法です。これまでのマルチモーダルAIは、「画像を理解するモデル（ビジョンモデル）」と「テキストを書くモデル（言語モデル）」が別々に分かれており、事後的にそれらを統合する設計が主流でした。

Kimi K3は、テキスト、画像、動画を単一のバックボーンが1つの文脈の中で処理し、事後にモダリティ（入力方法）を整合させる段階を置いていません。

技術のすごさ（同一トークン列での処理）

描画結果（ビジュアル）と、それを生成したコードが、全く同じ情報の配列（トークンストリーム）の中に存在します。

つまり、長期にわたる「視覚を伴う自律エージェント挙動」の圧倒的な基盤となります。AIがコードを書き、その出力を自ら検査し修正する、という人間と全く同じ「作って、見て、手直しする」の反復が、外部モデルへのデータ受け渡しを一切挟まずに、1つのモデル内で高速に完結します。

2.78兆パラメータの脳を「省エネ」で動かす

最後に、2.78兆パラメータという巨大な脳を常にフル稼働させていては、どれだけインフラがあっても足りず、電気代とサーバコストで運用が自滅します。Kimi K3は、いかにモデル全体を使わずにさぼらせるかの設計を主眼にしました。

技術のすごさ

これらの手法により、全2.78兆パラメータを毎回一律に使うのではなく、必要な部分だけを限定して動かすことで、巨大な知能と効率的実行を両立しています。

ただし、動かすパラメータが減った分だけ推論コストが下がるという単純な話ではありません。実際の推論原価は、演算量だけではなく、ノード間の通信、メモリアクセス、キャッシュ効率、そして並列化方式など、インフラ全体の作り込みに大きく左右されます。

原価を決めるのは「トークン単価」ではなく「設計」

商用サービスとして成立させるためのインフラ記述において、最も実務的なのは「キャッシュ（記憶の再利用）」と「要求の分離」についての言及です。

100万トークン規模のコーディング要求では、「40万トークンは既存のコードを読み込ませた上で、新規に4000トークン程度の修正計算を要求する」といった状況があるとします。

この時、毎回40万トークンをゼロから再計算してはインフラ原価が高額になります（同じチャット画面内でやり取りを重ねるほど、裏側に送られる過去の会話データは膨れ上がり続けます。これを適切なキャッシュ設計なしで処理しようとすれば、膨大な再計算が発生してしまいます）。

既にある情報（過去の会話や読み込ませたコード）の再計算を避け、キャッシュから再利用し、新規に追加された約4000トークン分を中心に処理する。この「会話の組み立て方」と「文脈の持たせ方（キャッシュのきかせ方）」の設計次第で、同じ業務でもコストは桁違いとなります。

「重いタスク」と「軽いチャット」に別々の計算予算を割り当てる

本番環境には「2000トークン未満の短い要求」と「最大100万トークンの超長文要求」が混在し、1回当たりの計算コストには約1000倍の開きが生まれる可能性があります。こうした要求を同じ資源プールで無制限に受け付けると、重い長文要求が資源を占有し、短いチャットの応答速度まで悪化する可能性があります。

Kimi K3は、要求を負荷別に分類し、それぞれに独立した計算予算を割り当てて制御しています。企業のAI基盤でも、即時応答が必要な対話と、時間をかけられる長文分析やエージェント処理を分け、それぞれに求める応答時間と計算資源の上限を別々に設計することが重要です。

ベンチマークの順位より「1タスクあたりの実質コスト」

レポートによると、Kimi K3の総合成績は、AnthropicのClaude Fable 5とOpenAIのGPT-5.6 Solに及びません。一方でコーディングやブラウジング、自律実行といった一部のエージェント系評価では、この2モデルに近い、または上回るスコアを示しています。

ただし、これらのスコアはMoonshot AIが自社で測定して公表した値です。全モデルを最大の推論設定で評価しており、評価環境や設定が変われば結果も変わります。

ここで見るべきなのは、スコアの順位ではなく「1タスク当たりの推論コスト」です。

コストで見た位置付け

レポートでは主要ベンチマークのスコアを開示しています。Webブラウジングやコーディングといったエージェント系の評価では、Kimi K3はClaude Fable 5やGPT-5.6 Solと数ポイント差の範囲に収まっています。ベンチマークによっては上回る項目もあります。

しかし、この「低コスト」の恩恵を日本の企業がそのまま享受できるわけではありません。

第1の理由は地政学的要因を含むガバナンス上のハードルです。Moonshot AIは中国企業です。セキュリティやガバナンス、各社の調達方針などによっては、日本企業が機密性の高い業務を中国ベンダーの商用APIに委ねることが難しい場合があります。

商用APIが自社の要件に適合しない場合、セルフホストや閉域環境での運用が選択肢になります。ただし、モデルの重みを取得できることと、企業の本番サービスとして運用できることは別問題です。

Kimi K3の公開後には、有志のコミュニティ実装として、必要な重みをストレージから逐次読み出し、単一CPUと約8GBのRAMで推論を成立させた事例も報告されています（論文外の非公式報告。生成速度は1トークンあたり数十秒規模とされる）。この事例が示すのは、「動かせること」と「業務サービスとして使えること」は違うという点です。

必要なインフラは、総パラメータ数だけでは決まりません。量子化方式、メモリとストレージの使い分け、応答速度、同時実行数、可用性によって大きく変わります。また、論文が一部の評価で示した低い「1タスク当たり推論コスト」は、セルフホストに伴う設備費、電力、運用要員まで含む総保有コストではありません。

Kimi K3の技術レポートは、オープンウェイトモデルが、一部のエージェント業務やコーディング業務でClaude Fable 5やGPT-5.6 Solに近い性能を示し得ることを報告しました。一方、モデルの重みを取得できることは、企業が必要とする応答速度、同時実行性、可用性、セキュリティを満たして運用できることを意味しません。セルフホストの可否は、総パラメータ数だけではなく、量子化方式、メモリとストレージの使い分け、必要な応答性能、運用体制を含むシステム全体で判断する必要があります。

結論

Kimi K3が示したのは「巨大オープンモデルは企業には使えない」という単純な結論ではありません。全ての重みを高速メモリへ常駐させず、ストレージから必要な部分を読みだせば小さいメモリでも動きます。一方でその代償として反応速度は大きく低下します。

つまり、モデルの総パメータ数や最低メモリ量だけでは企業利用の可否も経済性も判断できません。企業が比較すべきなのは、最小構成で一度動かせるかではなく、対象業務で求める品質を、必要な時間内に、想定する利用者へ、必要な可用性の下で提供できるかです。

「動く」と「企業で使える」は違います。Kimi K3は企業にこれを考えさせた点に価値があります。