La réponse courte : la VRAM dépend de la taille du modèle, de la quantization et du contexte
Il n’existe pas de valeur unique de VRAM qui fonctionne pour tous les Local LLMs. Le besoin pratique est la somme des poids du modèle, du KV cache, de l’overhead d’exécution et d’une marge de sécurité. Un petit modèle Q4 peut fonctionner sur du hardware modeste, tandis qu’un modèle Q8 plus grand avec un long contexte peut nécessiter beaucoup plus de mémoire. C’est pourquoi deux utilisateurs ayant le même GPU peuvent obtenir des résultats différents si l’un veut un chat court et l’autre du codage long contexte ou du RAG.
En règle pratique, 6GB est un niveau d’entrée, 8GB est utilisable pour les petits modèles, 12GB constitue une base desktop plus confortable, 16GB offre une meilleure marge, 24GB est un niveau grand public solide, et 48GB ou plus ouvre la porte à des modèles plus grands et à une quantization plus élevée. La mémoire unifiée Apple Silicon est une catégorie à part, car le CPU et le GPU partagent le même pool mémoire, mais elle doit tout de même laisser de la place à macOS, aux apps et à l’overhead d’exécution.
Les poids du modèle dominent généralement le budget mémoire
La plus grande partie du budget mémoire correspond généralement aux poids du modèle. Les poids FP16 sont volumineux, tandis que les fichiers GGUF quantized réduisent la taille en stockant les poids avec moins de bits. Un modèle 7B en Q4 peut tenir dans beaucoup moins de mémoire que le même modèle en FP16 ou Q8. C’est pourquoi la quantization est centrale dans les recommandations Local LLM : elle change ce qui est réellement exécutable sur des GPU grand public.
Cependant, la taille du fichier seule ne suffit pas. Certains modèles ont des architectures différentes, un comportement de paramètres actifs MoE, des réglages de tokenizer et des valeurs de contexte par défaut distinctes. Un fichier de modèle qui semble tenir sur le papier peut tout de même être trop juste une fois que le runtime réserve de la mémoire. La recommandation doit inclure une marge prudente au lieu de considérer la taille du fichier comme le besoin complet.
Le KV cache augmente avec la longueur de contexte
Le KV cache est la mémoire utilisée pour stocker les informations d’attention des tokens déjà traités. Il augmente avec la longueur de contexte, les réglages de batch, le nombre de couches, la taille cachée et les détails d’implémentation. C’est pourquoi un modèle qui fonctionne à 4K de contexte peut devenir instable ou lent à 16K, 32K ou davantage. Le long contexte n’est pas gratuit simplement parce que la carte du modèle l’annonce.
Pour les utilisateurs, cela signifie que la bonne cible de VRAM dépend de la charge de travail. Un chat simple peut garder un contexte modéré. Le codage sur de nombreux fichiers, la synthèse de longs documents et le RAG peuvent augmenter les besoins mémoire. Si le long contexte est la priorité, un modèle plus petit ou plus fortement quantized peut être un meilleur choix qu’un modèle plus grand qui consomme presque toute la VRAM avec ses seuls poids.
Niveaux réalistes de GPU pour les Local LLMs
À 6GB, attendez-vous à de petits modèles et à un contexte prudent. À 8GB, les modèles 3B à 7B Q4 deviennent réalistes, mais la marge est limitée. À 12GB, de nombreux modèles 7B et certains modèles 14B quantized deviennent plus pratiques. À 16GB, les mêmes modèles peuvent utiliser une meilleure quantization ou davantage de contexte. À 24GB, des modèles 14B solides et certains modèles quantized plus grands deviennent réalistes pour un usage quotidien. À 48GB et plus, les expériences locales plus ambitieuses deviennent beaucoup plus faciles.
Ces niveaux ne sont pas des promesses. La vitesse dépend de la bande passante mémoire, du backend GPU, du CPU, de la RAM, des drivers et de l’outil d’inférence. Le support NVIDIA CUDA est généralement le plus large dans les outils d’inférence locale. AMD peut bien fonctionner dans des stacks compatibles, mais peut exiger plus d’attention à la compatibilité du backend. Apple Silicon peut utiliser efficacement la mémoire unifiée, mais le budget de modèle utilisable reste inférieur au montant de RAM annoncé, car le système partage cette mémoire.
Quand l’offload partiel aide, et quand il nuit
Si un modèle ne tient pas entièrement en VRAM, certains outils peuvent offload une partie du modèle vers la mémoire CPU. Cela peut permettre de charger un modèle, mais réduit souvent la vitesse, car les données doivent circuler entre le GPU et la mémoire système. Sur les GPU discrets, PCIe et la bande passante mémoire du CPU peuvent devenir des goulots d’étranglement. Sur les Macs à mémoire unifiée, la pénalité est différente, mais la bande passante mémoire et la pression système restent importantes.
L’offload partiel doit être présenté honnêtement. Il peut être utile pour l’expérimentation, les longues réponses occasionnelles ou le test d’un modèle plus grand, mais il ne doit pas être la recommandation par défaut pour un utilisateur normal qui attend une vitesse interactive. Local LLM doit privilégier les recommandations full-GPU lorsque c’est possible et étiqueter séparément l’offload partiel lorsque le modèle est techniquement exécutable, mais moins confortable.
FAQ
8GB de VRAM suffisent-ils pour un Local LLM ? Oui, pour des modèles petits et soigneusement quantized. Ce n’est pas suffisant pour tous les modèles, et un long contexte réduira la plage utilisable.
12GB de VRAM suffisent-ils ? C’est un point de départ raisonnable pour de nombreux modèles 7B et certains modèles 14B quantized, surtout avec des réglages équilibrés.
Plus de VRAM signifie-t-il toujours de meilleures réponses ? Pas toujours. Plus de VRAM élargit l’ensemble des candidats, mais la qualité du modèle, son tuning, sa quantization et le cas d’usage déterminent toujours la meilleure recommandation.
Comment estimer ma propre configuration ? Saisissez votre VRAM, votre RAM, votre système d’exploitation et votre cas d’usage dans Local LLM. L’outil applique des règles de taille de modèle, de quantization, de KV cache et de marge aux données de modèles actuelles.