Alibaba ha presentado QwenGyre, un marco de aprendizaje por refuerzo diseñado para el que el equipo de investigación de la empresa denomina entrenamiento de agentes de "horizonte XLong": tareas en las que una sola ejecución puede durar horas, implicar cientos de interacciones entre el modelo y su entorno, y consumir cerca de un millón de tokens.

El marco responde a un cambio en la forma en que se despliegan los agentes LLM. A medida que pasan de resolver problemas individuales de repositorios a construir bases de código completas, los pipelines convencionales de RL en línea se topa con dos obstáculos. Las duraciones de las ejecuciones varían tanto que las GPU permanecen inactivas mientras terminan unas pocas ejecuciones rezagadas, y las rutas de ejecución ramificadas generan enormes volúmenes de datos de entrenamiento redundantes. En horizontes que se miden en horas y cientos de miles de tokens, ambos obstáculos se convierten directamente en cómputo desperdiciado: el hardware inactivo durante las colas de ejecución y los tokens duplicados elevan el costo de cada ciclo de entrenamiento.

El Elastic Scheduler ataca la subutilización de GPU

El primer componente, el Elastic Scheduler, aborda la subutilización de las GPU. Los marcos existentes suelen hacer una de dos cosas: alternar un grupo completo de GPU entre ejecución y entrenamiento (colocate), dejando el hardware inactivo durante largas colas de ejecución, o particionar estáticamente las GPU entre ambas etapas (async), lo que impide que un lado tome prestada la capacidad libre del otro. Cada diseño intercambia una forma de tiempo inactivo por otra — el enfoque colocate deja inactivo todo el grupo durante las colas de ejecución, mientras que el enfoque async bloquea la capacidad libre en el lado que no puede usarla.

QwenGyre, en cambio, agrupa el hardware en "celdas" conmutables de forma independiente que se reasignan entre inferencia y entrenamiento a medida que cambia el volumen de trabajo de ejecución pendiente. Las ejecuciones activas del harness nunca se interrumpen: las solicitudes del modelo se redirigen en pleno vuelo a los motores de ejecución restantes, con las cachés KV migradas por RDMA (acceso directo a memoria remota) para que no haya que repetir ningún cálculo. Las celdas liberadas se incorporan al paso de entrenamiento en curso como réplicas adicionales en paralelo de datos, obteniendo los pesos autoritativos una celda núcleo, mientras que el entrenamiento en streaming distribuye los micro-lotes según el progreso de cada grupo para que todas las celdas terminen en sincronía.

Las transiciones de rol son rápidas. En promedio, cambiar de ejecución a entrenamiento toma 8.5 segundos, y volver toma 3.5 segundos — insignificant frente a ejecuciones que duran horas.

Domando trayectorias ramificadas

El segundo componente, el Trajectory Processor, se encarga de los propios datos de entrenamiento. En horizontes XLong, los harness de agentes comprimen contextos saturados, delegan subtareas a sub-agentes y reintentan rutas fallidas, por lo que una sola ejecución produce un árbol ramificado de rutas de contexto divergentes en lugar de una trayectoria lineal. Expandir ingenuamente cada ruta duplica los prefijos compartidos e infla el costo de entrenamiento — una carga que crece con los contextos de casi un millón de tokens que estas ejecuciones producen.

QwenGyre, en cambio, reconstruye la ejecución como un árbol de trayectorias con prefijos compartidos, preservando el contexto de condicionamiento original exacto de cada salida del modelo. Solo se entrenan los tokens realmente generados por la política, y los objetivos compartidos se cuentan una sola vez mediante enmascaramiento en el árbol.

El progreso parcial también se evalúa: las ejecuciones que alcanzan su tiempo límite se evalúan aún sobre su estado de espacio de trabajo preservado, de modo que los intentos parciales conllevan recompensas significativas en lugar de descartarse. Dado que una sola ejecución puede retener el hardware durante horas, esa recuperación conserva señal que de otro modo se desecharía. En la admisión al entrenamiento, se selecciona un número acotado de trayectorias por ejecución — limitado por prioridad de rol, primero el agente principal, luego los sub-agentes y después las rutas de resumen — y las pérdidas de tokens se promedian dentro de cada ejecución para que el número de rutas no distorsione la ponderación.

Resultados de referencia

Aplicado al modelo insignia Qwen 3.8-2.4T de Alibaba con aproximadamente 700K tokens por ejecución, QwenGyre elevó la tasa de aprobación de NL2RepoBench de 52.5% a 58.5% en 48 pasos de entrenamiento, completándolos en 75.4 horas frente a 134.6 horas de la línea base async y 91.5 horas de la línea base colocate — aceleraciones de hasta 1.78× y 1.85× respectivamente, logradas mientras se igualaban las puntuaciones de entrenamiento de las líneas base. Las mejoras se mantuvieron de forma consistente en las tres cargas de trabajo evaluadas — NL2RepoBench, DeepSWE y TerminalBench — bajo presupuestos de GPU iguales.

Las casi 60 horas recuperadas frente a la línea base async subrayan por qué la programación importa a esta escala: un menor tiempo de reloj con puntuación equivalente reduce el costo temporal de cada ciclo de entrenamiento. Para los lectores que evalúen afirmaciones similares de infraestructura, los detalles a tener en cuenta son las dos condiciones adjuntas a estas cifras — puntuaciones de entrenamiento iguales y presupuestos de GPU equivalentes — y el hecho de que todas las cifras provienen de ejecuciones de aproximadamente 700K tokens, el régimen XLong para el que el marco está diseñado.

Fuente: QwenGyre de Alibaba aborda el problema del millón de tokens con programación elástica de GPU para RL XLong vía Metaverse Post.