AgentOpt v0.1 Technical Report: Client-Side Optimization for LLM-Based Agent

1. Problemstellung

Während die aktuelle Forschung zur Effizienz von KI-Agenten (AI Agents) stark auf serverseitige Optimierungen fokussiert ist (z. B. Caching, spekulatives Ausführen, Lastverteilung und Traffic-Scheduling), vernachlässigt sie einen kritischen Aspekt: die clientseitige Optimierung.

Moderne Agenten werden von Entwicklern zunehmend aus heterogenen Komponenten zusammengesetzt: lokale Tools, Remote-APIs und eine Auswahl verschiedener Sprachmodelle (LLMs). Die Entwickler müssen entscheiden:

• Welches Modell für welche Rolle im Pipeline-Prozess (z. B. Planer, Löser, Kritiker) verwendet wird.
• Wie das API-Budget über die einzelnen Schritte verteilt wird.
• Welche Trade-offs zwischen Qualität, Kosten und Latenz für die spezifische Anwendung akzeptabel sind.

Das Kernproblem: Diese Entscheidungen sind anwendungsspezifisch und können nicht zentral vom Anbieter getroffen werden. Die Arbeit zeigt, dass die Wahl der Modellkombination einen massiven Einfluss auf die Effizienz hat. Bei gleicher Genauigkeit können die Kosten zwischen der besten und der schlechtesten Modellkombination in den Experimenten um den Faktor 13 bis 32 variieren. Herkömmliche serverseitige Optimierungen können diese Lücke nicht schließen, da sie von einer festen Modellzuweisung ausgehen.

Zudem ist die Optimierung komplexer als einfaches „Routing" (Zuweisung eines Modells pro Anfrage). In mehrstufigen Agenten-Pipelines sind die Entscheidungen über die Rollen hinweg gekoppelt. Ein starkes Modell in einer Rolle (z. B. Planer) kann die Leistung einer nachgelagerten Rolle (z. B. Löser) beeinträchtigen, wenn es beispielsweise zu eigenständig agiert und notwendige Tools überspringt. Daher muss die Optimierung auf Ebene der gesamten Pipeline-Kombination und nicht einzelner Aufrufe erfolgen.

2. Methodik: AgentOpt Framework

Die Autoren stellen AgentOpt vor, ein framework-agnostisches Python-Paket zur clientseitigen Optimierung. Das Ziel ist es, die Pareto-Frontier (die beste Balance aus Genauigkeit, Kosten und Latenz) für eine gegebene Agenten-Pipeline zu finden.

Architektur und Design:

• Framework-Agnostisch: AgentOpt greift auf der HTTP-Transportebene (via httpx) ein, um LLM-Aufrufe zu verfolgen, ohne den Agenten-Code oder die Orchestrierungs-Frameworks (wie LangGraph, AutoGen) ändern zu müssen.
• Attribution: Mithilfe von contextvars werden einzelne API-Aufrufe den jeweiligen Datapoints und Modellkombinationen zugeordnet.
• Caching & Parallelisierung: Das System nutzt HTTP-Level-Caching, um redundante API-Aufrufe bei verschiedenen Kombinationen zu vermeiden, und ermöglicht eine kontrollierte parallele Ausführung, um die Evaluierungszeit zu verkürzen.

Das Optimierungsproblem:
Gegeben eine Pipeline mit $N$ Rollen und einer Menge von Kandidatenmodellen $M_i$ pro Rolle, ist die Aufgabe, die Kombination $c = (m_1, ..., m_N)$ zu finden, die eine Nutzenfunktion $J(c)$ maximiert (basierend auf Performance, Latenz und Kosten). Da der Suchraum exponentiell wächst ($|C| = \prod |M_i|$), ist eine erschöpfende Suche (Brute-Force) oft zu teuer.

Suchalgorithmen:
AgentOpt implementiert acht Suchalgorithmen, um diesen kombinatorischen Raum effizient zu erkunden:

1. Arm Elimination (Standard): Eine adaptive Methode, die in Runden arbeitet. Kombinationen werden auf Teilmengen der Daten evaluiert; Kombinationen, deren obere Konfidenzgrenze unter die untere Grenze der aktuellen Führung liegt, werden eliminiert.
2. Epsilon-LUCB: Fokussiert auf die Identifizierung einer $\epsilon$-optimalen Kombination durch gezieltes Sampling der unsichersten Paare.
3. Threshold Successive Elimination: Sucht nach allen Kombinationen, die einen bestimmten Qualitätsschwellenwert überschreiten.
4. Hill Climbing: Nutzt eine Nachbarschaftsstruktur, um schrittweise zu besseren Kombinationen zu gelangen (lokal optimiert).
5. Bayesian Optimization: Passt ein Surrogatmodell an den Suchraum an, um vielversprechende Kandidaten vorherzusagen.
6. LM Proposal: Nutzt ein starkes LLM, um basierend auf Beschreibungen eine Vorauswahl zu treffen (erwies sich als weniger zuverlässig).
7. Brute-Force & Random Search: Als Baselines.

3. Wichtige Beiträge

1. Formalisierung der clientseitigen Optimierung: Die Arbeit definiert die clientseitige Optimierung als eigenständiges Systemproblem für KI-Agenten und identifiziert die Modellkombinationsauswahl als primären Hebel für Effizienzgewinne.
2. Kombinatorische Optimierung statt Einzel-Routing: Es wird gezeigt, dass die Leistung eines Modells kontextabhängig ist (Rollen-spezifisch). Die beste Kombination ist oft nicht die Summe der besten Einzelmodelle. AgentOpt führt das Konzept der „Combo" als Einheit der Evaluation ein.
3. Implementierung und Evaluation: Vorstellung von AgentOpt als Open-Source-Tool und der Nachweis, dass Algorithmen wie Arm Elimination die Evaluierungskosten im Vergleich zur Brute-Force-Suche um 24–67 % senken können, während sie nahezu optimale Ergebnisse liefern.

4. Ergebnisse und Experimente

Die Evaluation erfolgte auf vier Benchmarks: HotpotQA (Multi-Hop QA), GPQA Diamond (Wissenschaft), MathQA (Mathematisches Reasoning) und BFCL v3 (Function Calling).

Hauptergebnisse:

• Massive Kosteneinsparungen: Bei gleicher Genauigkeit variierten die Kosten zwischen den besten und schlechtesten Kombinationen um den Faktor 13 bis 32.
  • Beispiel BFCL: Qwen3 Next 80B erreichte die gleiche Genauigkeit wie das teure Claude Opus 4.6, war aber 32-mal günstiger.
• Kontextabhängigkeit der Modellleistung:
  • HotpotQA: Das leistungsstärkste Modell (Claude Opus 4.6) war als „Planer" das schlechteste aller 81 Kombinationen (Genauigkeit ~31,7 %). Es ignorierte die Suchtools des nachgelagerten „Lösers". Die beste Kombination bestand aus einem schwachen, günstigen Planer (Ministral 3 8B) und einem starken Löser (Opus 4.6), was zu 74,27 % Genauigkeit führte.
  • Dies beweist, dass Modelle nicht isoliert, sondern im Kontext der gesamten Pipeline bewertet werden müssen.
• Algorithmische Leistung:
  • Arm Elimination erwies sich als robustester Algorithmus über alle Benchmarks hinweg. Er lieferte eine konsistente Balance zwischen Suchkosten und Ergebnisqualität.
  • Bayesian Optimization funktionierte gut bei HotpotQA, scheiterte aber bei MathQA, da die Genauigkeitslandschaft dort zu unregelmäßig für Surrogatmodelle war.
  • Hill Climbing versagte oft bei komplexen, nicht-intuitiven Kombinationen (z. B. HotpotQA), da es in lokalen Optima stecken blieb.
  • LM Proposal (Vorhersage durch ein anderes LLM) funktionierte nur dort, wo die Modellleistung intuitiv war (GPQA), scheiterte aber bei rollenspezifischen Interaktionen.

5. Bedeutung und Fazit

Der Technical Report unterstreicht einen Paradigmenwechsel in der Entwicklung von KI-Agenten:

• Vom Server zum Client: Die Effizienzoptimierung darf nicht mehr nur beim Anbieter (Server) liegen. Entwickler müssen die Kontrolle über die Ressourcenallokation in ihren Pipelines übernehmen.
• Qualität ist relational: Die „beste" KI ist nicht absolut, sondern hängt davon ab, welche Rolle sie in einem spezifischen Workflow erfüllt und welche anderen Modelle sie umgeben.
• Praktische Anwendbarkeit: AgentOpt bietet Entwicklern ein Werkzeug, um diese komplexen Trade-offs datengestützt zu lösen, anstatt auf Heuristiken oder isolierte Benchmark-Rankings zu vertrauen.

Die Arbeit etabliert die clientseitige Optimierung als notwendige Schicht im Stack von Agentensystemen und zeigt, dass durch intelligente Modellkombinationen enorme Kosteneinsparungen bei gleichbleibender oder sogar verbesserter Leistung erzielt werden können.