Faire fonctionner une IA sur son ordinateur : matériel nécessaire et limites à connaître

Faire fonctionner un modèle de langage sur son ordinateur peut éviter de transmettre chaque demande à un service distant. Mais télécharger un fichier de quelques gigaoctets ne suffit pas à savoir si l’expérience sera rapide, utile et réellement confinée à la machine. La taille du modèle, la mémoire, le contexte et le logiciel d’exécution doivent être examinés ensemble.

Le bon point de départ n’est pas « quelle carte graphique acheter ? ». C’est « quelle tâche locale doit réussir, avec quel délai et quelles données ? ». Un outil de reformulation et un assistant documentaire utilisé par plusieurs personnes n’ont pas le même besoin.

Choisir une tâche assez précise pour être évaluée

Écrivez trois à cinq usages : reformuler un texte court, extraire des champs d’un document, expliquer un morceau de code ou préparer une synthèse. Définissez pour chacun un résultat acceptable et les informations que le système ne doit pas inventer.

Une installation locale peut être intéressante pour maîtriser certains flux, travailler sans réseau après préparation ou expérimenter avec une configuration connue. Elle peut aussi ajouter de l’entretien et produire un résultat inférieur à ce que votre tâche exige. L’emplacement du calcul ne détermine pas la qualité de la réponse.

Pour une tâche professionnelle, comparez l’assistance obtenue au temps de vérification. Si une synthèse demande autant de contrôle que sa rédaction manuelle, le gain peut être faible. Un modèle plus volumineux n’est pas automatiquement plus utile sur chaque usage.

Le dossier sur le choix entre agent IA et automatisation propose une méthode complémentaire : conserver des règles explicites pour les calculs et les actions dont le résultat doit être déterministe. Installer un modèle local ne justifie pas de lui confier toutes les étapes.

La mémoire des poids donne une première estimation

Les paramètres du modèle occupent de la mémoire selon leur représentation. Un calcul simplifié multiplie leur nombre par le nombre de bits, puis divise par huit pour obtenir des octets. Il donne un ordre de grandeur des poids, pas toute la mémoire nécessaire à l’exécution.

Pour huit milliards de paramètres, une représentation sur 16 bits représente environ 16 milliards d’octets, soit 16 Go décimaux. Sur quatre bits, le calcul brut donne environ 4 Go. Les formats réels ajoutent des informations et les méthodes ne traitent pas forcément tous les éléments à la même précision.

Ces valeurs ne constituent pas une recommandation de mémoire minimale. Un modèle dont les poids font environ 4 Go ne tient pas nécessairement entièrement dans 4 Go de mémoire vidéo. Il faut encore les buffers, le contexte, les autres données et la marge de fonctionnement.

Vérifiez la taille réelle du fichier, les indications du logiciel d’exécution et les conditions du modèle choisi. Un libellé « 4 bits » ne permet pas de déduire exactement tous les besoins ni de comparer directement deux formats différents.

Quantifier réduit la mémoire, avec des compromis

La quantification emploie des représentations numériques moins coûteuses pour certains éléments. Elle peut réduire les besoins et rendre un modèle accessible à davantage de machines. Son effet sur la qualité dépend du modèle, de la méthode et de la tâche.

Il serait donc imprudent d’affirmer qu’un format réduit est toujours équivalent à l’original. Testez des exemples sensibles : chiffres, extraction de champs, instructions multiples et réponses où une nuance change le sens. Les écarts peuvent être plus importants sur certaines tâches que sur un dialogue ordinaire.

Comparez les configurations avec les mêmes demandes et les mêmes critères. Si vous modifiez simultanément le modèle, la quantification et les instructions, vous ne saurez pas expliquer la différence. Conservez une fiche de version comprenant le fichier utilisé et les paramètres importants.

Le bon compromis n’est pas nécessairement la compression maximale. Un modèle un peu plus petit avec une représentation adaptée peut offrir une expérience plus cohérente qu’un grand modèle fortement contraint par votre matériel. Il faut mesurer cette hypothèse, pas la transformer en règle générale.

RAM, mémoire vidéo et mémoire unifiée

Sur une machine équipée d’une carte graphique distincte, la mémoire vidéo et la mémoire principale sont des ressources différentes. Le logiciel peut exécuter certaines opérations sur le GPU, sur le processeur ou dans une organisation mixte, selon les capacités prises en charge.

Des moteurs d’exécution comme llama.cpp documentent plusieurs backends et des possibilités de calcul hybride CPU/GPU. Ces fonctions dépendent du matériel et de la version du logiciel. La présence d’un GPU ne garantit pas qu’il sera utilisé efficacement dans votre configuration.

Certaines plateformes utilisent une mémoire unifiée partagée par plusieurs composants. Il faut alors garder une marge pour le système et les applications. Un ordinateur disposant d’un volume total de mémoire donné ne peut pas en consacrer arbitrairement la totalité au modèle.

Avant un achat, vérifiez la compatibilité exacte : architecture, pilotes, backend et formats de modèle. Une carte annoncée puissante dans les jeux ne constitue pas, à elle seule, une validation pour votre moteur d’IA locale.

Sur un ordinateur existant, commencez avec un modèle adapté à ses ressources. Vous pourrez observer l’utilisation de la mémoire, la stabilité et les délais sans engager immédiatement un budget matériel. Le test doit inclure vos autres applications si elles resteront ouvertes pendant le travail.

Le contexte peut devenir le facteur limitant

Le contexte comprend les informations traitées pendant la demande et les échanges conservés. Son volume s’exprime souvent en tokens, dont le rapport avec les mots varie selon le texte et le tokenizer. Une limite annoncée en tokens n’est donc pas une longueur fixe en pages françaises.

Le cache utilisé pour certaines opérations d’attention peut croître avec le contexte, le nombre de requêtes simultanées et l’architecture du modèle. Les détails dépendent du moteur et des options. Ajouter un document long peut ainsi modifier les besoins de mémoire même si les poids ne changent pas.

Une fenêtre de contexte importante ne garantit pas non plus que le modèle exploitera parfaitement chaque information. Testez la récupération d’un détail au début, au milieu et à la fin du document, puis vérifiez la réponse. Une réponse plausible peut manquer une condition essentielle.

Évitez de charger tout un dossier par défaut. Sélectionnez les passages nécessaires à la question, tout en gardant leur contexte et leurs sources. Pour une recherche documentaire, une architecture spécifique peut être plus pertinente qu’une conversation contenant tous les fichiers.

Un scénario fictif illustre le besoin de marge. Si les poids et le fonctionnement de base occupent 6 Go, et qu’une requête longue ajoute 3 Go dans la configuration observée, une machine ne disposant que de 8 Go libres risque de rencontrer une limite. Ces volumes sont hypothétiques ; mesurez ceux de votre système plutôt que d’utiliser cet exemple comme dimensionnement.

Mesurer la latence et la génération séparément

Le délai avant le premier morceau de réponse et la vitesse de génération ne décrivent pas la même chose. Une demande contenant un long document peut nécessiter un traitement initial conséquent, puis produire du texte à un rythme satisfaisant.

Notez la taille de l’entrée, la taille de la réponse, le temps avant réponse et la durée totale. Précisez également si le modèle était déjà chargé. Le premier lancement et les demandes suivantes peuvent présenter des comportements différents.

Un calcul de lecture permet de relativiser un indicateur. À 20 tokens par seconde, une sortie de 400 tokens demande environ 20 secondes de génération, hors traitement initial. Cela ne signifie pas que tous les modèles produiront 400 mots, ni que votre machine atteindra cette vitesse.

Pour votre usage, fixez un délai acceptable : une extraction en arrière-plan peut tolérer davantage qu’un assistant interactif. La vitesse doit être évaluée avec la qualité, car produire rapidement une réponse qui demande cinq minutes de correction n’est pas forcément une amélioration.

Ne présentez pas une mesure de votre machine comme un benchmark général. Elle dépend du modèle, de ses options, du logiciel et du matériel. Une comparaison utile conserve ces conditions et la tâche réellement exécutée.

Local ne signifie pas automatiquement confidentiel

Le modèle peut s’exécuter sur votre machine tandis que l’interface, une extension ou un outil associé contacte un service distant. Vérifiez les fonctions de recherche, les journaux, la télémétrie et les intégrations. Le mot « local » doit décrire l’ensemble du parcours que vous utilisez.

Les fichiers de conversation et les documents peuvent rester sur le disque. Leur protection dépend alors des comptes de la machine, du chiffrement, des sauvegardes et des permissions. Une absence d’envoi réseau ne protège pas contre un accès local non autorisé.

N’exposez pas un serveur d’inférence sur Internet sans contrôler son authentification et son environnement. Une interface prévue pour un usage personnel peut devenir accessible à d’autres si elle écoute sur une adresse inadaptée ou si un port est ouvert sans précaution.

Pour des documents sensibles, suivez les règles de votre organisation. Le dossier sur les vérifications avant de coller un document dans une IA aide à examiner le traitement. L’installation locale peut modifier certaines réponses, mais elle ne supprime pas le besoin de validation.

Télécharger un modèle avec sa licence et sa provenance

Un fichier disponible publiquement n’est pas nécessairement utilisable dans toutes les activités. Consultez la licence du modèle, celle des éléments associés et les conditions correspondant à votre usage. La licence du logiciel d’exécution ne remplace pas celle du modèle.

Vérifiez le dépôt d’origine, la version et les informations publiées par les responsables. Évitez les archives qui ajoutent des exécutables inattendus. Les formats et les outils peuvent présenter des contraintes de sécurité ; utilisez des logiciels maintenus et suivez leurs consignes.

Conservez l’identifiant du fichier ou son empreinte lorsque cela aide à reproduire la configuration. Vous pourrez ainsi distinguer une mise à jour du modèle d’une modification de réglage. Cette traçabilité est particulièrement utile pour un usage collectif.

Lisez aussi les limites décrites dans la fiche du modèle. Les langues, les tâches et les conditions d’évaluation annoncées ne constituent pas une certification pour votre application. Elles orientent les essais à réaliser.

Un pilote local en cinq contrôles

Choisissez d’abord une tâche courte et un jeu d’exemples autorisés. Installez un moteur compatible depuis son canal officiel, puis un modèle dont la licence et les besoins correspondent à votre contexte. Gardez les options simples pour le premier essai.

Contrôlez ensuite la qualité, les délais, la mémoire, les connexions et les données conservées. Ajoutez progressivement un document plus long ou une seconde requête seulement après avoir compris le comportement initial. Les modifications doivent répondre à une observation.

Pour un usage professionnel, définissez qui vérifie les réponses et comment une version sera remplacée. Gardez une procédure pour revenir à la configuration précédente. Une mise à jour peut améliorer certains usages tout en dégradant un cas important.

L’IA locale devient un outil utile lorsqu’elle répond à une tâche évaluée sur une machine compatible. La mémoire et la vitesse sont des contraintes, mais la qualité, la confidentialité réelle et l’entretien pèsent autant. Acheter davantage de matériel doit venir après un besoin mesuré, pas avant la définition du résultat attendu.

Une grille de qualité plus utile qu’une impression générale

Pour une extraction, comptez les champs exacts, les champs absents correctement signalés et les valeurs inventées. Pour une synthèse, vérifiez que les conditions importantes sont présentes et que les chiffres restent associés à leur période et à leur unité. Pour une explication de code, confrontez les affirmations au programme et à des tests appropriés. Attribuez une gravité aux erreurs : une formulation maladroite ne pèse pas autant qu’un montant incorrect. Conservez quelques exemples échoués pour les rejouer après un changement de configuration, en gardant également des cas nouveaux afin de ne pas mesurer uniquement une adaptation aux anciens tests.