Thunderbolt 5 クラスター実測：複数台 Mac mini のネットワーク化でどれだけ速くなる？

単体で足りるのに、なぜ TB5 並列の話をするのか

多くのチームが最初に借りるクラウド Mac 1 台で、日常の iOS ビルドはすでにカバーできている。 M4・16 GB メモリならフル Archive も 3〜4 分程度。ボトルネックは単体 CPU より並列度に寄りやすい—— App target が 6 つ、Extension が 3 つ、Widget が 2 つあるのに CI スクリプトは 1 台で直列待ち； あるいは monorepo の Swift Package 依存が巨大で clean build が 15 分を超え、 各 Runner が数十 GB の DerivedData とソーススナップショットを同期しなければならない、といった場面だ。

よくある対処は「クラウド Mac をもう数台借りて、ジョブを分ける」だ。論理としては正しい。 しかし各マシンが独立した 1 Gbps 公網ポートだけでビルドキャッシュをやり取りすると、 40 GB のワークスペース同期に 6〜8 分かかり、並列化の利益を食いつぶす。 Thunderbolt 5 並列が解くのは同一ラック内マシン間のデータプレーンだ。 PixVPS は同一ノードの複数 Mac mini を TB5 物理ケーブルで接続し、公称 80 Gbps の帯域を確保する。 コンパイルファーム内のノードがアーティファクトを同期したりタスクを配分したりするとき、公網出口を奪わない。

先に誤解を解いておく。TB5 は 1 台の CPU コア数を増やすものではなく、3 台の M4 を「30 コア 1 台」に合成するものでもない。 加速するのはマルチマシン協調時のデータ転送とスケジューリング効率だ。 痛みが「1 台のコンパイルが遅い」なら TB5 追加の効果は限定的。 「マシン間のキャッシュコピーが遅い」「夜間バッチの総所要時間が下がらない」なら、TB5 が対症療法になる。

80 Gbps 物理接続 vs 1 Gbps 公網：何が違うのか

各 PixVPS Mac mini には独立した公網 IPv4 と 1 Gbps ポートがあり、SSH・VNC・TestFlight アップロードなど 「外向き」トラフィックに向く。一方、マシン A が 30 GB の DerivedData をマシン B に送って増分ビルドさせる場合、 公網経由だとデータが一度ラック外に出て戻る。理論上限は約 125 MB/s だが、TCP ウィンドウとディスク書き込みの影響で 実測は 108〜112 MB/s に安定し、30 GB 転送に約 4 分 30 秒かかった。

TB5 並列はラック内専用データチャネルを張る。システム情報では相互接続ポートが Thunderbolt 5 ブリッジネットワーク（bridge0 または専用 en* インターフェース）として表示され、 公網 en0 と分離される。ノード 1 と 2 の間で iperf3 を 60 秒 TCP スループット測定した結果、 単方向平均 58.4 Gbps（約 7.3 GB/s）、双方向合計約 94 Gbps。 rsync で 30 GB の大小混在ファイル（DerivedData 構造を模倣）を転送した所要時間は 42 秒で、 公網直伝の約 6.4 倍だった。

58 Gbps が公称 80 Gbps より低いのは正常だ。プロトコルオーバーヘッド、CPU ソフト割り込み、 NVMe 持続書き込み（単ディスク約 2.8 GB/s 順次書き込み）が重なるためだ。 コンパイルファームではボトルネックが「ネットワーク」から「ディスク I/O」や「リンカの単一スレッド」に移りやすく、 後述の Xcode 並列テストで加速比が線形 3 倍に届かない理由もここにある。

並列有効化後の受け入れテスト：システムに何が見えるべきか

注文構成ページで「Thunderbolt 5 マルチマシン並列」オプションにチェック（日額 $1.9、月額 $9.5）し、 同一ノード・同一注文バッチの複数インスタンスすべてに同オプションを付けること。 PixVPS がラック側で物理配線を完了する。各マシンにログイン後、以下で相互接続の準備完了を確認する。

1. 01
   TB5 ブリッジインターフェースの存在確認

   各マシンで networksetup -listallhardwareports を実行し、Thunderbolt Bridge または専用 TB インターフェースが表示されること。ifconfig で相互接続セグメントの IP（通常 169.254.x.x または DC 内網、実際の割り当てに従う）を特定する。

2. 02
   ノード間 ping と帯域クイックテスト

   ノード A から：ping -c 10 <ノードBのTB内網IP>、レイテンシは < 1 ms が目安。brew install iperf3 後、B で iperf3 -s、A で iperf3 -c <BのTB IP> -t 30、数十 Gbps 級のスループットを確認する。

3. 03
   SSH 相互信頼（TB 内網のみ）

   ~/.ssh/config にクラスタノードの Host エイリアスを書き、Hostname に TB 内網 IP を指定して大容量同期が公網を迂回しないようにする。例：Host m4-node2 → Hostname 10.20.0.12（IP はコンソール「クラスタ相互接続情報」に従う）。

4. 04
   共有アーティファクトディレクトリのマウント（任意）

   シンプルなのは rsync --delete で DerivedData を定期同期。発展形は NFS over TB や sshfs で読み取り専用キャッシュをマウント。今回のテストは「マスターノードでビルド + rsync で増分プッシュ」方式で、スクリプト化コストが最小だった。

テスト 1：夜間マルチ App マトリクス並列 Archive

第 1 シナリオは「独立 App を 4 つ持つチームが、30 分以内に全 Release Archive を終えたい」ケース。 単体直列：4 scheme を順に xcodebuild archive、各 clean build 平均 3 分 48 秒、 合計 15 分 12 秒（Export・アップロードは未計上）。

3 台並列戦略：GitHub Actions workflow の matrix で 4 scheme を 3 Runner に配分（2+1+1）。 各機が独立にコード取得と署名環境を持ち、DerivedData は共有しない。 壁時計時間は最遅マシンに依存：4 分 05 秒（最遅 scheme は Swift Package 解決で 17 秒多かった）。 直列比で待ち時間を約 73% 削減。

このシナリオではTB5 帯域をほぼ消費しない——各機のビルドは大容量再転送なし。 並列の価値は「同一注文バッチ・同一ラック・低遅延スケジューリング」にある。 App が 2 つで月 1 回リリースなら 3 台 + TB5 は過剰。target が 5 つ以上で毎晩バッチビルドならマトリクス並列が合理的だ。

テスト 2：monorepo 共有 DerivedData の増分同期

第 2 シナリオは TB5 帯域の強みに近い。マスターノードで初回フルビルド後、 28 GB DerivedData を 2 台のスレーブに同期し、各スレーブは担当 framework target の増分コンパイルのみ実行する。

フロー：ノード 1 で clean archive（3 分 52 秒）→ rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → ノード 2・3 が並列で各自の framework target を増分 archive。

TB5 経路は公網同期より約 3 分 40 秒短縮し、総フローは単体直列より約 5 分速い。 DerivedData が 50 GB 超、または PR ごとにキャッシュをプッシュする運用では差がさらに開く。 「マルチマシン協調 + ビルドキャッシュ共有」のチームが TB5 を優先検討すべき理由はここだ。

テスト 3：distcc 試験と現実とのギャップ

3 台の M4 を distcc で分散 C/Swift コンパイルに使う試験も行った。マスターが前処理済みコンパイル単位を配布し、 スレーブが .o を返す。理論上 3 台で約 3 倍だが、clean build は 3 分 52 秒から 2 分 34 秒（約 1.5 倍）にとどまり、線形加速からは遠かった。

理由は単純だ。Xcode の新ビルドシステムは Swift 明示モジュールと高並列をデフォルト有効にし、 単体 M4 ですでに 10 コアを使い切る。distcc のリモートスケジューリング、ヘッダ同期、リンクのマスター回帰が利益を相殺する。 Swift コンパイル単位にはモジュール依存順序があり、純 C プロジェクトのように自由にスライスできない。

結論：典型的な iOS/Swift 工程では「各マシンが独立ジョブを実行」が「単体 distcc 分割」より現実的だ。 TB5 の価値は各機が一貫したソースとキャッシュを素早く得ることにあり、1 回の xcodebuild を無理に複数 CPU に割ることではない。 主力が C/C++ で Makefile が成熟しているなら distcc も試す価値はあるが、SwiftUI 大規模工程で 3 倍を期待するのは難しい。

つまずきメモ：配線は正常なのに速度が公網並みのとき

テスト中に「並列したように見えるが速度が公網並み」というケースがいくつかあった。排障用に整理する。

rsync が公網 IP を通っている。SSH config の Host エイリアスが公網アドレスのままだと、 30 GB 同期は再び 4 分級になる。ssh -v m4-node2 で実接続先 IP が TB 内網セグメントか確認する。

ディスク書き込みがボトルネック。3 台が同時に NVMe へ rsync 書き込みすると単ディスク持続書き込みが 1.5 GB/s まで落ち、 iperf3 は高帯域でも rsync エンドツーエンドは遅くなる。同期をずらすか、増分ディレクトリのみ（--link-dest）に絞る。

ファイアウォールや Little Snitch が TB インターフェースをブロック。稀にセキュリティソフトがブリッジネットワークをデフォルト拒否する。 一時的に無効化するか Thunderbolt Bridge を許可してから iperf3 を再測定する。

クラスタノードが同一注文バッチにない。TB5 並列は同一ノード・同一バッチで並列サービスを有効にしたインスタンス組み合わせにのみ適用される。 ノードをまたぐ（例：シンガポール 1 台 + 東京 1 台）場合は TB 物理接続不可で公網のみ。このとき TB5 追加は不要だ。

TB5 並列サービスを追加する価値があるタイミング

タイトルの問いに戻る——複数台 Mac mini をネットワーク化すると、どれだけ速くなるか。 3 種類のテストでは答えがワークフロー形態に依存する。 純マトリクス並列（各 App が独立ビルド）ならマシン台数に近い壁時計短縮が見込める。 キャッシュ共有 monorepo は TB5 で同期を分単位から秒単位へ圧縮できる。 distcc で 1 回のコンパイルを複数機に割る手法は Swift 工程では効果が限定的だ。

日常 CI にクラウド Mac 1 台で足りるなら、標準 M4（$21.1/日、16 GB メモリ、1 Gbps 専用帯域）で十分で、 TB5 の追加料金は不要だ。以下の組み合わせが揃ったら TB5（$1.9/日 / $9.5/月）の追加が合理的になる： 同一ノードに 2 台以上、夜間バッチ総時間が 30 分超、 またはノード間で 10 GB 超の DerivedData / SPM キャッシュを頻繁に同期する必要がある。

PixVPS はシンガポール、日本（東京）、韓国（ソウル）、中国香港、米国東部の 5 ノードで同一ハードウェアと並列オプションを提供する。 支払い後 1〜5 分で単体が開通し、クラスタバッチの TB 配線はデータセンター側で実施される。 注文構成ページで TB5 並列にチェックすると複数マシンが同一相互接続ドメインに入る。 稼働中インスタンスへの後追い追加も可能（ヘルプセンター参照）。 7×24 有人サポート、チケット 1 時間以内返信。クラスタトポロジと内網 IP はコンソール「クラスタ相互接続情報」で確認できる。

コンパイルファームの経済学は単純だ。並列度 × 単体速度 − 協調オーバーヘッド = 実利益。 Thunderbolt 5 並列が削るのは協調コストの最大要因——大容量同期の待ち時間だ。 ワークフローを独立ジョブに分解してから TB5 でキャッシュ配布を加速する方が、 マシンを増やすだけより壁時計時間を短縮しやすい。