DeepSeek V4.1 Flash vs GLM-5.2 : deux modèles MIT, une réponse ennuyeuse

DeepSeek V4.1 Flash et GLM-5.2 sont le même genre d'objet, et c'est la partie que la plupart des comparaisons passent sous silence. Les deux sont des modèles à mélange d'experts, tous deux sont distribués sous licence MIT avec des poids téléchargeables, tous deux acceptent un million de tokens de contexte, et tous deux sont accessibles via une API hébergée par un fournisseur qui ne les a pas entraînés. GLM-5.2 est arrivé en premier et était, lors de sa sortie, le modèle à poids ouverts le mieux noté de l'indice Artificial Analysis, avec un score de 51. DeepSeek V4.1 Flash est arrivé le 10 septembre 2026 comme le modèle plus petit, plus récent et moins cher de la nouvelle famille d'architectures de DeepSeek. La comparaison qui compte entre eux n'est pas de savoir lequel est le plus intelligent. C'est de savoir lequel vous pouvez exécuter, et à quel coût, pour le travail que vous avez réellement.

Ce qu’ils partagent, ce qui en constitue la majeure partie

Commencez par les points communs, car ils éliminent la plupart des critères de décision habituels. Si vous hésitez entre un modèle ouvert et un modèle fermé, vous évaluez l’effet de verrouillage, vous évaluez la possibilité de l’affiner, vous évaluez si le fournisseur peut modifier les conditions à votre détriment. Rien de tout cela ne s’applique ici. DeepSeek V4.1 Flash et GLM-5.2 sont tous deux sous licence MIT, avec des poids que vous pouvez télécharger et servir vous-même. Tous deux acceptent 1M de tokens en entrée. Tous deux sont des architectures MoE, ce qui signifie que tous deux sont peu coûteux à exécuter par rapport à leur nombre total de paramètres, car seule une fraction des poids s’active par token.

Donc la comparaison n’est pas ouvert contre fermé, et ce n’est pas contexte long contre contexte court. C’est un ensemble de quatre ou cinq chiffres, et ces chiffres pointent dans une direction pour le coût et dans l’autre pour la maturité.

Là où ils divergent réellement

• Prix pour 1 M de tokens — DeepSeek V4.1 Flash 0,15 $ en entrée / 0,60 $ en sortie aux heures creuses, contre GLM-5.2 1,40 $ en entrée / 4,40 $ en sortie. Cela représente un peu plus de 9 fois le prix d’entrée et un peu plus de 7 fois le prix de sortie.

• Entrée mise en cache — V4.1 Flash 0,003 $ par million en heures creuses, contre GLM-5.2 0,26 $ par million. Près de 90 fois, sur le poste de facturation qui domine la facture d'une boucle d'agent.

• Paramètres — V4.1 Flash : 552 B au total, avec 8 B actifs en entrée et 16 B en sortie, contre GLM-5.2, environ 745 B au total avec environ 40 B actifs. GLM-5.2 active environ deux fois et demie plus de paramètres par token.

• Sortie maximale — V4.1 Flash 384K tokens contre GLM-5.2 128K tokens. Trois fois le plafond.

• Fenêtre de contexte — 1 M de tokens chacun. Niveau.

• Score d'indice indépendant — GLM-5.2 obtient 51 sur l'Artificial Analysis Index, le score le plus élevé de tous les modèles à poids ouverts au moment de sa sortie. DeepSeek V4.1 Flash ne dispose pas encore d'un chiffre d'indice publié.

• Latence observée jusqu'au premier token — V4.1 Flash 2,63 s au p50 et 9,05 s au p95 contre GLM-5.2 2,36 s au p50 et 10,00 s au p95, selon la télémétrie sur 7 jours d'OrcaRouter. Les médianes sont au même niveau. Les queues, non.

L’orientation du prix et celle de la maturité sont opposées. GLM-5.2 est le modèle doté du score indépendant et de l’historique le plus long. DeepSeek V4.1 Flash est le modèle dont les tokens sont moins chers : un neuvième du prix des entrées et un plafond de sortie trois fois plus élevé. Il n’existe aucune lecture de cette liste où un seul modèle domine tout simplement.

La queue est la ligne sous-estimée.

La plupart des comparaisons de modèles à poids ouverts commencent par le score d’indice. La télémétrie de latence mérite plutôt l’attention, mais pas pour la raison que vous imaginez : les médianes sont au même niveau. Le temps jusqu’au premier token au p50 de GLM-5.2 est de 2,36 s contre 2,63 s pour V4.1 Flash, ce qui n’est pas un écart, c’est du bruit sur un réseau partagé. Quiconque cite un avantage sur le premier token pour le modèle moins cher lit le mauvais percentile.

Le p95 est le point où les deux divergent, et la direction est inverse de ce que l’écart de prix laisserait supposer. Le temps d’attente dans le pire des cas de GLM-5.2 est de 10,00 s ; celui de V4.1 Flash est de 9,05 s. Cela compte plus qu’une médiane, car les requêtes qu’un utilisateur remarque sont les plus lentes. Un outil généralement instantané qui se bloque parfois pendant dix secondes paraît peu fiable d’une manière qu’un outil uniformément à trois secondes ne paraît pas, et dans une boucle d’agent qui distribue dix appels par tour, le p95 est le nombre qui décide si le tour se termine dans les limites de la patience d’une personne. La queue de GLM-5.2 n’est pas un défaut ; c’est un modèle plus grand qui active environ 40 milliards de paramètres par token, et il coûte ce qu’il coûte. Mais c’est la raison pour laquelle le modèle convient au travail asynchrone — une file d’attente, une tâche par lots, un agent en arrière-plan que personne ne surveille — mieux qu’il ne convient à une interface requête-réponse.

Aucun des deux modèles ne publie de chiffre de débit sur les pages que nous pouvons voir, ce qu'il vaut la peine de dire clairement plutôt que de combler. Le temps jusqu'au premier token est la seule dimension de latence sur laquelle ces deux modèles peuvent être comparés sur des données communes, et sur cette dimension, la lecture honnête est qu'ils sont à égalité à la médiane et proches dans la queue.

Ce qu’un score d’indice règle et ne règle pas

Le 51 de GLM-5.2 sur l’Artificial Analysis Index est un chiffre réel, produit indépendamment, et c’est l’argument individuel le plus solide en faveur du modèle. C’est aussi un composite : un seul nombre agrégeant plusieurs ensembles d’évaluation, ce qui en fait un bon résumé de la capacité générale et un mauvais prédicteur de la performance sur une tâche spécifique donnée. Un modèle qui obtient 51 et un modèle sans score publié ne sont pas équivalents à un modèle qui obtient 51 et à un modèle qui obtient 40.

La position honnête sur DeepSeek V4.1 Flash est que son historique indépendant est mince, et la raison en est sa jeunesse. Il est en disponibilité générale depuis douze jours. La seule évaluation tierce récente dans laquelle il apparaît — le tableau de codage agentique Agents on Rails publié le 21 septembre 2026 — le place à 17 % en effort maximal, en milieu de tableau, au-dessus de GLM-5.3 Flash à 15 % et en dessous de Gemini 3.8 Flash à 23 %. Il s’agit d’un seul tableau qui mesure une chose étroite, et il ne remplace pas un score de l’Index. Quiconque affirme aujourd’hui que V4.1 Flash dépasse GLM-5.2 en capacités extrapole à partir de l’architecture et du prix, et ne rapporte pas une mesure.

L’argument en faveur de chacun, exposé simplement

DeepSeek V4.1 Flash est le modèle à privilégier lorsque la charge de travail est à gros volume, sensible à la latence ou intensive en sortie. Un neuvième du prix d’entrée et environ un quatre-vingt-dixième du prix de lecture du cache constituent un avantage structurel dans une boucle d’agent qui relit le contexte à chaque tour, et un plafond de sortie de 384K relève d’une autre catégorie d’artefact que 128K. Si votre tâche est la classification, l’extraction, la génération structurée longue, ou l’exécuteur à gros volume au sein d’un pipeline d’agents, la différence de coût n’est pas marginale — c’est la différence entre un pipeline viable et un pipeline non viable.

GLM-5.2 est le modèle auquel recourir lorsque vous avez besoin d’un chiffre de capacité publié et vérifié de manière indépendante pour justifier une décision, ou lorsque le travail est asynchrone et qu’une attente de dix secondes dans le pire des cas est invisible. C’est le choix mature : le score existe, le comportement est documenté, le modèle est en production depuis assez longtemps pour que d’autres personnes aient trouvé ses limites. Il y a une réelle valeur à cela, et elle n’est pas capturée par une colonne de prix.

Là où aucun des deux n’est manifestement le bon choix — un assistant généraliste traitant un trafic mixte —, la décision utile n’est pas de choisir. Il faut envoyer l’essentiel du trafic vers le modèle bon marché et réserver le modèle coûteux aux requêtes qui en ont besoin.

Exécuter les deux comme un seul système

Comme les deux modèles sont à poids ouverts et tous deux hébergés, le schéma de répartition et de routage est ici exceptionnellement peu coûteux à mettre en place, et c’est là que la couche de routage d’OrcaRouter justifie sa place plutôt que de ressembler à un argumentaire greffé après coup. Les deux modèles se trouvent derrière une seule clé, de sorte que la décision de routage relève de la configuration plutôt que d’une seconde intégration : une règle qui envoie les requêtes courtes et à fort volume vers DeepSeek V4.1 Flash et les tâches asynchrones longues vers GLM-5.2 tient en quelques lignes plutôt qu’en une branche dans le code de votre application.

Deux propriétés de la plateforme comptent tout particulièrement pour ce jumelage. OrcaRouter répercute les tarifs catalogue des fournisseurs avec 0 % de marge, donc les chiffres ci-dessus sont les tarifs pratiqués par les fournisseurs eux-mêmes et le calendrier de pointe de DeepSeek s'applique exactement tel que DeepSeek le définit — la période de pointe s'étend de 01:00 à 04:00 et de 06:00 à 10:00 UTC en semaine, les week-ends étant entièrement hors pointe, une décision de planification qu'il vaut la peine de prendre explicitement sur un modèle aussi bon marché. Et le DSL de routage peut composer plusieurs modèles en un seul appel, ce qui est la manière naturelle d'utiliser deux modèles à poids ouverts dont les points forts ne se recoupent pas : le moins cher produit, le plus performant relit, et l'appelant ne voit qu'une seule réponse. Le basculement automatique en cas de défaillance se trouve derrière les deux chemins, ce qui compte lorsqu'un des deux modèles a douze jours et que son comportement sur vos données n'est pas encore connu.

La raison pour laquelle c’est la bonne configuration plutôt qu’un compromis, c’est que les deux modèles diffèrent selon des axes qui ne sont pas en concurrence. L’un est rapide et peu coûteux ; l’autre est évalué et lent. Un pipeline qui utilise les deux ne cherche pas à se couvrir : il fait correspondre les instruments aux tâches.

Que regarder

• Un chiffre publié de l'Artificial Analysis Index pour DeepSeek V4.1 Flash. Tant qu'il n'existe pas, la comparaison des capacités entre ces deux modèles relève de l'argumentation, et non d'une mesure — et c'est le seul élément de preuve qui permettrait de trancher.

• Savoir si le profil de latence de GLM-5.2 s’améliore. Son p95 de 10,00 s est le chiffre le plus susceptible d’évoluer à mesure que les fournisseurs d’hébergement optimisent, et c’est actuellement la plus grande différence mesurée entre les deux modèles — une attente de queue, pas un prix.

• Si le calendrier des heures de pointe de DeepSeek change. Pour un modèle à 0,15 $ par million de tokens d'entrée, le multiplicateur des heures de pointe est la plus grande variable isolée du modèle de coût.

Jusqu’à ce que le premier de ceux-ci soit disponible, le résumé exact est le suivant : DeepSeek V4.1 Flash est environ neuf fois moins cher en entrée et presque quatre-vingt-dix fois moins cher en entrée mise en cache que GLM-5.2, et son plafond de sortie est trois fois plus élevé ; GLM-5.2 est le modèle qui dispose d’un score indépendant et d’un historique plus long, et sa médiane de premier jeton est au niveau de celle du modèle moins cher, même si son pire cas ne l’est pas. Les deux sont sous licence MIT. Les deux sont accessibles avec une seule clé. Choisissez en fonction de la charge de travail, pas du gagnant.