Apple's Minions paper turns idle Macs into a shared GPU pool for AI jobs that queued for ten hoursApple's Minions paper turns idle Macs into a shared GPU pool for AI jobs that queued for ten hours

Six Apple researchers have published a paper describing Minions, a system that runs machine learning jobs on the graphics processors of Apple silicon Macs while those Macs sit idle.

The paper went up on arXiv on 9 October and is listed on Apple's Machine Learning Research site, with all six authors giving Apple addresses. It runs to three pages, with one diagram and one table, and drew wider attention when AppleInsider covered it on 15 October. It describes a tool Apple teams use internally. Apple has announced nothing, and the paper names no product or feature for customers.

How does Minions work?

The authors describe four parts. A central Minion Server takes a job through a web interface or an API and splits it into smaller subtasks. A PostgreSQL database with seven tables records every task, subtask, heartbeat and error. The Minion Executor is the program that runs on each participating Mac. A Minion Watchdog looks for executors that have stopped responding.

Nothing assigns work to a Mac. Each executor asks the server for a subtask over a REST API, and the claim is settled in the database: a unique constraint means only one Mac can hold a given subtask, and any Mac that loses the race simply asks for another. Inputs come from Amazon S3, results go back there, and a model the Mac does not already have is downloaded and cached before the work starts.

Executors report in every five minutes. When one goes quiet, because of a dropped network, a Mac going to sleep, a shutdown or an owner who needs the full machine back and stops the executor, the Watchdog returns the unfinished subtask to the queue for another Mac to pick up.

Two kinds of work are supported today, according to the paper:

• Embeddings, the numeric representations search systems use, generated with open models from Hugging Face through its transformers Python library.
• Large language model completions, run through Ollama, the open-source tool for running models locally on a Mac.

Jobs run first in, first out by default. The owner of each Mac can tell its executor to prefer work from a named team, project or task, so a team can point the machines it manages at its own urgent job.

What results does the paper report?

The paper says Minions has served inference work for several teams. Its one table compares life before and after: GPU queue time drops from hours, sometimes more than ten, to minutes; new GPU requests go from required to none; infrastructure cost goes from high to zero; and scaling goes from manual to organic.

That is the whole evaluation. The paper does not say how many Macs took part, which chips they had, how many tokens or embeddings they produced, how much power they drew, or how often a subtask had to be run again after a Mac dropped out.

It is candid about how participation works in practice. Colleagues message each other on Slack asking for the executor to be run for a particular project. The most common objection the authors met was confidentiality, running one team's data on another person's Mac, and their answer is separate deployments per team or organisation, each with its own database and its own pool of Macs. Future work, they write, is distributed training, and possibly federating idle Macs across organisations or the wider public into one shared pool.

Our take

The striking line in the paper is not technical. It is that teams inside Apple waited more than ten hours for GPU time, and that the fix was the Macs already on their desks. Even a company that designs its own chips rations server GPUs, and the spare capacity it found was in laptops and desktops doing email.

Minions is also deliberately ordinary. PostgreSQL, S3, Hugging Face and Ollama are tools any team can install this afternoon. The paper never mentions MLX, Apple's own framework for machine learning on Apple silicon, which suggests the authors chose whatever their colleagues could set up fastest over whatever would run fastest. For developers with a drawer of M-series Macs, that is the useful part: the design is copyable as written.

It is worth being clear about what it does not do. Each subtask runs whole on one Mac, so a model has to fit in that Mac's memory. That is the opposite approach to Meta's 816 billion parameter Muse Spark Open, which is split across several M5 Ultra Mac Studios joined by fast links. Minions suits batch work that breaks into independent pieces, such as embedding a large document collection or running one prompt over thousands of records, where losing a Mac costs one piece rather than the job.

The zero in the cost column needs reading carefully. The hardware was already bought, but electricity, storage in S3 and the owner's fan noise are not free, and none is measured. Pooling Macs is not a new idea either: a Spanish museum wired 30 old Intel Mac minis into a working Cray-1 replica. The difference is that those machines exist for the cluster. Minions borrows machines people are working on, and the paper does not explain how an executor decides a Mac is idle. The only way back it describes is the owner stopping the executor.

For Mac owners outside Apple, nothing changes: this is internal research, not a macOS feature. The idea the authors end on, a public pool of idle Macs, is where APPDOOK sees the real obstacle, and the paper names it itself. Colleagues inside one company hesitated to run each other's data. Strangers would need isolation guarantees that three pages do not begin to describe, and that is the part to watch if Apple ever takes this further.