AA-AgentPerf-Methodik
Überblick
AA-AgentPerf ist ein Hardware-Benchmark, der misst, wie viele aktive Agenten eine Inferenzbereitstellung unter realistischen agentischen Workloads unterstützen kann, während sie die Geschwindigkeitsziele pro Agent einhält.
- Reale agentische Trajektorien – mehrstufige Programmiersitzungen mit abwechselnden Schlussfolgerungen und Werkzeugaufrufen sowie variablen Kontextlängen (keine synthetischen, einheitlichen Prompts).
- Dauerhafte gleichzeitige Last – simulierte Agenten halten kontinuierlich laufende Anfragen aufrecht und beanspruchen damit die Wiederverwendung des KV-Caches, die spekulative Decodierung und das Schedulerverhalten.
- Marktbasierte SLO-Stufen – Leistungsschwellenwerte auf Grundlage der serverlosen API-Benchmark-Daten von Artificial Analysis, die das bei verschiedenen Anbietern beobachtete Dienstqualitätsniveau widerspiegeln.
- Fortlaufend aktualisiert – die Ergebnisse werden kontinuierlich aktualisiert, sobald neue Hardware, Software-Stacks und Modellversionen verfügbar sind.
- Produktionsreif – die Modelle werden mit aktivierten realitätsnahen Optimierungen und Bereitstellungstopologien im Produktionsmaßstab getestet.
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. Die Trajektorien wurden 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. Die Modelle wurden 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 wird die Verarbeitungszeit durch eine feste Verzögerung pro Nachricht simuliert. 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.
Den Testteilnehmern wird eine repräsentative Teilmenge für die Feinabstimmung bereitgestellt – 500 individuelle Trajektorien mit insgesamt 18.997 Prompts –, 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.
Service-Level-Ziele
Die Leistungs-SLOs werden anhand der serverlosen API-Benchmark-Daten von Artificial Analysis festgelegt. Für jedes getestete Modell wurden die derzeit am Markt verfügbaren Servicestufen ermittelt. Anbieter optimieren jede Stufe separat, um die Zahl der gleichzeitigen Agenten zu maximieren, die sie auf diesem Serviceniveau unterstützen können.
Geschwindigkeit und Latenz werden jeweils pro Anfrage berechnet. Wegen der großen Zahl an Anfragen mit kurzer OSL in agentischen Workloads verwenden wir die P25-Ausgabegeschwindigkeit; die Perzentile werden über alle während einer Phase gesendeten Anfragen berechnet.
Jedes Modell wird mit den vom Modellentwickler empfohlenen Sampling-Parametern und dem maximal verfügbaren Reasoning-Aufwand getestet: max reasoning effort für DeepSeek V4 Pro und Kimi K3 sowie high reasoning effort für gpt-oss-120b. Alle anderen Parameter bleiben auf ihren Standardwerten.
Wir stellen derzeit von den getrennten Metriken Ausgabegeschwindigkeit und TTFT auf eine kombinierte E2E-Geschwindigkeitsmetrik um. Während dieser Umstellung werden manche Werte als Geschwindigkeit/TTFT und andere als E2E-Geschwindigkeit angegeben.
| Modell | SLO-Stufe | P25-Ausgabegeschwindigkeit (Tokens/s) | P95-TTFT (s) |
|---|---|---|---|
| DeepSeek V4 Pro (max) | SLO #1 | 20 | 10 |
| SLO #2 | 60 | 5 | |
| SLO #3 | 180 | 3 | |
| gpt-oss-120b (high) | SLO #1 | 100 | 5 |
| SLO #2 | 250 | 3 | |
| SLO #3 | 500 | 2 | |
| SLO #4 | 2,000 | 1 | |
| Kimi K3 (max) | Für Kimi K3 testen wir eine neue Konfiguration ohne SLO, die auf die vollständige Paretofront ausgerichtet ist | ||
Leistungs-SLOs
Testdurchführung
Die Anzahl der unterstützten Agenten pro SLO wird nach einer anfänglichen exponentiellen Steigerung durch binäre Suche ermittelt. Die Metriken werden anhand der Token-Zeitinformationen im stationären Zustand berechnet. Nach Abschluss einer Phase und Berechnung der Metriken prüft das System, ob die SLOs verletzt wurden, und fährt dann mit der nächsten Zielanzahl gleichzeitiger Agenten fort. 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.
| Phase | Agents | p25 Speed | Result |
|---|
Mit zunehmender Zahl gleichzeitiger Agenten sinkt die Ausgabegeschwindigkeit pro Anfrage. Jede SLO-Stufe definiert eine akzeptable Mindestgeschwindigkeit und bestimmt damit die maximale Zahl an Agenten, die auf dieser Stufe unterstützt werden kann.
Metriken und Ergebnisse
In jeder Testphase werden die folgenden Zeitmetriken berechnet:
- 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.
- E2E-Geschwindigkeit: Ausgabetokens pro Sekunde und Anfrage über die gesamte Anfrage hinweg, einschließlich der Wartezeit auf das erste Token. Diese einzelne Metrik ersetzt die beiden vorherigen.
- Systemausgabedurchsatz: Aggregierte Ausgabetokens pro Sekunde über alle gleichzeitigen Agenten hinweg.
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. Die Leistungsaufnahme jedes Beschleunigers wird während des laufenden Tests gemessen. Die zentralen Ergebnisse – maximale Zahl gleichzeitiger Agenten und Ausgabedurchsatz je SLO-Stufe – werden pro Beschleuniger und pro MW normalisiert, um einen fairen Vergleich verschiedener Hardwarekonfigurationen zu ermöglichen. Die Werte pro MW basieren auf der unter Last gemessenen Leistungsaufnahme des Beschleunigers (GPU-Die + HBM) und nicht auf der Nenn-TDP.
Die Ergebnisse werden mit den vollständigen, vom Anbieter offengelegten Systemkonfigurationen auf der Bestenliste von Artificial Analysis veröffentlicht. 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.