Faire tourner des LLM sur votre propre matériel

L'année dernière, j'ai dépensé 4 200 $ pour monter une machine d'inférence locale capable de faire tourner un modèle de 70 milliards de paramètres à une vitesse raisonnable. Un collègue a regardé mon installation et m'a posé la question évidente : « Pourquoi ne pas simplement utiliser l'API ? C'est l'équivalent de huit ans de crédits API. » Il n'avait pas tort sur les chiffres. Mais il se trompait sur l'équation globale.

Faire tourner de grands modèles de langage en local était autrefois le domaine des laboratoires de recherche dotés de grappes de GPU en rack. Les choses ont vite changé. Le matériel grand public, les techniques de quantification et les moteurs d'inférence optimisés ont rendu les modèles de 70B+ accessibles aux passionnés et aux petites équipes. Des appareils comme la Tinybox vont encore plus loin : du matériel conçu spécifiquement pour faire tourner des modèles de 120 milliards de paramètres hors ligne, sans cloud.

Mais « possible » et « pratique » ne sont pas la même chose. Voyons ce qu'il faut vraiment pour exécuter de grands modèles en local, quand cela a du sens, et quand il vaut mieux payer une API.

Pourquoi exécuter des modèles en local, au juste ?

Le modèle API — envoyer vos données à un fournisseur cloud et récupérer les résultats — convient à la plupart des cas d'usage. C'est plus simple, moins cher par requête à faible volume, et vous donne toujours accès aux derniers modèles. Alors pourquoi quelqu'un s'embêterait-il avec l'inférence locale ?

Confidentialité et conformité. Certaines données ne peuvent pas quitter votre réseau. Dossiers médicaux, documents juridiques, code propriétaire, données financières : les secteurs réglementés ont souvent des exigences strictes en matière de résidence des données. Envoyer des dossiers de patients vers un point de terminaison API, même chiffré, peut enfreindre la HIPAA. L'inférence locale garde tout sur site.
Latence. Les appels API impliquent des allers-retours réseau, des temps d'attente potentiels en file et des limitations de débit. L'inférence locale n'a aucune latence réseau et vous ne faites jamais la queue. Pour les applications interactives — assistants de code en temps réel, traduction embarquée, interfaces vocales —, la différence entre 50 ms et 500 ms sépare « réactif » de « poussif ».
Coût à grande échelle. La tarification API se fait au token. À faible volume, c'est négligeable. À fort volume, cela grimpe brutalement. Une équipe qui fait beaucoup de revue de code, d'analyse de documents ou de traitement par lots peut dépenser plusieurs milliers de dollars par mois en API. Le matériel local a un coût fixe : une fois payé, l'inférence est pratiquement gratuite.
Disponibilité. Les API cloud tombent en panne. Des limites de débit sont imposées. Les tarifs changent sans préavis. Des modèles sont dépréciés. Si votre produit dépend d'une API tierce, vous êtes à la merci de leurs décisions commerciales. L'inférence locale fait que vos capacités ne disparaissent pas parce que le serveur de quelqu'un d'autre a une mauvaise journée.
Liberté d'expérimentation. Les fournisseurs d'API ont des politiques d'utilisation. Ils décident de ce que vous pouvez ou ne pouvez pas faire avec le modèle. Les modèles locaux n'ont pas de telles restrictions : vous pouvez les affiner, les modifier, les utiliser à toutes fins et les exécuter autant de fois que vous le souhaitez.

La réalité du matériel

La contrainte fondamentale de l'inférence LLM est la mémoire, pas le calcul. Les paramètres d'un modèle doivent tenir en mémoire (VRAM du GPU ou RAM système) avant que vous puissiez faire quoi que ce soit. Un modèle de 70 milliards de paramètres en virgule flottante 16 bits nécessite environ 140 Go de mémoire. C'est plus que ce qu'offre n'importe quel GPU grand public.

C'est là que la quantification change la donne. En réduisant la précision des poids du modèle de 16 bits à 8 bits, 4 bits, voire 2 bits, vous pouvez réduire considérablement les besoins en mémoire :

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

La quantification 4 bits (Q4_K_M dans l'écosystème llama.cpp) est le compromis actuel idéal. La dégradation de qualité est mesurable mais souvent acceptable en pratique : la plupart des gens ne peuvent pas distinguer une sortie Q4 de la pleine précision lors de tests en aveugle. La quantification 2 bits affecte nettement la qualité, surtout sur les tâches de raisonnement, mais reste utilisable pour des applications plus simples comme la classification de texte ou le résumé.

Configurations matérielles grand public

Si vous montez votre propre installation d'inférence locale, vous avez trois grandes options, chacune avec un rapport prix/performance différent.

La voie du GPU unique

Un RTX 4090 (24 Go de VRAM, environ 1 600 $) peut faire tourner confortablement des modèles quantifiés 4 bits jusqu'à environ 30 milliards de paramètres, ou des modèles de 70 milliards en quantification 2 bits agressive. Pour la plupart des modèles de 7 à 13 milliards, c'est exagéré : vous obtiendrez plus de 40 tokens par seconde, soit plus vite que la plupart des gens ne peuvent lire. C'est la voie la plus simple : acheter un GPU, installer llama.cpp ou Ollama, et c'est parti.

La voie multi-GPU

Deux GPU ou plus permettent de répartir un modèle sur plusieurs appareils (parallélisme tensoriel). Deux RTX 3090 (48 Go de VRAM au total, environ 2 200 $ d'occasion) peuvent faire tourner confortablement des modèles 70B en 4 bits. Le piège : il faut une carte mère avec suffisamment de lignes PCIe et de l'espace physique pour plusieurs GPU de taille réelle. Le flux d'air devient un vrai problème : deux GPU de 350 W dans un boîtier dégagent beaucoup de chaleur.

La voie de la mémoire unifiée

Les Mac à puce Apple Silicon dotés d'une grande mémoire unifiée offrent une option étonnamment viable. Un M2 Ultra avec 192 Go de mémoire unifiée peut loger en entier un modèle 70B en pleine précision. La vitesse d'inférence est inférieure à celle des GPU dédiés — environ 10 à 15 tokens par seconde pour un modèle 70B — mais la simplicité est difficile à battre. Pas de soucis de pilotes, pas de configuration multi-GPU, pas de gestion thermique. Juste un Mac Studio posé sur votre bureau qui fait tourner un modèle 70B.

Les puces de la série M y parviennent grâce à l'architecture de mémoire unifiée : le CPU et le GPU partagent le même pool de mémoire, donc aucun goulot d'étranglement lié à la copie de données entre la RAM du CPU et la VRAM du GPU. La bande passante mémoire est inférieure à celle d'une configuration GPU dédiée, ce qui explique la lenteur de l'inférence, mais disposer de 192 Go de mémoire adressable dans un appareil qui consomme 60 watts est vraiment impressionnant.

Les appareils d'inférence dédiés

La catégorie la plus récente est celle du matériel d'inférence locale conçu spécifiquement — des appareils dédiés pensés pour faire tourner efficacement de grands modèles. Ils visent à résoudre les tracas du multi-GPU : au lieu d'assembler des GPU grand public avec des nuits de gestion de câbles, vous obtenez un appareil conçu dès le départ pour l'inférence.

L'attrait est évident. Vous le branchez, vous pointez votre application vers lui, et il fait tourner votre modèle. Pas de conflits de pilotes, pas de gestion de versions CUDA, pas de throttling thermique parce qu'on a placé trois GPU trop près les uns des autres. Le compromis est le coût : les appareils dédiés coûtent généralement plus cher par FLOP que des GPU grand public équivalents. Vous payez l'intégration, la fiabilité, et le fait de ne pas avoir à déboguer l'allocation des lignes PCIe.

Pour les petites entreprises qui ont besoin d'inférence locale sans ingénieurs matériel en interne, ces appareils ont du sens. Pour les bidouilleurs qui aiment construire des choses, les installations multi-GPU artisanales restent moins chères et plus flexibles.

La pile logicielle

Le matériel ne fait que la moitié de l'histoire. La pile logicielle d'inférence a évolué rapidement, et le bon choix logiciel peut doubler votre débit sur le même matériel.

llama.cpp — Le couteau suisse de l'inférence locale. Écrit en C/C++, il fonctionne sur tout, des Raspberry Pi aux serveurs multi-GPU. Il prend en charge des dizaines d'architectures de modèles et de formats de quantification. Pas toujours le plus rapide, mais le plus portable et activement maintenu.
vLLM — Optimisé pour le débit sur GPU NVIDIA. Il utilise PagedAttention pour gérer efficacement la mémoire GPU, ce qui améliore fortement l'inférence par lots. Si vous servez plusieurs utilisateurs depuis une seule machine, vLLM est généralement le meilleur choix.
Ollama — L'approche « Docker pour les LLM ». Il enveloppe llama.cpp dans une interface conviviale avec un registre de modèles. Lancez ollama run llama3:70b et il télécharge le modèle, configure la quantification et démarre le service. Excellent pour démarrer, mais moins configurable que llama.cpp brut.
MLX — Le framework de machine learning d'Apple, optimisé pour Apple Silicon. Si vous êtes sur un Mac de la série M, MLX offre généralement de meilleures performances que llama.cpp en exploitant plus efficacement l'architecture de mémoire unifiée.

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

Le comparatif de coûts honnête

Faisons les calculs qui comptent vraiment. Supposons que vous fassiez tourner un modèle 70B et traitiez environ 1 million de tokens par jour (soit à peu près l'analyse de 50 à 100 documents ou le traitement de quelques centaines de conversations).

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

À 1 million de tokens par jour, l'API cloud reste moins chère pendant des années. Mais ce calcul change radicalement si votre volume augmente. À 10 millions de tokens par jour, l'API coûte 7 200 $ par an et le matériel local est amorti en environ 7 mois. À 50 millions de tokens par jour, l'inférence locale se rentabilise en quelques semaines.

Le comparatif de coûts ignore aussi les facteurs non financiers : confidentialité, latence, disponibilité et liberté d'expérimentation. Si l'un d'eux constitue une exigence (et non un simple souhait), la comparaison financière passe au second plan.

Ce que la quantification fait perdre

La quantification rend possible l'inférence locale de grands modèles, mais elle n'est pas gratuite. Réduire la précision signifie perdre une partie de l'information, et la dégradation n'est pas uniforme selon les tâches.

Lors de mes tests, les modèles quantifiés en 4 bits se comportent presque à l'identique de la pleine précision pour la génération de texte, le résumé, les questions-réponses simples, la traduction et la génération de code pour les schémas courants. La dégradation apparaît sur : le raisonnement complexe en plusieurs étapes, le calcul mathématique, les tâches nécessitant un rappel précis des données d'entraînement, et le suivi nuancé des instructions.

Conséquence pratique : si vous utilisez un modèle local pour la complétion de code, le résumé de documents ou l'IA conversationnelle, la quantification 4 bits convient parfaitement. Si vous l'utilisez pour du raisonnement analytique complexe ou pour des tâches où les subtiles différences de précision comptent, testez soigneusement et envisagez une précision supérieure, au prix d'une mémoire plus importante ou d'un modèle plus petit.

Prendre la décision

Après un an à faire tourner des modèles en local, voici mon cadre de décision entre inférence locale et cloud :

Utilisez les API cloud quand : vous avez besoin de la meilleure qualité de modèle possible, votre volume est faible à modéré, vous n'avez pas d'expertise matérielle, vous devez changer souvent de modèle, ou la latence n'est pas critique (quelques centaines de millisecondes, c'est acceptable).

Exécutez en local quand : vos données ne peuvent pas quitter votre réseau, vous avez besoin d'une latence constante inférieure à 100 ms, votre volume de tokens est assez élevé pour justifier le coût du matériel, vous voulez expérimenter librement sans coût par requête, ou vous avez besoin d'une disponibilité indépendante des pannes d'un tiers.

Le paysage évolue vite. Les modèles deviennent plus petits et plus efficaces. Les techniques de quantification s'améliorent. Le matériel devient moins cher. Le seuil de volume à partir duquel l'inférence locale a du sens financier baisse chaque année. Si cela n'a pas de sens pour vous aujourd'hui, ce sera peut-être le cas dans dix-huit mois — et la pile logicielle ne fera que devenir plus simple à utiliser d'ici là.