Le test DeepSeek H200 remet en cause l’affirmation « 80x moins cher »

DeepSeek a été soumis à un test pratique des coûts après que The Call Center Doctors a loué quatre GPU Nvidia H200 afin d’examiner l’affirmation selon laquelle le modèle serait « 80x moins cher ».

Le cabinet de conseil a tenté de faire fonctionner DeepSeek V4.1 Flash avec ses agents de programmation au lieu d’utiliser Claude Opus 5.5 via Claude Code. Son test initial a constaté que des poids de modèle peu coûteux ne suffisaient pas à créer un système opérationnel bon marché.

Le test DeepSeek H200 a mis en évidence un écart entre la tarification des tokens et le coût nécessaire pour achever de véritables tâches logicielles. Le serveur loué gérait rapidement des charges de travail synthétiques, mais son économie s’est dégradée lorsque l’équipe a rejoué son trafic réel de programmation.

Au tarif de location à la demande habituel, le serveur coûtait environ deux fois plus cher que l’envoi de la même charge de travail vers l’API de DeepSeek. Le cabinet a également conclu que ses abonnements Claude Code existants restaient compétitifs une fois les modifications de code achevées mesurées plutôt que les prix des tokens.

Ces conclusions proviennent de la charge de travail, de la configuration et des mesures internes d’une seule entreprise. Elles ne constituent pas un benchmark universel de l’un ou l’autre modèle. DeepSeek n’a jamais reçu l’autorisation d’écrire du code de production pendant le test, ce qui limite toute comparaison directe du travail accompli.

L’expérience reste néanmoins importante, car elle a utilisé le trafic d’agents de programmation déployés plutôt qu’un benchmark isolé. Elle a mesuré le contexte répété, la concurrence, la latence, le travail opérationnel et la frontière de sécurité autour de l’exécution autonome de code.

Le renversement central est simple. Les faibles tarifs API de DeepSeek restaient attrayants, tandis que l’auto-hébergement du même modèle sur des GPU haut de gamme produisait une économie moins favorable pour cette charge de travail particulière.

Le résultat pousse les acheteurs à définir ce que signifie « moins cher » avant de changer de fournisseur. Un faible tarif par token de sortie peut être significatif, mais il ne décrit ni le débit, ni la fiabilité, ni l’effort d’ingénierie, ni la livraison réussie.

Le test DeepSeek H200 a remplacé une affirmation de prix par un test de charge de travail

Le cabinet a testé un système d’inférence complet, et non simplement le chiffre affiché à côté d’un million de tokens.

The Call Center Doctors construit et exploite des environnements de centres d’appels pour d’autres entreprises. Il utilise également des agents de programmation pour maintenir les logiciels qui soutiennent ce travail.

Le 27 septembre, l’entreprise a loué un serveur contenant quatre accélérateurs Nvidia H200. Elle a téléchargé DeepSeek V4.1 Flash et configuré le modèle comme backend pour des agents normalement connectés à Claude Code.

Le test visait deux affirmations courantes au sujet des modèles à poids ouverts. La première affirme que des tarifs de tokens plus bas se traduisent directement par des coûts d’exploitation inférieurs. La seconde affirme que les organisations peuvent éviter les marges des fournisseurs en louant des GPU et en servant elles-mêmes le modèle.

DeepSeek donne aux acheteurs des raisons d’examiner ces affirmations. Son lancement de modèle décrit V4.1 Flash comme un modèle mixture-of-experts conçu pour une inférence plus rapide et un débit plus élevé.

Un modèle mixture-of-experts n’active qu’une partie de son réseau pour chaque token. Cette conception peut réduire les calculs par rapport à l’exécution de tous les paramètres pour chaque requête.

DeepSeek indique que son architecture active moins de paramètres tout en traitant les entrées et les sorties. L’entreprise affirme également que le modèle nécessite moins de mémoire à haute bande passante pour son cache clé-valeur que la génération précédente.

Un cache clé-valeur stocke des données d’attention intermédiaires provenant de tokens précédents. La réutilisation de ces données rend le contexte répété moins coûteux que le traitement de l’intégralité de la séquence comme une nouvelle entrée.

Le cabinet a donc choisi un matériel adapté à l’inférence gourmande en mémoire. Chaque H200 comprend 141GB de mémoire à haute bande passante, selon les spécifications H200 de Nvidia.

Sur quatre GPU, cette capacité suffisait pour charger et servir le modèle après plusieurs changements de configuration. Toutefois, parvenir à un service stable a nécessité cinq démarrages.

Chaque redémarrage exigeait une nouvelle période de chargement du modèle. Une optimisation a consommé une quantité de mémoire inattendue, une autre exécution s’est figée, et une configuration ultérieure a échoué avec une concurrence plus élevée.

La cinquième tentative s’est stabilisée avec un plafond de concurrence inférieur et la majeure partie de la mémoire disponible engagée. Cette séquence opérationnelle est devenue partie intégrante du résultat économique.

Une API hébergée masque les téléchargements de modèles, l’allocation de mémoire, les logiciels de service, la planification de capacité et les démarrages échoués. Une machine louée expose chacune de ces tâches au client.

Une fois stabilisé, le serveur a bien fonctionné lors de tests isolés d’une minute. Il traitait particulièrement vite les entrées mises en cache et générait des milliers de tokens par seconde à l’échelle de la machine.

Ce résultat soutenait initialement l’argument de l’auto-hébergement. Quatre H200 disposaient d’un débit brut substantiel, et la conception orientée cache de DeepSeek se comportait comme prévu.

Le problème est apparu lorsque l’équipe a cessé de tester une catégorie de tokens à la fois. Ses agents de programmation n’envoyaient pas une séquence équilibrée de nouvelles entrées, d’entrées mises en cache et de sorties.

Ils fournissaient à répétition de longues conversations, des résultats d’outils, du contexte de fichiers et des raisonnements antérieurs. La plus grande partie de chaque requête se composait de texte que le modèle avait déjà vu.

Cette charge de travail a éloigné le test de la vitesse théorique de sortie. Elle a forcé la machine à consacrer presque tout son temps au traitement du contexte nécessaire avant de générer la réponse suivante.

L’événement n’était donc pas une course conventionnelle entre modèles. Il testait si des taux d’inférence attrayants résistaient au trafic réel d’un système d’agents.

Pourquoi le contexte des agents a saturé les quatre H200

Les agents de programmation consacrent souvent bien plus de calcul à relire leur historique qu’à écrire le prochain token utile.

Les journaux de septembre du cabinet contenaient 388,5 milliards de tokens lus et 393 millions de tokens écrits. Parmi les entrées, 374,2 milliards de tokens correspondaient à des relectures mises en cache.

Cela signifie que plus de 96 pour cent des entrées enregistrées répétaient un contexte antérieur. Pour chaque token de sortie, les agents fournissaient environ 41,6 nouveaux tokens d’entrée et 1 042 tokens mis en cache.

Une requête moyenne relisait environ 196 000 tokens. Ce schéma importe, car les entrées mises en cache sont peu coûteuses par token, mais jamais gratuites sur le plan des calculs.

Le serveur loué traitait chaque token mis en cache plus rapidement que chaque nouveau token. Toutefois, les agents fournissaient tellement de tokens mis en cache que ces faibles coûts se sont accumulés pour devenir la charge dominante.

L’entreprise a mesuré environ 1,9 microseconde de temps serveur pour un token mis en cache. Un nouveau token d’entrée nécessitait environ 60 microsecondes, tandis qu’un token de sortie en nécessitait environ 189.

L’application de ces mesures au mix de trafic de production a produit un plafond combiné proche de 213 tokens de sortie par seconde. Il s’agissait du résultat agrégé de tous les agents partageant les quatre GPU.

La formule correspondait au test en direct à moins de trois pour cent près, selon le cabinet. Cette concordance a renforcé le modèle de charge de travail, bien qu’aucune partie indépendante ne l’ait répliqué.

L’entreprise a estimé que la machine pouvait traiter environ 20 milliards de tokens au total par jour avec ce mix. Sa journée la plus chargée de septembre a atteint 51 milliards de tokens.

La capacité est donc devenue une seconde contrainte. Un serveur ne pouvait pas absorber le pic enregistré, même si son économie de location habituelle avait été favorable.

Le contraste entre les tests isolés et mixtes explique pourquoi le débit affiché en titre peut être trompeur. La machine générait plus de 5 000 tokens par seconde lorsque seule la sortie était mesurée.

Les vrais agents ne peuvent pas fonctionner uniquement avec de la sortie. Ils doivent fournir en continu des instructions, du code, des fichiers, des journaux, des réponses d’outils et des messages antérieurs.

Les agents exécutés sur de longues périodes amplifient ce déséquilibre parce que les conversations s’allongent avec le temps. Chaque appel ultérieur peut contenir une grande partie du même historique, avec seulement une petite quantité de nouvelles informations.

Les remises sur le cache réduisent le coût de ces tokens répétés. Elles n’éliminent ni la bande passante mémoire, ni les délais de planification, ni le coût d’opportunité d’occuper un serveur.

Cette distinction complique également les comparaisons entre modèles. Un modèle plus compétent peut achever une tâche avec moins de tentatives, des prompts plus courts ou moins de révision.

Un modèle moins cher peut tout de même l’emporter s’il utilise un contexte similaire et obtient des résultats comparables. Il peut perdre s’il exige davantage de nouvelles tentatives, des explications plus longues ou la vérification par un autre modèle.

Le test DeepSeek H200 n’a pas entièrement répondu à cette question de qualité, car DeepSeek a principalement servi de relecteur en lecture seule. Il a toutefois montré pourquoi les seuls tarifs par token de sortie ne peuvent y répondre.

La métrique pertinente dépend du travail. Un système de synthèse par lots peut privilégier le débit total, tandis qu’un agent interactif a également besoin d’une faible latence et d’un usage fiable des outils.

Une opération de programmation se soucie des modifications achevées, du temps de révision, des régressions, de la sécurité et de l’attente des développeurs. L’efficacité des tokens n’est qu’un élément de ce résultat.

Les journaux du cabinet ont offert un avertissement utile aux autres acheteurs. Avant de sélectionner du matériel, les équipes doivent profiler le ratio entre les nouvelles entrées, le contexte mis en cache et la sortie générée.

Sans ce ratio, un benchmark peut optimiser la plus petite partie de la charge de travail. Un test de génération rapide peut révéler peu de chose sur un agent qui passe l’essentiel de son temps à lire.

L’auto-hébergement de DeepSeek a perdu face à l’API DeepSeek

Le résultat le plus clair n’était pas DeepSeek contre Claude, mais l’infrastructure DeepSeek louée contre le service géré de DeepSeek.

Le tarif de serveur à la demande habituel entraînait un coût quotidien représentant environ deux à 2,4 fois la valeur du même trafic via l’API de DeepSeek. Ce calcul supposait une utilisation continue.

La location spot utilisée pendant l’expérience était bien moins chère. À ce tarif temporaire, le serveur n’approchait la parité avec le service géré de DeepSeek qu’en fonctionnant à pleine charge.

La capacité spot comporte un compromis en matière de disponibilité. Les fournisseurs peuvent la récupérer lorsque la demande évolue, ce qui rend difficile de la considérer comme une infrastructure de production fiable.

C’est ce qui s’est produit presque immédiatement après l’expérience. Le fournisseur a récupéré la machine quelques minutes après le test final.

L’alternative à la demande évitait ce risque d’interruption, mais affaiblissait l’économie. Elle facturait également pendant le chargement du modèle, les redémarrages, l’attente de trafic ou les périodes en dessous de l’utilisation maximale.

L’API gérée de DeepSeek répartit ces périodes d’inactivité entre de nombreux clients. Le fournisseur peut regrouper les requêtes, mutualiser le matériel et exploiter sa propre pile de service à plus grande échelle.

Sa grille tarifaire API distingue également les entrées mises en cache, les nouvelles entrées et les sorties. Le trafic hors pointe bénéficie de tarifs inférieurs à ceux des heures de pointe en semaine.

Ce calendrier offre aux acheteurs une autre voie d’optimisation. Les charges de travail par lots flexibles peuvent être déplacées en dehors des périodes de pointe sans nécessiter une machine dédiée.

Le serveur loué ne disposait d’aucun ajustement correspondant à la demande. Son compteur horaire continuait de tourner, que les agents produisent ou non un travail utile.

La comparaison n’établit pas que l’auto-hébergement est toujours non rentable. Les organisations peuvent posséder du matériel amorti, négocier des tarifs de capacité plus bas ou maintenir une utilisation stable sur plusieurs charges de travail.

Les déploiements à grande échelle peuvent également optimiser les kernels, la quantification, le routage et la planification par lots au-delà de ce qu’une courte expérience a réalisé. DeepSeek invite lui-même les organisations prévoyant de très grands déploiements à discuter d’options supplémentaires.

La confidentialité peut justifier une exploitation locale même lorsque l’inférence hébergée est moins coûteuse. Des charges de travail réglementées peuvent exiger des contrôles de données qui l’emportent sur les coûts de calcul directs.

Une capacité prévisible peut également compter. Une entreprise confrontée à une demande soutenue peut préférer une infrastructure qu’elle contrôle, en particulier lorsqu’une API externe impose des limites ou des risques de disponibilité.

Cependant, ces avantages exigent une machine stable, des opérateurs expérimentés, de la supervision, du basculement et des contrôles de sécurité. Aucun ne découle automatiquement des poids ouverts.

Le test a également révélé un coût d’expertise. Les ingénieurs ont dû diagnostiquer la consommation mémoire, les échecs de démarrage, les limites de concurrence et le comportement du service avant d’exécuter la charge de travail utile.

Ce travail n’était pas inclus dans la simple comparaison des machines. Le prendre en compte rendrait cette courte expérience d’auto-hébergement moins favorable.

C’est la principale leçon pour les entreprises qui envisagent un déploiement auto-hébergé de DeepSeek. La comparaison pertinente oppose un service complet à un autre service complet.

Les poids du modèle ne constituent qu’un composant. La location du matériel, la capacité inutilisée, l’orchestration, l’observabilité, la réponse aux incidents, l’électricité, le stockage et le temps du personnel complètent le système.

L’API DeepSeek bénéficie de la même efficacité architecturale que le modèle téléchargeable. Elle bénéficie aussi d’une infrastructure que DeepSeek peut exploiter pour de nombreux clients.

L’auto-hébergement doit surmonter ces deux avantages. Éviter la marge d’une API ne suffit pas lorsque son fournisseur bénéficie d’une meilleure utilisation des ressources et d’une plus grande expertise du service.

Pour cette charge de travail, il n’y est pas parvenu. L’option à poids ouverts offrait du contrôle, mais le cloud de DeepSeek proposait l’expérience DeepSeek la moins coûteuse.

L’affirmation « 80x moins cher » comparait différents modèles d’achat

La comparaison mise en avant s’est affaiblie, car elle opposait des tarifs d’API publics à un accès par abonnement fortement utilisé.

L’affirmation « 80x moins cher » compare des tarifs par token selon certaines hypothèses. Elle ne décrit pas automatiquement le montant payé par chaque utilisateur de Claude Code.

Le cabinet de conseil accédait à Claude via des abonnements plutôt que par l’API facturée à l’usage d’Anthropic. Anthropic confirme que les formules éligibles donnent un accès par abonnement à Claude Code, sous réserve de limites d’utilisation partagées.

Un abonnement et une API répondent à des modes d’achat différents. L’abonnement regroupe l’accès dans des limites définies, tandis qu’une API facture selon la consommation mesurée.

Le cabinet a déclaré que son utilisation des abonnements équivalait à bénéficier d’une forte remise par rapport aux tarifs publics des API. Cette différence a absorbé l’essentiel de l’écart théorique de 80x.

À partir du trafic de septembre, l’entreprise a calculé que l’API de DeepSeek pourrait aller de légèrement moins chère à plus coûteuse que ses abonnements Claude. Le moment d’utilisation déterminait la position de la consommation entre les tarifs de pointe et les tarifs hors pointe.

Les résultats publiés estimaient également que le tarif public de l’API Claude aurait généré une facture bien plus élevée. Or, ce n’était pas le produit acheté par l’entreprise.

Cette distinction est facile à manquer lorsque les comparaisons réduisent chaque produit à un tarif nominal par token. Un même modèle peut être vendu via des abonnements, des contrats d’entreprise, des plateformes cloud ou des API directes.

Chaque canal présente des limites et des incitations économiques différentes. Un abonnement peut favoriser une utilisation individuelle régulière, tandis qu’une API offre une montée en charge programmable et une comptabilisation détaillée de l’usage.

Un contrat d’entreprise peut ajouter une capacité négociée, des engagements de service ou des contrôles. L’auto-hébergement remplace la marge de service du fournisseur par des responsabilités d’infrastructure et d’exploitation.

Aucun tarif unique ne couvre ces quatre modalités. Les acheteurs devraient comparer la voie qu’ils peuvent effectivement acheter et exploiter.

Le cabinet a également calculé le coût d’une modification de code fusionnée. Ses agents Claude ont réalisé 5 610 modifications fusionnées durant la période mesurée, dont cinq ont ensuite été annulées.

Il a estimé que DeepSeek nécessiterait des tokens supplémentaires, des nouvelles tentatives et des vérifications fondées sur Claude. Selon ces hypothèses, chaque modification acceptée coûterait davantage via DeepSeek.

Cette estimation mérite de la prudence. DeepSeek n’a pas exécuté la même tâche avec droits d’écriture, de sorte que l’étude n’a pas pu observer son taux réel de réussite ni son utilisation totale de tokens.

Les hypothèses pourraient être trop sévères si de meilleurs prompts, logiciels de service ou designs d’agents amélioraient les résultats de DeepSeek. Elles pourraient être trop optimistes si les revues révélaient davantage de défauts.

Néanmoins, le coût par modification acceptée est une cible plus utile que le coût par token de sortie. Il relie les dépenses d’inférence à des logiciels qui résistent à la revue.

La meilleure unité dépend du flux de travail. Les équipes de service client pourraient mesurer les dossiers résolus, tandis que les chercheurs pourraient mesurer les conclusions vérifiées.

Un faible tarif par token reste précieux lorsque les modèles exigent un travail similaire pour atteindre ces résultats. Il devient moins déterminant lorsque les capacités, la latence ou les contraintes de revue diffèrent.

Le chiffre « 80x » décrit donc une comparaison étroite, et non une économie universelle. The Call Center Doctors n’ont pas réfuté le tarif publié de DeepSeek.

L’étude a plutôt montré que les calculs fondés sur une grille tarifaire peuvent s’effondrer lorsque les produits, les charges de travail et la qualité des résultats diffèrent.

La sécurité a empêché DeepSeek d’écrire du code de production

La limite la plus forte de l’expérience était aussi son avertissement opérationnel le plus important : DeepSeek n’a jamais achevé la mission de codage prévue.

L’entreprise prévoyait d’utiliser DeepSeek pour des agents d’écriture de code. Ses réviseurs ont ensuite identifié de possibles voies permettant au code généré de s’échapper du bac à sable prévu.

Un bac à sable est un environnement d’exécution isolé qui limite ce à quoi du code non fiable peut accéder. Il devrait empêcher un agent d’atteindre des fichiers sensibles, des identifiants, des réseaux ou des privilèges administratifs.

Une faiblesse signalée concernait un fichier de paramètres dans un répertoire temporaire partagé. L’entreprise pensait qu’un contenu manipulé à cet endroit pourrait permettre au code généré de s’exécuter avec des permissions élevées.

Le cabinet a donc maintenu les agents de création hors ligne. DeepSeek n’a fonctionné qu’à travers 48 à 64 agents de révision en lecture seule.

Ces réviseurs ont examiné 2 377 dossiers de code et produit 32 rapports de bogues. Cette activité a démontré un débit utile, mais n’a pas testé l’implémentation autonome.

Le problème de sécurité n’a pas été présenté comme un défaut des poids du modèle DeepSeek. Il concernait l’environnement d’agents et les contrôles d’exécution qui entouraient le cabinet.

Cette distinction importe. Tout modèle capable de générer des commandes peut exposer des faiblesses dans une chaîne d’outils mal isolée.

Claude, DeepSeek ou un autre modèle peut produire des actions dangereuses lorsque les agents reçoivent un accès au système de fichiers et au shell. La frontière de sécurité doit considérer les sorties du modèle comme non fiables.

Le test a par conséquent mélangé deux questions distinctes. L’une concernait l’économie de l’inférence DeepSeek. L’autre portait sur la capacité du bac à sable d’agents de l’entreprise à prendre en charge une automatisation avec droits d’écriture.

Seule la première question a reçu des mesures directes de charge de travail. La seconde a interrompu l’essai de codage comparatif prévu.

Cela empêche d’affirmer avec force que Claude a produit un meilleur code dans la même expérience. Le travail achevé par Claude en septembre constituait des données historiques de production, tandis que celui de DeepSeek était un test restreint.

Cela empêche aussi une mesure équitable du coût de DeepSeek par modification fusionnée. Le modèle n’a jamais eu l’occasion de générer des modifications destinées à être revues et déployées.

L’entreprise a cité des benchmarks publics de programmation pour soutenir qu’Opus bénéficiait d’un avantage de capacité. Les benchmarks peuvent fournir du contexte, mais ils ne remplacent pas un ensemble de tâches internes identiques.

Un suivi rigoureux donnerait aux deux modèles les mêmes dépôts, outils, restrictions de sécurité, prompts et tests d’acceptation. Les réviseurs resteraient aveugles à l’identité du modèle.

L’étude enregistrerait les modifications réussies, les régressions, les nouvelles tentatives, la latence, l’utilisation de tokens, le temps de revue humaine et les violations de sécurité. Ce n’est qu’alors qu’elle pourrait comparer directement les coûts totaux de livraison.

Malgré cette limite, le déploiement abandonné apporte une leçon pratique. Le coût de l’infrastructure a peu de sens lorsque la couche d’exécution ne peut pas exposer en sécurité les outils prévus pour le modèle.

Les systèmes d’agents élargissent la surface d’attaque, car ils relient des sorties probabilistes de modèles à des actions déterministes. Une seule voie dangereuse peut compter davantage que des milliers de tokens bon marché.

Les entreprises devraient donc tester le confinement avant de calculer les économies liées au travail autonome. L’analyse en lecture seule et les agents avec droits d’écriture appartiennent à des catégories de risque très différentes.

La sécurité affecte également l’économie. Une isolation plus forte peut nécessiter des environnements jetables, des identifiants restreints, des contrôles réseau, une journalisation et des étapes d’approbation.

Ces contrôles consomment du temps d’ingénierie et ajoutent de la latence. Ils peuvent aussi réduire la concurrence ou nécessiter une infrastructure distincte.

Le modèle affichant le tarif d’inférence le plus bas ne produit pas nécessairement le coût le plus bas pour une livraison sûre. Le système pertinent comprend chaque contrôle nécessaire pour faire confiance à sa sortie.

Ce que le test DeepSeek H200 signifie pour les acheteurs d’IA

La prochaine comparaison devrait se concentrer sur le travail accepté, l’utilisation soutenue et l’exécution sûre plutôt que sur un seul prix par token.

Le premier signal à surveiller est une nouvelle exécution contrôlée avec droits d’écriture. DeepSeek doit disposer des mêmes outils, dépôts, prompts et critères d’acceptation que ceux précédemment utilisés avec Claude.

S’il réalise des modifications comparables avec une revue limitée, la conclusion négative du cabinet s’affaiblira. Si les nouvelles tentatives et les corrections restent nombreuses, l’argument fondé sur le coût par résultat se renforcera.

Le deuxième signal est l’utilisation soutenue sur plusieurs semaines. Un serveur auto-hébergé devient plus attrayant lorsque la demande utile reste proche de sa capacité tout au long de la journée.

The Call Center Doctors ont mesuré un pic qui dépassait la capacité d’une machine. Pourtant, un trafic variable peut encore laisser des périodes coûteuses d’inactivité en dehors de ces pics.

Un test plus long devrait rendre compte de l’utilisation par heure, de la profondeur des files d’attente, de la latence du premier token, des interruptions et de la fraction du temps consacrée au chargement ou à la récupération.

Il devrait aussi distinguer les entrées mises en cache, les nouvelles entrées et les sorties. Ces catégories interagissent différemment avec la bande passante mémoire et le traitement par lots.

Le troisième signal est DeepSeek V4.1-Pro. DeepSeek indique que son architecture Flash actuelle s’étendra vers des modèles plus grands, mais n’a pas fourni de date de sortie ferme.

Un modèle plus puissant pourrait changer l’économie s’il accomplit davantage de tâches avec moins de nouvelles tentatives. Il pourrait aussi nécessiter davantage de mémoire ou offrir un débit inférieur.

Les acheteurs devraient surveiller à la fois les capacités et les exigences de service. Une amélioration sur benchmark ne garantit pas un coût de production plus faible.

La réussite actuelle de DeepSeek reste significative. Ses tarifs officiels rendent l’expérimentation à grand volume accessible, et ses poids téléchargeables offrent une flexibilité de déploiement.

Le test n’a pas effacé ces avantages. Il a précisé les conditions dans lesquelles ils se traduisent en économies.

Pour une demande intermittente ou incertaine, l’API gérée de DeepSeek semble plus rationnelle que la location d’un serveur dédié à quatre GPU. Elle préserve de faibles tarifs par token sans transférer les opérations d’infrastructure au client.

Pour les données sensibles, une demande prévisible et soutenue, ou une optimisation spécialisée, l’auto-hébergement peut toujours mériter une évaluation. Le dossier économique doit inclure le personnel, la fiabilité, la sécurité et la capacité inutilisée.

Claude Code présente une proposition différente. Il regroupe l’accès au modèle, une interface de codage et une infrastructure exploitée par le fournisseur sous des limites d’abonnement.

Cette offre peut surpasser les comparaisons fondées sur les tokens pour un usage individuel intensif. Elle peut aussi devenir restrictive lorsque les organisations ont besoin de capacité programmable ou de contrôle centralisé.

La pression repose donc sur les équipes achats et les responsables de l’ingénierie. Ils doivent cesser de traiter « API », « abonnement » et « auto-hébergé » comme des unités d’achat interchangeables.

Ils devraient commencer par des traces de production plutôt que par des exemples de fournisseurs. La trace la plus utile consigne la longueur du contexte, les accès au cache, les sorties, la latence, les échecs et les résultats acceptés.

Les équipes peuvent ensuite rejouer des charges de travail représentatives à travers des systèmes concurrents. Le test devrait inclure les conditions opérationnelles qui comptent après une démonstration réussie.

Ces conditions incluent la concurrence, les variations de trafic, les redémarrages, la mise en file d’attente, les mises à jour de modèles, la supervision et la reprise. Les tests de sécurité doivent être réalisés avant que les agents n’obtiennent un accès en écriture.

Les indicateurs de résultat doivent correspondre à l’objectif de l’organisation. Pour les agents de programmation, ils comprennent les modifications fusionnées, les défauts, les annulations, le temps de revue et le délai d’achèvement.

Pour les agents de support, les mesures utiles incluent les dossiers résolus, les escalades, la satisfaction client et les violations de politique. Pour les agents de recherche, les résultats vérifiés comptent davantage que les pages générées.

Le test DeepSeek H200 est précieux parce qu’il s’est rapproché de cette norme. Il a remplacé une comparaison abstraite des tarifs par une distribution de contexte réelle et une infrastructure réelle.

Ses limites sont tout aussi instructives. La courte durée d’exécution, l’organisation unique, le travail de sécurité inachevé et les accès inégaux à la production empêchent tout verdict universel.

La conclusion appropriée est plus restreinte. Quatre H200 loués n’ont pas surpassé l’API de DeepSeek pour cette charge de travail d’agents, et l’API n’a pas apporté d’avantage manifeste de 80x par rapport aux abonnements.

C’est suffisant pour remettre en cause les affirmations simplistes. Ce n’est pas suffisant pour écarter DeepSeek, les poids ouverts ou l’inférence auto-hébergée.

Avant de modifier une pile IA, collectez une semaine de trafic représentatif et calculez le coût par résultat accepté. Répétez ensuite la comparaison avec les contrôles de sécurité activés.

Demandez-vous si le modèle accomplit le même travail, plutôt que de vous demander si son token le moins cher paraît impressionnant. Le prochain test DeepSeek H200 devrait répondre à cette question plus difficile.