Benchmarking-Methodik von Artificial Analysis

Umfang

Artificial Analysis führt Benchmarks zu Intelligenz, Qualität, Leistung und Preis von KI-Modellen, Endpunkten von Inferenz-APIs und Systemen durch. Dieser Bereich unserer Website beschreibt unsere Benchmarking-Methodik einschließlich unserer Qualitäts- und Leistungsbenchmarks.

Beim Benchmarking von Sprachmodellen gelten Endpunkte für uns als serverlos, wenn Kunden nur für ihre Nutzung und nicht einen festen Preis für den Zugang zu einem System zahlen. In der Regel bedeutet dies, dass Endpunkte pro Token abgerechnet werden, häufig mit unterschiedlichen Preisen für Eingabe- und Ausgabetokens.

Über alle Modalitäten hinweg misst unser Leistungsbenchmarking die Ende-zu-Ende-Leistung, die Kunden von KI-Inferenzdiensten und -systemen erleben. Die Benchmark-Ergebnisse sollen also nicht die maximal mögliche Leistung auf einer bestimmten Hardwareplattform abbilden, sondern die reale Leistung, die Kunden bei verschiedenen Anbietern erleben.

Wir führen Benchmarks sowohl für proprietäre Modelle als auch für Modelle mit offenen Gewichten durch.

Intelligenz von Sprachmodellen

Sprache, Bild, Video & Musik

Inferenz

Sonstiges

Definitionen

Auf dieser Seite und auf der gesamten Website von Artificial Analysis verwenden wir folgende Begriffe:

• Modell: Ein großes Sprachmodell (LLM), einschließlich proprietärer, quelloffener Modelle und Modelle mit offenen Gewichten.
• Modellentwickler: Die Organisation, die das Modell entwickelt und trainiert hat. Beispielsweise ist OpenAI der Entwickler von GPT-4 und Meta der Entwickler von Llama 3.
• Endpunkt: Eine gehostete Instanz eines Modells, auf die über eine API zugegriffen werden kann. Ein einzelnes Modell kann bei verschiedenen Anbietern mehrere Endpunkte haben.
• System: Eine dedizierte Rechenumgebung für die Ausführung von KI-Modellen, üblicherweise bereitgestellte Infrastruktur wie eine VM, deren Leistung unter Last gemessen werden kann.
• Anbieter: Ein Unternehmen, das einen oder mehrere Modellendpunkte oder Systeme hostet und den Zugang dazu bereitstellt. Beispiele sind OpenAI, AWS Bedrock und Together.ai. Unternehmen sind häufig sowohl Modellentwickler als auch Anbieter.
• Serverlos: Ein Cloud-Dienst, der nach Nutzung bereitgestellt wird. Bei LLM-Inferenz-APIs bedeutet dies in der Regel eine Abrechnung pro Ein- und Ausgabetoken. Serverlose Cloud-Produkte werden trotzdem auf Servern ausgeführt!
• Offene Gewichte: Ein Modell, dessen Gewichte vom Modellentwickler öffentlich freigegeben wurden. Wir sprechen von „offenen Gewichten“ oder einfach „offenen“ Modellen statt von „Open Source“, da viele offene LLMs unter Lizenzen veröffentlicht wurden, die nicht der vollständigen Definition von Open-Source-Software entsprechen.
• Token: Moderne LLMs basieren auf Tokens – numerischen Darstellungen von Wörtern und Zeichen. LLMs nehmen Tokens als Eingabe entgegen und erzeugen Tokens als Ausgabe. Der Eingabetext wird von einem Tokenizer in Tokens umgewandelt. Verschiedene LLMs verwenden unterschiedliche Tokenizer.
• Native Tokens: Tokens, wie sie der eigene Tokenizer eines LLM zählt und meist die API des Anbieters meldet. Preise beziehen sich in der Regel auf native Tokens, und unsere Leistungskennzahlen wie die Ausgabegeschwindigkeit zählen sie.
• Preis (Eingabe/Ausgabe): Der Preis, den ein Anbieter pro an das Modell gesendetem Eingabetoken und pro vom Modell empfangenem Ausgabetoken berechnet. Die angezeigten Preise sind die aktuell von den Anbietern veröffentlichten Preise.
• Mischpreis: Für einen einfacheren Vergleich berechnen wir einen Mischpreis unter der Annahme eines Verhältnisses von 7:2:1 zwischen Tokens mit Cache-Treffer, Eingabetokens und Ausgabetokens.
• Kosten pro Aufgabe: Die gewichteten Durchschnittskosten (USD) für die Bearbeitung einer Aufgabe des Artificial Analysis Intelligence Index. Sie werden berechnet, indem die Preise für Eingabe-, Cache- und Ausgabetokens mit den im Workload verbrauchten Tokens multipliziert, mit den gleichen Gewichtungen pro Benchmark, die auch der Intelligence Index verwendet, gewichtet und anschließend durch die Anzahl der Aufgaben geteilt werden. Als Preis wird entweder der direkte API-Tarif des Anbieters oder der Median über alle Anbieter verwendet. Die Cache-Kosten unterscheiden sich je nach Anbieter. Da die Kosten den tatsächlichen Tokenverbrauch abbilden, verursachen Modelle mit längeren Antworten oder mehr Reasoning-Tokens selbst bei identischen Preisen pro Token höhere Kosten pro Aufgabe.

  wobei i = jeder Benchmark im Artificial Analysis Intelligence Index und w = die Gewichtung dieses Benchmarks im Index

• Zeit pro Aufgabe: Die geschätzte gewichtete Durchschnittszeit für die Bearbeitung einer Aufgabe des Artificial Analysis Intelligence Index. Für jeden Benchmark teilen wir die Antwort- und Reasoning-Tokens pro Aufgabe durch die Ausgabegeschwindigkeit des Modells und gewichten das Ergebnis mit den gleichen Gewichtungen pro Benchmark, die auch der Intelligence Index verwendet. Die Ausgabegeschwindigkeit stammt aus unseren API-Performance-Benchmarks: die Ausgabetokens pro Sekunde über die gesamte Dauer jeder Anfrage, gemittelt über die Workloads, die wir in den vergangenen 5 Tagen gemessen haben, auf dem repräsentativen Endpunkt des Modells, in der Regel der eigenen API des Modellentwicklers, den wir auch für seinen Preis verwenden. Hat ein Modell keinen repräsentativen Endpunkt oder liegen dafür keine Messungen vor, nehmen wir den Median über die gemessenen Endpunkte des Modells. Wo wir die Zeit pro Aufgabe für einen Endpunkt zeigen, etwa auf Anbieterseiten, verwenden wir die Ausgabegeschwindigkeit dieses Endpunkts. Wir leiten die Zeit pro Aufgabe aus Tokens und Geschwindigkeit ab, statt Evaluierungsläufe zu messen, damit sie repräsentative API-Geschwindigkeiten widerspiegelt.

  wobei i = jeder Benchmark im Artificial Analysis Intelligence Index, w = die Gewichtung dieses Benchmarks im Index und Output Speed = die Ausgabegeschwindigkeit des Modells in Tokens pro Sekunde

• Zeit bis zum ersten Antworttoken: Die Zeit in Sekunden zwischen dem Senden einer Anfrage an den Dienst oder das System und dem Empfang des ersten Antworttokens. Bei Reasoning-Modellen schließt sie die Reasoning-Zeit ein, sodass sie anders als die Zeit bis zum ersten Token die Wartezeit auf eine Antwort bei Modellen mit und ohne Reasoning auf dieselbe Weise misst. Bei Multi-Turn-Workloads mitteln wir sie über die Runden einer Sitzung.
• Zeit bis zum ersten Token: Die Zeit in Sekunden zwischen dem Senden einer Anfrage an den Dienst oder das System und dem Empfang des ersten Tokens der Antwort. Bei Reasoning-Modellen, die Reasoning-Tokens zurückgeben, ist dies das erste Reasoning-Token. Bei Multi-Turn-Workloads mitteln wir sie über die Runden einer Sitzung.
• Ausgabegeschwindigkeit (Ausgabetokens pro Sekunde): Die Anzahl der Ausgabetokens einschließlich Reasoning-Tokens, die pro Sekunde über die gesamte Dauer einer Anfrage empfangen werden, vom Senden der Anfrage bis zum Empfang des letzten Tokens; sie schließt also die Zeit bis zum ersten Token ein. Bei einer Multi-Turn-Sitzung teilen wir ihre Ausgabetokens durch die Zeit, die der Endpunkt für die Beantwortung ihrer Anfragen gebraucht hat, ohne die Zeit, in der Tools zwischen den Anfragen laufen.
• Ende-zu-Ende-Zeit: Die Zeit in Sekunden zwischen dem Senden einer Anfrage und dem Empfang des letzten Tokens, bei jeder Anfrage gemessen. Bei einer Multi-Turn-Sitzung ist sie die Summe über die Anfragen der Sitzung, ohne die Zeit, in der Tools zwischen ihnen laufen.
• Endpunkt-Fehlerrate: Der Anteil der Anfragen eines Endpunkts in den vergangenen 5 Tagen, die auf Seiten des Endpunkts fehlgeschlagen sind. Eine Multi-Turn-Sitzung zählt als eine Anfrage, die fehlschlägt, wenn eine ihrer Anfragen fehlschlägt. Fehler, die wir nicht dem Endpunkt zuschreiben, schließen wir aus, etwa einen ungültigen API-Schlüssel, aufgebrauchtes Guthaben oder das Kontingent unseres Kontos, eine als ungültig oder für das Kontextfenster zu lang abgelehnte Anfrage, eine Antwort, die unser max_tokens-Limit vor der eigentlichen Antwort abschneidet, eine Sicherheitssperre oder einen Sandbox-Fehler. Fehler auf Seiten des Endpunkts zählen, darunter seine Ratenlimits, Zeitüberschreitungen und Anfragen, die bei Ablauf der Benchmark-Frist noch laufen. Über Workloads hinweg fassen wir die Anfragen vor der Division zusammen.
• Cache-Trefferrate: Der Anteil der cachefähigen Eingabe-Token, die aus dem Prompt-Cache des Anbieters bereitgestellt werden, wie von der API des Anbieters während mehrstufiger agentischer Sitzungen gemeldet. Für jeden Endpunkt geben wir eine repräsentative Cache-Trefferrate auf Basis seiner aktuellen Messungen an.