Avec deux agents par utilisateur intensif, une machine 4x B200 absorbe la charge Claude Code d'environ 200 abonnements pour environ 30 % de moins

Une seule machine peut-elle faire le travail Claude Code de 200 abonnements ? Nous avons mesuré 100 agents. Les 200 sont modélisés à partir de ces essais. Un serveur équipé de quatre cartes graphiques NVIDIA B200 dans le cloud inferencekey a fait tourner DeepSeek V4.1 Flash sur DeepInfer, le moteur que DeepSeek a publié en open source en octobre. Nous avons ajouté la pièce avec laquelle le moteur n'est pas livré : un cache. Cent agents synthétiques, dimensionnés comme de vraies sessions Claude Code, ont travaillé en même temps, chacun portant près d'un demi-million de tokens de conversation. La moitié de leurs réponses a démarré en 2,5 secondes environ, et pas une seule requête n'a échoué. Un simulateur calibré sur ces essais situe la machine à environ 400 agents simultanés. Si vos utilisateurs intensifs font tourner deux agents chacun, cela représente la charge d'environ 200 abonnements, pour environ 30 % de moins.

Les 200 abonnements supposent 2 agents simultanés par utilisateur intensif (400 agents, modélisé). Si chaque utilisateur était aussi intensif que notre utilisateur de référence, le simulateur donne environ 80.

Un agent de code relit surtout, et le cache rend la relecture presque gratuite

Chaque fois que Claude Code fait une étape (ouvrir un fichier, lancer un test, modifier une ligne), il renvoie au modèle toute la conversation. Dans nos tests, cette conversation faisait environ 450 000 tokens, à peu près un livre de 1 300 pages. Le modèle écrit quelques centaines de tokens de réponse et, à l'étape suivante, l'agent renvoie le livre entier, plus une nouvelle page.

Dans notre dernier article de recherche, nous avons mesuré un développeur très intensif pendant un mois et trouvé la même chose : 96,8 % de ce que lisait son agent avait déjà été lu. Imaginez une étagère à côté du modèle. Ce qu'il a lu une fois reste sur l'étagère, et la fois suivante il le reprend tout prêt au lieu de le relire.

DeepInfer est livré sans cette étagère. La page du projet chez DeepSeek range le cache parmi les pièces à construire soi-même. Sans lui, notre machine lisait moins d'un demi-livre par seconde, chaque conversation depuis zéro. Avec le cache inferencekey, elle lisait quatre livres par seconde. La facture des agents de code est surtout une facture de relecture, et celui qui tient l'étagère fixe le prix.

Même machine, même modèle : le cache transforme environ 200 K tokens lus par seconde en environ 1,8 M.

Claude Code n'a besoin que de quelques variables d'environnement, et a terminé une vraie tâche en 39 secondes

Quelques variables d'environnement indiquent à Claude Code où envoyer ses requêtes, quelle clé utiliser et quel modèle demander. Pointez-les vers votre endpoint inferencekey et il parle à DeepSeek V4.1 Flash au lieu d'Anthropic, avec les mêmes commandes et les mêmes outils.

Des variables d'environnement pointent Claude Code vers votre endpoint. Le cache inferencekey garde chaque conversation en mémoire GPU et en RAM.

L'étagère a deux niveaux. Le rapide se trouve dans la mémoire même des cartes graphiques et contient environ 57 millions de tokens, à peu près 120 conversations de notre taille. Derrière se trouve un second niveau dans la mémoire ordinaire du serveur, environ dix fois plus grand avec 617 millions de tokens, pour les conversations qui se sont mises en pause un instant.

Le 24 octobre, Claude Code 2.1.310 configuré ainsi a terminé une petite tâche réelle en 39 secondes. Il s'agissait d'implémenter une fonction appelée parse_duration pour qu'un fichier de 15 tests passe. L'agent a fait 14 appels d'outils (lire des fichiers, lancer les tests, modifier le code) et les 15 tests sont passés.

Claude Code 2.1.310, inchangé, sur notre endpoint : une vraie tâche faite en 39 s avec 14 appels d'outils et 15 tests sur 15 au vert. Une petite tâche, pas un benchmark.

La scène de la vidéo ci-dessus montre la vraie application refaisant cette tâche, en rejouant les réponses du modèle enregistrées ce jour-là pendant que les outils s'exécutent réellement.

Le mérite est partagé. L'équipe de DeepSeek a entraîné DeepSeek V4.1 Flash, écrit DeepInfer et l'a publié sous licence Apache 2.0. L'outil aiperf de NVIDIA a testé notre simulateur en charge. Claude Code d'Anthropic tournait par-dessus. Notre part, c'est le cache, l'adaptateur qui permet à inferencekey de faire tourner DeepInfer, l'API qui parle la langue de Claude Code avec vos propres clés, et les mesures.

100 agents à un demi-million de tokens chacun : la moitié des réponses démarre en 2,5 secondes, zéro erreur

Avec 100 agents simultanés, chacun avec environ 450 000 tokens déjà sur l'étagère, la moitié des réponses a démarré en 2,55 secondes et aucune n'a échoué. C'est la taille d'une longue session Claude Code en fin de journée. Nous l'avons lancé le 25 octobre et, sur une fenêtre d'une minute, la machine a traité 237 tours d'agent. La réponse de chaque agent arrivait à environ 135 tokens par seconde, une page en quelques secondes.

100 agents, cache chaud : 0 erreur et des réponses qui démarrent en 2,5 s environ. Les 5 % les plus lents attendent derrière de nouvelles conversations de 450K et manquent l'objectif de 15 s.

Passons à ce qui n'a pas réussi. Notre barre est stricte : 95 % des tours doivent commencer à répondre en 15 secondes. Seuls 2 de nos 8 essais l'ont franchie. Les 8 ont eu zéro erreur. Dans cet essai, 83 % des tours dont la conversation était déjà sur l'étagère ont démarré en 15 secondes. Les 5 % les plus lents ont attendu 37 secondes ou plus, donc l'essai a échoué. Sept conversations toutes neuves sont arrivées pendant cette minute, et chacune devait lire ses 450 000 tokens depuis zéro. Les tours en attente ont fait la queue derrière elles, comme un groupe qui attend que le précédent remballe tout son matériel. Donner la priorité aux tours déjà sur l'étagère, ou limiter le nombre de nouvelles conversations qui démarrent en même temps, aiderait probablement. Nous ne l'avons pas testé.

Test de stress à froid : 176 millions de tokens lus depuis zéro en moins de 15 minutes, zéro erreur

L'étagère vide, la machine a lu des conversations depuis zéro à un rythme régulier de 200 000 tokens par seconde sans une seule erreur. Le 24 octobre, nous lui avons donné 399 nouvelles conversations d'environ 440 000 tokens chacune, 16 à la fois, avec un cache vide. C'est plus dur que n'importe quel vrai matin, où les sessions commencent petites.

En 14,6 minutes, 397 d'entre elles étaient lues en entier et répondaient : 176 millions de tokens. Compté à partir de l'admission de chacune, la première réponse prenait environ 14 secondes (médiane). Compté depuis le début du test, la moitié a attendu plus de six minutes et la dernière près de 15. Les deux dernières étaient encore dans la file quand notre limite de 15 minutes a expiré. Si toute une équipe arrivait en même temps avec des conversations géantes, le problème serait la file d'attente, pas les erreurs.

Test de stress sans rien en cache : 397 conversations de 440K tokens, 176 M de tokens lus depuis zéro en moins de 15 minutes, 0 erreur.

Au quotidien, environ 400 agents tiennent, selon un simulateur construit sur 7 879 tours réels

Tout ce qui précède est mesuré. Cette section est modélisée, et la différence compte.

Environ 250 agents tiennent si 95 % des réponses doivent démarrer en 15 secondes, environ 400 si 30 secondes suffisent. À 400, une réponse typique met environ 21 secondes à démarrer, et 1 sur 20 attend environ 30 secondes ou plus.

Modélisé : un simulateur calibré sur 7 879 tours réels accepte 250 agents si 95 % des réponses démarrent en 15 s, et 400 en 30 s.

Nos tests mesurés étaient volontairement durs : chaque agent ne faisait que trois secondes de pause entre deux étapes. Les vraies sessions sont plus calmes, alors nous avons construit un simulateur de cette machine. Nous l'avons calibré sur chaque tour des deux campagnes de test jusqu'à ce qu'il reproduise ce qu'a fait la vraie machine, y compris son point de rupture. Puis nous l'avons alimenté avec 30 jours d'usage de Claude Code de notre utilisateur de référence : 140 300 appels au modèle, avec leurs vraies pauses.

La machine ne fait pas plus de travail à 400 qu'à 250. Elle répond à environ 450 appels au modèle par minute dans les deux cas. Avec plus d'agents, chacun attend simplement plus longtemps et appelle moins souvent, toutes les 52 secondes au lieu de toutes les 34.

200 abonnements si les utilisateurs intensifs font tourner deux agents chacun, et en dessous d'environ 140 la machine coûte plus cher

Les 200 du titre reposent sur une hypothèse : un utilisateur intensif fait tourner deux agents en même temps, toute la journée. Les 400 agents du simulateur divisés par deux donnent environ 200 abonnements.

Le hic, c'est la vitesse. Sur Claude, les agents de notre utilisateur de référence appellent le modèle toutes les 27 secondes en moyenne. À 400 agents sur cette machine, chacun appelle toutes les 52 secondes. Une tâche prendrait presque deux fois plus de temps.

Il existe une façon plus stricte de compter. Notre utilisateur de référence est l'un de nos utilisateurs très intensifs. Pendant une heure de pointe moyenne, il appelle le modèle environ toutes les 11 secondes. À 450 appels par minute, la machine garde environ 80 personnes comme lui à pleine vitesse. La machine ne coûte moins cher que les abonnements Claude Max 20x qu'au-delà d'environ 140 abonnements. Au compte strict de 80, elle coûte 27 900 USD par mois contre 16 000 en abonnements, environ 75 % de plus.

Notre utilisateur de référence n'est cependant pas typique. En plus de ses propres sessions, il fait tourner des agents autonomes pour des workflows et des tâches métier, donc un utilisateur ordinaire de Claude Max charge moins la machine. Les logs Claude Code de votre équipe peuvent vous dire où vous vous situez.

Environ 0,006 USD par million de tokens, 80 fois moins que l'API Claude

L'autre comparaison est l'API. Le vrai mois de Claude Code de notre utilisateur de référence, au tarif public de l'API Claude, est revenu à 12 365 USD pour 26,2 milliards de tokens, soit 0,47 USD par million. La machine revient environ 80 fois moins cher par token lu. Cela repose sur les 1,8 million de tokens par seconde d'une minute chargée de notre test le plus dur, étirés sur les 730 heures d'un mois, donc considérez-le comme le meilleur cas.

27 900 USD par mois à 1,8 M de tokens par seconde, c'est environ 0,006 USD par million de tokens. Soit environ 80 fois moins qu'un vrai mois intensif sur l'API Claude.

La comparaison est juste parce que les deux côtés relisent surtout : 96 % depuis le cache dans notre test, 96,8 % dans le vrai mois Claude. Une équipe qui dort la nuit paie plus par token utile. Les 30 % et les 80 fois répondent à des questions différentes, donc ne les multipliez pas.

Qualité : premier sur LiveBench agentic coding, et les réponses en cache correspondent aux réponses fraîches

Sur un benchmark de code externe, DeepSeek V4.1 Flash arrive premier. LiveBench a une catégorie agentic coding, où un modèle doit terminer une vraie tâche de programmation étape par étape. Le 10 octobre, DeepSeek V4.1 Flash a obtenu 77,3 et s'est classé premier sur 69 modèles. Claude Opus 5.5 a obtenu 71,7. Nous n'avons pas lancé ce benchmark nous-mêmes.

LiveBench agentic coding (livebench.ai, 10/10/2026) : DeepSeek V4.1 Flash 77,3 contre Claude Opus 5.5 71,7. Benchmark externe, non mesuré par nous.

Un indice plus large d'Artificial Analysis va dans l'autre sens : Opus 5.5 obtient 58 et Flash 39. Pour une équipe qui vient d'Opus, cet écart est la réserve honnête, alors essayez Flash sur vos propres tâches avant de changer.

Notre propre vérification, c'est que l'étagère ne change pas les réponses. Nous avons caché un fait dans un long document, jusqu'à 200 000 tokens, et l'avons demandé deux fois : une fois lu depuis zéro, une fois servi depuis le cache. Cinq documents sur cinq ont donné la même bonne réponse dans les deux cas. La version en cache a répondu en moins d'une seconde. Celle de 200 000 tokens a pris 13 secondes lue depuis zéro.

Cette vérification a mérité sa place. Une version antérieure de notre adaptateur ne servait rien depuis le cache, et cette vérification l'a repéré avant tout test de charge. Nous l'avons corrigé, et la version corrigée servait les répétitions à 95 à 99 % depuis le cache. Chaque chiffre mesuré de cet article en vient.

Votre code va là où vous le décidez

Avec Claude, ou avec l'API de DeepSeek, votre code et les données qu'il touche finissent chez un fournisseur de modèles. Avec inferencekey sur vos propres GPU, il ne quitte jamais votre réseau. Avec le cloud inferencekey, où ces tests ont tourné, il va sur nos GPU, pas chez Anthropic ni chez OpenAI. Dans les deux cas, les clés d'API restent de votre côté, dans votre réseau. Si l'une fuit, vous la renouvelez là. Le prix et les tests présentés ici concernent le cloud inferencekey. Nous n'avons ni chiffré ni testé le cas on-premise.

200 agents à 500K débordent le niveau rapide, donc environ 120 est le plafond à cette taille

Avec des conversations de 500 000 tokens, le niveau rapide de l'étagère est le plafond. Avec 200 agents qui demandaient tous en même temps, leurs conversations ne tenaient pas dans la mémoire des cartes graphiques. L'essai s'est effondré : la moitié des réponses a mis plus de deux minutes à démarrer. Rien n'a été perdu et rien n'a échoué, mais c'était inutilisable. À ce rythme dur, environ 120 conversations de cette taille peuvent être servies en même temps.

La plupart des tests ont contourné l'API inferencekey et appelé le moteur directement. Celui qui l'a utilisée a eu zéro erreur, mais ses réponses les plus lentes ont mis 22 secondes à démarrer, pas 15. C'était une seule fenêtre courte, donc nous ne pouvons pas encore dire combien coûte le saut supplémentaire sur les longues conversations.

Rentable au-delà d'environ 140 abonnements, si des réponses plus lentes aux heures de pointe sont acceptables

Au-delà d'environ 140 abonnements Claude Max 20x, une machine est une facture fixe sans plafond d'usage par personne. Le plafond est partagé, environ 400 agents, et vous gardez Claude Code. En dessous d'environ 140, les abonnements coûtent moins cher. Si votre code ne peut pas quitter le bâtiment, la même installation peut tourner sur vos propres GPU. Si vous avez dix développeurs, les abonnements ou l'API de DeepSeek restent le choix le plus simple.

Essayez vous-même

Suivez le guide DeepInfer sur 4x B200 pour servir DeepSeek V4.1 Flash et y pointer Claude Code. Il vous faut quatre cartes B200, ou un workload dans le cloud inferencekey, et une clé d'API inferencekey. Avec les poids sur disque, notre workload était prêt en moins de deux minutes.

export ANTHROPIC_BASE_URL=https://api.inferencekey.com/endpoint/<project>/<workload>
export ANTHROPIC_AUTH_TOKEN=ik_live_...
export ANTHROPIC_MODEL=deepseek-v4.1-flash
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4.1-flash
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4.1-flash
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4.1-flash
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
claude