En el ámbito del entrenamiento de agentes de inteligencia artificial (IA), incluso con potentes GPUs a disposición, gran parte del tiempo se consume en periodos de espera. Los agentes deben ejecutar tareas y producir resultados antes de que el modelo pueda aprender de ellos, y algunos intentos lentos retrasan las actualizaciones del entrenamiento. Esto convierte a los sistemas encargados de ejecutar esas tareas en un factor clave para la velocidad y el coste del entrenamiento.
Di Jin, vicepresidente de AI Training en Nebius, una empresa con sede en Ámsterdam, advierte que los equipos acostumbrados al pre-entrenamiento o al ajuste supervisado subestiman el papel crucial que juegan estos sistemas. Según Jin, «si se organiza y equipa el proyecto solo como entrenamiento, la inferencia se vuelve el cuello de botella que nadie asume».
El tiempo hasta obtener lotes entrenables
La generación de rollouts o trayectorias suele consumir la mayoría del tiempo real (reloj) de cada paso de entrenamiento. Esto hace que la gestión de lotes, cachés y planificación sean elementos fundamentales para que el modelo aprenda rápidamente. Jin destaca que además de medir el rendimiento a través del número promedio de tokens procesados por segundo, es vital analizar el tiempo necesario para formar un lote entrenable, ya que la ejecución de un lote sincrónico depende del paso más lento —las trayectorias no tienen todas la misma longitud y algunas tardan mucho más que otras, haciendo que el GPU se quede parado esperando. 
La importancia de entender los datos y la latencia temporal
Cuando el entrenamiento se realiza con datos generados por una versión anterior del modelo, surge una compensación. Un cierto desfase en las políticas puede mejorar la eficiencia de los GPUs permitiendo que la generación de datos y el entrenamiento se solapen, pero esto solo funciona si la política no ha cambiado drásticamente y si el algoritmo de entrenamiento puede manejar esa diferencia.
Jin explica que en un entrenamiento por refuerzo completamente sincrónico, los GPUs dedicados a inferencia esperan a que termine el entrenamiento y viceversa. Sin embargo, si la generación utiliza pesos ligeramente obsoletos (uno o pocos pasos atrás), ambos procesos pueden ejecutarse en paralelo, optimizando la utilización, especialmente en tareas difíciles donde las trayectorias exitosas valen la pena reutilizar, incluso si están algo anticuadas.
El riesgo está en la divergencia o alejamiento entre la política que generó la trayectoria y la que está siendo entrenada actualmente. «La antigüedad no es el enemigo, sino la antigüedad no medida», enfatiza Jin. Por tanto, en lugar de eliminar datos antiguos, es fundamental medir y gestionar esa antigüedad, aplicando correcciones mediante técnicas como el muestreo por importancia, descartando o reduciendo el peso de muestras muy obsoletas y monitorizando la divergencia entre políticas.
Los entornos como clave para el aprendizaje
Di Jin subraya que en el pos-entrenamiento con aprendizaje por refuerzo (RL), la mayor parte del trabajo recae en la gestión de datos y entornos, siendo el diseño de algoritmos solo una pequeña parte y la infraestructura determinante para la rapidez de iteración. En contextos de RL agentic, el propio modelo genera experiencias mediante la interacción con entornos, a diferencia del ajuste supervisado que utiliza conjuntos de datos preexistentes.
Es esencial contar con contenedores reproducibles, bases de código, sitios web y APIs que reflejen estados realistas para asegurar que el aprendizaje del agente se transfiera efectivamente a aplicaciones reales. También se necesitan verificadores fiables y tareas de dificultad adecuada para evitar que el modelo se estanque y deje de aprender. Jin afirma que «construir entornos es la nueva curación de datos».
Los problemas suelen aparecer en las interfaces entre componentes: entrenador, motor de inferencia, sandbox, y verificador. Por ejemplo, un modelo puede explotar fallos en los verificadores y recibir recompensas inesperadas, o un sandbox puede fallar, corrompiendo los datos de entrenamiento. Es crucial registrar los resultados de cada episodio distinguiendo entre éxito del modelo, fallo del modelo, fallo de infraestructura o resultado desconocido para solo incluir en el entrenamiento los datos fiables.
Optimización en la gestión de lotes y recursos
El entrenamiento agente a agente con largas trayectorias combina llamadas a herramientas y latencias externas, lo que genera picos de demanda de GPU y momentos de espera. Para entrenamientos de tipo GRPO, donde varios intentos se comparan para seleccionar los mejores, la organización debe centrarse en la finalización grupal, no en el orden de lanzamiento. Un grupo entra en la lista de listo cuando todos sus intentos terminan, y el entrenador selecciona entonces los grupos completamente listos, independientemente de cuándo comenzaron.
En un experimento realizado por Nebius en una carga de trabajo basada en Terminal-Bench, cambios en el enrutamiento, la ejecución en sandbox y la composición de lotes permitieron reducir en un 66,9% el tiempo necesario para recolectar un lote de 256 trayectorias, sin contar el trabajo del entrenador en optimizaciones. Esto refleja un avance significativo en la eficiencia del proceso.
Un objetivo clave en infraestructura para despliegues de IA agente es minimizar el tiempo que las GPUs costosas pasan esperando a que se completen operaciones en sandboxes, navegadores o ejecuciones de código, que son dependencias no relacionadas directamente con GPUs. Jin comenta: «Tu GPU más cara a menudo está esperando a tu contenedor más barato». Por ello, recomienda escalar independientemente la capacidad de CPU y sandboxes, y provisionarlas abundantemente, dado que los contenedores inactivos son económicos.
Mantener los sandboxes listos mediante técnicas de snapshot y fork ayuda a evitar tiempos de arranque en el camino crítico del entrenamiento. Además, colocar sandboxes en la misma red que las GPUs reduce la latencia acumulada de las numerosas llamadas que puede realizar un agente. Limitar pérdidas por procesos colgados con límites de tiempo por paso y presupuestos contribuye a mayor estabilidad. También es fundamental monitorizar las horas de GPU desperdiciadas esperando entornos para identificar mejor dónde invertir.
Consistencia numérica y actualización de pesos
Durante el pos-entrenamiento, el motor de generación y el entrenador pueden asignar distintas probabilidades a los mismos tokens incluso partiendo de idénticos pesos, debido a factores como la cuantización, los kernels, el batching o el enrutamiento de expertos en modelos mixtos. Estas diferencias pueden introducir sesgos sistémicos en las actualizaciones.
Jin aconseja alinear primero la precisión numérica entre sistemas y luego medir y corregir cualquier discrepancia restante, por ejemplo, empatando los esquemas de cuantización y el cálculo utilizado en la inferencia con el del entrenamiento, manteniendo pesos en mayor precisión para optimización. Las correcciones usando muestreo por importancia ayudan pero no resuelven todo.
Las evaluaciones deben realizarse con la precisión, motor de inferencia y versión que se usará en producción para evitar sorpresas después del despliegue. Cualquier cambio en cuantización o kernels debe implicar una reevaluación.
En cuanto a la actualización de pesos, el reto está en que los trabajadores de generación reciban las nuevas versiones de la política manteniendo el desfase (lag) dentro de márgenes aceptables. Jin describe tres estrategias principales: redistribuir pesos en memoria cuando entrenamiento e inferencia comparten GPUs; transferir pesos directamente a trabajadores de inferencia separados; y publicar puntos de control (checkpoints) que las inferencias cargan en caliente desde almacenamiento. La elección adecuada depende del modelo, la topología del hardware y los requisitos de frescura.
Evitar paradas completas en el servicio es posible usando transferencias asincrónicas y actualizaciones compactas que no afecten la continuidad del proceso. Hay que gestionar explícitamente las peticiones activas y las cachés durante actualizaciones, pudiendo terminar, abortar o pausar solicitudes y limpiar o recalcular contextos guardados. Cuando una trayectoria abarca varias versiones de política, debe quedar registrado para que el sistema de entrenamiento maneje esta mezcla de forma controlada.
Jin recomienda que los equipos pequeños comiencen con arquitecturas sencillas e incorporen complejidad asíncrona solo cuando los cuellos de botella medidos lo justifiquen.
Checklist para escalar correctamente el entrenamiento
- Preparación de lotes: tiempo para ensamblar un lote completo y usable, incluyendo los intentos más lentos.
- Frescura de la política: rastrear la versión que generó cada rollout y definir qué divergencia es demasiado obsoleta.
- Alineación numérica: medir y corregir las diferencias entre probabilidades del entrenamiento y la inferencia.
- Confiabilidad del entorno: distinguir fallos de infraestructura de fallos del modelo y garantizar reproducibilidad.
- Publicación de pesos: gestionar qué ocurre con peticiones activas y cachés durante actualizaciones, y medir la latencia completa.
- Evaluación: usar la precisión y motor con los que realmente se desplegará el modelo.
Gracias a estos avances en infraestructura y metodologías, Nebius ha reducido significativamente los tiempos de entrenamiento, optimizando recursos y mejorando la calidad del aprendizaje de agentes inteligentes, un aspecto crucial para el futuro de la IA aplicada.
