GrevireDev / Mon IA locale coûtait 10,72× moins cher que l'API — jusqu'à ce que je recalcule correctement

Rédigé avec Mimo v2.5 et corrigé par Deepseek V4.1

Correction (26 octobre 2026). La première version de cet article affirmait que l’inférence locale coûtait 10,72× moins cher que l’API équivalente. Ce chiffre était faux : j’avais facturé chaque token d’entrée au tarif plein, en ignorant le cache, facturé environ dix fois moins et qui représente l’essentiel d’une charge d’agent. Recalculé correctement, l’écart est d’environ 2×, pas 10,72× — et une fois le GPU amorti, il disparaît complètement. Les chiffres corrigés sont ci-dessous, avec ce que j’ai raté et ce qui tient encore. Merci aux lecteurs de r/LocalLLM qui l’ont relevé.

TL;DR — J’ai mesuré ce que me coûte mon inférence IA locale sur 30 jours. À la prise murale : 12.38 CHF (~14,05 $) d’électricité. Facturé naïvement, le même volume de tokens aurait coûté 132.77 CHF (~150,71 $) via l’API — un facteur de 10,72×. Ce chiffre était faux. Avec le cache facturé correctement, l’équivalent API tombe plutôt autour de 28-34 $, donc l’écart réel est d’environ 2×. Face à un GPU à 1 135 $, ça ne s’amortit pas. L’IA locale n’est pas moins chère. C’est un autre achat.

Le déclic

Quand on parle d’IA locale, la première question est presque toujours : « quel GPU choisir ? »

J’ai posé cette question autrement : combien ça coûte vraiment, une fois que ça tourne ?

Pas le prix catalogue des composants. Pas les benchmarks de laboratoire. Juste la facture d’électricité en bout de mois, comparée à ce que j’aurais payé si j’étais resté sur une API cloud.

La réponse, mesurée au wattmètre sur 30 jours, m’a surpris. Puis il s’est avéré que j’avais mesuré le côté local honnêtement et le côté API avec négligence.

Ce que j’ai mesuré

Ma configuration : un processeur AMD, 32 Go de DDR4, SSD 1 To, et une Radeon RX 7900 XTX de 24 Go de VRAM. Une machine d’inférence dédiée, alimentée et monitorée à la prise murale pendant toute la période.

Sur une période de 30 jours (25 septembre – 25 octobre 2026) :

Ce que j’ai raté

Trois erreurs distinctes, toutes du côté API de la comparaison. La mesure locale, elle, était bonne.

1. J’ai ignoré le cache d’entrée. C’est la principale. J’ai multiplié les 964 millions de tokens d’entrée par le tarif plein de 0,15 $/M. Les fournisseurs facturent le cache autour de 0,016 $/M — environ dix fois moins — et sur une charge d’agent, 90 à 95 % de l’entrée est du cache, parce qu’un agent relit les mêmes fichiers et le même contexte de conversation en boucle.

Recalculé, en supposant 90 % et 95 % de cache :

Donc l’équivalent API est de 28-34 $, pas 151 $. Face aux 14,05 $ d’électricité, ça fait un facteur d’environ 2 — et à un taux de cache plus bas, disons 50 %, on remonte à environ 86 $, soit 6×. La fourchette honnête est de 2× à 6×, et la vraie valeur dépend d’un taux de cache que je n’ai pas mesuré.

2. Ma grille tarifaire ne correspondait pas au modèle utilisé. J’ai appliqué les tarifs de qwen3.8-flash à une charge qwen3.8-flash-next-coder. Ce sont deux variantes différentes. C’est un problème plus profond que n’importe quel débat sur la quantification, et ça veut dire que même le chiffre corrigé reste une approximation.

3. Le chiffre de consommation a besoin d’une séparation idle/inférence. 30,20 kWh sur 720 heures, c’est une moyenne continue de 41,9 W. Une machine avec une 7900 XTX ne tourne pas à 42 W au repos. Deux explications possibles : mon logging a des trous (reboots, wattmètre hors ligne, crash du logger), ou mon estimation du temps de travail réel est trop optimiste. Dans les deux cas, le total à la prise n’est pas automatiquement le coût de l’inférence — et pour une machine dédiée, ce n’est pas automatiquement pas le coût non plus, puisqu’il n’y a pas d’autre usage à soustraire. Il me faut la série idle séparée de la série inférence avant de citer à nouveau un chiffre mensuel.

4. L’argument de la chaleur ne s’applique pas à moi. Plusieurs lecteurs ont fait remarquer, à juste titre, que l’électricité devient de la chaleur, donc qu’en hiver le coût est partiellement récupéré. La physique est exacte. Mais j’habite en appartement et le rig est à la cave : il chauffe les communs, pas mon salon. La chaleur est réelle ; le crédit n’est pas pour moi. Le déménager à l’étage réglerait ça, et le bruit est la raison pour laquelle il n’a pas bougé.

Le mois de benchmark empire les choses, il ne les améliore pas

Il y a une quatrième nuance à préciser, parce qu’elle joue contre ma propre conclusion.

C’était un mois de R&D, pas un mois de production. Une part importante de ces 964 millions de tokens d’entrée vient du benchmarking : balayages à contexte élevé pour trouver le plafond de chaque modèle, tests de prefill et de décodage à 256k, des dizaines de modèles essayés puis jetés.

Ça compte pour le taux de cache, et pas dans le sens qui m’arrange. Un benchmark envoie un prompt neuf à chaque fois. Il n’y a pas de contexte répété à mettre en cache, donc le taux de cache d’un mois de benchmark est proche de zéro — précisément le scénario où le contrefactuel API est le plus cher. Mon calcul naïf n’était pas seulement arithmétiquement faux : il décrivait accidentellement la seule charge de travail où le local a l’air le meilleur.

En production, c’est l’inverse : un agent relit les mêmes fichiers de projet et la même conversation pendant des heures, donc le taux de cache monte et la facture API descend. Un mois de production, avec moins de tokens et un cache élevé, pourrait fort bien passer sous mon coût électrique. Je ne le sais pas encore, parce que je n’ai pas mesuré de mois de production — mais la direction est claire, et elle n’est pas en faveur du local.

Pourquoi le local a quand même du sens — mais pas sur le prix

Le ratio n’est pas spectaculaire. Il est d’environ 2× en coût marginal, et négatif dès qu’on compte le matériel. Voilà l’arithmétique qui compte :

Le GPU a coûté environ 1 000 CHF (~1 135 $). À un avantage marginal de 2× — environ 20 $/mois économisés — il faut environ 4,6 ans pour l’amortir sur la seule électricité. À 6×, c’est environ 15 mois. Aucun des deux chiffres n’inclut le reste de la machine, la dépréciation, ni le mois d’apprentissage.

Donc l’IA locale n’est pas moins chère. Cette affirmation ne survit pas aux chiffres corrigés, et je ne vais pas la défendre.

Ce qui survit, c’est tout ce que la facture d’électricité ne sait pas chiffrer :

• Les données ne quittent jamais la maison. Pas un argument marketing — une propriété de la configuration. Pour tout ce qui touche du code client, du contexte médical ou administratif, ou du travail sous NDA, c’est tout l’argument.
• La compréhension. Je sais maintenant ce que la quantification coûte vraiment en qualité, pourquoi le prefill et le décodage se comportent de façon complètement différente, où part le budget de cache KV, et pourquoi un modèle qui score bien peut être inutilisable dans un harness donné. Rien de tout ça ne s’évapore le jour où je retourne sur une API. Au contraire, ça fait de moi un meilleur utilisateur d’API, parce que je sais enfin quel bouton je paie.
• La couverture. Une stack locale qui fonctionne est une option sur un futur où les tarifs, la disponibilité ou les conditions des API changeraient. Cette option a de la valeur même quand elle ne s’autofinance pas ce mois-ci.

Ollama, llama.cpp et la courbe d’apprentissage

J’ai commencé par Ollama. C’est simple, propre, parfait pour tester rapidement des modèles. Mais dès qu’on veut sortir du catalogue, utiliser des modèles téléchargés depuis Hugging Face ou ajuster finement la quantification, on se heurte à des limites.

Je suis rapidement passé à llama.cpp. Plus de contrôle, plus de flexibilité, mais aussi plus de paramètres à comprendre. Quantification IQ1_M vs Q4_K_M, cache KV, nombre de couches GPU vs CPU, flash attention. Autant de notions qui n’existent pas quand on se contente d’appeler une API.

Sur AMD, il faut ajouter la couche de compatibilité : ROCm pour l’accélération GPU, une compatibilité qui progresse mais reste en retard sur l’écosystème CUDA. Certains outils, comme vLLM, sont tout simplement inaccessibles. Heureusement, llama.cpp gère très bien les GPU AMD.

La question taboue : est-ce que ça vaut le coup ?

Si vous êtes développeur et que vous voulez juste un assistant pour vous aider à coder, 12 Go de VRAM suffisent. Une RX 6750 XT fait très bien tourner un modèle de 9B avec un contexte raisonnable.

Si vous voulez des agents autonomes qui travaillent sur des projets entiers, avec des contextes de 100k à 260k tokens sans compaction constante, 24 Go sont le sweet spot.

Mais la vraie question n’est pas technique, et ce n’est pas non plus la facture d’électricité.

L’IA locale est un investissement de recherche et développement personnel. Elle n’est pas « clé en main ». Elle est chronophage, frustrante par moments, gratifiante à d’autres. C’est un chemin que l’on parcourt par curiosité, par conviction, ou par désir d’autonomie technologique — pas parce que c’est le moyen le plus rapide ou le moins cher d’avancer sur un projet. Sur le prix, elle n’est ni l’un ni l’autre.

Si votre objectif est d’accélérer un projet concret tout de suite, restez sur une API. Pour quelques CHF par mois sur des modèles Flash (GLM, DeepSeek, Qwen), vous avancez plus vite et vous dépensez moins.

Si votre objectif est de comprendre, de construire une infrastructure que vous maîtrisez, et d’être indépendant des fournisseurs cloud — alors l’investissement en temps et en matériel se justifie, mais justifiez-le sur ces bases. Pas sur le ratio.

Mes chiffres en toute transparence

Parce qu’un article sur le coût de l’IA locale qui ne montre pas ses données brutes n’a aucune valeur, voici l’essentiel — y compris ce qui est encore cassé :

• Période : 25 septembre – 25 octobre 2026 (30 jours glissants).
• Matériel : RX 7900 XTX, 24 Go VRAM, 32 Go DDR4. Machine d’inférence dédiée, allumée 24/7.
• Logiciels : llama.cpp, modèles au format GGUF, dashboard Grafana pour le suivi.
• Électricité : 30.20 kWh, tarif résidentiel suisse standard → 12.38 CHF (~14,05 $) au taux de 1,135 USD/CHF.
• Référence API : qwen3.8-flash, International, grille tarifaire Alibaba Cloud Model Studio, consultée en octobre 2026 — à noter l’incohérence avec le modèle qwen3.8-flash-next-coder réellement exécuté.
• Manques connus : séparation idle/inférence pas encore isolée ; taux de cache non mesuré ; grille tarifaire non alignée sur le modèle utilisé.

Ce que je corrige. Le dashboard du prochain mois exposera une série idle à côté de la série inférence, pour que le chiffre de consommation soit un delta et non un total à la prise. J’alignerai la grille tarifaire sur le modèle réellement utilisé, et je mesurerai le vrai taux de cache au lieu d’en supposer un. Ensuite je publierai une comparaison sur un mois de production, qui est le chiffre qui compte vraiment — ce mois de R&D n’est pas représentatif de l’usage quotidien.

Conclusion

L’inférence IA locale, à usage équivalent, coûte environ deux fois moins en coût marginal qu’une API cloud — pas onze fois. Matériel inclus, elle coûte plus cher. Le 10,72× d’origine était le produit d’un calcul d’API négligent, et il a fallu un fil de commentaires pour le trouver.

Mais réduire le coût de l’IA locale à sa facture d’électricité, c’est comme réduire le coût d’une voiture au prix de l’essence — sauf que cette fois, le carburant s’est révélé plus cher que je ne le pensais.

Est-ce que je regrette mes 1 000 CHF (~1 135 $) de GPU et mon mois de R&D ? Pas une seconde — mais pas parce que ça m’a fait économiser. Ça ne m’a rien fait économiser. Ça m’a acheté de la compréhension, une configuration que je maîtrise, et des données qui ne sont jamais sorties de la maison. C’étaient les vraies raisons depuis le début. Je les avais juste habillées d’un chiffre qui les flattait.

Toutes les métriques mentionnées proviennent d’un dashboard Grafana partagé (llama.cpp — Suivi mensuel des modèles). Les tarifs API sont ceux d’Alibaba Cloud Model Studio pour qwen3.8-flash en octobre 2026. Corrections après discussion sur r/LocalLLM, octobre 2026.