Un premier essai d’IA locale ne nécessite pas d’acheter immédiatement un nouveau serveur. Un ordinateur existant peut montrer si un modèle de langage plus petit fournit des résultats utiles pour la tâche prévue. Pour le travail quotidien, les temps d’attente, la capacité disponible et une exploitation fiable comptent ensuite également.
La première question est donc : que doit faire le modèle ? Une courte révision de texte n’a pas les mêmes exigences que l’analyse de longs documents, un travail de programmation conséquent ou l’utilisation simultanée par plusieurs personnes. « Le modèle démarre » est un premier constat technique. Cela ne suffit pas encore à définir un poste ou un service d’entreprise adapté.
Ce qui est possible sans carte graphique particulière
Les modèles de langage peuvent fonctionner sur un CPU pris en charge. Le moteur d’exécution llama.cpp prend en charge différentes plateformes de processeurs ainsi que la répartition du travail entre CPU et GPU. Un GPU n’est donc pas un prérequis universel pour chaque essai, même s’il peut accélérer sensiblement le traitement. La différence réelle se mesure avec la tâche choisie. llama.cpp : matériel pris en charge et exécution (lien externe).
Un essai sur CPU peut par exemple servir à rédiger un brouillon à partir de notes non sensibles, à structurer une courte note ou à évaluer un petit exemple de code. Le modèle doit convenir à la langue et au sujet. Une longue entrée, une réponse exigeante ou une seconde requête simultanée peuvent modifier fortement un résultat initialement utile pour une seule personne.
32 ou 64 Go de RAM : des scénarios de dimensionnement, pas un minimum universel
Les niveaux suivants sont délibérément présentés comme des exemples. Ils ne remplacent ni la vérification du fichier précis du modèle ni un test de charge. De plus petits modèles peuvent nécessiter moins de mémoire ; de plus grands modèles, de longs contextes ou plusieurs services peuvent en demander beaucoup plus.
| Niveau d’évolution | Base donnée à titre d’exemple | Ce que le test doit établir |
|---|---|---|
| Évaluer l’ordinateur existant | CPU pris en charge, par exemple 32 Go de RAM et suffisamment d’espace libre sur SSD ; sans GPU supplémentaire au départ. | Un modèle plus petit convient-il au sujet ? L’attente est-elle acceptable pour quelques tâches courtes ? |
| Poste utilisé régulièrement | Par exemple 32–64 Go de RAM, un SSD NVMe et un GPU choisi selon le modèle et le contexte. | Le travail reste-t-il fluide lorsque d’autres applications fonctionnent en parallèle et que les entrées s’allongent ? |
| Service partagé | Ressources dédiées ; par exemple 64 Go de RAM système comme point de départ du dimensionnement, une accélération adaptée et une exploitation organisée. | Quels niveaux d’utilisation simultanée, de qualité des réponses et de disponibilité sont atteignables en charge réelle ? |
64 Go de RAM système ne remplacent pas une mémoire graphique suffisamment grande. De même, un fichier de modèle qui tient sur le SSD ne prouve pas que le modèle complet avec le contexte souhaité tiendra dans le GPU. Sur les systèmes à mémoire partagée, il faut examiner la répartition de l’ensemble de la mémoire.
Pourquoi la taille du modèle ne suffit pas
Un calcul simple illustre l’ordre de grandeur : huit milliards de paramètres avec quatre bits théoriques par paramètre donnent 8 000 000 000 × 4 ÷ 8 = 4 000 000 000 octets, soit environ 4 Go ou 3,73 Gio pour les seuls poids. Ce n’est pas le besoin mémoire complet d’un modèle exécutable.
S’y ajoutent notamment les informations de quantification, les parties stockées dans d’autres formats, les tampons d’exécution et la mémoire du contexte. Le fichier réel et le moteur choisi sont déterminants. GGUF contient par exemple des métadonnées en plus des tenseurs et prend en charge différents formats de quantification. Hugging Face : GGUF et quantification (lien externe).
Une fenêtre de contexte plus grande nécessite davantage de mémoire. La longueur d’entrée souhaitée est donc explicitement consignée dans le test. Une courte conversation avec une petite entrée renseigne peu sur le travail ultérieur avec de longs documents. Ollama : longueur du contexte et besoin mémoire (lien externe).
Un GPU doit convenir à l’ensemble de l’environnement
Le choix dépend de la mémoire graphique utilisable, des pilotes et du moteur pris en charge, de la consommation électrique, du refroidissement et des contraintes d’installation. Deux cartes aux noms commerciaux proches peuvent disposer de quantités de mémoire différentes. Une carte reconnue par le système d’exploitation n’est pas nécessairement correctement exploitée par le moteur du modèle souhaité.
Avant l’achat, le modèle exact de carte, le système d’exploitation et la version du pilote sont donc comparés à la prise en charge actuelle du moteur. Ollama documente différentes possibilités pour NVIDIA, AMD, Apple Metal et d’autres moteurs. Cela ne signifie pas que toutes les cartes d’une marque sont prises en charge. Ollama : matériel actuellement pris en charge (lien externe).
Ce qu’apportent NVMe et Linux
Un SSD NVMe est une option pertinente pour les fichiers de modèles locaux, les mises à jour et les données de travail. L’espace libre est réservé aux modèles réellement utilisés et aux versions supplémentaires. Un disque plus grand ne remplace toutefois ni la RAM ni la mémoire graphique ; même un SSD rapide ne rend pas automatiquement interactif un modèle trop volumineux.
Linux peut convenir à un service exploité en continu si les pilotes, la maintenance et les responsabilités sont adaptés à l’entreprise. Ollama décrit notamment son fonctionnement comme service système dédié. Le système d’exploitation est choisi en fonction de l’environnement existant ; il n’est pas nécessaire de le déployer sur chaque poste. Ollama : exploitation sous Linux et suivi des versions (lien externe).
Un court pilote fournit une meilleure liste d’achats
- Définir une tâche : par exemple rédiger un brouillon à partir de notes approuvées avant de connecter l’ensemble de la base de connaissances.
- Consigner les conditions du test : version du modèle, quantification, contexte, matériel et autres applications en cours d’exécution.
- Évaluer les résultats : exactitude du contenu, corrections nécessaires et travail réellement économisé.
- Mesurer les temps d’attente : entrées habituelles et plus longues, ainsi que l’utilisation simultanée attendue.
- Vérifier aussi l’exploitation : circulation des données, autorisations, mises à jour, sauvegarde et remise en service.
La démarche de test détaillée est décrite dans l’article Tester l’IA locale : un pilote avec une charge représentative. Pour passer à un service partagé, Ollama et Open WebUI dans le réseau d’entreprise explique la répartition entre accès, interface et modèle.
Bien utiliser l’existant et le compléter de façon ciblée
Un ordinateur existant peut suffire pour commencer. Si le pilote démontre une utilité solide, on peut ensuite effectuer une mise à niveau ciblée ou prévoir un service dédié. Pour les tâches rares ou particulièrement exigeantes, une API cloud approuvée ou un modèle hybride peut aussi être économiquement pertinent. Les données, la qualité, l’utilisation et l’effort d’exploitation sont déterminants.
DAXS accompagne cette évaluation et l’intégration dans l’informatique existante. Pour commencer, consultez LLM locaux et infrastructure et la demande de conseil en IA et automatisation.
Sources : les valeurs de mémoire sont des scénarios de dimensionnement explicitement décrits ou un calcul théorique des poids. Elles ne constituent ni un benchmark, ni une offre de prix, ni la preuve de la prise en charge d’un nombre donné d’utilisateurs. La licence du modèle précis et la compatibilité du système sont vérifiées avant utilisation.
