Une mise à jour discrète de deepseek-v4-flash est arrivée aujourd’hui. Sur quatre tâches évaluées, la version 0731 fait jeu égal avec GLM-5.2 à trois reprises, remporte la quatrième et coûte 19x moins cher à exécuter. Cela ne fait pas de Flash le modèle le mieux noté sur le papier : GLM-5.2 conserve cet avantage. Mais son échec sur ma quatrième tâche révèle un piège très concret.
Ce piège, c’est le budget de raisonnement. Via l’endpoint testé, GLM-5.2 raisonne longuement, même sur des requêtes courtes. Sur une tâche chargée en spécifications, il a consommé 16 000 tokens de sortie sans jamais produire de réponse. Flash a terminé cette même tâche en 2 525 tokens.
Ce que la version 0731 change pour deepseek-v4-flash
La documentation API de DeepSeek référence désormais DeepSeek-V4-Flash-0731 comme version de deepseek-v4-flash. La méthode d’appel ne change pas et l’alias pointe toujours vers la version la plus récente : votre code continue donc de fonctionner, sans vous signaler que le modèle sous-jacent a changé.
Aucune note de version n’accompagne cette mise à jour sur la page tarifaire, et l’index des actualités de DeepSeek ne comportait aucune entrée pour juillet 2026 lorsque je l’ai consulté le 2026-07-31. Il faut donc lire les comparatifs avec prudence : un score publié pour Flash reflète la version active lors du test. Vérifiez la date d’évaluation et la variante, car « Flash Base », « Flash (Reasoning) » et « Flash (Reasoning, Max Effort) » correspondent à trois lignes distinctes, avec des chiffres différents.
Cette même page de documentation confirme les caractéristiques utiles pour cette comparaison : 1M de contexte, une sortie maximale de 384K, le mode thinking activé par défaut avec un mode non-thinking disponible, ainsi qu’une limite de concurrence de 2 500 contre 500 pour Pro. À ce jour, la Responses API ne prend en charge que deepseek-v4-flash ; deepseek-v4-pro est annoncé pour début août 2026.
Quatre tâches identiques : les résultats réels
J’ai envoyé les mêmes prompts aux deux modèles via un relais compatible OpenAI le 2026-07-31. Le mode thinking est resté sur son réglage par défaut et max_tokens était fixé à 8 000, sauf indication contraire. Les sorties ont été évaluées mécaniquement, et non à l’œil : les deux exercices de code ont été exécutés contre des jeux de tests cachés, respectivement de 6 et 8 cas ; la tâche JSON a été vérifiée clé par clé face au schéma demandé ; la tâche de récupération n’admettait qu’une seule chaîne correcte.
| Tâche | DeepSeek V4 Flash (0731) | GLM-5.2 |
|---|---|---|
| t1 — repérer et corriger un cas limite dans une fusion d’intervalles | 6/6 tests, 5,0 s, 361 en sortie | 6/6 tests, 19,0 s, 990 en sortie |
t2 — implémenter next_version() selon une spécification à 8 règles | 8/8 tests, 29,9 s, 2 525 en sortie | aucune réponse renvoyée |
| t3 — JSON strict, clés exactes, sans bloc de code | réussi, 5,2 s, 327 en sortie | réussi, 11,2 s, 826 en sortie |
| t4 — retrouver et combiner 3 faits dans ~45K tokens | correct, 5,2 s, 172 en sortie | correct, 9,7 s, 317 en sortie |
Trois tâches sur quatre sont de vraies égalités. Les deux modèles ont trouvé le même bug dans t1 — un < strict qui ne fusionne pas les intervalles adjacents comme (1,4) et (4,5) — et ont livré le même correctif d’un seul caractère. Tous deux ont aussi réussi la tâche de JSON strict octet pour octet. Enfin, ils ont correctement résolu t4 en combinant un secret enfoui dans l’enregistrement 211 avec une règle située dans l’enregistrement 1290, pour renvoyer quartz-mallard-90.
t2 est l’exception, et elle mérite d’être décrite sans triomphalisme. GLM-5.2 n’a pas donné une mauvaise réponse : il n’en a donné aucune. Avec une limite de 8 000 tokens, il a consacré les 8 000 tokens au raisonnement puis renvoyé un contenu vide après 110 s. J’ai relancé à 16 000 pour écarter l’hypothèse d’une limite trop basse de mon côté : 16 000 tokens consommés, toujours aucun contenu, en 214 s. Une troisième tentative à 24 000 a échoué après 301 s. Flash, lui, a produit une fonction validant les huit cas, y compris les trois qui doivent lever ValueError.
Les limites de ce test doivent être explicites : il s’agit de n=1 par tâche via un seul endpoint relais, pas d’un benchmark. Ici, les tokens de raisonnement sont facturés dans completion_tokens, tandis que l’endpoint officiel de Z.ai peut les streamer ou les comptabiliser différemment. Ce que les données permettent de défendre, c’est la tendance, pas un ratio exact : GLM-5.2 consomme nettement plus de tokens et de temps réel par tâche.
Pourquoi GLM-5.2 reste devant en capacité
Selon les métriques qui font référence dans l’industrie, GLM-5.2 est le modèle le plus puissant ; lire mes résultats comme la victoire universelle du moins cher serait une erreur. Artificial Analysis attribue 51 à GLM-5.2 (max) dans son Intelligence Index, contre 40 pour DeepSeek V4 Flash (Reasoning, Max Effort). L’écart est de 11 points, avec un modèle beaucoup plus grand : 753B de paramètres au total et ~40B actifs, contre 284B au total et 13B actifs pour Flash.
Les chiffres publiés par Z.ai pour GLM-5.2 sont ceux attendus d’un flagship : SWE-bench Pro à 62,1 %, Terminal-Bench 2.1 à 81,0, AIME 2026 à 99,2 %, GPQA Diamond à 91,2 %, et HLE avec outils à 54,7 %. Ils sont fournis par l’éditeur, et Flash ne possède pas d’entrée comparable pour la plupart de ces évaluations.
C’est d’ailleurs le constat le plus honnête côté benchmarks : les deux modèles ne partagent pratiquement aucune évaluation. Le site de suivi benchlm les compare mais refuse de désigner un vainqueur, en relevant qu’ils n’ont aucune ligne directement comparable. Les résultats publics de Flash viennent d’une suite destinée aux modèles de base — MMLU 88,7 %, HumanEval 69,5 %, GSM8K 90,8 % — tandis que ceux de GLM-5.2 proviennent d’une suite consacrée au code agentique.
Les connaissances constituent la seule catégorie de recouvrement. Sur ce point, benchlm place GLM-5.2 devant, 59,6 contre 56,4. Lorsque deux pages de comparaison divergent sur ce duel, c’est généralement parce qu’elles ont comparé des variantes et des suites de tests différentes. Le chiffre pertinent est celui dont la variante et la date correspondent au modèle que vous comptez appeler.
Les retours de praticiens décrivent la même séparation que celle observée ici. Dans un fil r/opencodeCLI où la même tâche était exécutée sur les deux modèles :
GLM 5.2 reasons hard on everything. V4 scales it, almost no wind-up on the simple fix, GLM 5.2 pulls ahead on anything that is not banally [simple] …
Tout est là : le raisonnement de GLM-5.2 devient un atout sur les problèmes difficiles, mais un surcoût pur sur les tâches simples.
L’écart de coût dépasse largement les tarifs affichés
Commençons par les prix catalogue, tous vérifiés sur les pages officielles des éditeurs le 2026-07-31.
| Par 1M de tokens | DeepSeek V4 Flash | GLM-5.2 | Multiplicateur GLM |
|---|---|---|---|
| Entrée (cache manqué) | $0.14 | $1.40 | 10.0x |
| Entrée (cache touché) | $0.0028 | $0.26 | 92.9x |
| Sortie | $0.28 | $4.40 | 15.7x |
| Sortie maximale | 384K | 128K | — |
En appliquant ensuite ces tarifs aux tokens réellement consommés par chaque modèle sur mes quatre tâches, l’écart dépasse le ratio de 15,7x sur la sortie. La raison est simple : le modèle le plus cher est aussi le plus bavard.
| Tâche | Flash entrée→sortie | Coût Flash | GLM-5.2 entrée→sortie | Coût GLM-5.2 | Multiplicateur |
|---|---|---|---|---|---|
| t1 correction de bug | 165→361 | $0.000124 | 170→990 | $0.004594 | 37.0x |
| t2 implémentation | 182→2,525 | $0.000732 | 196→16,000 | $0.070674 | 96.5x |
| t3 JSON strict | 171→327 | $0.000116 | 177→826 | $0.003882 | 33.5x |
| t4 contexte long | 45,225→172 | $0.006380 | 44,164→317 | $0.063224 | 9.9x |
| Total des quatre | 45,743→3,385 | $0.007352 | 44,707→18,133 | $0.142375 | 19.4x |
Tous les prompts ont été envoyés à froid : l’ensemble des tokens d’entrée est donc facturé au tarif cache manqué. Multipliez les colonnes ci-dessus par les tarifs du tableau précédent pour retrouver chaque montant.
t4 présente l’écart le plus faible, à 9,9x. Sur une tâche dominée par les tokens d’entrée, le ratio de 10x sur l’input l’emporte et la verbosité en sortie pèse moins. C’est la configuration où le surcoût de GLM-5.2 reste le plus contenu.
La page tarifaire de DeepSeek indique que l’API « adoptera bientôt une politique tarifaire heures pleines/heures creuses », avec un facteur de 2x sur tous les postes de facturation entre 09:00–12:00 et 14:00–18:00, heure de Pékin (UTC+8). La date d’entrée en vigueur reste à annoncer. Cela ramènerait l’avantage de Flash sur la sortie à environ 5x pendant les heures de bureau asiatiques. À l’inverse, l’entrée sur cache touché de Flash à $0.0028 coûte 93x moins cher que les $0.26 de GLM-5.2 : rejouer un gros préfixe stable creuse donc encore l’écart. Enfin, pour un usage spécifiquement orienté code, le Coding Plan de Z.ai démarre à $18/month, inclut GLM-5.2 et propose une utilisation hors pointe à demi-tarif ; il s’agit d’une facturation différente des prix au token ci-dessus.
Quel modèle choisir selon la charge de travail
| Charge de travail | Choix | Pourquoi |
|---|---|---|
| Corrections de code simples à intermédiaires, à fort volume | V4 Flash | Même réponse que GLM-5.2 sur ma t1, 3,8x plus rapide et 37x moins cher |
| Sorties structurées ou format strict à grande échelle | V4 Flash | Résultat identique octet pour octet pour 1/34e du coût |
| Récupération en contexte long dans de gros documents | V4 Flash | Même bonne réponse ; écart de coût le plus réduit, mais encore de 9,9x |
| Code agentique complexe ou projets multi-fichiers | GLM-5.2 | 51 contre 40 à l’Intelligence Index, et ses propres tests agentiques sont là où il marque |
Toute tâche avec un max_tokens serré | V4 Flash | GLM-5.2 n’a rien renvoyé avec des plafonds de 8K et 16K sur ma t2 |
| Plus de 128K tokens de sortie en un appel | V4 Flash | Sortie maximale de 384K contre 128K pour GLM-5.2 |
Considérez cela comme une règle de routage par coût à valider, et non comme une vérité établie : elle repose sur une seule exécution de quatre tâches. Orientez par défaut vers Flash, puis basculez vers GLM-5.2 pour la part des tâches où une réponse erronée coûte plus de 19x la dépense en tokens. Si vous utilisez GLM-5.2, laissez-lui de la marge : une limite généreuse pour Flash peut aboutir à une non-réponse facturée avec GLM-5.2.
Cette comparaison ne peut toutefois pas trancher un point : aucune réévaluation tierce de Flash n’est apparue depuis l’arrivée de 0731 aujourd’hui. L’écart de 51 contre 40 décrit donc la version d’avril. La distance actuelle en capacité n’est pas mesurée ; pour l’estimer sur votre charge de travail, il faut lancer vos propres évaluations contre les deux alias.
FAQ
DeepSeek V4 Flash 0731 est-il un nouveau modèle ou une mise à jour ?
C’est une mise à jour du modèle existant, pas un nouveau modèle. La documentation DeepSeek indique la version DeepSeek-V4-Flash-0731 et précise que la méthode d’appel ne change pas : deepseek-v4-flash continue donc de résoudre vers la version la plus récente, sans modification de votre code.
DeepSeek V4 Flash a-t-il battu GLM-5.2 ?
Pas en capacité : Artificial Analysis attribue 51 à GLM-5.2 (max), contre 40 à DeepSeek V4 Flash (Reasoning, Max Effort). Flash l’emporte sur le coût par tâche résolue, avec trois égalités sur quatre tâches évaluées pour un coût total 19,4x inférieur.
GLM-5.3 est-il déjà disponible ?
Non au 2026-07-31 : GLM-5.2 est l’entrée la plus récente dans le tableau tarifaire de Z.ai comme dans la liste des modèles de son Coding Plan ; aucune des deux pages ne comporte de ligne 5.3.
Quel est le moins cher pour une tâche avec 1M tokens de contexte ?
DeepSeek V4 Flash : 10x moins cher sur les entrées sans cache et 93x moins cher sur les entrées avec cache. Ma tâche de récupération d’environ 45K tokens a coûté $0.006380 avec Flash, contre $0.063224 avec GLM-5.2.
Peut-on utiliser les deux modèles dans Claude Code ?
Oui. Les deux éditeurs documentent un endpoint au format Anthropic. DeepSeek liste https://api.deepseek.com/anthropic à côté de son URL de base au format OpenAI ; le guide Claude Code de Z.ai demande de définir ANTHROPIC_BASE_URL sur https://api.z.ai/api/anthropic et d’associer les emplacements Sonnet et Opus à glm-5.2[1m].
À lire aussi
Sources
- DeepSeek Models & Pricing — note de version 0731, tarifs, politique heures pleines/heures creuses, vérifié le 2026-07-31
- Tarifs Z.ai — tarifs GLM-5.2, vérifiés le 2026-07-31
- Z.ai Coding Plan — niveaux d’abonnement et couverture de GLM-5.2, vérifié le 2026-07-31
- Z.ai : configuration de Claude Code — URL de base compatible Anthropic et correspondance des modèles
- Index des actualités DeepSeek — consulté le 2026-07-31, aucune entrée pour juillet 2026
- Artificial Analysis : GLM-5.2 vs DeepSeek V4 Flash — Intelligence Index, paramètres
- benchlm : DeepSeek V4 Flash Base vs GLM-5.2 — couverture des benchmarks communs, scores de connaissances
- r/opencodeCLI : DeepSeek V4 vs GLM 5.2 pour le code — retour de praticien