Benchmark Qwen3.8 Max : résultats officiels et preuves terrain
Matrice des preuves
| Domaine | Résultat Qwen | Limite |
|---|---|---|
| Code | Terminal 86,6 ; SWE-Pro 67,7 | Séparer harness et réparation de dépôt |
| Agents | Toolathlon 72,5 | Mesurer outils, retries et intervention |
| Raisonnement | HLE 43,6 ; PaperBench 93,0 | Pas de classement universel |
| Multimodal | OmniDocBench 92,1 | Route média EvoLink à vérifier |
| EvoLink | Route live ; essai de preuve en attente | Exécuter 20–50 tâches avec succès, latence, retries, correction et coût |
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
Conserver une preuve reproductible derrière chaque score
Enregistrez ID, route, date, région, client, niveau Thinking, droits outils, cache, hash du prompt, essais, judge et règle d'acceptation. Sans ce registre, une révision peut sembler être un gain de qualité.
| Résultat | Artefact minimal | Usage permis |
|---|---|---|
| Qwen officiel | Tableau et configuration du harness | Hypothèses et baselines |
| Tiers | Prompts, route, répétitions, judge, échecs | Comparaison directionnelle |
| Communauté | Tâche reproductible ou preuve primaire | Edge case, pas de gagnant |
| Smoke test EvoLink | Request/response, Usage, latence, erreur | Confirmer le contrat |
| Workload EvoLink | Acceptance répétée et review | Main/Challenger/Fallback |
Publiez distribution et échecs, pas seulement les moyennes. Tool calls invalides, JSON cassé, timeouts, retries, fallbacks et correction humaine restent au dénominateur. Quatre succès et une boucle infinie peuvent être moins utiles qu'un score légèrement inférieur mais stable.
Versionner le dossier d'évaluation
Conservez prompts, fixtures, réponses brutes, logs outils, factures, règles du judge et décisions humaines dans un paquet daté. Une nouvelle version du modèle, du client ou de la route déclenche un nouveau run au lieu d'écraser l'ancien. Cette traçabilité permet de distinguer progrès réel, variance et changement d'infrastructure.
Transformer les benchmarks en décision de routage
Ne vous inscrivez pas sur la seule foi d’une annonce. Validez d’abord ces points, puis créez une clé API si la route correspond à votre charge.
- 01
Publié ?
Oui. Qwen3.8 Max est le modèle de production ; Preview reste un contexte de canal historique.
- 02
Disponible ?
Oui sur EvoLink. Vérifiez la route active et l’ID du modèle sur la page produit.
- 03
Adapté à mon cas ?
Pour le raisonnement long contexte, les grands dépôts et les agents à outils ; gardez les tâches simples sur une route plus légère.
- 04
Quel prix ?
Consultez le module de prix en direct de la page produit, sans reprendre un prix upstream ou Preview.
- 05
Comment l’appeler ?
Choisissez Chat Completions, Responses ou Messages, puis suivez le guide et la référence des paramètres.
Les cinq points sont validés ? Créer une clé API.
FAQ
Quel est le score de benchmark Qwen3.8 ?
Il n’existe pas de score global fiable. Qwen publie 86,6 sur Terminal-Bench 2.1, 67,7 sur SWE-bench Pro, 43,6 sur HLE et 92,1 sur OmniDocBench 1.5 ; ce sont des résultats fournisseur, pas un rang universel.
Qwen3.8 est-il juste derrière Fable 5 ?
Cela reste l’interprétation d’un fournisseur sur sa propre évaluation, pas un classement universel vérifié indépendamment. Attribuez plutôt un rôle par charge.
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 ?
Non. Les Credits décrivent une expérience Preview ; la comparaison de production doit utiliser le prix réellement facturé par le fournisseur ou la route EvoLink du même run.
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 ?
Quand route, ID, prix, limites, comportement et fallback sont vérifiés, et que des tâches réelles répétées atteignent le seuil d’acceptation.
Sources
- Journal des modèles QwenCloud
- Sortie technique et benchmarks Qwen3.8 Max
- Annonce Qwen3.8
- Qwen Token Plan
- Qwen Chat API
- Trilogy AI : benchmark Qwen3.8 Max vs Kimi K3
