AIHubMix Fidelitas Standard v2.0

AIHubMix Fidelitas betrachtet die Bereitstellungsleistung desselben Modells bei Diensten verschiedener Modellanbieter als Messgegenstand und bewertet die Korrektheit der Aufgabenergebnisse, die Funktionsverfügbarkeit, die Antwortleistung sowie den Abschluss beim ersten Request. Der Gesamtwert und die vier Dimensionswerte werden gemeinsam ausgewiesen und dienen dazu, die Serviceleistung desselben Modells unter den festgelegten Testbedingungen zu vergleichen. Dieser Artikel verwendet den AIHubMix Fidelitas Standard v2.0; die Projektversion ist AF v2.0. Der Hauptwert stützt sich auf die gemäß der Anbieterdokumentation konfigurierten Ergebnisse zur Funktionsunterstützung und Cache-Messung; Schnittstellenkompatibilität und Cache-Ergebnisse unter der Standardkonfiguration werden getrennt als Diagnosekennzahlen berichtet.

Bewertungsumfang und Leseweise

Bewertungskriterium	Kürzel	Gewichtung	Messgegenstand
Antwortqualität	Q (Quality)	35%	Korrektheit der Ergebnisse bei Tool-Aufrufen, Wissens- und Reasoning-Aufgaben sowie Aufgaben zum Verständnis langer Texte
Funktionsunterstützung	F (Functionality)	25%	Funktionsverfügbarkeit von Streaming, Tools, strukturierter Ausgabe, Parametern, Kontext, Fehlerantworten und Nutzungsmessung
Antwortgeschwindigkeit	P (Performance)	20%	Latenz bis zur ersten Antwort im Textkörper, Generierungsrate, effektiver Durchsatz bei Parallelität und effektive Cache-Treffer
Servicezuverlässigkeit	R (Reliability)	20%	Anteil der festen Request-Menge, der bei der ersten Ausführung wirksam abgeschlossen wird

Unabhängiges Bewertungsobjekt ist „Modellanbieter × Modellversion“, also der Dienst einer bestimmten Modellversion, den ein Modellanbieter bereitstellt. Jedes Objekt ergibt unter dem angegebenen Bewertungslauf und der angegebenen Konfiguration einen Satz von vier Dimensionswerten und einen Gesamtwert. Denkmodus, Request-Parameter, Service-Tier des Kontos, Testregion und Beobachtungszeitraum sind Messbedingungen und werden mit den Ergebnissen aufgezeichnet. Ergebnisse unter unterschiedlichen Bedingungen werden getrennt ausgewiesen und nicht direkt zusammengeführt. Lassen sich Modellversion, Region oder Service-Tier nicht verifizieren, wird der entsprechende unbestätigte Status vermerkt; es wird nichts als bestätigt angenommen. Die Bewertung wird über die AIHubMix API ausgeführt; die Ergebnisse beschreiben die tatsächlich beobachtete Leistung unter dieser Zugriffsart. Auch der offizielle Referenzdienst wird über die AIHubMix API gemessen und nicht als Ergebnis einer unabhängigen Direktverbindung zur offiziellen API ausgewiesen. Eine Vergleichsgruppe verwendet dasselbe Aufgabenset, dieselben Runden, Timeouts, Request-Budgets, dieselbe Fehlerbewertung und dieselben statistischen Methoden. Die gemäß der Anbieterdokumentation erforderlichen Request-Felder, Streaming-Strukturen und Nutzungsfelder werden von der Zugriffsadapterschicht (adapter) behandelt; das Messziel bleibt unverändert. Diese Methode dient nicht dem Ranking der Intelligenz verschiedener Modelle; die Identität des Modellanbieters stellt keinen Grund für eine Aufwertung dar.

Status der Scores

Status	Bedeutung
Regulär	Testregistrierung, Sampling, Bewertung und Evidenzprüfung wurden nach dem jeweiligen Standard abgeschlossen
Referenzergebnis (PROVISIONAL)	Ein Berechnungsergebnis liegt vor, jedoch bestehen Einschränkungen bei Sampling, Bewertung, Adapterregistrierung oder Evidenz
Nicht verfügbar (UNAVAILABLE)	Erforderliche Bewertung, Nenner oder Referenz fehlen; es wird kein numerischer Wert vergeben
Nicht vergleichbar	Modellkonfiguration, Beobachtungsbedingungen oder Ergebnisansicht stimmen nicht überein; das Ergebnis wird nicht in den gleichartigen Vergleich einbezogen

Fehlende Werte und 0 Punkte werden getrennt behandelt. Wenn ein Dienst eindeutig ausfällt oder eine erforderliche Fähigkeit nicht bereitstellt, wird dies nach der jeweiligen Regel als Fehler gewertet; bei fehlender Messung, unbekanntem Nenner oder unzureichender Evidenz bleibt der entsprechende Status erhalten. Ist eine Dimension nicht verfügbar, wird auch der Gesamtwert als nicht verfügbar markiert; ihre Gewichtung wird nicht auf andere Dimensionen umverteilt.

Interpretation der Ergebnisse

Rohkennzahlen werden mit der Bewertungsformel in die absolute Leistung A umgerechnet; nach relativer Referenz und Evidenzsynthese ergibt sich der Dimensionssynthesewert D. Der Gesamtwert verwendet D und gewichtet nicht direkt die rohe Korrektheitsrate, die Funktionsbestehensrate oder die Service-Erfolgsrate.
Der Score spiegelt die Leistung unter einem bestimmten Aufgabenset, einem Lastprofil, einer Region, einer Konfiguration und einem Beobachtungsfenster wider; die Anwendungsbedingungen werden mit den Ergebnissen aufgezeichnet.
Die Anzeigegenauigkeit gibt nicht die statistische Trennschärfe an. Unterschiede in der Antwortqualität werden zusammen mit den gepaarten statistischen Intervallen interpretiert; eine Einstufung als besser oder schlechter darf nicht allein anhand von Dezimalunterschieden erfolgen.
Der Gesamtwert ist ein zusammenfassender Index; er ist keine Zertifizierung und hat kein Konfidenzintervall. Statistische Schlussfolgerungen stützen sich auf die Evidenz der jeweiligen Dimension.
Bei der Servicezuverlässigkeit werden die Zahl der Erst-Erfolge, die Zahl der geplanten Gelegenheiten und das zweiseitige 95%-Intervall gemeinsam berichtet; dies darf nicht direkt als langfristige SLA interpretiert werden.

Werden nach Prüfung eine falsche Modellidentität, eine stille Kürzung der Eingabe, die Offenlegung sensibler Inhalte, eine schwerwiegende Protokollbeschädigung oder eine Abrechnungsanomalie bestätigt, wird das Ergebnis separat als „Zulassung nicht bestanden“ markiert; die Reproduktionsevidenz und die Nutzungseinschränkungen bleiben erhalten. Dimensions- und Gesamtwert heben diese Einschränkung nicht auf.

Gesamtwert und Dimensionssynthese

Gesamtformel

Der Gesamtwert wird durch gewichtete Berechnung der Syntheswerte der vier Dimensionen gebildet. D_Q, D_F, D_P und D_R stehen für die Syntheswerte von Antwortqualität, Funktionsunterstützung, Antwortgeschwindigkeit und Servicezuverlässigkeit.

Gesamtwert

Overall = 0.35 × D_Q + 0.25 × D_F + 0.20 × D_P + 0.20 × D_R

Alle vier Dimensionssyntheswerte verwenden eine Skala von 0–100. Der Gesamtwert fasst das Gesamtergebnis zusammen; die vier Dimensionswerte dienen der Identifikation konkreter Unterschiede.

Dreistufige Synthese

Jeder Dimensionssynthesewert D wird durch gewichtete Berechnung aus absoluter Leistung A, relativem Bezug zum offiziellen Referenzdienst B und Evidenzvollständigkeit C gebildet.

Dimensionswert

D = 0.65 × A + 0.20 × B + 0.15 × C

Eingabestufe	Gewichtung	Definition
A: absolute Leistung	65%	Tatsächliches Messergebnis nach dem festgelegten Test- und statistischen Verfahren
B: relativer Bezug zur offiziellen Referenz	20%	Abweichung der absoluten Leistung derselben Dimension vom offiziellen Referenzdienst
C: Evidenzvollständigkeit	15%	Grad, in dem Stichprobenabdeckung, Beobachtungskonsistenz und Messevidenz das vorliegende Ergebnis stützen

A, B und C sind Symbole der Berechnungsebene und bezeichnen keine Zugriffsstufe. Für die absolute Leistung gilt die festgelegte Formel; weder wird der schnellste oder höchstbewertete Dienst dieses Laufs auf 100 gesetzt noch eine Neunormierung pro Lauf vorgenommen. Der Teil vor dem Unterstrich bezeichnet die Berechnungsebene, der Teil danach die Bewertungsdimension. Beispielsweise ist A_F der Funktionsunterstützungswert der absoluten Leistungsebene und D_F der Funktionsunterstützungswert nach der dreistufigen Synthese. Für Hauptwert und Diagnosewerte gelten außerdem die folgenden Konfigurationssuffixe:

Kürzel	Englische Bezeichnung	Bedeutung und Verwendung
`F_native`	Native Functionality Score	Nativer Funktionsunterstützungswert, der gemäß der Anbieterdokumentation konfiguriert und ausgewertet wird; dient als `A_F` des Hauptwerts
`F_strict`	Strict Interface Compatibility Score	Strenger Kompatibilitätswert, der direkt anhand der AIHubMix-Schnittstellenvereinbarung geprüft wird; separate Diagnose
`K`	Cache Hit Score	Teilwert für effektive Cache-Treffer; fließt in die absolute Leistung der Antwortgeschwindigkeit ein
`K_native`	Native Cache Hit Score	Cache-Teilwert, gemessen mit der gemäß der Anbieterdokumentation erforderlichen Konfiguration; für den Hauptwert
`K_default`	Default-Configuration Cache Hit Score	Cache-Teilwert, gemessen ohne zusätzliche Sitzungsaffinitätskonfiguration; separate Diagnose

native bedeutet Konfiguration gemäß der Anbieterdokumentation, strict bedeutet strenge Schnittstellenprüfung, default bedeutet die in diesem Artikel definierte Standardkonfiguration. K ist das Cache-Symbol dieser Methode und bezeichnet nicht die Dimension Quality. Der Hauptwert verwendet einheitlich F_native und K_native; Diagnosewerte werden nicht mit dem Hauptwert vermischt.

Relativer Bezug zur offiziellen Referenz B

A_official bezeichnet den absoluten Leistungswert des offiziellen Referenzdienstes in der aktuellen Dimension; sein relativer Referenzwert B_official ist fest auf 50 gesetzt.

Relative Referenzstufe

B_official = 50
B = 50 + 50 × clip((A − A_official) / δ, −1, 1)

clip(x, −1, 1) ist eine Begrenzungsfunktion, die x auf −1 bis 1 beschränkt. Der Abweichungsparameter δ wird je Dimension definiert:

Dimension	δ
Antwortqualität Q	2
Funktionsunterstützung F	15
Antwortgeschwindigkeit P	10
Servicezuverlässigkeit R	2

Für die Antwortqualität wird die Abweichung vom offiziellen Referenzdienst mit einem gepaarten Aufgaben-Cluster-Bootstrap über 5,000 Wiederholungen geschätzt. Enthält das zweiseitige 95%-Intervall die 0, gilt B_Q = 50; enthält das Intervall die 0 nicht, wird die obige Abbildung angewendet. Der offizielle Referenzdienst durchläuft unabhängig eine Messung der absoluten Leistung; sein eigener B-Wert ist fest auf 50 gesetzt, und es wird keine volle Punktzahl vorausgesetzt. Wenn unterschiedliche Konfigurationen, Timeouts, Zeiträume oder Ergebnisansichten nicht vergleichbar sind, werden in die relative Stufe keine geschätzten Werte eingetragen.

Evidenzvollständigkeit C

C besteht aus den folgenden fünf Punkten mit je maximal 20 Punkten und einer Gesamtsumme von 100. Die einzelnen Punkte werden nach dem Abdeckungsgrad und der Evidenzlage in den Aufzeichnungen mit 20, 10 oder 0 Punkten bewertet:

Punkt	Prüfinhalt
Stichprobenabdeckung	Übereinstimmung der tatsächlich gültigen Aufzeichnungen mit dem geplanten Stichprobenumfang
Fensterabdeckung	Vollständigkeit der erforderlichen Zeiträume oder der Erfassungssegmente der Antwortqualität
Nutzungsvollständigkeit	Abdeckung und Verifizierbarkeit der ursprünglichen `usage`
Nennerevidenz	Nachprüfbarkeit der Nenner für Aufgabenbewertung, Funktionsentscheidung und Cache-Messung
Protokollkonsistenz	Übereinstimmung von Request-Konfiguration, Zuordnung der Aufzeichnungen und Beobachtungsprotokoll

C misst die Messevidenz und nicht unmittelbar die Modellfähigkeit. Jede Bewertung ist mit einer Evidenzaufzeichnung verknüpft; der Ergebnisstatus bleibt unabhängig erhalten; der Evidenzwert ersetzt nicht die erforderliche Prüfung der Datenvalidität.

Antwortqualität

Die Antwortqualität Q misst anhand von Referenzantworten und dem festgelegten Bewertungsprotokoll den Anteil korrekter Antworten an allen gültigen Aufgabeninstanzen.

Aufgabenset und Bewertung

Richtung	Messgegenstand	Aufgabenzahl × Runden	Geplante Instanzen	Bewertungsmethode
BFCL	Funktionsauswahl, Parameterbefüllung, parallele Aufrufe, Unterdrückung irrelevanter Aufrufe und dreistufige Tool-Kette	500 × 3	1,500	Python-only-JSON-Matching-Adapter auf Basis des offiziellen AST-Checkers der angegebenen Version
HLE	Nach Fachgebieten geschichtete, anspruchsvolle Textaufgaben zu Wissen und Reasoning	250 × 10	2,500	Antwortäquivalenz-Richter; Richtermodell, Prompt und Version werden aufgezeichnet
AA-LCR	Dokumentübergreifende Fragen zur Synthese mehrerer Dokumente mit etwa 74,000 bis 114,000 Token	25 × 10	250	Angegebene Dokumente und Referenzantworten; Bewertung nach Antwortäquivalenz
Gesamt	775 verschiedene Aufgaben	Ausführung nach den Rundenvorgaben der jeweiligen Richtung	4,250	Zusammenfassung über alle gültigen Instanzen

Absolute Leistung der Antwortqualität

A_Q = 100 × Zahl der korrekten Instanzen / Zahl der gültig gewerteten Instanzen

Vollständiger geplanter Nenner = 1,500 + 2,500 + 250 = 4,250

Die drei Richtungen werden nach Instanzzahl zusammengefasst; die Korrektheitsraten der einzelnen Richtungen werden nicht gleichgewichtet gemittelt. Mehrstufige Tool-Aufgaben können mehreren API-Requests entsprechen; Aufgabeninstanzen und Request-Zahl werden getrennt gezählt.

Dieses Aufgabenset ist ein abgeleitetes Aufgabenset der AF Suite und bildet keine exakte Teilmenge von Artificial Analysis dar; es reproduziert auch keine Ergebnisse aus deren Ranglisten. Die 50 BFCL-Mehrrundenaufgaben basieren auf echten Aufgaben und sind getrennt von der offiziellen zustandsbehafteten Mehrrunden-Ausführungsumgebung von BFCL definiert. Herkunft und Versionen finden Sie unter Herkunft der Datensätze.

Vergleichsbedingungen und Umgang mit fehlenden Werten

Die Aufgabenkorrektheit wird anhand der Referenzantworten entschieden; Antworten des offiziellen Referenzdienstes gelten nicht als Wahrheit.
Alle Parteien verwenden dasselbe kontrollierbare Budget, dieselbe Stichprobenanzahl und dieselben semantischen Äquivalenzparameter; lassen sich Denkmodus, Tool-Vorlage oder effort nicht angleichen, wird „Konfiguration nicht vergleichbar“ markiert.
Servicefehler, Timeouts, Verweigerungen und ausgeschöpftes Budget werden als Aufgabenfehler im Nenner gezählt.
Aufzeichnungen mit ungültigem Richter oder ohne gültige Bewertung werden separat gekennzeichnet, aus dem berechenbaren Nenner ausgeschlossen und behalten den Status eines Referenzergebnisses.
Die Regeln zum Aufgabenfilter werden bei der Testregistrierung festgelegt; der Bericht listet die geplante Zahl, die gefilterte Zahl und die tatsächlich gewertete Zahl getrennt auf.
Wiederholte Runden werden demselben Aufgabencluster zugeordnet und nicht als zusätzliche unabhängige Aufgaben behandelt.

Relative Abweichungen werden mit einem gepaarten Aufgaben-Cluster-Bootstrap je Richtung über 5,000 Wiederholungen ermittelt. Alle Parteien verwenden dieselben Aufgaben-Stichprobenindizes; berichtet wird das zweiseitige 95%-Intervall der Abweichung. Enthält das Intervall die 0, wird „kein Unterschied feststellbar“ markiert und die relative Referenzstufe auf 50 gesetzt.

Funktionsunterstützung

Die Funktionsunterstützung F misst, ob Schnittstellenfunktionen unter der festgelegten Konfiguration verfügbar sind; sie wird nicht erneut in die Korrektheitsrate der Aufgabenantworten eingerechnet.

Funktionsgruppen und Gewichtung

Funktionsgruppe	Gewichtung	Prüfinhalt
Streaming und Nachrichtenprotokoll	20%	Streaming-Inkremente, Ereignisreihenfolge, Abschlussblock, `finish_reason` und Position von `usage`
Tool-Schnittstelle	20%	Tool-Name, Schema, Parameterauswertung, parallele Aufrufe, Rückgabe von Tool-Ergebnissen und Fehlerbehandlung
Ausgabebeschränkungen und Parameter	20%	Tatsächliches Verhalten von `temperature`, `max_tokens`, `stop`, strukturierter Ausgabe und Denk-Konfiguration
Kontext und Zustand	15%	Fenstergrenzen, Umgang mit Überschreitung, Verlaufsnachrichten und Vollständigkeit langer Eingaben
Fehler und Wiederherstellung	15%	Übereinstimmung von Fehlercodes, Fehlerobjekten, Rate-Limiting und Retry-Semantik mit den Dokumentationsvereinbarungen
Messung und Cache-Protokoll	10%	Vollständigkeit von `usage`, Selbstkonsistenz der Summen und Cache-Messung

f[组] (Functional Group Pass Score, Bestehensrate der Funktionsgruppe) bezeichnet die Bestehensrate der gültigen anwendbaren Instanzen einer einzelnen Funktionsgruppe. Die Formelzeichen f流式, f工具, f约束, f上下文, f错误, f计量 entsprechen den sechs Gruppen der Tabelle.

Absolute Leistung der Funktionsunterstützung

f[组] = 100 × Zahl der bestandenen Instanzen / Zahl der gültigen anwendbaren Instanzen
A_F = 0.20 × f流式 + 0.20 × f工具 + 0.20 × f约束
    + 0.15 × f上下文 + 0.15 × f错误 + 0.10 × f计量

Jede Gruppe umfasst 10 Fälle; jeder Fall wird in 3 Fenstern einmal ausgeführt, insgesamt 60 Fälle und 180 Entscheidungen. Vorgeschriebene Wiederholungsrequests innerhalb eines Falls werden separat aufgezeichnet und ändern weder Fallgruppierung noch Gewichtung.

Entscheidungsstatus

Status	Bedeutung	Aggregationsbehandlung
PASS	Alle anwendbaren Prüfpunkte bestanden	Wird als bestanden und als gültige anwendbare Instanz gezählt
FAIL	Fehlende Funktion, Vertragsverstoß, falscher Wert oder unerwarteter Dienstfehler	Wird als gültige anwendbare Instanz gezählt, nicht als bestanden
NA	Die Fähigkeit wird vom Modell nativ nicht unterstützt; ausreichende Evidenz liegt vor und wurde vorab registriert	Aus dem anwendbaren Nenner ausgeschlossen
UNTESTED	Test nicht ausgeführt	Bei unzureichenden Pflichtprüfungen bleibt der Status eingeschränkt oder nicht verfügbar
INVALID	Testwerkzeug, Fixture oder Konfigurationsevidenz ungültig; keine Zurechnung zum getesteten Dienst möglich	Wird nicht als Funktionsfehler gewertet; gültiger Nenner und Evidenzeinschränkungen werden aufgezeichnet
UNOBSERVED	Vorheriger Schritt abgebrochen; keine nachfolgende Beobachtung	Wird nicht als bestanden gewertet; Status fehlender Beobachtung bleibt erhalten

Der native Fähigkeitswert wird auf Basis der gültigen anwendbaren Aufzeichnungen berechnet. Liegen INVALID- oder UNOBSERVED-Fälle vor, werden Einschränkungen bei Abdeckung und Nenner offengelegt; fehlt für erforderliche Prüfungen die Evidenz, ist der strenge Kompatibilitätswert nicht verfügbar. Eine Fähigkeit, die das Modell nativ unterstützt, der Dienst jedoch nicht bereitstellt, wird als FAIL gewertet und darf nicht als NA eingeordnet werden.

Native Fähigkeiten und Schnittstellenkompatibilität

Kennzahl	Englische Bezeichnung und Bedeutung	Prüfgrundlage	Verwendung
`F_native`	Native Functionality Score, nativer Funktionsunterstützungswert	Felder, Streaming-Struktur und erforderliche Request-Konfiguration werden gemäß der Anbieterdokumentation interpretiert; Vorhandensein und semantische Korrektheit der Funktion werden geprüft	Als `A_F` des Hauptwerts
`F_strict`	Strict Interface Compatibility Score, strenger Schnittstellenkompatibilitätswert	Felder, Ereignisstruktur und Rückgabeverhalten werden direkt anhand der AIHubMix-Schnittstellenvereinbarung geprüft	Separate Schnittstellenkompatibilitätsdiagnose

Sind Felder vorhanden und entsprechen Position oder Benennung der Anbieterdokumentation, wird die native Fähigkeitsprüfung nach der tatsächlichen Struktur ausgewertet. Fehlen Felder vollständig, sind Werte falsch oder widersprüchlich, wird nach dem tatsächlichen Prüfergebnis entschieden. Die Adapterschicht behält Originalfelder und Zuordnungsgrundlage bei und nimmt unbekannte Werte nicht als bestandene Funktion an. F_native und F_strict werden getrennt berichtet und dürfen in derselben Vergleichstabelle nicht abwechselnd als Hauptwert verwendet werden. Der Anteil effektiver Cache-Treffer fließt in die Antwortgeschwindigkeit ein; die Abrechnungsgenauigkeit wird separat geprüft.

Antwortgeschwindigkeit

Die Antwortgeschwindigkeit P setzt sich aus der Antwortleistung des Textkörpers und den effektiven Cache-Treffern zusammen. Der Hauptwert verwendet K_native.

Last und Stichproben

Das Nicht-Denkprofil I (Non-thinking Profile, Lastprofil ohne Denken) und das Denkprofil T (Thinking Profile, Lastprofil mit Denken) werden getrennt gemessen und berichtet. I und T sind Lastprofilkennungen; Profil I setzt native Unterstützung des Nicht-Denkmodus durch das Modell voraus, Profil T zeichnet effort, Denkbudget und Ausgabebudget auf. C1 (Concurrency 1, Einzelparallelität) und C10 (Concurrency 10, 10er-Parallelität) bezeichnen die Anzahl gleichzeitig ausgeführter Requests. C steht hier für Concurrency und wird getrennt vom C der Evidenzvollständigkeitsebene verwendet.

Konfigurationspunkt	Messvereinbarung
Eingabe	10,000 ± 2% Token, gemessen mit `o200k_base`; am Anfang der Eingabe wird ein eindeutiges Präfix eingefügt, um unerwartete Cache-Treffer zu kontrollieren
Ausgabe	1,000 bis 1,200 Antworttext-Tokens, einschließlich fester Prüfpunkte
Timeout	300 Sekunden, innerhalb derselben Vergleichsgruppe einheitlich
Einzelparallelität C1	90 (3 Fenster × 30)
10er-Parallelität C10	90 (3 Fenster × 30)
Cache-Untertest	30 (3 Fenster × zwei Stufen 8k/32k × 5)
Isolierung	Antwortqualität und Antwortgeschwindigkeit werden getrennt ausgeführt; für die Antwortgeschwindigkeit wird ein eigener Messzeitraum verwendet

Der Parallelitätstest verwendet einen geschlossenen Nachschubmechanismus: Nach Abschluss eines Requests wird ein weiterer Request gesendet. C10 bezeichnet das Beobachtungsergebnis unter dieser Last und stellt keine vollständige Kapazitätskurve dar.

Zeitmessung und gültige Ausgabe

Kennzahl	Englische Bezeichnung	Definition und Verwendung
Messstart	Measurement Start Time	Zeitpunkt, zu dem nach dem Aufbau der vorab hergestellten Verbindung das Schreiben des eigentlichen Requests beginnt; der Kaltstart der Verbindung wird separat aufgezeichnet
TTFT	Time to First Token	Wartezeit bis zum ersten tatsächlichen Reasoning-, Antworttext- oder Tool-Parameter-Payload; leere Rollen- und Heartbeat-Ereignisse werden nicht gezählt; dient als Rohkennzahl
TTFA	Time to First Answer	Wartezeit bis zum ersten nicht leeren finalen Antworttextfragment, einschließlich der vorherigen Denkzeit; wird für die Latenzbewertung verwendet
TPOT	Time per Output Token	Durchschnittliche Zeit pro Token in der Antworttext-Generierungsphase, berechnet aus den Zeitpunkten des ersten und letzten Textfragments und der entsprechenden Token-Zahl
goodput	Valid-Output Throughput	Rate gültiger Antworttext-Tokens, die während der vollständigen Wanduhrzeit des C10-Fensters die Korrektheits- und Vollständigkeitsanforderungen erfüllen

Wird der Antworttext in einem einzigen Block zurückgegeben, wird TPOT als ungültig markiert; daraus wird keine Token-für-Token-Rate konstruiert. Die Bewertungsstatistik verwendet den P50 (50th Percentile, das 50. Perzentil, also den Median) einschließlich der Behandlung von Fehlern; zusätzlich werden der empirische P95 (95th Percentile, das 95. Perzentil) und Schwankungen zwischen Fenstern berichtet. 90 Stichproben pro Stufe stützen keine P99-Schlussfolgerung (99th Percentile, das 99. Perzentil). P steht hier für Percentile und wird getrennt vom Dimensionssymbol P der Antwortgeschwindigkeit verwendet.

Bewertungsformel

Die Funktionsnamen und Teilwertsymbole in diesem Abschnitt sind Berechnungsnotationen dieser Methode und haben folgende Bedeutung:

Kürzel	Englische Bezeichnung	Bedeutung
`S(x; τ)`	Latency Score Function	Funktion, die die Wartezeit x in einen Latenz-Teilwert umrechnet; τ ist der Latenzmaßstab
`L(x; t, k)`	Lower-is-Better Score Function	Bewertungsfunktion, bei der niedrigere Werte besser sind; in diesem Abschnitt für TPOT verwendet, t ist das Ziel für volle Punktzahl, k der Bereichsfaktor
`H(x; t)`	Higher-is-Better Score Function	Bewertungsfunktion, bei der höhere Werte besser sind; in diesem Abschnitt für den effektiven Durchsatz verwendet, t ist das Ziel für volle Punktzahl
`l_ttfa`	Answer Latency Subscore	Teilwert der Latenz bis zur ersten Antwort; es wird der kleinere der Bewertungsergebnisse von C1 und C10 verwendet
`l_tpot`	Output Token Time Subscore	Teilwert der Zeit pro Antworttext-Token; es wird der kleinere der Bewertungsergebnisse von C1 und C10 verwendet
`P_response`	Response Performance Score	Teilwert der Antwortleistung, gebildet aus Latenz, Zeit pro Token und effektivem Durchsatz, ohne Cache-Teilwert
`P50_TTFA_C1`, `P50_TTFA_C10`	Median Time to First Answer at Concurrency 1 / 10	TTFA-Median einschließlich Fehlerbehandlung bei Einzel- bzw. 10er-Parallelität
`P50_TPOT_C1`, `P50_TPOT_C10`	Median Time per Output Token at Concurrency 1 / 10	TPOT-Median einschließlich Fehlerbehandlung bei Einzel- bzw. 10er-Parallelität

A_P ist der absolute Wert der Antwortgeschwindigkeit einschließlich Antwortleistung und Cache-Teilwert; D_P ist der Dimensionswert der Antwortgeschwindigkeit, der zusätzlich die relative Referenz und die Evidenzsynthese durchlaufen hat und in den Gesamtwert eingeht. Das folgende clip begrenzt Werte auf 0 bis 1, ln ist der natürliche Logarithmus, min bezeichnet den kleineren Wert und Σ die Summation. τ, b, c und k in den Formeln werden in der unmittelbar folgenden Parametertabelle definiert:

Absolute Leistung der Antwortgeschwindigkeit

S(x; τ) = 100 × τ / (τ + x)
L(x; t, k) = 100 × clip[ln(k·t/x) / ln(k)]
H(x; t) = 100 × clip[ln(x / (0.05·t)) / ln(20)]

l_ttfa = min(S(P50_TTFA_C1; τ), S(P50_TTFA_C10; τ))
l_tpot = min(L(P50_TPOT_C1; b, 10), L(P50_TPOT_C10; b, 10))

goodput = Σ gültige Anfragen min(Antworttext-Tokens, 1000) / Σ C10-Fenster-Wanduhrzeit

P_response = 0.35 × l_ttfa + 0.35 × l_tpot + 0.30 × H(goodput; c)
A_P = 0.80 × P_response + 0.20 × K_native

Parameter	Englische Bezeichnung	Wert	Bedeutung
τ	Latency Scale	2 Sekunden	TTFA, bei dem der Latenz-Teilwert 50 erreicht
b	Target Time per Output Token	5 ms/token	Ziel für volle Punktzahl bei TPOT; bei Erreichen oder Unterschreiten 100
c	Target Valid-Output Throughput	1,200 token/s	Ziel für volle Punktzahl beim effektiven C10-Durchsatz; bei Erreichen oder Überschreiten 100
k	TPOT Range Multiplier	10	Bereichsfaktor der logarithmischen TPOT-Abbildung

Die genannten Ziele gelten für die in diesem Standard festgelegten Lasten und stellen keine allgemeinen Schwellen für alle Modelle und alle Arbeitslasten dar.

TTFA	0 Sekunden	1 Sekunde	2 Sekunden	4 Sekunden	10 Sekunden
Latenz-Teilwert	100	66.7	50	33.3	16.7

Ungültige Ausgaben und Messisolierung

Ausgaben mit abweichender Länge, falschen Prüfpunkten, degenerativen Schleifen, Fehlern im Stream, abnormalem Abbruch oder Kürzung werden als ungültig gewertet und weiterhin in Last und Zeitaufwand eingerechnet. Vor der Berechnung des P50 werden folgende Behandlungen angewendet:

TTFA wird als positiv unendlich gewertet, der Latenz-Teilwert beträgt 0.
TPOT wird als 10b gewertet, also 50 ms/token.
Der Beitrag ungültiger Ausgaben zum goodput ist 0; die Zeit bleibt im entsprechenden C10-Fenster erhalten.
Die ursprünglich gemessene Dauer wird separat aufbewahrt und nicht durch den Bewertungswert überschrieben.

Zusätzlich werden die Zahl gültiger Requests, die geplante Zahl und die Rate gültiger Ausgaben berichtet. Leistungsergebnisse enthalten den Einfluss von Dienstfehlern auf die Bereitstellung und dürfen nicht allein anhand der Latenz erfolgreicher Requests interpretiert werden.

Cache-Treffer

Der Cache-Teilwert K (Cache Hit Score, Teilwert effektiver Cache-Treffer) misst den Anteil der Tokens in einem erwartbar wiederverwendbaren Präfix, die tatsächlich als Cache-Lesevorgänge gemeldet werden. Für jede Länge werden zunächst Lesemenge und erwartbar wiederverwendbare Menge der Warm-Requests summiert; anschließend werden die beiden Längen 8k und 32k gleichgewichtet aggregiert.

Kürzel	Englische Bezeichnung	Bedeutung
`K_length`	Length-Specific Cache Hit Score	Teilwert effektiver Cache-Treffer für eine Präfixlängenstufe
`K_8k`	8k-Prefix Cache Hit Score	Teilwert effektiver Cache-Treffer für die Präfixstufe von etwa 8k Token
`K_32k`	32k-Prefix Cache Hit Score	Teilwert effektiver Cache-Treffer für die Präfixstufe von etwa 32k Token
`cache_read_native_tokens`	Cache-Read Native Token Count	Anzahl nativer Token, die bei Warm-Requests tatsächlich als Cache-Lesevorgänge gemeldet werden, ohne Cache-Schreibvorgänge
`expected_reusable_native_tokens`	Expected Reusable Native Token Count	Anzahl nativer Präfix-Token, die nach der Regel wiederverwendbar sein sollten; dient als Nenner der Trefferrate

native_tokens bezeichnet hier Token, die mit dem angegebenen nativen Tokenizer gemessen werden, und wird getrennt von native in K_native interpretiert, das die Konfiguration gemäß der Anbieterdokumentation bezeichnet.

Cache-Treffer-Teilwert

K_length = 100 × Σ Warm-Requests cache_read_native_tokens
                 / Σ Warm-Requests expected_reusable_native_tokens

K = (K_8k + K_32k) / 2

Eine nach Tokens gewichtete Trefferrate über verschiedene Längen kann als Diagnosekennzahl dienen und ersetzt nicht das gleichgewichtete K des Hauptwerts.

Testsequenz und Nenner

Jede Gruppe verwendet ein festes langes Präfix und wechselnde neue Fragen, insgesamt 5 Requests:

Der erste Request schreibt in den Cache; am Anfang des Präfixes wird eine unabhängige Zufallskennung eingefügt, um verschiedene Testgruppen zu isolieren.
Bei den Requests 2 bis 4 bleibt das Präfix byteidentisch; am Ende wird jeweils eine andere kurze Frage verwendet. Die Requests werden 5 Sekunden, 30 Sekunden und 120 Sekunden nach Abschluss des vorherigen Requests gesendet.
Der fünfte Request verwendet ein vollständig unabhängiges neues Präfix als Kaltkontrolle.

Die drei Fenster decken jeweils die Stufen etwa 8k und 32k ab, insgesamt 30 Requests. Nur die Requests 2 bis 4 gehen in die Bewertung warmer Treffer ein; für jede Länge ergeben sich 9 Gelegenheiten für Warm-Requests. Der erste Schreibvorgang und die Kaltkontrolle werden separat geprüft. Der Nenner verwendet die registrierte Anzahl nativer Token des erwartbar wiederverwendbaren Präfixes auf Basis des angegebenen Tokenizers, Templates und der Cache-Regeln. Neue Fragen und nicht wiederverwendbare Teile werden separat identifiziert; der Nenner wird nicht durch alle Eingabe-Tokens, die tatsächliche Treffermenge oder eine Zählung mit o200k_base ersetzt. Blockweise gemeldete Lesemengen werden mit Originalwert und Blockgröße aufbewahrt. Der Hauptwert verwendet K_native: Die gemäß der Anbieterdokumentation für das Caching erforderliche Konfiguration wird aktiviert; erforderliche Sitzungsaffinitätsfelder werden von der Zugriffsadapterschicht behandelt. K_default zeichnet das Ergebnis ohne zusätzliche Sitzungsaffinitätskonfiguration auf und dient als Diagnose der Standardkonfiguration. Alle Anbieter folgen demselben Prinzip zur Bestimmung der Konfiguration; der Bericht behält die konkrete Konfiguration bei.

Anomalien und nicht beobachtbare Fälle

Fall	Behandlung
Erwartbar wiederverwendbarer Nenner unbekannt	K nicht verfügbar, nicht als 0 erfassen
Erfolgreichen Requests fehlt das Cache-Lesefeld	Standardmäßig als nicht beobachtbar erfassen; nur wenn die Dokumentation das Weglassen bei null Treffern ausdrücklich vorsieht, dies registriert wurde und die Evidenz übereinstimmt, als 0 interpretieren
Lesemenge übersteigt den Nenner oder Felder widersprechen sich	Anomalie und Originalwert aufzeichnen, nicht auf 100% kürzen
Kaltkontrolle erfolgreich und Lesemenge 0	Kann als Kaltkontroll-Evidenz dienen; eine nicht abgeschlossene Kontrolle behält den eingeschränkten Status
Warm-Request fehlgeschlagen und Nenner bestimmbar	Lesemenge als 0 einbeziehen; der fehlgeschlagene Datensatz wird separat ausgewiesen
Modell unterstützt Caching nativ, Dienst stellt es nicht bereit	K = 0
Modell unterstützt Caching nativ nicht und dies wurde vorab definiert	Separate No-cache-Stufe, `A_P = P_response`, getrennte Berichterstattung von der Stufe mit Cache
Trefferzählung nicht unterstützt	K und P als nicht verfügbar markieren, Cache-Gewichtung nicht verschieben

usage kann nur die über die Schnittstelle gemeldete Cache-Lesemenge belegen. Tatsächliche Kosten dürfen erst nach Prüfung als verifiziert markiert werden; ein Cache-Treffer bedeutet nicht, dass die Nutzung kostenlos ist, und garantiert auch keine niedrigeren Gesamtkosten.

Servicezuverlässigkeit

Die Servicezuverlässigkeit R misst den Anteil der festen Request-Menge, die beim ersten Versuch wirksam abgeschlossen wird; die Bewertung verwendet weder automatische Wiederholungen noch Fallback zwischen Modellanbietern:

Absolute Leistung der Servicezuverlässigkeit

A_R = 100 × Zahl der wirksamen Erstabschlüsse / Zahl der gültigen geplanten Gelegenheiten

Vollständige geplante Gelegenheiten = 300

Testmenge und Erfolgsbedingungen

Der Test umfasst 300 Gelegenheiten, verteilt auf 3 Fenster mit je 100 Gelegenheiten. Je 100 Gelegenheiten verwenden dieselbe Aufgabenkombination: 40 kurze Texte, 30 lange Eingaben mit etwa 10k, 20 Tool-Protokollaufrufe und 10 Einzelaufrufe mit Mehrrundenverlauf. Tool-Aufgaben verwenden einen vorgefertigten gültigen Verlauf, damit der Bewertungsnenner stabil bleibt. Standardmäßig gilt Einzelparallelität; die Request-Rate liegt innerhalb der verifizierten RPM- und TPM-Kontingente. Diese Suite wird unabhängig ausgeführt und mischt keine Aufgaben der Antwortqualität, keine negativen Funktionsfälle, keine Diagnose-Wiederholungen sowie keine Vorwärm- oder Lasttest-Requests ein. Ein Erst-Erfolg erfordert gleichzeitig:

Der HTTP-Status entspricht der Erwartung; Antwortstruktur und Ereignisreihenfolge sind gültig.
Antworttext oder Tool-Payload ist nicht leer und endet ordnungsgemäß.
Es gibt keine Fehler im Stream, keine unerwartete Kürzung und keine fehlenden Pflichtfelder.
Die vorgeschriebenen usage-Felder sind vollständig und werden gemäß der jeweiligen Schnittstellenstruktur ausgewertet.
Der Abschluss erfolgt innerhalb der Frist von 300 Sekunden.

HTTP 200 allein reicht nicht für die Erfolgsfeststellung; falsche Aufgabenantworten und Dienstfehler werden getrennt gezählt.

Fehler, ungültige Aufzeichnungen und Intervalle

429 innerhalb des Kontingents, Serverfehler, Verbindungsfehler, Timeouts, leere Antworten, Stream-Abbrüche und anomale Kürzungen werden als Fehler gewertet. Wenn ein Fehler des Modellanbieters dazu führt, dass ein geplanter Request nicht gesendet werden kann, wird dies als Fehler gewertet und der Grund aufgezeichnet. Anomalien der Testumgebung oder des Testwerkzeugs werden als INVALID markiert, nicht dem getesteten Dienst zugerechnet; die Zahl gültiger Gelegenheiten und die Abdeckungsbeschränkungen bleiben erhalten. Diagnose-Requests werden separat aufgezeichnet und ersetzen nicht das Erst-Ergebnis. Die Erfolgsrate wird mit einem zweiseitigen 95%-Clopper–Pearson-Intervall berichtet. Bei 300/300 beträgt die beobachtete Erfolgsrate 100%, die untere Intervallgrenze liegt bei etwa 98.78%; dies belegt weiterhin keine langfristige Service-Erfolgsrate von 100%. Die Fehlerverteilung und die längste aufeinanderfolgende Fehlerserie werden je Fenster und Aufgabenkategorie aufgezeichnet.

Testumfang und Vergleichbarkeit

Stichprobenumfang

Die folgenden Angaben bezeichnen den geplanten Umfang von AF Full innerhalb der AF Suite:

Punkt	Geplanter Umfang pro Anbieter	Zusammensetzung
Antwortqualität	4,250 Instanzen	BFCL 1,500; HLE 2,500; AA-LCR 250
Funktionsunterstützung	180 Entscheidungen	60 Fälle × 3 Fenster
Antwortgeschwindigkeit	180 Requests	C1/C10 je 90 (verteilt auf 3 Fenster)
Cache	30 Requests	3 Fenster × zwei Präfixlängen × 5
Servicezuverlässigkeit	300 Gelegenheiten	3 Fenster × 100

Aufgabeninstanzen, API-Requests und Richter-Requests werden getrennt gezählt; mehrstufige Tool-Aufgaben und Wiederholungen innerhalb eines Falls können zusätzliche Requests verursachen.

Ausführungsbedingungen

Dieselbe Vergleichsgruppe verwendet einheitlich Aufgabenset, Runden, Timeout, Temperatur, Ausgabebudget, Fehlerbehandlung und Bewertungsformel.
Es werden derselbe Client, dieselbe Netzwerkregion und dieselbe Verbindungsstrategie verwendet; Service-Tier des Kontos, tatsächliche Start- und Endzeiten sowie Ausführungsreihenfolge werden aufgezeichnet.
Der vollständige Test verwendet 3 Fenster mit mindestens 60 Minuten Abstand; Antwortqualität und Antwortgeschwindigkeit werden getrennt ausgeführt.
Modell-ID, Authentifizierung, erforderliche Felder, Streaming-Format, Nutzungszuordnung, Cache-Semantik und Tokenizer-Grundlage bilden die Adapteraufzeichnung.
Die Zugriffsadaption wird vor dem Sampling registriert und validiert; dieselbe Regel gilt für alle qualifizierten Modellanbieter.
Die Hauptansicht der Bewertung verwendet einheitlich F_native und K_native; Kompatibilitäts- und Standardkonfigurationsdiagnosen werden getrennt berichtet.
Ergebnisse der ersten Ausführung bleiben dauerhaft erhalten; geplante Menge, tatsächliche Menge, Filter, Fehler, ungültige und nicht beobachtete Aufzeichnungen werden getrennt geprüft.

Der Test wird innerhalb der genehmigten Kontingente, Berechtigungen und Kostenrahmen ausgeführt. Sind erforderliche Bedingungen nicht erfüllt, behalten die Ergebnisse den Status eingeschränkt, unvollständig oder nicht verfügbar; die verbleibenden Punkte werden nicht neu normiert.

Herkunft der Datensätze und Ergebnisaufzeichnung

Herkunft der Datensätze

Für die Antwortqualität wird ein versioniertes abgeleitetes Aufgabenset verwendet; Herkunft, Stichprobenaufzeichnungen und Integritätsprüfungen bleiben erhalten. Das Aufgabenset der Antwortqualität von AF Full enthält 775 verschiedene Aufgaben; die Herkunftssnapshots lauten wie folgt:

Richtung	Herkunftssnapshot	Versionsaufzeichnung	Lizenz und Nutzungsgrenzen
BFCL	Berkeley Function Calling Leaderboard Daten und Checker	`6ea57973c7a6`	Quellrepository Apache-2.0; diese Bewertung verwendet ein abgeleitetes Aufgabenset und eine Prüfanpassung
HLE	Textspiegel-Snapshot; offizieller Datensatz	Spiegel `e3e9cb5a550e`	Quelle ist als MIT ausgewiesen; byteweise Gleichheit mit der aktuellen offiziellen Version wurde nicht verifiziert
AA-LCR	Artificial Analysis AA-LCR Daten- und Dokumentations-Snapshot	`9a77ef56b717`	Datensatzrepository Apache-2.0; Rechte Dritter an referenzierten Dokumenten verbleiben bei den jeweiligen Rechteinhabern

BFCL wird nach Kategoriequoten gesampelt; HLE und AA-LCR werden proportional geschichtet gesampelt, wobei eine Mindestabdeckung jeder Schicht sichergestellt wird. Das Sampling verwendet den angegebenen Seed und eine SHA-256-Sortierung; Aufgabenset-Version, Filterliste und Bewertungsprotokoll werden mit den Ergebnissen aufgezeichnet. Die oben genannten Links dienen der Prüfung der Originalquellen und sind kein vollständiges Bewertungspaket, mit dem AF-Werte direkt reproduziert werden können. Eingeschränkte Daten werden in diesem Artikel nicht weitergegeben; für die konkrete Lizenz gilt die jeweilige Quelle.

Ergebnisaufzeichnung und Prüfung

Anbieterberichte werden einheitlich als AF Profile bezeichnet und enthalten folgende Bewertungsinformationen:

Aufzeichnungskategorie	Erforderlicher Inhalt
Bewertungsidentität	Standard- und Aufgabenset-Version, Modellanbieter, genaue Modellversion und offizieller Referenzdienst
Messbedingungen	Denk-Konfiguration, Kontostufe, Region, Zeitraum, Timeout, Parallelität und Leistungsparameter
Adaptionsgrundlage	Datum der Dokumentationsprüfung, erforderliche Felder, Streaming-Struktur, Nutzungsauswertung und Cache-Konfiguration
Stichprobenabdeckung	Geplante Zahl, tatsächliche Zahl, Bewertungsnenner, Filter, Fehler, ungültige und nicht beobachtete Punkte
Bewertungsgrundlage	Referenzantworten, Checker- oder Richter-Konfiguration, Bewertungsstatus und Abweichungsbewertung
Rohmessung	Redigierte Requests und Antworten, Ereigniszeiten, Status, Abbruchgründe und ursprüngliche `usage`
Aggregierte Ergebnisse	A/B/C-Eingaben der Stufen, vier D-Werte, Gesamtwert, Dimensionsintervalle und ungerundete Werte
Diagnosekennzahlen	`F_strict`, `K_default`, Gültigkeitsrate, Fehlerkategorien und zugehörige Nutzungseinschränkungen

Serviceerfolg, Aufgabenkorrektheit und gültige Ausgabe werden jeweils getrennt gekennzeichnet. Negative Fälle fließen nicht in den Servicezuverlässigkeitswert ein; Cache-Lese- und Schreibvorgänge werden getrennt gemessen; geschätzte und tatsächliche Kosten werden mit getrenntem Prüfstatus aufgezeichnet. Vor der externen Darstellung werden Schlüssel, Benutzerkennungen und sensible Inhalte entfernt; numerische Werte erhalten Einheiten, fehlende Werte behalten ihren Status.

Referenzdaten und Berechnungsbeispiel

Im Folgenden wird die Berechnungsmethode anhand der Ergebnisse von fünf Diensten für DeepSeek V4.1 Flash 1017 erläutert. Der Hauptwert verwendet F_native und K_native. Werte werden mit zwei Dezimalstellen dargestellt; Berechnungen basieren auf den in der Ergebnisdatei gespeicherten Zwischenwerten.

Dieser Abschnitt enthält Referenzergebnisse (PROVISIONAL). Die vorab registrierte Evidenz für Erfassung und Adaption ist unvollständig; die Angaben sind keine offiziellen AF Full-Ergebnisse des AIHubMix Fidelitas Standard. In die Antwortqualität gehen je Anbieter 4,240 Instanzen ein, zusätzlich 10 gefilterte Instanzen. Die Richter für HLE/AA-LCR gehören zur selben DeepSeek-Familie wie die getesteten Modelle; unabhängige Kalibrierungsevidenz ist unzureichend. Die Ergebnisse beschränken sich auf die aufgezeichnete Konfiguration und den beobachteten Bereich.

Absolute Leistung und Cache-Teilwerte

In der folgenden Tabelle sind Q, F, P und R absolute Leistungswerte A und nicht unmittelbar die vier Dimensionswerte des Gesamtwerts. K ist der Cache-Teilwert innerhalb von P.

Modellanbieter	A_Q	F_native (A_F)	A_P	K_native	A_R
ByteDance	42.05	74.98	84.37	93.83	100.00
Baidu	38.00	88.39	37.77	68.85	100.00
Alibaba Cloud	41.75	89.78	88.58	99.37	100.00
offizielle DeepSeek-Referenz	42.45	94.00	86.14	98.38	100.00
Fireworks	41.42	71.78	79.51	60.68	100.00

Alle fünf Dienste erreichen in der Servicezuverlässigkeits-Suite 300/300; Dienstfehler in anderen Suites werden weiterhin in ihrer jeweiligen Dimension gezählt und dürfen nicht durch das Ergebnis der R-Suite ersetzt werden.
Fireworks verwendet für K_native die in der Dokumentation vorgeschriebene Sitzungsaffinitätskonfiguration; die übrigen Dienste werden gemäß den Anforderungen ihrer jeweiligen Dokumentation gemessen.
Für Baidu folgt K der Stichprobenregel, dass ein bei null Treffern weggelassenes Feld als 0 interpretiert wird; die zugehörige vorab registrierte Evidenz ist unvollständig. Bei der 8k-Kaltkontrolle gibt es einen nicht abgeschlossenen Datensatz; K behält den Referenzstatus.
F_strict ist für DeepSeek wegen 27 INVALID-Aufzeichnungen nicht verfügbar; F_native wird auf Basis der gültigen anwendbaren Aufzeichnungen berechnet.

Dimensionssynthese der Funktionsunterstützung

Am Beispiel von Alibaba Cloud: Der absolute Funktionsunterstützungswert ist A_F = 89.777778, der entsprechende absolute Wert des offiziellen Referenzdienstes ist 94, der Abweichungsparameter δ_F = 15, die Evidenzvollständigkeit C_F = 100. Zuerst wird der relative Referenzwert B_F berechnet, anschließend der Dimensionswert D_F synthetisiert:

Relativer Bezug und Funktionsdimensionswert

B_F = 50 + 50 × clip((89.777778 − 94) / 15, −1, 1)
    ≈ 35.925926

D_F = 0.65 × 89.777778 + 0.20 × 35.925926 + 0.15 × 100
    ≈ 80.540741

89.78 bezeichnet die absolute Leistung der nativen Funktion, 80.54 den dargestellten Funktionsdimensionswert, der in den Gesamtwert eingeht.

Servicezuverlässigkeitswert der offiziellen Referenz

Die R-Suite der offiziellen Referenz erreicht 300/300; der absolute Servicezuverlässigkeitswert ist A_R = 100, der relative Referenzwert B_R = 50, die Evidenzvollständigkeit C_R = 100:

Dimensionssynthese der Servicezuverlässigkeit

D_R = 0.65 × 100 + 0.20 × 50 + 0.15 × 100
    = 90

100% ist die beobachtete Erfolgsrate der Servicezuverlässigkeits-Suite dieses Laufs; 90 ist der Dimensionsanzeigewert nach der dreistufigen Synthese.

Dimensionsanzeigewerte und Gesamtwert

Die folgende Tabelle verwendet D-Werte und entspricht der Gesamtformel. Die Tabellenreihenfolge folgt der Anzeigereihenfolge der Dienste und nicht dem Punktestand.

Modellanbieter	Antwortqualität D_Q	Funktionsunterstützung D_F	Antwortgeschwindigkeit D_P	Servicezuverlässigkeit D_R	Gesamtwert
ByteDance	50.83	62.24	76.57	88.50	66.37
Baidu	36.70	75.71	36.55	87.00	56.48
Alibaba Cloud	52.13	80.54	85.01	90.00	73.38
offizielle DeepSeek-Referenz	52.59	84.60	80.99	90.00	73.76
Fireworks	50.42	60.16	68.55	88.50	64.10

Am Beispiel der offiziellen Referenz:

Gesamtwertberechnung

Overall = 0.35 × 52.594340 + 0.25 × 84.600000
        + 0.20 × 80.990116 + 0.20 × 90.000000
        ≈ 73.76

Unabhängige Diagnosekennzahlen

Modellanbieter	F_strict	K_default
ByteDance	56.83	93.83
Baidu	66.17	68.85
Alibaba Cloud	89.78	99.37
offizielle DeepSeek-Referenz	Nicht verfügbar	98.38
Fireworks	71.78	11.06

F_strict drückt die Schnittstellenkompatibilität aus, K_default das Cache-Ergebnis ohne zusätzliche Sitzungsaffinitätskonfiguration. Keine der beiden Spalten ersetzt die Eingabe des Hauptwerts. Bei den Abweichungsintervallen der Antwortqualität gegenüber der offiziellen Referenz enthalten die 95%-Intervalle von ByteDance, Alibaba Cloud und Fireworks jeweils die 0; entsprechend gilt B_Q = 50. Die Abweichung von Baidu beträgt etwa −4.46 Prozentpunkte, das 95%-Intervall reicht etwa von −5.78 bis −3.16 Prozentpunkte. Diese Schlussfolgerung beschränkt sich auf die vorliegende Aufgabenmenge und die Beobachtungsbedingungen und wird nicht zu einer Aussage über die statistische Signifikanz des Gesamtwerts erweitert.

Standard und Anwendungsbedingungen

Standardkennung: AIHubMix Fidelitas Standard v2.0. Ergebnisse zeichnen gleichzeitig AF Suite, Adaptionskonfiguration, Bewertungsprotokoll und Messbedingungen auf. Ergebnisse unterschiedlicher Konfigurationen oder statistischer Definitionen werden getrennt interpretiert. Die vier Bewertungen auf der Modellseite sind D-Werte; Korrektheitsrate, Funktionsbestehensrate, Latenz, Cache-Anteil und Erst-Erfolgsrate im Bericht sind die entsprechenden Rohkennzahlen oder A-Werte. Der Gesamtwert dient der zusammenfassenden Darstellung; für die konkrete Integrationsentscheidung sind Dimensionsergebnisse, Funktionsanforderungen und Evidenzbedingungen maßgeblich. Verwandte Dokumentation: Modell auswählen · Modelldetails und Vergleich Dokumentdatum: 2026-11-05

​Bewertungsumfang und Leseweise

​Status der Scores

​Interpretation der Ergebnisse

​Gesamtwert und Dimensionssynthese

​Gesamtformel

​Dreistufige Synthese

​Relativer Bezug zur offiziellen Referenz B

​Evidenzvollständigkeit C

​Antwortqualität

​Aufgabenset und Bewertung

​Vergleichsbedingungen und Umgang mit fehlenden Werten

​Funktionsunterstützung

​Funktionsgruppen und Gewichtung

​Entscheidungsstatus

​Native Fähigkeiten und Schnittstellenkompatibilität

​Antwortgeschwindigkeit

​Last und Stichproben

​Zeitmessung und gültige Ausgabe

​Bewertungsformel

​Ungültige Ausgaben und Messisolierung

​Cache-Treffer

​Testsequenz und Nenner

​Anomalien und nicht beobachtbare Fälle

​Servicezuverlässigkeit

​Testmenge und Erfolgsbedingungen

​Fehler, ungültige Aufzeichnungen und Intervalle

​Testumfang und Vergleichbarkeit

​Stichprobenumfang

​Ausführungsbedingungen

​Herkunft der Datensätze und Ergebnisaufzeichnung

​Herkunft der Datensätze

​Ergebnisaufzeichnung und Prüfung

​Referenzdaten und Berechnungsbeispiel

​Absolute Leistung und Cache-Teilwerte

​Dimensionssynthese der Funktionsunterstützung

​Servicezuverlässigkeitswert der offiziellen Referenz

​Dimensionsanzeigewerte und Gesamtwert

​Unabhängige Diagnosekennzahlen

​Standard und Anwendungsbedingungen

Bewertungsumfang und Leseweise

Status der Scores

Interpretation der Ergebnisse

Gesamtwert und Dimensionssynthese

Gesamtformel

Dreistufige Synthese

Relativer Bezug zur offiziellen Referenz B

Evidenzvollständigkeit C

Antwortqualität

Aufgabenset und Bewertung

Vergleichsbedingungen und Umgang mit fehlenden Werten

Funktionsunterstützung

Funktionsgruppen und Gewichtung

Entscheidungsstatus

Native Fähigkeiten und Schnittstellenkompatibilität

Antwortgeschwindigkeit

Last und Stichproben

Zeitmessung und gültige Ausgabe

Bewertungsformel

Ungültige Ausgaben und Messisolierung

Cache-Treffer

Testsequenz und Nenner

Anomalien und nicht beobachtbare Fälle

Servicezuverlässigkeit

Testmenge und Erfolgsbedingungen

Fehler, ungültige Aufzeichnungen und Intervalle

Testumfang und Vergleichbarkeit

Stichprobenumfang

Ausführungsbedingungen

Herkunft der Datensätze und Ergebnisaufzeichnung

Herkunft der Datensätze

Ergebnisaufzeichnung und Prüfung

Referenzdaten und Berechnungsbeispiel

Absolute Leistung und Cache-Teilwerte

Dimensionssynthese der Funktionsunterstützung

Servicezuverlässigkeitswert der offiziellen Referenz

Dimensionsanzeigewerte und Gesamtwert

Unabhängige Diagnosekennzahlen

Standard und Anwendungsbedingungen