Benchmark Qwen3.8 : ce qui est confirmé et reste à tester
Attention au nom : Qwen3.8 Max Preview n’est pas Qwen3-8B. Les scores de l’ancien modèle 8B ne constituent pas une preuve sur Qwen3.8.
Cette page peut qualifier les faits et limites documentés. Elle ne peut pas conclure que Qwen3.8 bat globalement Fable 5, GPT-5.6, Kimi K3 ou Qwen3.7 Max.
État actuel des preuves
| Niveau | Disponible ? | Ce qu'il permet | Ce qu'il ne permet pas |
|---|---|---|---|
| Statut et fonctions officiels | Oui | ID, canal, raisonnement/vision/texte | Classement global |
| Positionnement de lancement Qwen | Oui | Hypothèses et concurrents à tester | Victoire indépendante |
| Tests tiers par charge | Limités | Observations sur une tâche et une route | Capacité générale |
| Large couverture indépendante | Insuffisante | Futur comparatif transversal | Conclusion définitive aujourd'hui |
Une fonctionnalité documentée n'est pas un score, et un classement fournisseur n'est pas une preuve indépendante.
Ce que Qwen affirme officiellement
| Déclaration | Hypothèse utile | Conclusion dangereuse |
|---|---|---|
| 2,4 billions de paramètres | Tester si l'échelle améliore les tâches difficiles | Plus de paramètres garantit mieux. |
| Positionnement proche de la frontière | Inclure Fable, GPT, Kimi et Qwen3.7 | Qwen3.8 est indépendamment deuxième. |
| Orientation code et travail complexe | Tester dépôts et longues boucles d'outils | Qwen3.8 est le meilleur pour coder. |
| Projet Open Weights | Préparer serving et reproductibilité | Les poids seront identiques à la Preview hébergée. |
L'absence de nombre de paramètres actifs et de détails d'architecture empêche aussi d'inférer coût d'inférence, latence, mémoire ou calcul par token.
Ce que révèle un premier test tiers
Trilogy AI a comparé Qwen3.8 Max et Kimi K3 sur l'architecture d'un dépôt de 269 fichiers. En revue aveugle, Kimi a obtenu 83/100 et Qwen 80/100. Kimi a terminé plus vite avec moins de tokens ; Qwen a produit des frontières système plus propres et de meilleures métadonnées de replay.
Signal utile, mais périmètre étroit : une seule tâche, peu de données de variance et une dépendance possible au client, aux outils, au niveau de raisonnement et à la route. La conclusion prudente est que Kimi a gagné de peu ce test précis, tandis que Qwen a montré des forces de conception à reproduire ailleurs.
Le canal d’accès fait partie du résultat : l’essai Qwen cité utilisait le Token Plan international dans un harnais de code interactif, tandis que Kimi passait par un abonnement Kimi Code. Le score 83 contre 80 compare donc deux parcours de bout en bout datés, pas deux API de production interchangeables. Une réplication solide doit figer les entrées, noter séparément les affirmations et la structure, distinguer modèle et route, publier latence et tokens avec la qualité, anonymiser la revue si possible et montrer l’analyse des échecs.
Les preuves encore manquantes
Divulgation complète des benchmarks officiels
Un tableau fournisseur exploitable doit préciser version du modèle, réglage de raisonnement, accès aux outils, politique de prompt, nombre d’essais, méthode de notation et configuration des concurrents. Sans le harnais, un score reste difficile à reproduire.
Couverture de code reproductible
Il faut plusieurs dépôts, langages, types de tâches et répétitions. Tests exécutables, lint, build et défauts injectés sont plus solides qu'une appréciation de style.
Fiabilité des agents
Mesurez appels d'outils valides, reprise après échec, boucles, dérive des consignes, critères d'arrêt et intervention humaine sur de longues sessions.
Qualité en contexte long
Une fenêtre déclarée ne garantit pas son utilisation. Testez rappel, contradictions, sensibilité à la position et citations à 64K, 256K, 512K et à la taille réellement utile.
Grounding multimodal
Séparez OCR, localisation visuelle, raisonnement et extraction structurée. Comptez détails manqués et hallucinés.
Économie de production
Ajoutez à la latence et aux tokens la longueur des sorties, les retries, fallback, temps de revue et réparation des défauts.
Stabilité de la route et cycle de vie
Une Preview peut évoluer pendant la période d’observation. Chaque essai doit enregistrer l’ID exact, la date, le canal, la région, le client et la configuration afin qu’une répétition ne mesure pas silencieusement une autre Preview.
Droits d’accès reproductibles
Un benchmark n’est pas reproductible en production si la clé testée ne peut pas alimenter légalement ou techniquement la charge cible. Consignez séparément l’évaluation interactive, la régression automatisée, le backend applicatif et le trafic batch autorisés.
Pourquoi les benchmarks publics échouent souvent en production
Un score mélange modèle, route, cache, outils, retries et notation. Une équipe de production doit mesurer ces facteurs séparément, surtout pour les agents avec état, reprise et critères d’arrêt.
| Angle mort du benchmark | Échec de production masqué | Meilleure mesure |
|---|---|---|
| Qualité en une seule réponse | Plan correct, implémentation cassée | Tâche acceptée de bout en bout |
| Prompt idéal | Fragilité sur les entrées réelles | Taux de réussite sur variantes de prompt |
| Aucun échec d’outil | Boucle après un mauvais appel | Reprise après échec injecté |
| Un seul essai | Forte variance et format instable | Essais répétés et intervalle de confiance |
| Prix du token seul | Appel bon marché mais nombreux retries | Coût par tâche acceptée |
| Contexte maximal | Mauvais rappel dans une longue entrée | Rappel avec position des preuves contrôlée |
| Note de réponse finale | Affirmations sans preuve cachées dans un texte fluide | Audit des preuves affirmation par affirmation |
Ces angles morts comptent particulièrement pour un modèle de code et d’agents : l’utilité dépend de l’état, des outils, de la reprise et de l’arrêt correct, pas seulement de la dernière réponse.
Futur gate de benchmark EvoLink
Ce protocole ne sera exécuté qu’après l’arrivée d’une route API admissible en production. Ce n’est ni un résultat publié ni une raison de financer maintenant un grand test Token Plan.
1. Figer des charges réelles
Après l’arrivée de l’API, commencez par un petit pilote et n’élargissez qu’avec des preuves utiles. Documentez entrées, outils, budget temps, critères et gravité des erreurs.
| Catégorie | Test minimal | Signal d’acceptation |
|---|---|---|
| Code dans un dépôt | Correction de bug et fonction transverse | Tests réussis, aucune modification parasite |
| Agent de code | Tâche longue avec plusieurs outils | Appels corrects, aucune boucle non résolue |
| Raisonnement | Décision technique en plusieurs étapes | Résultat correct et hypothèses traçables |
| Contexte long | Recherche de preuves dans dépôt ou documents | Preuves exactes avec sources |
| Compréhension visuelle | Capture, graphique ou document | Extraction ancrée, faible taux d’invention |
| Données/productivité | Analyse de tableau et rapport exploitable | Exactitude numérique et livrable utilisable |
| Charge courante | Petite tâche fréquente | Gain mesurable de la route frontier |
2. Choisir des baselines pertinentes
Qwen3.7 Max pour la génération précédente stable, Kimi K3 pour le challenger long contexte, et la route Claude ou GPT réellement utilisée sur les tâches difficiles.
3. Enregistrer les conditions
Conservez ID exact, route, date, niveau de raisonnement, system prompt, permissions d'outils, préparation du contexte, sampling et retries. Un résultat nommé seulement « Qwen3.8 » n'est pas reproductible.
4. Répéter et évaluer en aveugle
Effectuez au moins trois essais pour les tâches non déterministes. Utilisez tests et validateurs quand c'est possible, et une grille fixe en revue aveugle pour le subjectif.
5. Mesurer de bout en bout
| Dimension | Mesures |
|---|---|
| Qualité | Acceptation, tests, erreurs factuelles, score de grille |
| Fiabilité | Erreurs, outils/JSON invalides, boucles, interventions |
| Latence | p50, p95, temps jusqu'au résultat accepté |
| Efficacité | Entrée, cache, sortie, raisonnement, outils |
| Coût | Modèle, retries, fallback, revue, réparation |
accepted_task_cost = model_usage + retries + fallback + reviewer_time + defect_repair6. Attribuer un rôle de routage
| Rôle | Preuve requise |
|---|---|
| Route par défaut | Acceptation, latence et coût stables sur trafic courant |
| Spécialiste du code | Avantage clair sur dépôts et outils |
| Spécialiste contexte long | Meilleur rappel et cohérence aux tailles réelles |
| Escalade qualité | Meilleure acceptation des tâches difficiles |
| Liste de suivi uniquement | Aucune route de production, aucun prix ou signal API reproductible |
Avant activation et validation d'une route EvoLink, « liste de suivi uniquement » est le rôle correct.
Lire un nouveau score Qwen3.8
Demandez qui l'a publié, quelle version et route ont été utilisées, le niveau de raisonnement, les outils disponibles, le nombre d'essais, la reproductibilité des prompts, la proximité avec votre produit et la présence de latence, tokens, retries et échecs. Sans ces champs, marquez le résultat comme directionnel.
Action recommandée
FAQ
Quel est le score de benchmark Qwen3.8 ?
Il n'existe pas de score global unique et fiable. Positionnement Qwen, tableaux incomplets et faible réplication ne suffisent pas.
Qwen3.8 est-il juste derrière Fable 5 ?
C'est le positionnement du fournisseur, pas un classement universel indépendant.
Qwen3.8 a-t-il été testé indépendamment ?
Oui, sur quelques charges dont le dépôt de 269 fichiers. Elles sont utiles mais trop étroites pour classer globalement le modèle.
Qwen3.8 est-il bon pour le code ?
Le code est un cas majeur du lancement, mais les équipes doivent tester dépôts, outils, reprise, tests et revue.
Comment le comparer à Kimi K3 ?
Entrées figées, mêmes permissions, grille identique, plusieurs essais et mesures séparées de qualité, latence, tokens, intervention et coût.
Les Credits Token Plan permettent-ils un benchmark coût ?
Seulement pour la consommation de l'expérimentation par abonnement, pas comme tarif API général face à un prix par token.
Quelles baselines inclure ?
Qwen3.7 Max, Kimi K3 et la route Claude ou GPT réellement routable par votre produit.
Quand Qwen3.8 est-il prêt pour la production ?
Lorsque route, ID, prix, limites, comportement et fallback sont vérifiés, et que les tests répétés atteignent votre seuil d'acceptation.
