Ollama 自宅クラスタ構築｜Mac + Linux で分散推論

Llama 3.1 405Bのような超巨大なパラメータを持つモデルをローカル環境で動かそうとした際、192GBのユニファイドメモリを搭載したMac Studio M2 Ultraであっても、推論速度の低下やメモリ不足という物理的な限界に直面します。手元にRTX 4090を積んだLinuxサーバーや、余っているMac miniが存在する場合、それらを単体のマシンとしてではなく、一つの巨大な計算リソースとして統合する「分散推論クラスタ」の構築が極めて有効な手段となります。

個々のデバイスを独立して運用するのではなく、LiteLLMによるロードバランシング、OpenWebUIによる統一インターフェース、そしてTailscaleを用いたセキュアなネットワーク構築を組み合わせることで、物理的に異なるOS・ハードウェア構成のPC群を、あたかも一つの巨大な推論エンジンであるかのように機能させることが可能です。MacとLinuxが混在するホームラボ環境における、Ollamaを用いたスケーラブルなAI推論基盤の確立。その具体的なネットワーク設計から、Grafanaを用いたリソース監視手法に至るまでの全工程を紐解いていきます。

分散推論クラスタのアーキテクチャ：LiteLLMによるロードバランシング

Ollamaを用いた分散推論クラスタの本質は、単一の巨大なモデルを分割して計算すること（Model Parallelism）ではなく、複数の独立したOllamaインスタンスに対して、リクエストを効率的に振り分ける「タスク並列化」と「モデル・ローテーション」にある。2026年現在のLLM運用において、すべての推論を単一のGPUに集約することは、VRAM容量の限界と熱設計電力（TDP）の制約から極めて非効率である。ここで中核を担うのが、OpenAI API互換のプロキシサーバーとして機能するLiteLLMである。

クラスタ構成は、フロントエンドのOpenWebUI、ロードバランサーのLiteFM（LiteLLM）、そしてバックエンドの推論ノード群（Mac StudioおよびLinux Server）という3層構造で構築する。LiteLLMは、各Ollamaノードの稼働状況をヘルスチェックし、特定のモデル（例：Llama-3.1-70B）がロードされているノードへリクエストをルーティングする役割を持つ。例えば、Mac Studio M4 Ultra（192GB Unified Memory）には超巨大なパラメータを持つモデルを配置し、RTX 5090搭載のLinuxノードには高速応答が求められるLlama-3.1-8Bなどの軽量モデルを配置するといった、メモリ容量と推論速度に基づいた重み付け（Weight-based Routing）が可能になる。

ネットワーク層においては、Tailscaleを用いたメッシュVPNを利用することで、物理的に異なる拠点（自宅の書斎と別室のサーバーラックなど）にあるノードを、同一のL3サブネット内に仮想的に統合する。これにより、各ノードは固定のプライベートIP（例：100.64.0.x）を持ち、複雑なポートフォワーディングなしで相互通信が可能となる。

推論ノードの選定基準：Apple SiliconとNVIDIA Blackwell世代の共存

分散クラスタの性能を決定づけるのは、異種混合（Heterogeneous）な計算リソースの組み合わせである。Mac Studioに代表されるApple Silicon環境は、その「ユニファレンスメモリ（Unified Memory）」構造により、単体で100GBを超える巨大なコンテキストウィンドウを持つモデルのロードが可能という唯一無二の利点がある。一方で、NVIDIA RTX 5090（Blackwellアーキテクチャ）を搭載したLinuxノードは、FP8/FP4といった低精度演算における圧倒的なスループット（Tokens per second）を誇る。

ノード選定の判断軸は、「モデルのパラメータ数」と「要求される推論レイテンシ」の2点に集約される。70B以上のパラメータを持つモデルを運用する場合、VRAM容量がボトルネックとなるため、Mac Studio M4 Ultraのような大容量メモリ搭載機をメインノードとして選定すべきである。対して、エージェント的な自律動作やチャット応答など、低レイテンシ（< 50ms/token）が求められる用途には、RTX 5090のTensorコアを活用したLinuxノードが最適である。

具体的に構築すべきノード構成例を以下に示す。

• High-Capacity Node (Mac Studio)

  • CPU/GPU: Apple M4 Ultra (128-core GPU)
  • Memory: 192GB Unified Memory
  • Target Model: Llama-3.1-70B, Command R+ (104B)
  • Role: 長文コンテキスト処理、複雑な推論タスク

• High-Throughput Node (Linux Workstation)

  • GPU: NVIDIA GeForce RTX 5090 (32GB GDDR7)
  • CPU: AMD Ryzen 9 9950X (16C/32T)
  • RAM: 128GB DDR5-6400
  • Target Model: Llama-3.1-8B, Mistral NeMo (12B)
  • Role: 高速チャット応答、マルチエージェントの並列実行

このように、メモリ帯域幅（GB/s）と演算性能（TFLOPS）の特性が異なるデバイスを、LiteLLMのmodel_listで適切に定義することで、リソースの無駄を排除した高効率なクラスタリングが実現できる。

ネットワーク・ボトルネックと通信レイテンシの課題

分散推論における最大の技術的障壁は、ノード間通信に伴うレイテンシ（Latency）の増大である。LiteLLMがリクエストをルーティングする際、バックエンドのOllamaノードへのHTTP/REST通信が発生する。このとき、ネットワーク帯域幅やパケットロス率が、推論結果の「文字が流れてくる速度」に直接影響を与える。特に、Tailscaleを用いたリモート接続を行う場合、DERP（Detour Relay for Packets）リレーサーバーを経由してしまうと、RTT（Round Trip Time）が数百msec単位で悪化し、推論体験を著しく損なう原因となる。

これを回避するためには、可能な限り「Direct Connection」を実現するためのネットワーク設計が必要である。自宅内のLAN構成においては、以下の3点を徹底すべきである。

1. 10GbE SFP+ ネットワークの導入: Mac StudioとLinuxサーバー間は、標準的な1GbEではなく、10GbE（SFP+またはRJ45）で接続すること。これにより、大規模なモデルファイルの転送や、コンテキスト情報の同期に伴うオーバーヘッドを最小化できる。
2. Tailscaleの定常的なDirect Connection確認: tailscale statusコマンドを用い、各ノードが「active; direct」状態であることを確認する。もし「relay」と表示されている場合は、UDPポート41641の開放（UPnPまたは静的マッピング）を行い、通信経路を最適化しなければならない。
3. MTU（Maximum Transmission Unit）の整合性: 仮想ネットワーク層でのパケット断片化を防ぐため、各ノードのMTUサイズを適切に設定する。特にLinux側のDockerコンテナとmacOSホスト間での不一致は、通信エラーやスループット低下の隠れた要因となる。

また、LiteLLMの設定におけるtimeout値の設定も重要である。巨大なモデル（例：100B超）の初動（Time to First Token: TTFT）は、モデルのロード状況によって数十秒かかることがあるため、プロキシ層でのタイムアウト設定をデフォルトの60sから、ワークロードに合わせて120s〜300sへと拡張しておく必要がある。

可視化と運用管理：Prometheus/Grafanaによるメトリクス監視

大規模な分散クラスタを安定稼働させるためには、各ノードの「健康状態」をリアルタイムで把握するオブザーバビリティ（可観測性）が不可欠である。単にOllamaが動いているかどうかを確認するだけでなく、VRAMの使用率、GPU温度、および推論のスループット（Tokens per second）を定量的に監視しなければならない。

監視スタックには、PrometheusとGrafanaを用いた標準的な構成を採用する。各Ollamaノードのメトリクス収集には、NVIDIA GPU用のdcgm-exporterおよびApple Siliconの電力・温度情報を取得可能なカスタムエージェントを使用する。これらのデータをPrometheusがスクレイピングし、Grafanaのダッシュボード上で統合的に可視化する。

監視すべき重要指標（KPI）は以下の通りである。

• GPU/Unified Memory Utilization (%): VRAMの枯渇は、Ollamaのモデルロード失敗に直結するため、閾値（例：90%）を超えた場合にアラートを発報する設定とする。
• Tokens Per Second (TPS): 各モデルの推論速度を監視し、ネットワーク遅延やノードの負荷増大によるパフォーマンス低下を検知する。
• Request Latency (TTFT & TPOT): Time to First Token（最初のトークンが出るまでの時間）と Time Per Output Token（各トークンの生成間隔）を分離して計測し、ユーザー体験の劣化を定量化する。
• Node Temperature (°C): 特にLinuxノードのRTX 5090において、サーマルスロットリングが発生していないかを確認する。

さらに、運用コストの最適化という観点からは、電力消費量（W）のモニタリングも極めて重要である。24時間稼働するクラスタでは、各ノードのアイドル時および高負荷時の消費電力を合算することで、月間の電気代コストを算出できる。例えば、Mac Studioが30W、Linuxサーバーが350Wで稼働している場合、その差は月間で数百円〜千円単位のコスト差となって現れる。このような数値をGrafamente上で可視化し、必要に応じて「低負荷時はLinuxノードをスリープさせる」といった、電力効率に基づいた自動運用（Auto-scaling）への拡張も視野に入れるべきである。

分散推論クラスタ構築におけるハードウェア・ソフトウェア構成の徹底比較

Ollamaを用いた分散推論クラスタを構築する際、最大の課題は「異種混合（Heterogeneous）環境」をいかに最適化するかという点にあります。Apple Silicon特有の広帯域なユニファレンスメモリを活用したMac Studioと、圧倒的なFP8演算性能を誇るNVIDIA RTX 50シリーズ搭載のLinuxノードでは、計算リソースの性質が根本的に異なります。

単一の強力なGPUを用意するのと、複数の安価な、あるいは既存のデバイスを組み合わせるのとでは、コスト対効果（TCO）だけでなく、推論のスループットやレイテンシに劇的な差が生じます。ここでは、クラスタ設計の意思決定に不可欠な、ハードウェアスペック、ソフトウェアスタック、およびネットワーク構成の比較検証を行います。

1. 計算ノード：主要ハードウェア・プラットフォーム比較

クラスタの「脳」となる計算ノードの選定は、扱うモデルのパラメータ数（7B〜405B）に直結します。Mac Studioはメモリ容量（VRAM容量相当）の確保において圧倒的な優位性を持ち、一方のLinuxノードは単一トークン生成速度（Tokens per second）において高いパフォーマンスを発揮します。

Mac Studioを利用する最大のメリットは、Apple Siliconのユニファレンスメモリ構造にあります。32GBや48GBといった制限があるGPUワークステーションに対し、192GBもの広大な領域を推論用VRAMとして割り当てられるため、DeepSeek-V3のような巨大なパラメータを持つモデルの量子化版（Q4_K_M等）を単一ノードで動作させることが可能です。対して、LinuxノードはRTX 5090等の高速なメモリ帯域を活用し、軽量なLlama 3.1 (8B) クラスの爆速推論（100+ tokens/s）を担う役割として最適です。

2. ソフトウェア・オーケストレーション層の機能比較

分散クラスタにおいて、個別のOllamaインスタンスを単なる「点の集合」から「一つの知能」へと昇華させるのが、LiteLLMやOpenWebUIといったミドルウェア層の役割です。これらのコンポーネントは、リクエストのロードバランシングやプロトコルの変換を担います。

LiteLLMは、このクラスタ構築における「司令塔」です。複数のOllamaエンドポイントを一つのOpenAI互換APIに集約し、特定のノードが過負荷になった際のフォールバック設定や、モデルごとのルーティングルールを定義できます。これにTailscaleを組み合わせることで、自宅内のLANだけでなく、外出先のノートPCからもセキュアにクラスタへアクセス可能な「どこでもAI」環境が実現します。

3. モデル規模別：推論パフォーマンスとメモリ要件のトレードオフ

どのモデルをどのノードに割り当てるべきかは、VRAM容量と計算能力のバランスで決まります。量子化ビット数（Quantization）によってメモリ消費量は劇的に変化するため、各ノードのスペックに基づいた適切な配置計画が求められます。

ここで重要なのは、Linuxノードにおける「VRAM溢れ」のリスクです。RTX 5090（32GB）に70Bクラスを載せようとすると、コンテキスト長（Context Window）を拡大した際にメモリ不足でクラッシュします。そのため、LiteLLMのルーティング機能を用い、「70B以上のリクエストはMac Studioへ、8B以下の軽量な指示はLinuxノードへ」というロジックを実装することが、クラスタ全体の可用性を高める鍵となります。

4. ネットワーク・トポロジー：接続方式によるレイテンシ比較

分散推論において、ノード間の通信遅延（Latency）は「思考の停止」に直結します。特に、推論結果の一部を分割して受け取るようなマルチノード推論を検討する場合、ネットワーク帯域の確保は計算リソースの増強と同等に重要です。

自宅ラボ（Home Lab）環境では、基本的には10GbEのスイッチングハブを用いたローカル通信を主軸とし、外部からの管理やモバイルデバイスへの配信にはTailscaleを利用するハイブリッド構成が、セキュリティとパフォーマンスの両立において最適解となります。

5. オブザーバビリティ：クラスタ・モニタリング・マトリクス

複数のノードが稼働する環境では、「どのノードが熱暴走しかけているか」「どのモデルがメモリを圧迫しているか」をリアルタイムに把握する必要があります。Grafanaを用いた可視化は、運用フェーズにおける必須要件です。

GrafanaダッシュボードにPrometheus経由でこれらのデータを集約することで、例えば「Linuxノードの温度が85℃を超えた際に、LiteLLMのリクエストを自動的にMac Studioへ迂回させる」といった、高度な自律型クラスタ運用への道が開かれます。これは単なる監視を超えた、インテリジェントな負荷分散管理（Intelligent Load Balancing）の第一歩となります。

よくある質問

Q1. クラスタを24時間稼働させた際の電気代の目安はどのくらいですか？

Mac Studio（M2 Ultra）などの省電力なノードと、RTX 4090を搭載したLinuxサーバーを併用する場合、アイドル時の消費電力は50W〜100W程度に収まります。しかし、推論負荷が高い状態が続く場合、サーバー単体で最大450Wを超えることもあります。電気料金単価を31円/kWhと仮定すると、月間の増加費用は概ね3,000円から8,000円程度を見込んでおく必要があります。

Q2. Llama-3 70Bクラスのモデルを快適に動かすための最低予算は？

Llama-3 70BのQ4_K_M量子化モデルを動作させるには、少なくとも48GB以上のVRAMまたはユニファイドメモリが必要です。中古のMac Studio（64GBモデル）や、RTX 3090（24GB）を2枚搭載した自作Linux機を構築する場合、最低でも25万円〜35万円程度の初期投資が必要になります。既存のPC資産を活用できれば、このコストは大幅に削減可能です。

Q3. 分散推論におけるマスターノードのOSは何が最適ですか？

LiteLLMやOpenWebUIを動かすオーケストレーション層には、Ubuntu 24.04 LTSなどのLinuxディストリビューションを推奨します。Dockerコンテナの管理が容易であり、Tailscaleによるネットワーク設定も安定しているためです。一方で、推論を実行するワーカーノードとしては、大容量メモリを活かせるmacOS（Mac Studio）と、CUDA環境が構築可能なLinux（Ubuntu/NVIDIA搭載機）を混在させるのが理想的です。

Q4. ロードバランサーとしてLiteLLMを使うメリットは何ですか？

Nginxなどの一般的なリバースプロキシと比較して、LiteLLMは「OpenAI互換API」への変換機能と、複数のOllamaエンドポイントに対する高度なルーティング機能を備えています。例えば、特定のモデルが応答不可になった際に、別のノードにあるバックアップのモデルへ自動的にフォールバックさせる設定が可能です。これにより、マルチノード環境における可用性を劇的に向上させられます。

Q5. Tailscaleを使用した場合、推論速度に遅延（レイテンシ）は発生しますか？

WireGuardプロトコルを採用しているTailscaleのオーバーヘッドは極めて小さいため、通常のテキスト生成において体感できるほどの遅延は発生しません。ただし、モデルの重みデータや巨大なKVキャッシュをノード間で転送する場合、ネットワーク帯域がボトルネックとなります。1GbEの有線LAN環境を構築し、MTUサイズを最適化しておくことで、スループットの低下を防ぐことが重要です。

Q6. OpenWebUIから複数の異なるハードウェア（MacとLinux）を同時に参照できますか？

はい、可能です。LiteLLMをプロキシとして配置し、そこにMac Studio上のOllama（ポート11434）とLinuxサーバー上のOllamaのIPアドレスを登録します。OpenWebUI側からは単一のAPIエンドポイントのみを見れば良いため、ユーザーは背後にあるハードウェア構成を意識することなく、複数のモデルをシームレスに切り替えて利用できます。

Q7. 推論中に特定のノードがダウンしたことをどのように検知すべきですか？

Prometheusを使用してOllamaのメトリクス（ポート11434/metrics）を定期的にスクレイピングし、Grafanaで可視化する構成を推奨します。LinuxノードのGPU温度が85℃を超えた場合や、プロセスが停止した際に、Alertmanagerを通じてSlackやDiscordへ通知を送る仕組みを構築することで、クラスタの健全性をリアルタイムに監視できます。

Q8. 分散推論において、ネットワーク帯域がボトルネックになるケースは？

大規模なコンテキスト（128kトークン以上など）を扱う際、ノード間でプロンプトの内容や中間状態をやり取りする通信量が増大します。Wi-Fi接続のノードが含まれている場合、TTFT（Time To First Token：最初のトークンが出るまでの時間）が著しく悪化する可能性があります。安定した推論を実現するためには、各ノード間を10GbEなどの高速なイーサネットで接続することが強く推奨されます。

Q9. 今後、Raspberry Piのような低電力デバイスをクラスタに追加することは可能ですか？

可能です。Phi-3やGemma 2Bといった軽量なSLM（Small Language Models）であれば、Raspberry Pi 5（8GBモデル）でも十分な推論性能を発揮できます。LiteLLMのルーティングルールを活用し、「軽量なタスクはRaspberry Piへ、複雑な指示はMac Studioへ」という具合に、タスクの難易度に応じてノードを使い分けるエッジコンピューティング的な運用が可能です。

Q10. 次世代のGPU（RTX 50シリーズ等）へのアップグレードは検討すべきですか？

非常に価値があります。次世代GPUではVRAM容量の拡大やメモリ帯域の向上が期待されており、より大きなコンテキストウィンドウでの推論が可能になります。特にLLMの進化に伴い、128k〜1Mトークンの長文処理ニーズが高まっているため、24GB以上のVRAMを搭載したハイエンドなLinuxノードをクラスタに組み込むことは、将来的な拡張性において極めて重要です。

まとめ

本記事では、Mac Studioの強力なUnified MemoryとLinuxサーバーのGPUリソースを統合し、Ollamaを用いた分散推論クラスタを構築する手法を解説しました。複数の計算資源を単一の仮想的な推論基盤として機能させるための要点は以下の通りです。

• Ollamaを各ノードに展開し、MacとLinuxの異なるアーキテクチャにおけるGPU/メモリリソースを統合管理する
• LiteLLMをプロキシ兼ロードバランサーとして配置し、複数のAPIエンドポイントへのリクエスト分散を実現する
• TailscaleによるメッシュVPN構築により、物理的なネットワーク境界を超えたセキュアなノード間通信を確立する
• OpenWebUIをフロントエンドに据えることで、バックエンドの複雑な分散構成を意識しない一貫したユーザー体験を提供する
• PrometheusとGrafanaを用いたモニタリング環境を整備し、各ノードのVRAM使用率や推論レイテンシをリアルタイムで可視化する
• Dockerを用いたコンテナベースのデプロイを採用することで、ノードの追加や構成変更に対する高い拡張性を確保する

まずは手元のLinuxマシン、あるいはMacにOllamaとLiteLLMをセットアップし、単一ノードでのプロキシ動作を確認することから始めてください。ノードが増加するにつれ、Tailscaleのルーティング最適化やPrometheusによるメトリクス収集範囲の設計が重要な課題となります。