Colibrìは、GLM-5.2を一般向けPCで動かすための推論エンジンです。プロジェクトが対象にするのは、総パラメーター数744B、トークンごとに約40Bが働くMixture-of-Experts（MoE）モデル。モデル全体をRAMやVRAMへ載せる代わりに、必要なエキスパートだけをNVMe SSDから読み込みます。約25GBのRAMで起動できる、という数字の中身は「巨大モデルの圧縮」だけではなく、メモリ階層の使い分けです。(GIGAZINE, GitHub)
常に使う重みと、選ばれた重みを分ける
GLM-5.2では、attention、shared expert、embeddingなど約17Bの密な部分を毎回使います。Colibrìはここをint4で約9.9GBに収め、RAMへ常駐させます。残る19,456個のrouted expertは、int4で約370GB。75層それぞれのrouterが選んだエキスパートをディスクから取り出し、計算後もよく使うものはレイヤー別のLRUキャッシュや利用履歴に基づくhot-storeへ残します。OSのpage cacheも二段目のキャッシュとして働きます。(GitHub)
発想としては、VRAM、RAM、ストレージを別々の置き場ではなく、速度と容量が違う一続きのメモリとして扱うものです。高速な領域が足りなければ待ち時間は増えますが、既定の方針では精度やrouterの判断を黙って変えません。省メモリ化のために別のモデルへ近似するのではなく、同じモデルの重みを「いつ、どこから読むか」で成立させています。
25GBで動くが、370GBは消えない
小さくなるのは実行時のRAM使用量であって、モデルの総容量ではありません。変換済みモデルを置くローカルNVMeには約370GB、導入時にはおよそ400GBの空きが要ります。推論時にPython、BLAS、GPUは必須ではなく、中心となるエンジンはCの単一ファイルと小さなヘッダー群です。ただし、公式FP8チェックポイントからint4コンテナを自分で作る場合は、変換処理にPythonやPyTorchなどを使います。(GitHub, GLM-5.2)
この構成ではストレージ性能が、そのまま生成待ち時間に響きます。開発者の12コア、25GB RAM、NVMe環境で示されたcold decodeは0.05〜0.1 token/s。キャッシュが空なら、1トークンごとに約11GBを読む計算です。1トークンに10〜20秒かかる水準なので、「手元で動く」と「対話的に使える」は分けて読まなければなりません。キャッシュが温まり、頻出エキスパートがRAMへ乗れば速くなりますが、25GB前後の小容量構成では保持できる量にも限界があります。(GIGAZINE, GitHub)
見るべきはモデルサイズよりデータの動き
Colibrìが見せているのは、744B級モデルを軽量モデルのように扱える未来ではありません。MoEの疎な計算を利用し、容量不足を大量の読み込みへ置き換えれば、これまで起動すら難しかったモデルを限られたRAMで実行できる、という境界です。
試すならRAM容量だけで判断せず、約400GBの空き、NVMeのランダム読み込み性能、CPUのAVX2対応、許容できる応答時間を先に確認したいところです。Colibrìには環境と配置を読む coli doctor と coli plan も用意されています。まず計画を表示し、どの重みがRAMに残り、どれだけディスク待ちが発生するのかを見る。このエンジンは、その数字まで含めて評価するのが似合います。(GitHub)