🤖 AI

Arbor: Tree Search as a Cognition Layer for Autonomous Agents

Arbor ist ein Multi-Agenten-Framework, das eine strukturierte Baumsuche als Kognitionsschicht einführt, um eine autonome, koordinierte Optimierung über komplexe, zustandsbehaftete Aktionsräume hinweg zu ermöglichen, wobei signifikante Leistungssteigerungen bei der Full-Stack-LLM-Inferenz durch die Aufrechterhaltung eines gemeinsamen Arbeitsgedächtnisses von Hypothesen und die Anwendung einer Checks-and-Balances-Architektur zwischen Orchestrator- und Critic-Agenten erzielt werden.

Ursprüngliche Autoren: Neha Prakriya, Chaojun Hou, Zheng Gong, Huasha Zhao, Xi Zhao, Mou Li, Zhenyu Gu, Emad Barsoum

Veröffentlicht 2026-06-12

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Neha Prakriya, Chaojun Hou, Zheng Gong, Huasha Zhao, Xi Zhao, Mou Li, Zhenyu Gu, Emad Barsoum

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 versuchen, ein massives, komplexes Rennauto so schnell wie möglich abzustimmen. Das Auto hat einen Motor, ein Getriebe, Reifen, Aerodynamik und ein Computersystem. Wenn Sie nur die Reifen optimieren, machen Sie das Auto vielleicht schneller, aber Sie könnten auch dazu führen, dass der Motor überhitzt oder das Getriebe rutscht.

Arbor ist ein neues „Super-Coach“-System, das darauf ausgelegt ist, diese komplexen Computersysteme (speziell KI-Modelle, die auf Computerchips laufen) zu optimieren, ohne dass ein menschliches Team jeden einzelnen Teil mikromanagen muss.

So funktioniert es, unter Verwendung einfacher Analogien:

1. Das Problem: Der „blinde Fleck“ früherer Systeme

Vor Arbor waren KI-Optimierungswerkzeuge wie Mechaniker, die nur einen Teil des Autos zur Zeit betrachteten. Wenn sie den Motor verbesserten, prüften sie nicht, ob der neue Motor das Getriebe beschädigte. Sie arbeiteten isoliert.

Das Problem: In der realen KI führt das Beheben einer Schicht (wie dem Softwarecode) oft dazu, dass eine andere Schicht (wie die Hardware-Kommunikation) beschädigt wird. Frühere Systeme konnten diese „Domino-Effekte“ nicht sehen und stürzten ab oder gaben auf, wenn etwas schiefging.

2. Die Lösung: Ein „Baum der Ideen“ (Die Kognitionsebene)

Arbor probiert nicht einfach nur etwas aus und macht dann weiter. Es baut einen riesigen, lebendigen Baum der Ideen.

Der Baum: Stellen Sie sich einen Stammbaum vor, aber statt Vorfahren ist es eine Karte von jedem Versuch, das System schneller zu machen.
Die Zweige: Jedes Mal, wenn das System eine Änderung vornimmt, wächst ein neuer Zweig.
- Wenn die Änderung funktioniert, bleibt der Zweig grün.
- Wenn sie fehlschlägt, wird der Zweig rot, aber das System löscht ihn nicht. Stattdessen hinterlässt es eine Notiz an diesem Zweig, die erklärt, warum er fehlgeschlagen ist.
Das Gedächtnis: Dieser Baum ist das „gemeinsame Gedächtnis“ des Systems. Es erinnert sich daran, dass „das Ändern der Reifengröße dazu führte, dass der Motor überhitzte“, sodass es diese Kombination nicht noch einmal versucht. Dies ermöglicht es dem System, in Echtzeit aus seinen Fehlern zu lernen.

3. Das Team: Eine „Checks and Balances“-Crew

Arbor nutzt ein Team aus drei spezialisierten KI-Agenten, die wie eine gut geführte Ingenieursfirma agieren:

Der Orchestrator (Der Projektmanager): Dieser Agent ist der Fahrer. Er betrachtet den gesamten Baum, erkennt den größten Engpass (den Teil, der das Auto am meisten ausbremst) und sagt: „Lass uns versuchen, den Motor zu reparieren!“ Er delegiert die eigentliche Arbeit an die Experten.
Die Domänen-Spezialisten (Die Mechaniker): Dies sind keine festen Roboter, sondern „On-Demand“-Experten. Wenn der Projektmanager den Motor reparieren muss, erstellt er sofort einen „Kernel-Spezialisten“. Wenn er das Getriebe reparieren muss, erstellt er einen „Compiler-Spezialisten“. Sie leisten die tiefgehende, technische Arbeit.
Der Kritiker (Der Sicherheitsinspektor): Dies ist das wichtigste neue Feature. Der Kritiker beobachtet alles, was der Projektmanager tut.
- Wenn der Projektmanager eine riskante Änderung versucht, die das gesamte System zum Absturz bringen könnte, stoppt der Kritiker ihn.
- Wenn eine Änderung zu einem Absturz führt, führt der Kritiker eine „Ursachenanalyse“ (Root Cause Analysis) durch (wie ein Detektiv), um genau herauszufinden, was kaputtgegangen ist, und schreibt eine Regel, damit niemand diesen Fehler erneut begeht.
- Das Gleichgewicht: Der Projektmanager will schnell fahren; der Kritiker will sicher bleiben. Sie müssen sich einigen, bevor eine Änderung übernommen wird. Dies verhindert, dass das System irreparabel beschädigt wird.

4. Wie es lernt: „Re-Profiling“

Während das System Änderungen vornimmt, verschieben sich die „Verkehrsstaus“ (Engpässe).

Analogie: Stellen Sie sich vor, Sie lösen einen Stau auf der Hauptstraße auf. Plötzlich verlagert sich der Stau in die 2. Avenue.
Arbors Vorgehen: Nach jeder Serie von Änderungen hält Arbor inne und macht eine neue „Momentaufnahme“ (Profiling) des Systems. Es sieht, dass sich das Problem verlagert hat, und lässt daraufhin neue Zweige auf seinem Baum wachsen, um den neuen Problembereich zu erforschen. Es bleibt nicht stecken, indem es versucht, immer wieder dasselbe alte Problem zu lösen.

5. Die Ergebnisse: Geschwindigkeit und Stabilität

Das Paper testete dies auf AMD-Computerchips, die große KI-Modelle ausführen.

Der Solo-Agent: Als sie versuchten, dies mit nur einem KI-Agenten zu tun (oh,ne den Kritiker oder den Baum), erzielte dieser zwar kleine Verbesserungen, stürzte dann aber ab und konnte sich nicht mehr erholen.
Das Arbor-Team: Mit dem vollständigen Team und dem Baum erzielte es massive Geschwindigkeitssteigerungen – bis zu 193 % schneller als die Standardeinstellungen.
Zuverlässigkeit: Das System war so stabil, dass die Ergebnisse bei zweimaligem Durchlauf nahezu identisch waren (innerhalb von 2 %), was beweist, dass es nicht nur Glück war.

Zusammenfassung

Arbor ist wie ein autonom fahrendes Rennteam, das eine Karte von jedem Kurs erstellt, den es nimmt. Es hat einen Fahrer, der nach Geschwindigkeit drängt, einen Sicherheitsinspektor, der Unfälle verhindert, und einen Mechaniker, der spezifische Teile repariert. Indem es eine detaillierte Karte dessen führt, was funktionierte und was scheiterte, kann es komple durch, vielschichtige Computersysteme navigieren, um die schnellstmögliche Leistung zu finden, ohne das Auto zu beschädigen.

Technisches Resümee: Arbor – Baumsuche als Kognitionsebene für autonome Agenten

Problemstellung

Jüngste Fortschritte in der LLM-basierten Code-Optimierung haben gezeigt, dass autonome Agenten in der Lage sind, hochwertige Lösungen für isolierte Rechenziele (z. B. einzelne Kernel oder spezifische Operatoren) zu finden. Die Performance von Produktionssoftware resultiert jedoch aus dem komplexen Zusammenspiel mehrerer Schichten (Anwendung, Framework, Compiler, Kernel, Hardware). Die Optimierung einer Schicht führt oft dazu, dass Engpässe oder Regressionen in einer anderen Schicht aufgedeckt werden, was einen zustandsbehafteten, großen Aktionsraum schafft, in dem Interventionen bereits erzielte Fortschritte ungültig machen können.

Bestehende Ansätze stehen vor drei primären Einschränkungen:

Isolierter Umfang: Compiler-Autotuner und Multi-Agenten-Frameworks operieren typischerweise innerhalb einer einzelnen Schicht oder auf einem einzelnen Ziel und versäumen es, die Abhängigkeiten über verschiedene Schichten hinweg zu adressieren.
Mangel an zustandsbehaftetem Gedächtnis: Aktuelle Systeme unterhalten kein gemeinsames Arbeitsgedächtnis, das sich mit jeder Messung weiterentwickelt; sie behandeln Fehler lediglich als Stoppsignale statt als diagnostische Daten.
Unfähigkeit zum Umgang mit kaskadierenden Fehlern: Wenn eine Optimierung zu einem Systemabsturz oder einer Regression führt, fehlt es bestehenden Systemen an Mechanismen, um die Ursache zu diagnostizieren, die Constraints zurück an die Suche zu propagieren und die anschließende Exploration neu zu gestalten.

Die Kernherausforderung verschiebt sich von der Generierung von Kandidaten zur Selektion von Kandidaten: die Navigation durch eine dynamische Landschaft, in der jede Intervention die Verteilung der Engpässe verändert, was ein System erfordert, das Verschiebungen erkennen, Fehler über alle Schichten hinweg diagnostizieren und die Suchfront autonom erweitern kann.

Methodik: Das Arbor-Framework

Arbor formuliert die Full-Stack-Performance-Optimierung als eine heuristisch bewertete Baumsuche über einen dynamisch expandierenden Aktionsraum. Es führt eine Kognitionsebene ein, die einen expliziten Suchbaum als gemeinsames Arbeitsgedächtnis für die Agenten verwaltet.

1. Suchverfahren und Zustandsverwaltung

Baumstruktur: Der Optimierungszustand ist ein Baum $T = (V, E)$ , dessen Wurzel ein profiliertes Baseline-Szenario ist. Jeder Knoten repräsentiert eine Aktion und deren Ergebnis (beibehalten, rückgängig gemacht oder abgestürzt). Der Pfad von der Wurzel zum Knoten definiert die kumulative Sequenz der Interventionen.
Dynamische Expansion: Der Baum ist nicht statisch. Nach einer erfolgreichen Aktion re-profilt das System den Zustand, um zuvor unsichtbare Engpässe aufzudecken, wodurch neue Zweige entstehen, die bei der Initialisierung noch nicht existierten.
Suchschleife: Der Orchestrator führt eine Tiefensuche (Depth-First) aus:
1. Profilierung des aktuellen Zustands zur Identifizierung von Engpässen und GPU-Zeitanteilen.
2. Bewertung von Kandidaten-Aktionen mittels einer Heuristik-Funktion.
3. Versendung der am höchsten bewerteten Aktion an einen Domänen-Spezialisten.
4. Kontrolle der Ergebnisse durch Genauigkeitsverifizierung und End-to-End-Benchmarking.
5. Aktualisierung des Baums: Beibehaltene Aktionen werden zur neuen Baseline; rückgängig gemachte Aktionen erfassen diagnostische Annotationen; Abstürze lösen eine Ursachenanalyse (Root-Cause Analysis) aus.
6. Neu-Bewertung der verbleibenden Kandidaten, sobald sich die Verteilung der Engpässe verschiebt.

2. Heuristische Bewertung

Kandidaten werden bewertet, indem der erwartete Gewinn gegen Kosten und Risiko abgewogen wird, wobei ein Explorationsbonus einfließt:
$h(a) = \frac{g(a)}{c(a) \cdot (1 - r_{acc}) \cdot (1 - r_{crash}) \cdot m_{gap}} + C_s \frac{\ln N}{1 + n_{cat}}$

$g(a)$ : Erwarteter Gewinn, geschätzt aus dem GPU-Zeitanteil des Ziel-Kernels und kategorie-spezifischen Speedup-Priors (abgeleitet aus einer persistenten Wissensdatenbank).
$c(a)$ : Geschätzte Wanduhrzeit-Kosten (Implementierung, Neustart, Benchmarking).
$r_{acc}, r_{crash}$ : Empirische Fehlerraten für Genauigkeit und Abstürze, die im Verlauf der Kampagne verfeinert werden.
$m_{gap}$ : Dringlichkeitsmultiplikator, der mit der verbleibenden Lücke zum Durchsatzziel skaliert.
UCB-Term: Fördert die Exploration unterrepräsentierter Aktionskategorien.

3. Multi-Agenten-Architektur mit Checks und Balances

Arbor strukturiert seine Agenten so, dass sie effektive Engineering-Organisationen nachahmen, indem es Fähigkeiten in Hard Skills (Domänenexpertise) und Soft Skills (Koordinationsprotokolle) unterteilt.

Der Orchestrator (Der „Tech Lead“):
- Steuert die Optimierungsschleife durch Profilierung, Bewertung und Delegation.
- Konstruiert Domänen-Spezialisten dynamisch zur Laufzeit für spezifische Aufgaben (Kernel, Framework, Kommunikation, Compiler, Dispatch).
- Komponiert Prompts unter Verwendung von Hardware-Kontext, Einträgen aus der Wissensdatenbank und der Fehlerhistorie.
- Implementiert selbst keinen Code, sondern entscheidet, was zu versuchen ist und wer es implementiert.
Der Critic (Die „Qualitätssicherung“):
- Schützt die Stabilität und die Integrität der Messungen.
- Führt eine Ursachenanalyse (Root-Cause Analysis, RCA) bei Abstürzen durch, um zwischen Implementierungsfehlern und unproduktiven Richtungen zu unterscheiden.
- Setzt Leitplanken (Guardrails) ein, um Anomalien im Benchmarking zu erkennen.
- Betreibt Introspektion, um zu bewerten, ob eine rückgängig gemachte Idee unter anderen Bedingungen wieder an Wert gewinnen könnte.
- Überwacht die langfristige Systemgesundheit und veröffentlicht Constraints, um das Zurückkehren in unproduktive Bereiche zu verhindern.
Domänen-Spezialisten:
- Werden dynamisch pro Aufgabe konstruiert.
- Operieren asynchron über verschiedene Schichten hinweg und führen iterative Verfeinerungen mit lokaler Validierung durch, bevor sie einsatzbereite Patches zurückgeben.
- Halten sich an die vom Critic veröffentlichten Constraints.
Persistente Wissensdatenbank:
- Kumuliert Strategien und Fehlermodi über Sitzungen hinweg.
- Ermöglicht den Warm-Start-Transfer auf neue Modelle und Hardware, was die Scoring-Priors informiert und die Varianz zwischen den Durchläufen reduziert.

Zentrale Beiträge

Stateful Tree Search Formulierung: Die Arbeit formuliert die über-schichtige Optimierung als Baumsuche, wobei der Baum als gemeinsames Arbeitsgedächtnis dient. Fehler propagieren als Constraints auf Kindknoten, und Erfolge triggern ein Re-Profiling, um die Suchfront zu erweitieren.
Checks-and-Balances Multi-Agenten-Architektur: Führt ein Dual-Agenten-System ein, in dem ein Orchestrator die aggressive Optimierung vorantreibt, während ein Critic die Stabilität sichert. Keiner der Agenten kann das System einseitig steuern, was sicherstellt, dass kurzfristige Durchsatz-Opfer nur dann erfolgen, wenn sie für die Lebensfähigkeit der Sitzung notwendig sind.
Skill-Dekomposition: Zerlegt die Agentenfähigkeiten in Hard Skills (Domänenexpertise) und Soft Skills (Koordinationsprotokolle), gestützt durch eine persistente Wissensdatenbank für den Transfer über Sitzungen hinweg.
Dynamische Konstruktion von Spezialisten: Bewegt sich weg von festen Agenten hin zur dynamischen Konstruktion von Domänen-Spezialisten zur Laufzeit, basierend auf dem spezifischen Optimierungsziel, dem Hardware-Kontext und historischen Daten.

Ergebnisse

Arbor wurde auf LLM-Inferenz-Serving über sechs Produktionsmodellen auf AMD Instinct GPUs (MI355X und MI300X) evaluiert.

Durchsatz-Verbesserungen:
- Auf der MI355X erreichte Arbor nach Tagen vollautonomer Operation eine Durchsatzsteigerung von +40 % bis +193 % gegenüber den herstelleroptimierten Baselines.
- Auf der MI300X (Validierung über Generationen hinweg) lagen die Verbesserungen zwischen +62 % und +99 %.
Reproduzierbarkeit: Die Varianz zwischen den Durchläufen lag innerhalb von 2 Prozentpunkten, was eine hardwareagnostische Reproduzierbarkeit demonstriert.
Ablation/Vergleich: Ein einzelner Agent ohne das Arbor-Harness (das „Harness“ sei das Multi-Agenten-Baumsuch-Framework) stagnierte bei einer Durchsatzverbesserung von lediglich +33 % und stürzte innerhalb weniger Stunden irreparabel ab.
Fallstudie (gpt-oss-120b): In einem spezifischen Suchbaum für ein 120B MoE-Modell explorierte das System 30 Aktionen. 9 wurden beibehalten, 16 wurden mit diagnostischen Erkenntnissen rückgängig gemacht und 3 Abstürze wurden via RCA wiederhergestellt. Das System erreichte 6.515 tok/s/GPU (eine Steigerung von 48 % gegenüber der 4.405 tok/s/GPU Baseline) unter Nutzung von Erkenntnissen aus der Introspektion (z. B. Identifizierung toter Codepfade) und der RCA (Klassifizierung von Abstürzen als Abhängigkeitsprobleme statt als algorithmische Fehler).

Bedeutung und Ansprüche

Das Paper behauptet, dass Arbor einen Paradigmenwechsel in der autonomen Optimierung darstellt: weg von der isolierten Generierung von Kandidaten hin zum Navigieren in stateful, großen Aktionsräumen. Indem Fehler als diagnostische Signale behandelt werden, die die Exploration umgestalten, und ein gemeinsames Arbeitsgedächtnis aufrechterhalten wird, ermöglicht Arbor vollautonome, mehrtägige Kampagnen, die aufgrund von Systeminstabilität andernfalls unmöglich wären.

Das Framework zeigt, dass:

Über-schichtige Optimierung (Cross-layer optimization) ohne menschliches Eingreifen machbar ist, sofern das System in der Lage ist, Verschiebungen der Engpässe zu erkennen und Fehler über den gesamten Stack hinweg zu diagnostizieren.
Checks-and-Balances-Architekturen entscheidend für dauerhafte Autonomie sind, um zu verhindern, dass aggressive Exploration die Stabilität des Systems gefährdet.
Wissenstransfer über Sitzungen und Hardware-Generationen hinweg durch persistentes Gedächtnis möglich ist, was die Hürden für die Inbetriebnahme neuer Hardware oder Modelle senkt.

Letztlich zielt Arbor darauf ab, die Betriebskosten und die CO2-Intensität von LLM-Deployments zu reduzieren, indem es die koordinierte Anstrengung automatisiert, die traditionell von Engineering-Teams über den gesamten Software- und Hardware-Stack hinweg erforderlich ist.