GPU local pour l'inférence IA : le calcul que personne ne fait

Vous en avez assez de payer 100, 200, 500 euros par mois en API pour vos agents IA. Un post Reddit vous a convaincu qu'un Mac Studio d'occasion ou une pile de RTX 3090 pouvait tout remplacer. Le raisonnement paraît imparable : on achète le matériel une fois, on fait tourner ses modèles gratuitement, et l'investissement se rembourse en quelques mois.

Sauf que ce raisonnement oublie la moitié de l'équation. Je vois passer chaque semaine des builds à 7 000, 15 000, voire 25 000 euros sur r/LocalLLaMA, montés par des passionnés qui découvrent ensuite que leurs tokens par seconde ne rivalisent pas avec un appel API à 0,002 dollar. Avant de sortir la carte bleue pour du hardware, voici le calcul complet.

Le fantasme du "zéro coût API"

L'argument est toujours le même sur les forums : « j'ai remplacé 100 euros par mois d'API par un Mac Studio à 2 000 euros, rentabilisé en 20 mois ». Un utilisateur de r/n8n a récemment posté un build complet autour d'un Mac Studio M1 Ultra acheté sur eBay pour 1 800 euros, faisant tourner Qwen 3.5 35B à 60 tokens par seconde. Sur le papier, c'est séduisant.

La communauté a vite déchanté. « You didn't save anything, you spent 1 800 euros », a répondu un commentaire à 55 upvotes. Le contexte du modèle était limité à 4 096 tokens (contre 128K+ en API), et la qualité du modèle local ne rivalise pas avec Gemini ou Claude sur les tâches complexes.

Pourquoi le calcul "hardware une fois, gratuit ensuite" est faux ?

Ce calcul ignore trois postes qui s'accumulent silencieusement. L'électricité d'abord : un build multi-GPU tire entre 300 et 900 watts en continu. Le temps d'administration ensuite : configurer llama.cpp, vLLM ou SGLang, gérer les mises à jour de modèles, debugger les problèmes CUDA. La dépréciation enfin : une RTX 3090 achetée aujourd'hui vaudra moitié prix dans 18 mois.

L'API n'est pas gratuite non plus, mais elle inclut tout ça dans son prix. Quand vous payez 0,003 dollar par 1 000 tokens en sortie chez Anthropic ou OpenAI, vous payez le datacenter, le refroidissement, l'optimisation continue du serving, et l'accès au dernier modèle sans changer de carte.

J'ai déjà détaillé cette économie cachée des LLM dans un article dédié. Le constat est le même : le coût visible (la facture API) masque un coût invisible bien plus élevé côté local.

Ce que coûte vraiment un setup GPU local

Les builds qui circulent sur r/LocalLLaMA donnent une photographie assez précise du marché en mai 2026. Voici ce que les gens montent réellement, avec les prix constatés.

Combien faut-il investir selon le niveau de performance visé ?

Le build le plus spectaculaire de ces dernières semaines vient d'un utilisateur qui a monté 8 Radeon 7900 XTX sur une carte mère grand public, avec un switch PCIe Gen4 x16 à 500 dollars trouvé sur AliExpress. Résultat : 192 Go de VRAM pour 6 500 euros environ, 437 tokens par seconde en traitement de prompt, et 27 en génération sur GLM 4.5 Air quantifié en Q6.

Ce sont des résultats impressionnants pour le prix. Mais 27 tokens par seconde en génération, c'est lent. Un utilisateur en commentaire l'a souligné : « That is not a great speed for 1 TB/s GPUs. You're missing an optimization somewhere. That model runs at 50 tok/s on a Mac laptop. »

À l'autre bout du spectre, une agence de design de 60 personnes a investi dans deux RTX Pro 6000 Blackwell (96 Go de VRAM chacune) pour 25 000 euros environ. La communauté r/ollama a réagi vertement : « $25K thrown out the gate with very little research done prior is wild. » Le consensus : utiliser vLLM plutôt qu'Ollama, passer à Linux, et oublier Llama 3.1 au profit de Qwen 3.5/3.6.

Performance locale vs API cloud : le fossé se creuse

Les chiffres bruts ne suffisent pas. Ce qui compte pour une utilisation professionnelle, c'est le combo vitesse de génération, taille de contexte et qualité du modèle.

Quelles sont les vraies limites de l'inférence locale ?

Le contexte est le point faible structurel du local. Le build Mac Studio mentionné plus haut plafonnait à 4 096 tokens de contexte, là où les API proposent 128K, voire 200K. « I'm out on reducing the tokens to 4 096 », a commenté un utilisateur de r/n8n. Pour des agents IA qui doivent traiter des documents longs ou maintenir une conversation complexe, c'est éliminatoire.

Des solutions émergent pour repousser cette limite. Le projet kvcached (open source, compatible SGLang et vLLM) permet de libérer la mémoire GPU occupée par le KV cache entre les requêtes, autorisant plusieurs modèles sur un même GPU. TurboQuant promet une compression 6x du KV cache sans perte de qualité, ce qui revient à multiplier par 6 la fenêtre de contexte pour un même budget mémoire.

Ces optimisations sont prometteuses. Mais un commentaire sur r/OpenSourceeAI tempère : « TurboQuant doesn't lower the max VRAM need at all, it actually increases it. It only lowers KV cache size for decode phase, not pre-fill. » Autrement dit, la promesse marketing dépasse la réalité technique.

Le vrai problème reste la qualité du modèle. Les meilleurs modèles open-weight (Qwen 3.5, DeepSeek R1, GLM 4.5) sont excellents. Mais ils tournent à pleine capacité uniquement en FP16 non quantifié, ce qui demande une VRAM colossale. DeepSeek R1 en Q4_K_M pèse 404 Go rien que pour les poids : il faudrait 17 RTX 3090 pour le charger entièrement en GPU. Un utilisateur de r/LocalLLaMA résume bien la situation : les modèles MoE (Mixture of Experts) progressent vite, mais les solutions hardware pour les faire tourner « none of them seem particularly appealing ».

Selon le World Economic Forum, l'infrastructure IA reste un des principaux goulots d'étranglement pour l'adoption en entreprise, et ce constat s'applique tout autant à l'inférence locale qu'au cloud.

Quand l'inférence GPU locale fait vraiment sens

Je ne dis pas que le local est toujours une mauvaise idée. Il existe trois cas où le calcul penche clairement en faveur du hardware dédié.

Dans quelles situations le GPU local devient-il rentable ?

La confidentialité absolue. Si vos données ne doivent jamais quitter votre réseau (santé, juridique, défense), le local n'est pas un choix économique : c'est une contrainte réglementaire. L'utilisateur qui a monté son système « Trinity » sur Mac Studio le dit lui-même : « For a system I wanted to deploy to privacy-conscious clients, that's a dealbreaker. »

Le volume massif et prévisible. Une agence qui traite 500 000 tokens par jour sur le même modèle, tous les jours, finira par rentabiliser un build à 7 000 euros. Le seuil de rentabilité se situe autour de 300 à 500 euros de consommation API mensuelle, selon le build choisi et le coût électrique local.

L'expérimentation et le fine-tuning. Les chercheurs et développeurs qui testent des architectures, quantifient des modèles ou entraînent des adaptateurs LoRA ont besoin d'un accès direct au GPU. Les API ne permettent pas ce niveau de contrôle.

Pour une PME qui utilise l'IA pour automatiser des emails, alimenter un CRM ou générer du contenu, aucun de ces trois cas ne s'applique. J'ai accompagné des dizaines de PME dans leur intégration IA : pas une seule n'avait besoin de monter un serveur GPU. Toutes avaient besoin d'un workflow bien connecté à leurs outils existants.

Mon verdict : l'API reste le bon calcul pour 95 % des PME

« La vraie valeur n'est pas dans le modèle ni dans le GPU. Elle est dans l'intégration avec vos process métier. »

Vincent, mai 2026

Je vois trop de dirigeants fascinés par l'idée de « posséder » leur IA. C'est compréhensible : la dépendance à un fournisseur cloud crée de l'inconfort. Mais posséder un GPU ne vous donne pas un avantage concurrentiel. Ce qui vous donne un avantage, c'est un agent IA qui lit vos emails, met à jour votre CRM, et prépare vos devis pendant que vous dormez.

Faut-il ignorer complètement l'inférence locale ?

Non. Le mouvement open-weight est une excellente nouvelle pour tout l'écosystème. Des projets comme OpenClaw avec Ollama montrent qu'on peut construire des stacks locales fonctionnelles. Mais fonctionnel ne veut pas dire optimal pour votre business.

Un build GPU local à 7 000 euros qui génère 27 tokens par seconde avec un contexte limité ne remplace pas un appel API à 0,003 dollar qui vous donne 100+ tokens par seconde, 200K de contexte, et le dernier modèle sans rien changer à votre code. Le calcul est vite fait.

Ma recommandation concrète : gardez vos budgets pour l'intégration, pas pour le hardware. C'est d'ailleurs ce qu'on observe aussi côté développement logiciel sur GoLive Software : les entreprises qui progressent le plus vite investissent dans les workflows, pas dans l'infrastructure. Et si votre facture API dépasse 500 euros par mois, là seulement, commencez à regarder les options hybrides (GPU pour les tâches récurrentes à haut volume, API pour le reste).