El 27 de mayo de 2026 se integró en TRL una implementación de sincronización de pesos basada en deltas: en lugar de enviar el modelo entero a cada paso, el sistema empaqueta únicamente los elementos de peso que han cambiado en un archivo safetensors sparse y lo sube a un Hub bucket, desde donde el motor de inferencia lo recupera de forma asíncrona. La mecánica de la ruta consiste en calcular el delta de pesos, serializarlo como safetensors sparse, subir ese paquete a un bucket del Hub y notificar que los pesos están disponibles; el motor de inferencia (vLLM) descarga las actualizaciones a su propio ritmo. En la prueba reportada con Qwen3-0.6B el tamaño del payload por paso cayó de 1.2 GB a valores entre 20 y 35 MB.
Para validar el enfoque se ejecutó un entrenamiento completamente desagregado: el entrenador quedó en una máquina, vLLM en una Space separada, el entorno Wordle en otra Space y todos los pesos fluyeron a través de un único Hub bucket. Es importante subrayar que esa configuración funcionó sin un clúster compartido, sin RDMA y sin VPN, lo que demuestra que la ruta puede operar sobre infraestructura distribuida y pública. El cambio responde a un problema conocido en RL asíncrono: cada paso suele implicar enviar el modelo completo al motor de inferencia. En formato bf16, un modelo de 7B ocupa alrededor de 14 GB, y un checkpoint de frontera de ~1T puede situarse del orden de 1 TB por snapshot, cifras que elevan costes y obligan a arquitecturas de red complejas para mantener el rendimiento.
Trabajos previos proporcionan números que respaldan la idea de transmitir solo diferencias. Un post de Fireworks medido en fp8 encontró que un snapshot completo de frontera era de 1.024 GiB y que el delta medio entre checkpoints fue de 20.3 GiB (1.98%). Además, se observó que más del 98% de los pesos en bf16 permanecen bit‑equivalentes entre pasos adyacentes, lo que sugiere que la mayor parte de la representación no cambia paso a paso.
La explicación técnica se basa en las propiedades de bf16: con solo 7 bits de mantisa, la separación entre valores representables alrededor de un peso |w| es del orden de |w|·2⁻⁷, de modo que una actualización menor que la mitad de ese espaciado queda absorbida al castear a bf16 y no altera los bytes almacenados. El trabajo PULSE (Mihai & Belilovsky, 2026) formaliza este comportamiento con dos umbrales — el bound de absorción, más conservador, y un bound efectivo— y define la visibilidad en bf16 como |w|/256. Con tasas de aprendizaje típicas en RL (por ejemplo η = 3×10⁻⁶) el bound de absorción cae por debajo de esa visibilidad para casi todos los pesos, lo que explica la alta esparcidad del delta por paso.
Las mediciones empíricas cubrieron varios modelos: variantes de Qwen2.5 (0.5B, 1.5B y 7B), Llama‑3.2 (3B) y Gemma (3 — 4B). En esos experimentos la esparcidad media por paso se situó alrededor del 99% con desviaciones estándar de 0.2–0.4% en ventanas de 400 pasos; incluso en el peor caso los pesos no cambiados superaron el 98%. Esas cifras son coherentes con la hipótesis de que la mayoría de las coordenadas no varían a nivel de representación bf16 entre pasos contiguos.
Las implicaciones prácticas son notables: transmitir solo los diffs reduce la factura de ancho de banda en muchos escenarios hasta en dos órdenes de magnitud, acorta el tiempo de inactividad de GPU a segundos y permite un flujo de trabajo en el que el entrenador publica pesos listos mientras el motor de inferencia los descarga según su propio ritmo. La ruta usa safetensors sparse y un bucket como un 'cable' compartido, lo que ofrece una alternativa al enfoque tradicional de clústeres co‑localizados, enlaces dedicados o RDMA para mantener baja latencia y alto rendimiento.
El equipo advierte limitaciones y delimitaciones: la efectividad descrita depende del formato bf16 y de las tasas de aprendizaje habituales en RL; mediciones en otros formatos numéricos, como fp8, o con hiperparámetros distintos podrían producir deltas de tamaño distinto. El cambio presentado pretende ser una solución práctica y pip‑installable que lleve al ecosistema de TRL los enfoques de diff‑chain ya reportados por otros trabajos, facilitando su reproducción en entornos disgregados.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
