De combien de VRAM un assistant documentaire local a-t-il besoin ?

Un assistant documentaire local n’a besoin d’aucune VRAM dédiée lorsque la génération s’exécute à distance ou sur un serveur d’inférence séparé. Pour une inférence sur la même machine, 8 Go constituent un point de départ pratique pour les petits modèles quantifiés, tandis que les modèles plus volumineux, les contextes plus longs et l’exécution concurrente peuvent faire dépasser largement 16 à 24 Go. Dimensionnez le modèle exact et le contexte de travail avant l’achat, car l’application RAG elle-même ne définit pas les besoins en VRAM.

Déterminez si l’assistant a réellement besoin d’un GPU local

Un assistant documentaire comporte au moins deux couches : l’application qui stocke les fichiers, segmente le texte, recherche ou récupère des passages et présente les réponses ; et le backend du modèle qui génère le contenu. Ces couches ne doivent pas nécessairement fonctionner sur le même matériel. Un serveur compact peut héberger la bibliothèque documentaire privée et la pile de récupération, tout en envoyant les requêtes au modèle vers une autre machine locale équipée d’un GPU ou vers un fournisseur distant.

La documentation auto-hébergée d’AnythingLLM explicite cette séparation en permettant à l’application de se connecter à des services de modèles et d’embeddings hébergés ailleurs. Ses exigences d’auto-hébergement sont donc bien inférieures à celles du matériel nécessaire pour exécuter un LLM sur la même machine.

Si l’exigence est « les documents restent sur mon serveur » plutôt que « chaque token du modèle doit être généré sur ce serveur », zéro VRAM dédiée peut être un choix d’achat valable. Vous devez néanmoins vérifier quels textes quittent la machine, où sont produits les embeddings, comment le modèle distant traite les requêtes et si la limite de confidentialité correspond au cas d’usage.

La première décision d’achat est architecturale : une inférence distante ou séparée implique de dimensionner le processeur, la RAM et le stockage pour la récupération ; une inférence sur la même machine fait de la VRAM une contrainte principale dans le choix du modèle.

Dimensionnez les poids du modèle avant d’ajouter la surcharge du RAG

La planification de la VRAM commence par le modèle exact et sa précision. Les poids en pleine précision sont bien plus volumineux que les variantes 8 bits ou 4 bits, ce qui explique pourquoi deux utilisateurs affirmant « exécuter un modèle 7B » peuvent avoir des besoins mémoire très différents. La quantification peut permettre à un modèle plus petit et utile de fonctionner sur du matériel courant, mais elle peut également modifier le comportement des sorties et doit être évaluée avec la tâche documentaire.

Hugging Face indique que la quantification réduit les coûts en mémoire et en calcul en représentant les poids et les activations avec des types de données de précision inférieure, et prend en charge les méthodes courantes en 8 et 4 bits. La précision devient donc un critère d’achat, et non un simple réglage logiciel appliqué après le choix du matériel.

Comme règle approximative de planification actuelle, les modèles 4 bits de classe 7–8B tiennent souvent dans une plage de 6 à 8 Go, ceux de classe 13–14B se rapprochent généralement de 10 à 12 Go, tandis que ceux de classe 27–32B nécessitent souvent environ une vingtaine de Go avant de prévoir une marge supplémentaire pour le contexte. Le guide de dimensionnement de la VRAM de Spheron pour 2026 fournit des estimations INT4 similaires et ajoute explicitement la surcharge d’exécution aux estimations des poids.

N’achetez pas en vous basant exactement sur la taille du fichier du modèle téléchargé. Prévoyez de la place pour l’environnement d’exécution et l’état du contexte, puis vérifiez le modèle réel dans le moteur d’inférence prévu. Un modèle qui se charge avec une minuscule invite de test peut tout de même échouer ou basculer vers le processeur lorsque l’assistant reçoit un long contexte récupéré.

La longueur du contexte peut faire changer de palier de VRAM une fois le modèle chargé

Un assistant documentaire a souvent besoin de plus de contexte qu’un chatbot classique, car les passages récupérés, les citations, les instructions système, l’historique de conversation et les questions de l’utilisateur sont assemblés dans une seule requête. Les poids du modèle peuvent rester constants tandis que le cache clé-valeur et les autres états de la requête augmentent avec la longueur du contexte.

La documentation actuelle d’Ollama sur le contexte rend cet arbitrage visible : sa longueur de contexte par défaut augmente avec la VRAM disponible, passant de 4K sous 24 Gio à 32K entre 24 et 48 Gio, puis à des valeurs bien supérieures à partir de 48 Gio. Les valeurs exactes dépendent de l’environnement d’exécution, mais la leçon pour l’achat est que les tâches documentaires à long contexte consomment de la mémoire au-delà des seuls poids du modèle.

Ne réagissez pas en maximisant le contexte sans discernement. La récupération doit sélectionner le plus petit ensemble de passages permettant de répondre à la question, tandis que la segmentation ou le reclassement doivent supprimer le texte hors sujet avant la génération. Un assistant documentaire qui doit insérer tous les documents dans une seule invite utilise la VRAM pour compenser une conception de récupération insuffisante.

Passez au palier de VRAM supérieur lorsque le modèle testé est suffisamment précis, mais que les véritables requêtes documentaires provoquent un déport vers le processeur, des erreurs de mémoire insuffisante ou une latence inacceptable avec la longueur de contexte dont vous avez réellement besoin. Si la qualité de la récupération est mauvaise avant même que le contexte n’atteigne le modèle, corrigez d’abord l’index et le classement.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prévoyez séparément les embeddings, le reclassement, l’OCR et l’exécution concurrente

Le LLM local n’est pas le seul composant susceptible d’utiliser de la mémoire GPU. Certains assistants documentaires accélèrent également les embeddings, les modèles de reclassement, l’OCR, la transcription vocale ou les modèles de vision sur le même GPU. L’exécution simultanée de ces modèles peut réduire la VRAM disponible pour le générateur, même si chaque composant tient dans la mémoire lorsqu’il est testé seul.

L’article de ZimaSpace sur l’empreinte mémoire complète des modèles explique pourquoi les tampons d’exécution et l’état des requêtes doivent être pris en compte en plus de la taille du point de contrôle. Pour un assistant documentaire, le contexte récupéré et les services parallèles ajoutent une autre source de pression sur la mémoire partagée.

La concurrence modifie également la réponse. Deux utilisateurs actifs peuvent avoir besoin d’un état de cache clé-valeur distinct, même s’ils partagent un modèle résident. Un serveur orienté traitement par lots peut améliorer l’utilisation de l’accélérateur, mais il ne fait pas disparaître la mémoire nécessaire à chaque requête. Mesurez la requête documentaire normale la plus longue avec le nombre d’utilisateurs simultanés prévu.

Si le générateur est la seule charge GPU, vous pouvez dimensionner au plus près de son ensemble de travail testé. Si l’OCR, les embeddings, le reclassement et la génération doivent fonctionner en parallèle, achetez davantage de VRAM, séquencez les étapes lourdes ou répartissez les services entre les ressources CPU et GPU. Le choix le moins coûteux est celui qui respecte la latence requise sans payer pour une accélération inutilisée.

Utilisez les paliers de VRAM pour présélectionner les modèles, puis testez leur qualité

Une présélection utile peut être organisée selon ce que l’assistant documentaire doit accomplir, plutôt que selon le plus grand modèle qui tient en mémoire. Avec environ 6 à 8 Go de VRAM, commencez par de petits modèles 4 bits de classe 7–8B et une récupération limitée. Entre 12 et 16 Go, vous gagnez de la marge pour des modèles plus grands, une précision supérieure ou davantage de contexte. Avec environ 24 Go, de nombreux modèles quantifiés de classe 27–32B deviennent pratiques, avec une marge de fonctionnement accrue. À partir d’environ 40 à 48 Go, les modèles 4 bits de classe 70B commencent à devenir réalistes sans déport important vers le processeur.

Le guide 2026 de SitePoint sur les LLM locaux indique qu’un modèle 7B Q4_K_M peut tenir confortablement dans environ 6 Go de VRAM. D’autres guides de dimensionnement actuels placent les modèles quantifiés 14B et 32B plus haut, ce qui confirme que le palier dépend du point de contrôle exact plutôt que d’une étiquette générique d’« ordinateur IA ».

Constituez un jeu d’évaluation à partir de vos propres documents avant d’acheter le palier supérieur. Incluez des questions nécessitant une extraction exacte, une synthèse de plusieurs passages, un refus lorsque la source est absente, ainsi que des tableaux ou du texte structuré si nécessaire, et testez le contexte le plus long que vous prévoyez. Comparez la qualité des réponses, le comportement des citations, la latence jusqu’au premier token, la vitesse de génération et le pic de VRAM.

Achetez davantage de VRAM lorsque le modèle plus petit échoue parce que ses capacités ou sa capacité de contexte sont réellement insuffisantes. Ne changez pas de palier simplement parce qu’un point de contrôle plus grand existe. Pour une base de connaissances privée et délimitée, la récupération peut rendre un modèle plus petit et plus rapide plus utile qu’un modèle plus lent offrant un ancrage documentaire faible.

Gardez l’hôte de stockage et de récupération distinct de la décision concernant la VRAM

Un assistant documentaire a également besoin d’un stockage persistant pour les fichiers originaux, le texte extrait, les index, les bases de données applicatives, les journaux et les sauvegardes. Ces ressources consomment généralement de la RAM système et de la capacité disque, plutôt que de la VRAM. Réunir toutes les ressources dans un seul chiffre de « mémoire IA » conduit à de mauvaises décisions matérielles.

La présentation de ZimaSpace consacrée à un assistant IA privé sur NAS décrit le rôle prioritaire de la récupération des fichiers locaux. Cette architecture permet au système de stockage de rester stable, même si le matériel d’inférence est remplacé ultérieurement.

ZimaBoard 2 1664 convient lorsque le serveur compact sert au stockage documentaire, à l’indexation, aux applications et à l’orchestration, tandis que le LLM s’exécute à distance ou sur une machine équipée d’un GPU distinct. Ses composants graphiques Intel intégrés ne doivent pas être considérés comme de la VRAM dédiée aux LLM.

Choisissez l’hôte de stockage selon le volume documentaire, les sauvegardes, la mémoire nécessaire aux applications et les besoins réseau. Choisissez l’accélérateur selon le modèle exact, la quantification, le contexte et la concurrence. En séparant ces décisions, vous pouvez mettre à niveau le GPU sans reconstruire le référentiel documentaire faisant autorité.

Vérifiez toute configuration GPU sur une seule machine avant l’achat

Si vous souhaitez réunir le stockage, la récupération et la génération locale dans un même boîtier, la dernière vérification d’achat concerne la mémoire exacte du GPU disponible pour l’environnement d’exécution. Des noms de produits tels que « IA », « Creator » ou « RTX » n’indiquent pas si le modèle local choisi tiendra en mémoire. La VRAM, la prise en charge des pilotes, l’accès depuis les conteneurs, l’alimentation, le refroidissement et les possibilités d’extension doivent tous être vérifiés.

Le ZimaCube 2 Creator Pack est l’option Zima à évaluer lorsqu’un acheteur souhaite un stockage multi-baie et un GPU NVIDIA dédié dans le même système. La page produit actuelle identifie la famille du GPU, mais ne publie pas de capacité de VRAM dans le texte principal des spécifications. Ne le rattachez donc pas à un palier de 8, 16, 24 ou 48 Go avant d’avoir confirmé la mémoire exacte du GPU installé.

Avant de finaliser l’achat, exécutez ou demandez si possible un test avec un modèle représentatif. Notez le pic de VRAM avec la quantification et le contexte habituels, puis répétez le test avec les embeddings, le reclasseur, l’OCR ou les autres services GPU de l’assistant actifs. Vérifiez que l’environnement d’exécution utilise bien le GPU prévu, plutôt que de déporter silencieusement des couches vers la mémoire système.

La règle finale consiste à acheter la VRAM correspondant à l’ensemble de travail validé, et non à la catégorie marketing. Utilisez zéro VRAM dédiée lorsque l’inférence peut s’exécuter ailleurs ; commencez autour de 6 à 8 Go pour les petits modèles locaux quantifiés ; passez à 12–16 Go pour des modèles plus grands ou davantage de marge ; et n’envisagez 24 Go ou plus que lorsque le flux documentaire testé prouve que la taille du modèle, le contexte ou la concurrence l’exigent.

FAQ

Le RAG réduit-il la quantité de VRAM dont j’ai besoin ?

Le RAG peut permettre à un modèle plus petit de répondre à partir d’éléments récupérés plutôt que de s’appuyer sur les connaissances internes d’un modèle plus grand, ce qui peut réduire le palier de modèle nécessaire. Les passages récupérés consomment néanmoins de la mémoire de contexte ; une récupération de mauvaise qualité qui envoie trop de texte peut donc accroître la pression sur la VRAM.

Les embeddings nécessitent-ils autant de VRAM que le modèle conversationnel ?

Non. Les modèles d’embeddings ont leur propre empreinte CPU, RAM ou GPU et peuvent fonctionner sur le processeur ou via un service distinct. Si les embeddings et la génération partagent un GPU, mesurez leur pic combiné plutôt que d’additionner théoriquement les tailles des fichiers de modèles.