Contexte et définition du scale‑in

Nvidia positionne le scale‑in comme la quatrième catégorie de son architecture d’infrastructure IA, après le scale‑up (NVLink), le scale‑out (InfiniBand ou Spectrum‑X Ethernet) et le scale‑across (inter‑factory). Le scale‑in vise à intégrer utilisateurs, modèles, agents, stockage et calcul tout en appliquant des contrôles de sécurité qui s’étendent à l’ensemble du « AI factory ». Cette approche répond à la montée des charges de travail « agentic AI », où un agent effectue de multiples appels de modèle, accède à des données et déclenche des actions, créant ainsi une surface d’attaque plus large que les simples requêtes d’inférence.

Architecture technique et rôle du DPU

Le cœur du scale‑in repose sur le BlueField‑4, DPU de Nvidia, couplé aux interfaces réseau ConnectX et au Spectrum‑X Ethernet. Shainer indique que le BlueField‑4 offre un chemin d’accès sécurisé de 400 Gb/s, mais étend la couverture à 7,2 Tb/s de trafic sécurisé grâce à son architecture intégrée. Cette capacité permet de surveiller le trafic « north‑south » (entrée/sortie) et « east‑west » (communication interne) sans goulot d’étranglement, car le DPU opère out‑of‑band, séparé du flux de calcul principal, limitant ainsi toute dégradation de performance des GPU.

Le DPU ne se contente plus de sécuriser l’accès au serveur ; il devient un point de contrôle centralisé capable de monitorer et appliquer des politiques sur les ressources de calcul, mémoire et stockage utilisées par les agents. Cette séparation logique entre charge de travail et contrôle de sécurité repose sur le framework logiciel DOCA, qui expose des API de politique et de gestion des identités aux services d’infrastructure.

OpenShell 0.1.0 : runtime open‑source pour les agents

Nvidia accompagne le scale‑in d’un runtime nommé OpenShell 0.1.0. OpenShell fournit un environnement d’exécution sandboxé, une gestion des identifiants et une formal policy analysis. Il autorise les équipes à définir les capacités exactes requises par chaque tâche (par exemple accès à un stockage spécifique ou appel à un service) et à faire appliquer ces permissions en dehors du conteneur d’application principal. Le runtime supporte déjà les modèles Codex, Claude Code, Pi, Hermes et est prévu pour les futurs cadres d’IA d’entreprise.

En pratique, un développeur décrit une politique sous forme de JSON ou de DSL propriétaire, puis OpenShell intercepte les appels système de l’agent, vérifie la conformité et bloque toute opération non autorisée. Cette approche réduit la charge de conformité sur les serveurs GPU et CPU (nommés « Vera » dans le texte), tout en conservant un contrôle granulaire au niveau du trafic interne.

Implications pour les opérateurs et limites

Pour les opérateurs d’infrastructure, le scale‑in promet une visibilité accrue sur les activités des agents, facilitant la mise en conformité avec les exigences de sécurité AI. La surveillance out‑of‑band minimise l’impact sur les performances, mais elle introduit une dépendance supplémentaire au DPU : toute défaillance du BlueField‑4 pourrait affecter la capacité à appliquer les politiques, d’où l’importance de redondance et de mise à jour du firmware.

Le modèle économique de Nvidia repose également sur la vente de versions de DPU compatibles avec plusieurs générations de GPU, ce qui explique la mention d’une « valeur résiduelle » même après l’arrivée de nouvelles puces. Cependant, le texte ne fournit pas de métriques de latence ou de charge CPU spécifiques à OpenShell, limitant l’évaluation précise de son impact sur les charges de travail à grande échelle.