Déployer une IA en local : possible pour presque toutes les entreprises, nécessaire pour presque aucune
Je vois passer depuis quelques semaines une confusion qui coûte cher à ceux qui la font : « le modèle est open source, donc on peut l'héberger nous-mêmes, donc ça ne coûte rien ». Les trois propositions sont vraies séparément et fausses une fois mises ensemble. Ce qui est gratuit, ce sont les poids du modèle. Le fichier. Tout le reste, vous le payez au prix fort.
Kimi K3 en est le cas d'école. Moonshot publie un modèle de 2 800 milliards de paramètres, dont environ 104 milliards actifs à chaque passage, quantifié nativement en MXFP4, avec une fenêtre de contexte d'un million de tokens. Vous pouvez le télécharger cet après-midi. Vous ne pourrez pas le faire tourner. Parce qu'un modèle à experts n'active qu'une fraction de ses paramètres à un instant donné, 16 experts sur 896 dans ce cas, mais doit garder l'intégralité de ses experts en mémoire pour pouvoir router vers n'importe lequel au token suivant. Poids, runtime et activations compris, on arrive autour de 1,8 To de VRAM.
Coût réel du déploiement IA en local : ce que 1,8 To de VRAM veut dire en argent
Les ordres de grandeur qui suivent viennent de l'infographie qui a déclenché cet article, je les reprends comme tels et pas comme des chiffres que j'aurais mesurés moi-même. Ils sont cohérents avec ce que je vois côté marché.
Le plancher matériel, c'est 8 accélérateurs B300 ou GB300, soit environ 2,3 To de VRAM. C'est un minimum, pas une configuration confortable : dès que vous voulez du contexte long ou du batch, il faut passer à 16 B200, autour de 3 To. Une production sérieuse, c'est 64 accélérateurs ou plus. En achat, réseau, stockage et refroidissement inclus, comptez 800 000 $ à 1,5 M$ pour un cluster confortable. En location cloud, 16 B200 tournent entre 80 et 120 $ de l'heure, soit 60 000 à 90 000 $ par mois en continu, hors ingénierie et hors stockage.
Cette dernière précision est celle que les DSI oublient systématiquement. Le NVMe, l'électricité, le refroidissement, le monitoring, la redondance et surtout les gens capables de tenir la pile vLLM en production ne sont dans aucun de ces chiffres. Sur les projets que j'ai vus, l'ingénierie représente le poste qui dérape, pas le matériel.
La grille de décision IA locale contre API cloud, et ce qu'elle rate
La grille de décision qui circule tient en trois lignes, et elle est juste dans les grandes largeurs. Faible utilisation, PME, prototypes : API cloud, pas d'infra, paiement à la consommation. Utilisation intermédiaire, équipes internes, RAG métier : des modèles plus petits, 7 à 70 milliards de paramètres, sur GPU dédiés. Très forte utilisation, des millions de requêtes par jour : le self-hosting de gros modèles peut devenir rentable, avec une équipe infra spécialisée.
Mon reproche à cette grille, c'est qu'elle oppose deux mondes qui ne communiquent pas. D'un côté des modèles de 7 à 70 milliards de paramètres sur une ou deux cartes professionnelles, à quelques milliers d'euros pièce. De l'autre un cluster à un million de dollars. Entre les deux, rien. Et c'est précisément entre les deux que la situation a bougé en 2026.
Le palier oublié entre API et cluster : deux DGX Spark pour 9 400 dollars
Un dépôt GitHub sous licence MIT documente le déploiement de DeepSeek V4 Flash sur deux unités DGX Spark, en tensor parallelism 2, avec cache KV en NVFP4 et décodage spéculatif. Contexte calibré à 1 048 576 tokens, le dépôt insiste d'ailleurs sur le fait que le million est le plafond réel et pas les 1,5 M annoncés ailleurs. Débit de pointe autour de 84 tokens par seconde. La version officielle de DeepSeek V4 Flash, publiée le 31 juillet 2026, pèse 284 milliards de paramètres dont 13 milliards actifs, sous licence MIT : dix fois moins de paramètres totaux que Kimi K3, et huit fois moins de paramètres actifs. C'est cet écart d'échelle, pas une prouesse d'optimisation particulière, qui explique que l'un tienne sur deux DGX Spark quand l'autre ne tiendra jamais.
Le DGX Spark est un poste de travail, pas un rack. NVIDIA l'a lancé à 3 999 $ et a relevé le tarif de la Founders Edition à 4 699 $ fin février 2026, en invoquant les tensions sur l'approvisionnement mémoire. Deux unités, c'est donc environ 9 400 $ de matériel, hors réseau, stockage et ingénierie. Face aux 800 000 $ de la case « gros modèle auto-hébergé », le rapport est de un à cent.
Ce palier à 9 400 $ n'est d'ailleurs plus le plancher. Depuis, le moteur d'inférence FreeToken, issu de Berkeley et de UT Austin, a fait tourner un modèle MoE de 35 milliards de paramètres sur une carte grand public de 8 Go de VRAM, du matériel qu'une partie des entreprises possède déjà. Ça ne change rien au calcul de rentabilité pour les modèles de classe frontière comme Kimi K3, la mémoire nécessaire pour eux ne bouge pas. Mais ça ajoute un échelon sous celui des deux DGX Spark pour les modèles plus modestes, et ça confirme que ce terrain intermédiaire continue de se remplir plus vite que la grille de décision classique ne l'anticipe.
Il faut être précis sur ce que ce palier permet et ne permet pas, sinon on raconte n'importe quoi. Deux DGX Spark, c'est 256 Go de mémoire unifiée. Kimi K3 et ses 1,8 To n'y tiennent pas, et n'y tiendront jamais. Ce qui tient, c'est un modèle de classe Flash, qui doit loger ses poids, son cache KV au contexte maximal et son runtime dans ces 256 Go. Le fait que Kimi K3 ou DeepSeek soient publiés en open weight est ce qui rend l'exercice possible, un modèle fermé ne se déploie nulle part, mais ça ne dit rien sur la faisabilité matérielle, qui reste dictée par la mémoire disponible.
Second garde-fou, la vitesse. Le DGX Spark embarque 128 Go de mémoire unifiée à 273 Go/s en LPDDR5x, et l'équipe LMSYS écrit noir sur blanc que cette bande passante limitée est le goulot d'étranglement principal en inférence. Le dépôt lui-même est honnête : en trafic d'agents réaliste, on tombe à environ 22 tokens par seconde par flux à quatre requêtes simultanées, le profil validé plafonne à six séquences concurrentes, les premières requêtes après démarrage sont 30 % plus lentes, et sans le correctif prévu pour les poids officiels le débit est divisé par deux.
Autrement dit : ce palier sert une poignée d'utilisateurs simultanés, pas deux cents collaborateurs en interactif. C'est un étage prototypage, traitement par lots et souveraineté des données, pas un étage production grand public. Mais il existe, il coûte le prix de deux ordinateurs haut de gamme, et il fait tourner des modèles de 2026, pas des Llama de 2023.
Ce n'est pas propre à Kimi K3. Qwen 3.8 Max, sorti début août 2026 chez Alibaba, pèse 2,4 T de paramètres dont 95 milliards actifs, un ordre de grandeur identique. La génération actuelle de modèles de frontière, chinois comme américains, se range dans deux catégories très distinctes : quelques centaines de milliards de paramètres actifs pour les modèles qui visent la frontière, une dizaine de milliards pour ceux qui visent le déploiement large. Il n'y a pas d'entre-deux côté modèle, seulement côté matériel. Sur le terrain du matériel justement, une autre piste mérite d'être suivie : l'inférence en 1-bit de BitNet attaque directement le goulot de bande passante mémoire qui limite ces déploiements, mais reste pour l'instant cantonnée à des modèles de quelques milliards de paramètres, loin de la classe Kimi K3 ou DeepSeek V4.
Rentabilité IA locale contre API : le calcul de seuil que personne ne pose
Voici l'arithmétique que je refais avec chaque client qui me parle d'auto-hébergement. Elle est simple et elle tranche à peu près tous les débats.
Côté API, Kimi K3 est facturé 2,90 $ le million de tokens en entrée et 14 $ le million en sortie selon les tarifs OpenRouter que j'ai relevés. Petite mise au point au passage : le tarif de 0,30 $ que je citais dans mon article sur la bascule géopolitique de l'IA correspond au tarif des tokens déjà en cache côté Moonshot, pas au tarif d'entrée standard. Les deux chiffres sont exacts, ils ne mesurent pas la même chose.
Prenons un usage RAG typique, avec un ratio de dix tokens d'entrée pour un token de sortie. Le coût moyen ressort à environ 3,90 $ le million de tokens tout compris. Face à un cluster loué 60 000 à 90 000 $ par mois, le point de bascule se situe entre 15 et 23 milliards de tokens mensuels, soit grossièrement 500 à 750 millions de tokens par jour.
Traduit en usage humain, avec un collaborateur intensif qui consomme 30 échanges par jour à 5 500 tokens l'échange : il faut entre 3 000 et 4 500 utilisateurs quotidiens lourds pour que le cluster loué batte l'API. Et je suis généreux à chaque étape, puisque je n'ai compté ni l'ingénierie, ni le stockage, ni la mise en cache côté API qui ferait encore reculer le seuil. Ce calcul suppose surtout un cluster utilisé à pleine charge en permanence : s'il ne parvient pas à débiter ces 750 millions de tokens quotidiens, il faut en louer davantage, et le seuil s'éloigne encore.
Aucune PME française n'atteint ce volume. Très peu d'ETI l'atteignent. La conclusion est donc nette : sur le seul critère du coût, auto-héberger un modèle de classe frontière ne se rentabilise jamais pour l'immense majorité des entreprises françaises. Ce n'est pas une question de maturité technique, c'est une question d'arithmétique.
Souveraineté des données et IA locale : pour qui ça a du sens, pour qui c'est un piège
Le local a du sens dans trois cas, et le coût n'en fait pas partie.
Premier cas, la sensibilité des données. Données de santé, secret industriel, dossiers d'instruction, sous-traitance de défense : si la donnée ne peut pas sortir, la question du prix ne se pose plus, elle est remplacée par une contrainte. Deuxième cas, la contrainte réglementaire ou contractuelle, quand un client final ou un régulateur impose la localisation du traitement. Troisième cas, le volume prévisible en traitement par lots, typiquement de l'indexation ou de l'enrichissement documentaire nocturne, où la latence n'importe pas et où le matériel tourne à pleine charge 24 heures sur 24 au lieu de rester à 5 % d'utilisation.
C'est un piège dans deux configurations que je vois trop souvent. La première, l'entreprise qui veut du local pour ne pas dépendre d'un fournisseur, et qui échange une dépendance contractuelle contre une dépendance à deux ou trois ingénieurs qui partiront. La seconde, celle qui projette un usage massif à dix-huit mois et dimensionne pour cet usage : elle achète aujourd'hui du matériel qui aura perdu la moitié de sa valeur quand le volume arrivera, si tant est qu'il arrive.
Déployer une IA en local : la séquence de décision pour un dirigeant ou un consultant
Pour un dirigeant, la séquence est courte. Mesurez d'abord votre consommation réelle en tokens sur trois mois d'API, pas votre consommation imaginée. Classez ensuite vos cas d'usage par sensibilité de données, parce que c'est le seul critère qui peut justifier un surcoût d'un facteur dix. Comptez enfin le coût humain : si vous n'avez pas déjà en interne quelqu'un capable de diagnostiquer une régression de débit sur vLLM un vendredi soir, vous n'avez pas d'option locale, vous avez un projet de recrutement.
Pour un consultant, la valeur ajoutée n'est pas de connaître les références des cartes. Elle est de refuser la question telle qu'elle est posée. Quand un client demande « est-ce qu'on peut héberger un modèle en interne », la réponse utile n'est pas oui ou non, c'est le calcul de seuil ci-dessus fait avec ses chiffres à lui, en séparant explicitement ce qui relève du coût de ce qui relève de la conformité. Le palier à deux DGX Spark est l'outil qui manquait pour cette conversation : il permet de proposer un pilote souverain réel à 10 000 $ plutôt qu'un refus sec ou un devis à sept chiffres. Et il transforme un débat idéologique sur la souveraineté en un arbitrage chiffré, ce qui est exactement le terrain où un conseil se défend.
Sources : NVIDIA Developer Forums, annonce de changement de prix du DGX Spark ; LMSYS, NVIDIA DGX Spark In-Depth Review ; Dépôt GitHub DeepSeek V4 Flash sur 2× DGX Spark ; OpenRouter, tarifs de l'API Kimi K3 ; Caixin Global, sortie officielle de DeepSeek V4 Flash ; MarkTechPost, lancement de Qwen3.8-Max.
Pour aller plus loin : Frontière, open source, open weight, fermé : ce que ces mots veulent vraiment dire en IA et Kimi K3, Xi Jinping à Shanghai : la bascule géopolitique de l'IA que la France ne peut plus ignorer
Questions fréquentes
Peut-on faire tourner Kimi K3 sur du matériel abordable ?
Non. Kimi K3 demande environ 1,8 To de VRAM, selon les ordres de grandeur qui circulent, parce que l'intégralité de ses 896 experts doit rester en mémoire, même si 16 seulement sont actifs à un instant donné. Le plancher matériel est de 8 accélérateurs B300 ou GB300. Ce qui devient abordable, ce sont des modèles récents mais nettement plus légers, de classe DeepSeek V4 Flash, qui tiennent sur deux DGX Spark à environ 9 400 $ de matériel.
À partir de quel volume l'auto-hébergement devient-il moins cher qu'une API ?
Selon mon calcul, en comparant un cluster loué 60 000 à 90 000 $ par mois aux tarifs API de Kimi K3 sur un ratio de dix tokens d'entrée pour un de sortie, le seuil se situe autour de 500 à 750 millions de tokens par jour, soit l'équivalent de 3 000 à 4 500 utilisateurs internes intensifs. Hors coût d'ingénierie, qui repousse encore ce seuil.
Un modèle open weight garantit-il la souveraineté des données ?
Il la rend possible, pas automatique. Un modèle fermé ne peut pas être déployé chez vous, donc l'open weight est une condition nécessaire. Mais la souveraineté dépend ensuite de l'endroit où tourne réellement l'inférence, de qui administre la machine et de ce que vous journalisez. Un modèle open weight consommé via une API tierce n'apporte aucune garantie supplémentaire sur ce plan.
Découvre mes outils

À propos de l'auteur
Delivery Manager à Rennes. Je pilote des projets de transformation digitale, SEO/GEO et accessibilité RGAA pour des clients grands comptes. Ce blog est le reflet de ce que je rencontre sur le terrain.