IBM y CoreWeave diseñan controles para cargas de agentes
Durante años, la principal función de un clúster de investigación en IA fue entrenar modelos. Esa función se está ampliando. En cuanto los equipos recurren al aprendizaje por refuerzo (RL, por sus siglas en inglés) y empiezan a probar agentes, la misma infraestructura tiene que ejecutar el código que generan los modelos, llamar a herramientas, leer y escribir en el almacenamiento y conectarse a otros servicios. El entrenamiento puro nunca planteó la cuestión de dónde debía ejecutarse ese código ni a qué debía tener acceso. El trabajo con agentes sí lo hace.
IBM Research está abordando esa cuestión junto a CoreWeave, el proveedor de nube de GPU. Brian Belgodere, miembro sénior del personal técnico de IBM, describió la colaboración en una entrevista con Dave Vellante y John Furrier, de theCUBE Research, durante el evento Fully Connected. La entrevista se emitió en theCUBE, el estudio de retransmisión en directo de SiliconANGLE Media. theCUBE es socio mediático remunerado del evento, y CoreWeave patrocinó su cobertura. SiliconANGLE asegura que los patrocinadores no tienen control editorial sobre sus contenidos.
Por qué el aprendizaje por refuerzo cambia el clúster
Belgodere explicó que el RL añade una fase de ejecución de tareas al desarrollo de modelos. "El proceso de RL [consiste en que] estás en mitad del entrenamiento de un modelo", dijo. "En algún momento, coges ese punto de control, lo cargas en inferencia, le pides que haga algo y vas midiendo. Esa es tu fase de pruebas".
En la práctica, el bucle de entrenamiento incluye ahora un paso de inferencia y otro de ejecución. Se carga un punto de control, se le asigna una tarea y se puntúa el resultado. En la investigación con agentes, esa tarea puede consistir en ejecutar código. Es un perfil de riesgo distinto al de una GPU haciendo cálculo matricial, y hay que preverlo en el plano de la infraestructura.
De un clúster H100 propio a CoreWeave
La historia de la infraestructura de IBM arranca con Granite, su familia de modelos de IA. Desarrollarlos exigió muchísima capacidad de cálculo, y al principio IBM la construyó por su cuenta. "Salimos a montar un gran clúster de H100 y lo hicimos nosotros mismos: conseguimos el espacio, todo de principio a fin. Fue una tarea enorme", contó Belgodere.
La siguiente generación de hardware trajo unas exigencias de refrigeración y energía que, según Belgodere, contribuyeron a que IBM optara por trabajar con CoreWeave en lugar de repetir la fórmula de hacerlo todo por su cuenta.
Ingeniería conjunta en identidad
Desde entonces, la relación ha ido más allá del alquiler de capacidad. IBM trasladó a CoreWeave sus requisitos para extender sus sistemas internos de identidad al entorno de CoreWeave. Después, ambas compañías fueron perfeccionando la implementación a lo largo de varias iteraciones.
Belgodere afirmó que la colaboración funciona en las dos direcciones. "A menudo son ellos los que vienen y nos dicen: 'Oye, estamos pensando en esto, ¿nos dais vuestra opinión?'", explicó. "Y lo revisamos encantados".
Esto es relevante para los clientes empresariales. Las grandes organizaciones rara vez quieren un sistema de identidad distinto para cada proveedor de nube. Llevar la identidad corporativa existente a la plataforma del proveedor permite mantener el control de acceso en un único lugar.
Elegir dónde se ejecuta el código de los agentes
La mayor parte del clúster de IBM Research es de uso exclusivo, es decir, el hardware no se comparte con otros clientes. IBM también ha desplegado su propio almacenamiento dentro de CoreWeave y puede recurrir a capacidad adicional siempre que se mantenga dentro de sus parámetros de coste y seguridad.
La colaboración abarca también CoreWeave Sandboxes, que permiten una ejecución aislada, ya sea en infraestructura dedicada o mediante un entorno de ejecución gestionado sin servidor. Los investigadores pueden decidir dónde se ejecuta el código de los agentes y a qué recursos puede acceder.
Belgodere advirtió de que los equipos suelen equivocarse en estas primeras decisiones. "Hay muchos errores, y la gente tiende a subestimar lo que cuesta cambiar algunas de estas decisiones", señaló. "Si tomas una mala decisión de arquitectura al principio, el precio será o bien que has comprado sin querer muchísima más infraestructura de red de la necesaria, o bien que tienes que salir a comprar y reacondicionarlo todo".
Medir lo que cuesta la seguridad
IBM no da por hecho que los controles de seguridad salgan gratis. Mide su impacto en el rendimiento con resultados de pruebas comparativas y utiliza esas cifras en sus conversaciones con los equipos de seguridad sobre las contrapartidas. El aislamiento de cargas de trabajo es una pieza de esa arquitectura de seguridad, junto a la integración de la identidad empresarial.
Belgodere planteó el reto de fondo como una cuestión de procedencia. "Esto es un problema de cadena de suministro, de arriba abajo", afirmó. "No es solo el hardware, es el firmware, el nivel del kernel, el código, la procedencia de tus datos. Y luego entras en todo el mundo de los agentes, tus imágenes. Es un problema de procedencia en toda regla".
El panorama general
La entrevista deja claro que la seguridad de los agentes está bajando por la pila tecnológica. Buena parte del debate público se centra en el comportamiento de los modelos: lo que dice un agente, lo que se niega a hacer, cómo reacciona ante una inyección de instrucciones. El enfoque de IBM sugiere que, para los equipos que ejecutan agentes a gran escala, la frontera más importante puede ser física y de arquitectura. Es decir, en qué máquina se ejecuta el código, qué identidad tiene y qué almacenamiento puede ver.
Esto encaja en una tendencia más amplia. Incidentes recientes, como el de los agentes que filtraron capturas de pantalla de empresas en GitHub, muestran lo que puede ocurrir cuando los agentes reciben más acceso del que necesitan. CoreWeave también está tejiendo alianzas de seguridad en otros frentes, como su trabajo con CrowdStrike. IBM ha dado pasos similares en el terreno de las herramientas al ofrecer una versión autoalojada de IBM Bob para entornos aislados de la red.
Hay dos cosas que conviene seguir de cerca. La primera, si la ejecución aislada se convierte en una prestación estándar con la que compitan las nubes de GPU en lugar de un complemento. La segunda, si se extiende la costumbre de IBM de medir el coste en rendimiento de cada control. Si más equipos publican este tipo de cifras, el debate entre seguridad y velocidad podría basarse en datos y no en suposiciones.