Destilación on-policy vs off-policy: manda la dirección del KL
Destilación on-policy vs off-policy: manda la dirección del KL, no el rollout
TL;DR
- Verificado verbatim contra el abstract y el HTML v1 (arXiv 2609.35259, publicado el 28/09/2026; Julianna Piskorz, Antonin Berthon y Mihaela van der Schaar, University of Cambridge): en una destilación strong-to-weak controlada, “rollout policy does not necessarily play a central role” (abstract, traducción nuestra). Lo que decide el rendimiento es la dirección del KL; lo que decide el olvido y la sparsity de los updates es el learning rate.
- El número que rompe el mantra: mejor media en las 3 tareas, 72% para on-policy (OnPD) y 73% para off-policy (OffPD). Con forward KL la accuracy se mueve entre 71% y 73% en todas las combinaciones de rollout y LR; con reverse KL, entre 35% y 72%.
- El olvido lo paga el LR, no el rollout: en 7 benchmarks OOD el rendimiento cambia 1.3 pp o menos a LR 1e-5, pero cae 11.2-14.0 pp a LR 5e-5. Y en el sweep, a LR emparejadas, OffPD olvida menos que OnPD y produce updates al menos tan sparse (85.3-89.6% a LR bajo vs 51.9-60.0% a LR alto). Los dos argumentos clásicos a favor de on-policy —menos olvido, updates más sparse— no aparecen aquí.
- Dónde SÍ gana on-policy: generalización a variantes más duras de Countdown (+10-15% pass@k con ambas direcciones de KL) y menos transferencia de estilo del teacher con reverse KL. Pero la ventaja inicial no persiste de fiable tras una fase RLVR posterior, y los checkpoints con mejor RLVR sostenido son off-policy.
- Regla práctica: decide primero la dirección del KL. Con forward KL el rollout apenas importa — usa off-policy, que es más barato. Con reverse KL el rollout importa — ahí puede pagar on-policy. Y mete siempre OffPD como baseline: es la recomendación literal de los autores.
El mantra on-policy y de dónde sale
La última temporada ha consolidado una idea cómoda: destilar on-policy —que el estudiante genere sus propios rollouts y el teacher supervise token a token— reduce el olvido catastrófico, produce updates más sparse y generaliza mejor. Es la línea que repite el abstract de este paper al resumir lo que “se ha argumentado” en la literatura.
El problema con esa evidencia es de diseño, no de mala fe: las comparaciones habituales enfrentan SFT contra RLVR cambiando a la vez el objetivo, el rollout, el algoritmo de update y los hiperparámetros. Cuando todo se mueve a la vez, atribuir el resultado al rollout policy es astrología con GPUs. Este paper hace lo que casi nadie hace: un pipeline fijo —destilación con KL token-level— donde se varían de forma independiente la dirección del KL, el rollout policy y el learning rate.
El experimento que aísla la variable
El setup (§4.1) es deliberadamente pequeño y controlado: teacher Llama-3.1-8B, student Llama-3.2-1B. Existe una réplica con Qwen2.5-7B → Qwen2.5-1.5B en el Apéndice A.5, pero el experimento principal es Llama; no vendas la paridad de familias que el paper no reclama. Tres tareas de razonamiento (MedReason, médico; SciKnowEval, científico; Countdown-3, aritmético), 150 steps full-parameter, 3 semillas por configuración, dos learning rates (1e-5 y 5e-5), KL token-level sobre vocabulario completo y clipping de gradiente 1.0.
Las dos condiciones:
- OnPD (on-policy distillation): el estudiante genera sus rollouts y el teacher pone la supervisión por token sobre esas secuencias.
- OffPD (off-policy): los rollouts salen del teacher y el estudiante los imita — la destilación clásica estilo SFT.
La clave metodológica es romper el emparejamiento convencional. En la literatura, forward KL suele ir con rollouts off-policy y reverse KL con on-policy, así que ninguna comparación podía separar qué aportaba cada pieza. Aquí se cruzan las cuatro combinaciones, y encima se barre un espectro continuo de rollouts (§5.2) que mezcla secuencias del teacher y del estudiante.
Resultados: accuracy, olvido y sparsity
| Dimensión | Resultado (verificado en el HTML v1) | Qué la gobierna |
|---|---|---|
| Mejor media in-distribution (3 tareas) | OnPD 72% vs OffPD 73% | Ni rollout ni nada: empatados |
| Accuracy por configuración | Forward KL: 71-73% en todas las combinaciones · Reverse KL: 35% a 72% | Dirección del KL |
| Olvido OOD (7 benchmarks) | ≤1.3 pp a LR 1e-5 · 11.2-14.0 pp a LR 5e-5 | Learning rate |
| Sparsity de updates | 85.3-89.6% a LR bajo · 51.9-60.0% a LR alto | Learning rate (OffPD al menos tan sparse en cada comparación emparejada) |
Tres lecturas. Primera: la diferencia entre generar rollouts propios o imitar al teacher es ruido frente a la diferencia entre direcciones del KL. Forward KL da lo mismo con cualquier rollout; reverse KL es una lotería con el LR. Segunda: los dos beneficios que se atribuyen a on-policy —olvido y sparsity— en este experimento los decide el LR, y en las comparaciones emparejadas OffPD sale igual o mejor. Tercera, y es la parte accionable: con forward KL y LR bajo consigues la mejor accuracy sin el olvido, lo que los autores vinculan al fenómeno “cliff” de la literatura reciente.
| Claim | Qué hay detrás (consultado 03/10/2026) | Naturaleza |
|---|---|---|
| El rollout policy no es el factor central | Abstract verbatim + §4.2 (72% vs 73%) | Verificado en el paper |
| La dirección del KL manda el rendimiento | §4.2: forward 71-73% en todas las configs; reverse 35-72% | Verificado; experimento de los autores |
| OnPD olvida menos y produce updates más sparse | Falso aquí: OffPD olvida menos a LR emparejadas y es al menos tan sparse en cada comparación | Corregido; refuta los claims previos que el paper cita |
| OnPD generaliza mejor a variantes duras | §5.3: +10-15% pass@k en Countdown-4E, con ambas direcciones | Verificado |
| Esa ventaja persiste tras RLVR | Falso: “does not reliably persist” (abstract); mejores arranques OffPD (§5.3, Fig. 6) | Corregido; matiz clave |
| OnPD+reverse KL evita copiar el estilo del teacher | §5.3 + Ap. D.7 (teacher en español, estudiante conserva inglés) | Verificado; hallazgo del paper |
| Código disponible | No hay repo público enlazado; los github.com del HTML son referencias | Corregido: no prometer código |
| Llama y Qwen por igual | Principal: Llama-3.1-8B → Llama-3.2-1B; Qwen2.5 es réplica de apéndice | Matiz obligatorio |
Por qué: la asimetría de gradientes
El §5.1 da el mecanismo, y es la parte que sobrevive aunque desconfíes de los benchmarks. El gradiente del forward KL respecto a los logits del estudiante es (π_S − π_T): acotado en [−1,1]. Si el rollout cambia un poco, el gradiente cambia proporcionalmente — el Apéndice C formaliza este rollout-stability bound. El reverse KL, en cambio, pondera el gradiente por π_S·(log-ratio − D_RKL): sin acotación. El mismo apéndice demuestra que no existe bound libre de distribución para reverse KL; su estabilidad depende de controlar los likelihood ratios, que es exactamente lo que un rollout on-policy hace más fácil.
El barrido del espectro (§5.2) lo confirma empíricamente: forward KL mantiene la accuracy por encima del 80% en todo el rango —del rollout puro del teacher al puro del estudiante—, con una variación de 5.2 pp a LR bajo en Countdown-3. Reverse KL varía mucho con λ y entre semillas, y a LR alto es inestable y colapsa ocasionalmente. El detalle que remata la historia: OnPD con forward KL aprende incluso atravesando rollouts incoherentes de alta entropía (Ap. A.10). Con la dirección acotada del gradiente, da igual lo podrido que sea el rollout.
Dónde SÍ gana on-policy
Este paper no es un esperanto anti-on-policy, y conviene leerlo hasta el §5.3 antes de citarlo en una discusión de pasillo. Tres sitios donde el rollout on-policy aporta algo medible:
- Generalización a variantes más duras. En Countdown-4E —una variante más difícil que la de entrenamiento— on-policy da +10-15% pass@k con ambas direcciones de KL. Es el primer beneficio claro y consistente del rollout propio en todo el paper.
- Transferencia de estilo incidental (Ap. D.7). Con un teacher instruido en español, OnPD con reverse KL es la única configuración que preserva el inglés del estudiante; todas las demás transfieren el español casi por completo. Si tu teacher tiene tics de estilo que no quieres destilar, esto es un hallazgo práctico.
- Rollouts largos (matiz “suggestive”). En Numina-MATH, con respuestas de 622 tokens de media frente a los 94-135 de las tareas principales, OnPD con reverse KL logra la mejor MATH-500 a LR bajo. Pero es 1 run por condición y los propios autores lo llaman “suggestive”. Peso apropiado: una pista, no un resultado.
También en pass@10 con pass@1 comparable gana forward KL sobre reverse KL — pero ahí el que manda vuelve a ser la dirección del KL, no el rollout.
El matiz RLVR: la ventaja que se esfuma
La parte que más debería interesar a quien corre el pipeline por defecto destilar y luego RLVR. Tras 300 steps de RLVR sobre Countdown-4, la ventaja inicial de los checkpoints on-policy no persiste de fiable — “this advantage does not reliably persist after subsequent RLVR”, verbatim del abstract. Los checkpoints con mejor RLVR sostenido son OffPD (forward KL a 1e-5 o reverse KL a 5e-5), curiosamente partiendo de accuracy cercana a 0% en la tarea. Los autores lo señalan consistente con Zhang et al. 2026a: los mejores checkpoints iniciales no son los mejores puntos de partida para RLVR.
Traducción: si tu plan es destilar para arrancar un RL posterior, optimizar la accuracy post-destilación puede estar optimizando la variable equivocada. El mejor estudiante destilado no es necesariamente el mejor candidato a ser entrenado con RL. Es un resultado de un solo setup, sí — pero cruje donde duele.
Qué significa para costes y decisiones
La destilación on-policy no es gratis: exige generar con el estudiante durante el entrenamiento, en cada step, además del pase de training. La off-policy reutiliza generaciones del teacher — más baratas, cacheables y reutilizables. Si con forward KL las dos dan lo mismo (71-73%, recordatorio), el sobrecoste de generar on-policy no paga nada por defecto.
La regla que deja el paper:
- Forward KL: el rollout apenas importa. Usa off-policy y ahorra la generación. La robustez es del gradiente, no de tus rollouts.
- Reverse KL: el rollout importa, y el LR es una mina (35% de accuracy a LR alto). Si vas a usar reverse KL, el on-policy es donde brilla — y es también la única config que evita la transferencia de estilo del teacher.
- Cualquier eval de destilación que montes o leas: exige la baseline OffPD. Es la recomendación literal de los autores (“we encourage future work on on-policy distillation to include OffPD as a standard baseline”) y cuesta poco añadirla.
- Pipeline distill → RLVR: no asumas que el mejor checkpoint destilado es el mejor arranque de RLVR. El paper sugiere que puede ser al revés.
El coste de la generación durante entrenamiento no es un detalle: es la misma aritmética de tokens que cualquier decisión de inferencia en producción. Para el marco general de costes por token y routing entre proveedores, vale la guía de costes LLM: tokens y routing entre proveedores; para recortar la factura de inferencia, cómo reducir el coste de tokens un 30%.
Qué NO sabemos
- Escala. Estudiantes de 1B-1.5B y trazas de hasta 2,000 tokens, con teacher fijo por tarea y gap de capacidad forzado. Que la asimetría de gradientes se traduzca a estudiantes de 30B o trazas de 50k tokens es una hipótesis razonable — y sin demostrar.
- Sin réplica externa ni código. El v1 (preprint, sin peer review) tiene 5 días de vida (al 03/10/2026), no enlaza repo público —el reproducibility statement remite a los apéndices, no a código— y todo lo anterior es lo que reportan los autores sobre sus propios entrenamientos.
- La parte larga es una pista. Numina-MATH con 1 run por condición: los autores mismos lo marcan “suggestive”.
- Financiación declarada. Studentship de Piskorz por AstraZeneca, de Berthon por Eedi, y créditos Azure de Microsoft AI for Good Research Lab. Declarado en Acknowledgments; no invalida nada, pero está bien saber quién paga.
Qué haría yo
Si tienes una destilación en el horizonte: decide primero la dirección del KL, porque es la variable que de verdad mueve la accuracy. Con forward KL y LR bajo tienes el perfil más robusto del paper — buena accuracy y olvido mínimo — con rollouts off-policy baratos. No pagues generación on-policy por defecto; págala si tu objetivo es generalizar a variantes más duras que la de entrenamiento (+10-15% pass@k aquí), o si usas reverse KL y necesitas contener la sensibilidad al LR.
Y si tu pipeline continúa con RLVR, no selecciones el checkpoint de arranque por accuracy post-destilación: aquí los mejores arranques sostenidos de RLVR parten de accuracy cercana a cero. Antes de comprometer presupuesto de RL, probaría dos o tres candidatos de destilación baratos en 100-300 steps de RL y me quedaría con el que mejor aguanta, no con el que mejor puntúa al salir de la destilación.
Es el mismo reflejo escéptico que aplicamos en MiMo-V2.6-Pro-RL con el RL post-training en producción: el resultado de una fase de entrenamiento solo importa por lo que sobrevive a la siguiente. Y es el contraste exacto de UniEvo-VL, donde la auto-mejora on-policy sí era la receta: misma herramienta, distinto problema — aquí el dato duro es que el rollout propio no manda.
Fuentes
- Primarias: arXiv 2609.35259 — abstract · HTML v1 completo (abstract, §4-§7, Apéndices A, C y D) · API export.arxiv.org — consultados el 03/10/2026.
- Recepción: página del paper en Hugging Face (153 upvotes vía API, consultada el 03/10/2026).
- Contexto interno: UniEvo-VL: auto-mejora multimodal on-policy · MiMo-V2.6-Pro-RL: RL post-training de Xiaomi · reducir costes de tokens un 30% · guía de costes LLM: tokens y routing.