La promesse des 16 Go dépend du type de mémoire
L’IA locale a gagné une option plus ambitieuse en juin 2026. Google a lancé Gemma 4 12B, capable de recevoir du texte, des images et de l’audio, en indiquant qu’il pouvait tourner sur un portable doté de 16 Go de VRAM dédiée ou de mémoire unifiée.
La précision change le verdict. Un Mac Apple Silicon partage sa mémoire entre CPU et GPU. Un portable de jeu sépare RAM système et VRAM. Une machine fine avec circuit graphique intégré réserve une partie de la RAM. Ces trois appareils peuvent afficher 16 Go, sans offrir le même budget au modèle.
Le guide publié le 3 juin mentionne 16 Go de VRAM ou de mémoire unifiée. Un Mac avec 16 Go unifiés ou un GPU disposant de 16 Go peut accueillir un 12B quantifié dans de bonnes conditions. Sous Windows, avec 16 Go de RAM et 4 Go de VRAM, un modèle plus petit constitue un départ plus raisonnable.
Le progrès reste concret. Un portable peut résumer des documents privés, examiner des images, traiter de l’audio, écrire du code et servir une API locale sans transmettre chaque prompt à un fournisseur. Il faut surtout savoir ce qui restera au système, au contexte et à l’application.
Ce qui tient vraiment dans 16 Go
Le nombre de paramètres ne donne pas directement la mémoire requise. La précision fixe une base ; le runtime, l’architecture et le contexte ajoutent leurs allocations.
Google publie ces estimations pour Gemma 4. Elles incluent 20 % de marge pour le chargement de composants, mais excluent le logiciel et le contexte.
| Variante Gemma 4 | Q4_0 | SFP8 | BF16 | Lecture pratique sur 16 Go |
|---|---|---|---|---|
| E2B | 2,9 Go | 5,7 Go | 11,4 Go | Départ confortable |
| E4B | 4,5 Go | 8,9 Go | 17,9 Go | Q4 laisse une marge utile |
| 12B | 6,7 Go | 13,4 Go | 26,7 Go | Q4 est le choix raisonnable |
| 26B A4B | 14,4 Go | 28,8 Go | 57,7 Go | Trop serré avec contexte et apps |
| 31B | 17,5 Go | 34,9 Go | 69,9 Go | La base dépasse 16 Go |
Q4 stocke les poids avec moins de bits. La consommation baisse, avec un risque de perte de qualité. Les checkpoints officiels entraînés pour la quantification cherchent à limiter cet écart.
La taille téléchargée mesure autre chose. Au 31 juillet 2026, la bibliothèque Gemma 4 d’Ollama affichait 7,2 Go pour le paquet 12B QAT et 7,6 Go pour Q4_K_M. Le fichier sur disque ne couvre pas toute la mémoire de travail.
Le contexte ajoute un cache KV. Même si le modèle annonce 256K au maximum, Google exclut ce cache du tableau. Ollama choisit 4K par défaut sous 24 Gio de VRAM et prévient qu’un contexte supérieur consomme davantage. Sur 16 Go, commencez par 4K ou 8K.
- E4B Q4 convient lorsque la marge système et le multitâche comptent.
- 12B Q4 vise les 16 Go unifiés ou 16 Go de VRAM lorsque la tâche demande plus de capacité.
- 26B A4B Q4 consomme déjà environ 14,4 Go avant contexte et système ; l’équilibre est mauvais.
- 12B SFP8, estimé à 13,4 Go, exige un environnement étroitement contrôlé.
Choisissez le runtime avant de télécharger le modèle
Le modèle détermine les capacités. Le runtime détermine l’installation, la lecture de la mémoire et l’intégration.
| Runtime | Usage adapté | Matériel | Limite |
|---|---|---|---|
| LM Studio | Interface, documents et API locale | Recommande 16 Go ; Apple Silicon, Windows et Linux | Catalogue et téléchargements nécessitent Internet |
| Ollama | Terminal, service local, intégrations | Metal, Nvidia, AMD et Vulkan documentés | Contexte et choix local/cloud à surveiller |
| llama.cpp | Contrôle de GGUF et des paramètres | Metal sur Apple Silicon et nombreux backends | Plus de configuration |
| MLX | Développement centré sur Apple | CPU et GPU partagent la mémoire | Écosystème plus ciblé |
| LiteRT-LM | Intégrations Gemma récentes | Serveur local compatible API OpenAI | Choix de modèles plus étroit |
Les prérequis de LM Studio recommandent 16 Go sur Apple Silicon ; sous Windows, 16 Go de RAM et 4 Go de VRAM. Ils ne garantissent pas toute combinaison de modèle et de contexte. L’interface simplifie toutefois le test de chargement.
Ollama s’intègre bien comme endpoint local. Le service écoute 127.0.0.1:11434 par défaut et ollama ps indique si le modèle réside sur GPU, CPU ou les deux. Un partage peut permettre le chargement tout en dégradant le temps de réponse.
llama.cpp donne un contrôle direct sur GGUF, la quantification et les backends. MLX exploite la mémoire unifiée d’Apple Silicon. Dans les deux cas, il faut encore choisir le contexte et vérifier la qualité.
Une première configuration prudente
Le premier essai doit mesurer l’adéquation de la machine.
- Identifiez la mémoire. Sur Apple Silicon, relevez la mémoire unifiée ; sous Windows et Linux, séparez RAM et VRAM.
- Installez un runtime. LM Studio pour l’interface, Ollama pour le terminal et l’API.
- Commencez par un Q4 officiel. E4B garde plus de marge ; passez au 12B lorsqu’une tâche définie le demande.
- Réglez le contexte sur 4K–8K. Le maximum annoncé n’est pas une cible.
- Fermez les logiciels lourds. Navigateur, IDE, jeux et création consomment la même réserve.
- Testez trois tâches réelles. Un prompt court, un document ou une image, puis le cas quotidien le plus long.
- Contrôlez l’allocation. Utilisez
ollama psou l’état de chargement de LM Studio. - Modifiez une variable à la fois. Augmentez séparément contexte, précision et taille.
ollama run gemma4:12b
ollama ps
Vérifiez le tag, la taille, les entrées et la quantification avant le téléchargement. Comparez aussi les outils de développement IA.
Local ne veut pas dire privé ou open source par défaut
L’inférence sur l’appareil améliore le contrôle. LM Studio indique que les modèles téléchargés, les documents et le serveur local peuvent fonctionner hors ligne. Ollama affirme ne pas voir les prompts des modèles exécutés localement.
Cette limite comporte plusieurs ouvertures :
- recherche, téléchargements et mises à jour utilisent Internet ;
- un modèle cloud transmet la requête au fournisseur ;
- recherche web, plugins, MCP et outils externes créent leurs connexions ;
- une API ouverte au-delà du loopback devient un service réseau ;
- historiques, journaux, embeddings et poids restent à protéger sur le disque.
Ollama peut couper ses fonctions cloud avec OLLAMA_NO_CLOUD=1 et se limite au loopback par défaut. Ces contrôles sont vérifiables. Le mot « local » ne remplace pas une politique de sécurité.
Google qualifie Gemma 4 de modèle à poids ouverts et autorise un usage commercial responsable. Les conditions Gemma conservent des restrictions d’usage et des obligations de distribution. Télécharger les poids ne crée pas automatiquement une licence logicielle open source classique.
La décision entre local, cloud et hybride
L’IA locale convient aux documents qui doivent rester sur un appareil contrôlé, aux connexions incertaines, à un usage fréquent et aux tâches à contexte limité. Un portable à mémoire unifiée de 16 Go avec E4B Q4 ou 12B Q4 couvre désormais une part réelle de ces besoins.
Le cloud reste préférable pour les plus grands modèles, les contextes longs, la charge partagée et les équipes qui ne veulent pas maintenir de runtimes.
| Besoin | Choix initial |
|---|---|
| Notes privées, documents hors ligne, prototypes | Local |
| Grands modèles, recherche longue, capacité partagée | Cloud |
| Prétraitement sensible puis raisonnement difficile | Hybride |
| Matériel incertain | E4B Q4 local avec repli cloud |
L’hybride offre souvent le bon compromis : résumer ou retirer les données sensibles sur le portable, puis envoyer uniquement le contexte nécessaire à un modèle hébergé. Les 16 Go prennent ainsi en charge la partie où le contrôle local compte.
Commencez avec une tâche bornée et un modèle Q4. Si la machine reste réactive à 4K–8K et que la réponse suffit, conservez ce flux. Si le besoin exige d’emblée 256K, un modèle plus grand ou plusieurs utilisateurs, placez cette charge dans le cloud. Les guides des outils pour développeurs complètent le choix.
