colibriで744B MoEをローカル実行する方法｜必要スペックと速度

744B パラメータ級の大規模 MoE（Mixture-of-Experts）モデルは、クラウド API 越しに借りるものだと考えられがちです。重みを全部メモリに載せようとすれば数百 GB の高速メモリが必要になり、自社で確保できるハードウェアの範囲を簡単に超えてしまいます。機密データを外部に出せない制約があると、そこで検討が止まってしまうことも少なくありません。

一方で「ディスクからエキスパートをストリーミングすれば動く」という手法が広まり始めています。ただこの領域は情報が整理されておらず、必要な RAM の値ひとつを取っても記事ごとに食い違っていることがあります。結果として「自分のマシンで動くのか」「動いたとしてどれくらいの速度なのか」という最初の 2 つの問いに答えが出ず、372GB のモデルをダウンロードする決断ができない、という状態になりがちです。

colibri（README では colibrì とも表記）は、この問題に対して「ストレージ・RAM・VRAM を単一の推論階層として扱う」という設計で答えている推論エンジンです。モデルを高速メモリに収めるのではなく、ルータが必要と判断した瞬間にエキスパートをディスクからステージングすることで、744B から 2.8T パラメータのモデルを手元のハードウェアで動かします。必要スペックとハードウェア別の実測速度が公式ドキュメントに数値付きで公開されているため、導入前に見積もりを立てられるのが特徴です。

本記事では、公式 README・公式サイト・docs/ 配下の公式ドキュメント・GitHub Issues・gh api で取得したリポジトリメタデータをもとに、以下の 4 点を整理します。

• colibri がディスクストリーミングでローカル実行を成立させている仕組み
• 入手からモデル配置・起動までの手順と、つまずきやすい箇所
• モデル別の必要ディスク容量・RAM と GPU の要否、ハードウェア別の実測 decode 速度
• KTransformers・llama.cpp・airllm との棲み分けと、採用・見送りの判断軸

なお本記事は公開ドキュメントの読み解きに基づく整理であり、インストール・実行・ベンチマーク取得といった動作検証は行っていません。数値はすべて README・公式ドキュメント・Issue に記載されている報告値であり、出典を併記しています。導入検討時はご自身のハードウェアで公式のベンチマークプロトコルに沿って計測されることをおすすめします。

colibriとは｜744B〜2.8TのMoEモデルをローカル実行するC言語製推論エンジン

colibri は「Tiny engine, immense model.」を掲げる推論エンジンで、744B〜2.8T パラメータの MoE モデルをコンシューマ向け／混成構成のハードウェアで動かすことを目的としています。中核にあるのは、VRAM・RAM・ストレージを別々のリソースではなく単一の多階層メモリ（AI memory multitiering）として扱うという考え方です。

公式サイトのモットーは「Run open models. Keep your hardware.」で、重みとプロンプトがマシンの外に出ないこと（the model files never leave the machine）がプライバシー面の柱として挙げられています（出典: colibri 公式サイト）。外部 API に出せないデータを扱う前提では、この性質が検討の出発点になります。

リポジトリの基本情報とプロジェクトの健全性

2026年10月時点のリポジトリメタデータは以下のとおりです（出典: gh api /repos/JustVugg/colibri）。

メンテナンス状況の観点では、リポジトリが archived=false / fork=false / disabled=false の健全な状態にあり、作成から 3 ヶ月あまりで最新リリースが 2026-09-24、最終 push が 2026-10-04 と直近である点が確認できます。つまりアーカイブ済みのプロジェクトやフォークではなく、本家が活発に更新されている状態です。ライセンスは Apache-2.0 で、商用利用が可能な一方で特許条項を含みます。

ただしプロジェクト自体は 2026-07-01 作成で歴史が浅く、Open Issues は 94 件あります。採用判断では「活発だが若い」という性質を前提に置く必要があります。

なおフォーク数が 4,330 に達しており、検索結果には同名・類似名のリポジトリが混在します。本家は JustVugg/colibri であり、ドキュメント・リリース・サポートはこのリポジトリを参照してください。

「純C・依存ゼロ」が指す範囲と、Python が必要になる箇所

リポジトリの説明文は「pure C, zero deps, experts streamed from disk」とあり、エンジン本体は単一の C ファイル（c/colibri.c）と小さなヘッダ群で構成されます。BLAS を使わず、ランタイムに Python を必要とせず、GPU も必須ではありません。

初見で誤解しやすいのは、この「zero deps」がエンジン本体に限った話だという点です。README は次のように明記しています。ランチャー coli と API ゲートウェイは Python スクリプトであるため、Python 3 のインストールが必要です（モデル変換も一度だけ Python を使います）。

You only need Python 3 installed: the launcher and the API gateway are Python scripts, while the engine itself is pure C with zero dependencies.

出典: README「Get started」

もうひとつ、設計方針として README の冒頭に置かれているのが「速度に SLA はなく、セマンティクスは厳格に保証する」（no SLA on speed, and a hard guarantee on semantics）という宣言です。既定のポリシーはモデルの精度やルータのセマンティクスを黙って変えず、高速メモリが足りない場合に落ちるのは速度であってモデルの定義ではない、という切り分けになっています。この方針は後述の速度評価にそのまま影響するため、先に押さえておくと読み進めやすくなります。

colibriがローカル実行を成立させる仕組み｜エキスパートのディスクストリーミング

なぜ 372GB のモデルを 16GB の RAM で動かせるのか。ここは colibri の技術的な核であり、理解しておくと「自分のワークロードで速度が出るか」を自分で見積もれるようになります。

744BのうちトークンごとにアクティブなのはわずかというMoEの性質

出発点は MoE のスパース性です。README によれば、744B の MoE モデルがトークンごとに活性化するのは約 40B パラメータで、そのうちトークン間で入れ替わるのは約 11GB 分（ルーテッドエキスパート）だけです。README 内の図のキャプションは「only ~5.4% of parameters are active per token」と表現しています（出典: README「Why it works」）。

つまりモデル全体を常に高速メモリに置いておく必要はなく、トークンごとに必要になる分だけが間に合えばよいという構造になっています。

dense部はRAM常駐、ルーテッドエキスパート19,456個はディスクに置く

GLM-5.2 の場合、README は配置の内訳を次のように説明しています。

• dense 部（attention・shared experts・embeddings、約 17B パラメータ）は int4 で RAM 常駐（約 9.9GB）
• ルーテッドエキスパート 19,456 個（75 MoE 層 × 256 ＋ MTP ヘッド、int4 で各約 19MB）はディスク上（約 370GB）に置き、オンデマンドでストリーミングする。層ごとの LRU キャッシュ、学習されたピン留め hot-store、オプションの VRAM 層を併用する

（出典: README「Why it works」）

README はこの設計を「モデルは高速メモリに収まる必要はなく、配置される必要がある」（the model doesn't need to fit in fast memory — it needs to be placed）と要約しています。

比喩として挙げられているのが「重みの JIT」（a JIT, but for weights）です。コンパイラの JIT がプログラム全体をコンパイルせずホットパスだけを実行時にコンパイルするのと同じように、パラメータを「保持しておく常駐状態」ではなく「ルータが必要だと証明した瞬間にステージングするデータ」として扱います。この発想が成り立つ根拠として README が挙げるのは、ルーティングには計測可能な構造があり、構造はキャッシュできるという点です。

なお、日本語の二次情報には「エキスパート 21,504 個」と記載しているものもありますが、README の現行記述は 19,456 個です。本記事では公式ドキュメントの値を採用しています。

ディスクを2度待たないための4つの仕掛け

ディスクに置いた以上、キャッシュミスのコストは高くつきます。README の「Never wait for the disk twice」節では、ミスを避ける・隠すための実装が整理されています。

1. 1 回の pread で読む: 1 エキスパートが持つ 3 つの行列を隣接配置して、1 回の読み取りで取得する
2. 境界付き非同期 I/O プール（PIPE=1、既定）: 常駐しているエキスパートの計算中に、不足しているエキスパートをロードする
3. バッチ和集合（batch-union）: バッチ内の複数位置が同じエキスパートを要求しても、一意なエキスパートは 1 回だけ読む
4. ルータ先読みスレッド（PILOT=1）: 次の層のエキスパートをプリフェッチする。README はその根拠として、ルーティングが「71.6% predictable one layer ahead」（1 層先について 71.6% 予測可能）であると計測値を示しています

（出典: README「Never wait for the disk twice」）

GPU 側では常駐パイプライン（COLI_CUDA_PIPE=2）が残差ストリームをデバイス上に保持し、CPU のエキスパートループを中断させない構成が用意されています。Apple Silicon 向けの Metal バックエンドは experimental、Vulkan バックエンドは Vulkan 1.2 ドライバを持つ GPU（Mesa/RADV 経由の AMD カードを含む）に対応しています。

使うほど速くなる学習キャッシュと、公式が明記している留保

階層の中間にあるのが学習キャッシュです。エンジンは自分のワークロードがどのエキスパートにルーティングされたかを .coli_usage に毎ターン記録し、ホットなものを自動でピン留めします。README は「使うほど文字どおり速くなる」（literally gets faster the more you use it）と説明しています（出典: README「Multiple SSDs」節）。

ここで重要なのは、README 自身が留保を明記していることです。ルーティング履歴は過学習しうるし、先読みはホストによっては損になる。だからこそどちらも「約束」ではなく「計測可能なポリシー」として残してある、という書き方になっています。最適化は制御されたエンドツーエンドの A/B が示すまで仮説として扱う、という運営方針が README に明文化されており、未解決仮説の一覧も掲載されています。

ルーティングに構造があることの裏付けとして公開されているのがエキスパートアトラスです。GLM-5.2 の 13,260 個の特性付けされたエキスパートを Python・SQL・数学・詩・法律・中国語など 10 領域に配置したもので、各エキスパートの位置は学習済み埋め込みではなく計測されたルーティング親和性に基づいています（出典: Issue #175）。

colibriをローカル実行する手順｜入手からモデル配置・起動まで

README は必要なものを「プログラム（数百 KB）」と「モデル（372GB）」の 2 つに整理しています。手順そのものは短いので、ここではコマンドとどこで詰まるかを併せて確認していきます。プラットフォーム別の詳細は Quick Start ガイドにまとまっています。

エンジンを入手する（prebuiltリリース／ソースビルド）

prebuilt リリースは Linux・macOS・Windows 向けに提供されており、コンパイラは不要です。Releases から自分のプラットフォーム向けのアーカイブを取得して展開します。

mkdir colibri && tar xzf colibri-v1.8.0-linux-x86_64.tar.gz -C colibri && cd colibri
python3 coli info                         # engine ready ✓

出典: README「1. Get colibri」

展開するとエンジン（colibri、Windows では colibri.exe）、coli ランチャー、Python ヘルパーが入っています。coli は自分の隣にあるエンジンを自動で見つけるため、リネームや設定は不要です。

ソースからビルドする場合は gcc（または clang）と OpenMP が必要です。

git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh                                # checks gcc/OpenMP, builds, self-tests

出典: README「1. Get colibri」

なお README は「.exe はエンジン本体でランチャーではない」点にも注意を促しています。単体で起動するとモデルがないため即終了します。

モデルコンテナを用意する（gs64とint8 MTPヘッドという2つの必須条件）

事前変換済みの GLM-5.2 int4 コンテナが Hugging Face で公開されています。約 372GB あるため、容量に余裕のある、できれば高速なディスクに置きます（出典: mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp）。

GLM-5.3 は同じエンジンでロードできる同系列モデルで、専用コンテナが約 419GB です。ただし MTP ヘッドを含まないため、投機デコードは off のままになります（出典: Justvugg/GLM-5.3-colibri-int4-g64）。

ここが初見で最もつまずきやすい箇所です。README は 2 つの条件を強い調子で指定しています。

• group-scaled（gs64）コンテナを使うこと。古い per-row int4 ミラー（mateogrgic/…・jlnsrk/…）は品質が約 9pp 悪く、think モードのループや生成が終わらない不具合（Issue #455）の原因でした。ただし README は「gs64 は反復や EOS 枯渇に対する一般的なガードではない」とも明記しています
• MTP ヘッドは int8 であること（int4 ではドラフト受理率が 0%、Issue #8）。README にはファイルサイズで確認する方法が記載されています

（出典: README「2. Get the model」）

FP8 のソースから自前で変換する選択肢もあります。README によれば、756GB を一度にディスクに置く必要がない再開可能な単一コマンドです。

./coli convert --model /nvme/glm52_i4     # download+convert shard by shard (python, one-time)

出典: README「2. Get the model」

動かす前に確認する（plan / doctor / tune）

起動系のコマンド群は以下のとおりです。

COLI_MODEL=/nvme/glm52_i4 ./coli chat     # RAM budget, cache and MTP auto-detected
COLI_MODEL=/nvme/glm52_i4 ./coli plan     # inspect the planned VRAM/RAM/disk placement
COLI_MODEL=/nvme/glm52_i4 ./coli doctor   # read-only readiness check
COLI_MODEL=/nvme/glm52_i4 ./coli doctor --deep  # strict tensors/shards/index/mirror preflight
COLI_MODEL=/nvme/glm52_i4 ./coli tune     # measure and save this machine's fastest safe execution profile
./coli web  --model /nvme/glm52_i4        # API + dashboard, and opens a browser
./coli serve --model /nvme/glm52_i4       # API + dashboard, no browser (headless)

出典: README「3. Run it」

採用判断の観点で押さえておきたいのは plan と doctor です。plan は VRAM・RAM・ディスクへの配置計画を事前に確認するコマンド、doctor は読み取り専用の準備チェックで、doctor --deep はテンソル・シャード・インデックス・ミラーの厳格なプリフライトを行います。tune は「そのマシンで最も速い安全な実行プロファイル」を計測して保存します。

372GB のダウンロードを決める前に、配置計画と準備状態を読み取り専用で確認できるという点は、必要スペックの見積もりに直結します。

複数SSDに分散して読む（COLI_MODEL_MIRRORと部分ミラー）

decode がディスク律速になっている場合、2 台目の SSD にモデルのコピーを置き、両方のドライブから読ませる構成が用意されています。

COLI_MODEL_MIRROR=/second/glm52_i4 python3 ./coli chat --model /fast/glm52_i4

出典: README「Multiple SSDs」

エンジンは起動時にドライブを計測して読み取り分割の重みを決めます。README は「独立したドライブは帯域のヘッドルームを提供するが、トークンレートの倍率を保証するものではない」とし、共有コントローラ・キャッシュヒット・計算側がゲインを制限しうる点を明記しています。測定されたゲインと限界、単一ドライブとの比較はマルチディスクガイドにまとまっています。

運用上の性質として README が挙げているのは次の点です。

• ミラーは起動時に検証される（ファイルごとのサイズと safetensors ヘッダがプライマリとバイト一致している必要がある）。不一致・欠落したファイルはプライマリから読むため、部分ミラーでも問題ない
• ミラーは書き込まれない。.coli_usage や .coli_kv などのサイドカーはプライマリに残る
• ミラー側の読み取りエラーはプライマリにフォールバックする（警告 1 回、クラッシュなし）。実行中に 2 台目を外してもサーバは落ちずに劣化する

2 台目がモデル全体を収容できない場合は、学習済みのエキスパート履歴から部分ミラーをランク付けできます。代表的なプロンプトを何度か流して .coli_usage にワークロードを反映させてから、計画・配置・検証を行います。

./c/coli mirror plan  --model /fast/glm52_i4 --mirror /second/glm52_i4 \
  --budget-gib 200 --reserve-gib 20
./c/coli mirror stage --model /fast/glm52_i4 --mirror /second/glm52_i4 \
  --budget-gib 200 --reserve-gib 20
./c/coli mirror verify --model /fast/glm52_i4 --mirror /second/glm52_i4

出典: README「Multiple SSDs」

ステージングはプライマリのモデルを変更せず、一時ファイル経由でコピーし、指定した空き容量の予備を確保し、各シャードを SHA-256 で検証し、既存のミラーシャードを削除せず、選択したミラーの準備が完了してから receipt をアトミックに公開する、という手順が README に記載されています。

colibriの必要スペック｜モデル別のRAM・ストレージとGPUの要否

ここがタイトル副題「必要スペック」への回答です。README は対応モデルごとの要件を表で公開しており、注記として「これらは大きく異なり、2 つを並べて読んだ人が要件が矛盾していると誤解したことがある（Issue #191）。矛盾ではなく別のモデルである」と書かれています。自分の用途に対応するモデルの行だけを見るのが正しい読み方です。

モデル別に見る必要ディスク容量とRAM

出典: README「What each one needs」

GLM-5.2 を動かす場合、RAM の要求は最低 16GB・快適 24GB と現実的な一方、壁になるのはディスク 372GB という構図になります。逆に Kimi K3（2.8T パラメータ）は RAM 32GB 以上で足りますが、スナップショットが約 1.6TB です。

GPUは必須ではない — 速度を決めるのはディスク帯域

README は表の直前に「None of them needs a GPU.」と明記し、直後に次のように補足しています。

A GPU only ever makes it faster. Speed is set by your disk, because the experts are streamed from it — expect a fraction of a token per second on a slow drive and a few per second on a fast one with the cache warm.

出典: README「What each one needs」

GPU は速度を上げるだけで、速度を決めるのはディスクである、という説明です。遅いドライブなら 1 秒あたり 1 トークン未満、速いドライブでキャッシュが温まっていれば数トークン毎秒を見込むべき、という整理です。必要スペックを見積もるときは VRAM よりディスク容量と帯域を先に確認する順序になります。

DeepSeek V4 Flash については、README が --ram を最重要のノブとして挙げています。43×256 のルーテッドエキスパートがディスク上で約 137GiB を占め、1 トークンが 301 個に触れるため、エキスパートキャッシュのヒット率が tok/s を決めるという説明です。--ram は速度のみを変え、出力は変えません。

Inkling は int4 エキスパートと bf16 dense 重み（常駐 49.4GB）を持つため RAM 要求が高いモデルですが、inkling.md に dense を 15.3GB まで落とす一発ツールが用意され、975B を 25GB のマシンで動かせるとされています（トレードオフも併記されています）。

20GB級から始める選択肢（Qwen3.6 / OLMoE）

372GB の壁を越えずに colibri の挙動を確認したい場合、Qwen3.6-35B-A3B（約 20GB・RAM 24GB）や OLMoE（約 7GB・RAM 8GB）から入る選択肢があります。sibling engine 構成のおかげで、モデルを変えてもコマンドラインは同じです。ランチャーが config.json を読んでバイナリとチャットテンプレートを選ぶため、小さいモデルで操作とダッシュボードを確認してから大きいモデルに進む、という進め方が取れます。

ハードウェア構成別の実測速度｜colibriのdecodeスループットをどう読むか

タイトル副題のもう一方、「速度」への回答です。README の「What it achieves」節には、ハードウェアクラス別の decode 速度が報告値として並んでいます。計測の詳細はベンチマーク結果（docs/benchmarks.md）に、再現のためのプロトコルはベンチマーク計測プロトコル（docs/benchmarking.md）にまとまっています。

ハードウェアクラス別のdecode速度（4つのデータポイント）

出典: README「What it achieves」

読み方として押さえておきたいのは、同じエンジン・同じ int4 コンテナを使っており、ハードウェアが変えるのは「エキスパートがどこに住むか」だけという点です。6 枚の RTX 5090 で全エキスパートを常駐させれば decode パスからディスクが抜けて 5.8〜6.8 tok/s になり、25GB のラップトップではすべてがディスクからストリーミングされて 0.05〜0.1 tok/s になる。遅くはなっても「正しい」出力が出る、という設計です。

ストレージ設定で変わる幅（デュアルSSD・O_DIRECT）とドライブ依存性

ストレージ側のチューニングで変わる幅も数値で公開されています。

• デュアル NVMe: 独立した 2 台で decode +37.5%。3 台目（低速）は重み付きストライピング後は中立（出典: docs/multidisk.md）
• O_DIRECT（DIRECT=1）: Blackwell/Windows 機で PIPE=1 と併用して decode +34%、GB10 の iobench で 4.25→9.69 GB/s

ただし README は O_DIRECT について「ドライブ依存であり、QLC・DRAM レス・仮想化ディスクでは中立〜マイナスになりうる。まず試して、自分のハードウェアが報いる設定を残せ」と明記しています。既定のまま最速になるとは限らず、自分の環境で A/B を取る前提の設定という扱いです。チューニングの考え方はチューニングガイド（docs/tuning.md）にまとまっています。

GPUを足したときの効き方と、投機デコードが損になるケース

GPU の効き方が最も明確に数値化されているのは Qwen3.6 です。CUDA VRAM エキスパート層を使うと 8GB のカード 2 枚で 1.44 → 10.05 tok/s（7.0×）になり、しかも出力は CPU 経路とビット一致すると報告されています（出典: README「What each one needs」）。エキスパート集合が VRAM に収まる規模のモデルでは、GPU の追加が素直に効くことになります。

一方で投機デコードは常に得ではない点も明記されています。ネイティブ MTP は条件が揃えば 2.2〜2.8 tokens/forward を稼げますが、エキスパートヒット率 85% 付近では 32% の損失が計測されています。README は「投機は元を取らなければならない」という方針を掲げ、検証コストを回収できないときに無効化できるよう DRAFT=0 を用意しています。

DeepSeek V4 では投機が既定で off です。README によれば、DSpark の markov drafter と MTP は実装・検証済みですが、実測で受理が 15 回に 1 回／24 回に 10 回に留まり、リカレント注意状態のリプレイコストがドラフトの節約を上回りました（14 トークンの回答に 495 秒）。そのため V4_DRAFT と V4_MTP は既定 0 に設定されています。

この速度域で成立する用途・成立しない用途

以上を踏まえると、GLM-5.2 クラスの実測値は 0.05〜6.8 tok/s のレンジに収まります。この速度域の評価軸は次のように整理できます。

• 成立しやすい用途: バッチ処理、非同期ジョブ、夜間実行、分類・判定・フィールド抽出、出力品質の検証、推論システムの研究
• 成立しにくい用途: 対話レイテンシ要求のあるチャット UI、同時リクエストを捌く本番 API、ストリーミング表示で待たせられないユースケース

README が「速度に SLA はない」と明言していることも、この評価軸と整合します。colibri は速度を保証するのではなく、遅くても正しく動く範囲を広げることに賭けているエンジンだと読むのが実態に近いでしょう。

なお、後述の Brio モードは「生成せずに選択肢の確率を読む」仕組みで、分類・判定系の用途ではこの速度制約を大きく緩める選択肢になります。

対応モデル9ファミリーとBrioモード｜colibriが備える実装機能

機能を網羅するよりも、採用判断に影響する部分に絞って整理します。

9ファミリーをsibling engineとして抱える構成

colibri は 9 つのモデルファミリーに対応しています（出典: README「Other supported models」）。

各ファミリーはsibling engineとして扱われます。1 ファミリー 1 C ファイルで独自のアーキテクチャを持ちつつ、coli chat / coli serve / coli web という同じフロントエンドを共有します。ランチャーがモデルの config.json からバイナリを選ぶため、使う側のコマンドラインは変わりません。

Kimi K3・DeepSeek V4 Flash・DeepSeek V4.1 Flash・Qwen3.8-Flash-Next は変換不要で、公式チェックポイントのネイティブ量子化形式（MXFP4・fp4・block-FP8）をそのままストリームします。README は「tiering アルゴリズムはモデル非依存であり、ルーテッドエキスパートを持つ MoE なら同じ方法でステージングできる」とし、候補として MiniMax を挙げています。

Brioモード — 生成せずに選択肢の確率を読む

採用判断の観点で見逃せないのが Brio モードです。README の整理は「人がモデルに求めるものの多くは段落ではなく選択である（どのキュー・どの判定・フィールドが取り得る 4 つの値のどれか）」というものです。Brio モードは選択肢をエンジンに渡し、生成する代わりに各選択肢の確率を読みます。

• completion_tokens は 0
• 回答がリストの外に出ることはない
• 各回答にエントロピーが付くため、「モデルが確信していない」を閾値として扱える
• 9 ファミリーすべてで動き、同じサーバ上でリクエスト単位のオプトイン。利用しない側のチャットはバイト単位で同一

# in the TUI: the same model, told to stop writing
./coli chat --model /nvme/qwen36_i4_gs64
> /brio merge | request changes | close
> 340 lines, 8 files, no tests. CI is green but nothing covers that path.

# from anywhere: one JSON request on the running server
curl -s http://127.0.0.1:8000/v1/brio -H 'Content-Type: application/json' -d '{
  "model": "qwen36",
  "state": "340 lines, 8 files, no tests. CI is green but nothing covers that path.",
  "question": "What should the reviewer do?",
  "options": ["merge", "request changes", "close"]}'

出典: README「Brio mode: ask a closed question」

questions は 1 度読んだ 1 つの文書に対して複数の問いを投げる形式、schema は JSON オブジェクトを 1 フィールドずつ構成上妥当な形で埋める形式です。README によれば、同じ CPU マシンで同じ答えを生成する場合との比較で、Qwen3.6 において 4 フィールドのスキーマで 2.4×、1 文書に対する 4 問で 5.7× という計測結果が報告されています。モードの仕様・リクエストとレスポンスの形・効かないケースは Brio モード（docs/brio.md）にまとまっています。

分類・審査・フィールド抽出といった業務用途では、生成速度の制約を回避できるという点が、この機能の意思決定上の価値です。「数 tok/s では使えない」と結論づける前に、用途が生成なのか選択なのかを分けて考える余地があります。

圧縮KV状態と会話のウォーム再開

MLA 注意機構は圧縮された KV 状態を保持します。README によれば 1 トークンあたり 576 floats（非圧縮の 32,768 に対して 57× 小）で、.coli_kv に永続化されるため再起動を跨いで会話をウォームで再開できます。再 prefill はゼロで、中断なしのセッションとバイト一致すると報告されています。

正しさの担保についても記述があります。forward パスは transformers のオラクルに対して検証され、teacher-forcing で典型的に 30-32/32。残る 2 箇所は浮動小数の near-tie でツールチェーン依存とされています。DSA スパース注意は full-key 選択を強制して dense 注意を厳密に再現することで検証されています。

Brainページとプロファイリングで挙動を可視化する

./coli web で起動するダッシュボードは v1.12.0 で再設計され、チャット用ドック・Brio ページ・Brain ページ・Profiling ページを備えます。

• Brain ページ: 計測済みのエキスパートアトラスを皮質状に描画します。Live routing に切り替えると実行中のモデルに対応し、1 エキスパート 1 セル、色がストレージ階層を表し、ターン中にルーティングされたエキスパートが白く光る表示になります
• Profiling ページ: ターンごとのフェーズ別時間と直近 30 ターンの推移を表示します。README の例（Qwen3.6・CPU マシン）では、36 prompt／55 generated トークンで wall time 19.0 秒、2.9 tok/s、ディスクサービス 11.4 秒が計算とオーバーラップしたと記録されています

OpenAI 互換 API とダッシュボードの仕様は docs/api.mdにまとまっています。自分のワークロードでどこに時間が使われているかを数値で確認できるため、チューニングの投資判断に使えます。

あわせてローカルクラスタモードも用意されています。コーディネータがトークン生成・ルーティング・KV 状態をローカルに保持し、ディスク背景のエキスパートワーカーが別マシンでルーテッド FFN を実行する構成です。層ごとのルーテッドバッチ和集合を 1 本の永続 TCP リクエストで送るため、エキスパートごとのラウンドトリップは発生しません。ワーカーを設定しなければトランスポートは無効で、既存の単一マシン経路は変わりません。

類似OSSとの違い｜KTransformers・llama.cpp・airllmとの棲み分け

採用判断で最後に残るのが「KTransformers や llama.cpp ではなく colibri を選ぶ理由があるのか」という問いです。

エキスパートをRAMに置くか、ディスクに置くか（KTransformersとの違い）

最も近い比較対象は KTransformers です。清華大学 MADSys Lab 由来の CPU/GPU ハイブリッド推論エンジンで、MLA 注意機構・KV キャッシュ・shared experts を GPU に置き、256 個のルーテッドエキスパートを CPU（システム RAM）にオフロードすることで、デスクトップ級の GPU とシステム RAM で 671B クラスの MoE を動かします（出典: KTransformers SOSP25 論文）。

両者の決定的な差はエキスパートの一次保管場所です。

エキスパート群が RAM に収まる規模であれば、RAM から読む KTransformers のほうが速度面で有利です。収まらない規模、あるいは RAM を増設できない環境では、ディスクを一次保管場所に据える colibri が選択肢になります。KTransformers 側の詳細は巨大MoEローカル推論にKTransformersが選ばれる理由で整理しています。

エキスパートの置き場所と対応モデルの幅（llama.cppとの違い）

ローカル LLM 推論のデファクトである llama.cpp との差は、エキスパートをどこに置くかと階層管理の有無に表れます。

llama.cpp 側も、-ot / tensor override を使ってルーテッドエキスパートの FFN テンソルを CPU 側に配置する運用が可能です（出典: Hugging Face Blog「Performant local mixture-of-experts CPU i…）。「エキスパートだけを GPU から外す」という発想自体は llama.cpp でも実現できます。

colibri が異なるのは、ディスクを一次保管場所に据えたうえで、エキスパート単位の階層管理を組み込んでいる点です。層ごとの LRU キャッシュ、.coli_usage に基づく学習済み hot-store、ルータの 1 層先読み（README の計測で 1 層先について 71.6% 予測可能）という組み合わせで、ディスクからのステージングを前提にした階層を構成します。これに相当する機構は、llama.cpp リポジトリの公開ドキュメントおよび上記ブログの範囲では確認できませんでした。

対応モデルの範囲も異なります。llama.cpp は README に dense・MoE・マルチモーダルを含む多数のモデルファミリーを対応として列挙しており、GGUF 形式の量子化モデル・各言語バインディング・GUI を含むエコシステムが形成されています（出典: llama.cpp README）。一方 colibri が対象とするのは、ルーテッドエキスパートを持つ MoE の 9 ファミリーです。GGUF エコシステムの量子化モデルをそのまま使いたい場合や、dense モデルも含めて扱いたい場合は llama.cpp 側が適しています。

層単位ストリーミング・対象モデルを絞った実装との違い

小 VRAM 環境向けのアプローチとしては airllm があります。4GB の GPU で 70B クラスを動かす層単位ストリーミングの手法で、dense モデルの層を順次ロードする汎用的な仕組みです。MoE のルーティング構造は利用しません。colibri はルーティング熱の計測・学習（.coli_usage）を前提にした MoE 特化設計であり、ルーティングに構造があることを前提にできるかどうかが分岐点になります。airllm の仕組みと制約はairllmとは｜4GB GPUで70B LLMを動かす仕組みと制約で整理しています。

対象範囲の広さという軸では、対象モデルを絞った実装との対比も参考になります。ds4（DwarfStar 4）は DeepSeek V4 Flash / PRO と GLM 5.2 という少数モデルに絞った特化実装で、量子化戦略やバックエンドをその対象に合わせて設計しています。一方 colibri は 9 ファミリーをモデル非依存の共通 tiering アルゴリズムで扱い、DeepSeek V4 Flash / V4.1 Flash はそのうちの 2 つという位置づけです。colibri のリファレンスモデルである GLM-5.2 は ds4 の対象にも含まれるため、両者は対象が重なりつつ、絞り込みの設計思想が異なる関係にあります。この違いはDeepSeek V4ローカル推論にDwarfStar 4（ds4）が選ばれる理由と読み比べると見えやすくなります。

どれを選ぶかの目安

公開情報から整理すると、選定の目安は次のようになります。

• エキスパート群が RAM に収まる規模 → KTransformers（RAM から読むほうが速い）
• RAM に収まらない／ディスクに置くしかない規模（372GB〜1.6TB） → colibri
• 対応モデルの幅と周辺ツールを優先 → llama.cpp
• dense モデルを小 VRAM で動かしたい → airllm
• 対象モデルを絞った特化実装が欲しい → ds4 のような実装

colibriの導入判断チェックポイント｜向くケースと見送る条件

colibriが向くケース

• 重みとプロンプトをマシンの外に出せない: 公式サイトが掲げる「the model files never leave the machine」という性質が要件に直結する場合
• フロンティア級モデルの出力品質を自前で検証したい: forward パスが transformers オラクルに対して検証され、既定ポリシーが精度やルータのセマンティクスを黙って変えない設計であること
• バッチ・非同期ジョブで数 tok/s を許容できる: 夜間実行・キュー処理など、レイテンシ要求が緩い用途
• 分類・審査・フィールド抽出を高速に回したい: Brio モードで生成をスキップできる用途
• 推論システムの研究プラットフォームとして改造したい: 1 ファミリー 1 C ファイルという読める規模の実装と、未解決仮説の一覧が公開されていること

別の手段を検討したほうがよいケース

• 対話レイテンシ要求がある: GLM-5.2 クラスでは 0.05〜6.8 tok/s のレンジ。チャット UI の応答性には届きません
• 高スループットの本番 API が必要: 同時リクエストを捌く用途は想定の外側です
• 372GB〜1.6TB のディスク容量または帯域を確保できない: 速度を決めるのはディスクである、という前提が崩れます
• GGUF エコシステムの量子化モデルをそのまま使いたい: 専用コンテナまたは公式チェックポイントが前提のため、llama.cpp 側が適しています

ローカル LLM の導入そのものを検討している段階であれば、判断軸の整理から入るほうが近道です。ローカルLLMの導入判断については別記事でまとめています。

採用前に把握しておくリスクと未確定領域

公開情報から読み取れる留意点を、そのまま列挙します。

• プロジェクトは若い: 2026-07-01 作成、Open Issues 94 件（2026年10月時点）。最新リリース v1.12.1（2026-09-24）、最終 push 2026-10-04 と開発は活発ですが、API・環境変数は変化しうる段階です
• 速度の保証がない: README が「no SLA on speed」と明言しています。SLA を要求するワークロードには向きません
• 実験的／未確定の領域が明示されている: Metal バックエンドは experimental、COLI_EXACT_VERIFY=1 は量子化 KV キャッシュでは厳密性を提供しない、near-tie のフリップは「議論されたが GLM-5.2 の n=64 ではまだ捕捉されていない」といった記述があります
• 既定のまま最速になるとは限らない: O_DIRECT・デュアル SSD・投機デコードはいずれも「自分のハードウェアで計測して得かを判断する」設定です。環境変数の一覧は環境変数リファレンス（docs/ENVIRONMENT.md）にあります
• 同名フォークが多数ある: フォーク数 4,330。本家 JustVugg/colibri を参照してください
• ライセンスは Apache-2.0: 商用利用は可能ですが特許条項を含みます。実運用前に自組織のライセンス方針と突き合わせてください

colibri はベンチマーク計測プロトコルを整備し、ハードウェア・コミット・モデル／コンテナ・正確なコマンド・プロンプト・キャッシュ状態・スループット・TTFT・エキスパートヒット率・読み取りバイト数・品質チェックの記録を求めています。ネガティブな結果も公開することが推奨されており、自組織のハードウェアで A/B を取って判断する進め方に適した運営になっています。本記事では計測を実施していないため、実際の採用判断は公式プロトコルに沿った自組織での計測結果に基づいて行うことをおすすめします。

まとめ｜手元のハードウェアでフロンティア級MoEを試す選択肢としてのcolibri

本記事では、JustVugg/colibri について公式 README・公式サイト・docs/ 配下のドキュメント・GitHub Issues とリポジトリメタデータの範囲で、以下を整理しました。

• 仕組み: 744B の MoE はトークンごとに約 5.4% のパラメータしか使わないという性質を利用し、dense 部（約 9.9GB）を RAM に常駐させ、ルーテッドエキスパート 19,456 個（約 370GB）をディスクからストリーミングする。隣接 pread・非同期 I/O・batch-union・1 層先読み（71.6% 予測可能）でディスク待ちを隠す
• 必要スペック: GPU はどのモデルでも必須ではなく、速度を決めるのはディスク。GLM-5.2 は RAM 最低 16GB・ディスク約 372GB、Kimi K3 は約 1.6TB。Qwen3.6（約 20GB）や OLMoE（約 7GB）から始める経路もある
• 速度: 0.05〜6.8 tok/s のレンジ。対話用途には向かないが、バッチ処理・分類・品質検証には成立する。Brio モードは生成をスキップして選択肢の確率を読むため、分類系の用途で速度制約を緩められる
• 類似 OSS との選定軸: エキスパートの一次保管場所が RAM（KTransformers）かディスク（colibri）か。エキスパートを CPU に置けるだけ（llama.cpp）か、ディスク起点の階層管理まで組み込んでいる（colibri）か

次に読むべき公式ドキュメントとしては、導入手順なら Quick Start ガイド、速度の見積もりならベンチマーク結果、設定の詰めならチューニングガイドという順序が取りやすいでしょう。

繰り返しになりますが、本記事は公開ドキュメントに基づく整理であり、インストール・実行・ベンチマーク取得は行っていません。372GB のダウンロードを決める前に coli plan と coli doctor で配置計画と準備状態を確認し、そのうえで公式プロトコルに沿った計測で判断されることをおすすめします。

関連情報

自社ハードウェアでの LLM 推論基盤の構築や、技術選定を含む PoC をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。