クラウド Mac mini クラスター実測：Thunderbolt 5 連携した 80 Gbps の体験とは？

Thunderbolt 5 クラスター連携とは何か？

ZilCloud の申し込みページで追加オプションを選ぶと、「Thunderbolt 5 クラスターサービス」という項目があります。日額わずか $1.4、月額 $8.9。初めて見たときの正直な感想は「これ、何に使うの？」でした。

要点を先に言うと、Thunderbolt 5（以下 TB5）は Mac mini M4 に搭載された新しい相互接続規格で、理論帯域は 120 Gbps（PCIe チャネル）、デバイス間リンクでは 80 Gbps の双方向帯域——つまり約 10 GB/s のデータ転送が可能です。従来の TB4（40 Gbps）の倍です。ZilCloud の TB5 クラスターサービスは、クラウド上の Mac mini M4 ノードを物理 TB5 ケーブルで直結し、OS から見て透過的な超高速ローカルネットワークを構成するものです。

エンジニアリングの観点では、単に2台を LAN ケーブルでつないだわけではありません。TB5 クラスターは PCIe チャネルを通るため、イーサネットより遥かに低レイテンシで、Remote Direct Memory Access（RDMA）を介したクロスマシン・メモリマッピングも理論上可能です。ビルドファーム、AI 推論クラスター、動画レンダリングプールなど、マシン間で大量の状態を共有するワークロードにとって、これは単なる「速いネットワーク」以上の意味を持ちます。

環境構築：開通と TB5 インターフェースの認識

コンソールで2台のノードを選択し TB5 クラスター追加オプションを有効にすると、およそ3分で両マシンのステータスが「稼働中」に変わります。SSH で1台目にログインし、次のコマンドで TB5 ポートの認識状況を確認します。

system_profiler SPThunderboltDataType

出力では2つの TB5 ポートが認識され、いずれも「Connected」状態で対向デバイス（もう1台の Mac mini）が検出されます。macOS のネットワーク設定では、TB5 リンクが自動的に「Thunderbolt Bridge」インターフェースとして現れ、169.254.x.x のリンクローカルアドレスが割り当てられるため、手動設定なしでも通信できます。

静的 IP の手動設定（推奨）

APIPA アドレスでも動作しますが、後続のコンパイルジョブやスクリプトの安定性のため、静的 IP の設定を推奨します。両マシンの Thunderbolt Bridge インターフェースに次を設定します。

# ノード A
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.1 255.255.255.0

# ノード B
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.2 255.255.255.0

設定後、ping -c 4 192.168.100.2 で疎通を確認すると、平均 RTT はおよそ 0.08 ms。同一データセンター内の10ギガビットイーサネットよりも低い数値です。

帯域実測：iperf3 と fio のデータ

基礎ネットワークが整ったら、まず iperf3 で帯域を測ります。

iperf3 TCP テスト

# ノード B をサーバーに
iperf3 -s

# ノード A をクライアントに、8並列ストリーム
iperf3 -c 192.168.100.2 -P 8 -t 30

計測結果は次のとおりです。

UDP 単一ストリームは 79.1 Gbps まで到達し、80 Gbps の公称値にほぼ一致します。TCP マルチストリーム（8並列）では 72.4 Gbps——実ワークロードとしては十分すぎる帯域です。双方向同時転送では各方向 60 Gbps 超が安定し、合計 120 Gbps を超えます。これは TB5 の PCIe チャネル理論値と整合します。

fio によるクロスマシンファイル転送テスト

iperf3 はネットワーク層のみの計測です。実運用ではファイルシステムレベルの転送速度が重要になるため、macOS 標準の SMB 共有と NFS マウントでそれぞれテストしました。

NFS v4.2 のシーケンシャル読み取りは 6.2 GB/s に達し、単一 NVMe SSD のローカル読み取りを上回ります。M4 のメモリ帯域が高く、TB5 経由で対向マシンのユニファイドメモリバッファに直接アクセスできるため、リモート読み取りがローカル SSD より速くなるケースがあるのです。

Xcode 分散コンパイル実測

iOS / macOS 開発者にとって最も関心が高いのは、TB5 クラスターで Xcode のビルドがどれだけ速くなるか、という点でしょう。

テストには実在する iOS プロジェクト（約180モジュールの大規模 SwiftUI アプリ、クリーンビルドで約14分）を使用しました。distcc と pump モード でコンパイルタスクを2台に分散します。

# distcc のインストール
brew install distcc

# ノード B をコンパイルデーモンサーバーに
distccd --allow 192.168.100.0/24 --log-stderr --verbose

# ノード A で distcc ホストリストを設定
export DISTCC_HOSTS="192.168.100.2/8 localhost/4"

# pump モードでビルド開始
pump xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release build

クリーンビルドは14分から 8分47秒 へ短縮され、約 1.62倍 の高速化。理想的な2倍には届きませんが、Swift フロントエンドコンパイル（意味解析フェーズ）は現時点で分散非対応で、全体の約35%をローカル処理が占めるためです。純粋な C/C++/Obj-C コードに限れば分散効果はより顕著で、実測 1.9倍 まで達しました。

インクリメンタルビルドの効果はさらに大きく、中間成果物のクロスマシン共有が TB5 の転送速度を活かせるため、約3分46秒から 1分38秒 へ。日常の開発サイクルで節約できる時間は無視できません。

大規模言語モデル推論：llama.cpp マルチマシン

コンパイル以外にも、TB5 クラスターは AI 推論に大きな価値を持ちます。M4 の Apple Neural Engine は 38 TOPS の算力を持ち、単機推論には十分ですが、複数リクエストを同時処理する AI サーバー用途では2台クラスターがスループットを大幅に引き上げます。

llama.cpp の RPC バックエンド（build 0.1.x 以降でマルチマシン負荷分散をサポート）を使い、Llama 3.1 8B（Q4_K_M 量子化）の推論スループットを計測しました。

# ノード B で llama-rpc-server を起動
./llama-rpc-server --host 192.168.100.2 --port 50052 -ngl 99

# ノード A をマスターに、2台を指定
./llama-cli \
  --rpc 192.168.100.2:50052 \
  -m ./Llama-3.1-8B-Q4_K_M.gguf \
  -ngl 99 --parallel 8 -p "Write a detailed technical analysis of..."

8B モデルの推論スループットは単機 48.2 tok/s から2台クラスター 89.7 tok/s へ——ほぼ線形に近いスケールです。TB5 の超低レイテンシにより、マシン間の KV-Cache 同期オーバーヘッドは無視できるレベルです。これは従来のイーサネット構成では実現困難な特性です。

2台クラスターがもう一つの扉を開くのは、単機では不可能なタスクの実行です。Llama 3.1 70B Q4 量子化版は約40 GB のメモリを必要とし、16 GB の単機ではロードできません。TB5 RPC でモデルレイヤーを2台に分散配置すれば、GPU なしでもローカル推論が可能になり、スループットは約22 tok/s——実用の域に入ります。

レイテンシと安定性：72時間ストレステスト

ベンチマーク数値が良いだけでは不十分です。クラウドノードの安定性こそ、本番投入の判断基準になります。2台に対して 72時間 の連続高負荷テストを実施し、Xcode インクリメンタルビルドループ（5分間隔）+ llama.cpp 並列推論 + クロスマシン大容量ファイル循環読み書きを同時実行しました。

72時間の間、TB5 リンクは ゼロ断、両ノードとも SSH 到達性100%。帯域ピーク時に M4 のサーマルスロットリングでわずかに低下する場面はありましたが、平均 69.8 Gbps を維持し、ワークロードへの影響は無視できるレベルです。CI/CD ノードや常駐 AI サービスへの本番投入に耐えうる安定性と言えます。

適用シーンのまとめ

以上のテスト結果から、TB5 クラスター連携が特に効果を発揮するユースケースを整理します。

1. 分散 iOS / macOS コンパイル（Xcode + distcc）：クリーンビルド約1.6倍、インクリメンタルビルド2倍以上の高速化。CI パイプラインのビルド時間を大幅に圧縮できます。

2. 大規模モデルのローカル推論（llama.cpp RPC）：単機メモリ制限を突破し、2台合計32 GBのユニファイドメモリで70B級量子化モデルを実行可能。並列推論スループットはほぼ線形にスケールします。

3. 大規模動画レンダリング / メディア処理：TB5 経由 NFS のクロスマシン読み取りは 6.2 GB/s に達し、通常の LAN を大きく上回ります。Final Cut Pro のクラスターレンダリングと組み合わせれば、レンダリング時間の半減も現実的です。

4. リアルタイムデータパイプライン：80 Gbps 帯域 + 0.08 ms レイテンシによりクロスマシンメモリマッピングが可能になり、低レイテンシノード間通信が必要なリアルタイムデータ処理（クオンツ取引バックテスト、ストリーム集約など）に適しています。

避けて通れない問い：なぜ従来のクラウドサーバーでクラスターを組まないのか？

ここまで読むと、「同じクラスター要件なら AWS やさくらのクラウドの GPU インスタンスでもできるのでは？」と思うかもしれません。主流クラウドの HPC インスタンスは100 Gbps イーサネットや専用クラスターネットワークを謳っており、パラメータだけ見れば悪くないように聞こえます。

しかし、いくつか見落とされがちな本質的な違いがあります。

まず macOS 環境の代替不可能性です。Xcode ビルド、iOS コード署名、TestFlight 配信、Apple Neural Engine 推論——これらは Linux や Windows インスタンスでは法的・技術的に実行できません。AWS の Graviton は ARM ですが macOS は動きません。AWS EC2 Mac インスタンスは Apple 専用ハードウェアですが、最低料金は約 $1.08/時間、最短24時間契約（約 $25.9/日）で、ZilCloud の $20.9/日より高く、TB5 クラスター連携もできません。

次に 共有とオーバーセル（超売り）の問題です。従来クラウドの多くは仮想化によるオーバーセルが前提です。100 vCPU インスタンスの裏側に60物理コアしかない、といった構成は珍しくありません。「10 Gbps 帯域」がバースト値で保証帯域ではない、隣接テナントの noisy neighbor がピーク時のコンパイル速度や推論レイテンシに直撃する——ZilCloud は物理マシン専有で、仮想化層もオーバーセルもありません。10コア CPU はそのまま10コアです。

第三に ネットワーク相互接続の品質差です。AWS の Cluster Placement Group は低レイテンシを提供しますが、ノード間 RTT は0.5〜2 ms 程度。AWS の HPC インスタンス（EFA ネットワーク）でもレイテンシはマイクロ秒オーダーですが、TB5 の 0.08 ms RTT は物理層直結で、中間のネットワークスタックルーティングがありません。KV-Cache 分片推論のようにプロセス間で大量の状態を共有するワークロードでは、この差は決定的です。

もちろん従来クラウドにも強みがあります。秒単位課金の柔軟性、GPU モデルの豊富な選択肢、成熟したオートスケーリング——純粋な Linux GPU 学習が主目的なら、そちらが適しています。しかし macOS ネイティブ環境 + 高性能クラスター相互接続 + 日単位の柔軟レンタル という組み合わせを求めるなら、現時点で ZilCloud の TB5 クラスターサービスだけが実現できます。最低 $20.9/日に TB5 追加 $1.4/日、合計 $22.3/日で80 Gbps クラスターに参加できる Mac mini M4 物理ノードが手に入ります。2週間の短期プロジェクトなら2台借りて終わったら即停止——アイドルリソースへの追加コストは発生しません。