distributed-llama 評価: 家庭内の複数ノードで量子化 Llama を分割推論する
Distributed LLM inference. Connect home devices into a powerful cluster to accelerate LLM inference. More devices means faster inference.
ひと目でわかる
- これは何？
- b4rtaz/distributed-llama は、家庭内の複数デバイスをイーサネットで接続し、テンソル並列で LLM 推論を分担させる C++ 実装である。ノード数は 2 の冪に縛られ、KV ヘッド数が上限になる。その制約込みで、誰に向くツールなのかを整理する。
- 誰に向いている？
- 複数台のマシンが余っていて、Llama 3.3 70B のような単機では載らないモデルを Q40 量子化で動かしたい読者には検討の価値がある。逆に、単機で完結する VRAM があるなら distributed-llama を選ぶ理由は薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 72 日前です。
- 何の言語で書かれている？
- 主に C++ です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
単機のメモリ壁を、家庭内の複数台で分割する
解こうとしている問題ははっきりしている。70B 級のモデルを Q40 量子化しても 40GB 前後の重みが必要で、1 台の家庭用マシンには収まらないことが多い。distributed-llama は重みとニューラルネットワークの状態を複数ノードに分割し、各ノードが自分の担当スライスだけを処理する。README のアーキテクチャ図では、ルータまたはスイッチの下に ROOT 1 台と WORKER 群が並ぶ構成が示されている。対象読者は、GPU を増設する代わりに手元のミニ PC や Mac を寄せ集めたい個人や小規模チームである。README には 4 台の Mac Mini M4 Pro 24GB RAM で Llama 3.3 70B を動かしたという 2025 年 1 月のディスカッションへのリンクがある。
ROOT が重みを配り、WORKER はモデルを知らない
構成要素は 2 種類しかない。ROOT ノードはモデルと重みをロードし、それをワーカーへ転送し、ニューラルネットワークの状態を同期させる。ROOT 自身もワーカーとして自分のスライスを処理する。WORKER ノードは自分のスライスを計算するだけで、モデルに関する設定を必要としない。この非対称性は運用に直結する。モデルのパスやトークナイザを指定するのは ROOT 側だけでよく、ワーカー側で必要なのはバインド先の host と port、そしてスレッド数だ。同期はイーサネット越しの高スループット通信で行われ、テンソル並列として分割される。RAM 使用量は全ノードに分散されるが、README は ROOT がワーカーより少し多くの RAM を必要とすると明記している。ノードを増やすほど 1 台あたりの負担は下がる。
launch.py で ROOT を立て、dllama worker で参加する
もっとも短い導線はルートノード側のワンコマンド起動である。Python 3 と C++ コンパイラが必要で、コマンドはモデルとトークナイザのダウンロードまで行う。例えば Llama 3.1 8B Instruct Q40 (6.32 GB) なら python launch.py llama3_1_8b_instruct_q40、Llama 3.3 70B Instruct Q40 (40 GB) なら python launch.py llama3_3_70b_instruct_q40 を実行する。Qwen 3 は 0.6B から 30B A3B まで、DeepSeek R1 Distill Llama 8B も同じ形式のコマンドで並んでいる。手元の Hugging Face 形式モデルを使いたい場合は docs/HOW_TO_CONVERT_HF_MODEL.md の手順で変換する。実行モードは dllama inference、dllama chat、dllama worker、dllama-api の 4 つ。ワーカーは dllama worker --host 127.0.0.1 --port 9999 --nthreads 4 のように起動し、ROOT 側は dllama inference --model <path> --tokenizer <path> --buffer-float-type q80 --workers "10.0.0.1:9999 10.0.0.2:9999" のように worker のアドレスを空白区切りで渡す。--max-seq-len 4096 のように指定すると最大系列長を絞って RAM を節約できる。--nthreads は CPU コア数を超えない範囲で設定する、と README が注意している。
2 の冪と KV ヘッド数という 2 段の天井
採用判断で最初に効くのはここだ。README の Known Limitations は、ノード数が 1, 2, 4 ... 2^n に限られると述べている。3 台や 5 台では構成できない。加えて最大ノード数はモデルの KV ヘッド数に等しい。つまりヘッド数の少ないモデルでは、物理的に何台あってもそれ以上分割できない。量子化の組み合わせも狭い。q40 モデルには q80 の buffer-float-type、f32 モデルには f32 の buffer-float-type という 2 通りしかサポートされない。buffer-float-type は同期時の浮動小数点精度を決める引数なので、ここを外すと動かない。もう一点、通信がイーサネット前提である以上、Wi-Fi しか引けない部屋のマシンを混ぜると同期がボトルネックになりやすい。README は Wi-Fi での性能を保証していない。
llama.cpp との違いは、分割を前提にしているかどうか
比較対象として自然なのは llama.cpp である。どちらも量子化された Llama 系モデルを C++ で動かし、CPU 向けに最適化する。違いは分割の扱いにある。llama.cpp は 1 プロセス内で完結することを基本線とし、複数マシンにまたがる推論は主要な設計目標ではない。distributed-llama は逆で、ROOT と WORKER という役割分担、ワーカーへの重み転送、イーサネット越しの同期を最初から前提に据えている。この違いは、単機に収まるモデルを動かす場面では llama.cpp のほうが構成が単純になるという形で現れる。逆に、単機に収まらないモデルを手持ちの複数台で動かしたい場合、llama.cpp の標準的な使い方では届かない。どちらが優れているかではなく、重みを分割したいかどうかで選ぶ。
MIT ライセンスと、追従コストの見積もり
ライセンスは MIT で、商用利用を含めて比較的制約が少ない。ただしライセンスはツール自体に適用されるもので、ダウンロードするモデル重みのライセンスは別に確認が必要だ。launch.py はモデルとトークナイザを自動で取得するため、取得先のモデルカードの条件を自分で読むことになる。ここは法的助言ではないので、条件の解釈は各自で行ってほしい。保守の観点では、リリースが活発である。v0.16.5 が 2026 年 2 月、v0.16.4 が 2026 年 1 月、v0.16.3 が 2025 年 10 月と、ここ 1 年で複数回の更新が確認できる。2025 年 2 月には基盤コードの大規模リファクタがマージされ、2025 年 3 月に Vulkan サポートが実験的に入り、9 月には Qwen 3 MoE が CPU と Vulkan で扱えるようになった。追従コストは、対応モデルの追加に合わせて変換済みモデルを作り直す手間として現れる。
GPU を使う場合と CPU だけで組む場合
README は Linux、macOS、Windows に対応し、ARM と x86_64 AVX2 の CPU 向けに最適化されていると述べている。GPU を使う手順は docs/HOW_TO_RUN_GPU.md に分離されており、Vulkan 対応は実験的とされている点に注意したい。Raspberry Pi 向けの手順も別ドキュメントとして用意されている。つまり CPU クラスタ、GPU 混在、シングルボードコンピュータという 3 つの入口が文書として分かれている。どの経路を選ぶかで必要なドライバとビルド手順が変わるので、最初に自分のハードウェアがどの文書に対応するかを決めてから進めるほうがよい。CPU のみの構成は追加ドライバが不要な分だけ検証は楽だが、その分スループットはノード間通信とスレッド数に強く依存する。
編集部の結論
複数台のマシンが余っていて、Llama 3.3 70B のような単機では載らないモデルを Q40 量子化で動かしたい読者には検討の価値がある。逆に、単機で完結する VRAM があるなら distributed-llama を選ぶ理由は薄い。導入前に確認すべきは 3 点で、第一に自分のノード数が 2 の冪に乗るか、第二にモデルの KV ヘッド数がノード数以上あるか、第三に README が示す q40 と q80 の組み合わせ以外を使う予定がないかである。この 3 つが揃わない場合、dllama worker は起動しても意味のある分担にならない。
コミュニティノート