Apple has published research on Minions, a distributed computing system that pools the idle GPUs of Apple silicon Macs to run AI inference.
According to the research team, some jobs that previously waited more than 10 hours to start on congested, centrally managed GPU facilities can now begin within minutes under Minions.
The system's defining feature is that it does not rely on buying new GPUs. Instead, it uses the spare computing capacity of Apple silicon Macs that teams already own.
However, simply gathering idle GPUs from multiple Macs does not make every workload efficient. The system also has to handle questions such as how to recover when a Mac stops mid-task, which jobs to assign to which machine, and how far sensitive data can be shared.
Minions' design shows how everyday Macs can be turned into a practical distributed computing platform.
The findings appeared in a preprint that Apple's Jianhua Li and colleagues submitted to arXiv on October 9, 2026. Apple's official research summary and the paper's operational evaluation describe its use as a complement to existing centralized GPU facilities.
Note that the reduction from hours to minutes refers to the wait before a job starts running. It is not a performance comparison showing how many times faster the AI computation itself became, or how much total job completion time fell.
A Simple Distributed System in Which Macs Fetch Their Own Work
Minions currently supports inference, meaning the processing of data with an already trained AI model.
Specifically, it handles embedding generation, which converts text into numerical vectors usable for search and similar tasks, and text generation with large language models (LLMs).
Embedding generation uses Hugging Face's Transformers, while LLM text generation uses Ollama, which runs AI models on a Mac.
Each Mac downloads the models it needs and stores them locally so they can be reused in later jobs.
The core of the system consists of the "Minion Server," which manages jobs, and the "Minion Executor," which runs on each Mac.
The Minion Server splits incoming jobs into small units of work and registers them in a PostgreSQL database.
Each Mac's Minion Executor queries the server's API to obtain jobs it can run.
A Mac that receives work runs inference on its own GPU. When it finishes, it saves the result to storage and reports completion to the server.
In this setup, Macs do not need to connect directly to PostgreSQL. Job assignment and status management go through the Minion Server.
The main storage for input data and output results is Amazon S3, Amazon Web Services' (AWS) object storage.
Large data is exchanged directly between the Macs and S3, leaving the Minion Server to focus on managing and assigning jobs.
This avoids routing all input data and results through the central server, which keeps the load on it down.
Grafana is used to monitor operations. Based on information stored in PostgreSQL, teams can see which Macs are active or idle and how many jobs have completed or failed.
Keeping Multiple Macs From Running the Same Job
In distributed processing, multiple Macs may try to grab the same job at the same time.
Left unchecked, the same work would be executed twice, wasting limited GPU resources.
Minions addresses this with a PostgreSQL unique constraint.
A job is identified by team, project, and job name, and each split unit of work is given its own number.
A constraint on this combined identifier ensures that the record indicating which machine owns the work cannot be duplicated.
Even if several Macs try to take the same unit of work, only the machine whose record is successfully inserted into PostgreSQL gets to handle it.
Machines that fail to acquire it go look for other work.
This conflict resolution uses PostgreSQL's INSERT ... ON CONFLICT mechanism.
As a result, job assignment can be coordinated on the database side without the Macs having to check one another's status directly.
If a Mac Stops Midway, Another Machine Takes Over
Minions does not run on dedicated servers operating around the clock in a data center. It uses Macs that employees and researchers use every day.
Those machines may go to sleep, lose their network connection, or have the executor stopped by users who want to prioritize their own work.
Minions is designed on the assumption that such interruptions will occur.
The Minion Executor on each Mac sends a heartbeat to the server every five minutes.
A monitoring component called the "Minion Watchdog" checks for heartbeats from machines running jobs and returns the unfinished work of any machine that stops responding to the queue.
Another Mac can then pick up the job and redo the processing from the beginning.
Rather than monitoring every machine at all times, the system limits monitoring to machines that have running jobs, which keeps management overhead down even when the number of participating machines fluctuates.
This approach suits tasks such as generating embedding vectors from large volumes of text, or running many independent text-generation jobs.
For example, if 100,000 documents are split into many small jobs, and some Macs stop midway, only the unfinished jobs need to be rerun on other Macs.
Redoing work, however, costs extra computing time.
How large the jobs are made also affects how much computation is wasted when a machine drops out.
As a result, more participating Macs do not necessarily mean a proportional increase in the work that can be processed.
Furthermore, a mechanism that prevents duplicate job ownership does not by itself guarantee that each result is finalized exactly once.
For instance, if a Mac that lost its network connection keeps processing locally, the server may conclude that it has stopped and assign the same job to another Mac.
If the original Mac then reconnects and submits its result, multiple results arrive for the same job.
How to decide which result to adopt, and how to handle the duplicates, requires separate consideration.
The published paper does not describe in detail how such result conflicts are resolved.
This does not mean Minions is flawed, but it is one point worth verifying in real-world operation.
Also, a five-minute heartbeat interval does not mean a stopped machine's jobs are always reassigned within five minutes.
No concrete measurements have been published for the timeout before a machine is judged unresponsive, or for actual recovery time.
How Minions Differs From MLX, Which Runs Giant AI Models Across Multiple Macs
Separately from Minions, Apple is also developing technology for connecting multiple Macs and running a single giant AI model across them.
One piece is high-speed communication using RDMA (Remote Direct Memory Access) over Thunderbolt.
According to Apple's official technical note TN3205, the feature is available on Apple silicon Macs with Thunderbolt 5 running macOS 26.2 or later.
RDMA is a technology for exchanging data with low latency by reducing the CPU and OS overhead involved in memory transfers between machines.
The MLX session published at WWDC26 shows how this high-speed communication layer is combined with Apple's communication library JACCL and the machine learning library MLX to distribute AI model weights and computation across multiple Macs.
In tensor parallelism in particular, where the computation within each model layer is split across machines, frequent data exchange between machines occurs every time a token is generated.
Low communication latency therefore has a major effect on performance.
That said, simply connecting Macs with Thunderbolt cables does not automatically let them run a giant model in a distributed fashion. Supporting communication libraries and a mechanism for splitting and running the model are required.
Minions, by contrast, takes a different approach from model splitting.
It divides jobs into small pieces, and each Mac performs independent inference using an AI model it holds locally.
In other words, Minions distributes "work," while MLX tensor parallelism distributes "the model and its computation."
The differences are summarized below.
| Comparison | Minions | Model distribution with RDMA, JACCL, and MLX |
|---|---|---|
| What is distributed | Small inference jobs | The weights and computation of a single AI model |
| Coordination between machines | Jobs fetched via API; input and output go through storage | Frequent data exchange between machines during computation |
| Purpose of adding Macs | More independent jobs can run at the same time | Computation for a large model is spread across multiple machines |
| Main benefit | Use of idle GPUs and shorter waits before jobs start | Support for running large models and parallel computation |
This comparison is based on the execution method described in the Minions paper and the model-distribution technology presented for MLX at WWDC26.
Adding more Macs to Minions does not mean a giant model that does not fit in a single Mac's memory can suddenly be run.
The right system configuration depends on whether you want to process many independent inference jobs efficiently or run one giant model distributed across several machines.
Managing Job Priority and the Scope of Sensitive Data Sharing
In principle, Minions processes jobs in the order they were registered.
However, the people who contribute Macs can configure them to prioritize particular teams, projects, or jobs.
For example, if a team has an urgent inference job, its own Macs can be set to handle it first.
As a real-world example, the paper also describes asking colleagues on Slack to launch the Minion Executor and join a particular job.
Once no prioritized jobs remain, however, a machine takes work from the shared queue, which includes other teams' jobs.
This is convenient for flexibly sharing computing resources, but it calls for caution when handling sensitive data.
A team-priority setting only changes the order in which jobs are processed. It does not limit the scope of data sharing.
Separately from these priority settings, Apple's paper also describes configurations that provide dedicated environments for each team or organization.
Organizing the explanation of priority settings and the explanation of dedicated environments, the differences are as follows.
| Feature | What it controls | Relationship to other teams' jobs |
|---|---|---|
| Team and job priority settings | Which jobs are processed first | If there are no priority jobs, the machine also takes other teams' jobs |
| Dedicated database and independent machine pool | The environment that manages jobs and the range of participating Macs | Independent operating environments can be built for each team or organization |
It would be dangerous to assume, without understanding this difference, that priority settings alone keep confidential information within a particular team.
Building a dedicated environment, on the other hand, lets an organization manage which machines may participate. However, the paper does not disclose details such as the authentication method or access permissions, so a dedicated environment does not guarantee complete security.
In addition, inference running inside a Mac is a separate matter from whether the data being processed stays off external systems.
Minions retrieves input data from S3 and saves results to S3.
Even if there is no need to send inference requests to an external AI model API, permission management is still required: which Macs can access the input data, and which storage they can write results to.
Adding participating Macs may make more GPUs available.
But when handling highly sensitive data, processing must be entrusted only to trusted machines.
Balancing a broader pool of shared computing resources with appropriate limits on data access will be key to making a distributed processing system practical.
No New GPUs Needed, but Operating Costs Are Not Zero
The most notable result of the Minions research is that additional inference capacity was secured using only existing Macs, without buying new GPUs.
The paper describes the number of new GPUs required after adopting Minions as "none" and the infrastructure cost as "zero."
Being able to avoid buying additional dedicated GPUs by using the spare capacity of Macs already in the organization is a significant achievement.
This does not mean, however, that the operating cost of the entire system became completely zero.
There are costs for the electricity to run the Macs, the storage that holds input data and results, and the maintenance of servers and databases.
Managing individual machines and handling problems also require staff and time.
Because the published paper does not give a detailed breakdown of these costs, it is not possible to assess the total cost of ownership compared with dedicated GPU facilities.
The publicly available information is also limited on performance.
For example, details such as the number of Macs that participated in Minions, the generations of Apple silicon, the AI models used, and the evaluation period are not stated.
There are no specific measurements of token generation speed or GPU utilization during inference, and no results from a comparison with dedicated GPU facilities under the same conditions.
The reduction in job start wait times from more than 10 hours to a few minutes should therefore be read as a result that Apple's research team reported from actual operation.
Minions has also not been announced as a new feature that ordinary Mac users can start using right away.
Future research directions include supporting distributed training as well as inference, and a mechanism for sharing GPU resources across different organizations.
For anyone considering adopting a system like Minions, the first thing to check is whether the AI workload can be split into small, independent jobs.
Other important questions are whether reruns after machine interruptions are acceptable, and whether enough Macs can be secured that are safe to share input data with.
If these conditions are met and the system can be run efficiently, including management costs, existing Macs could be a strong option for easing congestion on centralized GPU facilities.
Apple's Minions shows that expanding AI processing capacity does not necessarily mean buying expensive new GPUs.
Setting up a mechanism to direct the computing resources already at hand toward the work that needs them, when it is needed, could also make AI infrastructure more efficient.