Technische Zusammenfassung: Hera – Erlernen der Langzeit-Koordination für kollaborative LLM-Agenten zwischen Gerät und Cloud

1. Problemstellung

Large Language Model (LLM)-Agenten haben die Fähigkeit unter Beweis gestellt, komplexe Aufgaben mit langem Zeithorizont durch autonome Interaktion mit Umgebungen zu lösen. Ihre reale Bereitstellung steht jedoch vor einem grundlegenden Dilemma zwischen Gerät und Cloud:

• Geräteseitige Einschränkungen: Modelle auf dem Gerät (typischerweise <10 Milliarden Parameter) sind effizient und haben geringe Latenz, fehlen aber oft der für komplexe Mehrschrittplanung erforderlichen Denktiefe, was zu Leistungsverschlechterung und inkohärenten Trajektorien führt.
• Cloudseitige Einschränkungen: Leistungsstarke Cloud-Modelle bieten überlegenes Denken, führen jedoch zu erheblicher Netzwerklatenz, hohen Rechenkosten und Datenschutzbedenken, was sie für Echtzeitanwendungen wie Robotik oder interaktive GUI-Navigation unpraktisch macht.

Bestehende Routing-Methoden zwischen Gerät und Cloud treffen typischerweise grobe, aufgabenbezogene Entscheidungen, indem sie eine gesamte Abfrage basierend auf geschätzter Schwierigkeit oder Zuverlässigkeit entweder dem Gerät oder der Cloud zuweisen. Dieser „Alles-oder-Nichts"-Ansatz ist für Agentenaufgaben mit langem Zeithorizont ungeeignet, bei denen die Ausführung als Folge voneinander abhängiger Schritte mit unterschiedlicher Schwierigkeit abläuft. Die Arbeit geht davon aus, dass eine feinere, schrittweise Koordinationsstrategie notwendig ist, um den Erfolg der Aufgabe und die Inferenzkosten effektiv in Einklang zu bringen.

2. Methodik: Das Hera-Framework

Die Autoren schlagen Hera vor, einen leichten schrittweisen Koordinator zwischen Gerät und Cloud, der den Kompromiss zwischen Aufgabenerfolg und Cloud-Nutzung optimiert. Hera ist ein 500-Millionen-Parameter-Decoder-only-Transformer mit einem binären Klassifikationskopf, der in jedem Interaktionsschritt $t$ entscheidet, ob der Zustand an die lokale Gerätepolitik ($\pi_{\theta_d}$) oder die Cloud-Politik ($\pi_{\theta_c}$) weitergeleitet wird.

Hera verwendet ein neuartiges zweistufiges Trainingsparadigma:

Stufe 1: Kaltstart durch Imitationslernen (IL)

Um die Routing-Politik ohne direkte Verstärkungssignale zu initialisieren, verwenden die Autoren Imitationslernen:

1. Trajektorien-Sammlung: Sowohl Geräte- als auch Cloud-Agenten werden ausgeführt, um Trajektorien für eine Reihe von Aufgaben zu generieren.
2. Filterung: Aufgaben, bei denen die Cloud das Gerät deutlich übertrifft (einen Rand $\delta$ überschreitet), werden ausgewählt, um einen Bereich zu definieren, in dem Cloud-Unterstützung notwendig ist.
3. Überwachung: Der Geräte-Agent wird auf den erfolgreichen Trajektorienzuständen der Cloud „wiedergegeben". Ein schrittweises Konsistenzlabel $y_t$ wird generiert:
   • $y_t = 1$ (Weiterleitung an die Cloud): Wenn die Aktion des Geräts $a^d_t$ von der Aktion der Cloud $a^c_t$ abweicht.
   • $y_t = 0$ (Weiterleitung an das Gerät): Wenn die Aktionen übereinstimmen.
4. Training: Der Router wird als binärer Klassifikator unter Verwendung des Binary-Cross-Entropy (BCE)-Verlusts auf diesem Datensatz trainiert, wodurch sein latenter Raum mit dem Leistungsunterschied zwischen den beiden Modellen abgeglichen wird.

Stufe 2: Kostenbewusstes Reinforcement Learning (RL) mit Zustandsgruppierung

Die IL-Stufe liefert eine Prior, optimiert jedoch nicht direkt das gemeinsame Ziel, die Rendite zu maximieren und gleichzeitig Cloud-Aufrufe zu minimieren. Hera wird mittels RL verfeinert:

1. Rollouts: Für jede Aufgabe werden mehrere Trajektorien ($N$) mit dem aktuellen Router gesammelt, wobei durch eine temperatur-skalierte Bernoulli-Verteilung Stochastik eingeführt wird, um Exploration zu fördern.
2. Zustandsgruppierung: Identische Zustände, die über verschiedene Rollouts hinweg auftreten, werden gruppiert. Für jeden eindeutigen Zustand $s$ schätzt das System:
   • $\hat{R}(d; s)$: Die erwartete Trajektorienrendite, wenn Entscheidung $d$ (Gerät oder Cloud) getroffen wird.
   • $\hat{C}(d; s)$: Die erwarteten zukünftigen Cloud-Aufrufe (einschließlich des aktuellen Schritts), wenn Entscheidung $d$ getroffen wird.
3. Präferenz-Labeling: Ein Präferenzlabel $y(s)$ wird abgeleitet, indem die Entscheidung mit der höheren geschätzten Rendite ausgewählt wird. Wenn die Renditen vergleichbar sind (innerhalb eines Rands $\epsilon$), wird die Entscheidung mit dem geringeren erwarteten zukünftigen Cloud-Verbrauch bevorzugt.
4. Optimierung: Der Router wird durch Minimierung des BCE-Verlusts auf diesen Präferenzlabels aktualisiert, ergänzt durch einen $L_2$-Regularisierungsterm, um eine übermäßige Abweichung von den durch IL initialisierten Parametern zu verhindern.

3. Hauptbeiträge

Die Arbeit beansprucht drei primäre Beiträge:

1. Erster schrittweiser Koordinator: Hera wird als erster Koordinator für Agenten zwischen Gerät und Cloud vorgestellt, der auf Schrittebene für Aufgaben mit langem Zeithorizont operiert und den Kompromiss zwischen Leistung und Kosten granularer adressiert als frühere Router auf Aufgabenebene.
2. Zweistufiges Trainingsframework: Die Autoren entwickeln eine spezifische Trainingspipeline, die Imitationslernen (für Kaltstart-Initialisierung basierend auf Aktionskonsistenz) und zustandsgruppiertes Reinforcement Learning (für gemeinsame Optimierung der Trajektorienrendite und der Cloud-Kosten) kombiniert.
3. Empirische Überlegenheit: Umfangreiche Experimente zeigen, dass Hera State-of-the-Art-Baselines übertrifft und eine stärkere Pareto-Grenze zwischen Aufgabenerfolg und Cloud-Nutzung erreicht.

4. Experimentelle Ergebnisse

Hera wurde an drei herausfordernden Benchmarks mit langem Zeithorizont evaluiert: ALFWorld (verkörperte Haushaltsaufgaben), WebShop (E-Commerce-Navigation) und AppWorld (Multi-App-Coding-Aufgaben). Das Gerätemodell war Qwen2.5-7B-Instruct, das Cloud-Modell war Qwen-Max.

Hauptergebnisse:

• Kompromiss zwischen Leistung und Kosten: Hera erreichte 92,5 % der Erfolgsrate des reinen Cloud-Ansatzes, nutzte die Cloud jedoch nur für 46,3 % der Schritte.
• Vergleich mit Baselines:
  • Auf ALFWorld erreichte Hera eine Erfolgsrate von 86,1 % bei Kosten von $4,0 \times 10^{-3}$ und übertraf damit deutlich die reine Cloud-Baseline (90,9 % Erfolg, Kosten von $11,7 \times 10^{-3}$) sowie alle anderen Routing-Baselines (z. B. RouteLLM, FrugalGPT).
  • Auf WebShop erreichte Hera 34,1 % Erfolg bei Kosten von $8,1 \times 10^{-3}$, verglichen mit 35,6 % Erfolg der reinen Cloud bei Kosten von $14,7 \times 10^{-3}$.
  • Auf AppWorld erreichte Hera 19,7 % Erfolg bei Kosten von $31,3 \times 10^{-3}$, verglichen mit 22,6 % Erfolg der reinen Cloud bei Kosten von $43,8 \times 10^{-3}$.
• Latenz: Durch die Reduzierung von Cloud-Aufrufen senkte Hera die End-to-End-Latenz erheblich (z. B. 105,5 s vs. 174,1 s auf ALFWorld), während hohe Erfolgsraten beibehalten wurden.
• Ablationsstudien: Das Entfernen der RL-Stufe führte zu niedrigeren Erfolgsraten und höherer Cloud-Nutzung. Das Entfernen der IL-Stufe führte zu instabilem Training und schlechterer Leistung, was die Notwendigkeit der zweistufigen Pipeline bestätigt.
• Mikro-Benchmarks: Die Analyse zeigte, dass Hera effektiv „kritische Schritte" identifiziert, die ein tiefes Kontexttracking oder eine komplexe Zusammensetzung von Einschränkungen erfordern, und diese an die Cloud weiterleitet, während Routine-Schritte lokal verarbeitet werden.

5. Bedeutung und Behauptungen

Die Arbeit argumentiert, dass Hera einen entscheidenden Wandel von grober, aufgabenbezogener Routing-Logik hin zu feingranularer, dynamischer Kollaboration darstellt. Ihre Bedeutung liegt in:

• Demokratisierung fortschrittlicher Agenten: Durch den Nachweis, dass nur ein kleiner Anteil kritischer Schritte Cloud-Eingriffe erfordert, senkt Hera die rechnerischen und finanziellen Barrieren für die Bereitstellung ausgefeilter Agenten auf Benutzergeräten.
• Ermöglichung von Echtzeitanwendungen: Das Framework macht latenzsensitive Anwendungen (z. B. Robotersteuerung, interaktive Assistenten) auf Gerätesoftware ohne prohibitiv hohe Kosten oder Verzögerungen realisierbar.
• Skalierbarkeit: Hera etabliert eine starke Pareto-Grenze für Leistung und Kosten und deutet auf einen gangbaren Weg hin zu skalierbaren, nachhaltigen und allgegenwärtigen autonomen Agenten in realen Umgebungen, in denen Ressourcenbeschränkungen von größter Bedeutung sind.

Die Autoren weisen auf Einschränkungen hin, darunter die Annahme einer synchronen, zuverlässigen Konnektivität und das Fehlen integrierter Datenschutzmechanismen für ausgelagerte Daten, und identifizieren diese als Bereiche für zukünftige Forschung.