Moonshot AIは7月27日、Kimi K3の重みをオンラインで公開し、これまでにリリースされた最大のオープンモデルを誰でも無料でダウンロードできるようにした。これは2023年創業の北京のスタートアップが開発した2.8兆パラメーターのシステムで、テキストだけでなく画像も読み取り、1回のクエリで100万トークンを受け付ける。コードベース全体を一度に保持できる規模だ。
業界が注目したのは、リーダーボードでの位置付けだった。独立系トラッカーによると、K3は分野の最上位に近く、Artificial Analysisの知能指数ではClaude FableとGPT-5.6 Sol Maxに次ぐ位置、Frontend Code Arenaでは首位に立っている。しかも運用コストはその一部にすぎない。オープンウェイトなら、誰でもダウンロードし、検査し、改変し、自社ネットワーク内に保持できる。主要なクローズドモデルのいずれも、いかなる価格でもこれを許可していない。先週、多くの人を動揺させたのはこの点であり、今回のリリースが単なる研究上のマイルストーンではなく、OpenAIやAnthropicに対する競争上の一手と受け止められた理由でもある。
あまり注目されていない落とし穴もある。ダウンロードできることと、実行できることは同じではない。ファイル容量は1.56テラバイトに達し、実際にはデータセンター向けGPUを搭載した複数ノードのラックが必要になる。それを持たない人にとって、オープンウェイトはほとんど技術上の建前にすぎなかった。
Pipe Networkはオープンソースの移植版を公開し、差を縮めた。動作するK3を単一のApple Siliconデスクトップ上で実行できるようにしたのだ。
障害となっていたのは、常にメモリだった。最も圧縮した状態でも、K3にはおよそ870GBが必要になる。現存する最大のMacであるM3 Ultra Mac Studioでも、ユニファイドメモリは最大512GBだ。惜しい差というわけではない。
この差を埋めるのが、2つのエンジニアリング上の工夫だ。
変換処理をストリーミングする
モデルをMacで実行するには、まずファイルをAppleの機械学習ソフトウェアが読み取れる形式に書き換えなければならない。標準ツールは、モデル全体をメモリに読み込み、変換してから再び書き出す。家庭で実行される小規模なモデルなら、これで問題ない。しかしK3には使えない。未加工のK3は5.6TBあり、市販されているどのマシンにもそれほどのメモリは搭載されていないからだ。
モデルは1つの固まりではない。複数のセクションが積み重なった構造で、K3には93個のセクションがあり、それぞれが処理の一部を担当して次へ引き渡す。移植版のコンバーターはこの構造を利用する。1つのセクションを読み込み、変換し、ディスクに書き出して破棄し、それから次へ進むのだ。全体が一度に存在する必要はないため、処理を行うマシンに必要なのは数千GBではなく、数十GBのメモリで済む。華やかさとは無縁の配管作業だが、これがなければプロジェクトの他の部分は何も実現しない。
使わない専門家を削除する
K3の大部分は、どの瞬間にも何も処理していない。これは設計上の特徴だ。巨大な汎用ネットワークを1つ用意するのではなく、狭い分野に特化した専門家の集合として構築されている。93個ある各セクションには896の専門家が含まれ、ルーターが処理中の単語に最適な16個を選ぶ。残りは処理に参加しない。合計すると、ディスク上のモデル容量のおよそ98%は、どの瞬間にも待機している専門家で占められている。それでも全員が容量を消費する。
これらの専門家はエキスパートと呼ばれ、REAPはCerebrasが開発した、どれを残すかを決めるための手法だ。実際に関心のある種類のテキストをサンプルとしてモデルに入力し、どのエキスパートが大きな役割を果たしているかを観察して、容量に見合う働きをしないものを破棄する。K3に適用すると、1.56TBが350GBまで減り、Mac Studioに余裕を持って収まる。
コーパスが製品を決める
リポジトリで最も興味深い結果は、調整に使うサンプルテキストによって、完成したモデルができることが決まるという点だ。
チームは、異なる種類のコンテンツがどのエキスパートに依存しているかを測定した。欧州言語は互いにまとまる。コードもまとまる。一方、中国語とコードはほとんど重ならず、ランダムな偶然から予想されるよりも少ない。
その影響は出力に表れる。英語とコードで調整したビルドは中国語を完全に失い、同じ内容を繰り返し始める。中国語だけで調整したビルドは、きれいな中国語を書く一方で、動作するコードを生成できなくなる。両方で調整したビルドは、両方を維持する。これは単にモデルを圧縮しているのではなく、どの能力を残すかを選んでいるのだ。
チームは、これは正式な評価ではなく、少数のテストプロンプトに基づく結果にすぎないと慎重に説明している。また、同じ実験の初期版では、後に誤りだと判明した結論に至っていた。
正直な注意点
トレーニングはモデルに知識を教える工程だ。推論は、モデルを使うたびに起きる処理であり、プロンプトを1語ずつ回答に変換していく作業だ。その1語ごとに、マシンはモデルの重みの大部分を走査しなければならない。そのため推論速度は、モデルがどれほど賢いかというより、コンピューターがデータをどれだけ速く移動できるかという問題になる。
ここでの速度は毎秒0.14~0.20トークンだ。1文の生成に数分かかる。生成される1語ごとに、メモリから約87GBを読み出す必要があるため、これはソフトウェアのバグではなくハードウェアの上限だ。さらに積極的に削減しても解決しない。100GB小さいビルドでも、速度はわずかに上がっただけだった。
これが、このプロジェクトの本当の教訓だ。モデルをマシンに載せることはソフトウェアで解決できた。しかし、実用可能にすることはできなかった。そして、この規模のモデルが「ローカル」という表現に意味を持たせられるようになるまで、なおどれほどのハードウェアを必要とするのかを、かなり正確に示している。これは、実行を開始してから戻ってくるようなジョブ向けのバッチツールであり、チャットボットではない。とはいえ、コンシューマー向けマシンのメモリ帯域幅は上昇し続けており、ソフトウェア面の基盤はすでに整い、公開されている。ハードウェアが追いついたときに、すぐ使える状態だ。
2つの点は問題なく機能する。ビジョンコンポーネントはMoonshot独自のコードと照合してテストされ、丸め誤差の範囲内で一致するため、画像処理はエンドツーエンドで機能する。また、残ったエキスパートは元のものとビット単位で完全に同一だ。ソース形式とAppleの形式がたまたま同じ方法で数値をエンコードしているためだ。失われた情報は、プルーニングそのものだけである。
このリポジトリは、まだテストされていないことについても、珍しいほど率直だ。完全なプルーニング前のバージョンは、一度も単一のトークンを生成していない。それらを保持できるコンピューターが存在しないからだ。
