AIHubMix Fidelitas Standard v2.0

AIHubMix Fidelitas prend pour objet de mesure la performance de livraison d’un même modèle dans les services de différents fournisseurs de modèles, et évalue séparément la justesse des résultats des tâches, la disponibilité des fonctionnalités, la performance de réponse et l’achèvement des premières requêtes. Le score total et les scores des quatre dimensions sont présentés conjointement afin de comparer la performance de service d’un même modèle dans des conditions de test prescrites. Le présent document applique AIHubMix Fidelitas Standard v2.0, dont la version de projet est AF v2.0. Le score principal utilise les résultats de prise en charge fonctionnelle et de mesure du cache configurés selon la documentation du fournisseur ; la compatibilité d’interface et les résultats de cache en configuration par défaut sont rapportés séparément comme indicateurs de diagnostic.

Périmètre de notation et lecture

Élément noté	Code	Poids	Contenu mesuré
Qualité des réponses	Q (Quality)	35%	Justesse des résultats pour les tâches d’appel d’outils, de connaissances et de raisonnement, et de compréhension de textes longs
Prise en charge fonctionnelle	F (Functionality)	25%	Disponibilité des fonctionnalités : streaming, outils, sortie structurée, paramètres, contexte, réponses d’erreur et mesure de l’usage
Vitesse de réponse	P (Performance)	20%	Délai avant la première réponse de contenu, débit de génération, débit effectif en concurrence et réussite effective du cache
Fiabilité du service	R (Reliability)	20%	Proportion d’un ensemble fixe de requêtes achevées effectivement lors de la première exécution

L’objet de notation indépendant est « fournisseur de modèles × version de modèle », c’est-à-dire le service d’une version de modèle fourni par un fournisseur de modèles donné. Chaque objet produit, dans un lot d’évaluation et une configuration donnés, un ensemble de scores sur les quatre dimensions et un score total. Le mode de raisonnement, les paramètres de requête, le niveau de service du compte, la région de test et la période d’observation sont des conditions de mesure, enregistrées avec les résultats. Les résultats obtenus dans des conditions différentes sont signalés séparément et ne sont pas fusionnés directement. Lorsque la version du modèle, la région ou le niveau de service ne peuvent pas être vérifiés, l’état non vérifié correspondant est indiqué, sans présomption de confirmation. Les évaluations sont exécutées via l’API AIHubMix ; les résultats décrivent la performance réellement observée selon ce mode d’accès. Le service de référence officiel est également mesuré via l’API AIHubMix et ne constitue pas une mesure effectuée par connexion directe et indépendante à l’API officielle. Un même groupe de comparaison utilise le même jeu de tâches, les mêmes répétitions, le même délai d’expiration, le même budget de requêtes, la même notation des échecs et la même méthode statistique. Les champs de requête nécessaires, la structure de streaming et les champs d’usage définis par la documentation du fournisseur sont traités par la couche d’adaptation d’accès (adapter), tandis que l’objectif de mesure reste identique. Cette méthode ne sert pas au classement des capacités d’intelligence entre modèles ; l’identité du fournisseur de modèles ne constitue pas un motif d’attribution de points supplémentaires.

États du score

État	Signification
Définitif	Inscription du test, échantillonnage, notation et vérification des preuves effectués selon la norme applicable
Résultat de référence (PROVISIONAL)	Un résultat calculable peut être établi, mais l’échantillonnage, la notation, l’inscription de l’adaptation ou les preuves présentent des limites d’application
Indisponible (UNAVAILABLE)	Notation, dénominateur ou référence nécessaires manquants ; aucune valeur numérique n’est attribuée
Non comparable	Configuration du modèle, conditions d’observation ou vue des résultats non cohérentes ; exclusion de la comparaison à périmètre identique

Les valeurs manquantes et les scores de 0 sont traités séparément. Lorsqu’un service échoue explicitement ou ne fournit pas une capacité requise, l’échec est comptabilisé selon la règle correspondante ; en cas de mesure manquante, de dénominateur inconnu ou de preuves insuffisantes, l’état correspondant est conservé. Si une dimension est indisponible, le score total est également marqué indisponible et son poids n’est pas redistribué aux autres dimensions.

Interprétation des résultats

Les indicateurs bruts sont convertis en performance absolue A par la formule de notation, puis combinés à la référence relative et aux preuves pour obtenir le score composite de dimension D. Le score total utilise D et ne pondère pas directement le taux de justesse brut, le taux de réussite fonctionnelle ou le taux de réussite du service.
Les scores reflètent la performance dans un jeu de tâches, une charge, une région, une configuration et une fenêtre d’observation donnés ; les conditions d’application sont enregistrées avec les résultats.
La précision d’affichage ne représente pas la capacité de discrimination statistique. Les écarts de qualité des réponses s’interprètent à l’aide d’intervalles statistiques appariés ; un écart au niveau des décimales ne suffit pas à établir une supériorité.
Le score total est un indice de synthèse ; il ne constitue pas une certification et ne comporte pas d’intervalle de confiance. Les conclusions statistiques reposent sur les preuves propres à chaque dimension.
La fiabilité du service rapporte le nombre de réussites initiales, le nombre d’occasions planifiées et l’intervalle bilatéral à 95%, et ne s’interprète pas directement comme un SLA de long terme.

Après examen et confirmation d’une non-concordance de l’identité du modèle, d’une troncature silencieuse des entrées, d’une fuite de contenu sensible, d’une dégradation grave du protocole ou d’une anomalie de facturation, le résultat est marqué séparément « non admis » ; les preuves de reproduction et les limites d’utilisation sont conservées. Les scores de dimension et le score total ne neutralisent pas cette restriction.

Score total et composition des dimensions

Formule du score total

Le score total est calculé par pondération des scores composites des quatre dimensions. D_Q, D_F, D_P et D_R désignent respectivement les scores composites de la qualité des réponses, de la prise en charge fonctionnelle, de la vitesse de réponse et de la fiabilité du service.

Score total

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

Les quatre scores composites de dimension utilisent une échelle de 0 à 100. Le score total résume le résultat global ; les quatre scores de dimension servent à identifier les écarts précis.

Composition à trois couches

Chaque score composite de dimension D est calculé par pondération de la performance absolue A, de la performance relative à la référence officielle B et de la complétude des preuves C.

Score de dimension

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

Couche d’entrée	Poids	Définition
A : performance absolue	65%	Résultat de mesure réel obtenu selon les méthodes de test et de statistique prescrites
B : performance relative à la référence officielle	20%	Écart de la performance absolue de la même dimension par rapport au service de référence officiel
C : complétude des preuves	15%	Degré d’étayage des résultats par la couverture des échantillons, la cohérence des observations et les preuves de mesure

A, B et C sont des symboles de couche de calcul et ne désignent pas un niveau d’accès. La performance absolue utilise la formule prescrite ; le service le plus rapide ou le mieux noté de ce lot n’est pas fixé à 100 et aucune renormalisation n’est effectuée par lot. La partie située avant le tiret bas désigne la couche de calcul, celle située après désigne la dimension de notation. Par exemple, A_F est le score de prise en charge fonctionnelle de la couche de performance absolue, et D_F le score de prise en charge fonctionnelle après composition des trois couches. Le score principal et les valeurs de diagnostic utilisent également les suffixes de configuration suivants :

Code	Libellé anglais complet	Signification et usage
`F_native`	Native Functionality Score	Score de prise en charge fonctionnelle native obtenu après configuration et analyse selon la documentation du fournisseur, utilisé comme `A_F` du score principal
`F_strict`	Strict Interface Compatibility Score	Score de compatibilité stricte obtenu par vérification directe selon les conventions d’interface AIHubMix, rapporté séparément en diagnostic
`K`	Cache Hit Score	Sous-score de réussite effective du cache, intégré à la performance absolue de la vitesse de réponse
`K_native`	Native Cache Hit Score	Sous-score de cache mesuré avec la configuration requise par la documentation du fournisseur, utilisé dans le score principal
`K_default`	Default-Configuration Cache Hit Score	Sous-score de cache mesuré sans configuration d’affinité de session, rapporté séparément en diagnostic

native désigne une configuration conforme à la documentation du fournisseur, strict une vérification stricte de l’interface et default la configuration par défaut définie dans le présent document. K est le symbole de cache de cette méthode et ne désigne pas Quality. Le score principal utilise uniformément F_native et K_native ; les valeurs de diagnostic ne sont pas mélangées au score principal.

Performance relative à la référence officielle B

A_official désigne le score de performance absolue du service de référence officiel pour la dimension considérée ; son score relatif à la référence officielle B_official est fixé à 50.

Couche relative à la référence officielle

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

clip(x, −1, 1) est une fonction d’écrêtage qui limite x à l’intervalle de −1 à 1. Le paramètre d’échelle d’écart δ est défini par dimension :

Dimension	δ
Qualité des réponses Q	2
Prise en charge fonctionnelle F	15
Vitesse de réponse P	10
Fiabilité du service R	2

La qualité des réponses utilise un bootstrap par grappes sur 5,000 tâches appariées pour estimer l’intervalle d’écart par rapport à la référence officielle. Lorsque l’intervalle bilatéral à 95% contient 0, B_Q = 50 ; lorsque l’intervalle ne contient pas 0, le calcul suit la mise en correspondance ci-dessus. Le service de référence officiel fait l’objet d’une mesure indépendante de performance absolue ; son propre B est fixé à 50, sans note maximale présupposée. Lorsque des configurations, délais d’expiration, périodes ou vues de résultats différents ne sont pas comparables, aucune valeur estimée n’est renseignée dans la couche relative.

Complétude des preuves C

C se compose des cinq éléments suivants, chacun sur un maximum de 20 points, pour un total de 100. Chaque élément est valorisé selon le degré de couverture et les preuves consignées, et peut valoir 20, 10 ou 0 point :

Élément	Contenu vérifié
Couverture des échantillons	Degré de conformité entre les enregistrements valides réels et la taille d’échantillon planifiée
Couverture des fenêtres	Degré de complétude des périodes requises ou des segments de collecte de la qualité des réponses
Complétude de l’usage	Degré de couverture et de vérifiabilité du champ brut `usage`
Preuves des dénominateurs	Degré de reproductibilité des dénominateurs de notation des tâches, de détermination fonctionnelle et de mesure du cache
Cohérence du protocole	Degré de cohérence de la configuration des requêtes, de l’attribution des enregistrements et du protocole d’observation

C évalue les preuves de mesure et non directement la capacité du modèle. Chaque valorisation est associée à un enregistrement de preuve et l’état du résultat est conservé séparément ; le score de la couche de preuves ne remplace pas la vérification nécessaire de la validité des données.

Qualité des réponses

La qualité des réponses Q mesure, sur la base des réponses de référence et du protocole de notation prescrit, la proportion d’instances de tâches correctes parmi l’ensemble des instances valides.

Jeu de tâches et notation

Axe	Contenu mesuré	Nombre de tâches × répétitions	Nombre d’instances planifiées	Méthode de notation
BFCL	Sélection de fonctions, remplissage de paramètres, appels parallèles, suppression des appels non pertinents et chaîne d’outils en trois étapes	500 × 3	1,500	Adaptation de correspondance JSON en Python uniquement, basée sur l’AST checker officiel de la version spécifiée
HLE	Questions de connaissances textuelles et de raisonnement de haute difficulté, stratifiées par discipline	250 × 10	2,500	Juge d’équivalence des réponses, avec enregistrement du modèle juge, du prompt et de la version
AA-LCR	Questions-réponses de synthèse multi-documents d’environ 74,000 à 114,000 tokens	25 × 10	250	Documents spécifiés et réponses de référence, avec notation par équivalence des réponses
Total	775 tâches distinctes	Exécution selon les répétitions prescrites par axe	4,250	Agrégation sur toutes les instances valides

Performance absolue de la qualité des réponses

A_Q = 100 × instances correctes / instances notées valides

Dénominateur planifié complet = 1,500 + 2,500 + 250 = 4,250

Les trois axes sont agrégés par nombre d’instances ; les taux de justesse de chaque axe ne font pas l’objet d’une moyenne à poids égal. Une tâche d’outils multi-tours peut correspondre à plusieurs requêtes API ; le nombre d’instances de tâches et le nombre de requêtes sont comptabilisés séparément.

Ce jeu de tâches est un jeu dérivé de l’AF Suite ; il ne constitue pas un sous-ensemble exact de l’Artificial Analysis officiel et ne reproduit pas les résultats de son classement. Les 50 tâches BFCL multi-tours sont composées à partir de tâches réelles et sont définies séparément de l’environnement d’exécution multi-tours avec état officiel de BFCL. Les sources et versions sont indiquées dans Sources des jeux de données.

Conditions de comparaison et traitement des données manquantes

La justesse des tâches est déterminée à partir des réponses de référence ; les réponses du service de référence officiel ne servent pas de vérité terrain.
Chaque partie utilise le même budget contrôlable, le même nombre d’échantillonnages et les mêmes paramètres d’équivalence sémantique ; lorsque le mode de raisonnement, le gabarit d’outils ou effort ne peuvent pas être alignés, la mention « configuration non comparable » est appliquée.
Les échecs de service, délais d’expiration, refus de réponse et épuisements de budget sont comptabilisés comme échecs de tâche au dénominateur.
Les enregistrements dont le juge est invalide ou qui ne comportent pas de décision valide sont signalés séparément, exclus du dénominateur calculable, et l’état de résultat de référence est conservé.
Les règles de filtrage des tâches sont précisées dans l’inscription du test ; le rapport indique le nombre planifié, le nombre filtré et le nombre réellement noté.
Les répétitions sont rattachées à la grappe de la même tâche et ne sont pas traitées comme de nouvelles tâches indépendantes.

Les écarts relatifs sont estimés par un bootstrap par grappes sur tâches appariées, par axe, avec 5,000 répétitions. Chaque partie utilise le même index d’échantillonnage des tâches ; l’intervalle bilatéral à 95% de l’écart est rapporté. Lorsque l’intervalle contient 0, la mention « écart non établi » est appliquée et la couche relative à la référence officielle prend la valeur 50.

Prise en charge fonctionnelle

La prise en charge fonctionnelle F mesure la disponibilité des fonctionnalités d’interface dans la configuration prescrite et n’est pas comptée une seconde fois dans le taux de justesse des réponses aux tâches.

Groupes fonctionnels et poids

Groupe fonctionnel	Poids	Contenu vérifié
Streaming et protocole de messages	20%	Incréments de streaming, ordre des événements, bloc de terminaison, `finish_reason` et emplacement de `usage`
Interface d’outils	20%	Nom d’outil, schema, analyse des paramètres, appels parallèles, retour des résultats d’outils et gestion des erreurs
Contraintes de sortie et paramètres	20%	Comportement réel de `temperature`, `max_tokens`, `stop`, de la sortie structurée et de la configuration de raisonnement
Contexte et état	15%	Limites de fenêtre, traitement du dépassement, messages d’historique et intégrité des entrées longues
Erreurs et reprise	15%	Conformité des codes d’erreur, du corps d’erreur, de la limitation de débit et de la sémantique de nouvelle tentative avec les conventions documentées
Protocole de mesure et de cache	10%	Complétude de `usage`, cohérence des totaux et mesure du cache

f[组] (Functional Group Pass Score, score de réussite d’un groupe fonctionnel) représente le taux de réussite des instances applicables valides d’un groupe fonctionnel. Dans la formule, f流式 (streaming), f工具 (outils), f约束 (contraintes), f上下文 (contexte), f错误 (erreurs) et f计量 (mesure) correspondent respectivement aux six groupes du tableau.

Performance absolue de la prise en charge fonctionnelle

f[组] = 100 × instances réussies / instances applicables valides
A_F = 0.20 × f流式 + 0.20 × f工具 + 0.20 × f约束
    + 0.15 × f上下文 + 0.15 × f错误 + 0.10 × f计量

Chaque groupe comprend 10 cas de test, chaque cas étant exécuté une fois dans 3 fenêtres, soit 60 cas de test et 180 décisions. Les requêtes répétées prescrites au sein d’un cas sont enregistrées séparément et ne modifient pas le regroupement des cas ni les poids.

États de décision

État	Signification	Traitement d’agrégation
PASS	Toutes les vérifications applicables réussies	Compté dans les instances réussies et applicables valides
FAIL	Fonctionnalité manquante, contrat non respecté, valeur erronée ou défaillance de service inattendue	Compté dans les instances applicables valides, non compté comme réussite
NA	Capacité non prise en charge nativement par le modèle, avec preuves suffisantes et inscription préalable	Exclu du dénominateur applicable
UNTESTED	Test non exécuté	État limité ou indisponible conservé lorsque les enregistrements obligatoires sont insuffisants
INVALID	Testeur, fixture ou preuve de configuration invalide, sans responsabilité imputable au service évalué	Non compté comme échec fonctionnel ; dénominateur valide et limites de preuve enregistrés
UNOBSERVED	Étape précédente interrompue, aucune observation ultérieure formée	Non compté comme réussite ; état d’observation manquante conservé

Le score de capacité native est calculé sur les enregistrements applicables valides. En présence d’enregistrements INVALID ou UNOBSERVED, les limites de couverture et de dénominateur sont également communiquées ; lorsque les vérifications nécessaires manquent de preuves, le score de compatibilité stricte est indisponible. Une capacité prise en charge nativement par le modèle mais non fournie par le service est comptée comme FAIL et ne peut pas être classée NA.

Capacités natives et compatibilité d’interface

Indicateur	Libellé anglais complet et signification	Base de vérification	Usage
`F_native`	Native Functionality Score, score de prise en charge fonctionnelle native	Interprétation des champs, de la structure de streaming et de la configuration de requête nécessaire selon la documentation du fournisseur ; vérification de l’existence et de la sémantique correcte des fonctionnalités	Utilisé comme `A_F` du score principal
`F_strict`	Strict Interface Compatibility Score, score de compatibilité stricte d’interface	Vérification directe des champs, de la structure des événements et du comportement de retour selon les conventions d’interface AIHubMix	Diagnostic de compatibilité d’interface rapporté séparément

Lorsqu’un champ est présent et que sa position ou sa dénomination est conforme à la documentation du fournisseur, la vérification de capacité native l’interprète selon sa structure réelle. Lorsqu’un champ est totalement absent, comporte une valeur erronée ou des contradictions, la décision suit le résultat réel de la vérification. La couche d’adaptation conserve les champs d’origine et les justifications de mappage, sans présumer qu’une valeur inconnue correspond à une fonctionnalité réussie. F_native et F_strict sont rapportés séparément et ne peuvent pas être utilisés en alternance dans le score principal d’un même tableau de comparaison. La proportion de réussite effective du cache est intégrée à la vitesse de réponse ; l’exactitude de la facturation est vérifiée séparément.

Vitesse de réponse

La vitesse de réponse P se compose de la performance de réponse du contenu et de la réussite effective du cache. Le score principal utilise K_native.

Charge et échantillonnage

Le profil sans raisonnement I (Non-thinking Profile, profil de charge sans raisonnement) et le profil avec raisonnement T (Thinking Profile, profil de charge avec raisonnement) sont mesurés et rapportés séparément. I et T sont des identifiants de profil de charge ; le profil I exige que le modèle prenne en charge nativement le mode sans raisonnement, le profil T enregistre effort, le budget de raisonnement et le budget de sortie. C1 (Concurrency 1, concurrence unique) et C10 (Concurrency 10, 10 requêtes simultanées) désignent le nombre de requêtes exécutées simultanément. Ici, C désigne Concurrency et se distingue de la couche C de complétude des preuves.

Élément de configuration	Convention de mesure
Entrée	10,000 ± 2% tokens, mesurés avec `o200k_base` ; un préfixe unique est ajouté au début de l’entrée pour limiter les réussites de cache inattendues
Sortie	1,000 à 1,200 tokens de contenu, incluant des points de vérification fixes
Délai d’expiration	300 secondes, identique au sein d’un même groupe de comparaison
Concurrence unique C1	90 requêtes, 3 fenêtres × 30
10 requêtes simultanées C10	90 requêtes, 3 fenêtres × 30
Sous-test de cache	30 requêtes, 3 fenêtres × deux paliers 8k/32k × 5 requêtes
Isolation	Qualité des réponses et vitesse de réponse exécutées séparément ; la vitesse de réponse utilise une période de mesure indépendante

Le test de concurrence utilise un mécanisme de complément en boucle fermée : une requête est renvoyée à chaque requête terminée. C10 représente le résultat observé sous cette charge et ne constitue pas une courbe de capacité complète.

Chronométrage et sortie valide

Indicateur	Libellé anglais complet	Définition et usage
Point de départ du chronométrage	Measurement Start Time	Instant où la requête formelle commence à être écrite après établissement de la connexion préétablie ; le temps de démarrage à froid de la connexion est enregistré séparément
TTFT	Time to First Token	Temps d’attente du premier payload réel d’inférence, de contenu ou de paramètres d’outil ; les événements de rôle vide et de heartbeat sont exclus ; utilisé comme indicateur brut
TTFA	Time to First Answer	Temps d’attente du premier fragment final de contenu non vide, incluant le temps de raisonnement précédent ; utilisé pour la notation de la latence
TPOT	Time per Output Token	Temps moyen par token pendant la phase de génération du contenu, calculé à partir des instants des premier et dernier fragments de contenu et du nombre de tokens correspondant
goodput	Valid-Output Throughput	Débit de tokens de contenu valides satisfaisant les exigences de justesse et d’intégrité, sur la durée réelle complète de C10

Lorsque le contenu est renvoyé en un seul bloc, le TPOT est marqué invalide et aucun débit par token n’est construit à partir de cette valeur. La statistique de notation utilise le P50 (50th Percentile, 50e percentile, c’est-à-dire la médiane) avec traitement des échecs ; le P95 empirique (95th Percentile, 95e percentile) et la variation entre fenêtres sont rapportés séparément ; 90 échantillons par palier ne permettent pas de conclure sur le P99 (99th Percentile, 99e percentile). Ici, P désigne Percentile et se distingue de la dimension P de vitesse de réponse.

Formule de notation

Les noms de fonctions et les symboles de sous-scores de cette section sont des notations de calcul propres à cette méthode ; leur signification est la suivante :

Code	Nom anglais	Signification
`S(x; τ)`	Latency Score Function	Fonction convertissant le temps d’attente x en sous-score de latence ; τ est l’échelle de latence
`L(x; t, k)`	Lower-is-Better Score Function	Fonction de notation où une valeur plus faible est meilleure ; utilisée dans cette section pour le TPOT, t étant la cible de note maximale et k le multiplicateur de plage
`H(x; t)`	Higher-is-Better Score Function	Fonction de notation où une valeur plus élevée est meilleure ; utilisée dans cette section pour le débit effectif, t étant la cible de note maximale
`l_ttfa`	Answer Latency Subscore	Sous-score de latence de la première réponse de contenu, égal à la plus petite des valeurs notées en C1 et C10
`l_tpot`	Output Token Time Subscore	Sous-score de temps par token de contenu, égal à la plus petite des valeurs notées en C1 et C10
`P_response`	Response Performance Score	Sous-score de performance de réponse, composé de la latence, du temps par token et du débit effectif, hors sous-score de cache
`P50_TTFA_C1`, `P50_TTFA_C10`	Median Time to First Answer at Concurrency 1 / 10	Médiane du TTFA avec traitement des échecs, en concurrence unique ou à 10 requêtes simultanées
`P50_TPOT_C1`, `P50_TPOT_C10`	Median Time per Output Token at Concurrency 1 / 10	Médiane du TPOT avec traitement des échecs, en concurrence unique ou à 10 requêtes simultanées

A_P est le score absolu de vitesse de réponse incluant la performance de réponse et le sous-score de cache ; D_P est le score de la dimension vitesse de réponse après composition avec la référence relative et les preuves, utilisé dans le score total. Ci-dessous, clip limite la valeur à l’intervalle de 0 à 1, ln désigne le logarithme népérien, min la valeur la plus petite et Σ la somme. Les paramètres τ, b, c et k des formules sont définis dans le tableau de paramètres qui les suit :

Performance absolue de la vitesse de réponse

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 = Σ requêtes valides min(tokens de contenu, 1000) / Σ durée réelle des fenêtres C10

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

Paramètre	Nom anglais	Valeur	Signification
τ	Latency Scale	2 secondes	TTFA auquel le sous-score de latence atteint 50
b	Target Time per Output Token	5 ms/token	Cible de note maximale du TPOT ; 100 lorsque la valeur atteint ou est inférieure à cette cible
c	Target Valid-Output Throughput	1,200 token/s	Cible de note maximale du débit effectif C10 ; 100 lorsque la valeur atteint ou dépasse cette cible
k	TPOT Range Multiplier	10	Multiplicateur de plage du mappage logarithmique du TPOT

Les cibles ci-dessus s’appliquent à la charge prescrite par la présente norme et ne représentent pas des seuils universels pour tous les modèles et toutes les charges de travail.

TTFA	0 seconde	1 seconde	2 secondes	4 secondes	10 secondes
Sous-score de latence	100	66.7	50	33.3	16.7

Sorties invalides et isolation des mesures

Les sorties dont la longueur ne correspond pas, dont les points de vérification sont erronés, qui présentent une dégénérescence en boucle, une erreur dans le flux, une terminaison anormale ou une troncature sont jugées invalides et restent comptabilisées dans la charge et le temps de traitement. Avant le calcul du P50, les traitements suivants sont appliqués :

Le TTFA est compté comme l’infini positif, avec un sous-score de latence de 0.
Le TPOT est compté comme 10b, soit 50 ms/token.
La contribution aux sorties valides du goodput est de 0, le temps restant comptabilisé dans la fenêtre C10 correspondante.
Le temps réellement mesuré d’origine est conservé séparément et n’est pas remplacé par la valeur de traitement de notation.

Le nombre de requêtes valides, le nombre planifié et le taux de sorties valides sont également rapportés. Les résultats de performance incluent l’effet des échecs de service sur le service rendu et ne peuvent pas être interprétés uniquement à partir de la latence des requêtes réussies.

Réussite du cache

Le sous-score de cache K (Cache Hit Score, sous-score de réussite effective du cache) mesure la proportion de tokens d’un préfixe réutilisable effectivement rapportés comme lus depuis le cache. Pour chaque longueur, les quantités lues et les quantités réutilisables des requêtes chaudes sont d’abord agrégées, puis les deux longueurs 8k et 32k sont agrégées à poids égal.

Code	Libellé anglais complet	Signification
`K_length`	Length-Specific Cache Hit Score	Sous-score de réussite effective du cache pour un palier de longueur de préfixe donné
`K_8k`	8k-Prefix Cache Hit Score	Sous-score de réussite effective du cache pour le palier de préfixe d’environ 8k tokens
`K_32k`	32k-Prefix Cache Hit Score	Sous-score de réussite effective du cache pour le palier de préfixe d’environ 32k tokens
`cache_read_native_tokens`	Cache-Read Native Token Count	Nombre de tokens natifs lus depuis le cache effectivement rapporté pour les requêtes chaudes, hors écritures de cache
`expected_reusable_native_tokens`	Expected Reusable Native Token Count	Nombre de tokens natifs du préfixe réutilisables selon les règles, servant de dénominateur au taux de réussite

Ici, native_tokens désigne des tokens mesurés avec le tokenizer natif spécifié ; ce terme se distingue de native dans K_native, qui désigne la configuration conforme à la documentation du fournisseur.

Sous-score de réussite du cache

K_length = 100 × Σ requêtes chaudes cache_read_native_tokens
                 / Σ requêtes chaudes expected_reusable_native_tokens

K = (K_8k + K_32k) / 2

Le taux de réussite pondéré par les tokens, après fusion des différentes longueurs, peut servir d’indicateur de diagnostic et ne remplace pas le K à poids égal du score principal.

Séquence de test et dénominateur

Chaque groupe utilise un long préfixe fixe et de nouvelles questions variables, pour un total de 5 requêtes :

La première requête écrit dans le cache ; un identifiant aléatoire indépendant est ajouté au début du préfixe afin d’isoler les groupes de test.
Les requêtes 2 à 4 conservent un préfixe identique octet par octet et utilisent de courtes questions différentes à la fin ; elles sont lancées respectivement 5, 30 et 120 secondes après l’achèvement de la requête précédente.
La cinquième requête utilise un nouveau préfixe entièrement indépendant, servant de contrôle à froid.

Les trois fenêtres couvrent chacune les deux paliers d’environ 8k et 32k, soit 30 requêtes au total. Seules les requêtes 2 à 4 entrent dans la notation des réussites à chaud, soit 9 occasions de requêtes chaudes par longueur. La première écriture et le contrôle à froid sont vérifiés séparément. Le dénominateur utilise le nombre enregistré de tokens natifs du préfixe réutilisable, déterminé selon le tokenizer, le gabarit et les règles de cache spécifiés. Les nouvelles questions et les parties non réutilisables sont identifiées séparément ; le dénominateur n’est pas remplacé par l’ensemble des tokens d’entrée, par la quantité effectivement lue ni par le comptage o200k_base. Les quantités lues rapportées par blocs conservent leur valeur d’origine et la taille de bloc. Le score principal utilise K_native : la configuration nécessaire à l’activation du cache est appliquée selon la documentation du fournisseur ; les champs d’affinité de session nécessaires relèvent de l’adaptation d’accès. K_default enregistre, selon une règle uniforme, le résultat obtenu sans configuration d’affinité de session, à titre de diagnostic de configuration par défaut. Tous les fournisseurs appliquent le même principe de détermination de configuration ; le rapport conserve la configuration concrète.

Cas anormaux et non observables

Cas	Traitement
Dénominateur réutilisable inconnu	K indisponible, non compté comme 0
Champ de lecture du cache absent d’une requête réussie	Non observable par défaut ; interprété comme 0 uniquement si la documentation indique explicitement l’omission du champ en cas de zéro réussite, si le cas est enregistré et si les preuves concordent
Quantité lue supérieure au dénominateur ou champs contradictoires	Anomalie et valeur d’origine enregistrées, sans troncature à 100%
Contrôle à froid réussi avec une quantité lue de 0	Utilisable comme preuve de contrôle à froid ; un contrôle non achevé conserve un état limité
Requête chaude en échec avec dénominateur déterminable	Quantité lue comptée comme 0, enregistrement d’échec rapporté séparément
Cache pris en charge nativement par le modèle, non fourni par le service	K = 0
Cache non pris en charge nativement par le modèle et défini au préalable	Palier No-cache rapporté séparément, `A_P = P_response`, avec rapport distinct du palier avec cache
Mesure des réussites non prise en charge	K et P marqués indisponibles, sans transfert du poids du cache

usage ne peut confirmer que la quantité de lectures de cache rapportée par l’interface. Les frais réels ne peuvent être marqués comme vérifiés qu’après contrôle ; une réussite de cache n’équivaut pas à la gratuité et ne garantit pas une réduction du coût total.

Fiabilité du service

La fiabilité du service R mesure la proportion d’un ensemble fixe de requêtes achevées effectivement lors de la première exécution ; la notation n’utilise ni nouvelle tentative automatique ni repli vers un autre fournisseur de modèles :

Performance absolue de la fiabilité du service

A_R = 100 × complétions valides au premier essai / opportunités planifiées valides

Opportunités planifiées complètes = 300

Ensemble de test et conditions de réussite

Le test comprend 300 occasions, réparties sur 3 fenêtres de 100 occasions chacune. Chaque ensemble de 100 utilise la même combinaison de tâches : 40 textes courts, 30 entrées longues d’environ 10k, 20 appels de protocole d’outils et 10 appels uniques avec historique multi-tours. Les tâches d’outils utilisent un historique valide prédéfini afin de stabiliser le dénominateur de notation. La concurrence unique est appliquée par défaut et le débit de requêtes reste dans les quotas RPM et TPM vérifiés. Cette suite est exécutée indépendamment et n’intègre ni tâches de qualité des réponses, ni cas fonctionnels négatifs, ni nouvelles tentatives de diagnostic, ni préchauffage, ni requêtes de charge de stress. La réussite initiale satisfait simultanément les conditions suivantes :

Le statut HTTP est conforme aux attentes, la structure de réponse et la séquence d’événements sont valides.
Le contenu ou le payload d’outil est non vide et se termine normalement.
Absence d’erreur dans le flux, de troncature inattendue ou de champ requis manquant.
Les champs usage prescrits sont complets et interprétés selon la structure d’interface correspondante.
La requête est achevée dans le délai limite de 300 secondes.

Un statut HTTP 200 ne suffit pas à lui seul à établir la réussite ; les erreurs de réponse aux tâches et les échecs de service sont comptabilisés séparément.

Échecs, enregistrements invalides et intervalles

Les erreurs 429 dans le quota, les erreurs côté serveur, les échecs de connexion, les délais d’expiration, les retours vides, les ruptures de flux et les troncatures anormales sont comptés comme échecs. Lorsqu’une défaillance du fournisseur de modèles empêche l’envoi d’une requête planifiée, l’échec est comptabilisé et la cause enregistrée. Une anomalie de l’environnement de test ou du testeur est marquée INVALID, n’est pas imputée au service évalué, et le nombre d’occasions valides ainsi que les limites de couverture sont conservés. Les requêtes de diagnostic sont enregistrées séparément et ne remplacent pas les résultats initiaux. Le taux de réussite est rapporté avec un intervalle de confiance bilatéral à 95% de Clopper–Pearson. Le taux de réussite observé de 300/300 est de 100%, la borne inférieure de l’intervalle étant d’environ 98.78% ; cela ne prouve pas pour autant un taux de réussite du service de 100% à long terme. La répartition des échecs et la plus longue série d’échecs consécutifs sont enregistrées par fenêtre et par catégorie de tâche.

Échelle des tests et comparabilité

Taille des échantillons

Voici la taille planifiée d’AF Full dans l’AF Suite :

Élément	Taille planifiée par fournisseur	Composition
Qualité des réponses	4,250 instances	BFCL 1,500, HLE 2,500, AA-LCR 250
Prise en charge fonctionnelle	180 décisions	60 cas de test × 3 fenêtres
Vitesse de réponse	180 requêtes	90 pour chacune des configurations C1 et C10, réparties sur 3 fenêtres
Cache	30 requêtes	3 fenêtres × deux longueurs de préfixe × 5 requêtes
Fiabilité du service	300 occasions	3 fenêtres × 100 occasions

Le nombre d’instances de tâches, le nombre de requêtes API et le nombre de requêtes au juge sont comptabilisés séparément ; les tâches d’outils à plusieurs étapes et les répétitions au sein d’un cas peuvent correspondre à des requêtes supplémentaires.

Conditions d’exécution

Un même groupe de comparaison applique uniformément le jeu de tâches, les répétitions, le délai d’expiration, la température, le budget de sortie, le traitement des échecs et la formule de notation.
Le même client, la même région réseau et la même stratégie de connexion sont utilisés ; le niveau de service du compte, les heures réelles de début et de fin et l’ordre d’exécution sont enregistrés.
Le test complet utilise 3 fenêtres espacées d’au moins 60 minutes ; la qualité des réponses et la vitesse de réponse sont exécutées séparément.
L’ID de modèle, l’authentification, les champs nécessaires, le format de streaming, le mappage de l’usage, la sémantique du cache et la base du tokenizer font l’objet d’un enregistrement d’adaptation.
L’adaptation d’accès est enregistrée et validée avant l’échantillonnage ; la même règle s’applique à tous les fournisseurs de modèles éligibles.
La vue principale de notation utilise uniformément F_native et K_native ; les diagnostics de compatibilité et de configuration par défaut sont rapportés séparément.
Les résultats de la première exécution sont conservés en permanence ; les quantités planifiées, les quantités réelles et les enregistrements filtrés, échoués, invalides et non observés sont vérifiés séparément.

Les tests sont exécutés dans les limites des quotas, autorisations et coûts approuvés. Lorsque des conditions nécessaires ne sont pas remplies, les résultats conservent un état limité, incomplet ou indisponible, sans renormalisation des éléments restants.

Sources des jeux de données et enregistrement des résultats

Sources des jeux de données

La qualité des réponses utilise un jeu de tâches dérivé et versionné, avec conservation des sources, des enregistrements d’échantillonnage et des informations de vérification d’intégrité. Le jeu de tâches de qualité des réponses d’AF Full comprend 775 tâches distinctes ; les instantanés de source sont les suivants :

Axe	Instantané de source	Enregistrement de version	Licence et limites d’utilisation
BFCL	Données et vérificateur du Berkeley Function Calling Leaderboard	`6ea57973c7a6`	Dépôt source sous Apache-2.0 ; la présente évaluation utilise un jeu de tâches dérivé et une adaptation du vérificateur
HLE	Instantané du miroir texte ; jeu de données officiel	Miroir `e3e9cb5a550e`	Source enregistrée sous MIT ; l’équivalence octet par octet avec la version officielle actuelle n’a pas été vérifiée
AA-LCR	Instantané des données et de la documentation AA-LCR d’Artificial Analysis	`9a77ef56b717`	Dépôt du jeu de données sous Apache-2.0 ; les droits de tiers afférents à la documentation citée restent attribués à leurs titulaires

BFCL est échantillonné par quotas de catégories ; HLE et AA-LCR sont échantillonnés par proportions stratifiées avec une couverture minimale garantie pour chaque strate. L’échantillonnage utilise une graine spécifiée et un tri SHA-256 ; la version du jeu de tâches, la liste de filtrage et le protocole de notation sont enregistrés avec les résultats. Les liens ci-dessus servent à vérifier les sources d’origine et ne constituent pas un ensemble d’évaluation complet permettant de reproduire directement les scores AF. Les données sous restriction ne sont pas redistribuées dans le présent document ; les licences applicables suivent la source correspondante.

Enregistrement et vérification des résultats

Les rapports des fournisseurs de modèles sont uniformément désignés sous le nom AF Profile et consignent les informations d’évaluation suivantes :

Catégorie d’enregistrement	Contenu nécessaire
Identité de l’évaluation	Version de la norme et du jeu de tâches, fournisseur de modèles, version exacte du modèle et service de référence officiel
Conditions de mesure	Configuration de raisonnement, niveau du compte, région, période, délai d’expiration, concurrence et paramètres de performance
Base d’adaptation	Date de consultation de la documentation, champs nécessaires, structure de streaming, interprétation de l’usage et configuration du cache
Couverture des échantillons	Nombre planifié, nombre réel, dénominateur de notation, éléments filtrés, échoués, invalides et non observés
Base de notation	Réponses de référence, configuration du vérificateur ou du juge, état de notation et évaluation des biais
Mesures brutes	Requêtes et réponses anonymisées, horodatage des événements, statut, cause de terminaison et `usage` brut
Résultats agrégés	Entrées des couches A/B/C, quatre scores D, score total, intervalles par dimension et valeurs non arrondies
Indicateurs de diagnostic	`F_strict`, `K_default`, taux de sorties valides, catégories d’erreurs et limites d’application correspondantes

La réussite du service, la justesse des tâches et la validité des sorties sont signalées séparément. Les cas négatifs ne sont pas intégrés au score de fiabilité du service ; les lectures et écritures de cache sont mesurées séparément ; l’état de vérification des coûts estimés et des coûts réels est enregistré séparément. Avant toute présentation externe, les clés d’API, identifiants d’utilisateur et contenus sensibles sont supprimés ; les valeurs sont accompagnées de leur unité et les valeurs manquantes conservent leur état.

Données de référence et exemples de calcul

Les résultats des cinq services de DeepSeek V4.1 Flash 1017 servent ci-dessous à illustrer la méthode de calcul. Le score principal utilise F_native et K_native. Les valeurs sont affichées avec deux décimales ; les calculs se fondent sur les valeurs intermédiaires conservées dans les fichiers de résultats.

Cette section présente des résultats de référence (PROVISIONAL). Les preuves d’inscription préalable de la collecte et de l’adaptation sont incomplètes et ne permettent pas de considérer ces résultats comme des résultats AF Full officiels de l’AIHubMix Fidelitas Standard. La qualité des réponses compte 4,240 instances par service, auxquelles s’ajoutent 10 instances filtrées. Les juges de HLE/AA-LCR et le modèle évalué appartiennent à la même famille DeepSeek ; les preuves de calibration indépendante sont insuffisantes. Les résultats se limitent à la configuration et au périmètre d’observation enregistrés.

Performance absolue et sous-score de cache

Dans le tableau ci-dessous, Q, F, P et R désignent la performance absolue A et ne constituent pas directement les scores affichés des quatre dimensions du score total. K est le sous-score de cache inclus dans P.

Fournisseur de modèles	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
référence officielle DeepSeek	42.45	94.00	86.14	98.38	100.00
Fireworks	41.42	71.78	79.51	60.68	100.00

Les cinq services obtiennent 300/300 pour la suite de fiabilité du service ; les échecs de service des autres suites restent comptabilisés dans leur dimension respective et ne peuvent pas être remplacés par le résultat de la suite R.
Le K_native de Fireworks utilise la configuration d’affinité de session prescrite par la documentation ; les autres services sont mesurés avec la configuration exigée par leur documentation respective.
Le K de Baidu applique la règle d’échantillonnage qui interprète comme 0 l’omission du champ en cas de zéro réussite ; les preuves d’inscription préalable correspondantes sont incomplètes ; le contrôle à froid 8k comporte des enregistrements non achevés et K conserve l’état de référence.
Le F_strict de DeepSeek est indisponible en raison de 27 enregistrements INVALID ; F_native est calculé sur les enregistrements applicables valides.

Composition de la dimension prise en charge fonctionnelle

Prenons l’exemple d’Alibaba Cloud : le score absolu de prise en charge fonctionnelle est A_F = 89.777778, le score absolu correspondant de la référence officielle est 94, l’échelle d’écart est δ_F = 15 et la complétude des preuves est C_F = 100. Le score relatif à la référence officielle B_F est d’abord calculé, puis le score de dimension D_F est composé :

Score relatif à la référence officielle et score de la dimension fonctionnelle

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 représente la performance absolue de la fonctionnalité native et 80.54 le score affiché de la dimension fonctionnelle utilisé dans le calcul du score total.

Score de fiabilité du service de la référence officielle

La suite R de la référence officielle obtient 300/300 ; le score absolu de fiabilité du service est A_R = 100, le score relatif à la référence officielle B_R = 50 et la complétude des preuves C_R = 100 :

Composition de la dimension fiabilité du service

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

100% est le taux de réussite observé de la suite de fiabilité du service pour cette campagne, et 90 le score affiché de la dimension après composition des trois couches.

Scores affichés des dimensions et score total

Le tableau ci-dessous utilise les valeurs D et correspond à la formule du score total. L’ordre de présentation des services est conservé ; le tableau n’est pas trié par score.

Fournisseur de modèles	Qualité des réponses D_Q	Prise en charge fonctionnelle D_F	Vitesse de réponse D_P	Fiabilité du service D_R	Score total
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
référence officielle DeepSeek	52.59	84.60	80.99	90.00	73.76
Fireworks	50.42	60.16	68.55	88.50	64.10

Prenons l’exemple de la référence officielle :

Calcul du score total

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

Indicateurs de diagnostic indépendants

Fournisseur de modèles	F_strict	K_default
ByteDance	56.83	93.83
Baidu	66.17	68.85
Alibaba Cloud	89.78	99.37
référence officielle DeepSeek	indisponible	98.38
Fireworks	71.78	11.06

F_strict exprime la compatibilité d’interface et K_default le résultat de cache obtenu sans configuration d’affinité de session. Aucune des deux colonnes ne remplace les entrées du score principal. Pour l’écart de qualité des réponses par rapport à la référence officielle, les intervalles à 95% de ByteDance, d’Alibaba Cloud et de Fireworks contiennent tous 0, d’où B_Q = 50. L’écart de Baidu est d’environ −4.46 points de pourcentage, avec un intervalle à 95% d’environ −5.78 à −3.16 points de pourcentage. Cette conclusion se limite au présent ensemble de tâches et aux conditions d’observation ; elle ne s’étend pas à une conclusion sur la significativité statistique du score total.

Norme et conditions d’application

Identifiant de la norme : AIHubMix Fidelitas Standard v2.0. Les résultats consignent également l’AF Suite, la configuration d’adaptation, le protocole de notation et les conditions de mesure. Les résultats obtenus avec des configurations ou des périmètres statistiques différents sont interprétés séparément. Les quatre scores de la page du modèle sont les valeurs D ; le taux de justesse, le taux de réussite fonctionnelle, la latence, la proportion de cache et le taux de réussite initial figurant dans les rapports sont les indicateurs bruts correspondants ou les valeurs A. Le score total sert à la présentation synthétique ; la décision d’accès concrète repose sur les résultats par dimension, les exigences fonctionnelles et les conditions de preuve. Documentation associée : Choisir un modèle · Détails et comparaison des modèles Date du document : 2026-11-05

⌘I

​Périmètre de notation et lecture

​États du score

​Interprétation des résultats

​Score total et composition des dimensions

​Formule du score total

​Composition à trois couches

​Performance relative à la référence officielle B

​Complétude des preuves C

​Qualité des réponses

​Jeu de tâches et notation

​Conditions de comparaison et traitement des données manquantes

​Prise en charge fonctionnelle

​Groupes fonctionnels et poids

​États de décision

​Capacités natives et compatibilité d’interface

​Vitesse de réponse

​Charge et échantillonnage

​Chronométrage et sortie valide

​Formule de notation

​Sorties invalides et isolation des mesures

​Réussite du cache

​Séquence de test et dénominateur

​Cas anormaux et non observables

​Fiabilité du service

​Ensemble de test et conditions de réussite

​Échecs, enregistrements invalides et intervalles

​Échelle des tests et comparabilité

​Taille des échantillons

​Conditions d’exécution

​Sources des jeux de données et enregistrement des résultats

​Sources des jeux de données

​Enregistrement et vérification des résultats

​Données de référence et exemples de calcul

​Performance absolue et sous-score de cache

​Composition de la dimension prise en charge fonctionnelle

​Score de fiabilité du service de la référence officielle

​Scores affichés des dimensions et score total

​Indicateurs de diagnostic indépendants

​Norme et conditions d’application

Périmètre de notation et lecture

États du score

Interprétation des résultats

Score total et composition des dimensions

Formule du score total

Composition à trois couches

Performance relative à la référence officielle B

Complétude des preuves C

Qualité des réponses

Jeu de tâches et notation

Conditions de comparaison et traitement des données manquantes

Prise en charge fonctionnelle

Groupes fonctionnels et poids

États de décision

Capacités natives et compatibilité d’interface

Vitesse de réponse

Charge et échantillonnage

Chronométrage et sortie valide

Formule de notation

Sorties invalides et isolation des mesures

Réussite du cache

Séquence de test et dénominateur

Cas anormaux et non observables

Fiabilité du service

Ensemble de test et conditions de réussite

Échecs, enregistrements invalides et intervalles

Échelle des tests et comparabilité

Taille des échantillons

Conditions d’exécution

Sources des jeux de données et enregistrement des résultats

Sources des jeux de données

Enregistrement et vérification des résultats

Données de référence et exemples de calcul

Performance absolue et sous-score de cache

Composition de la dimension prise en charge fonctionnelle

Score de fiabilité du service de la référence officielle

Scores affichés des dimensions et score total

Indicateurs de diagnostic indépendants

Norme et conditions d’application