メインコンテンツまでスキップ

Colibrì:744B MoE を SSD から動かす(そして本当のコストは何か)

上級
What you'll learn
  • 3階層のトリック ― 密な重みは RAM、ルーティングされるエキスパートはディスク、任意で VRAM 階層 ― と、MoE だからこそそれが可能になる理由を理解する
  • ベンチマーク表を正直に読む:どのハードウェアが 0.1 tok/s、どれが約2、どれが約6になるのか、そしてなぜ上限を決めるのが CPU ではなく NVMe 帯域なのか
  • 何日も無駄にさせる4つの落とし穴を知る:int8 MTP ヘッド、間違ったドライブでの O_DIRECT、損になる投機的デコーディング、SSD 摩耗
  • git clone から GLM-5.2 または DeepSeek V4.1 Flash での最初のストリーミングトークンまでたどり着く
  • Colibrì が GGUF + Ollama のオフロードに勝つのはいつか、代わりに GPU を借りるべきなのはいつか、ホスト型 API が単純に正解なのはいつかを判断する

2026年7月1日、JustVugg として活動する開発者が、一行の約束を掲げたリポジトリを公開しました。すでに持っているハードウェアでフロンティア MoE モデルを動かす ― 純C、依存ゼロ、エキスパートはディスクからストリーミング。Show HN スレッドは9日後に453ポイントに達しました。9月中旬時点でプロジェクトは 30.8k スターに達し、9月13日リリースのバージョン 1.11.0 では、公開チェックポイントを変換ステップなしでネイティブに読み込む9番目のモデルファミリー(DeepSeek V4.1 Flash、552B)が追加されました。このページの執筆時点で、GitHub のデイリートレンドで AI リポジトリのトップにいます。

この売り文句はトリックのように聞こえますし、ある意味では実際にトリックです。このページでは、370 GB をダウンロードする前にあなたのマシンで何が起きるかを予測できる程度に正確にそのトリックを説明します。

一文で言うと​

Mixture-of-Experts モデルはトークンごとに重みのごく一部しか触らないので、Colibrì は常に使われる部分(アテンション、埋め込み、共有エキスパート)を RAM に常駐させ、めったに使われない部分(ルーティングされるエキスパート)をオンデマンドで NVMe から読み込みます。秒あたりのトークン数と引き換えに、7440億パラメータのモデルをノートPCで動かす能力を手に入れるのです。

MoE がこれを可能にする理由​

プロジェクトがそれを中心に構築されたモデルである GLM-5.2 を参照ケースとして取り上げます。

量値
総パラメータ数744B
トークンごとのアクティブ数約40B
密な(常時オン)パラメータ約17B → int4 で 約9.9 GB 常駐
ルーティングされるエキスパート全層で約2万 → int4 でディスク上に 約370 GB
トークンごとに変わるエキスパートの重み(コールド)約11 GB
最小 RAM / 快適な RAM16 GB / 24 GB

すべてのトークンは、密な 9.9 GB に加えて、各層でルーターが選ぶ一握りのエキスパートを必要とします。密な部分は RAM に収まります。エキスパートは収まりません。しかし一度に必要なのはそのうちの数個だけで、次のトークンは同じものの多くを再利用することがよくあります。そこでエンジンは VRAM、RAM、NVMe を一つのメモリ階層として扱います:最近使われたエキスパートの層ごとの LRU キャッシュを RAM に、最も頻繁に使われるエキスパートの学習済み「ピン留めホットストア」、GPU があれば任意の VRAM 階層、そしてそれ以外すべてのバッキングストアとしてのディスクです。

フレームワークではなくモデルごとに単一のCファイルにした設計上の選択:BLAS なし、実行時に Python なし、GPU 不要。GLM エンジンは約1,300行のCから始まりました。依存ゼロは、OS のページキャッシュがエキスパート読み込みのための無料の第2キャッシュ層になることも意味します。

理解しておく価値のある4つの仕組み​

1. ルーター先読み:ルーティングは1層先で71.6%予測可能​

ストリーミングで高くつくのはディスクを待つことです。Colibrì は先読みスレッド(PILOT=1 で有効化)を実行し、次の層が必要とするエキスパートを予測して早めに読み込みを開始します。README の測定値では、ルーティングの判断は1層先で71.6%予測可能であり、I/O レイテンシの大部分を計算の裏に隠すのに十分です。「ウォームアップ後の tok/s」が「コールド tok/s」とはまったく違う数字になるのはこのためです。

2. デュアル SSD ストリーミング:2台のドライブ、1つのモデル、帯域の合算​

モデルの完全なコピーを2台目の NVMe に置くと、エンジンは両方から同時にストリーミングします。各エキスパートは各ドライブの測定された帯域で重み付けされ、決定論的に一方のドライブにハッシュされるので、重複キャッシュはなく、実効読み込み帯域はおおよそ2台の合計になります。下記の DeepSeek V4 Flash ベンチマーク(RTX 5080 + NVMe 2台、約1.6 tok/s)はデュアルドライブ構成です。

3. 再起動を生き延びる圧縮 KV 状態​

Multi-head Latent Attention(MLA)を持つモデルでは、Colibrì は圧縮された KV 状態を保存できます ― トークンあたり 32,768 ではなく 576 個の浮動小数点数、57倍の削減です。エンジンはその状態を .coli_kv ファイルに永続化するので、再起動後に会話を再び開いてもプリフィルのやり直しはゼロで、止まらなかったセッションとバイト単位で同一です。プリフィルがストリーミング速度で走るマシンでは、長いコンテキストをプリフィルし直さずに済むかどうかが、使えるか使えないかの分かれ目です。

4. セマンティクスは保証される、速度は保証されない​

プロジェクトが掲げる契約:高速メモリの不足は遅くするだけで、精度とルーターの挙動が黙って変わることは決してない。フォワードパスは transformers オラクルに対してトークン単位で完全一致するよう検証されています。これは「ノートPCに収まる」を謳うほとんどの量子化ストーリーとは逆のトレードで、そちらは別のモデルを受け入れることで速度を得ています。

ベンチマーク表を正直に読む​

プロジェクトの README からの数値(特記なき限り GLM-5.2)、記載がある場合はウォームキャッシュ:

ハードウェアTok/s意味
RTX 5090 × 6、エキスパート全体が VRAM に常駐5.8〜6.8(TTFT 約13秒)上限:ディスク I/O が一切ない。これは GPU リグであって「すでに持っているハードウェア」ではない。
128 GB RAM デスクトップ、CPU のみ、ウォームキャッシュ約1.8GPU なしの太いワークステーションでの現実的な最良ケース。
RTX 5070 Ti 1枚(約24 GB の VRAM 階層)1.07ノートPC級 GPU でコールドディスクの下限がおおよそ2倍になる。
RTX 5080 + 32 GB RAM + NVMe 2台、DeepSeek V4 Flash3k コンテキストで約1.6、ウォームアップ後より小さいモデルでのデュアル SSD 経路。
25 GB RAM ノートPC、遅い NVMe、コールド0.05〜0.1見出しの「25 GB で 744B」構成。10〜20秒に1トークン程度。

あなたの数字を決める変数は ドライブのランダム読み込み帯域であって、CPU ではありません。コールドなトークンは 11 GB 程度のエキスパート読み込みを必要とします。したがって 13〜15 GB/s の PCIe 5.0 NVMe では、コールドでプリフェッチなしの構成は 1 tok/s 近辺が上限になり、そこから上に行けるのは先読みとキャッシュヒットのおかげです。ローンチスレッドのコメント投稿者は、128 GB の Apple M5 Max で約23%のキャッシュヒット率、192 GB の DDR3 を積んだ古いデュアル Xeon で 0.091 tok/s ― 「一晩がかりのジョブなら実用的」― を報告しています。

つまり正直なユースケースは:夜間または非同期のバッチ、フロンティア級モデルを使ったプライベートなオフライン実験、MoE 推論が実際にどう振る舞うかの研究、そして 100 GB 以上の RAM を持つマシンでのウォームなマルチターンチャットです。32 GB ノートPCでのインタラクティブなペアプログラミングはリストに入っていません。

9つのモデルファミリーと、それぞれのディスクコスト​

モデル総数 / アクティブディスクRAM 最小備考
OLMoE7B / 1B約7 GB8 GB「ビルドが動くか」確認用モデル
Qwen3.635B / 3B約20 GB24 GB(RAM 完全常駐)GPU は任意。8 GB カード2枚で7倍の高速化を測定
Qwen3.8-Flash-Next125B + 51B n-gram / 6B約185.5 GB16 GBCPU のみ
DeepSeek V4 Flash284B / 13B約167 GB16 GBネイティブ fp4 エキスパート。GPU は任意(Pascal 以降)
GLM-5.3-Flash321B / 40B約195 GB25 GBビジョン対応
DeepSeek V4.1 Flash552B / 16B約203 GB16 GB1.11.0 で新規。公開チェックポイントを変換なしで読み込む
GLM-5.2 / 5.3744B / 40B約372 GB16 GB参照モデル。MIT ライセンスの重み
Inkling975B / 41B約469 GB25 GBbf16 の密な部分はデフォルトで 49.4 GB 常駐。int4 ツールで 25 GB ホストに収まる
Kimi K32.8T / 104B約1.6 TB32 GB 以上ネイティブ MXFP4。生のチェックポイントが必要で、変換手段はない

量子化はファミリーごとで、単一のグローバル設定ではありません:GLM と Inkling は int4 グループスケール、OLMoE と Qwen3.8 は int8 またはブロック FP8、Kimi K3 はネイティブ MXFP4、DeepSeek V4 系はネイティブ fp4 エキスパートと fp8-e4m3 の密な部分です。vLLM デプロイですでに Kimi K3 や DeepSeek V4.1 Flash の重みを持っているなら、Colibrì はその同じファイルを読み込みます。

何日も無駄にさせる4つの落とし穴​

  1. MTP ヘッドは int8 でなければならない。 int4 に量子化された Multi-token-prediction ドラフトヘッドはドラフト受理率 0〜4% になり、投機的デコーディングが黙って何もしなくなります(issue #8)。Hugging Face の事前変換済み GLM-5.2 コンテナが、モデルは int4、MTP は int8 になっているのはまさにこのためです。
  2. O_DIRECT はドライブによって効いたり害になったりする。 ページキャッシュのバイパスは、DRAM キャッシュと帯域の余裕がある NVMe ドライブでは +34% を測定し、QLC、DRAM レス、仮想化ディスクでは中立から負でした。自分のドライブで両方をベンチマークしてください。他人のフラグをコピーしないように。
  3. 投機的デコーディングは実際のチャットでは正味の損になることが多い。 マルチターンの会話では、MTP と文法ドラフターは24トークンのうちおおよそ1〜10しか受理されず、拒否されたサフィックスのためにエンジンの再帰的アテンション状態をリプレイするコストが、受理されたドラフトによる節約を上回りました。DeepSeek V4 についてプロジェクトは495秒の拒否サフィックスのリプレイを測定し、両方のドラフターをデフォルトでオフ(V4_DRAFT=0、V4_MTP=0)にして出荷しています。勝ちが測定できた場合にのみオンにしてください。
  4. SSD 摩耗は現実のもの。 重いエキスパート読み込みはページキャッシュの入れ替えを激しくします。README はコンシューマ向けドライブの摩耗について警告しており、ローンチスレッドのアドバイスはスワップを無効化し、モデルディレクトリを読み取り専用マウントにすることを検討せよというものでした。1日に何時間も 370 GB のモデルをストリーミングするのは、コンシューマ向け NVMe が想定して売られたワークロードではありません。

もう一つ、落とし穴というより制限事項:学習済みのエキスパートピン留めは、あなたのルーティング履歴に過学習することがあります。繰り返しのワークロードには有効ですが、メンテナーは、新しいプロンプトでの利得を信頼する前に、ホールドアウトのクロスセッション A/B テストがまだ必要だと述べています。

clone から最初のトークンまで​

Guided walkthrough1 of 5
  1. git clone https://github.com/JustVugg/colibri && cd colibri/c && ./setup.sh ― その後、GLM-5.2 なら make -C c glm、他のモデルなら make -C c inkling / make -C c kimi_k3。数百ギガバイトのダウンロードに踏み切る前に、OLMoE(7 GB)でビルドを確認しておきましょう。

GLM-5.2 での最小限の初回実行(Linux、NVMe 1台)

git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh
make -C c glm
./coli convert --model /nvme/glm52_i4        # one-time download + convert
COLI_MODEL=/nvme/glm52_i4 ./coli plan          # see what lands where
COLI_MODEL=/nvme/glm52_i4 PILOT=1 ./coli chat  # first streamed tokens

Colibrì と、すでに知っている代替手段との比較​

経路得意なことColibrì との違い
llama.cpp / Ollama の GGUF オフロード(Ollama ガイド)巨大なモデルカタログ、GPU オフロード、成熟したツール群。GLM-5.2 のページでは 239 GB の動的2ビット GGUF 経路を扱っているGGUF オフロードは量子化モデル全体を RAM + VRAM に置く必要がある(GLM-5.2 の2ビットで 256 GB)。Colibrì は 16〜24 GB の RAM と大きなディスクで済み、2ビットではなくラボが公開した精度そのままで動く。
レンタル GPU 上の vLLM / SGLang(Kimi K3 デプロイガイド)秒間数十トークン、バッチ処理、複数ユーザーすべてが HBM に常駐しているから速い。Colibrì はそのハードウェアが利用できない、または許可されない場合のために存在する。
ホスト型 API(DeepSeek、Z.ai、Moonshot)トークン単価が圧倒的に安い、ハードウェア不要Colibrì を選ぶ唯一の理由は、重みとプロンプトがマシンから決して出てはならないこと、または MoE 推論そのものを研究したいことである。

Colibrì の正しい捉え方は「速い llama.cpp」ではありません。それは、他の方法では読み込めないマシンでフロンティアサイズのオープンモデルを利用可能にし、待つのではなくスケジュールを組む速度で動かすためのツールです。インタラクティブ作業用の小さく速いローカルモデルと、バッチジョブ用の大きく遅いモデルを組み合わせるプライバシー第一のスタックについては、プライベートなローカル AI スタックを参照してください。

Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 7

Check yourself

0/5
  1. なぜ Colibrì では 744B モデルが 16〜25 GB のマシンでそもそも動くのですか?
  2. エキスパートをコールドでストリーミングするとき、秒あたりトークン数を縛る制約は何ですか?
  3. なぜプロジェクトは DeepSeek V4 の投機的デコーディングをデフォルトでオフにして出荷しているのですか?
  4. GLM-5.2 を自分で全テンソル int4 に量子化したところ、投機的デコーディングのドラフト受理率が約2%でした。何が起きたのでしょうか?
  5. NVMe 1台の 32 GB ノートPCで、Colibrì がよく合うワークロードはどれですか?

出典と参考資料​

次へ​