Les 2026-11-03/04, la suite APB Full a été exécutée avec DeepSeek V4.1 Flash 1017 chez cinq fournisseurs via AIHubMix. Le même modèle, les mêmes questions, les mêmes paramètres et les mêmes scripts de requête ont été utilisés pour chaque fournisseur ; le modèle est répertorié sur la page du modèle AIHubMix, et les cinq entrées des fournisseurs se trouvent sur la page des modèles. Ce profil APB porte uniquement sur Alibaba Cloud : voici ce que chaque section a mesuré et les résultats obtenus.
Cet article présente les scores sans établir de classement des fournisseurs ni en recommander un. Q, F, P, K et R sont présentés en premier ; K est un sous-score de P. Le score global est un indice récapitulatif, pas une certification, et ne comporte pas d’intervalle de confiance. Les règles de notation sont définies dans AIHubMix Provider Benchmark Standard v2.0.
Scores des cinq fournisseurs
Le fournisseur présenté dans cet article est indiqué en gras. Les fournisseurs apparaissent dans un ordre fixe, qui ne constitue pas un classement. K est un sous-score de P, pondéré à 20%, affiché séparément à titre de référence. Le score global est un indice récapitulatif sans intervalle de confiance. L’écart global entre le canal officiel DeepSeek et Alibaba Cloud est de 0.37, et les deux ne sont pas distinguables.
En bref
- Qualité des réponses : Q 41.75. BFCL 87.00%, HLE 13.29%, AA-LCR 53.60%. Par rapport au canal officiel, l’écart est de −0.71 point de pourcentage, avec un intervalle à 95% de −1.72 à +0.26 ; les deux ne sont donc pas distinguables.
- Prise en charge des fonctions : F 89.78. 155 des 177 vérifications prises en compte dans le dénominateur ont réussi. Un schéma d’outil invalide a renvoyé une erreur 503 au lieu d’une erreur de paramètre, le dépassement du contexte n’a pas renvoyé le type d’erreur documenté, et un résultat d’outil isolé a renvoyé 200.
- Vitesse de réponse : P 88.58. La médiane du délai jusqu’au premier token de contenu était de 1.34 s avec une concurrence de 1 et de 1.35 s avec une concurrence de 10 ; le TPOT était de 4.69 ms, et les 180 requêtes de vitesse étaient toutes valides.
- Cache : K 99.37. Les 18 requêtes à chaud sur les préfixes de 8k et 32k ont toutes atteint le cache, et aucune lecture de contrôle à froid n’a utilisé le cache.
- Stabilité du service : R 100. Les 300 requêtes dédiées ont toutes réussi dès la première tentative.
Configuration des tests
L’exécution est passée par AIHubMix en sélectionnant l’ID du modèle du fournisseur ; le guide de démarrage rapide décrit l’itinéraire. La page des tarifs de DeepSeek indique les tarifs publiés pour le modèle.
| Élément | Détail |
|---|---|
| Modèle | DeepSeek V4.1 Flash 1017 |
| ID du modèle demandé | alicloud-deepseek-v4.1-flash-1017 |
| Nom du modèle renvoyé | deepseek-v4.1-flash-1017 |
| Itinéraire d’accès | Via AIHubMix, en sélectionnant l’ID du modèle du fournisseur, et non en se connectant au compte propre du fournisseur |
| Paramètres | Mode sans réflexion, temperature 1.0, max_tokens 16,384, délai d’expiration 300 s, aucune nouvelle tentative automatique |
| Réflexion désactivée | Toutes les requêtes utilisaient reasoning_effort=none |
| Période | 2026-11-03 18:07 – 11-04 16:33 UTC+8. Les cinq fournisseurs partageaient un même Mac mini, réseau et compte. |
| Échantillons | Qualité des réponses : 4,250 exécutions de questions (BFCL 500 × 3 tours, HLE 250 × 10, AA-LCR 25 × 10) ; cas de prise en charge des fonctions : 60 × 3 fenêtres ; vitesse : 90 avec une concurrence de 1 et 90 avec une concurrence de 10 ; stabilité : 300 ; cache : 30 (préfixes de 8k et 32k, 3 groupes chacun) |
Q — qualité des réponses : 41.75
La qualité des réponses a été évaluée à l’aide de trois ensembles de questions : 500 questions BFCL à raison de 3 tours chacune, 250 questions HLE à raison de 10 tours chacune et 25 questions AA-LCR à raison de 10 tours chacune. BFCL a été noté selon des règles automatiques ; HLE et AA-LCR ont été évalués par le modèle juge deepseek-flash. Les cinq fournisseurs ont répondu aux mêmes questions, et les résultats des trois ensembles ont été combinés en une seule mesure de précision. Dix réponses ont été exclues car les questions ne pouvaient pas être notées ; il reste donc 4,240 exécutions de questions notées.
| Tâche | Questions | Correctes | Précision | Échecs |
|---|---|---|---|---|
| Appels d’outil BFCL | 500 × 3 | 1,305/1,500 | 87.00% | 0 |
| Questions-réponses difficiles HLE | 250 × 10 | 331/2,490 | 13.29% | 8 |
| Raisonnement sur de longs documents AA-LCR | 25 × 10 | 134/250 | 53.60% | 0 |
| Combiné · intervalle à 95% : 39.56%–43.85% | — | 1,770/4,240 | 41.75% | 8 |
Les échecs de service (requêtes échouées ou sorties tronquées) restent dans le dénominateur et sont comptés comme des réponses incorrectes ; ils ne sont pas supprimés. Pour Alibaba Cloud, la sortie HLE a atteint la limite max_tokens et a été tronquée 8 fois.
Chaque question BFCL est traitée en 3 tours ; le tableau présente les résultats combinés des 3 tours.
| Catégorie BFCL | Réussites | Taux de réussite |
|---|---|---|
| simple_python : une fonction, appel et arguments corrects | 332/360 | 92.22% |
| multiple : choisir la bonne fonction parmi plusieurs | 270/300 | 90.00% |
| parallel : appeler plusieurs fois la même fonction en parallèle | 273/300 | 91.00% |
| parallel_multiple : appeler plusieurs fonctions différentes en parallèle | 212/240 | 88.33% |
| irrelevance : aucune fonction n’est pertinente, aucune ne doit être appelée | 113/150 | 75.33% |
| ahm_multi_turn : chaîne d’outils en trois étapes | 105/150 | 70.00% |
Comparaison avec les quatre autres
Par rapport au canal officiel : différence de précision en points de pourcentage, avec l’intervalle à 95% représenté par des barres d’erreur ; un intervalle qui recoupe 0 indique l’absence de distinction. Le modèle juge deepseek-flash utilisé pour HLE et AA-LCR appartient à la même famille DeepSeek que le modèle testé et n’a pas été calibré ; sa notation peut donc être indulgente.
F — prise en charge des fonctions : 89.78
Les cas de prise en charge des fonctions vérifient si le comportement de l’interface respecte le protocole, et non si le modèle répond correctement. Les 60 cas sont répartis en six groupes, chacun exécuté dans trois fenêtres, soit 180 vérifications, évaluées selon le format documenté par chaque fournisseur. Les vérifications non applicables, invalides ou non observées sont exclues du dénominateur. Alibaba Cloud a réussi 155 des 177 vérifications prises en compte dans le dénominateur ; la pondération des groupes donne un score de 89.78.
Le score pondéré est calculé à partir des pondérations des groupes, et non par simple comptage des réussites sur 177.
| Groupe | Pondération | Réussites | Exclues | Score du groupe |
|---|---|---|---|---|
| Streaming et protocole de messages | 20% | 30/30 | — | 100.00 |
| Interface d’outil | 20% | 30/30 | — | 100.00 |
| Contraintes de sortie et paramètres | 20% | 30/30 | — | 100.00 |
| Contexte et état | 15% | 26/30 | — | 86.67 |
| Erreurs et récupération | 15% | 18/30 | — | 60.00 |
| Protocole de comptabilisation et de cache | 10% | 21/27 | 3 | 77.78 |
| Total · score pondéré | — | 155/177 | 3 | 89.78 |
Un décompte de fenêtres de 3/3 signifie que le cas a échoué dans les trois fenêtres.
| Cas en échec | Fenêtres en échec | Raison |
|---|---|---|
| Dépassement du contexte (contexte et état) | 3/3 | Une erreur a été renvoyée, mais pas l’erreur de longueur de contexte documentée |
| Erreur de format messages (erreurs et récupération) | 3/3 | A renvoyé 400 avec un corps de réponse vide, sans description structurée de l’erreur |
| Schéma d’outil invalide (erreurs et récupération) | 3/3 | Devrait renvoyer une erreur de paramètre ; a renvoyé 503 |
| Résultat d’outil isolé (erreurs et récupération) | 3/3 | Devrait renvoyer une erreur de paramètre ; a renvoyé 200 |
| Erreur de format stream_options (erreurs et récupération) | 3/3 | A renvoyé 400 avec un corps de réponse vide, sans description structurée de l’erreur |
| Comptabilisation des tokens de raisonnement (protocole de comptabilisation et de cache) | 3/3 | Aucun décompte des tokens de raisonnement renvoyé |
| Définitions d’outils comptabilisées en entrée (protocole de comptabilisation et de cache) | 3/3 | Avec des définitions d’outils, le nombre de tokens d’entrée indiqué n’était pas supérieur à celui sans ces définitions |
| Isolation des requêtes (contexte et état) | 1/3 | La première étape n’a pas répondu uniquement STORED comme requis ; la vérification de l’isolation n’a donc pas pu se poursuivre |
Ces vérifications sont exclues du dénominateur et ne comptent ni comme réussites ni comme échecs.
| Statut | Cas | Nombre | Raison |
|---|---|---|---|
| Non applicable | explicit cache_control | 3 | Indiqué à l’avance comme non pris en charge par cette interface |
Les cas d’erreur de format messages et stream_options ont échoué chez les cinq fournisseurs : chacun a renvoyé 400 avec un corps vide, de sorte que le client n’a reçu aucune description structurée de l’erreur. Comme le même comportement est observé chez les cinq, il se situe probablement dans la couche passerelle d’AIHubMix et doit faire l’objet d’une investigation distincte. La comptabilisation des tokens de raisonnement a également échoué chez les cinq, mais pour des raisons différentes : ByteDance et Fireworks ont indiqué des tokens de raisonnement même lorsque la réflexion était désactivée, tandis que les trois autres n’ont renvoyé aucun décompte des tokens de raisonnement.
Comparaison avec les quatre autres
P — vitesse de réponse : 88.58
Chaque requête contenait environ 10,000 tokens d’entrée et demandait environ 1,100 tokens de sortie. Sur trois fenêtres, 30 requêtes ont été envoyées avec une concurrence de 1 et 30 avec une concurrence de 10, soit 180 au total. Le délai jusqu’au premier token de contenu (TTFA) est mesuré pour chaque requête valide, et le tableau présente les médianes. Le TPOT est estimé à partir des temps des segments de streaming, et non du temps par token mesuré sur le matériel ; le débit est le nombre de tokens de sortie valides avec une concurrence de 10, divisé par la durée murale du lot.
| Métrique | Résultat |
|---|---|
| Délai jusqu’au premier token de contenu TTFA | Médiane avec une concurrence de 1 : 1.34 s ; médiane avec une concurrence de 10 : 1.35 s |
| Vitesse de génération TPOT | Concurrence de 1 : 4.63 ms/token ; concurrence de 10 : 4.69 ms/token |
| Débit effectif (goodput) | Concurrence de 10 : 1,313.6 token/s |
| Requêtes valides | Concurrence de 1 : 90/90 ; concurrence de 10 : 90/90 |
| Scores des composantes | TTFA 59.65, TPOT 100.00, débit 100.00 ; le TTFA et le TPOT retiennent la valeur la plus basse des deux niveaux, avec des pondérations de 35% / 35% / 30% ; score de réponse 85.88 |
| Score P | Score de réponse 85.88 pondéré à 80%, cache K 99.37 pondéré à 20%, total 88.58 |
Comparaison avec les quatre autres
Les cinq fournisseurs partageaient la même machine, le même réseau et le même compte. Les trois fenêtres ont été programmées fournisseur par fournisseur ; les périodes de collecte ne se chevauchent donc pas entièrement, et il ne faut pas surinterpréter les petits écarts.
K — cache : 99.37
Chaque groupe comprend cinq requêtes : la première contient un préfixe fixe d’environ 8k ou 32k tokens et alimente le cache ; les requêtes 2 à 4 conservent le préfixe et ne modifient que la question à la fin, après 5, 30 et 120 secondes ; la cinquième utilise un nouveau préfixe comme contrôle à froid. Trois fenêtres × deux longueurs donnent 30 requêtes. K correspond au nombre de tokens lus depuis le cache dans les requêtes à chaud, divisé par le nombre de tokens réutilisables selon la règle, chaque longueur ayant le même poids ; K compte pour 20% de P. La matrice présente les lectures de tokens du cache signalées par le serveur.
| Préfixe | Fenêtre | Amorçage (requête 1) | À chaud après 5 s | À chaud après 30 s | À chaud après 120 s | Contrôle à froid (requête 5) |
|---|---|---|---|---|---|---|
| 8k | Fenêtre 1 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Fenêtre 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Fenêtre 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | Fenêtre 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | Fenêtre 2 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | Fenêtre 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| Préfixe | Hits à chaud | Tokens lus | Réutilisables attendus | Score |
|---|---|---|---|---|
| 8k | 9/9 | 71,424 | 72,270 | 98.83 |
| 32k | 9/9 | 288,000 | 288,279 | 99.90 |
| K (8k et 32k, moitié chacun) | 99.37 |
Les 9 requêtes à chaud avec un préfixe de 8k ont toutes atteint le cache et lu 7,936 tokens chacune ; les 9 requêtes à chaud avec un préfixe de 32k ont toutes atteint le cache et lu 32,000 tokens chacune. La requête d’amorçage et le contrôle à froid n’ont lu aucun élément du cache, ce qui distingue clairement les requêtes à chaud des requêtes à froid.
Comparaison avec les quatre autres
R — stabilité du service : 100
Les 300 requêtes couvraient quatre types — texte court, entrée longue de 10k, appels d’outil et historique à plusieurs tours — et ont été envoyées avec une concurrence de 1 sur trois fenêtres. Seule la première réponse a été vérifiée, pour sa validité et son exhaustivité ; l’exactitude de la réponse n’a pas été contrôlée et aucune nouvelle tentative n’a été effectuée. Les échecs des sections qualité des réponses et vitesse sont comptabilisés respectivement dans Q et P, et ne sont pas recomptés dans R.
| Type de requête | Réussite à la première tentative |
|---|---|
| Texte court | 120/120 |
| Entrée longue de 10k | 90/90 |
| Appels d’outil | 60/60 |
| Historique à plusieurs tours | 30/30 |
| Total · intervalle à 95% : 98.78%–100% | 300/300 |
Les 300 requêtes ont toutes renvoyé une réponse valide et complète dès la première tentative. R 100 ne couvre que ces 300 requêtes dédiées et ne signifie pas que l’ensemble de la chaîne n’a connu aucun échec. La borne inférieure de l’intervalle à 95 % est de 98.78 % : même avec 300/300, le taux d’échec est probablement inférieur à 1.22 %.
Par rapport aux quatre autres
R ne couvre que ces 300 requêtes dédiées ; les échecs de qualité des réponses et de vitesse sont enregistrés dans Q et P, et ne sont pas comptabilisés une seconde fois dans R.
| Fournisseur | Réussite dès la première tentative | Intervalle à 95 % |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek officiel | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
FAQ
L’écart global de 0.37 entre Alibaba Cloud et le canal officiel est-il significatif ?
Non. Les deux ne peuvent pas être distingués lors de ce test : l’écart de Q est de −0.71 point de pourcentage, avec un intervalle à 95 % de −1.72 à +0.26, qui inclut 0, et le score global est un indice récapitulatif sans intervalle de confiance.
Que combine le score Q ?
Trois ensembles : BFCL, 500 questions × 3 séries, évaluées automatiquement ; HLE, 250 × 10, et AA-LCR, 25 × 10, évalués par le modèle juge deepseek-flash. La précision combinée est de 41.75 % sur 4,240 exécutions de questions évaluées.
Pourquoi F est-il de 89.78 alors que 155 contrôles sur 177 ont réussi ?
Le score est pondéré par groupe, et non calculé comme un simple taux de réussite. Les groupes « erreurs et récupération » et « mesure de l’usage et protocole de cache » ont obtenu respectivement 60.00 et 77.78, tandis que les trois groupes de protocole ont obtenu 100.00.
Pourquoi R indique-t-il 100 si des requêtes ont échoué dans d’autres sections ?
R ne couvre que les 300 requêtes dédiées à la stabilité. Les échecs de qualité des réponses et de vitesse sont enregistrés dans Q et P, et ne sont pas comptabilisés une seconde fois dans R.
K 99.37 correspond-il à un taux de hit de cache ?
Il s’agit du rapport entre les tokens en cache lus lors des requêtes à chaud et les tokens qui devraient être réutilisables, avec une pondération égale pour 8k et 32k. Le préfixe 8k a obtenu 98.83 et le préfixe 32k, 99.90.
Le premier token en 1.34 s signifie-t-il que la réponse complète arrive en 1.34 s ?
Non. C’est le temps d’attente avant le premier token de contenu. Chaque requête demandait environ 1,100 tokens de sortie, et le TPOT à une concurrence de 10 était de 4.69 ms par token.
À lire ensuite : la série DeepSeek V4.1 Flash
- Le Q combiné d’Alibaba Cloud diffère de 0.71 point de pourcentage de la référence officielle, un écart qui se situe dans un intervalle incluant 0 ; le profil ByteDance examine la même comparaison pour la mesure de l’usage des appels d’outil : DeepSeek V4.1 Flash sur ByteDance : les appels d’outil correspondent, pas la mesure de l’usage.
- Alibaba Cloud a renvoyé des réponses valides pour les 180 requêtes de vitesse ; le profil Baidu utilise le même banc de test, où aucun canal disponible n’a affecté Q et P : DeepSeek V4.1 Flash sur Baidu : aucun canal disponible n’affecte Q et P.
- Le canal officiel sert de référence pour la comparaison de la qualité des réponses dans cet article ; son profil présente un F de 94.00 et 15 sondes invalides à concurrence unique : DeepSeek V4.1 Flash sur le canal officiel : F de 94.00, 15 sondes invalides.
- Alibaba Cloud a atteint 9/9 requêtes à chaud pour les deux longueurs de préfixe ; le profil Fireworks porte sur des réponses d’arrêt vides et 3/9 hits de cache à 8k : DeepSeek V4.1 Flash sur Fireworks : réponses d’arrêt vides, 3/9 hits de cache.
