Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices
Listen
Radio episode about this paper
Transcript
Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.
Tom: Today's paper: "Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices".
Jane: The gist Minions presents a dynamic and distributed virtual GPU cloud that aggregates idle Apple Silicon GPUs across macOS devices to execute large-scale machine learning inference workloads,
Tom: First, who's behind it and why it matters.
Paper summary: Tom: So to wrap up, "Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices" presents a system that aggregates idle Apple Silicon GPUs across macOS devices to run machine learning inference tasks.
Jane: The core claim is that this enables teams to leverage existing hardware without needing to procure additional GPUs, providing flexible execution and fault tolerance.
Lu: The key technical innovation they highlight is the atomic subtask acquisition mechanism in PostgreSQL, which manages ownership through a dedicated table enforcing uniqueness.
Meng: From an operational standpoint, they show that this approach leads to a significant reduction in GPU queue time when compared to relying on centralized GPU resources under resource constraints.
Tom: The implications are that idle Apple Silicon GPUs on macOS devices can become a practical distributed platform for machine learning inference, which is a novel opportunity if organizations can securely federate these resources.
Jane: It’s about transforming dormant consumer hardware into a shared resource pool for the broader AI ecosystem, provided they can manage the federation securely.
Conclusion: Tom: So, we've been looking at Minions, this paper about using idle Apple Silicon GPUs to run machine learning inference tasks across macOS devices.
Jane: Right, so the title is "Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices," and the authors are Jianhua Li and his team.
Lu: The core idea is aggregating those idle GPUs into a cloud structure that teams can use right now without buying new hardware.
Meng: I gotta ask, how much of this actually works at scale? What breaks when you try to deploy this on real traffic?
Tom: Well, the paper shows they built an architecture with four main parts: a server, a database for metadata, an executor that runs on the devices themselves, and a watchdog to keep things running.
Jane: That means users submit tasks through the server, and then the executor pulls those subtasks off in chunks. They even use S3 for storing the input data because it keeps compute separate from storage.
Lu: The way they handle task binding is interesting; they use a specific database table to make sure only one executor owns a subtask at a time, which is an atomic acquisition mechanism.
Meng: That sounds like it would cause some contention under heavy load if not tuned perfectly. What about the actual workload? Are we talking just small embedding generations or full large language model completions?
Tom: They show examples for both; they use open-source transformer models from HuggingFace for embeddings, and they integrate with Ollama for running larger language models locally on the devices.
Jane: The big picture here is taking hardware that's already sitting there doing nothing and making it useful again in a distributed way. It really lets teams leverage existing assets without needing massive GPU procurement budgets.
Lu: If this works as described, it opens up a new way for organizations to share underutilized silicon across their entire fleet of Macs for inference needs.
Tom: It changes the conversation about infrastructure—instead of buying more centralized boxes, you can use what you already have spread out.
Jane: But there are still hurdles, and we need to figure out how secure this federation is for different teams and projects. What does this actually mean for someone just trying to run a single inference job?
Lu: It means if your team has a lot of idle Macs, you can access that collective GPU power dynamically.
Meng: I'm still worried about the complexity of the deployment pipeline. If we want this running reliably in production, that whole orchestration layer needs to be rock solid.
Tom: That’s what future work is going to focus on—extending this concept from just inference to distributed model training as well.
Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan, Sean Suchter
Apple
cs.DC, cs.LG
Submitted: 2026-10-09
Updated: 2026-10-09
Comments: 3 pages, 1 figure, 1 table
License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
Importance score: 73/100
The gist: The gist Minions presents a dynamic and distributed virtual GPU cloud that aggregates idle Apple Silicon GPUs across macOS devices to execute large-scale machine learning inference workloads,
Key concepts
- Minion Server
- This is the central coordination hub that manages all user requests via a web interface and APIs. It breaks down large tasks into smaller pieces and queues them in the database, acting as the brain of the entire system.
- Minion Executor
- These are agents running on macOS devices with Apple Silicon GPUs. They periodically check for available small tasks from the server, perform the actual GPU inference work (using models like HuggingFace transformers or Ollama), and write results back to storage.
- PostgreSQL Metadata Store
- This database acts as the system's single source of truth, storing all task information and system states. It tracks which executor is working on which subtask, enabling reliable coordination and monitoring across the distributed cloud.
- AWS S3 Storage Layer
- Instead of moving large data through the server, Minions uses Amazon S3 for input artifacts and output results. This decouples compute from storage, ensuring secure access control while allowing executors to pull necessary files directly.
Summary
The gist
Minions presents a dynamic and distributed virtual GPU cloud that aggregates idle Apple Silicon GPUs across macOS devices to execute large-scale machine learning inference workloads, enabling teams to leverage existing hardware without requiring additional GPU procurement.
System Overview and Architecture
Minions consists of four primary components: Minion Server, PostgreSQL Metadata Store, Minion Executor, and Minion Watchdog The system architecture consists of four primary components: Minion Server, PostgreSQL Metadata Store, Minion Executor, and Minion Watchdog Users or IR pipelines submit GPU inference tasks through the Minion Server The system workflow illustrates the end-to-end process of GPU inference task submission, execution, and failure recovery.
Key Components
The Minion Server serves as the central coordination layer of the system, handling all user-facing requests through a web UI and APIs Upon task submission, the Minion Server asynchronously splits a task into subtasks and enqueues them into the PostgreSQL metadata store. The Minion Executor is the primary GPU execution agent and runs on macOS devices equipped with Apple Silicon GPUs Executors periodically fetch eligible subtasks via REST APIs exposed by the Minion Server For embedding generation, Minions leverages open-source transformer models from HuggingFace. For large language model (LLM) completion workloads, Minions integrates with Ollama, an opensource framework for running LLMs locally on macOS devices. The Minion Watchdog is responsible for monitoring active subtask executions and handling executor failures.
Data Storage and Execution Model
Minions utilizes AWS S3 as the primary storage layer for GPU inference inputs and outputs Task input artifacts are read from S3 by executors, and inference results are written back to S3 upon completion. This design decouples compute from storage, avoids transferring large payloads through the Minion Server, and leverages industrystandard access control and security mechanisms. The Minion Executor uses a pull-based execution model which accommodates the inherently intermittent availability of personal devices while enabling elastic parallelism.
Subtask Acquisition and Task Binding
Minions employs an atomic subtask acquisition mechanism implemented with a dedicated table, minion subtask acquirement, that records which executor currently owns a given subtask. This approach provides a simple, low-overhead mutual exclusion mechanism using standard database constraints. Dynamic task binding allows executors to express preferences for a specific team, project, and task name These preferences are evaluated by the Minion Server as part of subtask selection logic and translated into database-level filters. By default, Minions processes inference workloads in a first-in, first-out (FIFO) order.
Observability and Operational Impact
Minions incorporates observability through Grafana-based dashboards that provide real-time visibility into system state at a team level. All observability metrics are derived from the PostgreSQL Metadata Store, which serves as the system’s source of truth. Executor-level metrics include the number of registered, online, busy, and idle executors. The operational impact shows that with Minions, GPU queue time can be reduced significantly compared to before adoption. This demonstrates that idle Apple Silicon GPUs on macOS devices can be aggregated into a dynamic, distributed virtual GPU cloud for machine learning inference.
Future work will extend Minions to support distributed model training in addition to inference. This platform points toward a novel opportunity for the machine learning community if idle macOS devices across organizations can be securely federated, they could form a massive, shared GPU resource pool that benefits the broader ecosystem. The paper concludes that Minions demonstrates that idle Apple Silicon GPUs on macOS devices can be aggregated into a dynamic, distributed virtual GPU cloud for machine learning inference.
Acknowledgments
We thank Scott Guo for peer review and helpful comments, and Matt Jockers for peer review and publication coordination.
References
[1] Hugging Face: https://huggingface.co/
[2] Ollama: https://ollama.com/
[3] PostgreSQL: https://www.postgresql.org/
[4] Grafana: https://grafana.com/
--- Page 1 ---
Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices
Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan, Sean Suchter
Apple
USA
jianhua li3@apple.com
Apple USA jianhua li3@apple.com Yun Xing Apple USA yun xing@apple.com Girisha De Silva Apple USA girisha desilva@apple.com Ryan Flint Apple USA rflint@apple.com Kai Yuan Apple USA kai yuan@apple.com Sean Suchter Apple USA ssuchter@apple.com Abstract The increasing demand for GPU-accelerated machine learning inference has exposed limitations in centralized GPU infrastructures, including high cost, limited elasticity, and long wait times under resource constraints At the same time modern Apple Silicon–based macOS devices are equipped with powerful GPUs that remain largely idle during normal usage This paper presents Minions, a dynamic and distributed virtual GPU cloud that aggregates idle Apple Silicon GPUs across macOS devices to execute large-scale machine learning inference workloads Minions enables teams to leverage existing hardware without requiring additional GPU procurement The system provides flexible GPU inference task execution, fault tolerance, and efficient resource utilization Our experience shows that idle macOS devices can be transformed into a practical distributed GPU inference platform in environments where centralized GPU resources are constrained Keywords GPU inference, distributed systems, Apple Silicon, information retrieval systems, large language models
--- Page 2 ---
Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan and Sean Suchter
Figure 1: Minions architecture overview.
Improvements for AI systems
-
Apple Silicon GPU utilization for large language model (LLM) inference will be significantly increased by dynamically aggregating
idle Apple Silicon GPUs across macOS devices to execute large-scale machine learning inference workloads.
This enables teams toleverage existing hardware without requiring additional GPU procurement.
-
Implementation of a dynamic task binding mechanism allows executors to express preferences for specific workloads, enabling them to
preferentially dequeue and execute matching subtasks, even if other tasks are ahead in the global queue.
This optimizes resource allocation based on team or project priorities. -
The system supports heterogeneous inference types by leveraging both open-source transformer models via the HuggingFace API for embedding generation and integrating Ollama for large language model (LLM) completion workloads. This allows Minions to handle both
embedding generation
andlarge language model (LLM) completion
tasks locally on the same distributed platform. -
The architecture incorporates robust fault tolerance through a Minion Watchdog that reclaims unfinished subtasks upon executor failure, ensuring
reliable task completion in the presence of ad hoc device churn.
This minimizes lost work due to intermittent availability of personal devices. -
Decoupling compute from storage by using AWS S3 as the primary storage layer for inputs and outputs simplifies data management while supporting
scalable and secure execution.
This design ensures that large payloads are handled efficiently without transferring them through the Minion Server.
Related papers
- iScheduler: Reinforcement Learning-Driven Continual Optimization for Large-Scale Resource Investment Problems
- SAMM: Sharded Automated Market Maker
- InferScale: GPU-Native KV Injection for Personalized LLM Serving
- Vigil: Accountable Liveness against Selective Silence
- Steelhead: Interleaving Partially Synchronous and Asynchronous Commit Rules on a Shared DAG
- Lightweight Scheduling Policies for Continuously Batched LLM Serving Across GPU Architectures