L’inférence locale contestée entre coût matériel et contrôle des modèles

Le débat sur l’exécution des modèles d’IA change de ton: d’un côté, Sam Altman estime qu’il vaut mieux concentrer les ressources dans le cloud; de l’autre, Eclypsium montre qu’un modèle peut voir son comportement modifié en mémoire sans que son fichier d’origine soit altéré. Entre pénurie de composants, pression sur la mémoire et sécurité des infrastructures, la question n’est plus seulement où faire tourner l’IA, mais qui contrôle réellement ce qui s’exécute.

Le cloud comme réponse à la pénurie, selon Sam Altman

Dans un entretien récent sur le podcast Cheeky Pint, le patron d’OpenAI a plaidé pour une utilisation maximale du cloud, au motif que la capacité mondiale en silicium reste contrainte. Selon lui, multiplier les machines personnelles capables de faire tourner des modèles à domicile gaspille une ressource rare, surtout quand la demande en mémoire et en stockage grimpe déjà fortement. Son raisonnement vise surtout l’allocation industrielle des puces, pas le confort des utilisateurs qui aiment garder leurs modèles sous la main. C’est moins romantique qu’un PC de gamer sous le bureau, mais le calcul est clair.

Altman a aussi soutenu que beaucoup de personnes surestiment la capacité du local inference, c’est-à-dire l’exécution d’un modèle sur sa propre machine plutôt que sur un serveur distant. Pour lui, les hyperscalers offrent une meilleure utilisation des infrastructures. Cette position alimente toutefois une tension de fond: plus l’IA dépend du cloud, plus l’accès aux modèles, aux données et aux coûts d’exploitation se concentre chez quelques acteurs.

Quand l’infrastructure modifie le modèle sans toucher au fichier

Eclypsium apporte une réponse très différente, mais sur un autre terrain: la sécurité. Dans une recherche publiée le 29 octobre, la société explique avoir démontré qu’une infrastructure compromise peut modifier le comportement d’un modèle pendant l’inférence, alors même que ses fichiers stockés restent intacts. Autrement dit, vérifier une signature ou un hash ne suffit pas à prouver que le modèle en mémoire est bien celui qui a été approuvé.

La démonstration, menée avec le soutien de NVIDIA, reposait sur un data processing unit, ou DPU, c’est-à-dire un processeur programmable chargé de fonctions réseau, stockage ou sécurité. En combinant ce composant compromis avec une isolation mémoire permissive, les chercheurs ont modifié des poids du modèle au moment de l’exécution. Les réponses produites changeaient, sans altérer le service d’inférence ni le fichier d’origine. L’expérience a même affecté une question géopolitique, ce qui rappelle que l’enjeu dépasse largement le simple test de laboratoire.

Le scénario dépendait cependant de conditions précises: un environnement NVIDIA Grace Hopper, un chemin d’accès DMA et des réglages comme l’IOMMU passthrough et une isolation PCIe permissive. Les chercheurs précisent que ces paramètres n’étaient pas les réglages Linux par défaut. En configuration d’isolation plus stricte, le même chemin d’attaque n’était plus disponible. L’alerte porte donc moins sur une faille universelle que sur un rappel brutal: une capacité de protection existe seulement si elle est réellement activée.

La sécurité de l’IA ne s’arrête pas au modèle

Le point de fond, pour Eclypsium comme pour NVIDIA, est simple: les frontières de confiance de l’IA incluent aussi le matériel, le firmware et la configuration des dispositifs. NVIDIA met en avant sur ses BlueField des mécanismes d’authentification au démarrage, de racine de confiance matérielle, d’attestation et de protection des mises à jour. Mais la disponibilité d’une fonction ne dit rien, à elle seule, de son bon paramétrage dans un environnement donné.

Cette nuance devient critique quand les modèles accèdent à des outils, à des données d’entreprise ou lancent des actions. NVIDIA présente d’ailleurs son Open Agent Safety Platform comme une réponse en couches: OpenShell pour la gouvernance d’exécution, et Sentry sur BlueField pour surveiller depuis une zone isolée du reste du système. L’idée est cohérente: déplacer le contrôle hors de l’application pour réduire le risque. Reste que ce nouveau point de contrôle doit, lui aussi, être digne de confiance. Sinon, on déplace simplement le problème d’un étage à l’autre.

Ce que les opérateurs doivent vérifier en pratique

Eclypsium décrit ce qu’il appelle l’AI Infrastructure Assurance Gap, soit l’écart entre l’assurance centrée sur le modèle et l’intégrité réelle de l’infrastructure. La société propose d’inventorier les composants, d’évaluer le firmware et la configuration, de comparer l’état des équipements à des références approuvées et de suivre les changements dans le temps. Pour les exploitants, cela implique de traiter les GPU, DPU, contrôleurs de gestion et firmwares comme des actifs à part entière, avec propriétaire identifié, version suivie et processus de mise à jour connu.

Ce suivi doit aussi survivre aux changements de cycle de vie: déploiement, mise à jour, reprise après incident, réaffectation. Dans des environnements mutualisés, un matériel peut servir plusieurs clients successifs; un système propre en façade ne garantit donc rien sur les couches basses. Les signatures de modèles restent utiles, mais elles ne disent qu’une chose: le fichier chargé est bien celui attendu. L’exécution réelle, elle, dépend d’une chaîne plus large. Et cette chaîne-là ne pardonne pas les angles morts.