Évaluations de DeepSeek V3.2 : ce que mesurent ses benchmarks et jusqu’où peut-on les comparer ?

Périmètre : ce que les éléments disponibles permettent d’affirmer

Un score de benchmark ne décrit pas à lui seul un modèle. Pour l’interpréter, il faut au minimum connaître la tâche évaluée, le jeu de tests, la métrique, la variante du modèle et les conditions d’exécution. Si l’un de ces éléments diffère entre deux résultats, la comparaison peut ne plus être directe, même si les deux chiffres figurent dans un même tableau ou sont présentés comme les résultats d’un même système.

Cet examen applique ces critères à DeepSeek-V3.2. Les documents disponibles confirment l’existence d’un paper portant ce nom et d’une note officielle de lancement qui distingue DeepSeek-V3.2 de DeepSeek-V3.2-Speciale. Ils recensent également la documentation du modèle sur Hugging Face, un dépôt DeepSeek consacré à DeepSeek-V3.2-Exp, ainsi que des analyses externes de V3.2-Exp et des benchmarks d’API. Les extraits fournis ne contiennent cependant ni les tableaux complets ni les protocoles d’évaluation du paper.

C’est pourquoi cet article ne présente aucun score précis et ne reconstitue pas de classement entre modèles. Il ne transforme pas non plus des mentions générales du raisonnement, de la programmation ou de l’utilisation d’outils en résultats quantitatifs. Son objectif est de délimiter ce que les éléments repérés permettent d’affirmer, de distinguer des sources de nature différente et de préciser ce qui doit être vérifié dans les documents complets avant d’utiliser un chiffre pour choisir un modèle ou comparer des systèmes.

L’index des benchmarks et la fiche intitulée « évaluations-deepseek-v32 » sont des parcours thématiques permettant d’organiser cet examen ; ils ne constituent pas, à eux seuls, la preuve qu’un test a été réalisé ou qu’un résultat est reproductible. DeepSeek est l’organisation concernée ici et le modèle examiné est DeepSeek-V3.2, pas n’importe quel système dont le nom contient « DeepSeek ».

Inventaire des sources et des éléments qu’elles permettent de vérifier

Le paper intitulé DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models est la source prioritaire pour examiner les évaluations attribuées au modèle. L’extrait disponible le présente comme un travail consacré à DeepSeek-V3.2, avec un accent général sur l’efficacité de calcul, le raisonnement et les performances des agents. Ce résumé ne révèle ni les noms des benchmarks, ni leurs scores, ni les jeux évalués, ni les conditions d’exécution. Il ne suffit donc pas à dresser un inventaire complet des tests.

La note officielle de lancement aide à distinguer les variantes : le matériel fourni sépare V3.2, présenté sous l’angle de l’équilibre entre inférence et longueur, de V3.2-Speciale, décrit comme une configuration privilégiant des capacités de raisonnement maximales. Cette distinction est importante, mais elle ne prouve pas qu’un tableau particulier du paper évalue l’une ou l’autre variante. Pour attribuer chaque résultat, il faut consulter l’en-tête du tableau, ses notes et la section méthodologique correspondante.

La fiche du modèle sur Hugging Face est une documentation primaire du fournisseur et confirme l’existence d’une page identifiée comme DeepSeek-V3.2. L’extrait fourni ne précise pas de protocole complet de benchmark. En parallèle, la critique externe intitulée DeepSeek V3.2-Exp Review concerne explicitement V3.2-Exp et mentionne de façon générale des évaluations de programmation ; ses conclusions ne doivent pas être automatiquement transposées à V3.2.

Le dépôt DeepSeek-V3.2-Exp porte lui aussi sur une variante expérimentale. L’extrait indique que ses configurations d’entraînement ont été alignées sur celles de V3.1-Terminus afin d’étudier l’effet de l’attention dispersée. Cela caractérise l’objectif expérimental décrit, mais ne prouve pas que les résultats de la version Exp soient ceux du modèle V3.2. Enfin, l’analyse de DeepInfra porte, d’après son titre et sa description, sur des benchmarks d’API, la latence et le débit. Il s’agit d’un autre type de mesure, qu’il ne faut pas mélanger aux tests de capacité sans examiner sa méthodologie.

Les informations que doit contenir une fiche benchmark par benchmark

Pour publier un tableau d’évaluations traçable, chaque ligne doit identifier le test et expliquer la tâche qu’il propose. Une étiquette comme « raisonnement » ou « programmation » ne suffit pas : il convient de préciser le jeu de données ou la version du benchmark, le type d’entrée et de sortie ainsi que le critère de notation. Il faut également indiquer si le résultat correspond à une exécution directe, à une configuration avec outils ou à un système associant le modèle à un environnement.

La métrique doit être nommée et définie, et pas seulement recopiée sous forme de chiffre. Un taux de réussite, un score agrégé et une mesure de latence répondent à des questions différentes. Si plusieurs métriques sont utilisées, il faut indiquer laquelle sert à la comparaison principale et comment elle a été calculée. Lorsqu’un test est exécuté plusieurs fois, le nombre de tentatives et la méthode d’agrégation sont importants. Si un seul résultat est communiqué, il ne faut pas supposer qu’il s’agit d’une moyenne ou qu’une incertitude statistique a été publiée.

L’identification du modèle doit elle aussi être précise. « DeepSeek » peut désigner différentes générations, et V3.2, V3.2-Speciale et V3.2-Exp ne sont pas des noms interchangeables. Une version d’API, une révision des poids ou une configuration avec outils peuvent changer la nature de l’évaluation. Si la source n’identifie pas l’artefact exact, cette limite doit rester visible au lieu d’être comblée par déduction.

Les extraits disponibles ne contiennent pas les lignes nécessaires pour remplir cette fiche. Un tableau de résultats chiffrés serait donc incomplet s’il était établi à ce stade. Le tableau des éléments repérés ci-dessus est volontairement une matrice de disponibilité : il évite de présenter comme vérifié ce qui exigerait de consulter et de confronter le paper complet.

Protocole et comparabilité : pourquoi deux chiffres ne sont pas forcément équivalents

Une comparaison valable exige davantage que l’utilisation du même nom de benchmark. La version du jeu de données, les consignes, le prompt, le harness et la méthode de notation peuvent influer sur le résultat. Les outils disponibles comptent également : un agent disposant d’un accès à la recherche, à l’exécution de code ou à d’autres ressources n’est pas nécessairement évalué dans les mêmes conditions qu’un modèle isolé. Ces variables doivent être décrites dans la source ou contrôlées lors de la comparaison.

Le budget de tokens est une autre condition importante. Si une exécution peut générer davantage de tokens, effectuer plus d’étapes ou multiplier les tentatives, elle dispose de plus d’occasions de résoudre une tâche. Cela n’invalide pas l’évaluation, mais oblige à décrire le budget et à ne pas présenter le résultat comme s’il avait été obtenu avec des ressources équivalentes. Il en va de même pour les limites de temps, les paramètres d’échantillonnage et les critères de répétition des réponses.

Les extraits fournis ne détaillent ni le prompt, ni le harness, ni les outils, ni le budget de tokens, ni le nombre d’exécutions des tests du paper. Ils n’indiquent pas non plus si les scores de DeepSeek et ceux d’autres modèles ont été obtenus avec des versions identiques des jeux et des procédures équivalentes. Il est donc impossible, à partir de ce matériel, d’affirmer qu’une comparaison donnée est équitable ou ne l’est pas. La formulation juste est qu’elle n’est pas vérifiée ici.

Les analyses d’API doivent être séparées pour une raison supplémentaire. Une mesure de latence peut dépendre de la région, de la charge du service, de la taille de l’entrée et de la longueur de la réponse. Le débit peut refléter la capacité de service sous une charge donnée. Ces observations peuvent être utiles pour évaluer un déploiement, mais elles ne remplacent pas un test de capacité du modèle et ne doivent pas être intégrées à un classement de raisonnement sans expliquer le lien entre les métriques.

Contamination, reproductibilité et limites des éléments disponibles

La contamination d’un jeu d’évaluation par des données d’entraînement peut compromettre l’interprétation d’un score, mais elle ne doit pas être déduite du seul fait qu’un résultat semble élevé ou que le benchmark est connu. Pour étayer une affirmation de contamination, il faut des éléments probants et une explication de la méthode utilisée pour la détecter ou la limiter. Le matériel disponible ne permet pas de confirmer quelles vérifications le paper décrit ni quels éléments il fournit concernant les recouvrements.

La reproductibilité suppose que suffisamment d’éléments soient publiés pour reconstruire l’évaluation : version du modèle, code ou harness, consignes, configuration, accès aux cas et conditions d’exécution. L’existence d’une fiche de modèle ou d’un dépôt ne prouve pas, à elle seule, que tous ces composants sont disponibles pour chaque benchmark. De même, la description d’une variante expérimentale ne démontre pas que ses évaluations peuvent être reproduites dans des conditions identiques.

Dans le cadre de cet examen, le niveau de détail disponible est inégal. Les sources permettent de distinguer les objets concernés — paper du modèle, note de lancement, fiche, variante expérimentale et mesures d’API —, mais pas de certifier l’inventaire complet des tests, de reproduire leurs scores ou d’évaluer les vérifications de contamination. Cette différence entre « la source existe » et « le protocole est vérifié » doit être préservée dans tout résumé ultérieur.

Si le document complet comporte des annexes, des notes de tableau ou des liens vers du code, ces éléments pourraient résoudre une partie des questions en suspens. Tant qu’ils n’ont pas été consultés, l’absence d’informations dans les extraits reçus ne doit pas être transformée en affirmation selon laquelle DeepSeek n’a pas publié ces données. La formulation exacte est plus limitée : les éléments disponibles ici ne suffisent pas à les vérifier.

Variantes et accès : modèle, expérimentation et service

La note officielle de lancement distingue DeepSeek-V3.2 de DeepSeek-V3.2-Speciale. Cette distinction suffit à exiger que chaque chiffre soit attribué à une variante identifiable, mais elle ne permet pas de savoir laquelle a été évaluée dans chaque test. Avant de comparer les résultats, il faut examiner le nom indiqué dans le tableau original et toute note définissant la configuration. Si le tableau indique seulement « V3.2 », il ne faut pas le réinterpréter automatiquement comme désignant Speciale ou V3.2-Exp.

V3.2-Exp doit être traité séparément. La source de DeepSeek consacrée à cette variante la situe dans une étude de l’attention dispersée et mentionne l’alignement de configurations d’entraînement avec V3.1-Terminus. Ces informations aident à comprendre pourquoi une évaluation de la version Exp pourrait relever d’une expérience comparative particulière. Elles n’autorisent pas à additionner ses résultats à ceux de V3.2 comme s’il s’agissait d’une seule version.

Il convient également de distinguer les poids ou le modèle des conditions d’accès par API. La réponse fournie peut dépendre d’une version déployée, de limites opérationnelles et de paramètres de service. Une analyse externe de la latence et du débit peut décrire le comportement d’une API dans les conditions choisies par l’évaluateur ; sans détails sur cet environnement, il ne faut pas attribuer une différence exclusivement à l’architecture ou à la capacité générale du modèle.

Pour les responsables d’achat, cette distinction évite une conclusion fréquente mais fragile : choisir une configuration parce qu’elle est associée au score d’une autre variante ou à une mesure de service qui répond à une question différente. Une décision exige d’identifier le produit exact, le mode d’accès et la tâche réelle de déploiement, puis de vérifier si l’évaluation reflète les contraintes et les outils qui seront disponibles en production.

Ce que les tests permettent de conclure — et ce qui échappe à leur portée

Lorsqu’un score est vérifié, la conclusion doit se limiter à la tâche, au jeu et aux conditions dans lesquels il a été obtenu. Un résultat à un test de programmation ne démontrerait pas automatiquement un niveau général en programmation dans tous les langages, dépôts ou flux de travail. Une évaluation du raisonnement ne prouverait pas, à elle seule, la sécurité, la fiabilité dans la durée, la qualité des citations, l’adaptation à une organisation ou les performances en production.

Dans ce cas précis, les extraits fournis ne permettent pas de formuler de conclusion quantitative sur DeepSeek-V3.2 ni d’affirmer qu’il surpasse un modèle donné sur un benchmark particulier. Ils permettent néanmoins de structurer les bonnes questions : quelle variante a été testée, quelle tâche a été mesurée, quelle métrique a été communiquée, quelles ressources étaient autorisées et qui a réalisé le test. Ils permettent aussi de rappeler que la critique de V3.2-Exp et l’analyse des benchmarks d’API ne remplacent pas le protocole du paper.

Une évaluation opérationnelle devrait compléter les benchmarks publiés par des tests internes reposant sur des tâches représentatives et des critères définis avant la comparaison. Une évaluation interne devrait tenir compte des échecs, de la variabilité, des coûts et des délais, et pas seulement du meilleur résultat. Si des outils sont employés, l’évaluation doit porter sur le système complet et documenter la part du résultat qui dépend du modèle et celle qui dépend de l’environnement.

Il n’est pas possible d’affirmer qu’une évaluation publiée prédit à elle seule le comportement de DeepSeek-V3.2 dans tous les contextes. Le transfert dépend de la proximité entre la tâche de test et l’usage réel. Cette limite ne discrédite pas les benchmarks : elle délimite les questions auxquelles ils répondent et évite de transformer une mesure circonscrite en affirmation générale sur les capacités.

Conclusion : résultats vérifiés et questions en suspens

La conclusion la plus solide permise par les éléments disponibles est d’ordre méthodologique. Il existe un paper sur DeepSeek-V3.2, une note officielle qui distingue V3.2 de V3.2-Speciale, ainsi que des documents concernant une variante V3.2-Exp et des mesures d’API. Ces sources ne sont pas interchangeables : chacune porte sur un objet ou une question différente. L’extrait du paper ne fournit ici ni les tableaux ni le protocole complet ; il n’existe donc pas de base suffisante pour publier un classement quantitatif vérifié.

Avant d’intégrer des résultats à une comparaison, il faut consulter le paper complet et consigner chaque test avec sa version, sa variante, sa métrique et ses conditions. Il faut ensuite confronter les notes de tableau et les annexes, puis séparer les résultats officiels des évaluations externes. Si une condition n’est pas indiquée, elle doit être signalée comme inconnue ; il ne faut pas la déduire de la fiche du modèle, d’une critique ou de la description d’une autre variante.

Pour les lecteurs de l’index des benchmarks, la règle pratique est simple : un score n’est comparable que si la tâche et les conditions pertinentes sont suffisamment alignées. Les équipes qui évaluent DeepSeek-V3.2 devraient exiger une traçabilité jusqu’au tableau source et réaliser leurs propres tests avec le produit et la configuration réellement prévus pour le déploiement. Au vu des éléments fournis à ce stade, les résultats concrets restent à vérifier dans la documentation.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.