Oui, un serveur domestique utilisant uniquement le processeur peut exécuter un système RAG utile pour les documents familiaux, à condition que la recherche reste compacte et que la génération utilise un petit modèle quantifié.
Une bibliothèque familiale composée de manuels, de reçus, de notes scolaires, de garanties et de PDF numérisés nécessite rarement un débit digne d’un centre de données. Elle a besoin d’une recherche privée, de passages vérifiables et d’un temps de réponse acceptable pour une ou deux personnes. Le processeur doit tout de même vectoriser les documents, rechercher les vecteurs, traiter le texte récupéré et générer une réponse. L’utilité dépend donc de la limitation de la taille du modèle, de la longueur du contexte, de la simultanéité et des erreurs de nettoyage des documents.
Le verdict dépend du pipeline RAG, pas de la présence d’un GPU
Le RAG sépare la tâche en ingestion, recherche et génération. L’ingestion extrait le texte et crée les représentations vectorielles ; la recherche trouve un petit ensemble de segments pertinents ; la génération transforme ces segments en réponse. Un processeur peut exécuter chaque étape, mais chacune possède un goulot d’étranglement différent. La recherche vectorielle peut se terminer rapidement, tandis que l’évaluation de l’invite et la génération des jetons dominent l’attente.
Le RAG hors ligne utilisant uniquement le processeur peut fonctionner de manière sécurisée sur un matériel limité. Cela ne signifie pas que tous les modèles ou toutes les charges documentaires sont interactifs. L’affirmation utile est plus précise : avec un modèle adapté, un contexte maîtrisé et un fonctionnement patient pour un seul utilisateur, le système peut répondre à des questions fondées sur des sources sans GPU dédié ni service cloud.
Pour une bibliothèque familiale, « utile » devrait signifier que le bon document est retrouvé, que la réponse cite le passage pertinent et que les questions courantes obtiennent une réponse dans un délai convenu. Cela ne devrait pas signifier une discussion instantanée avec plusieurs utilisateurs ni un raisonnement parfait sur des centaines de pages. Un serveur utilisant uniquement le processeur offre l’avantage de la confidentialité et de la réutilisation du matériel existant ; il atteint ses limites lorsque la latence ou la demande simultanée devient prioritaire.
La recherche reste généralement abordable ; la génération donne le rythme
Un index vectoriel local recherche des représentations numériques compactes au lieu de relire chaque fichier. Pour une collection domestique de quelques milliers ou dizaines de milliers de segments, l’index peut souvent rester en RAM et renvoyer rapidement des candidats. L’OCR et la vectorisation sont plus lourds lors de l’ingestion initiale, mais ces opérations peuvent s’exécuter en arrière-plan et ne doivent être répétées que pour les documents modifiés.
La recherche ajoute tout de même une latence mesurable et peut représenter une grande partie du délai avant le premier jeton dans certaines architectures. Les compromis des systèmes RAG mesurés montrent également que les choix d’intégration modifient la précision et le délai de bout en bout. Sur un processeur domestique, limiter la valeur de top-k et éviter les recherches répétées pendant la génération empêchent une étape de recherche modeste de devenir un coût récurrent.
La génération reste séquentielle : le modèle traite les jetons de l’invite et émet les jetons de la réponse un par un. Les longs passages récupérés coûtent donc deux fois plus : ils nécessitent davantage d’évaluation de l’invite et offrent davantage d’occasions d’introduire des éléments non pertinents. Un contexte plus petit et bien segmenté peut donner à un modèle modeste une impression de rapidité et de précision supérieure à celle d’un modèle plus grand exécuté sur processeur avec des documents entiers. Davantage de contexte ne signifie pas automatiquement une meilleure recherche.
Les petits modèles quantifiés rendent le budget mémoire viable
La quantification stocke les poids du modèle avec une précision moindre, ce qui réduit l’utilisation de la RAM et la bande passante mémoire nécessaire à chaque jeton généré. Les modèles de trois à huit milliards de paramètres deviennent ainsi envisageables sur des machines dotées d’une mémoire système ordinaire, même si les tampons de contexte, le système d’exploitation, la base de données vectorielle et les services OCR ont eux aussi besoin de marge. Un modèle qui tient tout juste en mémoire peut basculer sur le disque et devenir inutilisable.
Les modèles locaux quantifiés présentent des débits, une consommation mémoire et un comportement énergétique différents selon les petits ordinateurs et les moteurs d’exécution. Le nombre de paramètres ne suffit donc pas à prédire l’expérience. Le niveau de quantification, la bande passante mémoire, le moteur d’exécution, la longueur de l’invite et l’architecture du modèle influencent tous le nombre de jetons par seconde et le délai avant la première réponse.
Commencez par un modèle qui laisse au moins plusieurs gigaoctets au reste de la pile, puis mesurez les performances sur votre processeur exact. Si un modèle sur quatre bits produit des réponses correctement sourcées à une vitesse acceptable, passer à un modèle plus grand risque de réduire la réactivité davantage que d’améliorer le rappel des documents familiaux. La qualité de la recherche, la précision de l’OCR et les limites des segments méritent souvent d’être améliorées avant la taille du modèle.
Le RAG utilisant uniquement le processeur atteint ses limites avec les longs contextes et la simultanéité
La conception devient moins confortable lorsque plusieurs utilisateurs envoient de longues questions, lorsque chaque réponse inclut de nombreux segments récupérés ou lorsque le modèle doit synthétiser de gros contrats et des dossiers médicaux. Les générations simultanées se disputent la bande passante mémoire et les cœurs. La latence augmente de manière non linéaire si les requêtes s’empilent, si les caches de contexte prennent de l’ampleur ou si le serveur commence à utiliser la mémoire virtuelle.
Les petits modèles de langage avec RAG nécessitent de traiter le modèle, la base de données vectorielle et la conception de la recherche comme un seul problème de déploiement. Un serveur familial utilisant uniquement le processeur ne devrait donc pas promettre des niveaux de service comparables à ceux du cloud. Il convient bien aux recherches occasionnelles et aux résumés courts, mais pas aux assistants vocaux à faible latence, à l’analyse massive de documents ni à de nombreuses sessions simultanées.
La limite est également informationnelle, et pas seulement informatique. La présentation par ZimaSpace d’un assistant IA privé sur un NAS indique que la recherche et les résumés légers conviennent mieux aux systèmes utilisant uniquement le processeur que l’inférence lourde. Une réponse rapide fondée sur un texte mal extrait par OCR reste incorrecte ; l’interface devrait donc afficher les noms de fichiers sources et les passages cités afin de permettre une vérification.
Effectuez un test d’acceptation en 20 questions avant de le déclarer utile
Constituez un jeu de test à partir de tâches familiales réelles : trouver la date de garantie d’un appareil, localiser une clause d’assurance, identifier une échéance scolaire et répondre à une question dont la réponse est absente. Incluez des PDF numérisés et des PDF natifs. Pour chaque requête, notez la réussite de la recherche, l’exactitude de la citation, le délai avant le premier jeton, le temps de réponse total, la RAM maximale utilisée et la capacité du modèle à reconnaître l’absence de preuve.
Le travail de recherche peut être réduit en limitant, pour chaque requête, la partie de l’index examinée. TeleRAG utilise une recherche par regroupements afin de limiter l’espace de recherche actif. Un test domestique n’a pas besoin de reproduire cette architecture, mais il devrait vérifier le même principe : la recherche doit renvoyer quelques segments pertinents, et non transférer toute la bibliothèque dans l’invite.
Conservez la conception utilisant uniquement le processeur si au moins 18 questions sur 20 retrouvent la bonne source, si chaque réponse factuelle expose un passage vérifiable, si les requêtes habituelles respectent l’objectif de latence du foyer et si la RAM maximale reste inférieure à 80 %. Si la recherche échoue, corrigez l’OCR ou la segmentation ; si la recherche réussit mais que la génération est trop lente, réduisez le contexte ou la taille du modèle. N’ajoutez un GPU qu’après avoir confirmé que les mesures en justifient la nécessité.
| Échec observé | Goulot d’étranglement probable | Test suivant |
|---|---|---|
| Mauvais fichier retrouvé | OCR, segments ou représentations vectorielles | Examiner les cinq premiers passages |
| Passages corrects, premier jeton lent | Traitement de l’invite | Réduire top-k et la longueur des segments |
| Flux de jetons lent | Modèle ou moteur d’exécution | Essayer un modèle quantifié plus petit |
| Échec uniquement en utilisation simultanée | File d’attente et bande passante mémoire | Sérialiser les requêtes |
Centre Tech & IA
Plus à lire

Pourquoi Home Assistant fonctionne-t-il différemment sur le réseau local et à distance ?
Les sessions Home Assistant en réseau local et à distance utilisent des chemins réseau différents ; la latence à distance ajoute le DNS, le...

Home Assistant fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?
Le CGNAT et le double NAT n’affectent généralement pas le contrôle local de Home Assistant ; ils modifient principalement la façon dont les clients...

Comment la latence du réseau affecte-t-elle Home Assistant pendant les pannes d’Internet ?
La perte de connexion Internet et la latence du réseau sont deux problèmes distincts : les chemins locaux entre les appareils peuvent rester rapides...

