Appleが、Appleシリコン搭載Macの空いているGPUを集め、AIの推論処理に活用する分散コンピューティングシステム「Minions」の研究成果を公表した。

研究チームによると、従来は集中管理されたGPU設備が混雑し、処理の開始まで10時間以上待たされることもあった一部のジョブが、Minionsでは数分以内に開始できるようになったという。

この仕組みの特徴は、新たなGPUを購入するのではなく、チームがすでに所有しているAppleシリコン搭載Macの余剰計算能力を活用することだ。

ただし、複数のMacから空いているGPUを集めるだけで、すべての処理を効率化できるわけではない。Macが作業途中で停止した場合の復旧方法や、各端末にどの仕事を割り当てるか、機密データをどこまで共有できるかといった課題にも対応する必要がある。

Minionsの設計からは、身近なMacを実用的な分散計算基盤として利用するための工夫が見えてくる。

今回の研究成果は、AppleのJianhua Li氏らが2026年10月9日にarXivへ投稿したプレプリント論文で公開された。Appleの公式研究紹介と論文の運用評価では、既存の集中型GPU設備を補完する用途が説明されている。

なお、数時間から数分へ短縮されたのは、ジョブの実行開始までの待ち時間だ。AIの計算処理自体が何倍高速化したのか、あるいはジョブ全体の完了時間がどれほど短縮されたのかを示す性能比較ではない。

AD

Macが自ら仕事を取得するシンプルな分散処理システム

Minionsが現在対応しているのは、学習済みのAIモデルを使ってデータを処理する「推論」だ。

具体的には、文章を検索などに利用できる数値ベクトルへ変換する「埋め込み生成」と、大規模言語モデル（LLM）による文章生成に対応している。

埋め込み生成にはHugging Faceの「Transformers」を利用し、LLMによる文章生成には、Mac上でAIモデルを実行できる「Ollama」を採用している。

各Macは必要なモデルをダウンロードし、その後の処理でも再利用できるようにローカルへ保存する。

システムの中心となるのは、ジョブを管理する「Minion Server」と、各Macで動作する「Minion Executor」だ。

Minion Serverは、受け付けたジョブを小さな処理単位に分割し、データベースのPostgreSQLに登録する。

各Macで動作するMinion Executorは、サーバーのAPIに問い合わせ、実行可能なジョブを取得する。

仕事を受け取ったMacは、自身のGPUを使って推論処理を実行する。処理が完了すると、結果をストレージに保存し、サーバーへ完了を報告する。

この構成では、MacがPostgreSQLへ直接接続する必要はない。ジョブの割り当てや状態管理は、Minion Serverを通じて行われる。

入力データと出力結果の主な保存先には、Amazon Web Services（AWS）のオブジェクトストレージ「Amazon S3」を使用する。

大容量のデータはMacとS3の間で直接やり取りし、Minion Serverはジョブの管理や割り当てに専念する。

これにより、すべての入力データと処理結果が中央サーバーを経由する構成を避け、サーバーへの負荷集中を抑えている。

運用状況の監視にはGrafanaを利用する。PostgreSQLに保存された情報を基に、稼働中のMacや待機中のMac、ジョブの完了状況や失敗状況などをチーム単位で確認できる。

複数のMacが同じ仕事を実行しないための工夫

分散処理では、複数のMacが同時に同じジョブを取得しようとする可能性がある。

そのままでは、同じ処理が重複して実行され、限られたGPU資源を無駄にしてしまう。

Minionsは、この問題への対策としてPostgreSQLの一意制約を利用している。

ジョブはチーム、プロジェクト、ジョブ名で識別され、さらに分割された処理ごとの番号が割り当てられる。

これらを組み合わせた識別情報に対して、処理を担当する端末の所有権を示す記録が重複しないよう制約を設けている。

複数のMacが同じ処理を取得しようとしても、PostgreSQLへの記録の追加に成功した端末だけが、その処理を担当できる仕組みだ。

取得に失敗した端末は、別の仕事を探す。

こうした競合の解決には、PostgreSQLが提供するINSERT ... ON CONFLICTの仕組みを活用している。

これにより、各Macが互いの状態を直接確認しなくても、データベース側でジョブの割り当てを調整できる。

Macが途中で停止しても、別の端末が処理を引き継ぐ

Minionsが利用するのは、データセンターで常時稼働する専用サーバーではなく、社員や研究者が日常的に使用するMacだ。

そのため、端末がスリープしたり、ネットワーク接続が切れたり、利用者が本来の作業を優先するために実行プログラムを停止したりする可能性がある。

Minionsは、こうした中断が発生することを前提に設計されている。

各Macで動作するMinion Executorは、5分間隔でサーバーへ生存通知を送信する。

「Minion Watchdog」と呼ばれる監視機能は、ジョブを実行している端末からの通知を確認し、応答しなくなった端末が担当していた未完了の処理を待ち行列へ戻す。

その後、別のMacがジョブを取得し、処理を最初からやり直せるようにする。

また、すべての端末を常時監視するのではなく、実行中のジョブを持つ端末に監視対象を絞ることで、参加台数が変動する環境でも管理負荷を抑えている。

この仕組みは、大量の文章から埋め込みベクトルを生成する処理や、互いに独立した多数の文章生成ジョブなどと相性がよい。

例えば、10万件の文章を複数の小さなジョブに分割して処理する場合、一部のMacが途中で停止しても、未完了のジョブだけを別のMacで再実行できる。

一方、処理をやり直すには、その分の計算時間が余計にかかる。

また、ジョブをどの程度の大きさに分割するかによっても、端末の離脱によって無駄になる計算量が変わる。

したがって、参加するMacが多ければ、それに比例して処理できる仕事が増えるとは限らない。

さらに、ジョブの所有権を重複させない仕組みだけで、処理結果を必ず一度だけ確定できるとは限らない。

例えば、ネットワーク接続が途切れたMacがローカルで処理を続けていた場合、サーバーはその端末が停止したと判断し、同じジョブを別のMacへ割り当てる可能性がある。

その後、元のMacが接続を回復して結果を送信すると、同じジョブについて複数の処理結果が届くことになる。

こうした場合に、どちらの結果を採用するのか、重複した結果をどのように処理するのかは、別途考慮する必要がある。

公開論文では、このような結果の競合をどのように解決するかについて、詳細な説明は示されていない。

これはMinionsに欠陥があると断定するものではないが、実運用で確認すべき点の一つだ。

また、生存通知が5分間隔だからといって、停止した端末のジョブが必ず5分以内に再割り当てされるわけではない。

応答停止と判断するまでのタイムアウトや、実際の復旧時間については具体的な測定値が公表されていない。

AD

複数のMacで巨大AIモデルを動かすMLXとの違い

AppleはMinionsとは別に、複数のMacを接続し、1つの巨大なAIモデルを分散して実行する技術も開発している。

その一つが、Thunderbolt経由のRDMA（Remote Direct Memory Access）を利用した高速通信だ。

Appleの公式技術文書「TN3205」によると、この機能はThunderbolt 5を搭載したAppleシリコンMacと、macOS 26.2以降の環境で利用できる。

RDMAは、端末間のメモリ転送に伴うCPUやOSの処理負荷を抑え、低遅延でデータをやり取りするための技術だ。

WWDC26で公開されたMLXの解説では、この高速通信基盤にAppleの通信ライブラリ「JACCL」と機械学習ライブラリ「MLX」を組み合わせ、AIモデルの重みや計算処理を複数のMacへ分散する方法が紹介されている。

特に、モデルの各層で行う計算を複数の端末に分割する「テンソル並列」では、トークンを生成するたびに端末間で頻繁なデータ交換が発生する。

そのため、通信遅延の小ささが処理性能を大きく左右する。

ただし、ThunderboltケーブルでMac同士を接続するだけで、自動的に巨大モデルを分散実行できるわけではない。対応する通信ライブラリや、モデルを分割して実行する仕組みが必要になる。

一方、Minionsはこうしたモデル分割とは異なる方式を採用している。

Minionsではジョブを小さく分割し、それぞれのMacがローカルに保持したAIモデルを使って独立した推論処理を行う。

つまり、Minionsは「仕事」を分散する仕組みであり、MLXのテンソル並列は「モデルと計算」を分散する仕組みだ。

両者の違いを整理すると、次のようになる。

比較項目 Minions RDMA・JACCL・MLXによるモデル分散
分散する対象 小分けにした推論ジョブ 1つのAIモデルの重みと計算処理
端末間の連携 API経由でジョブを取得し、ストレージを介して入出力 計算中に端末間でデータを頻繁に交換
Macを増やす目的 同時に処理できる独立したジョブを増やす 大きなモデルの計算を複数端末へ分散する
主な利点 余剰GPUの活用とジョブの開始待ち時間の短縮 大規模モデルの実行や並列計算を支援

この比較は、Minions論文で説明された実行方式と、WWDC26で紹介されたMLXのモデル分散技術に基づいている。

Minionsに参加するMacを増やしたからといって、単一のMacのメモリに収まらない巨大モデルが、そのまま実行できるようになるわけではない。

多数の独立した推論ジョブを効率よく処理したいのか、それとも1つの巨大モデルを複数端末に分散して実行したいのかによって、適切なシステム構成は異なる。

ジョブの優先順位と機密データの共有範囲をどう管理するか

Minionsでは原則として、先に登録されたジョブから順番に処理する。

ただし、Macを提供する側は、特定のチームやプロジェクト、ジョブを優先するよう設定できる。

例えば、あるチームで急ぎの推論ジョブが発生した場合、そのチームのMacに優先的に処理させることが可能だ。

論文では、実際の運用例として、Slackで同僚にMinion Executorの起動を呼びかけ、特定のジョブへの参加を依頼する方法も紹介されている。

ただし、優先するジョブがなくなると、端末は他のチームのジョブも含む共通の待ち行列から仕事を取得する。

これは、計算資源を柔軟に共有する上では便利な仕組みだが、機密データの取り扱いを考える際には注意が必要になる。

特定のチームを優先する設定は、あくまで処理するジョブの順序を変更するものであり、データの共有範囲を制限するものではないからだ。

Appleの論文では、こうした優先設定とは別に、チームや組織ごとに専用の環境を設ける構成も紹介されている。

優先設定に関する説明と専用環境に関する説明を整理すると、次のような違いがある。

機能 制御する対象 他チームのジョブとの関係
チーム・ジョブの優先設定 どのジョブを優先して処理するか 優先ジョブがなければ、他チームのジョブも取得する
専用データベースと独立した端末群 ジョブを管理する環境と参加するMacの範囲 チームや組織ごとに独立した運用環境を構築できる

この違いを理解せず、優先設定だけで機密情報が特定のチーム内に限定されると考えるのは危険だ。

一方、専用環境を構築すれば、端末の参加範囲を組織単位で管理できる。ただし、論文では認証方式やアクセス権限の詳細までは公開されておらず、専用環境だからといって完全な安全性が保証されるわけではない。

また、AIの推論がMac内部で実行されることと、処理するデータがMacの外部へ出ないことも別の話だ。

Minionsでは、入力データをS3から取得し、処理結果をS3に保存する。

外部のAIモデルAPIへ推論を依頼する必要がなくても、どのMacが入力データにアクセスできるのか、どのストレージに結果を保存できるのかといった権限管理は必要になる。

参加するMacを増やせば、それだけ多くのGPUを利用できる可能性がある。

しかし、機密性の高いデータを扱う場合には、信頼できる端末だけに処理を任せなければならない。

計算資源の共有範囲を広げることと、データのアクセス範囲を適切に制限することの両立が、分散処理システムを実用化する上で重要になる。

AD

GPUの追加購入は不要でも、運用コストまでゼロになるわけではない

Minionsの研究成果で特に注目されるのが、新しいGPUを購入せず、既存のMacだけで追加の推論能力を確保できたという点だ。

論文では、Minions導入後に必要となる新たなGPUの数を「なし」、インフラ費用を「ゼロ」と表現している。

すでに社内にあるMacの余剰計算能力を活用することで、専用GPUの追加購入を避けられたことは、大きな成果といえる。

ただし、これはシステム全体の運用費用が完全にゼロになったことを意味するわけではない。

Macを稼働させるための電力、入力データや処理結果を保存するストレージ、サーバーやデータベースの維持管理などには費用がかかる。

また、各端末の管理やトラブル対応にも、人員や時間が必要になる。

公開論文では、こうした費用の詳しい内訳は示されていないため、専用GPU設備と比較した総保有コストを評価することはできない。

性能面でも、現時点で公表されている情報には限界がある。

例えば、Minionsに参加したMacの台数やAppleシリコンの世代、使用したAIモデル、評価期間などの詳細は明記されていない。

推論時のトークン生成速度やGPU使用率に関する具体的な測定値もなく、専用GPU設備と同一条件で比較した結果は示されていない。

そのため、ジョブの開始待ち時間が10時間以上から数分に短縮されたという成果は、Appleの研究チームが実際の運用を通じて報告したものとして捉える必要がある。

また、Minionsは一般のMacユーザーがすぐに利用できる新機能として発表されたわけではない。

今後の研究課題としては、推論だけでなく分散学習にも対応することや、異なる組織の間でGPU資源を共有する仕組みなどが挙げられている。

Minionsのような仕組みを実際に導入する場合、まず確認すべきなのは、処理したいAIワークロードを独立した小さなジョブに分割できるかどうかだ。

さらに、端末の中断に伴う再実行を許容できるか、入力データを安全に共有できるMacを十分に確保できるかも重要になる。

これらの条件を満たし、管理費用まで含めて効率的に運用できるなら、既存のMacは集中型GPU設備の混雑を解消するための有力な選択肢になり得る。

AppleのMinionsは、AIの処理能力を拡大する方法が、必ずしも高価なGPUを新たに購入することだけではないと示している。

すでに手元にある計算資源を、必要なときに必要な仕事へ振り向ける。そうした仕組みを整えることも、AIインフラの効率化につながる可能性がある。