Apple-Forscher beschreiben Minions als System, das Inferenzaufgaben auf freie Apple-Silicon-GPUs in Macs mit macOS verteilt. PostgreSQL regelt dabei, welcher Rechner eine Unteraufgabe übernimmt; ein Watchdog gibt unerledigte Arbeit nach einem Ausfall wieder frei. Das am 9. Oktober 2026 datierte Paper beschreibt zwei Einsatzbereiche: Embeddings mit unterstützten Transformer-Modellen von Hugging Face und Textvervollständigung mit großen Sprachmodellen über Ollama. Tom’s Hardware berichtet, Apple nutze Minions intern als zusätzliche Kapazität bei Engpässen mit zentralen GPUs.
Was Minions mit freien Macs erledigt
Minions bündelt ungenutzte GPU-Kapazität mehrerer Apple-Silicon-Macs für maschinelles Lernen. Das System verteilt eingereichte Jobs in kleinere Unteraufgaben, die einzelne Rechner lokal ausführen. Die beschriebenen Anwendungen sind die Erzeugung von Embeddings mit unterstützten Hugging-Face-Transformer-Modellen sowie LLM-Textvervollständigung über Ollama auf den beteiligten Macs.
Damit wird Arbeit auf mehrere Rechner verteilt: Minions weist jedem Executor eine Unteraufgabe zu, die dieser lokal bearbeitet. Die Beschreibung handelt von verteilten Inferenzjobs, nicht davon, dass mehrere Macs gemeinsam die Gewichte eines einzelnen Modells ausführen.
Wie PostgreSQL Aufgaben eindeutig zuweist
Der Minion Server prüft eingereichte Jobs und zerlegt sie in Unteraufgaben. Ein Minion Executor fragt diese über REST-Schnittstellen ab, lädt bei Bedarf Eingaben und ein Modell herunter und führt die Inferenz auf dem Apple-Silicon-Grafikprozessor aus. Die Ergebnisse gehen in einen konfigurierbaren Objektspeicher; das Paper nennt AWS S3 als Beispiel.
PostgreSQL verwaltet den Aufgabenstatus und die Zuweisungen. Für jede Unteraufgabe legt das System einen eindeutigen Eintrag anhand von Team, Projekt, Aufgabenname und Unteraufgaben-ID an. Diese Eindeutigkeitsregel lässt nur einen Executor als Eigentümer der jeweiligen Unteraufgabe zu. So koordiniert Minions die Arbeit über eine gemeinsame Aufgabenverwaltung, statt eine zentrale Scheduler-Instanz vorauszusetzen.
Was bei einem nicht erreichbaren Executor passiert
Die Executor-Rechner senden im Abstand von fünf Minuten Lebenszeichen. Ein Minion Watchdog überwacht aktive Aufgaben. Antwortet ein Executor nicht mehr – etwa bei einem Netzwerkausfall, im Ruhezustand oder nach dem Ausschalten –, gibt das System seine unerledigte Unteraufgabe wieder frei, damit ein anderer Executor sie übernehmen kann.
Welche Betriebsdaten Teams sehen
Grafana-Dashboards greifen auf Kennzahlen aus PostgreSQL zu. Sie zeigen etwa, wie viele Executor-Rechner registriert, online, beschäftigt oder frei sind. Für Aufgaben lassen sich aktive, abgeschlossene und fehlgeschlagene Jobs sowie der jeweilige Inferenztyp erfassen. Damit bildet die Übersicht sowohl verfügbare Rechenkapazität als auch den Bearbeitungsstand ab.
Für Bereitstellungen auf Team- oder Organisationsebene beschreibt das Paper getrennte PostgreSQL-Datenbanken und separate Executor-Pools als Ansatz, um Vertraulichkeitsanforderungen zu berücksichtigen.
Was die gemeldeten Wartezeiten aussagen
Die Apple-Forscher berichten, dass manche Inferenzjobs zuvor mehr als zehn Stunden auf GPU-Kapazität warteten und mit Minions häufig innerhalb weniger Minuten starten konnten. Diese Beobachtung betrifft die Wartezeit bis zum Beginn der Ausführung; sie beschreibt nicht, wie schnell ein Modell anschließend rechnet.
Der beschriebene Einsatzbereich
Minions verteilt derzeit die genannten Inferenzaufgaben. Verteiltes Modelltraining führen die Autoren als künftige Erweiterung auf. Auch eine gemeinsame Nutzung von Macs über Organisationsgrenzen hinweg beschreiben sie als mögliche Zukunftsrichtung, sofern sich Geräte sicher föderieren lassen.
