AA-AgentPerf-Methodik

Überblick

AA-AgentPerf ist ein Hardware-Benchmark, der unter realistischen agentischen Workloads den Kompromiss zwischen dem Gesamtdurchsatz einer Inferenzbereitstellung und der Geschwindigkeit misst, die jeder Agent erhält.

  • Reale agentische Trajektorien: Mehrstufige Programmiersitzungen mit abwechselnden Schlussfolgerungen und Werkzeugaufrufen sowie variablen Kontextlängen (keine synthetischen, einheitlichen Prompts).
  • Dauerhafte gleichzeitige Last: Jeder simulierte Agent bleibt während der gesamten Testphase aktiv und beansprucht damit die Wiederverwendung des KV-Caches, die spekulative Decodierung und das Schedulerverhalten.
  • Live-Bestenliste: Wir veröffentlichen Ergebnisse fortlaufend, nehmen neue Hardware auf, sobald sie verfügbar ist, und messen Systeme mit neuen Software-Stacks und Modellversionen erneut.
  • Produktionsreif: Wir testen die Modelle mit aktivierten realitätsnahen Optimierungen und Bereitstellungstopologien im Produktionsmaßstab.
gleichzeitige Agenten0/ 9INFERENZ-SYSTEMAGENT 1AGENT 2AGENT 3AGENT 4AGENT 5AGENT 6AGENT 7AGENT 8AGENT 9SystemdurchsatzAusgabegeschwindigkeit pro Agent

Jeder simulierte Agent arbeitet agentische Programmiertrajektorien der Reihe nach ab (er stellt Überlegungen an, ruft Werkzeuge auf und bearbeitet Code), während das System für eine zunehmende Zahl gleichzeitiger Agenten skaliert.

Datensatz

Der AA-AgentPerf-Datensatz enthält reale agentische Trajektorien aus verschiedenen Anwendungsfällen, Programmiersprachen und Modellen. Wir haben die Trajektorien im agentischen OpenCode-Harness mit drei führenden Open-Source-Modellen bei aktivierter Schlussfolgerung erzeugt (DeepSeek V3.2, GLM 4.7 und Kimi K2.5). Dabei haben wir die Modelle angewiesen, Issues in echten öffentlichen Code-Repositorys zu lösen. Alle Trajektorien enthalten abwechselnde Schlussfolgerungen und Werkzeugaufrufe.

  • Input Sequence Length (ISL): Reicht von etwa 5K bis etwa 131K Tokens, bei einem Mittelwert von rund 27K Tokens. Trajektorien werden gekürzt, damit sie in die maximal empfohlene Kontextlänge der getesteten Modelle passen.
  • Output Sequence Length (OSL): Die Ausgabelänge variiert stark zwischen den Gesprächsrunden: Manche erzeugen kurze Ausgaben wie einfache Werkzeugaufrufe, andere erfordern längere Schlussfolgerungen, bevor das Modell antwortet oder handelt.
  • Sprachen: Der Datensatz umfasst mehr als 12 Programmiersprachen, basierend auf der Hauptsprache des jeweiligen Quell-Repositorys. Python-Repositorys kommen am häufigsten vor, gefolgt von TypeScript und Go.
  • Verzögerungen bei Werkzeugaufrufen: Nach jedem Werkzeugaufruf simulieren wir die Verarbeitungszeit durch eine feste Verzögerung pro Nachricht. Sie wird aus einer nach aufgerufenem Werkzeug unterteilten Verteilung realer Werkzeugaufrufzeiten gezogen. Die Verzögerungen reichen von weniger als 0,1 s bis zu 5 s, bei einem Median von etwa 1 Sekunde.

Wir stellen den Testteilnehmern eine repräsentative Teilmenge für die Feinabstimmung mit 500 individuellen Trajektorien (18.997 Prompts) bereit, um Konfigurationen zu validieren und die Leistung zu optimieren. Der vollständige Testdatensatz bleibt privat, damit keine gezielten Optimierungen für den Benchmark vorgenommen werden können.

Paretofront

Für jedes System veröffentlichen wir die Ergebnisse als Paretofront aus Gesamtdurchsatz des Servers und Ausgabegeschwindigkeit pro Anfrage. Jeder Punkt steht für eine Serving-Konfiguration bei einer bestimmten Anzahl gleichzeitiger Agenten, und die Paretofront enthält die Punkte, die keine andere Konfiguration desselben Systems sowohl beim Durchsatz als auch bei der Geschwindigkeit übertrifft.

Wir berechnen Geschwindigkeit und Latenz pro Anfrage. Da agentische Workloads viele Anfragen mit kurzer OSL enthalten, zeigen die Diagramme standardmäßig die P25-Ausgabegeschwindigkeit; die Perzentile werden über alle während einer Phase gesendeten Anfragen berechnet.

Testdurchführung

Wir messen jede Bereitstellung bei einer festen Reihe von Stufen gleichzeitiger Agenten, mit einer Phase pro Stufe, und berechnen die Metriken anhand der Token-Zeitinformationen im stationären Zustand. Jede Phase läuft so lange, bis mindestens 30 Trajektorien abgeschlossen wurden, jeder simulierte Agent mindestens 3 Trajektorien abgeschlossen hat und mindestens 10 Minuten Messzeit im stationären Zustand vergangen sind. Die Zuweisung der Agententrajektorien ist über die Phasen hinweg deterministisch. Zu Beginn jeder Trajektorie werden in jeder Phase dynamisch erzeugte Präfixe hinzugefügt, um das Präfix-Caching zwischen den Phasen zu verhindern. Ein max_tokens-Wert von 16K verhindert, dass einzelne Anfragen, bei denen ein Modell in einer Wiederholungsschleife stecken bleibt, die Ergebnisse verzerren.

Wir testen jedes Modell mit den vom Modellentwickler empfohlenen Sampling-Parametern und dem maximal verfügbaren Reasoning-Aufwand (max für DeepSeek V4.1 Flash, DeepSeek V4 Pro 0813, Kimi K3, GLM-5.2 und GLM-5.3; xhigh für Muse Spark Open). Alle anderen Parameter bleiben auf ihren Standardwerten.

Metriken und Ergebnisse

In jeder Testphase berechnen wir die folgenden Metriken:

  • Time to First Token (TTFT): Latenz pro Anfrage vom Absenden der Anfrage bis zum Empfang des ersten Ausgabetokens.
  • Ausgabegeschwindigkeit: Ausgabetokens pro Sekunde und Anfrage, gemessen nach Empfang des ersten Tokens.
  • Gesamtdurchsatz des Servers: Eingabe- und Ausgabetokens pro Sekunde über alle gleichzeitigen Agenten hinweg, wie vom Server gemeldet. Die Eingabe umfasst auch Prompt-Tokens, die aus dem KV-Cache bedient werden.

Alle Metriken werden auf Zeiträume im stationären Zustand beschränkt, in denen sämtliche Agenten bei der Zielanzahl gleichzeitiger Agenten mindestens 30 Sekunden lang aktiv waren. Geschwindigkeitsmetriken verwenden serverseitige Token-Zahlen aus den Nutzungsmetadaten des Inferenz-Frameworks, die durch lokale Tokenisierung mit dem nativen Tokenizer des getesteten Modells überprüft werden. Wir messen die Leistungsaufnahme jedes Beschleunigers während des laufenden Tests. Wir normalisieren das zentrale Ergebnis, den Gesamtdurchsatz des Servers, pro MW, pro Beschleuniger und pro Dollar Mietpreis je Beschleunigerstunde. Die Werte pro MW basieren auf der unter Last gemessenen Leistungsaufnahme des Beschleunigers (GPU-Die + HBM) und nicht auf der Nenn-TDP. Die Mietpreise stammen von Silicon Data; für Chips, für die Silicon Data keine Preise ausweist, verwenden wir eigene Schätzungen.

Wir veröffentlichen die Ergebnisse auf der Bestenliste von Artificial Analysis mit der vollständigen Systemkonfiguration, die der jeweilige Anbieter offenlegt. Anbieter können ihre Ergebnisse vor der Veröffentlichung auf sachliche Richtigkeit prüfen.

Einreichungen

Wenn Sie als Hardwareanbieter Ihr System zur Bewertung mit AA-AgentPerf einreichen möchten und noch nicht mit uns in Kontakt stehen, schreiben Sie an agentperf@artificialanalysis.ai.