Los investigadores de Moonshot AI presentan Seer: un sistema de aprendizaje contextual en línea para implementaciones rápidas y sincrónicas de aprendizaje por refuerzo de RL

¿Cómo se puede evitar que el aprendizaje por refuerzo para modelos de razonamiento grandes se estanque en algunas implementaciones muy largas y lentas mientras las GPU no se utilizan? Un equipo de investigadores de Moonshot AI y la Universidad de Tsinghua presenta ‘Seer’, un nuevo sistema de aprendizaje contextual en línea que apunta a un cuello de botella de sistemas específicos en el aprendizaje por refuerzo para modelos de lenguaje grandes. En configuraciones de políticas sincrónicas, la fase de implementación domina el costo de cada iteración. Seer reestructura esta fase e informa ganancias en el rendimiento de implementación del 74 por ciento al 97 por ciento y reducciones de la latencia de cola del 75 por ciento al 93 por ciento en comparación con una base sincrónica sólida llamada veRL.

https://arxiv.org/pdf/2511.14617

¿Por qué la implementación sincrónica es lenta para los modelos de razonamiento?

Las cargas de trabajo de RL de razonamiento moderno utilizan una larga cadena de resultados de estilos de pensamiento. En los experimentos de Seer, los investigadores aplican GRPO a tres modelos diferentes, Moonlight, Qwen2 VL 72B y Kimi K2. Estas cargas de trabajo se ejecutan en 32 nodos informáticos con 8 GPU H800 por nodo. Las tres tareas utilizan 32, 128 y 256 GPU respectivamente, con 400, 600 y 800 mensajes por iteración y 8 o 16 respuestas por mensaje.

La longitud máxima de generación es grande. Moonlight está configurado para 65,536 tokens, Qwen2 VL 72B para 40,960 tokens y Kimi K2 para 98,304 tokens. Una sola y larga cadena de solicitud de pensamiento puede crecer desde unos pocos cientos de megabytes de KVCache hasta decenas de gigabytes a medida que avanza la decodificación. Este crecimiento de la memoria obliga a las instancias a reducir la concurrencia o a adelantarse a las solicitudes, lo que desencadena una costosa redecodificación.

El equipo de investigación define las solicitudes finales como el último 10 por ciento de las solicitudes que finalizan en una implementación. Para Moonlight y Qwen2 VL 72B, esta cola por sí sola puede consumir hasta el 50 por ciento del tiempo total de implementación en el sistema de referencia. El despliegue ya domina el tiempo de iteración, por lo que este efecto de cola ralentiza directamente RL.

https://arxiv.org/pdf/2511.14617

Arquitectura vidente sobre Mooncake y vLLM

Seer mantiene el algoritmo RL idéntico al veRL sincrónico. Cada iteración de entrenamiento utiliza solo datos de la iteración de implementación actual, por lo que el sistema conserva el comportamiento de las políticas. La fase de formación utiliza Megatron para la optimización distribuida. La fase de implementación utiliza una implementación interna de vLLM como motor de inferencia.

Para respaldar una programación de solicitudes agresiva, Seer se basa en un grupo global de KVCache creado sobre la arquitectura KVCache desagregada de Mooncake utilizada en la producción de Kimi. Mooncake proporciona un almacén de caché KV DRAM y SSD de dos niveles compartido entre nodos de inferencia, lo que permite a Seer migrar solicitudes sin volver a calcular los precargas.

Además de este sustrato, Seer introduce tres mecanismos clave:

Despliegue dividido Programación consciente del contexto Decodificación especulativa agrupada adaptativa

Estos están orquestados por un búfer de solicitud, un administrador de contexto y un grupo de motores de inferencia conectados al grupo global de KVCache.

https://arxiv.org/pdf/2511.14617

Implementación dividida, programación detallada y migración

La implementación sincrónica convencional asigna grupos GRPO completos a instancias de inferencia. Un grupo es un conjunto de solicitudes que comparten un mensaje. Una vez asignado, un grupo permanece en la misma instancia hasta que finalicen todas las respuestas. Debido a la gran variación en las longitudes de salida, esto conduce a un desequilibrio de carga y a rezagos de larga duración.

Seer divide los grupos en dos pasos. Primero descompone cada grupo en solicitudes individuales. Luego divide cada solicitud en varios fragmentos según la duración de la generación. Cuando el programador envía una solicitud desde el búfer de solicitudes, establece un pequeño valor máximo de tokens, como 8000 tokens para ese fragmento. Después de cada fragmento, la solicitud se vuelve a poner en cola hasta que alcanza un token de fin de secuencia o su límite máximo de tokens original.

Debido a que KVCache se almacena en el grupo global de KVCache, las solicitudes divididas pueden moverse entre instancias en límites de fragmentos sin volver a ejecutar el prellenado. El programador mantiene un nivel de concurrencia que mantiene alta la utilización de la memoria y al mismo tiempo evita la preferencia. Esto reduce el desperdicio y suaviza el uso de KVCache durante la iteración.

Programación consciente del contexto utilizando estadísticas de duración del grupo

El equipo de investigación observa que diferentes solicitudes en el mismo grupo tienden a tener duraciones de salida correlacionadas. Seer utiliza esta estructura como contexto en línea. Para cada grupo de avisos, designa una solicitud como solicitud especulativa. El programador mantiene las solicitudes especulativas en una cola de alta prioridad y las atiende con una primera política más pequeña basada en los tokens generados hasta el momento. Las solicitudes breves se completan rápidamente y salen. Quedan solicitudes largas e identifican grupos que son candidatos potenciales a la cola.

El Administrador de contexto mantiene una estimación de la longitud de cada grupo. Actualiza esta estimación a la longitud máxima generada entre las solicitudes completadas en el grupo. Si no ha finalizado ninguna solicitud, utiliza los tokens máximos originales como límite conservador. Una vez que las solicitudes especulativas están en curso o finalizadas, Seer programa las solicitudes restantes con una primera política aproximada más larga a nivel de grupo. Este diseño logra un rendimiento y un comportamiento de cola cercano a un programador de Oracle que conoce todas las longitudes de salida de antemano.

https://arxiv.org/pdf/2511.14617

Decodificación especulativa agrupada adaptativa

Seer agrega decodificación especulativa agrupada adaptativa además de los dos componentes anteriores para acelerar la decodificación, especialmente para solicitudes largas en la cola. Introduce un servidor de borrador agrupado distribuido, o DGDS. DGDS mantiene un árbol de sufijos comprimidos para cada grupo y agrega secuencias de tokens de todas las solicitudes de ese grupo. Las instancias agregan de forma asincrónica tokens generados a DGDS, obtienen periódicamente árboles de sufijos actualizados y realizan decodificación especulativa local basada en las estadísticas de patrones compartidos.

El sistema ajusta la longitud del borrador y el número de rutas según la arquitectura del modelo, el tamaño del lote y la longitud de aceptación medida. Para los modelos densos y de mezcla de expertos, calcula previamente diferentes umbrales de especulación y los utiliza para limitar la profundidad del borrador para cada lote. En las últimas etapas finales, la concurrencia es baja, por lo que Seer aumenta la profundidad del borrador y permite el borrador de múltiples rutas para generar tokens aceptados por paso.

Los resultados de la ablación muestran que la implementación dividida produce una mejora del rendimiento de hasta un 35 por ciento con respecto a la línea de base. Agregar la programación consciente del contexto aumenta esto hasta en un 47 por ciento con respecto al valor inicial. Habilitar la decodificación especulativa agrupada aumenta la aceleración total entre un 77 y un 87 por ciento con respecto a la línea de base en la iteración evaluada.

Impacto de principio a fin en la formación de RL

El equipo de investigación evalúa a Seer en tres tareas RL construidas en Moonlight, Qwen2 VL 72B y Kimi K2. Ejecutan 10 iteraciones de implementación por tarea y miden los tokens de salida por segundo y el tiempo de finalización de cada implementación. Seer mejora el rendimiento de la implementación entre un 74 y un 97 por ciento en estas cargas de trabajo en relación con veRL con el mismo algoritmo RL y motor de inferencia basado en vLLM.

La latencia de cola se reduce entre un 75 y un 93 por ciento. Para tareas con memoria limitada, el sistema de referencia dedica hasta la mitad de su tiempo al último 10 por ciento de las solicitudes. Seer elimina la mayor parte de esta cola al combinar la implementación dividida, la programación consciente del contexto y la decodificación especulativa agrupada adaptativa además del grupo global KVCache basado en Mooncake.

Conclusiones clave

Cuello de botella de implementación: Seer apunta a la fase de implementación de RL sincrónica, que representa aproximadamente del 63 % al 87 % del tiempo de iteración y está dominada por solicitudes de cola larga y fragmentación de caché KV. Tres mecanismos centrales: Seer combina la implementación dividida, la programación consciente del contexto y la decodificación especulativa agrupada adaptativa para explotar la longitud de la salida y la similitud de patrones entre las respuestas GRPO que comparten un mensaje. Programación detallada en un caché KV global: las solicitudes se dividen en fragmentos y se migran a través de un grupo de KVCache global estilo Mooncake, que preserva la sincronía en la política RL al mismo tiempo que mantiene alta la utilización de la memoria de la GPU y reduce las apropiaciones. Contexto en línea para la reducción de la latencia de cola: las estadísticas de longitud a nivel de grupo de solicitudes especulativas impulsan una programación consciente del contexto que se aproxima al primer programador más largo de Oracle y reduce drásticamente el tiempo dedicado al último 10 por ciento de las solicitudes. Ganancias medidas de extremo a extremo: en cargas de trabajo RL de grado de producción con Moonlight, Qwen2 VL 72B y Kimi K2, Seer mejora el rendimiento de implementación entre un 74 % y un 97 % y reduce la latencia de cola larga entre un 75 % y un 93 % en relación con una línea base sincrónica basada en vLLM de última generación.

Seer es una contribución importante a los sistemas porque optimiza la fase de implementación en RL síncrona sin cambiar el algoritmo GRPO subyacente, por lo que preserva las garantías políticas y la reproducibilidad al tiempo que soluciona un cuello de botella de infraestructura real. La combinación de implementación dividida, programación consciente del contexto y decodificación especulativa agrupada adaptativa ofrece una plantilla práctica para otras pilas de RL que se basan en una larga cadena de modelos de razonamiento de pensamiento y grandes huellas de KVCache. En general, Seer muestra que el aprendizaje contextual en línea a nivel de sistemas es ahora tan crítico como la arquitectura modelo para escalar el razonamiento RL de manera eficiente.

Consulte el documento aquí. No dude en consultar nuestra página de GitHub para tutoriales, códigos y cuadernos. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 100.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.

Asif Razzaq es el director ejecutivo de Marktechpost Media Inc.. Como empresario e ingeniero visionario, Asif está comprometido a aprovechar el potencial de la inteligencia artificial para el bien social. Su esfuerzo más reciente es el lanzamiento de una plataforma de medios de inteligencia artificial, Marktechpost, que se destaca por su cobertura en profundidad del aprendizaje automático y las noticias sobre aprendizaje profundo que es técnicamente sólida y fácilmente comprensible para una amplia audiencia. La plataforma cuenta con más de 2 millones de visitas mensuales, lo que ilustra su popularidad entre el público.

🙌 Siga MARKTECHPOST: agréguenos como fuente preferida en Google.