> ## Documentation Index > Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt > Use this file to discover all available pages before exploring further. # AIHubMix Fidelitas Standard v2.0 > Erfahren Sie mehr über die vier Bewertungsdimensionen, die Gesamtformel, die Bewertung nativer Fähigkeiten und der Schnittstellenkompatibilität, die Messung von Antwortgeschwindigkeit und Cache-Treffern sowie die Herkunft der Aufgabensets und die statistischen Grenzen des AIHubMix Fidelitas Standard. 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. ```text Gesamtwert theme={null} 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. ```text Dimensionswert theme={null} 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. ```text Relative Referenzstufe theme={null} 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 | ```text Absolute Leistung der Antwortqualität theme={null} 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. > [!NOTE] > > 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](#dataset-sources). ### 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. ```text Absolute Leistung der Funktionsunterstützung theme={null} 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](#speed) 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: ```text Absolute Leistung der Antwortgeschwindigkeit theme={null} 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. ```text Cache-Treffer-Teilwert theme={null} 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: 1. Der erste Request schreibt in den Cache; am Anfang des Präfixes wird eine unabhängige Zufallskennung eingefügt, um verschiedene Testgruppen zu isolieren. 2. 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. 3. 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: ```text Absolute Leistung der Servicezuverlässigkeit theme={null} 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](https://github.com/ShishirPatil/gorilla/tree/6ea57973c7a6097fd7c5915698c54c17c5b1b6c8/berkeley-function-call-leaderboard) | `6ea57973c7a6` | Quellrepository Apache-2.0; diese Bewertung verwendet ein abgeleitetes Aufgabenset und eine Prüfanpassung | | HLE | [Textspiegel-Snapshot](https://huggingface.co/datasets/macabdul9/hle_text_only/tree/e3e9cb5a550ec7de645fac553b0e2768d30a03ee); [offizieller Datensatz](https://huggingface.co/datasets/cais/hle) | 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](https://huggingface.co/datasets/ArtificialAnalysis/AA-LCR/tree/9a77ef56b717057ade24ceab4d273712a0b4f19e) | `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. > [!NOTE] > > 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: ```text Relativer Bezug und Funktionsdimensionswert theme={null} 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`: ```text Dimensionssynthese der Servicezuverlässigkeit theme={null} 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: ```text Gesamtwertberechnung theme={null} 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](https://docs.aihubmix.com/de/guides/choose-models.md) · [Modelldetails und Vergleich](https://docs.aihubmix.com/de/guides/model-details.md) Dokumentdatum: 2026-11-05 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.