Téléchargeable ne signifie pas exploitable

Début août, des classements des meilleurs modèles d’IA open source circulent, dans lesquels un modèle se distingue en tête… alors que ses poids ne sont même pas encore publiés. Pour les responsables informatiques et les architectes cloud, cela soulève une question que nul fil d’actualité ne saurait trancher : comment décider si l’on opte pour une IA déployée en local ou non ?

Les points clés en bref

Articles associés :Soofi S : souverain ne signifie pas vainqueur  /  Inkling : ce que peut le nouveau modèle à poids ouverts

Le débat précède la disponibilité

Début août, Alibaba a présenté Qwen3.8-Max : 2 400 milliards de paramètres, dont 95 milliards actifs, une architecture Mixture-of-Experts et une fenêtre de contexte pouvant atteindre un million de tokens. En parallèle du modèle phare, un second checkpoint devrait être rendu public, Qwen3.8-27B. Pourtant, au moment de l’annonce, les poids des deux modèles n’étaient pas encore disponibles – l’entreprise évoquant une mise à disposition pour la semaine suivante.

Cela n’a pas empêché les classements ni les vidéos explicatives de les présenter comme déjà accessibles. Des experts de la communauté ont rectifié le tir, parfois avec fermeté. Pourtant, derrière cette situation se cache une tendance structurelle plutôt qu’une simple erreur isolée : annonce, tableau de benchmarks et évaluation communautaire se construisent en quelques heures, tandis que les poids, et surtout l’expérience opérationnelle, nécessitent des semaines.

Qui planifie ses achats sur ce rythme s’engage pour un modèle qui n’existe pas encore… ou qui ne démarrera jamais dans son propre réseau.

Des poids ouverts, mais verrouillés par le matériel

Une phrase tirée du débat résume parfaitement la situation et est devenue un adage : « Des poids ouverts, mais verrouillés par le matériel ». Lorsque l’exploitation nécessite des centaines de milliers de GPU, il ne s’agit plus d’un modèle local. C’est un modèle cloud avec des poids téléchargeables.

Les ordres de grandeur confirment cette analyse. Fin juillet, Moonshot a publié les poids de Kimi K3, soit 2,8 billions de paramètres pour un contexte d’un million de tokens. Dans la communauté, une liste de préparation à moitié sérieuse circule : il faudrait d’abord réunir un budget matériel à six chiffres élevés. L’objection réaliste, quant à elle, souligne que la plupart des modèles ouverts ne peuvent tout simplement pas être exécutés localement, faute de ressources suffisantes.

Il existe cependant des contre-exemples, impressionnants. Grâce à une quantification agressive en 1 bit, Kimi K3 passe d’environ 1,56 téraoctets à environ 594 gigaoctets, soit une réduction de plus de 60 %, tout en conservant environ 79 % de sa précision initiale. Cela fonctionne alors sur une station de travail bien équipée. Il s’agit toutefois d’un cas particulier : la perte de précision est réelle. La limite de mémoire est repoussée, mais elle ne disparaît pas.

Un calcul rapide permet de mieux appréhender ces dimensions. 2,4 billions de paramètres en 4 bits représentent environ 1,2 téraoctet rien que pour les poids. Une NVIDIA H200 dispose de 141 gigaoctets. Cela équivaut, en théorie, à neuf GPU avant même qu’un seul octet de cache KV ne soit alloué. Avec un contexte d’un million de tokens, ce cache devient substantiel. Ici, « local » signifie soit un centre de données personnel, soit un cluster loué, et non la station de travail au fond du couloir.

Ce sont les paramètres actifs qui pèsent sur la mémoire

Le point technique qui fait échouer les achats : avec les modèles Mixture-of-Experts (MoE), ce n’est pas le nombre de paramètres actifs qui détermine les besoins en mémoire. DeepSeek V4 Flash compte 13 milliards de paramètres actifs, mais charge l’intégralité de ses 284 milliards en mémoire. Qui lit « 13B actifs » et commande une carte de 16 gigaoctets se trompe d’un ordre de grandeur.

Ce schéma se répète dans la génération actuelle de modèles. Qwen3.8-Max : 2,4 billions au total, 95 milliards actifs. GLM-5.2 de Zhipu : 744 milliards au total, environ 40 milliards actifs, disponible sous licence MIT sur Hugging Face. DeepSeek V4 Pro : 1,6 billion au total, 49 milliards actifs, également sous MIT. Les paramètres actifs expliquent les coûts de calcul par token. Les besoins en mémoire, eux, dépendent de la taille totale.

Les mesures pratiques partagées par la communauté révèlent les limites réalistes. Il s’agit de valeurs individuelles, non de données constructeur, mais elles convergent : DeepSeek V4 Flash, avec un logiciel d’inférence optimisé, atteint près de 26 tokens par seconde sur une carte grand public de 24 gigaoctets, contre 3 tokens au départ. Sebastian Raschka indique que pour des modèles MoE de 30 milliards, on obtient environ 40 tokens par seconde sur un poste de travail bien équipé, et précise qu’un modèle de 118 milliards avec 8 milliards de paramètres actifs reste sous les 80 gigaoctets de RAM.

Quelques repères pratiques en quantification 4 bits : 7 milliards de paramètres nécessitent environ 8 gigaoctets, 14 milliards 12, la classe entre 24 et 32 milliards a besoin de 16 à 24, et un modèle de 70 milliards requiert au moins 40 gigaoctets. Ce sont là les tailles de travail pour un usage quotidien, et non les modèles qui font la une des journaux.

Ce qui était haut de gamme hier tourne aujourd’hui sur une seule carte graphique

La physique des mémoires n’est qu’une partie de l’histoire. L’autre, c’est la vitesse à laquelle cette limite recule. C’est d’ailleurs le vrai message pour la planification des infrastructures.

Un exemple avec des chiffres concrets : en avril 2026, Alibaba a lancé Qwen3.6-27B, un modèle dense de 27 milliards de paramètres fonctionnant sur une seule RTX 4090 ou un Mac doté de 24 Go de mémoire. Sur le benchmark SWE-bench Verified, l’un des plus exigeants pour le programming agentique, il atteint 77,2 %, devançant ainsi son propre modèle phare précédent de 397 milliards de paramètres, qui plafonnait à 76,2 %. Quinze fois plus petit, légèrement plus performant, et disponible trois mois et demi plus tôt. Ce qui nécessitait un data center au printemps tient désormais dans un poste de travail.

La pression vient des deux côtés. Et c’est une nouveauté. Les fournisseurs de modèles ouverts ont réagi en quelques semaines : Moonshot a libéré Kimi K3, son plus grand modèle open source à ce jour, tandis que DeepSeek et Zhipu ont placé leurs modèles phares sous licence MIT. Alibaba, quant à lui, ouvre pour la première fois sa classe de modèles la plus avancée avec Qwen3.8-Max. De l’autre côté, les acteurs des modèles fermés baissent leurs prix et publient des prises de position sur les poids ouverts, une démarche qu’ils jugeaient inutile il y a un an. Pour un exploitant, c’est une configuration rare : les deux camps travaillent actuellement sur la même courbe d’évolution.

Les prévisions vont dans le même sens. Gartner estime que l’inférence sur un modèle d’un billion de paramètres coûtera en 2030 plus de 90 % moins cher qu’en 2025, sous l’effet de semi-conducteurs et d’infrastructures plus efficaces, d’une meilleure conception des modèles, d’un taux d’utilisation des puces plus élevé, de matériel d’inférence spécialisé et de l’exécution locale pour des cas d’usage spécifiques. Par rapport aux modèles comparables de 2022, les analystes anticipent une efficacité coût jusqu’à cent fois supérieure. La part du traitement local devrait suivre une tendance similaire : plus des deux tiers des entreprises devraient exploiter l’IA en périphérie d’ici 2029, contre environ 10 % en 2025.

Un bémol s’impose. Gartner le souligne lui-même : ces économies ne se répercuteront pas intégralement sur les entreprises utilisatrices. Les applications agentiques consomment bien plus de tokens par tâche que la génération de texte classique, ce qui absorbe une partie significative de l’avantage tarifaire. Un coût par token réduit ne signifie pas automatiquement un coût par processus réduit.

Pour la planification, cela implique néanmoins une conclusion claire. Le tableau ci-dessous décrit un état de fait, pas une situation permanente : ses lignes descendent, mais en mois plutôt qu’en années. Quiconque définit une architecture aujourd’hui devrait intégrer l’inférence locale comme une part croissante de son paysage applicatif. La considérer comme une niche pour cas particuliers serait une erreur de calcul.

Où en est-on ?

Ce qui n’apparaît dans aucune spécification peut faire échouer un projet. La puissance électrique requise est le blocage silencieux le plus fréquent : une baie qui fait sauter le disjoncteur du bâtiment n’est pas un concept d’exploitation. La chaleur dégagée et le bruit représentent un obstacle architectural majeur dans un bureau sans salle serveur. Et les mises à jour de modèles déplacent les exigences vers le haut, comme dans un cas documenté où 10 Go de mémoire vidéo supplémentaire étaient nécessaires par rapport à la version précédente.

Les « Open Weights » ne sont pas l’Open Source

Les « Open Weights » signifient que les poids du modèle sont téléchargeables. Ce qui est autorisé ou non est précisé dans la licence. Les données d’entraînement, le code d’entraînement et la reproductibilité n’en font pas partie.

L’Open Source selon la définition de l’OSI (OSAID 1.0) exige en plus des informations sur les données : leur origine, leur volume, les méthodes d’acquisition et de sélection, l’étiquetage, le traitement, le filtrage. Selon ces critères, aucun modèle de pointe actuel n’est véritablement Open Source.

Le point de différenciation : GLM-5.2 et DeepSeek V4 Pro sont sous licence MIT, une licence OSI authentique. Pourtant, ils ne sont pas considérés comme de l’IA Open Source selon l’OSAID, faute de données d’entraînement. Une licence permissive sur les poids et une IA à code source ouvert sont deux choses distinctes.

Le règlement européen sur l’IA (AI Act) intervient de manière nuancée. Le considérant 104 exige, pour l’exception, des paramètres, poids, architecture et informations d’utilisation disponibles publiquement. Cependant, cette exception ne couvre que les obligations liées à la transparence. La synthèse des contenus d’entraînement et le respect du droit d’auteur restent obligatoires.

En une phrase pour les décideurs : les « Open Weights » n’éliminent pas le verrouillage propriétaire. Ils le déplacent simplement du fournisseur du modèle vers votre propre infrastructure, incluant la maintenance, la quantification, le monitoring et l’adaptation personnalisée.

Ce qui détermine réellement la décision

Ce n’est pas le nombre d’employés. Un expert-comptable avec douze collaborateurs manipule des données clients qui ne doivent pas quitter son système. Un groupe avec une norme Zero Trust en cloud reste hybride, même avec dix mille salariés. Le seuil se situe ailleurs :

1. Classe de données. Des données publiques et non critiques peuvent être envoyées vers une API. Des données personnelles, stratégiques ou confidentielles imposent une infrastructure interne.
2. Charge et prévisibilité. Une utilisation sporadique ne se calcule pas de la même façon qu’une charge continue. Le seuil de rentabilité pour l’auto-hébergement, comparé aux tarifs des API de modèles haut de gamme, se situe autour de 2 à 5 millions de tokens par jour sur douze mois. Face à des fournisseurs économiques de modèles ouverts, ce seuil passe à 50 millions de tokens par jour, voire plus.
3. Classe de modèle versus tâche. Un modèle de 27 milliards de paramètres avec RAG sur des documents internes suffit-il ? Ou la tâche nécessite-t-elle vraiment une qualité de pointe ? Beaucoup d’applications métiers se contentent d’un niveau fonctionnel, sans passer par un data center.
4. Maturité opérationnelle. Un stack d’inférence local nécessite 10 à 20 heures de maintenance par mois. Sans une équipe dédiée disponible 24h/24, un déploiement local reste un projet pilote avec une date d’expiration.
5. Latence et obligation de fonctionnement hors ligne. Les secteurs de la production, du terrain ou des réseaux isolés imposent la localisation, indépendamment du coût des tokens.
6. Puissance électrique, refroidissement et espace. Le coût brut des GPU ne représente que 30 à 40 % de l’investissement réel. En règle générale, il faut multiplier le prix du matériel par un facteur de 2,5 à 3. En production, le taux d’utilisation réel se situe entre 40 et 65 %, et non entre 80 et 90 % comme l’indiquent les présentations.
7. Réglementation et contrats. La gestion des données à caractère personnel, l’AI Act, les règles sectorielles et les contrats clients imposent des limites que aucun benchmark ne peut remplacer.

L’hybride est ainsi la norme : les tâches sensibles sont traitées localement ou dans un cloud privé, tandis que les usages généraux passent par une API, routés en fonction de la classe de données plutôt que de l’actualité.

Ce que vous devez en retenir

Les positions dans le débat sont clairement réparties. D’un côté, on souligne à juste titre que les modèles ouverts garantissent la transparence et permettent une exploitation sur matériel interne, sans transférer données et propriété intellectuelle à des fournisseurs fermés. De l’autre, les investisseurs en capital-risque estiment que les modèles haut de gamme sont surdimensionnés pour la majorité des cas d’usage. La partie adverse rétorque que beaucoup de ces modèles ne peuvent tout simplement pas fonctionner localement par manque de ressources. Chacun a raison, mais ils parlent de classes de modèles différentes.

Pour votre propre infrastructure, cela se traduit par trois étapes :

Premièrement : inventorier les cas d’usage selon la classe de données et la charge. Quelles requêtes peuvent quitter l’entreprise ? Quelles autres nécessitent une capacité hors ligne ou une latence fixe ? Sans cette liste, toute discussion sur le matériel relève de la spéculation.

Deuxièmement : lier la classe de modèle à la tâche, et non au titre accrocheur. Pour la recherche interne, les résumés et les Q&R sur documents, la classe entre 24 et 32 milliards de paramètres avec RAG suffit sur une seule GPU. La classe des billions reste en pratique du domaine des API, sauf à budgétiser et exploiter un cluster avec huit GPU ou plus par nœud.

Troisièmement : établir le calcul avec des facteurs réalistes. Matériel multiplié par 2,5 à 3, taux d’utilisation entre 40 et 65 %, 10 à 20 heures de fonctionnement par mois, seuil de rentabilité par rapport à la classe tarifaire réellement utilisée. Qui se contente de comparer le prix catalogue des GPU au coût par token construit un modèle qui ne résiste pas à l’épreuve du terrain.

Et quatrièmement, le point à l’impact le plus durable : concevoir l’architecture pour évoluer. Si un modèle, capable de tenir sur une seule carte graphique, atteint en un trimestre les performances d’un prédécesseur quinze fois plus grand, toute décision exclusive en faveur d’un fonctionnement par API revient à parier contre sa propre courbe de coûts. Cela ne signifie pas rapatrier aujourd’hui tout en interne. Cela implique de construire une abstraction qui laisse la porte ouverte au changement : des points de terminaison d’inférence interchangeables plutôt que des SDK fournisseurs figés, des cas d’évaluation propres plutôt que des benchmarks externes, ainsi qu’une classification des données qui sait déjà quels processus migreront en priorité vers l’interne.

La communauté continuera d’évaluer les modèles avant que les poids ne soient disponibles. C’est du bruit. Le signal sous-jacent, c’est la vitesse : l’écart entre la classe haut de gamme et les modèles exploitables localement se réduit en quelques mois. Téléchargeable reste une question de licence, exploitable une question d’infrastructure. Mais la réponse à la seconde question évolue désormais plus vite que la plupart des cycles d’approvisionnement.

Foire aux questions

Un modèle de 27 milliards de paramètres suffit-il pour des tâches professionnelles ?

Pour la recherche interne, les résumés, les Q&R sur documents et l’assistance au codage avec RAG sur vos propres documents, cette classe suffit dans de nombreux cas. Elle fonctionne sur une seule GPU de 16 à 32 Go. L’essentiel reste de mesurer les performances sur vos propres cas : ce qui arrive en tête dans un classement ne mène pas forcément dans votre contexte métier.

Pourquoi les plans matériels échouent-ils si souvent à cause des modèles Mixture-of-Experts ?

Le nombre de paramètres actifs indique les coûts de calcul par token, mais la mémoire nécessaire dépend de la taille totale. Un modèle avec 13 milliards de paramètres actifs peut charger 284 milliards en RAM. Qui se base sur le premier chiffre pour ses achats se trompe d’un ordre de grandeur.

À partir de quel volume l’hébergement en interne devient-il rentable par rapport à une API ?

Face aux prix des modèles haut de gamme, le seuil de rentabilité se situe autour de 2 à 5 millions de tokens par jour sur douze mois. Par rapport aux fournisseurs d’API de modèles ouverts bon marché, ce seuil passe à 50 millions ou plus, car ces derniers exploitent le même matériel avec un meilleur taux d’utilisation et des marges réduites. Ces deux valeurs ne valent qu’avec un taux d’utilisation réaliste.

Que signifie l’accélération du développement pour les achats en cours ?

La classe de modèle exploitable en local rattrape la classe haut de gamme en quelques mois. Une décision exclusive en faveur d’un fonctionnement par API, avec engagement pluriannuel et interfaces fournisseurs figées, affaiblit ainsi votre position de négociation. Une architecture avec des points de terminaison d’inférence interchangeables, qui maintient cette flexibilité, est donc judicieuse.

Nos conseils de lecture

• Soofi S : souverain ne signifie pas vainqueur
• Inkling : ce que peut le nouveau modèle à poids ouverts
• FP8, FP4 et vLLM : réduire les coûts GPU de l’inférence IA grâce à la quantification

Source de l’image : générée par IA (août 2026)