Apple researchers have described Minions, an internal system that pools the GPUs of idle Apple silicon Macs into a shared cloud for machine learning inference, in a paper Apple published on its Machine Learning Research site in October 2026. The six authors, all listed with an Apple affiliation, say inference jobs that once waited more than ten hours for central GPU capacity can now often start within minutes.
The paper, Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices, was submitted to arXiv on October 9, 2026. Its authors are Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan and Sean Suchter.
The problem: GPUs in the data center, idle GPUs on desks
The paper starts from two observations. Centralized GPU clusters “are expensive to expand and frequently oversubscribed,” which leads to “long queue times, reduced experimentation velocity, and increased operational cost.” At the same time, Macs with Apple silicon have “high-performance GPUs” that are “primarily used for interactive workloads, leaving significant GPU capacity idle for extended periods.”
Don’t miss the best of The Mac Observer
Set us as a preferred source and our Apple reporting ranks higher in your Google Search results and Discover feed — one tap, no account changes.
Minions is the answer to the question the authors pose: “can idle Apple Silicon GPUs be dynamically aggregated into a shared, distributed inference platform without additional hardware investment?” They describe it as a complement to central GPU infrastructure, not a replacement.
How Minions works
The system has four parts, according to the paper:
- Minion Server, which takes jobs through a web UI and APIs, checks the parameters and splits each task into subtasks
- PostgreSQL metadata store, which holds task and executor state in seven tables
- Minion Executor, the agent that runs on each Mac, pulls subtasks and runs them on the Mac’s GPU
- Minion Watchdog, which tracks executors that are running work and hands their subtasks back to the queue if they stop responding
Executors pull work rather than having it pushed to them. The authors say this pull model “accommodates the inherently intermittent availability of personal devices.” Each executor sends a heartbeat every five minutes while it works. If a Mac drops off the network, goes to sleep, is switched off, or its owner stops the executor because they need the full machine, the Watchdog releases that subtask so another Mac can pick it up.
Inputs and outputs live in Amazon S3, so large files never pass through the coordinating server. To stop two Macs grabbing the same subtask, the system relies on a unique database constraint: when several executors race to claim one subtask, “exactly one insert succeeds.”
What it runs
Minions handles two kinds of inference work on Macs. For embedding generation, executors use open-source transformer models from Hugging Face through the transformers Python library. For large language model completion, Minions uses Ollama, which runs models locally on the Mac “without remote API calls.” If a Mac does not already have a model cached, the executor downloads it before running the job.
Jobs normally run first in, first out. A feature called dynamic task binding lets a Mac’s owner tell its executor to prefer a particular team, project or task, so a group can point its own Macs at an urgent job. When nothing matching is queued, those Macs fall back to the general queue.
The results Apple reports
The paper’s evaluation is a short operational summary rather than a benchmark. It says Minions “has been used to support GPU inference workloads across multiple teams,” and lists the before and after in a table.
| Metric | Before Minions | With Minions |
|---|---|---|
| GPU queue time | Hours (up to 10+) | Minutes |
| New GPU requests | Required | None |
| Infrastructure cost | High | Zero |
| Scaling effort | Manual | Organic |
The authors also describe how people use it in practice: “team members may send Slack messages requesting others to temporarily run the Minion Executor and target a specific project or task.”
They name one adoption hurdle. Running work on Macs outside one’s own group raises data confidentiality concerns, so Minions supports deployments scoped to a team or organization, with their own databases and isolated pools of Macs.
Where Apple wants to take it
Future work, the paper says, will add distributed model training, not just inference. The authors end on a bigger idea. If idle Macs across organizations, or even across the wider community, “can be securely federated, they could form a massive, shared GPU resource pool that benefits the broader ecosystem.”
The paper does not say that Apple plans a product built on Minions. It describes a tool Apple teams use internally, and it is three pages long with one figure and one table.
Part of a wider push on Macs for AI
Minions appeared on Apple’s research site alongside another post, dated October 15, on running large language models with MLX across several Mac Studio computers. That post says a single Mac Studio offers “up to 512GB of unified memory” and that a cluster of four Mac Studios ran Muse Spark Open at “over 36 tokens per second.” We covered that work in our report on Muse running on Mac Studio.
The two projects tackle different jobs. The MLX post is about squeezing very large models onto a few powerful desktops. Minions is about using spare capacity on the Macs people already have.
