2.78兆パラメータのモデルが、RAM 8 GB と 179 KB の C コードで動く。本当に重要な数字は 1.7 テラバイトだ

個人開発のプロジェクト kimi-k3-in-c は、Moonshot AI の Kimi K3 — 2.78兆パラメータ、これまで公開されたオープンウェイトモデルの中で最大 — の推論を、CPU 1基、ピーク実メモリ 8.24 GB で走らせる。エンジンは C99 で書かれ、BLAS も PyTorch も GPU コードパスもなしに 180 KB 未満にコンパイルされる。スター 8.1k、フォーク 1.3k、ライセンスは Apache 2.0 だ。

主張は、およそ成り立ちそうにない響きがある。だが成り立っている。そして、なぜ成り立つのかは見出しよりも面白い。

計算を追う

bfloat16 における K3 の重みは約 5,560 GB になる。リポジトリはそこからの削減を4段階で示しており、そのどれもがモデルに仕掛けた小細工ではなく、モデル自身の性質である。

大きく効いているのは2段目であり、それは量子化ではない。K3 は各トークンを1層あたり 896 個のエキスパートのうち 16 個へルーティングする。残り 880 個はそのトークンにとって不活性だ。通常の推論スタックは重みの移動が高価だからすべてをメモリに保持するが、このプロジェクトは代わりに I/O を払い、ほとんど何も常駐させない。Moonshot 自身のアーキテクチャ資料は、2.8兆のうちトークンあたりの活性パラメータを約 500億 としている。つまりこのモデルは最初から 98% が遊んでいたのであり、それを文字どおりに受け取るエンジンを誰も作っていなかったということだ。

アテンションも同様に扱われる。93 層のうち 69 層は Kimi Delta Attention を使い、その再帰状態はコンテキスト長に関係なく固定 217 MB である。グローバルアテンションの 24 層は MLA を使い、96ヘッド × 320次元ではなく1位置あたり 576次元の潜在表現1つをキャッシュする。リポジトリはこれを 53倍の削減と計測している。どちらも作者の発明ではない。いずれも K3 の設計上の選択であり、GPU 前提のスタックにはそのメモリ上の帰結を活用する動機が特にない、というだけのことだ。

ここで実際に作られているもの

作者自身のエンジニアリングは配管部分にあり、それが異例なほど丁寧だ。MXFP4 の重みは逆量子化せずパックされたまま乗算される。リポジトリの計算では、これによりトークンあたり 194 GB のメモリトラフィックが回避される。手書きの JSON スキャナは、96 個の safetensors シャードにまたがる 497,220 個のテンソルを、ヘッダーだけを読んで 0.27 秒でインデックス化する。BPE トークナイザは tiktoken をバイト単位で一致するよう再実装し、Unicode・絵文字・コードにわたるラウンドトリップで検証されている。

最も物を言うのは、間違えるとそれらしく見えるゴミを静かに出力してしまう5つの不変条件を列挙した節だ。A_log はチャネル単位ではなくヘッド単位で索引すること。UT 変換の逆行列の符号。KDA の2つの行列のうちどちらが対角成分を保持するか。MLA がキャッシュしつつ決して回転させない 64 の rope 次元。そしてルーターのバイアスはエキスパート選択を誘導するだけで、重み付けにはバイアスなしのシグモイドスコアを使うこと。このリストは、各項目で痛い目を見た人間でなければ書けない。テストスイートは PyTorch 参照実装に対する3つの適合ゲート — teacher forcing、貪欲デコード、キャッシュ付き逐次デコード — を通過するまで生成を許さず、カーネルとトークナイザの層は重みを1バイトもダウンロードする前に検証できる。

代償

1トークン 32 秒は、毎分およそ2トークンである。300 トークンの回答なら午後がまるごと消える。そして小構成では実行時間の 71% が算術ではなくストレージ読み出しに費えている。エンジンはディスクを待っているのだ。メモリを I/O と引き換えにする設計から予測されるとおりの結果である。

この表には2つ注意がいる。数値は 124 コアの2ソケット AMD EPYC 7763 上で計測されており、プリセットはマシンを替えるのではなくメモリ予算に上限をかけている。実在する 8 GB のノートパソコンには 124 コアもそのメモリ帯域もないので、Laptop 行は「ノートパソコンでの結果」ではなく「メモリ予算を絞った結果」である。そして忠実性の主張 — すべてのプリセットでバイト単位に同一の出力 — は、プロジェクト自身のテストスイートに依拠している。そのスイートはよくできているように見えるが、独立した再現報告は公表されていない。

要件はどこへ移ったのか

見出しが省いている一行がここにある。このプロジェクトは約 1.7 TB の空きストレージを必要とする。チェックポイントの 1.56 TB に、初回実行前に生成する 109 GB のパック済みトランクファイルを加えた量だ。

メモリ要件は消えていない。階層を1段下り、DRAM からディスクへ移り、その過程で3桁遅くなった。ディスクは安く DRAM は高いのだから、これは正当でよく選ばれたトレードオフだ。しかしそれは、「RAM 8 GB で動く」がワーキングセットを述べているにすぎず、参入障壁を述べていないことを意味する。障壁は 1.7 TB のダウンロードである。

したがって実用的な価値は、余っているデスクトップで K3 を提供できるようになることではない。価値は、このエンジンが K3 推論とは実際に何から成るのかを、依存関係なしに読み切れる形で完全に述べていることにある。Karpathy の llama2.c の系譜であり、端から端まで読めて数秒でコンパイルできるものだ。K3 を変わったハードウェアへ移植しようとする人、あるいは兆パラメータ級 MoE が実際にどこでバイトを使っているのかを理解したい人にとって、「静かに間違える5つの方法」のリストが付いた 179 KB の C プログラムは、それらすべてを隠すフレームワークよりはるかに価値がある。

ソース: kimi-k3-in-c（GitHub） · Kimi K3 モデル概要（Hugging Face） · Moonshot AI が Kimi K3 を公開（CNBC）