kimi-k3-in-c: 1.56 TB のチェックポイントを 8.24 GB の RSS で回す C99 推論エンジン

この実装が解こうとしている問題は推論速度ではない

2.78 兆パラメータのモデルを単一 CPU で動かす、というと速度の話に見える。だが README が繰り返し述べているのは別のことだ。1.56 TB のチェックポイントを持ちながら、ピーク RSS が 8.24 GB に収まり、しかも 128 GB 以上のマシンで出る出力とバイト単位で同一になる。つまり目的は、モデルを「動かせる大きさに縮める」ことではなく、メモリ予算がいくらであっても同じ計算結果に到達させることにある。想定読者は、量子化や蒸留でモデルの中身を変えたくないが、手元に GPU クラスタも 1.5 TB の RAM もないエンジニアだ。README の表現を借りれば、同じモデルが 8 GB でも 224 GB でも動き、その間のどの予算でも出力が一致する、という主張になる。

4 つの削減: 重みを展開せず、KV を伸ばさず、ヘッドを束ねる

README は「4 つの削減」という枠で設計を説明している。1 つ目はルーティングされるエキスパート群で、これは 1.45 TB あり、常駐しない。パックされた 4-bit 形式のまま積算するため、展開後の 16-bit 重みをメモリに置く必要がない。2 つ目は KDA と呼ぶ線形注意で、記憶領域が伸びない。3 つ目は MLA で、96 個のヘッドの代わりに 1 つの潜在表現を使う。4 つ目はデンスなトランクを選んだ深さまでメモリに残し、残りをストリームする方式だ。この 4 つは独立した最適化ではなく、バイトの置き場所を決める一つの方針として提示されている。アーキテクチャ図には、小さな常駐ワーキングセットが上に、モデル本体が NVMe の上に、その間にいくつかのパイプが描かれている。

プリセットは RAM の量ではなく待ち時間の選好を表す

README の表は 4 段階のマシンを並べている。8 GB のノート PC では 1 トークン 26.5 秒、32 GB で 24.2 秒、64 GB で 19.8 秒、128 GB 以上で 5.6 秒。最初の 3 行は毎ステップ モデルをディスクから読むため、ドライブが遅ければその分だけ遅くなる。128 GB 以上の行だけがディスク待ちから外れる。注目したいのは差の付き方で、8 GB から 64 GB への 8 倍のメモリ増加が生む短縮は 26.5 秒から 19.8 秒、つまり 25% 程度に留まる。一方 64 GB から 128 GB では 19.8 秒から 5.6 秒へと約 3.5 倍改善する。メモリを積む効果は連続的ではなく、モデルが収まりきる閾値を越えたところで階段状に現れる。README が「メモリは速度を買うだけ」と書くのはこの意味だ。

ビルドと実行: モデルなしで 1 分、モデルありで 1.56 TB

README は Quick start を「モデルなしで約 1 分」と説明している。clone、ビルド、検証までをモデル抜きで済ませられる構成になっている点は、採用判断のコストを下げる。実行時のコマンドは README に 2 例が載っている。1 つ目はノート PC 向けで、./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental を実行し、8 トークンに 261.5 秒、ピーク RSS 8.24 GB という結果が示されている。2 つ目はサーバー向けで --preset server を指定し、28 トークンに 299.3 秒、ピーク RSS 127.92 GB となる。オプションはプロンプト、メモリ、生成、診断の 4 群に分かれており、環境変数と終了コードも定義されている。--trunk と --tok が別ディレクトリを指している点は、チェックポイントとトークナイザの配置が分離されていることを示す。

出力がバイト一致するという主張の重みと、その代償

メモリ量を変えても出力が同一になる、という性質は再現性の面では利点だ。同じプロンプトを 8 GB のノート PC で流し、後で 128 GB のワークステーションで再実行しても、得られる文字列は変わらない。検証や比較の基準として使いやすい。ただし README 自身が断っているように、これはベースモデルでありチャットテンプレートを持たない。"The capital of France is" に対して返るのは " Paris." に続く継続であり、応答ではない。対話用のモデルとして期待すると外れる。また README の注記によれば、2 つの実行例はより遅いドライブでの当初の記録であり、時計の値はやや高めに出ている。数値をそのまま自分の環境の期待値として使うべきではない。

v1.0.0 が変えたものと、変わっていないもの

リリースは v0.1.0 が 2026-08-02、v1.0.0 が 2026-08-07 で、間は 5 日しかない。README によれば v1.0.0 でトークンあたりの演算が約 8 分の 1 になり、チャットでの追撃質問が 3.9 倍速くなり、長いプロンプトのコストが約半分になった。ただしこれは同一マシン上での比較であり、条件は docs/data/ に置かれている。注目すべきは、この改善がメモリ使用量の削減ではなく計算量の削減として説明されている点だ。8.24 GB というピーク RSS は変わっていない。つまり v1.0.0 は「より小さく動かす」方向ではなく「同じ大きさでより速く」方向の更新である。バージョン間の差分を追うときは、RSS ではなく秒あたりの数値を見るべきだ。

向かない条件と、代わりに選ぶなら何が違うのか

この実装が向かないのは、待ち時間が問題になる用途だ。README の数値では最も速い構成でも 1 トークン 5.6 秒であり、8 GB 構成では 26.5 秒かかる。ストリーミング応答や対話的なコーディング支援には使えない。またプラットフォームは Linux x86-64 に限定され、AVX2 がトピックに挙がっている。macOS や ARM での動作は README からは確認できない。代替として挙げられるのは llama.cpp 系の量子化推論だが、アプローチが根本的に異なる。llama.cpp は重みを量子化してモデル自体を小さくし、メモリに載る形に変換することを狙う。対してこのプロジェクトはモデルの数値形式を変えず、4-bit で出荷されたエキスパートをそのまま積算し、載らない部分はディスクから流す。モデルの忠実性を優先するか、スループットを優先するかの違いである。

ライセンスと保守の見通し

ライセンスは Apache-2.0 で、リポジトリの LICENSE ファイルへのリンクが README にある。Apache-2.0 は特許許諾条項を含む寛容なライセンスだが、モデル本体の重みのライセンスは別問題であり、このリポジトリの記載からは判断できない。チェックポイントを別途取得する必要がある以上、重みの利用条件は各自で確認する必要がある。保守の面では、エンジン全体が 176 KB と小さく、依存がゼロである点は追跡しやすい。CI ワークフローが .github/workflows/ci.yml にあり、CHANGELOG.md と docs/data/ が更新ごとに維持されている。ただし v0.1.0 から v1.0.0 までが 5 日という短い間隔であり、この粒度の更新が続くかどうかは README からは読み取れない。

編集部の結論

8 GB から 128 GB 級のマシンしか持たず、1 トークンあたり十数秒から 20 秒超の待ち時間を受け入れられるなら、この実装は検討に値する。逆に、対話的なレイテンシやバッチ処理のスループットを求める用途では選択肢にならない。最初に確認すべきは docs/data/ の測定条件と、自分のチェックポイントが config リーダーの想定するフィールド名を満たしているかどうかだ。--preset laptop で 8 トークン生成し、PEAK RSS が 8.24 GB 付近に収まるかを自分の環境で見るところから始めるのが現実的である。

公式情報源

1. FareedKhan-dev/kimi-k3-in-c on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases