EP.14 では 1 台の Mac でどこまでできるかを見ました。今回はその上限を超える話です。複数台の Mac を束ねて、1 台には載らないモデルを動かす。2026 年 8 月の Mac Studio 発表で Apple が公式にこの構成をサポートしたことで、選択肢として現実味が出てきました。
執筆時点（2026 年 9 月）の情報です。ハードウェア仕様と公式のクラスタ機能については Apple の発表（2026-08-25）を出典としています。OSS 側のツールは更新が速いので、導入時に各プロジェクトの最新版を確認してください。
1. なぜ束ねたいのか
理由はひとつです。1 台のメモリに載らないモデルを動かしたい。EP.14 で見たとおり、ローカル LLM で動かせるモデルの上限は搭載メモリで決まります。 のおかげで Mac は 1 台でもかなり大きなモデルを載せられますが、それでも上限はある。
「速くしたいから束ねる」ではない、という点を最初に強調しておきます。ここを誤解したまま機材を揃えると、台数を増やしたのに体感が変わらないという結果になります。詳しくは 4 章で分解します。
2. Apple 公式のクラスタ機能
2026 年 8 月 25 日発表の新しい Mac Studio で、Apple は複数台のクラスタ化を公式機能として打ち出しました。発表文の要点はこうです。
- Thunderbolt 5 と （Remote Direct Memory Access）の内蔵サポートで複数の Mac Studio をクラスタ化できる
- これによりシステムをまたいだ広大な共有メモリプールが構成され、現在入手できる最大級の モデルを読み込める
- 4 台構成のクラスタは、単体比で最大 3 倍の AI 推論性能
| M5 Max | M5 Ultra | |
|---|---|---|
| CPU | 18 コア | 最大 36 コア |
| GPU | 最大 40 コア | 最大 80 コア |
| ユニファイドメモリ | 最大 128GB | 最大 512GB |
| メモリ帯域 | — | 1.2TB/s（従来比 50% 増） |
| 価格（米国） | $2,499 〜 | $5,499 〜 |
注目すべきは 1.2TB/s です。EP.14 で見たとおり、ローカル LLM の生成速度はほぼ帯域で決まります。従来の M3 Ultra が 819GB/s だったので、1 台あたりの素の速度がまず上がっている。クラスタの話をする前に、この効果の方が大きい場合があります。
3. 「共有メモリプール」の正しい読み方
ここが誤解の生まれやすいところです。「共有メモリプール」という言葉から、4 台が 1 台の巨大なマシンとして振る舞い、すべてが 4 倍速くなるという絵を想像しがちですが、そうではありません。
実態は、モデルを分割して各マシンに配置し、マシン間で受け渡しながら処理する構成です。得られるのは容量の合算であって、演算の完全な統合ではありません。
| 期待 | 実際 | 理由 |
|---|---|---|
| 4 台なら 4 倍のモデルが載る | おおむね正しい | メモリ容量は合算される |
| 4 台なら生成が 4 倍速い | 誤り | 1 トークンごとにマシン間の往復が挟まる |
| 4 台なら応答が速くなる | 多くの場合むしろ逆 | では通信の待ちが増える |
| 4 台なら同時に多く捌ける | 正しい | スループットは台数で改善しうる |
4 台構成で最大 3 倍という公表値は、台数に対して線形ではないことを同時に示しています（4 台で 4 倍ではない）。そして単一リクエストの応答が 3 倍速くなるという意味でもありません。公表値は正確ですが、期待の方を正しく設定する必要があります。
4. 何が速くなって、何が速くならないか
分散推論で起きていることを、1 トークン生成する流れで追うと理解が早いです。モデルの前半の層を持つマシン → 中間結果を次のマシンへ → 後半の層 → 出力。つまり 1 トークンごとにマシンをまたぐ往復が発生します。
この往復の待ち時間が、分散推論の速度を決める支配要因です。 が重要なのはここで、OS を介さず相手のメモリへ直接読み書きすることで、この待ち時間を桁で削ります。従来のネットワーク通信では台数を増やすほど遅くなることすらあった領域が、RDMA によって「増やせば伸びる」側に変わったのが近年の変化です。
- 速くならないもの: 1 つの質問に対する応答時間（）。往復が挟まるぶん、むしろ悪化しうる
- 速くなるもの: 同時に複数の依頼を捌く能力（）。チームで共有するなら効く
- そもそも可能になるもの: 1 台に載らないサイズのモデルの実行。これが最大の価値
5. 方式の地図
Apple 純正だけが選択肢ではありません。手持ちの機材を束ねたいなら OSS の方が現実的なこともあります。
| 方式 | 何をするか | 必要なもの | 向いている場面 |
|---|---|---|---|
| Apple 純正クラスタ | TB5 + で共有メモリプールを構成 | 新しい Mac Studio、Thunderbolt 5 | 公式サポート。最も素直で運用が楽 |
| で複数機に分割。同一ネットワーク上の機体を自動発見 | OSS。複数の Mac | 手持ちの Mac を寄せ集めて束ねたい | |
| の RPC | モデルの層を別マシンに割り当てて実行 | llama.cpp | Mac と Linux / GPU 機の混在でも動く |
| distributed | MLX 上で分散実行 | MLX、全ノードで同一ランタイム | Apple Silicon で速度を詰めたい |
全ノードで同じランタイムを要求する方式（MLX 系）は、Mac だけで揃えるなら速い一方、別 OS や GPU 機を混ぜられません。llama.cpp の RPC はネットワーク越しのプロトコルで抽象化しているぶん、手元にある雑多な機材を寄せ集める用途では強い。持っている機材で方式が決まる、という側面があります。
6. 構成と費用の現実
夢のある話をした後で恐縮ですが、費用は正直に見ておくべきです。M5 Ultra 構成の Mac Studio は $5,499 から。4 台束ねれば単純計算で $21,996（構成を盛ればさらに上）。
ここで立ち止まって考えるべきは、「1 台の 512GB で足りないのか」という問いです。512GB あれば、現在配布されている大半のオープンウェイトモデルは 1 台に載ります。分散には必ずオーバーヘッドと運用の手間が乗るので、1 台で足りるなら 1 台が正解です。
- まず 1 台の上限を使い切る: メモリ構成を上げる方が、台数を増やすより安く確実なことが多い
- 次に用途を確認する: 容量が足りないのか、同時アクセスを捌きたいのか。前者でないなら分散の効果は限定的
- 最後に方式を選ぶ: 新規調達なら純正、手持ち活用なら OSS、混在環境なら llama.cpp
7. 測って組む：最小の 2 台構成
いきなり 4 台を揃える前に、2 台で挙動を確かめるのが確実です。そして何より先に、単体の基準線を取ること。分散構成の評価は「単体と比べてどうか」でしか下せません。
# 1) 単体の基準線を取る。ここを飛ばすと分散の効果を判定できないollama run gpt-oss:20b --verbose "500字程度で自己紹介してください"# 出力末尾の eval rate（tok/s）を控えておく
# 2) モデルを載せる前に、ノード間の素の性能を測るping -c 20 192.168.1.11 # 往復の待ち時間iperf3 -s # 相手ノードで待ち受けiperf3 -c 192.168.1.11 # こちらから帯域測定
# 分散推論は 1 トークンごとに往復が発生するため、# ここで出た待ち時間がそのまま生成速度の足かせになる疎通と性能が確認できたら、実際に分割してみます。ここでは手持ち機材の混在にも対応できる の RPC 機能を例にします。主ノードがモデルの層を分配し、ワーカーが割り当てられた層を処理する構成です。
# --- ワーカー側（層の一部を担当するマシン）---rpc-server --host 0.0.0.0 --port 50052
# --- 主ノード側 ---llama-cli \ --model ./models/your-model.gguf \ --rpc 192.168.1.11:50052 \ --gpu-layers 999 \ --prompt "分散構成の疎通確認"
# ワーカーが複数ならカンマ区切りで並べる# --rpc 192.168.1.11:50052,192.168.1.12:50052
# 動いたら、単体で測った tok/s と必ず比べる。# 落ちていても異常ではない（容量を得る代わりに速度を払う構成のため）2 台に分けて が単体より落ちても、構成が失敗したわけではありません。 は容量と引き換えに速度を払う仕組みだからです。判断すべきは「そのモデルが単体では動かせたのか」。動かせなかったなら、遅くても分散は成功しています。
8. 運用ノウハウ
- 有線が最低条件: 無線では往復の待ち時間が支配的になり、分散の意味が消える
- ノード間の帯域を先に測る: モデルを載せる前に、素の通信性能を確認しておくと切り分けが楽
- モデルの分割位置は自動任せで始める: 手で最適化するのは、まず動かしてボトルネックを見てから
- 1 台の実測を基準線にする: 分散構成の評価は「単体と比べてどうか」でしか判断できない。先に単体で測る
- 電源と熱: 常時稼働の複数台は消費電力も発熱もまとまった量になる。設置場所を先に決める
- 障害時の縮退: 1 台落ちたら全体が止まる構成になっていないか。止まって困る用途なら単体構成の方が堅い
9. 落とし穴
- 速度目的で束ねる: 最大の誤解。単一リクエストは速くならない。容量と同時処理のための構成
- カタログ値を線形に外挿する: 4 台で最大 3 倍。台数に比例しない
- 無線でつなぐ: 往復の待ちが支配的になり、分散の利点が消える
- 単体の基準線を取らずに評価する: 比較対象がないと「速くなったのか」すら判断できない
- 1 台で足りる用途に導入する: メモリを増やす方が安く、運用も楽
- を変えて比較する: 条件を揃えないと、分散の効果なのか量子化の差なのか分からない
- 可用性を考えない: ノードが 1 台落ちた時の挙動を、本番投入前に必ず試す
10. ふくふくの進め方
「大きなモデルを社内で動かしたい」というご相談では、まず本当に分散が必要かの切り分けから入ります。多くの場合、1 台のメモリ構成を上げるか、そもそもモデルを一段小さくして評価し直す方が、費用も運用負荷も低く収まります。分散が要ると判断できたときに初めて、方式と台数の設計に進みます。
11. ここまでのまとめ
- 束ねる理由は速度ではなく容量。1 台に載らないモデルを載せるための構成
- Apple 公式は Thunderbolt 5 + RDMA で共有メモリプール。4 台で単体比最大 3 倍（線形ではない）
- 単一リクエストの応答は速くならない。マシン間の往復が挟まるため、むしろ悪化しうる
- RDMA が効くのはノード間の待ち時間。ここが分散推論の支配要因
- 選択肢は 純正 / EXO / llama.cpp RPC / MLX distributed。持っている機材で方式が決まる
- まず 1 台の上限を使い切る。メモリ増設の方が安く確実なことが多い
複数台構成は派手に見えますが、実態は「容量の問題を金と手間で解く」構成です。夢のある機能ではあるものの、導入判断は地味な問いから始まります。「1 台では本当に足りないのか」。ここに自信を持って答えられるようになってから機材を揃えると、無駄がありません。続編では、実際に 2 台構成を組んで単体と比較した測定、ノード障害時の挙動、混在環境での構成例などを、読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。