- Un dépôt regroupe la configuration matérielle, les réglages du switch PCIe et la configuration d’exécution Docker pour faire tourner localement des LLM de pointe et de la conversion voix-texte
- Un budget d’environ 2 k$ vise une configuration avec 2× RTX 3090 pour obtenir 48 Go de VRAM et exécuter Qwen3.6-27B ainsi qu’un STT local basé sur
whisper-large-v3
- Un budget d’environ 40 k$ part d’une configuration avec 4× RTX PRO 6000 Blackwell Workstation pour obtenir 384 Go de VRAM et un niveau d’intelligence de modèle assez proche de Claude Opus
- Le système réel à 4× RTX 6000 Pro combine une machine d’occasion basée sur EPYC/DDR4 avec un switch PCIe Gen4 c-payne afin de gérer les communications P2P entre GPU dans le fabric du switch plutôt que via le root complex CPU
- Après réglage du BIOS, de GRUB, de l’ACS et des limites de puissance, le P2P atteint 27,5 Go/s en unidirectionnel, 50,4 Go/s en bidirectionnel, avec une latence de 0,37–0,45 µs, soit le débit de ligne Gen4
Tranches de budget pour exécuter des LLM en local
- Cette configuration s’adresse aux utilisateurs qui veulent faire tourner localement des modèles de pointe et de la conversion voix-texte
- Le dépôt inclut le matériel utilisé, les raisons d’achat, des conseils de configuration, la manière d’exécuter un STT local et une configuration d’exécution de modèles basée sur des conteneurs Docker
- Une note précise que tout le contenu, sauf les tableaux du README, n’a pas été rédigé par une IA
-
Configuration autour de 2 k$
- Une configuration avec 2× RTX 3090 est proposée pour obtenir 48 Go de VRAM au total
- Cette configuration permet d’exécuter Qwen3.6-27B
- Le STT local utilise whisper-large-v3, avec le harnais multiplateforme
stt pour l’accès
./runners/stt contient une configuration STT prête à l’emploi qui part du principe qu’il n’y a qu’environ 11 Go de VRAM sur un GPU Nvidia- Le STT local est présenté comme un outil plus pratique à utiliser qu’un service hébergé
-
Configuration autour de 40 k$
- Elle part d’une configuration avec 4× RTX 6000 Pro pour obtenir 384 Go de VRAM au total
- À ce niveau de prix, elle est décrite comme donnant accès à une intelligence de modèle assez proche de Claude Opus
- Au 2026-07, le meilleur modèle actuel pour 4× RTX6kPRO est indiqué comme étant
GLM-5.2-Int8Mix-NVFP4-REAP-594B
- La configuration d’exécution se trouve dans
runners/GLM-5.2-594B
- Une autre approche mentionnée consiste à relier un cluster de 4× DGX Spark pour obtenir 512 Go de VRAM, puis laisser un gros cerveau lent et un Qwen3.7-27B traiter rapidement les tâches répétitives
Matériel réel de la machine 4× RTX 6000 Pro
- Le système réel est construit autour de 4× RTX PRO 6000 Blackwell Workstation
- Chaque GPU dispose de 96 Go, pour un total de 384 Go de VRAM, et l’ensemble coûte environ 46 000 $
- La machine réutilise une plateforme EPYC de génération précédente et des composants DDR4 achetés sur eBay afin de réduire le coût de base du système et concentrer les dépenses sur la VRAM
- En juillet 2026, les systèmes PCIe5/DDR5 étant très chers, le choix s’est porté sur un switch PCIe Gen4 et une base DDR4
-
BOM du système de base
- Le système de base est composé en grande partie de composants EPYC de génération précédente achetés sur eBay
- Les principaux composants et leurs prix sont les suivants
- Carte mère ASRock Rack ROMED8-2T : 715 $
- CPU AMD EPYC Milan 7313P 16 cœurs 3,0 GHz : 504 $
- 8× 16 Go Crucial DDR4 ECC RDIMM, soit 128 Go de RAM au total : 642 $
- 2× alimentations Super Flower 1700W : 750 $
- Switch PCIe Microchip Switchtec PM40100 Gen4 de c-payne : environ 1 330 $
- NVMe de démarrage 4 To : 291 $
- 2× NVMe 8 To pour les poids de modèles : 1 200 $
- Total du système de base : 5 587 $
-
Switch PCIe Gen4
- Un switch PCIe4 de c-payne est utilisé pour gérer de façon quasi directe les communications entre GPU
- Lors de l’étape d’allreduce en parallélisme tensoriel, les données entre GPU transitent dans le fabric du switch sans passer par le root complex PCI du CPU
- Le sous-BOM du switch est d’environ 1 220 €, soit environ 1 330 USD
- Switch PCIe Gen4 5× x16 basé sur Microchip Switchtec PM40100
- Adaptateur hôte SlimSAS PCIe Gen4 x16
- 2 câbles SlimSAS SFF-8654 8i
- Un caisson en bois pour les GPU et le switch PCI a été fabriqué à la main, ce qui a pris environ une journée
- Le ventilateur intégré au switch PCI était très bruyant et semblait inutile, il a donc été retiré de la carte
Stockage des poids de modèles et mode d’exécution
- Tous les poids de modèles sont stockés localement sur un système de fichiers ZFS répliqué sur deux disques de 8 To
- Le système de fichiers est monté sur
~/storage
- Les modèles à exécuter sont d’abord téléchargés en local avec la commande suivante
hf download <model-name> --local-dir ~/storage/<model-name>
- Chaque modèle possède son propre
docker-compose.yml dans un répertoire séparé et s’exécute dans son propre conteneur Docker
- Les configurations d’exécution se trouvent dans
./runners/
- Chaque conteneur monte
~/storage/models en lecture seule pour lire les poids mis en cache
- Quand le modèle est servi sur
http://clank.j.co:5000, il est utilisé via opencode, hébergé sur la VM d’une autre machine
- Un serveur DNS interne associe
clank.j.co à la machine LLM, mais une URL du type http://<llm-machine-ip>:5000 fonctionne aussi
Harnais d’agents et configuration des outils
- Dans une VM séparée, une application crée une session tmux pour chaque répertoire de l’arborescence
~/src et lance une instance opencode dans chaque session
- Chaque instance
opencode utilise comme backend l’API HTTP de la machine d’inférence, http://clank.j.co:5000
- La configuration des outils est présentée comme la clé pour bien exploiter des modèles open source
- Le résumé
skills/ inclut les outils suivants
- navigation Web et recherche via camofox, une clé API kagi.com et searXNG
- communication et notifications via un bot Telegram
- instance Gitea privée locale pour la collaboration sur le code source
- Les agents peuvent soit travailler en interaction au sein d’une session, soit prendre en charge des issues Gitea et ouvrir des PR
- Tout cela s’exécute dans une VM sandbox, avec comme seul canal de communication avec l’hôte un montage de système de fichiers partagé
Switch PCIe et configuration multi-GPU
-
Réglages BIOS
- Les réglages BIOS de la carte mère ROMED8-2T ont été ajustés pour éviter que la vitesse du switch PCI ne chute
AMD PCIE Link Width est réglé sur x16 pour le slot du switch- L’ancienne configuration de bifurcation x8/x8 divise le slot et fait entraîner le lien upstream en Gen4 x8
- Les deux câbles SlimSAS 8i doivent être connectés, chaque câble prenant en charge un x8
PCIe Link Speed est forcé en Gen4- Lors de l’auto-négociation de périphériques Blackwell Gen5 via un switch Gen4, l’entraînement peut échouer et retomber en Gen1
ASPM est réglé sur Disabled- ASPM L1 abaisse les liens inactifs à 2,5GT/s
- C’était la raison pour laquelle
lspci pouvait laisser croire à un passage en Gen1, alors qu’en charge le système fonctionne bien en Gen4
Re-Size BAR est réglé sur Enabled- Ce réglage est nécessaire pour exposer l’intégralité des 96 Go de BAR VRAM et pour le P2P GPU
SR-IOV est réglé sur Disabled- Ce choix vise à éviter la surcharge IOMMU et les interférences avec le P2P dans un environnement d’inférence bare metal
Preferred IO est laissé sur Auto- Assigner manuellement le bus
81 du switch c-payne peut légèrement améliorer la latence, mais il s’agit d’une optimisation plutôt que d’un correctif, et les numéros de bus peuvent changer après une modification du BIOS
-
Redriver et câbles
- Sur conseil de c-payne, le gain du redriver a été abaissé à
lvl 3 avec le c-payne tool
- Le niveau de gain dépend de la longueur des câbles du connecteur SAS
- Comme trop peu de câbles avaient été commandés chez c-payne, des câbles SAS apparemment similaires ont été achetés sur Amazon, mais de petites différences ont causé des problèmes et il a fallu recommander
Noyau, ACS et limites de puissance
-
GRUB et NVIDIA UVM
- Les paramètres de noyau suivants sont définis dans
/etc/default/grub
GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
- Sans
iommu=off, NCCL se bloque en P2P multi-GPU
- Le réglage suivant est appliqué pour corriger le P2P NVIDIA UVM
echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u
-
Désactivation de l’ACS
- Si l’ACS est activé par défaut, le trafic P2P ne reste pas dans le fabric du switch et passe par le port racine CPU
- Dans ce cas, l’intérêt du switch PCIe disparaît
- Comme
pcie_acs_override nécessite un noyau patché, l’ACS est désactivé à l’exécution via setpci
- Au démarrage, un service systemd oneshot exécute
/usr/local/bin/disable-acs.sh
- La vérification se fait de la manière suivante
- Dans
lspci -vvv | grep ACSCtl, tout doit apparaître avec des signes moins
- Dans
nvidia-smi topo -m, les quatre GPU doivent apparaître en PIX entre eux, et non en PHB/NODE
./tools/measure-gpu-speed.sh permet de mesurer facilement la bande passante et la latence P2P
-
Limite de puissance GPU
- Pour éviter d’installer un circuit 220V, le système fonctionne sur un seul circuit 110V avec une limitation de la puissance GPU
- Au démarrage, systemd active le persistence mode et applique la limite de puissance
sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
- La limite de puissance GPU est de 350W par GPU, contre 600W par défaut
- 4×350W correspondent à 1 400W de charge GPU, en ligne avec le budget d’alimentation
- Avant de passer à un circuit 240V, au stade d’une seule alimentation 1700W, les GPU étaient exploités autour de 260W
- 4×260W = 1 040W pour les GPU
- En ajoutant environ 280W pour le système, on arrive à un total d’environ 1 320W
- La vérification se fait avec
nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv
Résultats de mesure et ressources
- Le lien upstream vers le CPU est en Gen4 x16, soit environ 30 Go/s
- Le P2P via le switch atteint 27,5 Go/s en unidirectionnel et 50,4 Go/s en bidirectionnel
- La latence est de 0,37–0,45 µs, au niveau du débit de ligne Gen4
- Si ASPM est activé quelque part,
lspci peut afficher les liens GPU downstream au repos comme 2.5GT/s (downgraded)
- Cet affichage est purement cosmétique : les liens se réentraînent en Gen4 sous charge
-
Resources
- local-inference-lab/rtx6kpro : dépôt fréquemment mis à jour sur l’usage de 4, 6 ou 8 cartes RTX 6000 Pro
- c-payne : switch PCI indépendant utilisé dans cette configuration
- RTX6kPRO Discord : serveur Discord consacré aux benchmarks RTX6kPRO et aux tests de nouveaux modèles
1 commentaires
Avis sur Hacker News
J’ai beaucoup utilisé de LLM en local et j’ai dépensé bien trop d’argent en matériel, mais il faut revoir ses attentes à la baisse et lire attentivement les conditions détaillées
Le gros build décrit dans l’article démarre avec un budget de 40 000 dollars, mais comme il inclut 4 GPU à 12 000 dollars pièce, il se rapproche en réalité plutôt de 50 000 à 55 000 dollars
Les configurations locales reposent souvent sur des techniques comme la quantification ou REAP pour faire tenir le modèle sur le matériel. On affirme souvent que la quantification 4 bits est sans perte, mais cela vient de mesures de divergence KL sur de petits corpus ; quand on l’utilise pour des tâches de code avec de longs contextes, la baisse de qualité est nette. Même pour des tâches hors code comme l’analyse de datasets, on peut mesurer des écarts de qualité assez importants entre le 4 bits, le 8 bits et parfois l’original en 16 bits
L’article recommande aussi l’usage de modèles REAP, ce qui signifie que quelqu’un a supprimé une partie des poids pour rendre le modèle plus petit. L’idée est de retirer les poids moins utiles pour certaines tâches, mais la qualité globale des sorties baisse encore
Le piège, c’est que lorsque les gens disent « faire tourner GLM-5.2 en local », on regarde les benchmarks et cela paraît impressionnant, mais en réalité ils ne font pas tourner GLM-5.2 : ils exécutent un modèle dérivé où la plupart des bits ont été jetés et certains experts supprimés. Sur de toutes petites tâches ou du chat, la différence entre les modèles quantifiés/REAP et l’original ne se voit pas beaucoup, mais sur des travaux longs où de petites erreurs s’accumulent, elle devient douloureuse
Et comme on a déjà dépensé 50 000 dollars, on se retrouve sur une pente glissante : pour améliorer un peu la qualité et rentabiliser l’investissement, il suffirait d’acheter encore un ou deux GPU à 12 000 dollars
Pour les tâches de code, il faut découper la session en plusieurs appels. J’ai créé https://github.com/aka-rider/orqestra, mais avec les environnements actuels d’exécution d’outils, on peut faire à peu près la même chose soi-même presque partout
L’idée essentielle est d’avoir une session séparée qui consomme du contexte pour lire le code et appeler les outils, puis de produire un rapport Markdown du type « le code et la documentation pertinents sont ici, et voici les éléments qui le justifient » afin de réduire les hallucinations. La session de planification est séparée ; comme les petits modèles sautent des détails, il faut faire 1 à 3 allers-retours entre le critique et l’architecte, puis aussi entre l’exécutant et le vérificateur pour la même raison
Qwen3.6 peut chercher pendant des heures des bugs complexes en mode lecture seule et finit généralement par les trouver. Les correctifs qu’il propose seront sans doute bricolés, mais Sonnet fait pareil
Qwen3.6 peut écrire du code mécaniquement à partir d’un plan produit par Opus. Ensuite, il faut le prompter du genre : « relis toi-même tes changements. Y a-t-il un bug ? En les recoupant avec le plan initial, manque-t-il quelque chose ? Y a-t-il une violation de CLAUDE.md ? ». Mais il faut faire exactement la même chose avec Sonnet
J’utilise aussi les LLM locaux pour réindexer une base de connaissances. Pour trier des tickets, il suffit parfois de laisser des notes brutes comme « panneau unique pour le rendu des erreurs, déplacer tous les messages d’erreur » pour obtenir en retour une spec complète à environ 90 %, avec l’objectif et le contexte
C’est vraiment bien pour les petites tâches, mais la première fois que je lui ai donné une grosse tâche, il a oublié dans quel environnement d’exécution d’agent il se trouvait et a commencé à utiliser un mauvais format d’appel d’outils. Il tournait sur un Pi, mais il croyait tourner dans Claude et essayait d’appeler des outils Claude inexistants
Il n’écrit pas une application entière tout seul, mais il a résolu un problème réseau pénible dans mon tailnet que je n’avais ni le temps ni l’envie de comprendre moi-même, et je l’utilise souvent pour des tâches simples que je n’aurais pas faites parce que le coût d’investigation était trop élevé. Ce n’est pas Opus, mais c’est utile, et je n’ai pas à me demander si je rentabilise un abonnement ou des coûts d’API
Les petits outils de traitement du langage naturel, de synthèse vocale, de traitement d’image, d’ingénierie audio, de traitement du signal, les plugins de diffusion pour Krita, etc., conviennent très bien aux configurations locales. J’ai aussi écrit un court billet à ce sujet il y a quelques jours[1]
[1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...
« Pour environ 40 000 dollars, l’intelligence du modèle monte d’un cran et se rapproche assez nettement de Claude Opus » : c’est l’équivalent de 16,8 ans d’utilisation de Claude Opus 4.8 ou de Codex GPT 5.5 à 200 dollars par mois.
J’aime vraiment exécuter des modèles en local, mais cela reste absurdement cher, la qualité est inférieure, et cela peut aussi être risqué s’il y a des backdoors. J’aimerais sincèrement que ce ne soit pas le cas.
Cela dit, je doute qu’une machine locale puisse réellement traiter un volume équivalent à 4 000 dollars d’API par mois, car il est difficile de faire tourner des prompts en parallèle aussi efficacement en local que dans les multiples datacenters d’Anthropic.
Des entreprises comme OpenAI et Anthropic vendent encore leurs forfaits à des prix subventionnés par le capital-risque, et ce capital voudra un jour un retour sur investissement.
J’ai utilisé 1 milliard de tokens le premier mois avec OEM spark, ce qui représenterait plus de 1 000 dollars avec Opus. Les profils de tokens sont différents, donc la comparaison n’est pas parfaitement équitable, mais depuis, les améliorations de vLLM, surtout grâce à MTP, ont aussi augmenté la vitesse d’un facteur 2 à 3. DiffusionGemma est environ 4 fois plus rapide que Gemma classique.
Vous ne possédez pas non plus de fibre optique ; alors pourquoi vouloir posséder un autre actif cher, pénible à gérer et qui se déprécie vite ?
Louer des GPU cloud permet de participer à la culture de la possession, du contrôle des données, du contrôle des prix et du hacking sans construire une énorme boîte Frankenstein de hobbyiste. Cette boîte est chère, distillée au point d’être en pratique moins utile, et pénible à maintenir.
On dit « 40 000 dollars et c’est presque Opus », mais si GLM 5.2 est « presque Opus », alors pour une inférence confortable il faut au minimum 8xH200, donc on est plus près de 400 000 dollars que de 40 000.
L’article propose d’utiliser un modèle modifié : « GLM-5.2 élagué avec REAP, avec environ 22 % des experts retirés, quantifié en Int8-mix NVFP4, environ 594B paramètres ».
Je me demande comment il se comportera réellement hors benchmarks. Qwen3.6 se met déjà souvent à boucler pendant l’inférence en quantification 6 bits, et ici on a en plus retiré une partie des experts. Parfois, un modèle plus petit en 8 ou 16 bits peut être plus intelligent qu’un grand modèle lobotomisé. Il semble y avoir un consensus selon lequel, pour le code, mieux vaut ne pas descendre sous 8 bits.
On ne sait pas non plus clairement combien de contexte utilisable il reste quand on fait tenir ce modèle lobotomisé sur 4 RTX 6000. En dessous de 100k, c’est presque inutilisable, car on se heurte souvent à la compression avant d’avoir rassemblé le contexte nécessaire. En vérifiant dans le dépôt, le contexte était de 240k.
J’aimerais savoir s’il ne se lance pas du tout, ou s’il est simplement trop lent pour être utilisable. Je voudrais valider en local le build et les concepts d’un modèle de dernière génération, puis compléter le reste dans 18 à 24 mois si les prix des GPU baissent fortement.
Est-ce que cela veut dire qu’on peut lancer des centaines de prompts en même temps ?
C’est inclus dans llamacpp. La personne qui a créé heretic a aussi développé des stratégies anti-boucle et de diversification à l’état de l’art.
Il n’y a pas vraiment de besoin pratique de faire tourner 8x H200, sauf si c’est simplement ce dont vous avez envie. Exception faite du cas où vous devez régulièrement servir beaucoup d’utilisateurs ou d’agents simultanés.
Il existe aussi des options intermédiaires. Avec 128 Go de VRAM, il y a désormais plusieurs solutions permettant d’obtenir ce volume via une architecture à mémoire unifiée, et DwarfStar permet de faire tourner DeepSeek V4 flash à une bonne vitesse.
Je ne dépenserais pas cet argent, mais pour beaucoup de gens, cela semble être un compromis raisonnable.
Il faut toutefois utiliser Pi. claude code embarque trop de contexte au bootstrap, ce qui ralentit énormément tout le reste.
« Avec deux RTX 3090, pour un total de 48 Go de VRAM, on peut faire tourner Qwen3.6-27B, et c’est un excellent modèle », dit-on, mais pour 3 000 dollars, on peut acheter un M5 MacBook Pro avec 48 Go de mémoire unifiée, sans que ce soit une énorme boîte
Ou bien il vaut aussi la peine d’envisager de dépenser cet argent chez un hébergeur cloud. Cela peut être, au moins dans une certaine mesure, voire beaucoup, moins cher. Bien sûr, pouvoir faire tourner un modèle en local, c’est génial
Mais ce n’est qu’après avoir essayé quelque chose de correct, comme Gemma 4 31B et Qwen 3.6 27B, que j’ai compris à quel point c’était utile
On cesse de s’inquiéter de partager des informations sensibles, on ne se demande plus si l’on va tomber à court de tokens, et on ne s’inquiète plus non plus de la disponibilité d’une IA distante. Les LLM locaux ont énormément de valeur
Deux 3090 offrent au total 1,87 To/s, soit 0,936 To/s par carte, alors que le M5 MacBook Pro n’a que 0,3 To/s. Les puces Max montent jusqu’à 0,63 To/s, mais cette configuration correspond à une machine à 10 000 dollars
C’est pourquoi Qwen 27B tourne assez vite pour un usage réel sur deux 3090, mais semble douloureusement lent sur un MacBook Pro. De plus, faire tourner de gros modèles sur un MacBook Pro rend l’interface saccadée et le clavier brûlant. Il est bien préférable de mettre deux 3090 à la cave et de s’y connecter depuis le MacBook
Ce n’est pas seulement la vitesse de génération des tokens, mais aussi le temps jusqu’au premier token, c’est-à-dire le temps de traitement du prompt, qui diffère. Le matériel M5 est excellent en soi, mais les GPU restent nettement plus rapides
Faire tourner le modèle sur une boîte GPU a aussi l’avantage de permettre d’utiliser le portable sur les genoux sans le transformer en plaque chauffante
Donc le pré-remplissage, limité par les FLOPS, comme le décodage, limité par la bande passante, seront tous deux plus lents
Comme je viens de monter un LLM local cette semaine, j’ajoute mon expérience. J’ai choisi une carte 32 Go d’Intel, l’Arc B70 : elle est moins chère qu’une 3090 et a plus de RAM, mais son bus mémoire est plus lent
Je l’ai choisie parce que les modèles que je voulais utiliser étaient un peu trop gros pour tenir confortablement dans 24 Go, et qu’il me fallait aussi de la place pour quelques petits modèles d’autocomplétion et de reconnaissance vocale. J’avais aussi déjà un serveur bon marché, et passer à deux GPU aurait nécessité de changer la carte mère, l’alimentation, et probablement le boîtier
La configuration a été assez pénible. La gamme Intel a besoin d’un paquet de pilotes appelé « level zero » pour prendre en charge SYCL, en gros l’équivalent Intel de CUDA, et il a été difficile de le faire fonctionner correctement. Je fais tourner llama.cpp dans un conteneur Docker, et faire en sorte que le conteneur voie la carte a aussi demandé un peu de travail. Il faut également un noyau datant des derniers mois
Une fois que ça fonctionne, le résultat est très impressionnant pour un investissement de 1 000 dollars. Qwen 3.6 35B en quantification q4 utilise environ les 3/4 de la RAM et atteint autour de 88 tokens/s. Si l’on veut un modèle de taille raisonnable à bas coût, c’est une possibilité
La B70 a un bus 256 bits à 2375 MHz, soit 608 Go/s, et la 3090 a un bus 384 bits à 2438 MHz, soit 936 Go/s. Ce n’est pas plus lent : il y a moins de canaux, autrement dit le bus est plus étroit
qwen3.6-27b peut faire tourner sa variante q4 sur une seule 3090, même avec un contexte total d’environ 250K
C’est suffisamment rapide pour ne pas être frustrant, donc le gain de vitesse avec deux 3090 ne vaut pas le coup pour moi. Il y a aussi l’option de faire tourner q6 sur deux cartes, à moitié moins vite et avec un contexte plus petit, mais comme cela ne rivalisera de toute façon pas avec les modèles de pointe, je pense qu’au prix actuel, une seule 3090 est le meilleur investissement, sauf si l’on en possède déjà deux. Avec un environnement d’exécution bien configuré, c’est suffisant pour faire beaucoup de choses
D’après mon expérience, à cette précision, la qualité du rappel sur les longs contextes chute fortement. J’ai préféré garder le cache KV en q8 et travailler avec un contexte de 120k
À ce sujet, je me demande quel est le meilleur système d’isolation utilisable aujourd’hui. Je ne sais pas s’il faut aller jusqu’à une grosse VM complète, ou si quelque chose façon Firecracker suffit.
Chaque option possible semble avoir des pièges subtils où il est facile de se tirer une balle dans le pied, et de finir avec pratiquement aucune sécurité. Les VM sont utilisées parce qu’on peut réellement faire confiance au fait que la sécurité est un principe de base de cette technologie, pas parce que « si on met ces 20 flags et qu’on plisse les yeux, ça devrait aller ».
Il faut d’abord modéliser les vecteurs d’attaque.
rm -rfse bloque avec des restrictions d’écriture, etcurl malware.sh | shen limitant l’exécution dans les répertoires inscriptibles (seatbelt/SELinux). Le simple fait de restreindre l’écriture dans les répertoires sensibles neutralise probablement une grande partie des malwares.Pour l’exfiltration d’identifiants, il suffit de nettoyer les variables d’environnement, d’interdire la lecture de .ssh, .aws, etc., et de ne pas placer le LLM à proximité du système d’exploitation.
J’ai créé un petit utilitaire pour MacOS, https://github.com/aka-rider/leash, mais on peut aussi le faire avec des scripts bash.
Si on veut quelque chose de léger, on peut utiliser un outil comme bubblewrap[1], ou une microVM comme libkrun[2] ; si on veut aussi l’outillage associé, on peut aller jusqu’à Docker complet.
[1] https://github.com/containers/bubblewrap
[2] https://github.com/libkrun/libkrun
Je comprends l’incertitude sur la façon de savoir réellement si tout est bien verrouillé.
Personnellement, je pense que les VM ou microVM sont la bonne voie. Contrairement aux conteneurs, elles sont conçues comme de vraies frontières de sécurité. Même comparées à bubblewrap, elles permettent de donner tout le système de fichiers à l’agent et de le faire tourner en mode YOLO, tandis qu’avec bubblewrap il faut amorcer un par un l’accès à chaque outil de développement, monter de façon sûre les répertoires de configuration, les caches de paquets, etc., et on risque malgré tout de tomber sans cesse sur des erreurs de permissions. L’isolation est aussi beaucoup plus faible.
Le support côté environnement d’exécution est limité, mais je trouve assez raisonnable de faire tourner le processus d’environnement d’exécution sur l’hôte et de déléguer tous les appels d’outils et les interactions avec le système de fichiers à la VM. On peut ainsi garder les données de session et les clés d’authentification sur la machine principale, sans jamais les faire entrer dans le contexte. En contrepartie, l’environnement d’exécution lui-même devient une partie de la frontière de sécurité, c’est le compromis.
La manière de transférer les données entre la VM et l’extérieur pose aussi un problème d’ergonomie. J’utilise des scripts qui poussent un dépôt git local dans la VM puis le récupèrent comme s’il s’agissait d’un remote ; ainsi, la VM ne peut pas initier de connexion vers l’hôte et n’a pas besoin d’identifiants git. Mais pour quelqu’un qui veut que l’agent pousse directement vers GitHub, c’est peut-être trop contraignant.
Les options que j’ai essayées ou vues côté VM sont qemu + libvirt, crun-vm et la famille libkrun. qemu + libvirt demande des efforts de configuration, mais c’est très éprouvé et très configurable. crun-vm est une PoC de couche d’intégration de haut niveau entre podman et qemu ; elle semble abandonnée, mais elle est intéressante car centrée sur les outils existants et les standards. libkrun est un entrant plus récent, avec des wrappers comme microsandbox, smolvm et krunvm. Tout cela vaut pour Linux.
Je trouve étrange de faire autant d’efforts pour utiliser un LLM. Surtout pour courir après le dernier cri de cette manière.
Si des choses comme Claude disparaissaient demain, je ne sourcillerais même pas.
Je ne comprends pas pourquoi les gens échangent leurs circonvolutions cérébrales contre un accès à des machines à produire de la bouillie. Une bonne analogie serait peut-être de donner à un menuisier qualifié une machine qui sort des meubles d’une qualité inférieure d’un ou deux crans à Ikea. Est-ce que ça fait le travail ? La plupart du temps, oui. Est-ce que le menuisier prend plaisir au processus ? Non.
D’après mon expérience, je n’ai jamais lancé un modèle fortement quantifié comme en q4, ou modifié dans une certaine mesure, en me disant « waouh, c’est vraiment impressionnant ». Au contraire, après quelques prompts, il finissait à la corbeille.
J’ai une RTX 6000 PRO de 96 Go, et ce que je peux faire tourner confortablement se limite à Qwen 3.6 27B ou MoE, et Gemma 4 31B. Quand on exécute les modèles en pleine précision et avec la longueur de contexte maximale, c’est à peu près la limite.
Ils sont performants et utilisables pour plusieurs usages, comme le codage ou les recherches sur Internet. Si, d’après vos calculs, vous pensez dépenser plus de 2 400 dollars par an chez Anthropic, acheter ce genre de carte peut avoir du sens, mais il faut accepter une baisse de qualité. De toute façon, on peut se demander si des humains coderont encore dans cinq ans.