Apple uses a “Minions” system to turn idle Macs into an internal AI computing network. Tasks that once waited more than 10 hours for a GPU may now wait only a few minutes by distributing subtasks to Macs through a pull-based system.
The limitation is that Minions supports only AI inference, and each Mac runs the entire model locally rather than splitting the model across machines. Data confidentiality remains a concern because teams worry that workloads may run on devices outside their group. Infrastructure costs are described as zero in the research, but electricity and hardware wear are not included.
From Hour-Long GPU Queues to Using Idle Macs
Some AI workloads previously had to wait more than 10 hours in a GPU queue, disrupting experimentation and processing even when the team was ready to run the jobs.
Minions addresses this by sending subtasks to idle Macs on the network. Each machine takes a task, runs it, and sends the result back. In some cases, the system reduces waiting time from several hours to just a few minutes.
Where Minions Fits in Apple’s Computing System
Minions is an internal Apple system that combines Macs powered by Apple Silicon into a “virtual GPU cloud” for AI inference. It supports both embedding and text-generation workloads through models installed on the machines.
The system therefore serves as another layer of computing infrastructure alongside Apple’s data centers and external cloud providers. More complex workloads in Private Cloud Compute still use Nvidia GPUs on Google Cloud.
How It Turns Individual Macs into Shared Computing Power
| Traditional approach | Minions |
|---|---|
| Jobs remain in a GPU queue or require additional GPUs | The Minion Server splits jobs into subtasks and stores them in PostgreSQL |
| Jobs must wait for centralized resources | Each Mac pulls tasks through REST APIs without a central scheduler |
| Adding workloads may require requesting GPUs and infrastructure | Macs read data from S3, load models when needed, run them on their local GPUs, and send results back to S3 |
If a Mac goes to sleep, disconnects from the network, or the user stops the Executor, unfinished tasks return to the queue through the Minion Watchdog.
When Long Queues Become Jobs That Run While Macs Are Idle
Imagine a team submitting an AI job and waiting more than 10 hours in a GPU queue. Team members send a message in Slack asking others to start the Minion Executor on idle Macs and help with a specified project or task.
Once Macs join the pool, pending jobs are distributed across those machines, reducing the wait to just a few minutes in some cases. This works well for inference tasks such as generating embeddings or having language models generate text, but the team still needs to decide whether it is willing to let workloads run outside its own group.
From Vector Embeddings to Text Generation on Macs
Minions supports two main types of inference workloads: generating embeddings with open-source Hugging Face models, and generating text from large language models through Ollama installed on each Mac. It is suitable for teams with many subtasks that want to make productive use of idle machines.
The system reads input from Amazon S3 and stores the results back in S3. Mac owners can choose whether tasks from a particular team or project take priority through dynamic task binding, or allow tasks to proceed in a first-in, first-out queue.
How Minions Differs from Other Distributed Work Systems
| Concept | Workload characteristics | Usage context |
|---|---|---|
| Minions | AI inference on Apple Silicon, with each Mac running the complete model for its own task | Used within an organization to distribute work to idle Macs, with databases and machines grouped by team |
| OpenClaw home lab | Runs entire models on the hardware and unified memory of a single Mac | Used in a home lab, not as an internal organizational machine pool |
| SETI@home / Folding@home | Distributes small tasks to idle machines | A volunteer-computing concept; the source does not specify that it focuses on AI inference |
Minions’ main strength is that it directly connects the concept of idle machines with an organization’s AI workloads. Access control and confidentiality still require appropriately separated pools for each team.
Strengths and Limitations Revealed by the Actual Architecture
Minions helps move AI workloads waiting in GPU queues onto idle Macs, reducing waits from more than 10 hours to just a few minutes. It also avoids requesting new GPUs, lowers infrastructure costs, and scales with the number of participating machines.
The limitations are that it supports only AI inference on Apple Silicon, and each Mac must run the entire model locally rather than splitting it across multiple machines. There are also concerns about internal data, as well as electricity costs and hardware wear that are not included.
Costs That Do Not Disappear with the GPU Queue
Although the system describes infrastructure costs as zero, electricity and hardware wear are not included. These costs have not disappeared; they simply do not appear directly on the GPU bill.
In addition, Mac owners may need to stop the Minion Executor to use their machines themselves. Active tasks are sent back to the queue, meaning the cost savings come at the expense of machine availability.
Whose Mac Will Confidential Data End Up On?
The main concern is that a team’s data may run on a Mac outside its group, even if all machines are on the same internal network. This is especially important for internal workloads that must remain confidential.
Apple reduces the risk by separating deployments by team and organization. Each group has its own database and uses a separate Mac pool, making it easier to define the boundaries of workloads and the devices permitted to process them.
What to Watch If Apple Expands Minions Further
Minions shows clearly that computing has become a bottleneck for AI workloads. Some tasks that once waited more than 10 hours in GPU queues may be distributed across existing Macs, reducing wait times to minutes.
However, the system handles only AI inference, with each Mac running the complete model locally. Its processing limitations therefore still need to be monitored, along with electricity costs and hardware lifespan, which are not yet included in the system’s cost.