【検証】非力なPCで744Bパラメータの「GLM 5.2」を動かす！極限の軽量化プロジェクト「Colibrì」誕生

先日、GLM 5.2を試してみたのですが、その性能とセキュリティレベルの高さに驚かされました。ClaudeやGPTと同等のLLMが手元で動くなんて、正直信じられません。そこで、「自分の非力なPCでも動かせるのか？」「メモリ不足（OOM）にならずに完走できるのか？」という疑問を解消するため、AIエージェントの助けを借りて検証を始めました。int4量子化やMTPの使用、さらには長文コンテキストのためのDSAの実装などを経て、最終的に32GB RAMのPCでGLM 5.2を動かすことに成功しました。速度は0.1 tok/sと極めてスローですが、重要なのは「動かせる」という事実です。その過程で生まれたのが「Colibrì」です。744BのMoE（Mixture-of-Experts）モデルでありながら、トークンごとにアクティブ化されるのは約40B、そのうち更新されるのは約11GBのみという特性を活かしています。高密度部分（約17Bパラメータ、約9.9GB）はRAM上に常駐させ、21,504個のルーティングされたエキスパート（約370GB）はディスク上に配置してオンデマンドでストリーミングする仕組みです。エンジンはC言語の1ファイル（約1,300行）のみで完結し、BLAS、Python、GPUは一切不要です。12コア・25GB RAMのノートPCで開発・テストした個人プロジェクトですが、興味のある方はぜひフィードバックをください。コントリビューターも大歓迎です！リポジトリ: https://github.com/JustVugg/colibri

一番の疑問は、実用レベルで考えた時にトークン/秒で測定できるのか、それとも1分に1トークンくらいのレベルなのかってことだ。ローカルで動かすLLMで1トークン/秒くらい遅いやつでも、夜通しプロジェクトを投げ込んで、6〜8時間後に結果を確認するような使い方なら十分役に立つのは経験済みなんだけどね。一方で、このURLの低スペック環境向けの報告にある0.05〜0.1トークン/秒ってのは、正直ほとんど使い物にならないよ。追記：このプロジェクトのコンセプト自体は最高だし、350B〜900Bクラスの巨大なモデルを一般家庭用のPCで、たとえ1トークン/秒だとしてもローカル実行できるようにする取り組みはもっと増えてほしい。高速なNVMe SSDがあるなら、モデル全体をメモリにロードしようとせず、必要な時に11GB/トークン単位で読み込むっていうアイデアは筋がいいと思う。

めっちゃいいじゃん！自分も今週GLM 5.2をいじってて、同じく感銘を受けてたところ。仕事では死ぬほど高いハードウェアを使ってテストしてるけど、こうやって誰かが巨大なFOSSモデルを普通のPCで動かそうとしてるのは素晴らしいこと。現時点では実用的とは言えなくてもね。いい仕事だ！

実は自分も同じものを作ってたんだけど、RAMの追加消費を抑えるためにモデル全体をmmapでメモリにマッピングするアプローチをとったよ。あと、別のモデルをメモリにロードするのを避けるために、Claudeを使ってモデルにMedusa[1]を実装してMTPの恩恵を得ようともしてた。今は信号待ちで詳しく書けないし、投稿もまだ全部読めてないんだけどね。家に帰ってから補足すると、全部llama.cppを改造してやってて、最終的にはNVMeでmmapファイルが扱えるようなSBC（シングルボードコンピュータ）に乗せるのが目標。今の環境での理論限界は事前テストだと1.8トークン/秒くらいだけど、Medusaヘッドが完全には学習されてない状態（そもそもトークン数にカウントされるのかも分かってない）での話。結局、似たようなアイデアに行き着いたみたいだね。自分はまだLLMのパーサーやランナーをスクラッチで書く方法が分からないから、メモリ管理はLinuxカーネルにお任せしちゃってるけど。あ、最後に一つ。llama.cppのメモリ使用量を32GB中16GBに制限してたから、もっと下げられる可能性はあるかも。

自分もhttps://github.com/cretz/thinfer で画像や動画生成で似た戦略をとってるよ（videoブランチを見ると作業の様子がわかるはず）。要は、LRUアルゴリズムで必要に応じてウェイトを出し入れできる推論エンジンが必要だったんだよね。で、最終的に--vram-budgetを指定して（ほぼ）その範囲内に収まるようにするコードを適当に書いてみた。結局、mmapしたバイトをVRAMに出し入れするのは計算量に比べれば屁でもない。パイプラインやダブルバッファリングを組み合わせれば、メモリ境界というより計算境界（compute bound）になることがほとんど。まあ、自分はもっと小さいモデルを使ってるからっていうのもあるけどね（笑）。

ページにSSDの摩耗警告[0]があるね。自分は自作PCだからSSDを交換できるけど、オンボード（はんだ付け）のユーザーはどうするんだろう？こういったアプリケーションを避けるか、ストレージの寿命が縮むのを承知で突っ走るか。消耗品としてのSSDを外付けで使うのが前提なのかもね。

Apple SiliconのmacOS向けに似たようなことをやってるよ。UnslothのGGUF分割、ユニファイドメモリでの圧縮済み部分読み込み（自分の64GBより128GBの環境向けだけど）、ネイティブMetalカーネル、そしてRAMのみのネイティブ圧縮KV。準備ができたらGitHubに公開するつもり。

こういうのってすごく楽しいよね。自分はもっと小規模な方向で、DiffusionGemma (26B) をカスタム量子化したRustポートをいじってる。ベンチマークの印象より（応答が）優秀で、サイズにしては十分高速。36GBのMacでもプリフィルと生成の両方でかなりうまく動いてるよ。ユニファイドメモリでMetalカーネルを高性能化するためのバランスを学ぶのは面白いね。数週間以内にGitHubにリポジトリを上げる予定。

今週頭にGemma4.pasを知ったばかりなのに、今度はこれか。推論エンジンってこんなに簡単に作れるものなのかと驚いてる。詳しくないから、めちゃくちゃ高度な数学やシステムレベルの深い知識が必要で……ひたすら根気が必要な作業だと思ってたよ。

ユーザーランドとカーネルのやり取りにどれくらい時間を使ってるの？カーネルモジュールとして動かす挑戦はしてみた？ :) あと、CPUがそれなりに古いなら、CPUのバグ緩和策（mitigations）を無効化してみたりした？

MTPのみの結果が、出力品質とトークン/秒の面でどうなるのか興味ある！