Faire tourner un agent IA dans une VM tout en gardant le modèle sur le GPU de l'hôte : le schéma avec Strata

Un agent qui installe lui-même des paquets, lance des scripts et modifie des fichiers fait gagner des heures. Mais vous donnez en réalité à un stagiaire les droits d'administrateur sur votre ordinateur portable. Une seule hallucination dans un script de nettoyage, un seul postinstall dans un dépôt inconnu, et vous en subirez les conséquences sur votre système principal.

La solution évidente est la machine virtuelle. Le problème : on ne peut généralement pas y passer le GPU, et un modèle local sans carte graphique est atrocement lent. Un article de Habr propose de séparer le « cerveau » et les « mains ».

Comment le schéma est construit

Il y a trois circuits.

L'hôte s'occupe de l'inférence. Il fait tourner l'application de bureau Strata, qui expose une API compatible OpenAI (port par défaut : 47831). Le code tiers n'y arrive pas et n'y est jamais exécuté.

La machine virtuelle en mode NAT est le bac à sable. VS Code et le plugin Cline y sont installés ; c'est aussi là que l'on décompresse les archives, installe les dépendances et lance les scripts douteux. Si quelque chose tourne mal, la VM est restaurée depuis un snapshot en environ cinq secondes.

La passerelle réseau redirige de force tout le trafic de l'hyperviseur sur l'hôte vers un proxy SOCKS via Proxifier. Si le code analysé contient de la télémétrie ou une connexion inversée, seule l'IP du proxy sortira, et non celle du réseau domestique.

Un exemple simple : vous voulez analyser rapidement un dépôt GitHub inconnu. Vous le clonez dans la VM et demandez à l'agent de compiler le projet et de lancer les tests. Le modèle réfléchit sur la carte graphique de l'hôte, mais tout s'exécute dans le bac à sable.

Où ça casse

Ce qui est intéressant ici, ce n'est pas l'idée elle-même, mais deux pièges réseau.

Premier piège : les serveurs de modèles locaux (Strata, Ollama, LM Studio) n'écoutent par défaut que sur 127.0.0.1. Depuis la VM, on ne les voit pas, même via la passerelle 10.0.2.2. L'auteur résout cela avec le portproxy intégré à Windows. Une seule commande netsh interface portproxy redirige le port, et une règle de pare-feu l'ouvre. La vérification est simple : curl.exe 10.0.2.2:47831/v1/models depuis la VM doit renvoyer un JSON avec la liste des modèles. On en tire le champ id exact, nécessaire dans Cline.

Le second piège n'est pas évident. Quand la VM contacte 10.0.2.2, le paquet est finalement traité par le svchost.exe système. Proxifier l'intercepte et tente de l'envoyer vers une adresse locale via le serveur SOCKS distant. La connexion se fige. On corrige cela avec une règle d'exception : applications — Any (précisément parce que le trafic passe par svchost), hôtes — 10.0.2.2, 127.0.0.1, localhost et sous-réseaux locaux, port — 47831, action — Direct. La règle doit être placée au-dessus de la règle générale de l'hyperviseur. Comme le port est fixé, le reste de la sortie Internet de la VM continue de passer uniquement par le proxy.

Dans Cline, les réglages sont les suivants : fournisseur OpenAI Compatible, Base URL 10.0.2.2:47831/v1, clé — n'importe quel mot non vide, Model ID — le nom figurant dans la réponse du serveur. Il est raisonnable de désactiver les modèles distincts pour les modes Plan et Act afin de ne pas dupliquer la configuration.

À prendre en compte en pratique

L'isolation repose sur la discipline. Dans la VM, on désactive les dossiers partagés et le presse-papiers bidirectionnel, sinon le bac à sable perd son sens. Il ne faut pas se connecter à ses comptes personnels ni y conserver de vraies clés et de vrais jetons : l'Auto-approve de Cline autorise l'agent à faire tout ce qui est accessible dans la machine.

Il y a aussi un point faible que l'article n'aborde pas. La commande portproxy utilise listenaddress=0.0.0.0, c'est-à-dire que le port écoute sur toutes les interfaces de l'hôte, et la règle de pare-feu de l'exemple ne restreint pas la source. Si vous êtes sur un Wi-Fi partagé, il est judicieux de restreindre la règle au sous-réseau de la VM via le paramètre remoteip, ou de lier listenaddress à l'adresse de l'adaptateur virtuel. C'est notre conclusion, et non une recommandation de l'auteur. Par ailleurs, la VM n'offre pas de garantie absolue : l'évasion de l'hyperviseur est rare mais possible, et il faudra mettre à jour le snapshot.

En résumé pour le développeur : il ne vous faut pas un agent « intelligent », mais un agent en cage. Le schéma se monte en une soirée avec des logiciels gratuits et convient à l'audit de code tiers, à l'analyse de paquets suspects et aux expériences en mode autonome. Il vaut la peine d'exporter le profil Proxifier et de prendre un snapshot propre juste après avoir vérifié l'IP externe.