colibriとは何か 744BのMoEモデルを25GB RAMで動かすpure C推論エンジン

colibri（JustVugg/colibri）は、GPUやPythonランタイムに依存しないpure C製のローカル推論エンジンで、VRAM・RAM・ストレージを1つの統合メモリ階層として扱うことで、744Bパラメータ級のMoE（Mixture of Experts）モデルを一般的なPCで動かせるようにする。ライセンスはApache 2.0。2026年7月10〜11日にリリースされ、Hacker Newsで「Show HN: Getting GLM 5.2 running on my slow computer」として投稿され900pt超を獲得、GitHub Trendingにも浮上した。2026年9月14日時点でGitHubスター数は約3万。

結論を先に言うと、colibriは「速さ」ではなく「メモリに載らないはずの巨大モデルを、正確さを保ったまま一応動かす」ことを目的にしたエンジンである。GLM-5.2（744Bパラメータ、活性化は約40〜55B）を25GBのRAMで動かせるが、速度はコールドキャッシュ時で0.05〜0.1トークン/秒と、実用速度とは言えない。ウォームキャッシュや潤沢なハードウェアがあれば数トークン/秒まで上がる。

MoEモデルは全パラメータのうち、1トークンあたり実際に計算に使うのはごく一部（アクティブパラメータ）だけという特性を持つ。GLM-5.2の場合、744Bパラメータのうち実際に使うのは約40B、しかもトークンが変わっても更新される部分は約11GB相当にとどまる。colibriはこの特性を利用し、モデルを2つに分けて扱う。

- 常時RAM常駐: Attention・埋め込み・共有Expertなど、どのトークンでも使う「共通層」（GLM-5.2で約17B、int4量子化で約9.9GB）
- ディスク常駐＋オンデマンド読込: ルーティングされるエキスパート群（GLM-5.2で約19,456個、1個あたりint4で約19MB、合計約370GB）はディスク上にmmapで置き、ルーターが選んだ分だけ読み込む

読み込みには層単位のLRUキャッシュを使い、学習的なピン留め（よく使われるエキスパートを優先的に保持）と1層先読みでディスクI/Oを減らす。開発元はこの挙動を「重み版のJITコンパイラ」と表現しており、実行パターンを見ながら「ホットな」エキスパートを高速なティアへ動的に配置していく。GPUがあればVRAM常駐という追加の高速ティアとして使えるが、CPUのみの経路も完結しており必須ではない。

開発元はこの設計思想を「速度より正確さ」と表現しており、量子化やティア配置によってモデルの出力が変わらないよう、Hugging Face transformers との完全一致（トークン単位のオラクル検証）を品質担保の基準にしている。速いメモリが足りなければ遅くなるだけで、モデルの意味的な挙動自体は変えない、という設計原則である。

colibriはモデルファミリーごとに専用のCファイル（例: c/glm.c は約2,400行）を持ち、共通のCLIで操作する。2026年9月時点で以下のモデル系列に対応している（数値は概算・README記載値）。

対応モデルはREADMEの更新頻度が高く、今後も追加が見込まれる。最新の対応状況はGitHubリポジトリで随時確認するのが確実である。

colibriはLinux・macOS・Windows向けのビルド済みバイナリを配布しており、コンパイラなしですぐ試せる。

ビルドまたは展開後は、共通のCLI coli で操作する。

主な環境変数には、モデルパスを指定する COLI_MODEL、VRAMティアのサイズを自動調整する CUDA_EXPERT_GB=auto、全エキスパートをRAMにピン留めする PIN_GB=all、2枚のSSDへ分散配置して読み込み帯域を約33%向上させる COLI_MODEL_MIRROR、投機的デコードを無効化する DRAFT=0、マルチソケット環境向けの COLI_NUMA=1 などがある。

colibriの最小要件は動かすモデルによって大きく異なる。目安は次の通り（2026年9月時点、README記載の実測・概算値）。

開発元自身が明言している通り、速度を決めるのはモデルサイズそのものよりディスクI/Oである。GPU・VRAMティアは高速化に寄与するが必須ではなく、CPUのみの経路が完結した動作パスとして用意されている。ゲーミングPC程度のNVMe＋RAM32GB前後でも動かせるが、実用的な対話速度を求めるなら中小規模モデル（Qwen3.6やOLMoEなど）を選ぶか、GPUを複数枚用意する必要がある。

colibriはGLM-5.2のネイティブなMTP（Multi-Token Prediction）ヘッドを使った投機的デコードに対応する。ドラフトしたトークンを1回のバッチ処理でまとめて検証し、キャッシュがウォームな状態では1回のフォワードパスあたり2.2〜2.8トークンを生成できる。ただしMTPヘッドはint8精度が必須で、int4量子化すると採択率が0〜4%まで落ち込むとされる。コールドワークロードでは検証コストがドラフトの節約分を上回るため、デフォルトでは無効化される。

またMLA（Multi-head Latent Attention）方式によりKVキャッシュを1トークンあたり576floatまで圧縮（通常の32,768floatに対し約57分の1）し、.coli_kv ファイルとして永続化する。これにより会話を再開する際、プリフィル（プロンプトの再計算）なしで続きから再開できる。

ローカルLLM実行エンジンはすでにllama.cpp・Ollamaという定番があるほか、2026年に入ってからも小型MoEを省メモリで動かす専用エンジン（turbo-fieldfare、Edge0）が登場している。狙いはそれぞれ異なる。

llama.cppとOllamaは「モデル全体をメモリまたはVRAMに載せる」ことを前提にした汎用エンジンで、密モデルを含む幅広いモデルを安定して動かせる反面、モデルサイズがハードウェアのメモリ容量を超えると動作しない。turbo-fieldfareとEdge0はcolibriと同じ「ディスクからエキスパートをストリーミング」する発想を採るが、対象はGemma 4 26B-A4BやEdge0の35B/8B級といった比較的小さいMoEモデルで、Apple SiliconのMLX/Metal環境に最適化されている。colibriはこれらより一桁以上大きい、数百B〜Kimi K3の2.8Tパラメータ級までを対象にしており、GPUを持たないLinux/Windowsサーバーでも動かせる点が異なる。速度面では、turbo-fieldfareやEdge0が実用的な対話速度（十数〜千トークン/秒級、条件次第）を狙うのに対し、colibriは巨大モデルを「動かせること」自体を優先し、速度は二の次という位置づけである。

colibriはまだ2026年7月にリリースされたばかりの新しいプロジェクトであり、対応モデルやパフォーマンス数値は今後のアップデートで変わる可能性が高い。実運用のチャットボットやAPIサービスとして常時利用するより、手元のハードウェアで「フロンティア級の巨大MoEモデルが動くかどうか」を検証する用途、あるいは研究・実験目的での利用に向いている。速度が遅い場合はモデルサイズを下げるか、COLI_MODEL_MIRROR によるデュアルSSDストライピングやGPUティアの追加で改善できる余地がある。

- Edge0-35B-A3Bとは何か — SSDストリーミングで35BのMoEを3GB未満のRAMで動かす仕組みと必要スペック
- Nex-N2.5 必要スペック早見表 — VRAM 約22GB〜1.6TB級／RTX 4090〜H200マルチノード【2026年9月版】
- ローカルLLMのコンテキスト長とVRAM — KVキャッシュ計算式と早見表