Apple researchers publish Minions, a GPU cloud on idle Apple Silicon Macs

What did Apple researchers publish?

On Apple’s Machine Learning Research site, Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan and Sean Suchter posted Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices. The same paper is also available as arXiv:2610.12970. The Register covered the work on 13 October 2026.

The problem they state is familiar inside large companies: embedding generation and large-language-model completion jobs pile up on shared GPU clusters that are expensive to expand. At the same time, modern Apple Silicon Macs leave high-performance GPUs idle for long stretches of a normal workday. Minions asks whether those idle GPUs can be aggregated into a practical inference platform without buying more hardware.

This is a research paper about an internal system, not a Mac App Store download or a cloud product. There is no public signup, no pricing page and no claim that outside organisations can join Apple’s pool. Read it as a systems design and an ops report from teams that already own fleets of Macs.

How does Minions turn idle Macs into a GPU cloud?

Minions has four main pieces: a Minion Server, a PostgreSQL metadata store, Minion Executor agents on macOS devices, and a Minion Watchdog. Users or information-retrieval pipelines submit inference tasks to the server. The server validates parameters, splits each task into subtasks and writes them into PostgreSQL.

Executors never talk to the database directly. They pull eligible subtasks through REST APIs on the Minion Server, download inputs from object storage such as Amazon S3, run the work on the local Apple Silicon GPU, upload outputs back to S3 and report status. Heartbeats go back to the server about every five minutes while a subtask is running.

Ownership of a subtask is an atomic insert into a dedicated acquirement table with a unique constraint on the team, project, task name and subtask id. If two Macs race for the same work, PostgreSQL lets exactly one insert succeed. That design avoids a heavy central scheduler and fits devices that appear and disappear through the day.

Teams can also bias which work a machine prefers. Device owners configure preferences for a team, project and task name so urgent jobs jump the global FIFO queue when the owning team temporarily marshals its own Macs. When no preferred work is waiting, executors fall back to the shared queue. For context on other local Mac and Windows inference packaging, see our note on Hugging Face’s Llama Windows tray app.

What workloads does Minions actually run?

The paper says Minions currently supports two GPU inference families on macOS. Embedding jobs load open transformer models from Hugging Face through the transformers Python API and generate vectors on the local GPU. Large-language-model completion jobs go through Ollama, which must be installed on the participating Mac; executors call Ollama locally rather than a remote API.

Those choices matter. Embeddings and chat completions are the jobs that often clog shared clusters in retrieval and agent stacks, and both can run on consumer Apple Silicon without a data-centre lease. They also leave training out of scope for now. The conclusion flags distributed training as future work, not as something Minions already does.

Compared with buying another rack of accelerators, the trade is organisational rather than silicon: you need people willing to leave an executor running, tolerate background GPU use and accept that a personal device can vanish mid-job. That is a different reliability model from a dedicated DGX-class box, even when the FLOPs look similar on paper.

How does the system stay reliable when a Mac sleeps?

Personal Macs fail in boring ways: sleep, Wi-Fi drops, power-offs, or a user killing the executor because they need the machine. Minions treats that as expected. The Watchdog tracks heartbeats only for executors that currently own a subtask. When a heartbeat goes missing, it releases the subtask back to the queue so another healthy Mac can claim it.

Storage is deliberately decoupled from the coordinator. Large inputs and outputs stay in S3 (or a configured object store) so the Minion Server is not a bandwidth bottleneck and so access control can reuse the organisation’s existing cloud IAM. Observability is built from the same PostgreSQL source of truth into Grafana dashboards that show online versus busy executors and task status by team.

Confidentiality is the adoption blocker the authors call out most clearly. Even for internal workloads, people hesitate to run jobs on machines outside their immediate group. Minions answers with team-scoped deployments: dedicated PostgreSQL instances and isolated executor pools so a group can keep stronger governance while still sharing Macs inside its boundary.

What results do the authors report?

The evaluation section is operational, not a Model Zoo shoot-out. Before Minions, some inference jobs in the authors’ environment waited more than ten hours for central GPUs. With Minions, tasks could often begin within minutes by using idle Macs. Their Table 1 summarises the claimed impact: queue time from hours (up to 10+) down to minutes, no new GPU requests, infrastructure cost described as “zero”, and scaling effort described as “organic” rather than a formal capacity ticket.

Those figures are Apple’s own experience report. The paper does not publish tokens per second, p50/p99 latency, GPU utilisation curves, failure rates or a controlled A/B against a reserved cluster of equal cost. The Register’s 13 October write-up likewise notes the absence of public throughput benchmarks. Treat “hours to minutes” as an internal ops outcome, not a portable SLA.

Informal coordination still matters. The authors say teams often ping colleagues on Slack to start an executor and target a specific project when something is urgent. That social layer is part of the system, even though it does not appear in the architecture diagram.

What are the limits, and what comes next?

Minions does not magically make every Mac a safe place for every dataset. Scoped deployments help, but a pull-based fleet of employee devices still expands the attack and compliance surface compared with a locked-down training cluster. Battery, thermals and interactive responsiveness also matter when the same machine is someone’s daily driver.

The paper’s future-work paragraph points at federating idle Macs across organisations, or even a wider community pool. That vision sits far beyond the internal system described today and would need stronger isolation, billing, identity and abuse controls than a Postgres-backed team queue.

For readers, the concrete takeaway is narrower: if your bottleneck is inference queue time and you already own lots of Apple Silicon Macs that sit idle, a pull-based executor with atomic subtask claims and a watchdog can turn that idle capacity into a useful overflow lane. It complements, rather than replaces, reserved GPU infrastructure—and until Apple or others publish numbers beyond queue-time anecdotes, it remains an engineering pattern to evaluate, not a finished public cloud.