Pas besoin de GPU à 2 000 € : faire tourner un LLM rapide sur ton PC ou ton serveur

Tu veux une IA locale, mais la première recherche t’envoie immédiatement vers des cartes graphiques hors de prix, des alimentations de centrale nucléaire et des tableaux de benchmarks incompréhensibles. Mauvaise nouvelle pour les vendeurs de GPU : ce n’est pas obligatoire. Pour discuter, résumer des documents, écrire du code ou interroger tes notes, un PC classique avec suffisamment de mémoire peut déjà faire tourner un modèle de langage performant.

Le mot important n’est pas « GPU ». C’est mémoire. Un modèle local doit charger ses paramètres en RAM, en mémoire vidéo ou dans la mémoire unifiée d’un Mac. Si le modèle tient, il répond. S’il déborde, le système commence à déplacer des données vers le disque et ton assistant se transforme en diaporama.

Le matériel qui compte vraiment

Un modèle de langage, ou LLM, est un logiciel qui génère du texte à partir d’une suite de tokens. Ses paramètres représentent les connaissances et les capacités apprises pendant son entraînement. Plus un modèle possède de paramètres, plus il peut être compétent sur certaines tâches, mais plus il réclame de mémoire.

Pour une utilisation locale quotidienne, les repères sont assez simples :

• 8 Go de RAM : petits modèles de 2 à 4 milliards de paramètres, tâches simples et contexte court ;

• 16 Go de RAM : modèles de 7 à 8 milliards, bon point de départ sur un PC sans GPU ;

• 32 Go de RAM : modèles de 13 à 14 milliards, meilleur confort pour le code et les documents ;

• 64 Go et plus : modèles de 30 milliards et davantage, avec un contexte plus généreux.

Ces chiffres concernent la mémoire disponible pour le modèle, pas seulement la quantité annoncée sur la boîte. Si ton navigateur, Docker, un éditeur et plusieurs applications occupent déjà 10 Go, un PC équipé de 16 Go ne dispose pas réellement de 16 Go pour l’IA.

Le stockage compte aussi. Un SSD NVMe accélère le chargement initial du modèle, mais il ne remplace pas la RAM pendant la génération. Un modèle qui tient uniquement grâce au swap fonctionnera peut-être, mais avec une latence qui donne envie de retourner au courrier papier.

La quantification fait rentrer les gros modèles dans le quotidien

La quantification consiste à stocker les paramètres avec moins de précision. Au lieu de conserver chaque valeur en virgule flottante sur 16 bits, on peut utiliser 8, 6 ou 4 bits. Le modèle prend alors beaucoup moins de place, avec une perte de qualité variable selon la méthode et la tâche.

Dans les catalogues de modèles, tu verras souvent des noms comme Q4_K_M, Q5_K_M ou Q8_0. Ce sont des formats quantifiés utilisés notamment par llama.cpp et les outils qui s’appuient sur GGUF. Pour commencer, Q4_K_M offre généralement un compromis raisonnable entre mémoire et qualité. Pour du code ou des réponses techniques, Q5 ou Q6 peut être intéressant si la mémoire suit.

À la louche, un modèle de 7 milliards de paramètres en Q4 occupe environ 4 à 5 Go. Un 13 ou 14 milliards demande plutôt 8 à 10 Go. Un 30 milliards se rapproche de 20 Go, et un 70 milliards dépasse généralement 40 Go en Q4. Il faut ajouter la mémoire du contexte, appelée KV cache : c’est la zone où le moteur conserve les informations déjà traitées pendant la conversation.

C’est la raison pour laquelle une machine peut charger un modèle mais ralentir dès que tu lui colles un long document. Le modèle tient, mais l’historique de la conversation remplit le reste. Augmenter le contexte à 128 000 tokens parce que le bouton existe est une excellente façon de saturer sa mémoire sans améliorer une question de trois lignes.

Ollama, LM Studio et Open WebUI : trois outils, trois usages

Ollama est un moteur local qui télécharge, charge et expose des modèles via une interface simple et une API. Il fonctionne sur CPU et sait exploiter différents accélérateurs matériels quand ils sont disponibles. Sa force est sa sobriété : tu peux lancer un modèle depuis le terminal, l’appeler depuis un script ou le connecter à une autre application.

Ollama indique la répartition réelle de la charge avec `ollama ps`. Tu peux ainsi vérifier si le modèle est chargé à 100 % sur le GPU, à 100 % en mémoire système ou partagé entre CPU et GPU. Cette information vaut mieux qu’une promesse marketing dans une fiche produit.

LM Studio vise davantage le confort de bureau. L’application permet de chercher des modèles, de les télécharger, de modifier les paramètres et d’exposer une API compatible avec les outils existants. La documentation recommande au moins 16 Go de RAM et environ 4 Go de mémoire vidéo dédiée comme base raisonnable, tout en précisant que le modèle choisi reste le facteur principal.

LM Studio peut aussi fonctionner sans rester attaché à son interface graphique grâce à son daemon `llmster`. Cela le rend plus intéressant pour un serveur ou une machine distante. Sur Apple Silicon, le moteur MLX exploite la mémoire unifiée : les 16, 32 ou 64 Go de la machine servent à la fois de mémoire système et de mémoire accélérateur.

Open WebUI n’est pas le moteur d’inférence. C’est l’interface web qui se connecte à Ollama ou à un serveur compatible avec l’API OpenAI. Elle apporte les conversations, les comptes utilisateurs, la gestion des modèles, la recherche dans des documents et des fonctions de partage. Tu peux donc avoir Ollama sur un serveur et Open WebUI accessible depuis un navigateur, sans envoyer automatiquement le contenu à un fournisseur externe.

Cette séparation est utile. Ollama fait tourner le modèle. Open WebUI organise l’usage. Le moteur peut changer sans devoir reconstruire toute l’interface.

Sans GPU, oui. Sans compromis, non.

Un bon processeur moderne peut faire tourner un modèle de 7 ou 8 milliards de paramètres en quantification Q4. Pour de la rédaction, des résumés, des questions-réponses et un peu de code, c’est parfaitement exploitable. La vitesse dépendra du processeur, du nombre de cœurs, de la bande passante mémoire et du moteur utilisé, mais une réponse à quelques dizaines de tokens par seconde paraît déjà instantanée dans une conversation normale.

Le GPU devient utile dès que tu veux plus de débit, plusieurs utilisateurs, de longs contextes ou des modèles plus gros. Une carte avec 8 à 12 Go de VRAM peut offrir un excellent équilibre pour les modèles de 7 à 14 milliards. Une RTX 4090 devient pertinente pour des charges lourdes, pas pour demander à une IA de reformuler un courriel.

Le piège classique consiste à acheter une carte trop puissante pour un modèle trop grand. Si le modèle ne tient pas dans la VRAM, le moteur peut en charger une partie dans la RAM. Cela fonctionne, mais les transferts entre mémoire vidéo et mémoire système réduisent souvent le bénéfice de la carte. Une configuration équilibrée avec 32 Go de RAM et une carte moyenne peut être plus agréable qu’une carte très chère coincée avec un modèle qui déborde partout.

Sur un serveur, le CPU peut même être le choix le plus logique. Il consomme moins, coûte moins cher et suffit pour un usage personnel intermittent. Pour un service ouvert à plusieurs utilisateurs, la situation change : la mémoire nécessaire augmente avec le nombre de requêtes simultanées et la taille du contexte. Le même modèle qui répond très bien à une personne peut mettre un serveur à genoux avec quatre conversations longues.

Choisir un modèle sans se faire hypnotiser par un classement

Les classements comme l’Open LLM Leaderboard de Hugging Face sont utiles pour comparer des scores, mais ils ne répondent pas directement à la question « quel modèle est agréable sur ma machine ? ». Les résultats dépendent de la précision, du prompt, du benchmark et de la version évaluée. Un modèle très bien classé peut être trop lent, trop gros ou mal adapté à ton usage.

Commence par la tâche, pas par le nombre de paramètres. Pour discuter et résumer, un petit modèle généraliste récent peut suffire. Pour programmer, privilégie un modèle spécialisé capable de suivre un contexte de dépôt. Pour analyser des documents, regarde la longueur de contexte et la qualité de la récupération d’informations. Pour utiliser des images, il faut un modèle multimodal et parfois un fichier de projection supplémentaire.

Télécharge ensuite une version GGUF adaptée à ta mémoire. Q4 est un point de départ raisonnable. Si les réponses sont trop approximatives, teste Q5 ou un modèle légèrement plus petit. Le bon modèle local n’est pas celui qui bat tout le monde dans un tableau : c’est celui qui répond assez bien, assez vite, sans faire chauffer la machine pour une question banale.

Un conseil de méthode vaut mieux qu’une liste figée de modèles. Teste trois tâches réelles : un texte à résumer, un problème de code et une consigne longue avec plusieurs contraintes. Mesure la vitesse, les erreurs et la stabilité. Après vingt minutes d’essai, tu en sauras plus qu’après deux heures de vidéos comparant des cartes graphiques.

La confidentialité n’est pas automatique

Faire tourner un LLM local réduit fortement l’exposition des conversations, mais cela ne transforme pas magiquement ton installation en coffre-fort. Si Open WebUI est exposé directement sur Internet, si le serveur utilise des extensions douteuses ou si les journaux restent accessibles, la confidentialité peut partir par la fenêtre.

Un déploiement sérieux doit limiter l’accès réseau, utiliser une authentification robuste, maintenir les composants à jour et éviter d’exposer directement le port d’Ollama. Les documents ajoutés à une base de recherche doivent être protégés comme n’importe quelle donnée sensible. Local signifie que l’inférence se déroule chez toi. Cela ne signifie pas que toute l’architecture est sûre par défaut.

Pour un usage personnel, le trio Ollama, un modèle quantifié adapté et Open WebUI offre déjà une expérience très convaincante. Pour un serveur domestique ou un petit VPS, un modèle de 7 ou 8 milliards en Q4 est souvent plus raisonnable qu’un modèle géant qui monopolise toute la mémoire. Et pour un poste de travail, ajouter de la RAM peut parfois apporter davantage qu’acheter une carte graphique hors de prix.

Le meilleur accélérateur local n’est donc pas toujours une carte graphique. C’est parfois un modèle plus petit, une quantification correcte et un contexte qui ne cherche pas à avaler Internet. L’IA locale ne demande pas forcément un compte en banque blindé. Elle demande surtout de choisir un modèle qui tient dans la machine que tu possèdes déjà.

Sources

• Ollama — Context length — https://docs.ollama.com/context-length — rôle du contexte, mémoire nécessaire et vérification du placement CPU/GPU.

• Ollama — FAQ — https://docs.ollama.com/faq — chargement des modèles, mémoire, traitement parallèle et quantification du KV cache.

• LM Studio — System Requirements — https://lmstudio.ai/docs/app/system-requirements — prérequis matériels pour Windows, Linux et Apple Silicon.

• LM Studio — Improving the MLX Engine for Agentic Workflows — https://lmstudio.ai/blog/mlx-engine-agentic-workloads — réduction de l’usage mémoire et cache de contexte sur Apple Silicon.

• Open WebUI — Documentation — https://docs.openwebui.com/ — interface auto-hébergée, fonctionnement hors ligne et connexion à Ollama.

• Hugging Face — Open LLM Leaderboard FAQ — https://huggingface.co/docs/leaderboards/main/open_llm_leaderboard/faq — interprétation des scores et impact de la précision des modèles.

• Hugging Face — Leaderboards and Evaluations — https://huggingface.co/docs/leaderboards/main/index — limites et rôle des classements de modèles ouverts.

—

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.