Apple's idle Macs pull their own AI jobs from a PostgreSQL queue, with no central scheduler
Apple's internal Minions system moves stalled AI jobs onto idle Macs, cutting some 10-plus-hour GPU queues to as little as minutes. The researchers also saw a common worry about team data running on devices outside the group.
The Engineer · Build desk
What happened
- A Minion Server splits submitted tasks into subtasks in PostgreSQL, and an executor on each Mac pulls the next one over REST APIs with no central scheduler.
- The system only does inference on Apple Silicon: embeddings with open-source Hugging Face models, and text generation through Ollama installed on each participating Mac.
- A Watchdog tracks heartbeats that working Macs send every five minutes, and unfinished subtasks return to the queue when a Mac sleeps, drops off, powers off or is stopped.
- The paper also cites that Minions requests need no new GPU requests and that scaling effort goes from manual to organic.
Why it matters
- constraint Each Mac runs a whole model on its own piece of work, so the model has to fit on one Mac. The queue-time result transfers only to workloads of that shape, and only when enough Macs sit idle as the queue builds.
- cost Infrastructure cost is zero on paper, but electricity and hardware wear are not counted, so the bill moves to whoever owns the Macs.
- exposure Scoping each deployment to a team or organization, with its own database and Mac pool, protects data. Every added boundary also leaves fewer idle Macs for a given queue.
Without a central scheduler, the PostgreSQL table is the only coordination point [4]. A Mac asks for work when it is free to take it. A Mac that stops asking drops out of the pool with no deregistration step [4]. Tom's Hardware's account does not say how many missed heartbeats trigger a requeue.
Re-running a subtask is cheap because of how the work is cut. Tom's Hardware reads the paper as having every Mac run a complete model on its assigned slice of the job, and says the paper does not suggest any one model is split across Macs [7]. A dead Mac therefore costs one subtask, not a shard of a model. We think that is the right tradeoff for machines whose owners can close the lid at any time. The same outlet points out that handing small chunks to idle machines is old, as SETI@home and Folding@home did [8]. Training is a different workload, and the authors list it as future work [16].
Capacity planning here is a Slack thread. According to the paper, team members may "send Slack messages requesting others to temporarily run the Minion Executor and target a specific project or task" [10]. Owners keep control of what their Mac runs. With "dynamic task binding" an owner can prefer one team's or project's jobs, and the default is first-in, first-out [9].
The motive is visible in Apple's quarterly filing from July. It says the company "depends on access to sufficient computing resources" in an ecosystem with "constrained supply, extended lead times, and increasing costs" [12]. Tom's Hardware writes that the risk of being unable to "secure sufficient capacity," even with Apple's own data centers and third-party clouds, appears to make the Minions approach more practical [13].
The authors look further out. They write that if idle Macs across organizations "or potentially across the global community" can be "securely federated," those machines could be pooled into one shared GPU resource [17]. Today the Macs serve as spillover capacity for AI work within Apple alone [18].
What to watch
- Whether Apple or the authors publish pool sizes and the share of jobs that saw minute-level waits instead of the 10-plus-hour queues.
- How the planned distributed-training extension copes with Macs that sleep or drop off mid-run.
- Whether federation across organizations gets a concrete confidentiality design beyond team- and organization-scoped pools.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence40
- Adoption15
- Hype gap+20
- Incentives45
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Apple internally uses a system called Minions, a 'virtual GPU cloud' made up of idle Macs, described in a recent arXiv paper by its researchers.
- [2]
Minions takes stalled AI jobs, some of which once had 10-plus-hour company GPU queues, and distributes them to Macs on the network, with wait times down to as little as minutes.
- [3]
The researchers observed a common concern about teams' data running on devices outside their group.
- [4]
The Minion Server splits submitted tasks into subtasks stored in a PostgreSQL database; a Minion Executor on each Mac pulls the next subtask over REST APIs, with no central scheduler in this 'pull-based execution model.'
- [5]
Minions relies on Apple Silicon for AI inference, the only type of work it does; the two job kinds are embeddings with open-source Hugging Face transformer models and text generation from LLMs through Ollama, installed on each participating Mac.
- [6]
The Minion Watchdog catches failures by tracking heartbeats that Macs running work send every five minutes; unfinished subtasks return to the queue when a Mac goes to sleep, drops off the network, powers off, or a user stops the executor.
- [7]
Tom's Hardware understands that each Mac runs a whole model on its own piece of work, and says the paper does not suggest any one model is split across Macs.
- [8]
The volunteer computing angle is not new, reminiscent of SETI@home's and Folding@home's model of distributing small chunks to idle machines.
- [9]
The Mac's owner can determine which jobs it takes first, such as preferring one team's or project's jobs with 'dynamic task binding,' or can rely on the default first-in, first-out scheme.
- [10]
Participation is handled informally; team members may 'send Slack messages requesting others to temporarily run the Minion Executor and target a specific project or task.'
- [11]
Apple aims to mitigate confidentiality concerns with team- and organization-scoped deployments that have their own databases and separate pools of Macs.
- [12]
Apple's latest quarterly filing, in July, says it 'depends on access to sufficient computing resources' in an ecosystem with 'constrained supply, extended lead times, and increasing costs.'
- [13]
The risk that Apple may be unable to 'secure sufficient capacity,' even with its own data centers and third-party cloud providers, appears to make the Minions approach more practical.
- [14]
The paper cites that requests with Minions do not require new GPU requests and that the scaling effort goes from manual to organic.
- [15]
The paper cites the infrastructure cost as zeroed; Tom's Hardware notes this does not factor in electricity costs or hardware wear.
- [16]
The authors say that in future work Minions will extend to distributed model training.
- [17]
The authors write that if idle Macs across organizations 'or potentially across the global community' can be 'securely federated,' they could form a shared GPU pool.
- [18]
For now, the Macs act as overflow AI capacity only inside Apple.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- tomshardware.comApple researchers turn idle Macs into a virtual GPU cloud with ‘Minions’
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Distributed AI inferenceFollow
- AI Compute Supply and ScarcityFollow
- Apple SiliconFollow