Il existe une catégorie de tâches pour lesquelles faire tourner un LLM en local ne relève ni de la prouesse technique ni de la posture militante : c'est simplement la solution la plus économique et la plus prévisible. Classer des messages entrants, extraire trois champs d'un devis, reformuler un paragraphe, détecter une langue : sur ce terrain, un modèle de sept milliards de paramètres tournant sur une machine de bureau fait le travail, sans facture au jeton et sans données qui sortent du réseau.
Le réflexe inverse domine pourtant. Quand un besoin d'IA apparaît, on branche l'API d'un grand fournisseur, on met une clé dans un fichier de configuration, et l'affaire est réglée en vingt minutes. C'est un bon réflexe pour prototyper. C'en est un mauvais quand le volume monte, quand la latence compte, ou quand les données traitées n'ont rien à faire chez un tiers.
Cet article trace la frontière. Quelles tâches un petit modèle de langage traite correctement, quel matériel il faut vraiment, quelle latence attendre, et à partir de quel volume le calcul bascule en faveur du local. Avec une conclusion qui ne fera plaisir à personne : les deux approches cohabitent, et le tri se fait tâche par tâche, pas par principe.
Ce que « faire tourner un LLM en local » veut dire concrètement
Un modèle de langage local, c'est un fichier de quelques gigaoctets posé sur un disque, et un programme qui le charge en mémoire pour produire du texte. Rien de plus. Trois briques suffisent : les poids du modèle, un moteur d'inférence, et une interface pour l'appeler.
- Les poids se téléchargent librement pour les modèles ouverts. Ils sont distribués en plusieurs tailles, exprimées en milliards de paramètres : 1, 3, 7, 8, 14, 30 et au-delà.
- La quantisation réduit la précision des poids pour les faire tenir en mémoire. Un modèle de 7 milliards de paramètres pèse environ 14 Go en précision native, et autour de 4,5 Go en quantisation 4 bits, pour une perte de qualité modérée sur les tâches simples.
- Le moteur expose souvent une interface compatible avec celle des grandes API. Concrètement, votre code existant change d'adresse et de nom de modèle, pas de structure.
Ce dernier point est décisif pour l'expérimentation : passer d'un appel distant à un modèle local, puis revenir en arrière, coûte une ligne de configuration. Rien n'oblige à choisir son camp avant d'avoir mesuré.
Les trois familles de tâches où un petit modèle de langage suffit
La qualité d'un modèle ne se mesure pas dans l'absolu, mais sur une tâche donnée. Trois familles passent presque toujours l'épreuve du local.
La classification
Ranger un message dans une catégorie parmi cinq, détecter une intention, repérer un ton hostile, dire si un document est une facture ou un contrat. La sortie attendue est courte et fermée, la marge d'erreur est mesurable, et un modèle de 3 à 8 milliards de paramètres atteint couramment 90 à 95 % d'accord avec un humain sur des catégories bien définies. Le reste du travail consiste à écrire des consignes nettes, ce qui relève de la méthode de rédaction des instructions plus que de la puissance du modèle.
L'extraction structurée
Sortir un numéro de commande, une date, un montant, un nom de société d'un texte non structuré. Là encore, la sortie est courte et vérifiable : un montant est un nombre, une date se valide, un numéro respecte un format. Vous pouvez contrôler automatiquement la sortie et rejouer la requête en cas d'échec, ce qui rattrape une bonne partie des erreurs.
La reformulation courte
Résumer en trois phrases, réécrire dans un registre plus neutre, traduire un fragment, générer un objet de courriel. Les petits modèles s'en sortent bien tant que le texte d'entrée tient en quelques milliers de mots et que l'enjeu de style reste modeste.
À l'inverse, quatre familles restent hors de portée : le raisonnement en plusieurs étapes sur des données chiffrées, la rédaction longue à tenue éditoriale constante, le code non trivial, et tout ce qui demande une connaissance factuelle étendue du monde. Un petit modèle sait manipuler le texte qu'on lui donne, pas se souvenir du monde.
Le matériel réellement nécessaire pour une IA sur son ordinateur
C'est le point où les discussions dérapent le plus vite. Voici des ordres de grandeur constatés sur des machines ordinaires, en quantisation 4 bits, pour de la génération de texte.
| Configuration | Taille de modèle confortable | Débit indicatif |
| Portable bureautique, 8 Go de RAM, sans carte graphique dédiée | 1 à 3 milliards de paramètres | 5 à 15 jetons par seconde |
| Poste de travail, 16 à 32 Go de RAM, processeur récent | 7 à 8 milliards de paramètres | 8 à 20 jetons par seconde |
| Machine à mémoire unifiée, 16 à 32 Go | 7 à 14 milliards de paramètres | 20 à 40 jetons par seconde |
| Serveur avec carte graphique de 12 à 24 Go de mémoire vidéo | 7 à 30 milliards de paramètres | 40 à 100 jetons par seconde |
Deux règles pratiques en découlent. D'abord, la mémoire disponible détermine la taille de modèle possible, pas la vitesse : un modèle qui déborde en mémoire vive s'effondre en performance. Ensuite, un débit de 10 jetons par seconde est inconfortable pour une conversation, mais parfaitement acceptable pour une tâche de fond qui classe deux mille messages pendant la nuit.
C'est le vrai critère : un modèle local en entreprise se juge sur le débit cumulé d'un traitement par lots, pas sur l'impression de fluidité d'un échange interactif.
Coût et latence : local contre appel d'API
Prenons un cas réaliste. Une PME classe 40 000 messages entrants par mois. Chaque appel consomme environ 600 jetons en entrée et 30 en sortie, soit à peu près 25 millions de jetons par mois.
| Poste | Appel d'API, petit modèle hébergé | Modèle local |
| Coût mensuel d'inférence | Quelques euros à quelques dizaines d'euros selon le fournisseur | Électricité et amortissement, de l'ordre de quelques euros |
| Coût d'entrée | Nul | Machine dédiée, de 800 à 3 000 euros |
| Latence par appel | 0,5 à 2 secondes, réseau compris | 1 à 4 secondes, sans dépendance réseau |
| Exploitation | Aucune, hors gestion des clés | Mises à jour, supervision, sauvegarde |
| Confidentialité | Contrat, localisation à vérifier | Rien ne sort du réseau |
Sur ce volume, l'écart de coût brut ne justifie pas à lui seul l'achat d'une machine. Ce qui fait basculer la décision, ce sont les trois autres lignes : la sensibilité des données, la volonté de ne pas dépendre d'une grille tarifaire qui peut changer, et l'existence d'un serveur déjà présent que l'on peut charger davantage. Le raisonnement complet sur la localisation des traitements est développé dans notre article sur l'hébergement de son IA en France.
Un dernier point est souvent oublié : le local supprime la variabilité. Pas de limitation de débit imposée, pas de dépréciation de version, pas de comportement qui change du jour au lendemain sur une consigne que vous aviez affinée. Pour une chaîne de traitement en production, cette stabilité vaut parfois plus que l'économie.
Comment trancher en une demi-journée
La bonne méthode n'est pas de lire des comparatifs, mais de mesurer sur vos données. En quatre étapes.
- Constituez un jeu de 50 cas réels, avec la réponse attendue pour chacun. C'est l'étape qui prend le plus de temps, et c'est la seule qui compte vraiment.
- Faites tourner votre consigne actuelle sur un petit modèle local et sur l'API que vous utilisez déjà. Mêmes entrées, même consigne, même format de sortie.
- Comptez les écarts, en séparant les erreurs graves des approximations tolérables. Un taux d'accord de 92 % contre 96 % ne veut rien dire tant qu'on ne sait pas ce que coûte une erreur.
- Mesurez le débit sur les 50 cas, puis extrapolez à votre volume mensuel. Vous saurez si le traitement tient dans la fenêtre de temps dont vous disposez.
Cette démarche rejoint celle que nous décrivons pour lire un classement de modèles sans se faire avoir : un score public dit ce qu'un modèle sait faire en moyenne, votre jeu de test dit ce qu'il sait faire chez vous. Le second gagne toujours.
Une architecture mixte, plutôt qu'un camp
Les organisations qui s'en sortent le mieux ne choisissent pas. Elles routent : les tâches simples et volumineuses partent sur un modèle local, les tâches rares et exigeantes partent sur une API. Un aiguillage de quelques lignes dans le code suffit, et la bascule reste réversible si un fournisseur change ses conditions. Le raisonnement de fond, entre modèles ouverts et modèles fermés, est détaillé dans notre comparatif modèles ouverts ou API propriétaires.
Un effet de bord agréable mérite d'être signalé : mesurer sérieusement une tâche pour décider s'il faut faire tourner un LLM en local améliore la tâche elle-même. On découvre que la consigne était ambiguë, que trois catégories se recouvrent, que 8 % des cas ne devraient pas passer par un modèle du tout. Le gain est souvent là, avant même le choix de l'infrastructure.
Ce qu'il faut retenir
Commencez par la tâche, pas par la technologie. Si la sortie attendue est courte, fermée et vérifiable, un petit modèle de langage la traitera probablement bien, et le local devient une option sérieuse. Si la tâche demande du raisonnement, de la connaissance ou de l'endurance rédactionnelle, gardez une API et concentrez vos efforts ailleurs.
Le test tient en une demi-journée : 50 cas réels, deux moteurs, un tableau d'écarts. À l'issue, vous saurez si faire tourner un LLM en local vous fait gagner de l'argent, de la latence, de la confidentialité, ou rien du tout. Dans ce dernier cas, vous aurez au moins un jeu de test qui servira à toutes vos décisions suivantes.
Laisser un commentaire