Acheter des tokens, louer des GPU ou posséder le rack ?

Il y a peu, héberger soi-même un modèle de pointe n’était pas une vraie question. Les modèles à poids ouverts avaient une génération de retard sur les modèles propriétaires, donc il n’y avait aucun calcul à faire.

Puis l’écart s’est refermé. Pas à zéro, mais à une trentaine de points Elo. Kimi K3 est sorti avec des poids ouverts et se place deuxième de l’arène de code frontend avec 1 682, derrière Claude Opus 5 Max à 1 712 et devant tout le reste¹. Ses poids tiennent, sur le papier, sur un seul nœud de huit GPU. Tu peux télécharger le modèle ce soir, gratuitement.

La machine, c’est une autre histoire. À supposer que tu puisses investir le capital. Et à supposer qu’une fois l’arithmétique faite, ça vaille le coup.

J’ai donc modélisé quatre façons de faire tourner la même charge : un rack dans ton bureau, du matériel acheté dans un datacenter en colocation, des GPU dédiés loués, et des API payées au token. Cette dernière, je l’appelle le compteur dans tout ce qui suit.

La réponse n’est pas « achète le rack ». En dessous d’environ 44 ingénieurs, le compteur reste le moins cher. Entre 44 et 95 environ, les GPU loués gagnent. Au-dessus, posséder commence à payer, et à 750 ingénieurs ça bat le compteur de six contre un environ.

Le chiffre qui décide, c’est le taux d’utilisation. Un rack acheté sur trois ans coûte la même chose à trois heures du matin, qu’il serve des tokens ou qu’il chauffe le bâtiment.

K3 n’est ici qu’un exemple. La même méthode s’applique à ce qui sortira ensuite.

Quatre façons d’acheter de l’inférence

Option	Tu possèdes	Tu loues	Tu paies
Rack au bureau	Les GPU, l’alimentation électrique, le refroidissement	Rien	Capex, électricité, un électricien, de la surface au sol, des gens
Rack en colo (ton matériel, le bâtiment de quelqu’un d’autre)	Les GPU	L’espace, l’alimentation, le refroidissement	Capex, location du rack au kW2, des gens
GPU dédiés / loués	Rien	Des GPU entiers à l’heure	Des heures réservées, des gens
Le compteur (API au token)	Rien	Rien	Des tokens

Plus tu descends dans ce tableau, plus ton engagement fixe baisse et plus ta flexibilité monte. Ce que tu perds, c’est le contrôle et, à grande échelle, le coût unitaire. Trouver où ce compromis bascule, c’est tout l’exercice.

Avant le tableur, une question plus basique : peut-on vraiment mettre une de ces machines dans un bureau ?

Est-ce qu’on peut ?

Dans la saison deux de Silicon Valley, les serveurs de Gilfoyle prennent feu. L’équipe en met trop sur Anton, il atteint son maximum d’ampères, fait sauter le disjoncteur général et brûle. Tout le monde s’en souvient comme d’un gag sur l’orgueil démesuré. Ici, on le traite comme un commentaire sur le génie électrique.

Désolé si tu n’as pas vu Silicon Valley. C’est un classique moderne, en avance sur son temps.

K3, c’est 2,8 billions de paramètres, 104 milliards actifs par token, 896 experts, quantifié en MXFP4 dès la sortie de l’entraînement³. Ça fait 1 390 Go de poids sur le papier. Un nœud B200 à huit GPU t’en donne 1 440, donc sur le papier ça tient avec 50 Go de marge. Les mesures du checkpoint réel donnent plutôt 1,56 To une fois comptés tous les éléments qui ne sont pas des poids quantifiés, auquel cas ça ne tient pas du tout. C’est le rêve mouillé de r/selfhosted : le deuxième meilleur modèle de code de la planète, qui ronronne dans un placard, à toi.

Puis tu lis la fiche technique.

Spécifications, un DGX B200	Valeur	Ce que ça donne dans un bureau
Consommation	14,3 kW4	Deux plaques à induction complètes, tous les feux, en permanence
Circuit domestique britannique (ring main)	7,4 kW	Un serveur réclame deux circuits entiers pour lui
Chaleur dégagée	~48 800 BTU/h	Trois à quatre climatiseurs domestiques, à fond
Débit d’air	2 145 CFM4	Pas un placard. Un local technique
Poids	130 kg4	Avant le rack, les PDU et le refroidissement
Deux nœuds par rack	2x 380V triphasé 32A4	Tu appelles un électricien, tu n’achètes pas une rallonge

Une incohérence à assumer : les chiffres de puissance, de poids et de débit d’air sont ceux de NVIDIA pour le DGX B200, son appareil intégré, alors que les 450 000 $ que je modélise sont un prix de rue pour un HGX B200 à 8 GPU, la carte autour de laquelle un OEM construit un serveur. Un DGX est listé plus près de 515 000 $. J’utilise le prix le plus bas avec la consommation de la machine la plus chère, ce qui avantage l’auto-hébergement sur le capex et le pénalise sur l’électricité.

Anton n’a pas fait sauter ce disjoncteur parce qu’un scénariste voulait un incendie au troisième acte. Il l’a fait sauter parce que c’est ce qui arrive quand tu branches une charge industrielle sur du câblage domestique.

Un seul nœud, au passage, c’est le cas charitable, et il l’est de deux façons. Ces 50 Go de marge ne laissent rien pour le cache KV, la mémoire de travail dont un modèle a besoin pour tenir une longue conversation, donc un vrai déploiement en production demande plus d’accélérateurs que ça. Moonshot en recommande 64 ou plus⁵. Ça fait huit de ces boîtes, 114 kilowatts, dans ton bureau. Moins une salle serveur qu’un micro-réacteur nucléaire qui attend qu’on annonce une série A autour.

J’ai quand même modélisé le nœud unique, parce que c’est la chose la moins chère qui pourrait plausiblement contenir les poids. Attention toutefois : ce n’est pas un pire cas. Le personnel et les travaux électriques sont presque fixes, donc plus de nœuds les répartissent et l’économie s’améliore. Un résultat à un nœud, c’est l’épreuve la plus dure pour l’auto-hébergement, pas la plus facile.

Reste l’approvisionnement. Les allocations Blackwell vont d’abord aux plus gros acheteurs, donc en obtenir une, c’est faire la queue derrière Musk.

Il te faut un Gilfoyle

Gilfoyle, c’est le gars des systèmes. Il possède les racks, ne fait confiance à rien, et c’est le seul du bâtiment à savoir pourquoi le cluster est en feu.

Ce qui nous amène à ma fiction préférée dans un business case d’auto-hébergement : une fraction d’ingénieur.

Tu ne peux pas embaucher 0,3 personne. Ce poste fait tourner vLLM ou SGLang en production, sait ce qu’est le parallélisme d’experts, débogue NCCL à deux heures du matin, et garde plusieurs centaines de gigaoctets de mixture d’experts chauds et opérationnels. Robert Half donne un salaire médian de 102 000 £ pour un ingénieur en machine learning à Londres, et près de 119 000 £ pour le quartile supérieur⁶. J’ai modélisé 120 000 £, volontairement une embauche du quartile supérieur, parce que la médiane ne sait pas faire ce travail.

Il aura aussi des opinions. Sur ta facture cloud, sur le clavier qu’il exige, sur les parts qu’on doit à la seule personne du bâtiment qui comprend le truc dont tout le monde dépend désormais. C’est ça, le vrai coût de le faire tourner toi-même, et il ne figure sur aucune fiche technique de GPU.

Il t’en faut deux, parce qu’un seul, c’est un point de défaillance unique avec un passeport et des avis tranchés sur les congés annuels.

Ligne	Valeur (GBP)
Salaire de base (quartile supérieur)	120 000 £
Coefficient de charges (cotisations patronales, retraite, matériel)	1,3
Coût chargé par personne	156 000 £
Personnes nécessaires	2
Total annuel	312 000 £ (environ 396 000 $)

Ce chiffre ne s’amortit pas. Il ne baisse pas, et il se moque que ton matériel soit occupé ou non.

La charge de travail décide plus que le matériel

La plupart des calculs d’auto-hébergement que j’ai vus sont chiffrés sur du chat, le pire cas possible pour posséder du matériel et à mille lieues de ce que fait une équipe de développement toute la journée.

Le codage agentique tourne à 4,17 millions de tokens par tâche, avec un ratio entrée/sortie d’environ 153:1⁷. Rien ne compte plus ici que ce ratio, sauf le taux d’utilisation.

Sur ton propre matériel, il joue en ta faveur. Le prefill, la lecture de ton prompt, et le decode, l’écriture de la réponse, sont deux tâches différentes aux coûts différents. vLLM mesure 26 200 tokens par GPU et par seconde en prefill contre 10 100 en decode⁸, donc le prefill est deux fois et demie plus efficace. Le codage agentique, c’est presque uniquement du prefill. Le travail de ton équipe se trouve être celui pour lequel les GPU sont les meilleurs.

Sur le compteur, il joue aussi en ta faveur, parce que les tokens d’entrée coûtent cinq fois moins cher que ceux de sortie.

Composante	Calcul	$/1M tokens
Entrée non mise en cache	0,30 × 0,9935 × 5 $	1,49
Entrée en cache (lectures à 0,1×)	0,70 × 0,9935 × 5 $ × 0,1	0,35
Sortie	0,0065 × 25 $	0,16
Moyenne pondérée, 70 % de hits de cache		2,00 $
Moyenne pondérée, sans aucun cache	0,9935 × 5 $ + 0,0065 × 25 $	5,13 $

Ces 70 % sont une hypothèse, pas une mesure, et c’est le deuxième chiffre le plus important de ce post. Il divise le compteur par plus de deux, de 5,13 $ à 2,00 $. Si tu divises le taux de hits par deux, à 35 %, le compteur monte à 3,57 $, ce qui déplace tous les points de bascule ci-dessous nettement vers l’auto-hébergement. Dans l’autre sens, le compteur gagne presque partout.

Deux choses de plus sur ces 2,00 $ avant de leur faire confiance. Anthropic facture environ 1,25x l’entrée pour écrire une entrée de cache, et j’ai chiffré chaque token non mis en cache comme une simple lecture. Si les 30 % non mis en cache étaient tous des écritures, le compteur serait à 2,37 $ au lieu de 2,00 $. La vérité est quelque part entre les deux.

Quelqu’un demandera pourquoi je compare K3 auto-hébergé à Opus 5 plutôt qu’à l’API de K3 elle-même, moins chère à 3 $ et 15 $ le million avec des hits de cache à 0,30 $⁹, soit environ 1,20 $ avec ce mélange de tokens. Parce que pour la plupart des entreprises visées par ce post, envoyer du trafic de production vers un cloud chinois n’est pas une option, quoi que dise la grille tarifaire. Ce n’est pas un jugement technique, c’est un jugement d’achats, et il se prend au-dessus de ta tête. Le choix réaliste, c’est faire tourner K3 toi-même ou acheter Opus 5 chez Anthropic, et c’est ce que comparent les tableaux.

C’est aussi, soit dit en passant, le même instinct qui pousse les gens à s’auto-héberger au départ. Si tu étais tranquille sur l’endroit où tournent les poids, tu utiliserais l’API et tu arrêterais de lire.

Alors avant d’utiliser quoi que ce soit ici : va regarder ton vrai taux de hits de cache. Il compte plus que le prix d’un GPU.

Ce que sert vraiment une machine

Pour comparer quatre options, il me faut deux chiffres : combien de travail un nœud traite, et combien de travail un ingénieur génère. Aucun n’est exact, voici donc chaque hypothèse, y compris celles qui ruinent le fantasme.

Étape	Calcul	Résultat
Part d’entrée dans les tokens	153 ÷ 154	0,9935
Débit mélangé par GPU	moyenne harmonique de 26 200 en prefill et 10 100 en decode avec ce mélange	25 932 tok/s
Décote K3 vs classe DeepSeek	104 Md de paramètres actifs vs ~37 Md	× 0,35
Décote B200 vs GB200	le benchmark tournait sur GB200	× 0,70
Décote trafic réel vs benchmark	les benchmarks sont propres, la production non	× 0,60
Débit décoté par GPU	25 932 × 0,147	3 812 tok/s
Par nœud	× 8 GPU	30 496 tok/s
Capacité annuelle à 100 % de charge	× 31 536 000 secondes	962 000M tokens

En face, la demande :

Étape	Calcul	Résultat
Tâches par ingénieur et par jour	hypothèse de charge, non mesurée	6
Tokens par tâche	Bai et al.7	4,17M
Jours travaillés par an	260 moins congés et jours fériés	230
Tokens par ingénieur et par an	6 × 4,17M × 230	5 755M

À fond, un nœud sert environ 167 ingénieurs. Avec un cycle d’utilisation annuel de 21 %, à peu près l’usage en heures de bureau, il en supporte environ 35.

Le chiffre exact de capacité se discute, et je reviendrai sur son degré d’erreur possible. Une fois le matériel acheté, le taux d’utilisation écrase toutes les autres variables.

Le taux d’utilisation décide

Le matériel acheté coûte pareil endormi ou à fond. L’amortissement court, la location du rack court, et tes deux Gilfoyle sont payés quoi qu’il arrive. L’électricité est la seule ligne qui suit la demande, et l’électricité s’avère être de la petite monnaie.

Utilisation	Rack bureau $/1M	Colo $/1M	Compteur $/1M
5 %	12,23	12,81	2,00
10 %	6,14	6,40	2,00
21 % (heures de bureau seulement)	2,95	3,05	2,00
35 %	1,79	1,83	2,00
50 %	1,27	1,28	2,00
80 %	0,81	0,80	2,00
100 %	0,66	0,64	2,00

La courbe du bureau croise le compteur à 31,2 % d’utilisation, celle de la colo à 32,0 %.

Une réserve qui a sa place ici plutôt qu’à la fin : c’est une courbe à un seul nœud. Deux ingénieurs plateforme et la facture de l’électricien ne croissent pas avec le nombre de nœuds, donc à deux nœuds le point de bascule tombe vers 21 %, et à cinq vers 14 %. Plus tu es gros, moins il te faut d’utilisation pour justifier de posséder.

Maintenant, compare une vraie équipe. Huit heures par jour, 230 jours par an, ça fait 1 840 heures sur 8 760 possibles. Un cycle d’utilisation de 21 %. Une équipe qui travaille en heures de bureau puis rentre chez elle reste sous le seuil de rentabilité, et l’auto-hébergement perd.

La question n’a donc jamais été de savoir si les modèles à poids ouverts sont assez bons, ou si les GPU sont assez bon marché. Les deux sont réglés. La question, c’est de savoir si tu peux remplir l’équipe de nuit avec des jobs batch, des évals, de la réindexation et la CI que personne ne surveille. À 35 %, tu gagnes. À 50 %, tu gagnes confortablement. Laisse-le tourner à vide chaque soir et tu as acheté un radiateur d’appoint hors de prix, en leasing sur trois ans.

Des analyses indépendantes du débit provisionné d’Azure situent le seuil de rentabilité face au paiement à l’usage autour de 80 % d’utilisation soutenue¹⁰. Ni AWS ni Microsoft ne publient de seuil de rentabilité, donc prends ça pour de l’arithmétique de tiers plutôt que pour une recommandation de fournisseur. C’est très loin de mes 31 %, et je ne vais pas prétendre le contraire. Ils mesurent des choses différentes : le leur est un produit à marge, tarifé face à sa propre grille, le mien est un coût brut face à la grille d’un rival. Ce qu’ils ont en commun, c’est le sens : la capacité réservée doit être occupée la plupart du temps avant de rapporter.

Les GPU loués gagnent le milieu

L’utilisation fixe le prix unitaire. La taille de l’équipe décide de l’option gagnante, parce que c’est elle qui répartit les coûts fixes.

À 25 ingénieurs, un nœud tourne à 15 % de charge et le compteur gagne haut la main. Deux ingénieurs plateforme coûtent 396 240 $ par an. La facture de tokens qu’ils remplaceraient s’élève en tout à 287 777 $. Le personnel coûte plus cher que le problème. Rien d’autre dans le tableur ne mérite d’être lu.

À 60 ingénieurs, un nœud tourne à 36 % de charge et la capacité louée passe devant de justesse.

Ligne annuelle (USD)	Bureau	Colo	Loué	Compteur
Amortissement du matériel11	150 000	150 000	0	0
Infrastructure électrique	25 400	0	0	0
Électricité	31 821	0	0	0
Location du rack	0	69 564	0	0
Location des GPU	0	0	138 382	0
Ingénieurs plateforme	396 240	396 240	396 240	0
Facture de tokens	0	0	0	690 664
Total	603 461	615 804	534 622	690 664
Par ingénieur	10 058	10 264	8 910	11 511
Par 1M de tokens	1,75	1,78	1,55	2,00

Remarque ce qui manque dans ce tableau : une remise de personnel pour la location. Chaque option auto-hébergée porte deux ingénieurs plateforme complets, parce qu’on ne peut pas appeler une fraction de personne à deux heures du matin, quel que soit le propriétaire du métal. Louer t’épargne le capex, l’électricien et la file derrière Musk. Ça ne t’épargne pas la paie.

C’est pourquoi la victoire est mince. De la moins chère à la plus chère, l’écart entre les quatre options est de 29 %, bien à l’intérieur de la marge d’erreur de mes propres hypothèses.

J’ai cherché quelqu’un qui aurait chiffré cette option face aux trois autres et je suis resté sur ma faim, ce qui me laisse perplexe, parce que louer des GPU n’a rien d’obscur. Lambda, CoreWeave, Spheron et une douzaine d’autres publient leurs tarifs horaires B200, et un agrégateur en suit plus de 26¹². Le milieu est bel et bien à vendre, et pour une équipe de 60 ingénieurs il bat les deux extrémités.

À 750 ingénieurs, cinq nœuds tournent à 90 % de charge et la location perd lourdement, parce qu’elle facture à l’heure et qu’à cette utilisation tu les paies presque toutes. Posséder le matériel coûte 1 494 059 $ en colo ou 1 565 997 $ dans ton propre bureau, contre 2 126 018 $ en location et 8 633 301 $ sur le compteur. C’est le seul endroit de tout le modèle où posséder est manifestement la bonne réponse, et ça bat le compteur de six contre un environ.

Remarque pourtant à quel point les colonnes bureau et colo sont proches. Au-dessus d’environ 95 ingénieurs, elles restent à quelques pour cent l’une de l’autre et changent de place selon le nombre de nœuds. Comme mon option bureau ne paie pas de loyer, la lecture honnête est que c’est la même réponse, et que le choix entre les deux porte sur qui tu veux voir changer les filtres.

Taille d’équipe	Option la moins chère	Coût annuel par ingénieur	Raison principale
25	Le compteur	11 511 $	Le personnel plateforme coûte plus que toute la facture de tokens
60	GPU loués	8 910 $	Assez de charge pour vouloir de la capacité, pas assez pour justifier le capex
750	Matériel acheté (colo)	1 992 $	Une demande quasi continue rend les heures de location chères

Les tokens ne sont pas de l’argent

Il existe dans la planification technologique une hypothèse tenace, et je le dis en faisant clairement partie du problème : les tokens seraient le nouveau baril de pétrole. L’unité d’échange universelle. Des entreprises entières bâtissent maintenant leurs cycles de planification en tokens.

Tout compris et à pleine utilisation, le nœud acheté dans ce modèle coûte environ 0,66 $ le million de tokens contre 2,00 $ sur le compteur avec cache. L’électricité seule en représente 6,6 cents, soit un dixième du total et, ce qui est agaçant, un facteur dix d’écart avec le chiffre juste au-dessus. Les deux sont justes.

Ligne	Calcul	Valeur
Puissance du nœud	14,3 kW × 8 760 heures	125 268 kWh/an
Aux tarifs professionnels britanniques13	× 0,25 £	31 317 £
Avec le surcoût de refroidissement du bureau (PUE 1,6)	× 1,6	50 107 £
En dollars	× 1,27	63 636 $
Tokens produits à pleine charge		962 000M
Électricité par 1M de tokens		6,6 cents

Le but n’est pas que quelqu’un facture sept cents. Le prix d’un token inclut le matériel, le personnel, le risque, la recherche et la marge, et c’est normal. Le but, c’est de voir qu’un token est une abstraction de facturation de détail posée sur des secondes de GPU, avec un taux de change fixé par celui qui les vend. Si les tokens sont vraiment le nouveau pétrole, alors les hyperscalers sont l’OPEP, avec l’avantage pratique de pouvoir réviser la physique dès que les marges ont besoin d’un coup de main.

C’est là que ça va ensuite, et c’est moins une prédiction qu’un schéma qui a déjà tourné une fois. La puissance de calcul de l’IA se financiarise exactement comme celle du Web 2.0. EC2 a démarré en facturant à l’instance-heure, et en quelques années le vrai marché, c’étaient les instances réservées, les savings plans, le spot et les remises d’usage soutenu. Les gros acheteurs ont arrêté de payer le tarif à la demande il y a des années.

Ça commence déjà. Bedrock vend du débit provisionné à l’heure par unité de modèle, de 4,11 $ à 49,50 $ selon le modèle, et le tarif baisse avec la durée d’engagement¹⁰. Azure vend la même chose sous forme d’unités de débit provisionné. Ce ne sont pas des prix au token, ce sont des réservations de capacité avec une courbe d’engagement.

Ce qui manque sur cette page en dit long. Aucun modèle Claude actuel n’a de tarif de débit provisionné publié. Le marché réservé des modèles de pointe existe, mais il est coté sur devis plutôt que listé, ce qui montre à quel point on est tôt.

Suis ça jusqu’au bout et tu arrêtes d’acheter des tokens. Tu réserves de la capacité pour ta base, tu prends la remise d’usage soutenu, et tu bascules sur le compteur quand tu pointes. Les tokens deviennent l’échappement d’un tuyau que tu as déjà payé, et ce que tu budgètes devient l’heure de GPU, qui a au moins une vraie courbe d’offre derrière elle.

Est-ce qu’on devrait ?

Une partie de ce qui précède peut ressembler à un plaidoyer pour aller acheter du métal. Ce n’est pas tout à fait ça.

Tu achèterais un actif qui se déprécie pendant que le prix du compteur baisse. Opus 5 est sorti exactement au prix d’Opus 4.8, 5 $ et 25 $ le million de tokens, et c’est un bien meilleur modèle¹⁴. La grille tarifaire n’a pas bougé pendant que ce qu’il y a derrière s’améliorait. Ton capex est donc un pari sur trois ans que l’intelligence de pointe baisse de prix plus lentement que ton matériel ne s’use, alors que la frontière avance à l’échelle de quelques mois. Le matériel que tu spécifies aujourd’hui reste coincé avec l’économie d’aujourd’hui jusqu’en 2029.

Les deux choses sont donc vraies à la fois. Les tokens portent une grosse marge, et acheter des machines est une mauvaise façon pour la plupart des gens d’y échapper. La sortie, c’est que tu n’as pas besoin d’acheter un rack pour arrêter de payer le prix de détail. Réserve la capacité, n’achète pas le bâtiment.

Deux choses survivent à l’arithmétique, mais une seule proprement.

La souveraineté. Si tes données ne peuvent pas quitter le bâtiment, tu ne te compares pas à 2,00 $, tu te compares à rien, parce que le compteur ne t’est pas en vente, à aucun prix. Fais quand même tourner les chiffres d’utilisation, mais tu as déjà décidé.

La latence, mais moins que tu ne l’espères. Un modèle dans le même rack t’économise un aller-retour réseau. C’est peut-être quarante millisecondes face à la trentaine de secondes que la chose passe à réfléchir, donc pour le travail agentique, c’est du bruit. Ça se justifie sur les cas serrés, l’autocomplétion et les suggestions en ligne, où tu vises un budget sous les 100 ms et où le réseau en pèse une vraie part. Si ce n’est pas ta charge, ne le mets pas dans le business case.

Voici donc ce que je ferais vraiment : arrête de choisir l’une des quatre. Réserve assez de capacité pour couvrir ta base et mets le reste au compteur. Le travail prévisible à gros volume tourne la nuit sur le tuyau que tu as déjà payé, à l’utilisation où il gagne deux contre un ou mieux. Le raisonnement difficile va au modèle de pointe sur le compteur, où tu paies pour quelque chose que tu ne peux ni reproduire ni amortir.

En pratique, c’est le placement plutôt que le choix du modèle qui est le principal levier économique. C’est l’argument que j’avais fait sur le routage entre modèles, une couche plus bas dans la pile.

Où ce modèle pourrait se tromper

Quatre choses.

Ma décote de débit est probablement trop sévère, et la corriger favorise la location. J’ai réduit le benchmark vLLM d’un facteur sept pour couvrir le fait que K3 est plus gros, que le matériel est refroidi par air et que le trafic réel est plus brouillon qu’un benchmark. C’est du calcul au dos d’une enveloppe, et une vérification grossière sur les FLOPs bruts dit que le vrai chiffre pourrait être trois ou quatre fois plus haut. Refais tourner avec ce chiffre et 200 ingénieurs basculent de posséder à louer, parce qu’un matériel plus rapide réduit tout de suite les heures de GPU loués alors qu’il ne change rien au capex déjà engagé. Ça joue contre un rack, pas pour.

Les tâches par ingénieur et par jour sont une estimation. J’ai pris six. Ça pilote la demande absolue et donc les résultats par taille d’équipe. Ça ne touche pas le tableau d’utilisation, ce qui explique pourquoi c’est l’affirmation la plus solide et pourquoi je l’ai mise en premier.

La configuration à un nœud est optimiste, comme signalé plus haut. Moonshot veut 64 accélérateurs en production et j’en ai modélisé huit, ce qui est la lecture la plus généreuse que l’auto-hébergement puisse demander.

L’option bureau a son bâtiment gratuitement. Elle paie le matériel, l’installation électrique et de refroidissement, et l’électricité. Elle ne paie ni loyer, ni taxes professionnelles, ni assurance, ni extinction d’incendie, ni onduleur, ni PDU, ni travaux de structure pour 130 kg par nœud, ni mise à niveau de l’alimentation du gestionnaire de réseau, et au-dessus d’environ deux nœuds un immeuble commercial britannique aura besoin de cette mise à niveau plutôt que d’un électricien. La colo paie tout cela dans les 285 £/kW/mois. Cet écart explique en partie pourquoi le bureau bat la colo partout dans mes tableaux, et tu devrais considérer les deux comme plus proches qu’elles n’en ont l’air. Facturer à l’option bureau la moitié du tarif tout compris de la colo la laisse devant à toutes les tailles d’équipe, ce qui est la seule raison pour laquelle je n’ai pas tenté d’inventer un chiffre.

Chaque chiffre a une source et un indice de confiance dans le classeur derrière ce post. Les moins fiables sont les trois que tu viens de lire.

L’arithmétique peut donc se tromper sur les bords. La physique, non. Quatorze kilowatts, c’est quatorze kilowatts, que mon estimation de débit tienne ou non, la chaleur doit aller quelque part, et l’électricien veut toujours être payé.

Je pourrais acheter des tokens et ne plus jamais penser à tout ça. Ou je pourrais penser à tout ça, et attraper un coup de chaleur en câblant une carte graphique de plus.

Footnotes

1. Classement Arena WebDev, 28 juillet 2026, 492 170 votes. claude-opus-5-max 1 712 ; kimi-k3-max 1 682 ; claude-opus-5-high 1 669 ; claude-fable-5 1 628 ; gpt-5.6-sol-xhigh 1 623 ; claude-opus-4-8-thinking 1 568. À garder en tête : le rang de K3 en code le flatte. Sur le classement texte principal (27 juillet 2026), kimi-k3-max est onzième avec 1 486 ±10, derrière claude-fable-5 (1 508) et claude-opus-5-max (1 495), et à égalité statistique avec claude-opus-4-8-thinking (1 484 ±5). C’est un spécialiste du code, pas le meilleur modèle du monde. ↩

2. Je modélise la colo à 285 £ par kW et par mois. Ce chiffre, je l’ai sorti de mon cul, parce que je n’ai pas trouvé de source assez bonne pour l’assumer. Pour ce que ça vaut : la colocation britannique en gros tourne à 150-300 £ par kW et par mois à partir de 1 MW, le détail à Londres est coté 300-800 £ par baie et dépasse 2 000 £ pour la densité, et les racks GPU haute densité portent une prime que personne ne veut chiffrer. Mon déploiement fait 14 à 72 kW, bien trop petit pour les tarifs de gros. Si tu sais ce que coûte vraiment un rack GPU de 30 kW à Londres, dis-le-moi et je corrigerai. Je traite le tarif comme tout compris, couvrant espace, refroidissement, résilience et alimentation, parce que facturer l’électricité mesurée par-dessus compterait deux fois la plus grosse ligne d’une facture de colo. ↩

3. Moonshot AI, Kimi-K3 model card. Hugging Face. 2,8T de paramètres au total, 104B actifs (16 experts sur 896), poids MXFP4 avec activations MXFP8, contexte de 1 048 576 tokens. ↩

4. NVIDIA, Data Center Best Practices with DGX B200. Fiche technique. Puissance système estimée 14,3 kW max, poids >130 kg, et 150 CFM par kilowatt, soit 2 145 CFM par nœud (le document indique 4 290 CFM pour un rack de deux nœuds). Deux nœuds par rack exigent 2 alimentations triphasées 380V 32A. Le chiffre de chaleur est ma propre conversion, pas celle de NVIDIA : 14,3 kW x 3 412 = ~48 800 BTU/h. ↩ ↩² ↩³ ↩⁴

5. Moonshot AI, article de lancement de Kimi K3 : “we recommend deploying Kimi K3 on supernode configurations with 64 or more accelerators”. Une recommandation, pas un plancher. Moonshot ne publie aucun nombre minimal de GPU. ↩

6. Robert Half, Guide des salaires 2026, ingénieur machine learning, Londres. 50e percentile 102 000 £, 75e percentile environ 119 000 £. ↩

7. Bai et al. (2026), How Do AI Agents Spend Your Money? Article, figure 1. Le codage agentique atteint en moyenne 4,17M de tokens par tâche avec un ratio entrée/sortie de 153,85:1, contre 1,33 pour le chat de code et 0,16 pour le raisonnement de code. L’article donne aussi 1,86 $ par tâche, mais c’est une moyenne sur huit modèles, la plupart bien moins chers qu’Opus 5, et cela revient à environ 0,45 $ par 1M de tokens. Je prends le volume de tokens et le ratio de l’article et je les chiffre moi-même : la même tâche sur Opus 5 avec 70 % de hits de cache coûte environ 8,34 $. Ne lis pas les deux chiffres de coût comme comparables. ↩ ↩²

8. vLLM, Driving vLLM WideEP and Large-Scale Serving Toward Maturity on Blackwell (Part I), 3 février 2026. Lien. 26,2K tokens de prefill et 10,1K de decode par GPU-seconde sur GB200 pour un MoE de type DeepSeek à 2K en entrée / 2K en sortie. Deux choses à garder avec ce chiffre : il vient d’une topologie désagrégée de 16 GPU (quatre instances de prefill de deux GB200 chacune, une instance de decode de huit), et le débit plafonne autour d’une taille de batch de 64K. Le faire passer linéairement à une seule machine à huit GPU refroidie par air est exactement l’erreur que mes décotes sont là pour couvrir. ↩

9. Kimi K3 sur l’API de Moonshot coûte 3 $ le million de tokens d’entrée et 15 $ le million de sortie, avec des hits de cache à 0,30 $, tarif identique sur tout le contexte de 1M. Ces tarifs sont largement rapportés mais je n’ai pas pu les confirmer sur la page de tarifs de Moonshot elle-même, donc prends-les comme indicatifs. Avec le mélange de tokens de ce post, ça donne 1,20 $ le million contre 2,00 $ pour Opus 5. ↩

10. AWS, tarifs Bedrock. Les tarifs de débit provisionné publiés vont de 4,11 $ à 49,50 $ par unité de modèle et par heure et ne couvrent que des modèles anciens (Llama 2 à 21,18 $ pour un mois, Cohere Command à 49,50 $ pour un mois contre 23,77 $ pour six, Command Light de 8,56 $ à 4,11 $). Aucun modèle Claude actuel n’a de tarif provisionné publié. L’équivalent d’Azure est l’unité de débit provisionné, dont le fonctionnement est documenté sur Microsoft Learn, bien que la page ne donne aucun chiffre en dollars. Le seuil de rentabilité d’environ 80 % vient d’une analyse tierce, pas d’une recommandation de fournisseur, et aucune des deux plateformes ne publie un tel chiffre. ↩ ↩²

11. Le prix de rue d’un HGX B200 à 8 GPU tourne autour de 400 000 à 500 000 $ et j’ai modélisé 450 000 $ sur trois ans en amortissement linéaire sans valeur résiduelle. Prends-le comme mon hypothèse plutôt que comme une citation : les seules sources publiques sont des pages de contenu marketing de fournisseurs, sans auteur nommé et sans références primaires, dont l’une concède qu’il n’existe aucun marché secondaire fonctionnel pour vérifier. Si tu as un vrai devis, le tien l’emporte sur le mien. ↩

12. Les tarifs horaires publiés du B200 varient énormément selon le fournisseur et l’engagement, d’environ 2,14 $ à 27,04 $ par GPU-heure. Lambda affiche 4,99 $ et Spheron 3,70 $ à la demande contre 2,74 $ en spot, tandis qu’AWS p6 est à 14,24 $. getdeploying agrège plus de 26 fournisseurs. J’ai modélisé 5,50 $, qui se situe entre les tarifs des neoclouds et ceux des hyperscalers sans correspondre à aucun, donc prends-le comme une hypothèse de point médian, pas comme un devis. ↩

13. DESNZ, Quarterly Energy Prices, juin 2026, tableaux 3.4.1 à 3.4.2. Prix moyen pondéré par le volume de l’électricité non domestique de 24,14 p/kWh au T1 2026, provisoire, taxe sur le changement climatique incluse et TVA exclue. J’ai arrondi à 25 p, ce qui fait paraître les options auto-hébergées un peu moins bonnes plutôt que meilleures. Le PUE (power usage effectiveness) est le ratio entre la puissance totale de l’installation et la puissance qui arrive réellement aux équipements. ↩

14. Anthropic, Models overview. Opus 5 et Opus 4.8 sont tous deux listés à 5 $ le million de tokens d’entrée et 25 $ le million de tokens de sortie. ↩