He estado hablando con muchas personas que trabajan en RL últimamente, y he notado algo interesante: cada vez que la conversación gira en torno a RL Infra, casi siempre se centra en un tema: la alineación entre entrenamiento e inferencia. Cómo mantener consistentes las políticas de entrenamiento e inferencia. Cómo controlar el grado de off-policy. Cómo manejar la diferencia de probabilidad de log después de introducir async. Todas estas son preguntas importantes, sin duda. Pero estoy cada vez más convencido de que RL Infra está sufriendo de una significativa mala asignación de atención. Tomando prestada una forma de enmarcarlo de una discusión reciente con un colega, llamo a esto el Efecto Barril de RL Infra. Un barril solo contiene tanta agua como su duela más corta. El rendimiento y la corrección de un sistema de entrenamiento de RL funcionan de la misma manera: no están determinados por el módulo que has optimizado más, sino por el que has descuidado más. La alineación entre entrenamiento e inferencia podría ser la duela que has lijado y pulido a la perfección. Pero si la estabilidad de tu sandbox es un desastre, tu canal de recompensas se detiene constantemente, y tu observabilidad de extremo a extremo es prácticamente inexistente, ¿de qué sirve una alineación perfecta? La capacidad del sistema ya está limitada por cada otro eslabón débil. Esto es fundamentalmente diferente de cómo funciona la optimización del sistema de inferencia. Como motor de inferencia, SGLang tiene un enorme espacio de estrategia para la optimización, pero su canal es relativamente lineal: procesar la solicitud, prellenar, decodificar. Puedes aislar cuellos de botella módulo por módulo, y el acoplamiento entre componentes es manejable. El entrenamiento de RL es una bestia completamente diferente: un bucle de múltiples sistemas increíblemente complejo: la generación de rollouts depende del motor de inferencia, el cálculo de recompensas puede depender de entornos externos, las actualizaciones de políticas dependen del marco de entrenamiento, y la siguiente ronda de rollouts depende de la política actualizada. Si cualquier eslabón único se rompe, todo el bucle colapsa. Desafortunadamente, por lo que he visto en el último año, todavía hay muchos puntos débiles subestimados: Confiabilidad del Sandbox del Agente. Este es probablemente el trabajo más sucio, agotador y menos glamuroso académicamente en RL Infra hoy en día. El RL basado en agentes necesita un sandbox de ejecución confiable para los rollouts: suena simple, resulta ser una pesadilla. Estabilidad de contenedores, latencia de inicio en frío, confiabilidad de aislamiento de recursos, gestión del estado del sandbox: estas cosas parecen desacopladas en papel, pero los productos de sandbox disponibles en el mercado consistentemente no cumplen con las expectativas. El sandboxing de agentes no es un problema de algoritmo, pero determina directamente tu eficiencia de generación de datos, que a su vez determina tu velocidad de entrenamiento. Observabilidad. Depurar el preentrenamiento es relativamente sencillo: observa la curva de pérdida, verifica la norma del gradiente, y generalmente puedes identificar el problema. Pero depurar RL requiere capacidades de trazado de extremo a extremo: distribuciones de calidad de rollout, estadísticas de recompensas, grado de off-policy, magnitudes de actualización de políticas, e incluso atribución de la diferencia de logprob (¿la diferencia proviene del lado de inferencia, o del retraso de versión del entrenamiento asíncrono?). Desafortunadamente, la mayoría de los equipos que he encontrado están esencialmente volando a ciegas en estas dimensiones. Esto lleva a una situación incómoda: cuando los resultados del entrenamiento son pobres, ni siquiera sabes qué módulo culpar. El Dilema de la Escala. Muchas optimizaciones de RL Infra solo muestran un impacto medible a escala suficiente. Los experimentos a pequeña escala a menudo no revelan ninguna diferencia significativa, no porque la optimización sea inútil, sino porque el ruido es demasiado alto y el conteo de pasos demasiado bajo para que la señal emerja. Sin embargo, los experimentos a gran escala son prohibitivamente costosos. Esto crea un ciclo vicioso: no puedes probar que tu optimización funciona a pequeña escala, por lo que no puedes asegurar los recursos para experimentos a gran escala; y sin validación a gran escala, tu optimización queda atrapada para siempre en "teóricamente debería ayudar." La inversión de la industria en RL Infra está severamente desajustada con su complejidad real. La mayoría de los equipos lo tratan como un trabajo de parche sobre la infraestructura de preentrenamiento: agarra un marco de entrenamiento listo para usar, añade un motor de inferencia, pégalos juntos con scripts, y llámalo RL Infra. Pero la complejidad del sistema de entrenamiento de RL y el preentrenamiento ni siquiera están en la misma liga. Los canales de preentrenamiento son lineales, homogéneos y tienen prácticamente cero dependencias externas. Los canales de entrenamiento de RL son cíclicos, heterogéneos y dependen en gran medida de entornos externos. Aplicar la mentalidad arquitectónica del primero al segundo está garantizado que chocará contra una pared a escala. La verdadera dificultad en la ingeniería de sistemas no se trata de llevar ningún módulo único a su extremo: se trata de entender el acoplamiento entre módulos y el espacio de compensación global. Esto es cierto para los sistemas de inferencia, y aún más para RL Infra, donde las dimensiones de acoplamiento son mayores, los bucles de retroalimentación son más largos, y la densidad de información para depuración es mucho más baja. Quiero cerrar con dos preguntas que he estado reflexionando, y me encantaría escuchar a otros que trabajen en este espacio: ¿Dónde exactamente comienzan a disminuir los rendimientos marginales de la alineación entre entrenamiento e inferencia? Una vez que se introduce async, el grado de off-policy ya es sustancial. Sobre esa base, ¿es la ganancia incremental de una mayor alineación realmente de mayor ROI que invertir el mismo esfuerzo de ingeniería en la estabilidad del sandbox, la optimización del canal de recompensas, o la infraestructura de observabilidad? Tengo mi propia respuesta tentativa, pero creo que esta pregunta merece un serio análisis por parte de más personas, en lugar de recurrir a la alineación como la máxima prioridad simplemente porque es el tema más visible. Y hay una razón por la que es el más visible: la alineación entre entrenamiento e inferencia tiene una formalización matemática limpia y produce ablaciones elegantes: es un ajuste natural para los artículos. Pero, ¿cómo escribes un artículo sobre la estabilidad del sandbox? ¿Cómo enmarcas la confiabilidad de la orquestación de contenedores como una historia académica? Realmente no puedes. Así que estos problemas son ignorados colectivamente. Incluso si un sistema de RL Infra logra una alineación entre entrenamiento e inferencia a nivel de bits, la eficiencia general aún puede ser desastrosa, porque el cuello de botella se movió a otro lugar hace mucho tiempo. ¿Hasta qué punto puede estandarizarse RL Infra? Los sistemas de inferencia tienen métricas de referencia relativamente bien definidas: TTFT, TBT, Throughput. Estos indicadores objetivos nos permiten evaluar claramente el impacto de las optimizaciones. Pero, ¿cuáles son los estándares de evaluación para RL Infra? ¿Rendimiento de entrenamiento? ¿Eficiencia de muestra? ¿Tiempo total de reloj de extremo a extremo? La arquitectura óptima puede variar drásticamente entre escenarios (generación de código vs. agente vs. razonamiento). Si ni siquiera tenemos consenso sobre cómo se ve "buena RL Infra", entonces el conocimiento de ingeniería en este campo será extremadamente difícil de acumular y reutilizar. Si RL es el camino crítico para mejorar las capacidades del modelo, ese juicio aún está evolucionando. Pero si la respuesta es sí, entonces Infra es el cuello de botella más subestimado en ese camino. No porque nadie esté trabajando en ello, sino porque la atención colectiva está mal asignada. La crueldad del Efecto Barril es esta: no importa cuán alta sea tu duela más alta, no puede salvar el sistema.