Apple's Minions Paper Pools Idle Mac GPUs for Inference and Reports No Throughput

The claim in Apple's new Minions paper is that a team can cut GPU queue time from "hours (up to 10+)" to minutes by running inference on the Macs it already owns. The number that matters here is not the hours but the denominator: the paper never says how many Macs, which chips, or how many tokens per second they delivered.

Minions was posted to arXiv as 2610.12970 on 9 October 2026 and listed by Apple Machine Learning Research under the title "A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices." The authors are Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan and Sean Suchter. The arXiv paper runs three pages with one figure and one table.

What Minions actually is

It is a work queue, not a cluster. A Minion Server validates tasks and splits each one into subtasks. A Minion Executor on each participating Mac pulls eligible subtasks, downloads inputs from an AWS S3 bucket, caches models locally, runs inference and uploads results. A PostgreSQL store holds task and executor state, and a Minion Watchdog reclaims work from executors that stop responding.

There is no central scheduler. Default order is first-in, first-out, and claiming is settled by a database unique constraint on team, project, task name and subtask ID: "exactly one insert succeeds, and the winning executor becomes the subtask owner." Executors never touch PostgreSQL directly; they go through the server's REST APIs. The paper says the store has seven tables and names one.

Two workloads are described. Embedding generation uses open-source Hugging Face transformer models through the transformers Python API. LLM completion runs through Ollama on the participating device, with no remote API calls.

Fault tolerance at five-minute resolution

Executors send a heartbeat every five minutes. When one goes silent because a laptop slept, lost its network or was shut by its owner, the Watchdog returns the subtask to the queue.

Five minutes is the unit that decides what this system can serve. The paper does not give the Watchdog's timeout, but a 5-minute heartbeat means a subtask on a closed laptop cannot be declared lost in under one interval. That is tolerable for batch embedding jobs and useless for anything a person is waiting on, and the paper describes no latency-sensitive path.

The Watchdog also tracks heartbeats only for executors that are running subtasks, so an idle Mac costs the server nothing to keep registered.

The evaluation is a table of adjectives

Table 1 compares a centralized GPU setup with Minions on four rows. None carries a measurement.

Measure	Centralized GPUs	Minions
GPU queue time	Hours (up to 10+)	Minutes
New GPU requests	Required	None
Infrastructure cost	High	Zero
Scaling effort	Manual	Organic

"Zero" infrastructure cost is the claim to price carefully. It excludes the Macs, which already exist, and the S3 storage and PostgreSQL instances, which the paper says are maintained separately for development and production. It also excludes the electricity those GPUs draw while a person's laptop would otherwise be idle, and the paper gives no wattage.

A 10-hour queue is a statement about one team's experience of a shared cluster, not about a GPU model. The comparison would be sharper with cost per million embedded tokens on the same model, and the table has no such row. On this site's pricing coverage, such as the Claude Haiku 5.5 token price breakdown, the unit is always dollars per million tokens; Minions offers nothing to set beside it.

How teams recruit executors

The paper says teams often recruit executors over Slack. That is the supply side of the system: volunteers, running when their owners are not. Dynamic task binding lets an executor owner set preferences for a team, project and task name, and matching subtasks are dequeued first before the executor falls back to the global queue.

Observability is a Grafana dashboard on the PostgreSQL store that shows registered, online, busy and idle executors per team, plus active, completed and failed tasks. That dashboard presumably holds the utilisation numbers the paper omits.

What the paper does not say

Security gets two sentences. Team and organisation scoped deployments use dedicated databases and isolated executor pools, and S3 provides "industry-standard access control and security mechanisms." The paper acknowledges that confidentiality concerns about running work on devices outside an organisation are a barrier to adoption. It does not say whether model weights cached on a laptop are protected at rest.

There is no limitations section. Chip models, memory per device, model names and sizes, and throughput are all absent. Apple's page lists two related readings, one on MLX with the M5 Neural Accelerators from November 2025, and neither supplies those numbers either.

What would change my read is a follow-up with a fleet size and a delivered rate. If a few hundred Macs sustained even a modest embedding workload at a published tokens-per-second figure, the cost comparison would become testable against rented accelerators; without it, the paper is an architecture note with a satisfied customer. Apple's developer tooling remains a separate story, as in the xtool project that builds iOS apps without Xcode.

The authors say the next step is distributed model training and possibly federating idle macOS devices across organisations, which would move the confidentiality question from a footnote to the central design problem.