GLM-5 vs DeepSeek V3 vs GPT-5 : Vitesse et Coût pour les Développeurs

Salut, je m’appelle Dora. Ce qui m’a poussée à écrire était plus modeste : une tâche de résumé qui aurait dû prendre cinq minutes s’est étalée sur quinze parce que la première réponse s’est figée au démarrage. Pas entièrement la faute du modèle — streaming de tokens, charge serveur, tout ça — mais ça m’a rappelé que la “précision” n’est pas la seule chose qui peut faire dérailler une journée.

Alors je me suis attardée sur la question qui revenait me hanter : dans le monde réel, comment GLM-5, DeepSeek et GPT-5 se ressentent-ils vraiment à l’usage ? Pas dans des graphiques, mais en temps de réponse, en coût qui ne vous surprend pas, et en fiabilité quand une tâche comporte trois ou quatre variables. C’est ma tentative de mettre ça par écrit, calmement, avec la mise en garde que votre stack, votre région et votre tolérance aux cas limites changeront le tableau.

Je resterai concret : GLM-5 vs DeepSeek vs GPT-5, au-delà du battage médiatique et des captures d’écran de benchmarks habituelles.

Ce qu’il faut comparer au-delà des scores de benchmark

Les benchmarks sont un garde-fou, pas une destination. Les tests auxquels je prête attention ne sont pas spectaculaires :

• La latence là où ça compte : le temps jusqu’au premier token (TTFT) et le débit constant. Un modèle qui “réfléchit plus longtemps” n’est pas un problème : un modèle qui reste inactif avant même de démarrer, si.
• Un coût qui correspond à la forme du travail : le prix par million de tokens est utile, mais le gaspillage de fenêtre contextuelle, les relances et les appels d’outils peuvent doubler la dépense réelle.
• Les modes de défaillance : comment les modèles se comportent quand les prompts sont légèrement incorrects, que les outils expirent, ou que les entrées sont plus longues que d’habitude.
• Les leviers de contrôle : une température qui déplace vraiment la variation, des prompts système qui tiennent, un function-calling qui ne vacille pas sur les bords du schéma.
• La dégradation sous charge : la troisième requête en une minute, ou le centième job dans un batch.

Avec GLM-5, DeepSeek et GPT-5, je cherchais une compétence discrète : des modèles qui ne me surprennent pas dans le mauvais sens. J’ai aussi noté où chacun montre ses limites, parce qu’il est plus facile de concevoir autour de failles connues qu’autour de promesses marketing.

Vitesse d’inférence (TTFT + débit)

Je m’intéresse à deux moments : quand le premier token apparaît, et à quelle vitesse le reste suit.

• TTFT : Cela me dit si un modèle commence à s’engager ou me laisse à fixer l’écran. Dans les outils interactifs (rédaction, chats de support), un TTFT rapide ressemble à de la bienveillance.
• Débit : Une fois lancé, peut-il maintenir un rythme régulier sur de longues sorties sans accrocs ?

Ce que j’ai observé en pratique (février 2026, endpoints mixtes US/UE) :

• GLM-5 : TTFT régulièrement rapide sur les prompts courts. Sur les contextes longs (au-delà de ~30–40k tokens), il démarre un peu plus lentement mais diffuse de façon régulière. Bonne impression de “pas de drame” pour la rédaction et les modifications de code. Si vous voulez des chiffres bruts et des données de latence côte à côte, j’ai trouvé cette analyse comparative des vitesses d’inférence de GLM-5 utile pour la mise en contexte.
• DeepSeek (notamment les variantes R1/V3) : TTFT étonnamment réactif, même sous une charge batch légère. Micro-pauses occasionnelles en milieu de stream sur les très longues générations, mais les reprises sont fluides.
• GPT-5 : Démarre plus lentement que prévu sur certains endpoints, puis compense avec un streaming très stable. Quand le function-calling est en jeu, le surcoût de transition est faible, ce qui aide les flux multi-étapes.

Mise en garde que je répète sans cesse : la région et la passerelle comptent autant que le modèle brut. Si vous routez via un agrégateur, activez le streaming et réduisez max_tokens sur les exécutions exploratoires. Ça coupe le vide sans changer la qualité.

---

Coût par million de tokens

Les tarifs affichés sont un point de départ, pas la facture finale. Trois leviers ont modifié mon coût réel plus que prévu :

• Gaspillage de contexte : Envoyer le même préambule système et les mêmes schémas d’outils à chaque appel s’accumule. La mise en cache ou la réduction des schémas s’est rapidement amortie.
• Politique de relance : Une relance agressive sur les limites de débit peut silencieusement doubler les dépenses pendant les périodes chargées.
• Discipline sur la longueur des sorties : Définir max_tokens à un plafond raisonnable (et laisser le modèle s’arrêter sur les function calls) a été plus efficace que n’importe quel code de réduction.

Ce mois-ci :

• DeepSeek pratique une tarification agressive, surtout pour les variantes de raisonnement. Adapté aux workflows batch, à condition de surveiller la variance occasionnelle de style.
• GLM-5 se situe dans un juste milieu pragmatique. Pas le moins cher, mais prévisible, et la prévisibilité a de la valeur quand la finance demande des prévisions.
• La tarification de GPT-5 est encore en mouvement publiquement. En pratique, j’ai modélisé les budgets avec les fourchettes GPT-4.1/4o comme borne inférieure et ajouté une marge pour le niveau de raisonnement de GPT-5. Si vous avez besoin d’un plafond ferme aujourd’hui, c’est celui-là qu’il faut tester sous pression.

Si vous comparez des choses comparables, mesurez le “coût effectif par sortie utile”, pas les tokens. Un modèle 1,2× plus cher qui réduit les révisions de moitié est gagnant à mes yeux.

---

Qualité du raisonnement et du code

Je n’ai pas organisé un classement. J’ai fait le travail que je fais réellement : rédaction structurée, petits utilitaires de code et flux d’agents multi-outils. Deux angles importaient surtout.

Précision sur tâche unique

Sur des tâches ciblées (par ex., “convertir ce JSON en interface typée”, “résumer ces notes de réunion avec les actions à prendre”), GPT-5 m’a semblé le plus abouti. Il nécessitait moins de corrections pour suivre des formats étroits, et le function-calling restait dans le schéma de façon plus fiable.

DeepSeek s’en est bien sorti sur les étapes de raisonnement qu’il pouvait détailler. J’ai remarqué une légère tendance à trop élaborer, ce qui convient pour les brouillons, mais est moins idéal pour les sorties strictes, sauf si je limitais max_tokens et spécifiais la concision. GLM-5 s’est positionné dans un calme milieu : moins d’ornements, conformité régulière et bonnes modifications de code quand le diff était petit. Sur les démarrages à froid avec des prompts ambigus, il jouait parfois la sécurité plus que je ne le voulais, mais un prompt système plus précis y remédiait.

Fiabilité en agent multi-étapes

Quand les outils entrent en jeu — recherche, scraping, lectures de base de données — la question passe de “La réponse est-elle bonne ?” à “La boucle survit-elle ?”

• GPT-5 : Efficace pour planifier des chaînes courtes et récupérer quand un outil expire. Il demandait à nouveau les champs manquants plutôt que de les deviner. Petit détail, grand gain de sérénité.
• DeepSeek : Chaînes compactes et efficaces. À l’occasion, il prenait une mauvaise direction avec confiance quand deux outils se chevauchaient en capacité. L’ajout de règles explicites de sélection d’outils dans le prompt système a aidé.
• GLM-5 : Très stable quand le schéma était bien défini. Si un outil retournait des formes inattendues, il préférait la prudence et demandait des éclaircissements. Je préfère ça à l’hallucination silencieuse.

Ça ne m’a pas fait gagner du temps au début — en fait, câbler les garde-fous m’a pris un après-midi supplémentaire — mais après quelques exécutions, j’ai remarqué que ça réduisait l’effort mental. Moins de défaillances mystérieuses. Moins de moments “pourquoi a-t-il fait ça ?”.

---

Meilleur modèle par type de charge de travail

Ce n’est pas une cérémonie de couronnement. C’est un exercice d’association. Voici où chacun s’est le mieux adapté dans ma semaine.

Applications temps réel → ?

Si des gens attendent de l’autre côté de l’écran, je privilégie un TTFT rapide et un style prévisible.

• Chat léger, rédaction, sidebars de support : GLM-5 ou DeepSeek. Les deux sont agiles. DeepSeek tend légèrement plus vite vers le premier token : GLM-5 a tendance à garder un ton cohérent entre les sessions.
• Assistants lourds en outils : GPT-5. La planification et la stabilité du schéma réduisent les blocages sur les cas limites. Si le budget est serré, prototypez avec DeepSeek et passez à GPT-5 pour les endpoints qui comptent le plus.

Traitement par batch → ?

Pour les gros jobs offline (des centaines à des milliers d’éléments) :

• DeepSeek gagne en efficacité de coût si vous pouvez tolérer une légère dérive stylistique. Ajoutez des schémas de sortie stricts et des vérifications par diff.
• GLM-5 est un choix sûr et stable quand vous vous souciez de moins de valeurs aberrantes et que vous acceptez de payer un peu plus pour l’uniformité.
• GPT-5 est excessif sauf si la tâche nécessite vraiment un raisonnement plus profond ou une récupération multi-sauts par élément. Quand c’est le cas, le taux de relance chute suffisamment pour le justifier.

Pipelines multimodaux → ?

Pour les flux image + texte ou audio + texte, la colle compte plus que la brochure.

• GPT-5 : Les transitions les plus nettes entre modalités et outils dans mes tests. Si votre pipeline navigue entre extraction, raisonnement et génération, cette fluidité est payante.
• DeepSeek : Rapide et compétent. Pour OCR + résumé ou légende + tags, il maintenait une faible latence.
• GLM-5 : Fiable sur les tâches structurées d’image vers texte. Si la cohérence prime sur le style (pensez à l’analyse de factures ou au nettoyage de données produit), je le choisissais en premier.

Note de conception : diffusez les résultats intermédiaires dans vos logs. C’est le moyen le plus simple de détecter les incompatibilités de modalité avant la mise en production.

---

Comment la tarification WaveSpeed se compare pour les trois

J’ai essayé WaveSpeed comme couche de rationalisation des coûts — pas une solution miracle, juste une façon plus sereine de raisonner sur les dépenses.

Ce qui ressortait n’était pas une remise magique. C’était les mécaniques :

• Routage persistant : Épinglez GPT-5 pour les endpoints qui ont besoin de sa planification, envoyez les résumés simples à DeepSeek, gardez GLM-5 pour les éditions structurées. Une seule facture, moins de surprises.
• Mise en cache du contexte : Les prompts système et les schémas d’outils n’étaient pas renvoyés à chaque appel. Dans mes tests, cela a réduit les tokens d’entrée d’un tiers en moyenne. Ce n’est pas spectaculaire, mais c’est le genre d’économie qui s’additionne.
• Garde-fous en bordure : Si un modèle dérivait du schéma, WaveSpeed l’interceptait tôt et relançait avec le même fournisseur. Pas de roulette de fournisseur au milieu d’un job.

Côté prix, la comparaison est simple :

• Si vous jongiez déjà avec deux fournisseurs ou plus, le routage et la mise en cache de WaveSpeed peuvent réduire votre “coût effectif par sortie utile”, même si les tarifs affichés ne bougent pas.
• Si vous n’utilisez qu’un seul modèle et que vos prompts changent rarement, vous n’en verrez peut-être pas beaucoup les bénéfices. Dans ce cas, la tarification directe par API plus votre propre mise en cache suffit.

Je ne pense pas à WaveSpeed comme à un moyen d’obtenir des tokens moins chers. Je le vois comme un moyen d’en gaspiller moins.

Si vous faites face à des contraintes similaires, ça mérite un coup d’œil. Et si vous êtes satisfait d’un seul fournisseur, c’est aussi très bien — parfois le stack le plus discret est le meilleur.