Apple's Minions: a GPU cloud built from idle Macs — how it works

TL;DR: Apple published a paper called Minions (arXiv, October 2026): an internal system that pools idle GPUs on employees’ Macs into a distributed cloud for ML inference. Jobs that queued for centralized GPUs for 10+ hours now start within minutes — with zero new hardware. The architecture is deliberately pragmatic: PostgreSQL as the source of truth, no central scheduler, Ollama on every Mac.

The problem: GPUs queue for hours while hundreds of Macs sit idle

In any large company, ML inference lives on centralized GPU clusters: expensive, permanently oversubscribed, and jobs wait in line. The paper states the number honestly: some inference jobs waited in queue for over ten hours.

Meanwhile, engineers’ desks host Apple Silicon Macs with perfectly capable GPUs that do nothing most of the day. The question Minions answers: can this stranded capacity be turned into a working cloud — without a single new purchase order?

The answer is yes, and it runs in production across several Apple teams.

Architecture: four components and no magic

The system has four parts:

• Minion Server — the coordinator with a web UI and REST APIs. Accepts a task, validates parameters, and asynchronously splits it into subtasks.
• PostgreSQL — the single source of truth: all tasks, subtasks, executor states, and heartbeats. Seven tables in total.
• Minion Executor — an agent on each macOS device. Pulls subtasks from the server over REST, executes on the local GPU, writes results to S3, heartbeats every five minutes.
• Minion Watchdog — monitors executors. If a device sleeps, loses network, or its owner kills the agent, the unfinished subtask returns to the queue and another executor picks it up.

Two design decisions keep the system simple and resilient.

No central scheduler. Executors pull subtasks themselves. Claiming a subtask is a race to INSERT into the minion_subtask_acquirement table, which has a unique constraint over (team, project, task_name, subtask_id). Whoever inserts first owns the subtask; everyone else gets ON CONFLICT DO NOTHING and grabs the next one. The entire mutual-exclusion logic is one uniqueness constraint in Postgres.

Failure is the norm, not the exception. The Watchdog tracks only executors that are currently running something — not every registered device — which is cheap and scales. Device went to sleep mid-subtask? The subtask simply returns to the queue.

What it runs: embeddings and LLMs via Ollama

Minions supports two workload classes, both about local inference:

1. Embedding generation — open-source transformers from HuggingFace via the Python API.
2. LLM completion — through Ollama installed on each participating Mac. No external API calls: the model caches locally, inference happens on-device.

Inputs and outputs live in S3 — compute is decoupled from storage, and large payloads never travel through the coordination server.

There’s a pleasantly human detail too: priorities are partly resolved by hand — a team simply messages colleagues on Slack asking them to run the executor tonight. For urgent work there’s dynamic binding: a device owner can pin their executor to prefer a specific project, and when nothing preferred is pending, it falls back to the global FIFO queue.

Numbers

An honest caveat: the paper is three pages — an experience report, not a benchmark. There’s no throughput data, no per-model breakdown, no cost-per-token comparison.

The catch: your data on someone else’s desk

The authors name the main adoption blocker directly: data confidentiality. Running your workload on a colleague’s Mac from another department is a trust question, even inside one company. Minions’ answer is organizational rather than cryptographic: team-scoped deployments with a dedicated PostgreSQL and an isolated executor pool.

And that’s arguably the most interesting thing in the paper. The hottest problem in distributed computing turned out to be social, not technical: data matters to whoever holds it.

Why this is close to home

Minions hits two themes we live by.

First — local inference as the norm. Apple runs embeddings and LLM completion inside the company on ordinary Macs via Ollama — because it’s free, fast, and needs nobody’s permission. MaxGraph is built the same way: the embedding model runs on your machine or your server, and your agent’s memory is a file you own, not a row in someone else’s database. When Apple writes that “idle hardware is a cloud,” local-first stops being a fringe philosophy.

Second — data wants to live with its owner. Minions solves confidentiality with trust boundaries. We solve it more radically: your agent’s memory never leaves your machine at all — no boundaries needed when there’s nothing to share.

FAQ

Is Minions open source? No. It’s an experience paper from Apple; no public code. But the architecture is described well enough to build an equivalent: pull model, a Postgres unique constraint for subtask claiming, a heartbeat watchdog, Ollama on the nodes.

Could a small team run something like this? The idea scales down nicely: two Macs in an office plus Postgres on a NAS is already a working setup for batch embeddings. Ollama gives you LLM inference on Apple Silicon out of the box.

Does this replace cloud GPUs? For inference — partly. For training, no: the authors themselves name distributed training as future work. And a “cloud of Macs” isn’t about peak throughput; it’s about utilizing what you already own.

What does this have to do with agent memory? Directly: embedding generation is one of Minions’ two workloads — the same class of task MaxGraph runs for semantic search over the memory graph. Local embedding inference is exactly what lets our search work without sending your data anywhere.

What’s next

• Why local inference is also about money: our token savings benchmark.
• How hybrid memory search works: graph + vectors.
• Agent memory in 10 minutes: the Claude Code guide.