DeepSeek V4.1 Pro est-il en test ? Ce que révèle le score de 64 % sur LobeBench

DeepSeek V4.1 Pro suscite de nouveau l’attention après qu’un évaluateur indépendant a signalé une forte évolution des résultats du V4 Pro actuel sur un ensemble privé de tâches pour agents. Le gain rapporté intéresse les développeurs : il porte sur la capacité à terminer une tâche difficile de manière répétée, et pas seulement une fois.

Il faut toutefois préciser ce qui a été comparé : une expérience observée sur le site et une version antérieure de V4 Pro. Cette évaluation ne prouve ni que DeepSeek a déployé V4.1 Pro, ni qu’un déploiement a causé la récente interruption du service.

Que montre le test LobeBench ?

Max For AI, développeur et mainteneur de LobeHub, a publié les résultats de LobeBench Hard 50, un ensemble privé de 50 tâches complexes pour agents. Selon lui, ces tâches évaluent notamment la compréhension d’une demande, l’utilisation d’outils et la capacité à poursuivre le travail jusqu’à son terme.

Sur la mesure des trois réussites en trois tentatives, la hausse est de 16 points de pourcentage, soit huit tâches. L’évaluateur affirme aussi que le résultat actuel arrive en tête des modèles chinois de sa comparaison. Ce classement concerne ce test privé et les modèles évalués, pas l’ensemble des modèles chinois.

Découvrez nos DeepSeek Coding Plans et leur disponibilité actuelle.

Pourquoi réussir les trois tentatives compte-t-il ?

Réussir une tâche au moins une fois montre que le modèle trouve parfois une solution. La réussir aux trois tentatives pose une question plus exigeante : peut-il la terminer de façon répétée dans les conditions du test ? Pour un agent qui doit appeler des outils et enchaîner plusieurs étapes, la régularité peut compter autant qu’un résultat isolé impressionnant.

Les taux de réussite au moins une fois sont proches, alors que les résultats aux trois tentatives sont plus éloignés. Cela suggère une meilleure régularité sur ce test. Trois essais et 50 tâches ne suppriment toutefois pas l’effet du hasard, et un jeu de tests privé est plus difficile à examiner ou à reproduire. Ce résultat ne prouve pas à lui seul une amélioration générale sur toutes les tâches de programmation ou configurations d’agents.

Le modèle testé est-il DeepSeek V4.1 Pro ?

Le benchmark n’a pas établi l’identité du modèle. L’évaluateur a décrit le V4 Pro disponible sur le site de DeepSeek et évoqué un possible test progressif de V4.1 Pro. Un meilleur score, un nom affiché familier ou un changement de style ne permettent pas d’identifier le checkpoint ni d’exclure des modifications de configuration, de routage ou du système d’agent.

L’annonce de V4.1 Flash par DeepSeek en septembre évoquait une future sortie de V4.1 Pro. Le journal des modifications de l’API a ensuite indiqué que le service V4 Pro continuerait après le 14 septembre. Le plan de routage initial de l’annonce ne doit donc pas être considéré comme la configuration actuelle de l’API. Le test sur le site ne décrit pas non plus automatiquement ce que reçoit chaque client de l’API.

La panne annonçait-elle une sortie ?

L’historique de DeepSeek indique des interruptions partielles du site et de l’API les 3 et 7 novembre. L’incident du 7 novembre a touché les API V4 Pro et V4.1 Flash ainsi que d’autres services ; il a été déclaré résolu après 45 minutes. La proximité entre une panne et un changement de performance rapporté ne prouve pas que l’un a causé l’autre.

Des publications sur les réseaux sociaux affirment aussi que DeepSeek a démenti la rumeur de test progressif. Nous n’avons pas pu vérifier de manière indépendante la déclaration officielle originale alléguée ; cette affirmation reste donc elle aussi non confirmée.

Quand DeepSeek V4.1 Pro sera-t-il lancé ?

Les documents officiels consultés pour cette mise à jour ne donnent aucune date de sortie confirmée. Les prévisions d’un lancement la semaine suivante restent des spéculations. La sortie de V4 Pro-0813 le 13 août apporte du contexte, mais le temps écoulé ne permet pas d’établir le calendrier de son successeur.

Comment les développeurs peuvent-ils vérifier un changement significatif ?

1. Choisissez plusieurs tâches représentatives, dont certaines ont déjà échoué, et gardez les mêmes prompts, outils, framework d’agent et critères d’évaluation.
2. Exécutez chaque tâche plusieurs fois. Notez si elle réussit au moins une fois et à quelle fréquence, ainsi que les erreurs et le temps nécessaire.
3. Notez la date, le service ou fournisseur, le nom affiché, l’identifiant API le cas échéant, les paramètres et toute version ou empreinte renvoyée. Un nom inchangé ne prouve pas que le modèle sous-jacent est resté le même.
4. Comparez suffisamment de tâches et d’exécutions pour voir si le gain apparent persiste. Un petit échantillon ne prouve pas l’identité du modèle.

Pour le contexte, consultez notre article d’octobre sur les spéculations autour du déploiement de V4.1 Pro et notre couverture de la sortie de V4 Pro-0813.