遅いパソコンでGLM-5.2を動かす — colibrìが744Bモデルをディスクからストリーミングする仕組み

はじめに — 25GBのRAMで744Bモデルを?
中核の仕掛け — MoEの疎性とディスクストリーミング
耐えられる速度にするための工夫
正直な話 — 実際どれくらい速いのか
おわりに — 「動く」と「使える」のあいだ
参考資料

はじめに — 25GBのRAMで744Bモデルを?

colibrì は、GLM-5.2 を普通のコンシューマPCで動かすことを目標にした推論エンジンです。GLM-5.2 は colibrì の説明によれば、総パラメータ 744B(7,440億)の MoE モデルです。通常この規模は GPU を複数枚と数百GBの VRAM を要求します。colibrì はこれを12コアCPU・25GBのRAMのマシンで動かします。純粋Cで約1,300行、ランタイム依存はゼロ — BLAS もPythonもありません。

もちろんタダではありません。プロジェクトが掲げる目標からして速度ではありません。要約すると「12コアのノートPC・25GBのRAMで GLM-5.2 に正しく答えさせること、たとえ速度が段落あたり数分で測られようとも」です。本記事は、colibrì が実際に何をしているのか、どんな工夫でそれが可能なのか、そしてそれがどれだけ実用に足るのかを正直に見ていきます。

中核の仕掛け — MoEの疎性とディスクストリーミング

二つの事実が噛み合っています。

第一に、GLM-5.2 は MoE です。1トークンを生成する際、744B すべてではなく約 40B だけが活性化します。パラメータは「エキスパート」に細かく分割されており、トークンごとにルーターが入力に合う少数だけを選びます。colibrì のビルドではルーテッドエキスパートは 21,504個(75個の MoE レイヤー × 256個)、int4 でそれぞれ約19MBです。

第二に、だからすべてを RAM に載せる必要はありません。colibrì はモデルを二つに分けます。

密(dense)な部分 — アテンション・共有エキスパート・埋め込みで約 17B。int4 に圧縮し、9.9GBだけを RAM に常駐させます。
ルーテッドエキスパート — 約 370GB(int4 コンテナ)。NVMe SSD に置き、トークンごとに必要な分だけ読み込みます。

つまり「巨大なモデル、小さなエンジン」です。トークンごとのボトルネックは計算ではなくディスク読み込みで、コールド状態では1トークンあたり約11GBを SSD から読みます(75レイヤー × 8エキスパート)。このディスク帯域が速度の上限を決めます。

耐えられる速度にするための工夫

ディスクストリーミングは本質的に遅いものです。colibrì で面白いのは、その遅さを削り取る方法です。

学習キャッシュ(learning cache) — 実際の利用でどのエキスパートが頻繁に呼ばれるかを .coli_usage に毎ターン記録し、次回起動時にその「熱い」エキスパートを余った RAM に事前ピン留めします。つまり使うほど速くなるということで、--repin でセッション中のライブ再配置もできます。
MTP 投機デコード — GLM-5.2 の multi-token prediction ヘッドで複数トークンを先読みし、一度に検証します。int8 ヘッドで forward あたり 2.2〜2.8 トークン、受理率 39〜59% を実測。ヘッドを int4 に落とすと受理率が 0〜4% に崩壊するため、ヘッドだけ int8 に保ちます。
圧縮 KV キャッシュ — トークンあたり 576 float で、元の 32,768 に対して 57倍小さいです。会話はエンジンを再起動しても warm なまま続きます。
非同期先読みとバッチ統合 — あるブロックを乗算している間に次のブロックを先読みし、1バッチ内で同じエキスパートは一度だけ読みます。

これらすべての土台が量子化です。int4 コンテナに per-row スケール、AVX2 カーネルで dequant-on-use。量子化まとめ記事で扱った「ビットを減らしてメモリと帯域を買う」戦いが、ここでは「ディスクから読むバイト数を減らす」にそのまま繋がります。

実際に動かすための下限と、4つのエントリポイントは次の通りです。

# ハードウェア下限 (READMEより)
OS:    Linux または WSL2     CPU: AVX2, 12コア以上
RAM:   16GB以上 (キャッシュ自動上限, ピーク約20GB)
Disk:  約370GB ローカルNVMe (ext4) — ネットワークマウント不可

# 実行モード
./coli chat     # 対話CLI
./coli serve    # OpenAI互換API (テキストのみ)
./coli bench    # MMLU / HellaSwag / ARC
./coli plan     # ヘッダのみのドライラン, 割当ゼロ

正直な話 — 実際どれくらい速いのか

遅いです。コールド状態で約 0.05〜0.1 tok/s、実質10〜20秒に1単語です。ロードだけで約30秒。コミュニティが報告した実測はハードウェアで割れます。M5 Max(128GB)1.06 tok/s、Framework 13(128GB + 学習ピン)0.37 tok/s、PCIe5 NVMe を積んだ 9950X で 0.28 tok/s。最良のケースでも毎秒1トークン強です。

これは対話ツールではありません。1段落に数分かかります。では、いつ使うのか。

クラウドが不可能または禁止されている場所 — オフライン、エアギャップ、規制環境。
プライバシーが絶対条件のとき — データがマシンを離れてはいけない場合。
ハードを買わずにとにかく試したいとき — 古いデスクトップで 744B モデルの出力を自分の目で確かめたいとき。

本番のスループットが必要なら答えは明確です。GPU をきちんと割り当ててください。colibrì もそれを置き換えるつもりはありません — ./coli serve で OpenAI 互換 API を開けますが、その速度で実トラフィックは捌けません。

おわりに — 「動く」と「使える」のあいだ

colibrì で本当に興味深いのは速度ではなく、成立すること自体です。「GPU なしでは不可能」とされてきた規模が、MoE の疎性 + ディスクストリーミング + 賢いキャッシュで、25GBのRAMのマシンでもとにかく答えを返します。「動く」と「使える」は確かに別物ですが、まず「動く」が証明されてこそ「使える」も後から続きます。

ローカル推論の民主化はたいていこの順で来ました — まず「正気じゃないが動く」、次に数年かけて「実用的だ」。llama.cpp もまさにそう始まりました。colibrì が今どのあたりにいるかは、上の数字が正直に語っています。それでも、段落あたり数分が文あたり数秒になる日を想像するのは、そう難しくありません。