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

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

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](/glossary/llm)をセットアップし、単一ノードでのプロキシ動作を確認することから始めてください。ノードが増加するにつれ、Tailscaleのルーティング最適化やPrometheusによるメトリクス収集範囲の設計が重要な課題となります。

Llama 3.3 405B をローカルで動かすためのハードウェア構成と最適化