IBM et CoreWeave co-conçoivent des contrôles pour agents IA

Pendant des années, la mission principale d'un cluster de recherche en IA consistait à entraîner des modèles. Cette mission s'élargit. Dès que les équipes recourent à l'apprentissage par renforcement (RL) et commencent à tester des agents, la même infrastructure doit exécuter du code produit par les modèles, appeler des outils, lire et écrire dans le stockage et se connecter à d'autres services. L'entraînement pur n'a jamais posé la question de savoir où ce code devait s'exécuter et à quoi il devait avoir accès. Le travail sur les agents, si.

IBM Research se penche sur cette question avec CoreWeave, le fournisseur de cloud GPU. Brian Belgodere, senior technical staff member chez IBM, a décrit cette collaboration lors d'un entretien avec Dave Vellante et John Furrier de theCUBE Research, à l'occasion de l'événement Fully Connected. L'entretien a été diffusé sur theCUBE, le studio de diffusion en direct de SiliconANGLE Media. theCUBE est partenaire média rémunéré de l'événement, et CoreWeave a sponsorisé sa couverture. SiliconANGLE affirme que les sponsors n'exercent aucun contrôle éditorial sur ses contenus.

Pourquoi l'apprentissage par renforcement change le cluster

Selon Brian Belgodere, le RL ajoute une étape d'exécution de tâches au développement des modèles. "Le processus de RL, c'est [que] vous êtes en plein entraînement d'un modèle", explique-t-il. "À un moment donné, vous prenez ce checkpoint, vous le chargez en inférence, vous lui demandez de faire quelque chose et vous mesurez. C'est votre phase de test."

Concrètement, la boucle d'entraînement contient désormais une étape d'inférence et une étape d'exécution. Un checkpoint est chargé, reçoit une tâche et est évalué sur le résultat. Dans la recherche sur les agents, cette tâche peut consister à exécuter du code. Le profil de risque n'a rien à voir avec celui d'un GPU qui fait du calcul matriciel, et il faut l'anticiper dès le niveau de l'infrastructure.

D'un cluster H100 maison à CoreWeave

L'histoire de l'infrastructure d'IBM commence avec Granite, sa famille de modèles d'IA. Leur développement a demandé énormément de puissance de calcul, et IBM a d'abord construit cette capacité elle-même. "Nous avons construit un grand cluster H100, et nous l'avons fait nous-mêmes : trouver les locaux, tout de A à Z. C'était un chantier énorme", raconte Brian Belgodere.

La génération de matériel suivante a apporté des exigences de refroidissement et d'alimentation qui, d'après lui, ont contribué à pousser IBM vers une collaboration avec CoreWeave plutôt que de renouveler l'approche du fait-maison.

Une ingénierie commune sur l'identité

La relation a depuis dépassé la simple location de capacité. IBM a transmis à CoreWeave ses exigences pour étendre ses systèmes d'identité internes à l'environnement CoreWeave. Les deux entreprises ont ensuite affiné la mise en oeuvre au fil de plusieurs itérations.

Brian Belgodere assure que les échanges vont dans les deux sens. "Souvent, ce sont eux qui viennent nous voir en disant : 'Tiens, on réfléchit à ça, vous pouvez nous donner votre avis ?'", dit-il. "Et on s'y prête volontiers."

Ce point compte pour les entreprises clientes. Les grandes organisations veulent rarement un système d'identité distinct pour chaque fournisseur cloud. Étendre l'identité existante de l'entreprise à la plateforme du fournisseur permet de centraliser le contrôle d'accès.

Choisir où s'exécute le code des agents

L'essentiel du cluster d'IBM Research est mono-locataire. Autrement dit, le matériel n'est pas partagé avec d'autres clients. IBM a aussi déployé son propre stockage au sein de CoreWeave, et peut puiser dans des capacités supplémentaires tant qu'elle reste dans ses limites de coût et de sécurité.

La collaboration porte également sur CoreWeave Sandboxes. Ces bacs à sable permettent une exécution isolée, soit sur une infrastructure dédiée, soit via un environnement d'exécution serverless géré. Les chercheurs peuvent décider où s'exécute le code des agents et à quelles ressources il peut accéder.

Brian Belgodere prévient que les équipes se trompent souvent sur ces choix initiaux. "Il y a beaucoup d'erreurs, et les gens ont tendance à sous-estimer le coût d'un changement sur certaines de ces décisions", explique-t-il. "Si vous prenez une mauvaise décision d'architecture au départ, le prix à payer, c'est soit [que] vous avez acheté par erreur beaucoup trop d'infrastructure réseau, soit que vous devez tout racheter et tout réaménager."

Mesurer le coût de la sécurité

IBM ne considère pas les contrôles de sécurité comme gratuits. L'entreprise mesure leur impact sur les performances à l'aune de résultats de benchmarks et s'appuie sur ces chiffres dans ses discussions avec les équipes de sécurité sur les compromis à faire. L'isolation des charges de travail est une composante de cette architecture de sécurité, aux côtés de l'intégration de l'identité d'entreprise.

Brian Belgodere présente l'enjeu global comme une question de provenance. "C'est un problème de chaîne d'approvisionnement, de bout en bout", affirme-t-il. "Ce n'est pas seulement le matériel, c'est le firmware, le niveau du noyau, le code, la provenance de vos données. Ensuite, on entre dans tout l'univers des agents, de vos images. C'est clairement un problème de provenance."

Une vue d'ensemble

Cet entretien montre que la sécurité des agents descend dans la pile. Une grande partie du débat public porte sur le comportement des modèles : ce que dit un agent, ce qu'il refuse, sa réaction face à l'injection de prompt. L'approche d'IBM suggère que pour les équipes qui font tourner des agents à grande échelle, la frontière la plus importante pourrait être physique et architecturale. C'est-à-dire sur quelle machine s'exécute le code, quelle identité il porte et quel stockage il peut voir.

Cela s'inscrit dans une tendance plus large. Des incidents récents, comme des agents qui ont divulgué des captures d'écran d'entreprises sur GitHub, montrent ce qui peut arriver quand des agents obtiennent plus d'accès que nécessaire. CoreWeave développe aussi des partenariats de sécurité ailleurs, notamment son travail avec CrowdStrike. IBM a fait des choix similaires côté outillage en proposant une version auto-hébergée d'IBM Bob pour les environnements isolés.

Deux points méritent d'être suivis. D'abord, si l'exécution en bac à sable deviendra une fonctionnalité standard sur laquelle les clouds GPU se font concurrence plutôt qu'une option. Ensuite, si l'habitude d'IBM de mesurer le coût en performances de chaque contrôle fera des émules. Si davantage d'équipes publient ce genre de chiffres, le débat entre sécurité et vitesse pourrait reposer sur des données plutôt que sur des suppositions.