💻 computer science

OpenJarvis: Personal AI, On Personal Devices

OpenJarvis führt eine dekomponierte, typisierte persönliche KI-Architektur ein, die eine von LLMs geführte Spezifikationssuche nutzt, um fünf unabhängige Primitive zu optimieren, wodurch On-Device-Systeme Cloud-Level-Genauigkeit erreichen und gleichzeitig API-Kosten sowie Latenz drastisch reduzieren.

Ursprüngliche Autoren: Jon Saad-Falcon, Avanika Narayan, Robby Manihani, Tanvir Bhathal, Herumb Shandilya, Hakki Orhun Akengin, Gabriel Bo, Andrew Park, Matthew Hart, Caia Costello, Chuan Li, Christopher Ré, Azalia Mirhosei

Veröffentlicht 2026-05-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Jon Saad-Falcon, Avanika Narayan, Robby Manihani, Tanvir Bhathal, Herumb Shandilya, Hakki Orhun Akengin, Gabriel Bo, Andrew Park, Matthew Hart, Caia Costello, Chuan Li, Christopher Ré, Azalia Mirhoseini

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten einen brillanten, weltklasse persönlichen Assistenten, der in der Cloud lebt. Er ist unglaublich intelligent, kann komplexe Probleme lösen und Ihre sensiblen Daten (wie E-Mails, Kalender und Gesundheitsakten) verarbeiten, indem er sie an einen riesigen Server-Farm sendet. Das funktioniert gut, kostet aber jeden Monat viel Geld, erfordert eine Internetverbindung und bedeutet, dass Sie Ihr privates Tagebuch einem Fremden zum Lesen übergeben.

Stellen Sie sich nun vor, Sie möchten, dass derselbe Assistent in Ihrem eigenen Laptop oder Telefon lebt. Sie wollen, dass er privat ist, keine monatlichen Gebühren kostet und auch dann funktioniert, wenn Sie im Flugzeug ohne WLAN sind.

Das Problem ist, dass es, wenn Sie einfach das „Gehirn" des Cloud-Assistenten (ein leistungsfähiges KI-Modell) nehmen und versuchen, es auf Ihrem Telefon laufen zu lassen, abstürzt. Es ist, als würde man versuchen, einen Formel-1-Rennwagen-Motor in eine Kompaktlimousine einzubauen; das Auto wurde nicht für diesen Motor gebaut. Das Fahrwerk, das Kraftstoffsystem und die Lenkung des Autos (der Software-Stack) sind alle auf den kleineren Motor abgestimmt. Wenn Sie den Motor tauschen, ohne den Rest des Autos zu ändern, fällt es auseinander.

Dies ist das Kernproblem, das die Arbeit „OPENJARVIS" löst.

Das Problem: Das Versagen des „Motortauschs"

Die Forscher führten ein einfaches Experiment durch: Sie nahmen bestehende persönliche KI-Systeme (wie OpenClaw oder Hermes Agent) und tauschten einfach das Cloud-Gehirn gegen ein lokales aus (ein kleineres KI-Modell, das auf Ihrem Gerät läuft).

Das Ergebnis? Das System wurde schrecklich. Die Genauigkeit sank um 25–39 %.
Warum? Weil die „Anweisungen", „Werkzeuge" und „Speichereinstellungen" alle speziell für das riesige Cloud-Gehirn geschrieben wurden. Wenn Sie ein lokales Gehirn einsetzen, wird es durch Anweisungen verwirrt, für die es nicht ausgelegt war.

Die Lösung: Der „LEGO-Bauplan" (die Spezifikation)

Die Autoren erkannten, dass man nicht einfach das Gehirn tauschen kann; man muss das ganze Auto umgestalten, damit es zum neuen Motor passt. Um dies zu tun, schufen sie OPENJARVIS.

Stellen Sie sich OPENJARVIS als einen universellen LEGO-Bauplan (eine „Spezifikation") vor. Anstatt einen chaotischen, verwickelten Knoten aus Code zu haben, zerlegten sie das persönliche KI-System in fünf verschiedene, austauschbare LEGO-Blöcke:

Intelligenz: Das Gehirn (das KI-Modell).
Motor: Der Motor und das Getriebe des Autos (wie das Modell läuft).
Agenten: Die Logik des Fahrers (wie es denkt und entscheidet).
Werkzeuge & Speicher: Die Karte und die Werkzeugkiste (wie es auf Dateien und das Internet zugreift).
Lernen: Der Mechaniker (wie das System sich selbst verbessert).

Da dies separate Blöcke sind, können Sie den „Intelligenz"-Block gegen ein lokales Modell austauschen und dann die anderen vier Blöcke so abstimmen, dass sie perfekt dazu passen. Es ist, als würde man einen Rennwagen-Motor nehmen und das Fahrwerk, die Reifen und das Kraftstoffgemisch speziell für diesen Motor anpassen, anstatt zu versuchen, ihn in eine Limousine zu zwingen.

Der Zaubertrick: Die „Lehrer-Schüler"-Suche

Selbst mit den LEGO-Blöcken ist ein lokales Gehirn immer noch weniger intelligent als ein Cloud-Gehirn. Wie macht man das lokale so leistungsfähig wie das Cloud-Gehirn?

Sie entwickelten eine Methode namens LLM-gesteuerte Spezifikationssuche. Stellen Sie sich eine Lehrer-Schüler-Beziehung vor:

Der Schüler: Die lokale KI, die auf Ihrem Gerät läuft.
Der Lehrer: Eine supersmartes Cloud-KI (wie die, für die Sie bezahlen).

So arbeiten sie zusammen:

Der Test: Der Schüler versucht, eine Aufgabe zu erledigen und scheitert.
Die Diagnose: Der Lehrer betrachtet das Scheitern und sagt: „Ah, Sie sind gescheitert, weil Sie das Kalender-Werkzeug nicht korrekt verwendet haben", oder „Sie müssen Ihre Denk-Schritte ändern."
Die Bearbeitung: Der Lehrer gibt nicht nur die Antwort; er schreibt den LEGO-Bauplan um. Er könnte sagen: „Beschreibung des Werkzeugs ändern", „Speichereinstellungen anpassen" oder „Parameter des Gehirns justieren."
Der Torhüter: Eine strenge Regel prüft: „Hat diese Änderung den Schüler verbessert, ohne ihn in anderen Bereichen schlechter zu machen?" Wenn ja, wird die Änderung akzeptiert. Wenn nein, wird sie abgelehnt.
Das Ergebnis: Der Schüler lernt und verbessert seinen Bauplan.

Entscheidend: Der Lehrer hilft nur während der „Suche"-Phase (der Einrichtung). Sobald der Bauplan perfektioniert ist, läuft der Schüler vollständig auf Ihrem Gerät ohne einzige Cloud-Anfrage. Der Cloud-Lehrer verschwindet, und Sie bleiben mit einem hochoptimierten, privaten, lokalen Assistenten zurück.

Die Ergebnisse: Privat, Schnell und Günstig

Die Arbeit testete dies an 8 verschiedenen realen Aufgaben (Programmieren, Recherche, Terminplanung usw.). Hier ist, was sie fanden:

Leistung: Die optimierten lokalen Assistenten schnitten fast genauso gut ab wie die teuren Cloud-Varianten. Bei 4 von 8 Tests war die lokale Version tatsächlich besser oder gleichwertig. Im Durchschnitt waren sie nur 3,2 % weniger genau als das beste Cloud-Modell.
Kosten: Da das lokale Modell auf Ihrer eigenen Hardware läuft, sanken die Kosten pro Abfrage um etwa das 800-fache. Sie hören auf, das monatliche Abonnement zu bezahlen.
Geschwindigkeit: Die lokale Version war 4-mal schneller, weil sie nicht warten musste, bis Daten zur Cloud und zurück reisten.
Datenschutz: Ihre Daten verlassen Ihr Gerät während der normalen Nutzung nie.

Zusammenfassung

OPENJARVIS ist eine neue Art, persönliche KI zu bauen. Anstatt eine lokale KI zu zwingen, wie eine Cloud-KI zu funktionieren, zerlegt es das System in Teile und nutzt einen „Lehrer", um diese Teile speziell für die lokale Hardware neu zu gestalten. Das Ergebnis ist eine persönliche KI, die in Ihrer Tasche lebt, Ihre Geheimnisse bewahrt, fast nichts kostet, um sie laufen zu lassen, und fast so intelligent ist wie die teuren Cloud-Riesen.

Technische Zusammenfassung: OPENJARVIS – Eine dekomponierte, end-to-end optimierbare persönliche KI-Stack

1. Problemstellung

Persönliche KI-Stacks (z. B. OpenClaw, Hermes Agent) sind zu einem zentralen Bestandteil täglicher Arbeitsabläufe geworden, verlassen sich jedoch derzeit fast ausschließlich auf in der Cloud gehostete Frontier-Modelle. Diese Architektur wirft vier kritische Probleme auf:

Datenschutz: Abfragen enthalten häufig sensible lokale Daten, die an Server Dritter weitergeleitet werden.
Kosten: Wiederkehrende API- und Abonnementkosten belaufen sich für intensive Nutzer auf Tausende von Dollar pro Jahr.
Abhängigkeit: Nutzer besitzen keine Kontrolle über die Modelle und benötigen eine ständige Netzwerkanbindung.
Energieverbrauch: Cloud-Inferenz verbraucht pro Token um Größenordnungen mehr Energie als die lokale Ausführung.

Während Consumer-Hardware mittlerweile Open-Weight-Modelle (1–128 Milliarden Parameter) unterstützt, die bei persönlichen KI-Aufgaben nur 6–12 Monate hinter Frontier-Modellen zurückliegen, scheitert ein einfacher Ersatz eines lokalen Modells in einem bestehenden, für die Cloud konzipierten Stack. Experimente zeigen, dass das Ersetzen eines Cloud-Modells (z. B. Claude Opus 4.6) durch ein lokales Modell (z. B. Qwen3.5-9B) innerhalb von Frameworks wie OpenClaw oder Hermes Agent zu einem Abfall der Genauigkeit um 25–39 Prozentpunkte (pp) führt.

Die Ursache liegt darin, dass bestehende Stacks monolithisch sind: Agenten-Prompts, Tool-Beschreibungen, Speicher-Konfigurationen und Laufzeit-Einstellungen sind gemeinsam entworfen und für spezifische Cloud-Modelle fusioniert. Aktuelle Optimierungsmethoden (z. B. Prompt-Optimierer wie GEPA oder DSPy) können lediglich das Prompt-Primitive feinabstimmen und schließen nur 5 pp der Lücke. Die Optimierung eines einzelnen Primitives isoliert kann die Fehlausrichtung im gesamten Stack nicht beheben.

2. Methodik: Die OPENJARVIS-Architektur

Um lokale Modelle in die Lage zu versetzen, mit Cloud-Systemen zu konkurrieren, schlagen die Autoren OPENJARVIS vor, eine Architektur, die persönliche KI-Systeme in fünf typisierte, unabhängig bearbeitbare Primitives zerlegt.

2.1 Die Spec-Abstraktion

OPENJARVIS repräsentiert ein persönliches KI-System als eine typisierte Spezifikation (Spec), die aus fünf Primitives besteht:

Intelligence: Die Architektur des Sprachmodells, die Gewichte und die Generierungsparameter.
Engine: Die Inferenz-Laufzeit, der Hardware-Ausführungspfad, das Batching und die Quantisierungseinstellungen.
Agents: Die Denk-Schleife, Prompts und Richtlinien für die Tool-Nutzung.
Tools & Memory: Externe Schnittstellen, Abrufmechanismen und persistenter Benutzerzustand.
Learning: Der Optimierer, der das System aus Verläufen aktualisiert (z. B. LoRA, Prompt-Optimierer oder der vorgeschlagene Suchalgorithmus).

Diese Dekomposition ermöglicht es, den gesamten Stack als ein einziges optimierbares Objekt zu behandeln und jede Komponente als Freiheitsgrad offenzulegen.

2.2 LLM-gesteuerte Spec-Suche

Der zentrale Optimierungsalgorithmus ist die LLM-gesteuerte Spec-Suche, eine lokale-Cloud-Kollaboration, die die vier bearbeitbaren Primitives (Intelligence, Engine, Agents, Tools & Memory) gemeinsam optimiert, während das Learning-Primitive den Prozess steuert.

Suchzeit (Cloud): Ein Frontier-Cloud-Modell (der „Lehrer") fungiert als reflektierender Vorschlagsgenerator. Es analysiert Ausführungsverläufe der aktuellen lokalen Spec, diagnostiziert Fehlercluster (z. B. „der Schüler scheitert bei mehrstufigen Kalenderabfragen") und schlägt koordinierte Änderungen über mehrere Primitives hinweg gleichzeitig vor (z. B. das Umschreiben einer Tool-Beschreibung und die Anpassung einer Laufzeit-Einstellung).
Inferenzzeit (Lokal): Die resultierende optimierte Spec läuft vollständig auf dem Gerät. Das Cloud-Modell ist an der Inferenz nicht beteiligt.
Das Gate: Um eine Verschlechterung zu verhindern, akzeptiert ein „Gate"-Mechanismus eine Änderung nur, wenn sie die Leistung bei einem spezifischen Fehlercluster verbessert, ohne unakzeptable Regressionen (definiert durch eine Toleranz $\epsilon$ ) bei anderen Clustern zu verursachen.
Gemeinsame Optimierung: Im Gegensatz zu Single-Primitive-Optimierern ermöglicht diese Methode, dass eine einzelne Änderung mehrere Primitives umfasst und gekoppelte Effekte erfasst (z. B. das Aktualisieren von Modellgewichten, um einer neuen Prompt-Struktur zu entsprechen).

3. Hauptbeiträge

OPENJARVIS-Architektur: Ein neuartiges Framework, das persönliche KI in fünf typisierte Primitives zerlegt und den Stack end-to-end optimierbar sowie messbar hinsichtlich Genauigkeit, Kosten und Latenz macht.
LLM-gesteuerte Spec-Suche: Ein Suchalgorithmus, der Frontier-Cloud-Modelle nutzt, um bei der Suche Änderungen an lokalen Specs vorzuschlagen, und dabei die Lücke in der Genauigkeit zwischen lokal und Cloud um 13–32 pp schließt, bei 7–11× niedrigeren Optimierungskosten als Single-Primitive-Baselines.
Pareto-optimale lokale Konfigurationen: Empirische Belege zeigen, dass optimierte On-Device-Specs die Cloud-Genauigkeit bei 4 von 8 Benchmarks erreichen oder übertreffen können, während die marginalen API-Kosten um ~800× und die End-to-End-Latenz um das 4-Fache reduziert werden.
Umfassende Analyse: Eine Ablationsstudie, die zeigt, dass die Gewinne sowohl vom Vorschlagsgenerator (LLM-Diagnose vs. evolutionäre/zufällige Suche) als auch vom Bewegungsbereich (Optimierung aller vier Primitives vs. nur eines) stammen.

4. Experimentelle Ergebnisse

Die Autoren evaluierten OPENJARVIS über 8 Benchmarks (einschließlich PinchBench, GAIA, LiveCodeBench und DeepResearchBench), 11 lokale Modelle aus 4 Familien und 7 Hardware-Plattformen.

Wiederherstellung der Portabilität: Ein einfacher Austausch eines lokalen Modells in einem Cloud-Framework senkt die Genauigkeit um 24–39 pp. Die Verwendung der OPENJARVIS-Spec mit demselben lokalen Modell stellt 56–77% dieses Abfalls wieder her und reduziert die verbleibende Lücke auf 5,6–16,5 pp.
Genauigkeit vs. Cloud: Die beste einzelne On-Device-Spec (Qwen3.5-122B) erreicht eine durchschnittliche Genauigkeit von 80,3%, was nur 3,2 pp unter der besten Cloud-Baseline (Claude Opus 4.6 bei 83,5%) liegt. Bei 4 von 8 Benchmarks erreicht oder übertrifft das beste lokale Modell die Cloud-Leistung.
Effizienzgewinne: Lokale Konfigurationen bieten eine ~800× Reduktion der marginalen API-Kosten und eine 4-fache Reduktion der End-to-End-Latenz im Vergleich zu Cloud-Baselines.
Wirksamkeit der Suche:
- Die LLM-gesteuerte Spec-Suche verbesserte lokale Modelle um 13–32 pp über die Benchmarks hinweg.
- Die Erweiterung des bearbeitbaren Sets von nur Prompts auf alle vier Primitives fügte 5,5–16,5 pp hinzu.
- Die Verwendung eines LLM-Lehrers zur Fehlerdiagnose brachte im Vergleich zur evolutionären Suche bei gleichem Bewegungsbereich 10,0 pp mehr.
- Akzeptierte Änderungen verteilten sich über alle Primitives: Intelligence (16–44%), Agents, Tools und Engine, was bestätigt, dass keine einzelne Komponente die Optimierung dominiert.

5. Bedeutung und Behauptungen

Die Arbeit behauptet, dass lokale persönliche KI mehr als nur einen Modellersatz erfordert; sie benötigt einen portablen, messbaren und optimierbaren Stack. OPENJARVIS zeigt, dass:

Lokal-Cloud-Parität erreichbar ist: Mit der richtigen Architektur können On-Device-Systeme die Frontier-Cloud-Leistung annähern, ohne lokale Eigenschaften (Datenschutz, Kosten, Eigentum) aufzugeben.
Dekomposition der Schlüssel ist: Die Leistungslücke ist architektonisch bedingt, nicht nur durch Fähigkeiten begrenzt. Indem die Annahmen von für die Cloud entworfenen Stacks als bearbeitbare Primitives offengelegt werden, können lokale Modelle neu konfiguriert werden, um ihren Stärken zu entsprechen.
Hybride Suche effizient ist: Die Nutzung von Cloud-Modellen nur für die Such-Phase (Diagnose und Vorschlag) und das Ausführen der optimierten Spec lokal zur Inferenz-Zeit überträgt Frontier-Fähigkeiten auf lokale Geräte ohne persistente Cloud-Abhängigkeit.

Die Autoren betonen, dass die resultierenden lokalen Specs zur Inferenzzeit keine Cloud-Aufrufe tätigen. Während die Suchphase einmalige Kosten verursacht (nach sechs Monaten Nutzung auf <0,001 $ pro Anfrage amortisiert), verschiebt sich das Betriebsmodell von einem wiederkehrenden Cloud-Abonnement zu einer einmaligen Optimierung gefolgt von lokaler Ausführung.

Von den Autoren festgestellte Einschränkungen:

Die statistische Präzision ist durch 5 unabhängige Durchläufe pro Konfiguration begrenzt.
Potenzielle Verzerrungen durch den LLM-Richter (Verwendung von GPT-5-mini) könnten Ausgaben der GPT-Familie begünstigen.
Die Evaluation ist derzeit auf Single-Machine-Bereitstellungen beschränkt.
Einige Cloud-Baselines zeigten aufgrund von Tool-Integrationsproblemen im Evaluierungsrahmen unerwartet niedrige Scores.