colibri解説｜GLM-5.2（744B MoE）を25GB RAMで動かす純Cランタイムの実測速度

「744Bのフロンティア級モデルを、H100のファン1個より安いマシンで動かす」——colibri（JustVugg/colibri）は、その一点だけに賭けたGitHubスター14,900超の推論ランタイムです。動かす相手はGLM-5.2、総パラメータ744BのMoE（Mixture-of-Experts）。それを約25GBのRAMしかないコンシューマ機で走らせます。しかも純C・依存ゼロ、BLASもCUDAもDockerも要りません。2026年7月1日に公開されてから2週間強で247コミット、Hacker Newsでも453ポイントを集めました。ただし——この記事でいちばん大事なのは、その先の「で、実際どれくらいの速度で動くのか」です。

なお、GLM-5.2 ローカル実行の前提となるモデルそのもの（744B MoE・1Mコンテキスト・MITライセンス）の中身については、当サイトのGLM-5.2 使い方・解説｜Z.aiの744B MoEオープンモデルをローカル運用＋ベンチ比較で個別に解説しています。colibriはあくまで、そのモデルを動かすためのMoE 推論ランタイムという位置づけです。また、ローカルLLM全体の前提知識はLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめてあります。

colibriとは何か——「低RAM向けの軽量エンジン」ではない

まず、よくある誤解を1つ潰しておきます。colibriは「非力なマシン向けに小さいモデルを速く動かす軽量推論エンジン」ではありません。公式リポジトリの説明文はこうです——「Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine — pure C, zero deps, experts streamed from disk」。つまり巨大なモデルを、小さいマシンで、遅くてもいいから動かしきるためのランタイムです。READMEのキャッチコピーも “Tiny engine, immense model“（小さなエンジン、巨大なモデル）。エンジンが小さいのであって、モデルが小さいのではありません。

もう1つの特徴が実装の潔さです。エンジン本体は純粋なCで書かれ、実行時の依存はゼロ。BLASもCUDAツールキットもPyTorchもDockerも不要で、gcc と OpenMP、そして AVX2 が使えるCPUがあれば動きます。READMEは「実行時のエンジンは純粋なCで、Pythonは一度きりのコンバーターでしか使わない」と明記しています。19,456個のエキスパートを管理する仕組みが、数千行のCファイルに収まっている——この「工学的な密度」がHacker Newsで刺さった理由でしょう。

何ができて、何を解決するのか

読者が知りたいのは結局この3つのはずです。整理しておきます。

・何ができるか：744B MoEのGLM-5.2を、RAM 25GB程度＋NVMe 400GB程度のコンシューマ機で、精度を落とさずに推論できる
・何を解決するか：「オープンウェイトのフロンティア級モデルが公開されても、個人には動かす機材がない」という断絶。重みは無料で配られているのに、動かすには数百万円のGPUが要る、という状況を「時間で払う」形に置き換える
・何を代替できるか：正直に言えば、速度が要る用途では何も代替できません。代替できるのは「巨大モデルを試すためだけにGPUクラウドを時間借りする」といった検証用途、あるいは「データを外に出さずにローカルで完結させたい」バッチ処理です

なぜ25GBで動くのか——19,456エキスパートをディスクへ追い出す設計

MoEというアーキテクチャの性質が、この芸当を可能にしています。GLM-5.2は総パラメータ744Bですが、1トークンを生成するのに実際に使うのは約40Bだけ。さらにそのうちトークンごとに入れ替わるのは約11GB分（ルーテッドエキスパート）にすぎません。つまり残りは「毎回は要らない」のです。

colibriはこの性質を素直に設計へ落とし込んでいます。

・密部分（アテンション・共有エキスパート・埋め込み、約17Bパラメータ）はint4でRAMに常駐——実測9.9GB
・19,456個のルーテッドエキスパート（75 MoE層 × 256エキスパート ＋ MTPヘッド、1つ約19MB）はディスク上に約370GBとして置き、必要になった瞬間に読み出す
・読み出したエキスパートは層ごとのLRUキャッシュに保持し、よく使われるものはpinned hot-storeへ固定。さらにOSのページキャッシュが「タダのL2キャッシュ」として効く
・キャッシュのサイズは起動時に MemAvailable から自動決定される。ワーキングセット・KV・MTP行・再構成バッファまで含めた「正直なピーク投影」を行い、カーネルのOOMキラーが発動しないようにする

1トークン生成するたびに、75層それぞれで上位8エキスパートが選ばれます。75 × 8 = 600個前後、容量にして約11GBのディスク読み出しが1トークンごとに発生する——これがcolibriの物理です。

この図の「ミス」経路が全体の速度を決めます。キャッシュヒット率が上がるほど速くなり、下がるほどディスクの帯域に張り付く。後述するコミュニティ実測で、ヒット率が3%の機体と98%の機体では30倍以上の差がつきます。

精度は落としていない

「25GBに詰め込む」と聞くと精度の犠牲を疑いますが、READMEは明確です——「高速メモリが不足すると速度は落ちうるが、既定のポリシーはモデルの精度や出力を黙って変えることはない」。int4への量子化は行いますが、それはエキスパートを19MBに収めるための一貫した処理であり、メモリが足りないときに勝手にさらに劣化させることはしない、という設計思想です。

【本題】ハード別の実測速度——どこから実用になるのか

ここからが本記事の中心です。colibriの公式READMEには「Honest numbers（正直な数字）」というセクションがあり、さらにコミュニティが実測したハード別のベンチマーク表が公開されています。この表がcolibriを評価するうえで最も価値のある一次情報です。

主要な実測値を整理すると次のようになります。

ボトルネックは「順番に入れ替わる」

この表の面白さは、単なる速度順のランキングではないところにあります。マシンが良くなるにつれてボトルネックが移動するのです。

第1段階：RAM上限が律速（24〜32GB級）——意外なことに、小RAM機ではディスクが遅いから遅いのではありません。RAMが24GBしかないとエキスパートキャッシュが層あたり2スロットに自動制限され、デコードは冷えたままになります。READMEはこう総括しています——「小RAM機ではディスクではなくRAM上限が拘束条件」。事実、開発者機の2〜2.7倍速いディスクを積んだ機体でも0.07 tok/s程度に留まっています。

第2段階：ディスクが律速（RAM 100GB超・低速SSD）——RAMが増えてキャッシュが育つと、今度はディスク帯域が効いてきます。ここで最も美しい実験がissue #31です。同じ機体・同じ使用履歴のまま、ディスクだけをCrucial P3（QLC Gen3・1.51GB/s）からSamsung 9100 PRO（PCIe 5.0・8.81GB/s）へ交換した結果、0.10 → 0.28 tok/s。帯域は5.8倍になり、トークンは2.9倍になりました。そしてプロファイルが「66%がディスク待ち」から「57%がmatmul」へ反転しています。

第3段階：計算が律速（RAM大・高速NVMe）——ここまで来ると、もうディスクの話ではありません。EPYC 7443の行が象徴的で、RAM 430GBを積んでヒット率98%、ディスク律速が事実上消滅した状態で1.00 tok/s。それでも1 tok/s止まりなのは、Zen3にAVX-512/VNNIが無く、RAM帯域とmatmulが新しい天井になったからです。

GPUを足しても速くなるとは限らない

もう1つ、直感に反する実測があります。Ryzen 7 9800X3D（RTX 5090搭載）の行では、CUDAエキスパート層の効果が≒0%と報告されています。理由は「AVX-512のCPU matmulが5090に匹敵するから」。READMEは「GPU層がVRAMの元を取るのはCPUが弱点であるときだけで、既定で得をするわけではない」と結論づけています。

この行には特筆すべき注釈がついています。READMEは自ら「#101からの正直な訂正」として、以前のバージョンのレポートはOMPチューニングを切った状態で走っており、偽のmatmul律速クロスオーバーとCUDAの偽の+14%を作り出していた。どちらもクリーンな再試験では再現しなかったと開示しているのです。自分に不利な数字を撤回して残す——ベンチマークの誠実さを測るうえで、これは good sign です。

READMEの「4+ tok/s」は6× RTX 5090の画面——数字の読み方

colibriの数字で最も誤読されやすいのがここです。READMEの冒頭近くにダッシュボードのスクリーンショットがあり、そこには確かに「4.2 tok/s」と表示されています。これを見て「25GBのマシンで4 tok/s出るのか」と読むと、完全に間違えます。

READMEの画像キャプション自体がそう書いています——「a 744B model answering at 4+ tok/s end-to-end on 6× RTX 5090」。6枚のRTX 5090を積んだ機体の話です。上のスクリーンショットを見れば、左サイドバーに「6× GPU・202GB VRAM・264GB RAM・48コア」、メモリティアに「Disk 0」——つまりディスク読み出しゼロの全常駐状態——と明記されています。25GBのコンシューマ機の数字ではありません。

公式の実験レポート（docs/experiments/glm52-6x5090-2026-07-12.md）はさらに詳細で、6GPU・24コアで全19,456エキスパートをVRAM＋RAMに常駐させ、ディスク待ちをゼロにした状態で6.28〜6.84 tok/s（96トークンの固定ベンチと256トークン走行）と報告しています。ちなみに同レポートでは、同じ6GPU機で走らせたvLLM-Moetが2.3〜2.7 tok/sだったとも記録されています。ただしこれは特定の1構成での比較であり、「colibriはvLLMより速い」と一般化できる話ではありません。colibriの価値はスループットではなく、そもそも25GB機で744Bが動くことにあります。

実用ラインの線引き——チャットは無理、ではどこからなら使えるのか

ここまでの実測を、実際の使用感に翻訳します。以下の所要時間は実測 tok/s からの単純換算であり、測定値そのものではないことをお断りしておきます。

・0.05〜0.1 tok/s（開発者機・25GB）：500トークンの返答に約1.4時間。対話型チャットとしては成立しません。「動くことの証明」の領域です
・0.28 tok/s（9950X＋PCIe 5.0）：500トークンで約30分。プロンプトを投げて席を立つ運用なら、ぎりぎり回せます
・1.0〜1.23 tok/s（EPYC / M5 Max / 9950X3D2）：500トークンで約7〜8分。夜間バッチや非同期のドキュメント処理なら実用圏。1晩8時間回せば数万トークン処理できます
・2.06 tok/s（M5 Max ＋ Metal・warm pin）：500トークンで約4分。人間が「待てる」ぎりぎりの下限に近づきます
・6.84 tok/s（6× RTX 5090）：500トークンで約1分。ただしこれは数百万円級の構成で、colibriを使う動機そのものが薄くなる領域です

自分のマシンで使えるかを事前に確かめる

colibriには実際にモデルをロードする前の事前チェックが用意されています。coli plan はsafetensorsのヘッダーだけを読んで、密部分のフットプリント・RAM予約・安全なエキスパートキャッシュ上限・VRAMホット層の配置計画を出力します。coli doctor は読み取り専用の実行可能性チェックで、コンパイラ・実行ファイル・利用可能RAM・CUDA連携などを検証し、要件不足や危険なRAM投影なら終了コード1を返します。モデルを400GBダウンロードする前に、これを回すのが正解です。

なお「そもそも自分のPCでどのローカルLLMが動くのか」を判定したい場合は、当サイトで解説しているllmfit完全ガイド：今のPCで動くローカルLLMを1コマンドで判定するツールのようなツールが役立ちます。

llama.cpp・vLLMと何が違うのか——colibriが埋めるニッチ

「llama.cppでいいのでは？」という疑問に答えます。結論から言えば、競合というより設計の中心が違うというのが正確です。

llama.cppは既定でmmapを使うため、物理RAMを超えるモデルをページング経由で動かすこと自体は可能です。実際、MoEモデルをRAMの100〜150%規模で動かす際にmmapが有効だという報告もあります。ただしエキスパート単位のLRUキャッシュ、学習型の固定（pin）、ルーターの先読みプリフェッチといった、MoE特化の階層管理まで作り込んでいるわけではありません（llama.cpp側でもディスクへのエキスパート退避や2階層エキスパートキャッシュは提案・PoCとして議論されている段階です）。colibriはそこだけに全振りした専用機、という理解が実態に近いでしょう。

vLLMとの関係はさらに明快で、土俵が違います。vLLMはGPUのVRAMに載ることを前提に、スループットと並列性を最大化するサーバーです。「VRAMに載らないモデルをディスクから流して1台で動かす」というcolibriの問題設定とは、そもそも解いている問題が別物です。当サイトではvLLMについても個別に解説しています。

似た思想の先行例としては、CPUだけで100B級のモデルを動かすことを狙ったMicrosoftのBitNet｜Microsoftの1ビットLLM量子化フレームワークがあります。BitNetが「重みを1ビットまで削って載せる」アプローチなのに対し、colibriは「int4のまま、載せずにディスクから流す」アプローチ——同じ「小さいマシンで巨大モデル」という目標に、正反対の側から挑んでいる点が対比として面白いところです。

導入手順——コピペで動かす

実際に動かす手順です。前提として約400GBの空きがあるNVMe（できればext4などの実ファイルシステム）と、gcc ＋ OpenMP が要ります。

まずビルド。setup.sh がgcc/OpenMPの確認・ビルド・セルフテストまで一括で行います。

git clone https://github.com/JustVugg/colibri.git
cd colibri/c
./setup.sh

次にモデルです。ここが最大の関門で、選択肢は2つあります。楽なのは変換済みモデルをHugging Faceから落とす方法です。

# 変換済み int4 モデル（int8 MTPヘッド入り）を取得して指すだけ
COLI_MODEL=/path/to/GLM-5.2-colibri-int4-with-int8-mtp ./coli chat

自分で変換する場合は、coli convert がFP8のチェックポイントを1シャードずつ（約5GB単位）ダウンロード→逆量子化→int4へ再量子化→シャード削除と繰り返します。756GBのFP8チェックポイントが一度にディスク上に存在する必要がない設計で、途中から再開もできます。変換時のみ Python（torch・safetensors・huggingface_hub・numpy）が要ります。

# ダウンロードからint4変換、MTPヘッド変換まで1コマンド。中断・再開可
./coli convert --model /nvme/glm52_i4

そして、モデルを落とす前に実行可能性を確かめるのが plan と doctor です。

COLI_MODEL=/nvme/glm52_i4 ./coli plan      # 配置計画（RAM予算・キャッシュ上限・VRAM層）を表示
COLI_MODEL=/nvme/glm52_i4 ./coli doctor    # 読み取り専用の実行可能性チェック（要件不足なら終了コード1）

あとは対話するだけです。RAM予算・エキスパートキャッシュ・MTPはすべて自動検出されます。

COLI_MODEL=/nvme/glm52_i4 ./coli chat

OpenAI互換のHTTP APIサーバーとしても起動できます（ゲートウェイはPython標準ライブラリのみ、推論は同じ依存ゼロのCエンジン）。

COLI_MODEL=/nvme/glm52_i4 COLI_API_KEY=local-secret ./coli serve

速度を稼ぐ実用ノブ

実測表から効果が確認できている設定を挙げておきます。

・--topp 0.7（アダプティブ・エキスパート top-p）——ディスク読み出しを30〜40%削減。Core Ultra 7の実測で0.07 → 0.11 tok/s（約1.6倍）
・RAM_GB=<n>——保守的な自動検出より多くRAMをキャッシュへ割り当てる。32GBホストで RAM_GB=31 にするとヒット率が実測で改善
・int8 MTPヘッド＋大きめのキャッシュ上限＋学習型pin——Framework 13の実測で0.29 → 0.37 tok/s（ヒット率28% → 66%、採択率52%）
・DIRECT=1 / PIPE=1 / URING=1（Linux）——I/O経路の最適化。Strix Haloで0.06（cold）→ 1.10 tok/s（sustained）
・キャッシュを温める——warmとcoldは別物。M5 Max＋Metalは走行中に1.11 → 1.83 tok/sまで伸びている

使えるかどうかの判定材料——ライセンス・活性度・リスク

採用判断に必要な事実を並べます。

ポジティブ材料は、依存ゼロという性質そのものです。npmやpipの依存ツリーを持たないため、サプライチェーン攻撃の面は事実上ありません。ライセンスもApache-2.0で商用利用に問題なし。16日で247コミット・30名超のコントリビュータという活性度は、「スターだけ多くて中身がない」タイプのリポジトリとは明確に違います。

ネガティブ材料も正直に挙げます。

・リリース0本——バージョンの目印がなく、main が動く保証は日々変わりうる
・Metal / CUDA は experimental——READMEが自ら明記している
・出力のバイト単位の再現性がない場合がある——これは重要な注意点で、READMEは「量子化整数カーネルは形状依存であり、バッチ（S>1）やGPUの前向き計算は単一トークン経路とわずかに異なる丸めをする。int4のGLM-5.2はargmaxの同点に十分近く、その丸めの違いでトークンが入れ替わりうる」と開示しています。投機ゼロでもカーネル系統を替えるだけで5問中3問でgreedy出力が分岐した、というコミュニティ確認まで書かれています。バイト単位の再現性が必要なら DRAFT=0、さらに IDOT=0 COLI_CUDA=0 の指定が要ります
・単一モデル専用——GLM-5.2以外には使えない。GLM-5.2が世代交代したとき、このランタイムがどうなるかは未知数
・そして何より遅い——ここまで見てきたとおり

まとめ——「動く」と「使える」の間にある距離

colibriは、744BのGLM-5.2を25GBのRAMで動かすという一点において、間違いなく本物です。19,456個のエキスパートをディスク上の階層として扱い、密部分9.9GBだけをRAMに残す設計は、MoEというアーキテクチャの性質を最も素直に突いた実装であり、それを純C・依存ゼロでやりきったエンジニアリングは称賛に値します。Apache-2.0、16日で247コミット、30名超のコントリビュータ——プロジェクトとしての実体も十分にあります。

同時に、チャット用途では現実的に使えません。開発者機の0.05〜0.1 tok/sは1トークンに10〜20秒であり、これは「動くことの証明」であって「使えるツール」ではない。実用ラインは概ね1 tok/s——RAMを100GB以上積み、PCIe 4.0以降のNVMeを載せた機体で、夜間バッチや非同期処理として回すところからです。M5 Max＋Metalの2.06 tok/sが現時点の民生機の最速で、それでも500トークンに4分かかります。

参照ソース

・JustVugg/colibri（公式リポジトリ・README） — 設計・Honest numbers・コミュニティ実測表・各種ノブの一次情報
・GLM-5.2 on 6x RTX 5090（公式実験レポート・2026-07-12） — 全エキスパート常駐時の6.28〜6.84 tok/sとvLLM-Moet比較の詳細
・GLM-5.2-colibri-int4-with-int8-mtp（Hugging Face） — int8 MTPヘッド入りの変換済みモデル
・issue #31 — 同一機体でディスクのみ交換した実測 — 0.10 → 0.28 tok/s、プロファイル反転の記録
・issue #4 / #5 — Apple M5 Max の実測 — 1.06 tok/s のデータポイント
・llama.cpp Discussion #23324 — MoE offload to disk with on-demand paging — 他エンジンにおける同種アプローチの議論状況