L’essentiel en 5 points
- La contrainte qui décide de tout n’est pas le GPU, c’est la mémoire disponible et sa bande passante.
- La quantification fait tenir un modèle dans quatre fois moins de mémoire, avec une perte de qualité presque imperceptible en 4-bit et 8-bit.
- À chaque palier son usage réaliste : 8 Go pour l’assistance de code et l’extraction, 48 Go et plus pour une sensation proche du haut de gamme propriétaire.
- « Ça tient » et « c’est fluide » sont deux questions différentes : la capacité fait rentrer le modèle, la bande passante le rend agréable à utiliser.
- L’écosystème open source (Qwen, GLM, Kimi, Mistral, Gemma, DeepSeek, Llama) est désormais au niveau des modèles propriétaires pour une large part des usages.
La réponse rapide
Le bon modèle n’est pas le plus gros que vous puissiez télécharger, c’est le plus gros qui tient confortablement dans votre mémoire tout en laissant de la place au contexte. Pour estimer ce qui rentre, une règle simple suffit : un modèle quantifié en 4-bit occupe environ un demi-octet par paramètre. Un modèle de 7 milliards de paramètres pèse donc à peu près 4 Go, auxquels s’ajoutent le contexte et le système. C’est pour cela qu’un poste à 8 Go fait déjà tourner un assistant de code utile, tandis qu’une machine à 48 Go atteint une qualité que des praticiens décrivent comme proche du haut de gamme propriétaire.
Le reste de cet article détaille les paliers de mémoire, explique la quantification sans jargon, et distingue deux questions qu’on confond souvent : est-ce que le modèle tient, et est-ce qu’il est fluide.
Pourquoi la RAM décide de tout
Un modèle de langage est un gros paquet de nombres, ses paramètres. Pour générer du texte, la machine doit lire ces nombres à chaque étape. Deux propriétés matérielles comptent alors, et elles ne se confondent pas.
La première est la capacité : le modèle doit tenir en mémoire, sinon il ne se charge pas, ou il pagine depuis le disque et devient très lent. La seconde est la bande passante mémoire : la vitesse à laquelle la machine lit ces nombres, qui détermine le nombre de mots générés par seconde. Un Mac à mémoire unifiée doit sa réputation en inférence locale à cette bande passante élevée, pas à un GPU dédié.
Le GPU, justement, aide mais n’est pas indispensable. Des projets d’inférence en 1-bit permettent de faire tourner de très gros modèles sur un simple processeur, et l’écosystème Apple Silicon a rendu le Mac crédible comme plateforme d’inférence. La vraie question de dimensionnement reste donc la mémoire, pas la carte graphique.
La quantification, expliquée simplement
Par défaut, chaque paramètre d’un modèle est stocké avec une précision de 16 bits, soit 2 octets. Multipliez par plusieurs milliards de paramètres et l’empreinte mémoire devient vite hors de portée d’un poste de travail.
La quantification consiste à stocker ces mêmes paramètres avec moins de bits. En 8-bit, on divise l’empreinte par deux ; en 4-bit, par quatre. Un modèle qui réclamait 28 Go en pleine précision tient alors dans 7 Go environ. On perd un peu de finesse dans les nombres, mais pour la plupart des tâches professionnelles la différence est presque imperceptible jusqu’en 4-bit. En dessous, la qualité se dégrade nettement, sauf architectures conçues pour la basse précision.
L’implication pratique : ne raisonnez jamais sur la taille brute d’un modèle, raisonnez sur sa taille quantifiée. C’est elle qui décide de ce que votre machine peut accueillir.
Le guide par palier de mémoire
8 Go : l’assistance ciblée. Un modèle de 7 à 9 milliards de paramètres en 4-bit tient et laisse de la place au contexte. Les usages réalistes sont l’autocomplétion de code, l’extraction d’informations d’un document, la classification, le résumé et le tool-calling léger. Les petits modèles Qwen, Gemma et Llama sont taillés pour ce palier, et certains rivalisent avec des modèles bien plus gros sur des tâches ciblées.
16 Go : l’assistant généraliste. On monte vers 13 à 27 milliards de paramètres quantifiés. Le raisonnement devient correct, le RAG local sur vos documents fonctionne bien, et l’assistant tient une conversation de travail cohérente. C’est le palier d’entrée confortable pour un usage quotidien.
32 Go : le coding et le raisonnement sérieux. Des modèles de 30 à 70 milliards de paramètres quantifiés deviennent accessibles. C’est le palier où le coding agentique, le tool-calling fiable et le raisonnement multi-étapes tiennent la route. Les familles Kimi (orientée coding agentique), DeepSeek (raisonnement) et Mistral trouvent ici leur terrain.
48 Go et plus : la sensation haut de gamme. À ce niveau, un modèle large quantifié en 8-bit atteint une qualité que des praticiens décrivent comme proche du meilleur propriétaire, tool-calling compris. Les familles GLM et Qwen dans leurs grandes déclinaisons visent ce palier. C’est le seuil du poste de travail souverain, capable de traiter des dossiers sensibles sans jamais solliciter le cloud.
« Ça tient » n’est pas « c’est fluide »
C’est la confusion la plus fréquente. Un modèle de 35 milliards de paramètres se charge sur une machine à 16 Go en paginant depuis le disque : il tient, mais chaque mot se fait attendre. À l’inverse, le même modèle sur une machine à forte bande passante génère à une vitesse confortable.
La leçon de dimensionnement : ne visez pas la limite de capacité. Gardez de la marge pour le contexte et pour le confort de génération. Un modèle un cran en dessous du maximum théorique, mais fluide, sert mieux au quotidien qu’un modèle plus gros qui rame. Pour un poste de travail, la fluidité fait la différence entre un outil qu’on utilise et un outil qu’on abandonne.
Le cas d’usage entreprise : le poste de travail souverain
Le palier 48 Go ouvre un scénario que le cloud ne peut pas offrir : un poste où la donnée ne quitte jamais la machine. Pour une profession réglementée, un cabinet juridique, un acteur de la santé ou de la finance, c’est un argument qui dépasse le coût. Les contentieux récents autour du partage de données par des services d’IA en ligne rappellent que dès qu’une donnée quitte l’appareil, elle échappe au contrôle et peut fuiter par des canaux non prévus.
Un poste de travail souverain répond à cette exigence : le modèle tourne en local, les documents sensibles restent sur le device, et la conformité RGPD se raisonne à l’échelle d’une machine plutôt qu’à celle d’un fournisseur tiers. Le modèle frontière cloud reste disponible pour la petite fraction de requêtes qui le justifient, mais il n’est plus le passage obligé de tout le travail.
Par où commencer
Le bon point de départ n’est pas de télécharger le plus gros modèle possible, mais de partir de votre matériel et de vos usages. Mesurez la mémoire réellement disponible sur les postes concernés, identifiez les tâches à couvrir, puis choisissez le modèle quantifié le plus capable qui reste fluide sur ce matériel.
Colombani.ai forme les équipes techniques à cette démarche via la formation IA locale, vos données restent chez vous (choix de modèle par contrainte matérielle, quantification, environnement d’inférence local), certifiée Qualiopi et finançable OPCO. Pour dimensionner un parc de postes de travail souverains, Colombani.ai conçoit des architectures IA souveraines qui gardent vos données en Europe et sur vos machines. L’expertise mobilisée est certifiée par Anthropic (Claude Certified Architect).