Passer au contenu principal
Chaque modèle local a besoin de suffisamment de mémoire pour contenir ses poids, son cache KV et une certaine marge de travail — et lorsqu’il ne tient pas entièrement dans la VRAM, le délestage décide ce qui s’exécute rapidement sur le GPU par rapport à ce qui s’exécute lentement sur le CPU. Cette page couvre la théorie du dimensionnement et la mécanique du délestage ; pour des tableaux de VRAM prêts à l’emploi par GPU et taille de modèle, consultez le guide d’ajustement des modèles GPU — cette page ne répétera pas ces tableaux.

​
La formule de dimensionnement

Les poids du modèle occupent un nombre fixe d’octets par paramètre, défini par la précision : GGUF Q4_K_M est une précision mixte et moyenne environ 0.5–0.56 octets par paramètre plutôt qu’un plat 0.5, car les K-quants attribuent différentes largeurs de bits à différents tenseurs — voir Quantification pour savoir comment lire ces noms. Multipliez le nombre de paramètres par les octets-par-paramètre pour obtenir la taille brute des poids, puis ajoutez environ 20% par-dessus pour le cache KV, les activations et les frais généraux du framework à une longueur de contexte modeste :
Hugging Face a mesuré ce motif directement sur un modèle de 15B+ : environ 29 GB à bf16, ~15 GB à 8-bit et ~9.5 GB à 4-bit — voir le guide Hugging Face pour optimiser les LLM. Un contexte plus long ajoute plus de cache KV par-dessus cette ligne de base de 1.2× ; voir Cache KV et contexte pour comprendre pourquoi cela évolue de cette manière.
Cette formule est une estimation de planification pour la taille des poids, pas une vérité absolue. Le nombre réel est la taille réelle du fichier GGUF pour la quantification exacte que vous prévoyez d’exécuter, plus le cache KV pour votre longueur de contexte cible. Consultez le guide d’ajustement des modèles GPU pour des exemples détaillés et un estimateur interactif.

​
Ce qui concurrence réellement pour la mémoire

Trois éléments partagent le même pool de VRAM (ou mémoire unifiée) :
  • Poids du modèle — fixes une fois le modèle chargé, non affectés par la longueur du prompt.
  • Cache KV — croît avec la longueur du contexte et la taille du lot ; voir Cache KV et contexte.
  • Activations et frais généraux du framework — mémoire de travail plus petite nécessaire pendant chaque passe avant, ce que le facteur 1.2× dans la formule ci-dessus prend approximativement en compte.
Les poids constituent le coût le plus important et le plus prévisible. Le cache KV est la partie qui peut vous surprendre, car il est invisible jusqu’à ce que votre contexte grandisse.

​
Délestage : lorsqu’un modèle ne tient pas entièrement

Si les poids d’un modèle ne tiennent pas entièrement dans la VRAM de votre GPU, les backends comme llama.cpp vous permettent de diviser le modèle entre le GPU et le CPU au lieu d’échouer directement. Cela est contrôlé avec le drapeau --n-gpu-layers (forme courte -ngl) : il définit combien de couches du modèle sont chargées sur le GPU, le reste restant dans la RAM système.
  • Délestage complet (-ngl défini suffisamment haut pour couvrir chaque couche) : le modèle entier s’exécute sur le GPU, à pleine vitesse GPU.
  • Délestage partiel : certaines couches s’exécutent sur le GPU, le reste s’exécute sur le CPU en utilisant la RAM système. Cela permet à un modèle plus grand que votre VRAM de se charger et de s’exécuter réellement, à un coût.
  • Aucun délestage (-ngl 0) : le modèle entier s’exécute uniquement sur le CPU.
Le coût du délestage partiel est la vitesse, pas la correction — la sortie est la même dans les deux cas. Les couches côté CPU et la RAM système ont une bande passante mémoire bien inférieure à celle de la VRAM GPU, et rappelez-vous de Comment fonctionne l’inférence que le décodage est limité par la bande passante mémoire : chaque jeton généré doit lire à travers les couches pertinentes, donc toute couche située dans une mémoire plus lente devient un goulot d’étranglement à chaque étape. Plus vous déplacez de couches hors du GPU, plus la génération devient lente — parfois de manière dramatique une fois que le modèle déborde de la RAM vers le disque.
Si un modèle déborde vers le disque (swap) au lieu de rester dans la RAM, attendez une pénalité de vitesse sévère — la bande passante du disque est plusieurs ordres de grandeur plus lente que la RAM, sans parler de la VRAM. Considérez le débordement sur disque comme un signe de choisir un modèle plus petit ou une quantification plus agressive plutôt que quelque chose à traverser.
Trouvez le nom exact du drapeau et le comportement pour votre backend dans le référentiel llama.cpp ; d’autres backends (LM Studio, Ollama) exposent la même idée à travers leurs propres paramètres, généralement construits sur llama.cpp en dessous.

​
Comment la mémoire unifiée change la donne

Sur les systèmes avec mémoire unifiée — Apple Silicon et la plateforme Strix Halo d’AMD — le CPU et le GPU partagent un seul pool de mémoire au lieu que le GPU ait sa propre VRAM séparée et plus petite. Cela change le calcul du délestage :
  • Capacité : un système à mémoire unifiée peut charger un modèle beaucoup plus grand qu’un GPU discret avec une VRAM fixe, car le pool de “VRAM” peut être aussi grand que la RAM totale de la machine (jusqu’à la portion attribuée à l’utilisation graphique).
  • Bande passante : ce même pool fonctionne à une bande passante inférieure à celle de la mémoire GDDR dédiée sur un GPU discret. Un modèle qui tient entièrement dans la mémoire unifiée se décode toujours plus lentement que le même modèle tenant entièrement dans la VRAM d’un GPU discret, car la vitesse de décodage suit la bande passante, pas seulement la capacité.
En pratique, la mémoire unifiée déplace le compromis de “est-ce que ça tient du tout” à “à quelle vitesse ça s’exécute une fois que ça tient” — elle résout le problème de capacité qui force le délestage en premier lieu, mais ne vous donne pas une bande passante de classe GDDR en échange. Consultez le guide d’ajustement des modèles GPU pour voir comment les systèmes spécifiques à mémoire unifiée se comparent aux GPU discrets.

​
Aller plus loin

Comment fonctionne l'inférence

Pourquoi le décodage est limité par la bande passante mémoire en premier lieu.

Cache KV et contexte

La partie de l’utilisation de la mémoire qui croît avec votre conversation, pas seulement votre modèle.

Quantification

Réduire les octets-par-paramètre pour changer l’entrée la plus importante de la formule de dimensionnement.

Guide d'ajustement des modèles GPU

Tableaux de VRAM, un estimateur interactif et ce qui tient sur le matériel courant.

​
Une fois qu’il tient et s’exécute

Le dimensionnement et le délestage permettent à un modèle de s’exécuter sur votre matériel, que ce soit entièrement sur le GPU ou divisé avec le CPU. Une fois qu’il répond aux requêtes sur localhost, l’étape suivante est d’y accéder depuis n’importe où ailleurs.

Donnez-lui un point de terminaison stable

Tokios ne choisit, n’héberge ni n’affine le modèle — une fois qu’il s’exécute localement, Tokios le transforme en un point de terminaison stable et authentifié que vous pouvez appeler depuis n’importe où.