SemiAnalysis: La eficiencia en el entrenamiento de aprendizaje por refuerzo depende de igualar el rendimiento, no solo de escalar la computación
Experimentos en frameworks de RL de código abierto revelan el cuello de botella crítico para escalar las capacidades de los modelos - 16 de junio de 2026
El post-entrenamiento mediante aprendizaje por refuerzo (RL, por sus siglas en inglés) se ha convertido en el ingrediente secreto detrás de los modelos de IA más capaces, pero escalar el RL es sumamente costoso. SemiAnalysis llevó a cabo extensos experimentos en frameworks de RL de código abierto para comprender qué impulsa realmente la eficiencia del sistema en el entrenamiento de RL. La sorprendente respuesta: no se trata de destinar más capacidad de cómputo al problema, sino de equilibrar cuidadosamente el rendimiento (throughput) entre dos componentes clave: el generador que crea los datos de entrenamiento y el entrenador que aprende de ellos.
El equipo de investigación ejecutó experimentos utilizando modelos como Qwen3-235B y GLM-5 en diferentes frameworks de RL, incluidos Prime RL, slime y verl. Lo que descubrieron desafía fundamentalmente el pensamiento convencional sobre el diseño de infraestructura de RL.
El problema de salud de las colas del que nadie habla
SemiAnalysis define la eficiencia del entrenamiento de RL a través de un modelo mental elegante: una cola donde el generador produce "rollouts" (resultados de ejecución) y el entrenador los consume. Cuando el generador es más lento, el entrenador se queda sin datos y permanece inactivo. Cuando el generador es más rápido, las muestras envejecen en la cola, creando lo que el equipo denomina "obsolescencia de políticas" (policy staleness), un fenómeno donde el modelo se entrena con resultados generados por versiones anteriores de sí mismo, lo que degrada la calidad del aprendizaje.
En su primer experimento importante con Qwen3-235B-Thinking en 64 GPUs H200 para entrenamiento y 192 GPUs para generación, el sistema se vio severamente limitado por la generación. El entrenador consumía muestras a una tasa de 2,75 por segundo, pero esperaba el 30% del tiempo total, operando a solo el 10,5% de la utilización de FLOPs del modelo. El generador entregó solo 1,95 muestras por segundo a pesar de utilizar tres veces el cómputo del entrenador. La causa: el modelo producía respuestas extremadamente largas con trazas de razonamiento extendidas, y la varianza en la longitud de las respuestas creó graves problemas de latencia de cola (tail latency).
Para manejar esto, el equipo tuvo que descartar el 60% de los rollouts enviados mediante una técnica llamada sobremuestreo (oversampling): lanzar más rollouts concurrentes de los necesarios y descartar los inacabados. Este enfoque ineficiente subraya cuán crítica se vuelve la eficiencia de la inferencia durante el entrenamiento de RL, un punto que parece subestimado en las discusiones actuales sobre infraestructura de RL.
La deriva del comportamiento del modelo crea objetivos móviles
Un segundo experimento con GLM-5 en 128 GPUs H200 reveló otra dimensión del problema que hace que el diseño de sistemas de RL sea excepcionalmente desafiante: el comportamiento del modelo cambia durante el entrenamiento de formas que alteran las restricciones del sistema. A lo largo del entrenamiento, la longitud promedio de respuesta por turno y el número de llamadas a herramientas se triplicaron, pasando de 20 a 51. Esto aumentó la longitud de las secuencias y desplazó la carga de trabajo hacia un perfil intensivo en prefill, cambiando fundamentalmente la configuración óptima de la infraestructura a mitad del entrenamiento.
Para empeorar las cosas, el plan de estudios resultó ser demasiado fácil para el modelo: el 55% de los problemas tuvo una tasa de resolución del 100%, donde cada rollout del grupo tuvo éxito. Cuando todos los rollouts reciben la misma recompensa, el cálculo de la ventaja (advantage) produce cero y el grupo no contribuye con ninguna señal de entrenamiento. Como explica SemiAnalysis, esto sucede cuando "la tasa de resolución es cercana al 100% o cercana al 0%": la tarea es demasiado fácil o demasiado difícil. La recompensa promedio se mantuvo plana a pesar del gasto en cómputo.
Los efectos combinados resultaron en un sistema fuertemente limitado por la generación, donde el entrenador pasó el 74% del tiempo de reloj esperando, y su tasa de consumo fue cinco veces mayor que la tasa de producción entregada por el generador. La tasa efectiva de producción del generador colapsó debido a las muestras filtradas que no proporcionaban ninguna señal de aprendizaje.
El muro de escala de los sandboxes
Un tercer experimento en hardware GB300 aumentó los rollouts concurrentes de 96 a 960 y chocó contra un muro de infraestructura difícil que no se discute lo suficiente: el escalado de sandboxes. Cada rollout requiere al menos un sandbox contenedorizado para ejecutar código y proporcionar recompensas. A 960 rollouts concurrentes, el equipo encontró "errores de inicialización de sandbox y latencia de hasta 1 hora en el inicio de los mismos". Tuvieron que reducir a 96 rollouts concurrentes, pero entonces observaron una baja eficiencia de rollout.
Esto revela una restricción fundamental en el entrenamiento de RL para asistentes de programación que SemiAnalysis valora en más de $30 mil millones en ingresos recurrentes anuales hoy en día entre seis actores principales, con camino a superar los $100 mil millones para fin de año. La infraestructura de sandbox debe escalar linealmente con los rollouts concurrentes, y las empresas de servicios de sandbox como Modal enfrentan desafíos únicos, incluyendo latencia de inicio, demanda fluctuante y robustez ante comportamientos inesperados del modelo, como crear un millón de archivos que agoten la memoria.
Obsolescencia de políticas: El impuesto oculto del entrenamiento asíncrono
Los algoritmos clásicos de gradiente de política asumen que todos los rollouts en un grupo provienen de los mismos pesos del modelo. Esto fuerza una ejecución síncrona donde el generador no puede actualizar los pesos hasta terminar el lote actual, creando una ineficiencia masiva. La industria se ha movido hacia técnicas asíncronas, particularmente PipelineRL, que permite actualizaciones de pesos durante el proceso mientras se siguen generando rollouts.
Pero esto crea obsolescencia de políticas: las muestras son generadas por una mezcla de políticas antiguas y nuevas. SemiAnalysis identifica tres niveles de obsolescencia: a nivel de trayectoria (brecha entre la versión de la política que inició el rollout y la versión actual), a nivel de token (actualizaciones de peso que ocurren a mitad del rollout, por lo que diferentes tokens provienen de diferentes versiones de política) y a nivel de estado del entorno (particularmente relevante para entornos con estado).
El framework slime implementa una función de "rollout parcial" que guarda los rollouts rezagados en un búfer y los reinicia en lotes posteriores, mitigando la latencia de cola. Pero esto introduce una obsolescencia a nivel de estado del entorno que es particularmente insidiosa. Como explica el equipo, "el sandbox en el que despierta no es un repositorio nuevo. El sandbox mantiene las ediciones a medio aplicar, los archivos creados y el estado del directorio de trabajo que la política antigua produjo en sus turnos anteriores. La política más nueva ahora debe continuar desde una situación que no creó y que no necesariamente habría creado por sí misma". Esto corrompe la señal de entrenamiento durante la atribución de ventajas.
La economía cuenta una historia brutal
SemiAnalysis realizó un análisis del costo total de propiedad comparando sus experimentos con Tinker de Thinking Machines Lab, una plataforma gestionada de entrenamiento de RL. Para la infraestructura H200, calculan $1,59 por GPU por hora en costo total de propiedad, con el costo de capital contribuyendo al 72,5%. El costo del servidor sigue siendo el factor dominante con $258.000 por servidor, o el 71% del capex inicial total de $361.000 por servidor.
En su experimento de Qwen3-235B usando slime, llegaron a $16,23 por millón de tokens, 4,86 veces más alto que el objetivo publicado de $4,86 por millón de tokens de Tinker. En Prime RL, la brecha se redujo a 2,01 veces, con $6,90 por millón de tokens frente al objetivo de $3,43 de Tinker. La marcada diferencia entre sus costos en slime y Prime RL subraya cuánto determina la eficiencia de la inferencia el costo total.
SemiAnalysis plantea la hipótesis de que Tinker logra su ventaja de costos principalmente a través de la multi-tenencia. Tinker proporciona una API de entrenamiento de Adaptación de Bajo Rango (LoRA, por sus siglas en inglés) donde múltiples usuarios entrenan modelos compartiendo la mayoría de los pesos. "Del lado del entrenador, Tinker puede aumentar enormemente la eficiencia procesando por lotes las solicitudes de entrenamiento entre usuarios, con algunas modificaciones específicas de LoRA. Del lado de la generación, la multi-tenencia mitiga el efecto de los rezagados al rellenar espacios inactivos con los rollouts de otros inquilinos cuando una ejecución se estanca".
El equipo espera que Thinking Machines Lab también aplique optimizaciones de inferencia como la desagregación prefill-decode y que posiblemente esté utilizando GPUs Blackwell, que ofrecen ganancias de inferencia significativas sobre Hopper según su análisis InferenceX. La ventaja de la multi-tenencia se combina con mejoras de infraestructura y hardware para crear la dramática brecha de costos.
La apuesta de Anthropic por el escalado de RL
El informe proporciona un contexto importante sobre por qué esto es relevante. El CEO de Anthropic, Dario Amodei, ha descrito que el RL muestra "el mismo tipo de escalado que tuvo el pre-entrenamiento, donde el rendimiento aumenta logarítmicamente con el tiempo de entrenamiento". Pero ese escalado es sumamente costoso, lo que hace que la eficiencia del sistema de RL sea fundamental para determinar cuánto RL se puede permitir y, por lo tanto, qué tan lejos pueden avanzar las capacidades del modelo.
Concretamente, Claude Opus 4.8 obtiene un 69,2% en SWE-bench Pro y un 74,6% en Terminal-Bench 2.1, y el entrenamiento de RL se describe como "una parte importante de lo que impulsa la puntuación". Estas capacidades de codificación agéntica no surgen solo del pre-entrenamiento; requieren un post-entrenamiento extenso y costoso mediante aprendizaje por refuerzo.
La comunidad de código abierto ha logrado un progreso notable. SemiAnalysis rastrea el linaje desde OpenRLHF, uno de los primeros esfuerzos tras el lanzamiento de DeepSeek R1, hasta frameworks populares como slime y verl. Numerosos mantenedores de OpenRLHF desarrollaron posteriormente estos frameworks, creando comunidades vibrantes en torno al entrenamiento de RL que el equipo cree que "contribuyeron positivamente a los avances recientes de los modelos chinos". Los frameworks también han permitido a los investigadores académicos desarrollar nuevos algoritmos y técnicas, poniendo la investigación de RL al alcance de la academia.
La experiencia de usuario del framework importa más de lo esperado
El equipo ofrece evaluaciones sinceras de los frameworks que probaron. Prime RL recibe elogios por su ergonomía: la mayoría de los comandos funcionan a través de uv con configuración en archivos toml, además de archivos de habilidades de agente para una integración más fluida. El centro de entornos de RL y el soporte para la desagregación prefill-decode destacan como fortalezas. Pero la fuerte dependencia de uv creó fricción, con el equipo pasando un tiempo significativo "compilando y reinstalando flash attention 3 porque no podíamos entender por qué uv lo desinstalaba".
Prime Sandbox, aún en fase beta, generó muchas ejecuciones fallidas al final de la ejecución. "Los errores incluyen sandboxes colgados que agotan la cuota de sandbox, errores de falta de recursos, problemas de falta de crédito, muchos de los cuales pueden detectarse antes de lanzar una ejecución".
Slime se gana elogios por sus "abstracciones limpias y minimalistas" y particularmente por sus abstracciones de hook que hacen que la personalización sea sencilla. El equipo de desarrollo recibe altas calificaciones por su capacidad de respuesta. La crítica principal: el enfoque en el modo co-ubicado resultó en una documentación escasa de los modos asíncronos, lo que obligó al equipo a descifrar mecanismos "principalmente mediante prueba y error".
La API de sandbox de Modal recibe elogios por la calidad de la documentación y la robustez del servicio a pequeña escala. Surgieron desafíos a alta concurrencia con errores de inicialización y latencias de inicio de cola larga. Resultó ser que eran límites de recursos en la cuenta en lugar de límites estrictos de la plataforma; Modal elevó los límites y el equipo verificó la estabilidad a alta concurrencia. Aún así, la experiencia destaca la necesidad de mejores herramientas de observabilidad de sandbox y documentación de escalado.
La honestidad brutal sobre los aspectos ásperos de las herramientas de código abierto contrasta con el marketing típico de los proveedores, pero sirve a la audiencia institucional que necesita comprender los desafíos de implementación del mundo real antes de comprometer capital en la infraestructura de entrenamiento de RL.