8, 12, 16 ou 24 Go de mémoire graphique permettent une première sélection. L’intérêt quotidien d’un modèle local dépend aussi de sa version, du contexte et des usages simultanés. Comparer la mémoire évite un achat inadapté.
Ce qui occupe réellement la mémoire graphique
La planification couvre trois éléments : les poids du modèlechargés, la mémoire de contexte, cache KV compris et les tampons d’exécution du backend utilisé. Prévoir aussi de la place pour les autres applications GPU et une réserve d’exploitation. Avec une carte graphique dédiée classique, RAM système et mémoire graphique sont des ressources distinctes.
Le budget diffère avec une mémoire partagée : système d’exploitation, applications et modèle puisent dans la même réserve. Le pilote doit aussi y mesurer la mémoire réellement disponible et la tâche réelle. La capacité nominale ne suffit pour aucune des deux architectures.
4 bits : un calcul utile aux limites claires
Le « B » de 7B ou 70B signifie milliards de paramètres. Pour estimer les poids avec 4 bits uniformes : nombre de paramètres × 4 ÷ 8 = octets. La quantification stocke les poids avec une précision réduite. Son effet sur la qualité des réponses doit être vérifié pour la tâche concernée.
| Classe de modèle | Taille théorique sur 4 bits | Conséquences |
|---|---|---|
| 7–8B | 3,5–4,0 GB ≈ 3,26–3,73 GiB | Point de départ compact pour un premier essai ; il faut aussi tenir compte du fichier exact et du contexte. |
| 14B | 7,0 GB ≈ 6,52 GiB | Ce calcul seul ne prouve pas une exécution complète sur une carte de 8 Go. |
| 32B | 16,0 GB ≈ 14,90 GiB | Même un budget nominalement suffisant pour les poids ne laisse aucune place au reste de l’exécution. |
| 70B | 35,0 GB ≈ 32,60 GiB | Dans ce calcul simplifié, les seuls poids dépassent déjà une carte unique de 24 Go. |
Un GGUF précis est plus volumineux ou composé autrement que ce calcul. Des méthodes comme Q4_K_M ne stockent pas simplement tous les éléments sur quatre bits par paramètre. La planification doit donc préciser le fichier exact du modèle et sa variante de quantification retenue.
Exemple vérifiable dans les répertoires officiels Qwen : les parties Q4_K_M additionnées de Qwen2.5-Instruct représentent pour 7B environ 4,68 GB / 4,36 GiB, pour 14B 8,99 GB / 8,37 GiB et pour 32B 19,85 GB / 18,49 GiB. Ce sont des tailles de fichiers, pas des consommations VRAM mesurées. Elles montrent toutefois pourquoi « 32B sur 4 bits tient dans 16 Go » n’est pas un engagement fiable pour cette version.
Situer les capacités de 8, 12, 16 ou 24 Go
| Classe de capacité | Périmètre d’essai utile | Points de vigilance |
|---|---|---|
| 8 GB | Une version compacte de 7–8B avec un contexte limité comme point de départ. | Les autres usages GPU et les entrées longues peuvent vite réduire le budget disponible. |
| 12 GB | Davantage de marge pour les modèles compacts ; tester une quantification précise de 14B. | Poids, cache KV et tampons doivent tenir ensemble dans la mémoire libre. |
| 16 GB | Réserve supplémentaire pour des versions adaptées de modèles petits et moyens. | Le Qwen2.5-32B-Q4_K_M cité dépasse déjà cette classe en tant que fichier complet. |
| 24 GB | Une quantification adaptée de 32B peut être présélectionnée. | Il faut aussi tester le contexte long et les requêtes simultanées. Cela ne signifie pas une prise en charge de 70B. |
Vérifier l’unité de l’outil de mesure et la mémoire libre . Deux cartes de même capacité peuvent fortement différer en bande passante, puissance de calcul, pilotes et consommation. Plus de GB ne constituent donc ni validation d’un modèle ni benchmark.
Tester le contexte et les requêtes simultanées
Le cache KV conserve les valeurs intermédiaires nécessaires au traitement. Son besoin dépend notamment de l’architecture du modèle, de la longueur du contexte et du format de stockage. Documents longs, historiques de discussion et extraits de connaissances prennent de la place. La fenêtre de contexte maximale annoncée n’est donc pas une capacité mémoire disponible sans coût.
Un essai unique réussi renseigne peu sur les requêtes simultanées. Avec Ollama, le traitement parallèle des contextes augmente la mémoire utilisée ; consigner la configuration exacte. Tester une requête courte, un contexte réaliste plus long et la concurrence attendue. Évaluer ensemble qualité, délai du premier token, durée totale, erreurs et pic de mémoire.
Un format KV plus petit ou quantifié peut économiser de la mémoire selon le moteur et le backend. Il peut aussi modifier la précision et le comportement. Quantification des poids et quantification KV sont deux réglages distincts ; les comparer avec les mêmes cas métier.
Déporter vers le CPU et la RAM : possible, avec un comportement différent
Des moteurs comme llama.cpp permettent de répartir l’exécution entre CPU et GPU. Un modèle dont le besoin total dépasse la mémoire graphique peut ainsi devenir utilisable. Il faut suffisamment de RAM et un chemin de données adapté. Un SSD ne remplace pas la VRAM manquante par une mémoire graphique aussi rapide.
Le déport modifie le chemin d’exécution et souvent le délai de réponse ; sans mesure, son effet ne peut être chiffré sérieusement. Dans Ollama, ollama pspermet de contrôler la répartition CPU/GPU actuelle. Plusieurs GPU n’équivalent pas automatiquement à un seul grand appareil : vérifier la prise en charge, la répartition et les transferts entre cartes dans l’architecture.
Avant l’achat : valider une configuration précise
- Définir le modèle : version exacte, quantification, licence et qualité attendue.
- Définir la charge : budget de contexte, longueurs d’entrée/sortie et requêtes simultanées.
- Vérifier l’environnement : GPU précis, backend, pilotes, système, RAM, refroidissement et alimentation.
- Mesurer : capacité libre, pic de consommation, délais de réponse et erreurs métier dans un pilote représentatif.
- Décider : réutiliser le matériel existant, le compléter de façon ciblée ou choisir un service local, externe ou hybride.
DAXS inscrit le choix du modèle et du matériel dans votre informatique existante et l’exploitation convenue. La page spécialisée LLM locaux et infrastructureprésente le cadre. L’article sur le pilote de charge pour l’IA locale montre l’évaluation sur des tâches réalistes ; Coûts et choix du modèle examine l’aspect économique.
Discuter du choix du modèle et du matériel
Sources : Ollama : longueur du contexte (lien externe) · Ollama : mémoire, concurrence et déport (lien externe) · llama.cpp : chemins d’exécution (lien externe) · Hugging Face : GGUF (lien externe) · répertoires officiels des fichiers Qwen 7B (lien externe), 14B (lien externe), 32B (lien externe). Repères pour l’inférence ; ni test d’entraînement, ni offre de matériel, ni mesure client revendiquée.
