Todos los productos de AWS Marketplace
S4 Weights
IA y GPU

S4 Weights

Compresión lossless de checkpoints en GPU

Compresión sin pérdidas exacta a nivel de bit Servicio de AWS que reemplaza: Almacenamiento de checkpoints de PyTorch en S3
Obtener en AWS Marketplace

Un codec de compresión lossless en GPU para checkpoints de entrenamiento de PyTorch (pesos + estado del optimizador). Divide cada tensor en planos de bytes y enruta el plano de exponente por ANS y la mantisa por GDeflate (nvCOMP) en la GPU, manteniéndose bit-exact (lossless) para bf16, fp16 y fp32. Los checkpoints comprimidos se persisten en su propio bucket S3. Entregado como GPU AMI g6 / g6e.

S4 Weights es un codec transparente y lossless para los checkpoints que escribe una ejecución de entrenamiento: los pesos del modelo y el estado del optimizador. La restauración es idéntica byte-for-byte, verificada frente a patrones de bits adversarios (NaN, ±Inf, denormal, -0.0) en cada dtype compatible. Para ejecuciones que hacen checkpoints con frecuencia, también comprime el delta byte-XOR entre checkpoints consecutivos. La propia compilación de la AMI falla si un round-trip compress→decompress no es bit-exact en la GPU de build, por lo que una reconstrucción de planos rota nunca llega a una imagen de cliente. Sus checkpoints nunca salen de su propia VPC ni de su bucket S3.

El problema

Las ejecuciones de entrenamiento a gran escala en PyTorch escriben checkpoints — los pesos del modelo y el estado del optimizador — con frecuencia, por lo que el espacio de almacenamiento que ocupan en Amazon S3 y los bytes que transfiere no dejan de crecer. Los checkpoints más grandes también implican mayores paradas al guardar/cargar que pausan el entrenamiento cada vez, acumulando tanto costes de almacenamiento como tiempo de inactividad de la GPU. Estos checkpoints son los números crudos en bf16/fp16/fp32, donde cualquier pérdida o cuantización es inaceptable, por lo que la compresión debe ser sin pérdidas (lossless) para ser fiable.

Cómo funciona

  1. 1

    Dividir en planos de bytes en la GPU

    Cada tensor se divide en la GPU en planos de bytes de signo, exponente y mantisa, y cada plano se redirige al códec más adecuado — el plano del exponente mediante codificación de entropía ANS, la mantisa a través de GDeflate y el plano de signo mediante empaquetado de bits (basado en NVIDIA nvCOMP).

  2. 2

    Comprimir el delta entre checkpoints

    Para las ejecuciones que realizan checkpoints con frecuencia, S4 Weights also almacena y comprime el delta byte-XOR entre checkpoints consecutivos, el cual es mucho más pequeño cuando la mayoría de los pesos apenas cambian entre guardados.

  3. 3

    Restauración exacta a nivel de bits, con persistencia en su propio S3

    La restauración es siempre idéntica byte a byte, verificada contra patrones de bits adversarios (NaN, +/-Inf, denormal, -0.0) en cada dtype compatible. Los checkpoints comprimidos persisten en el bucket de S3 que configure y nunca salen de su cuenta.

Características destacadas

Lossless (byte-for-byte) para bf16 / fp16 / fp32, verificado frente a patrones adversarios NaN / ±Inf / denormal / -0.0.

División en planos de bytes: exponente → ANS, mantisa → GDeflate en la GPU (nvCOMP); también comprime la cadena delta entre checkpoints.

Los checkpoints comprimidos llegan a su propio bucket S3 dentro de su propia VPC; GPU AMI g6 / g6e.

Qué incluye

  • Códec de checkpoint sin pérdidas (lossless) para GPU — compresión exacta a nivel de bits de checkpoints de entrenamiento de PyTorch (pesos del modelo y estado del optimizador) para bf16/fp16/fp32
  • Ruta de datos de planos de bytes (plano de exponente -> ANS, plano de mantisa -> GDeflate, plano de signo empaquetado por bits, ejecutándose en la GPU y basado en NVIDIA nvCOMP)
  • Cadena delta byte-XOR entre checkpoints consecutivos — ahorro adicional en guardados frecuentes y nunca expande un blob más allá de una pequeña cabecera fija
  • API de PyTorch drop-in — s4weights.save / s4weights.load transparentes más un almacén de checkpoints de base->delta (save_checkpoint / load_checkpoint)
  • Verificación de patrones de bits adversarios — NaN / +/-Inf / denormal / -0.0 comprobados en cada dtype compatible, y la propia compilación de la AMI falla a menos que un ciclo de compresión->descompresión en la GPU sea exacto a nivel de bits
  • AMI de GPU g6/g6e basada en Ubuntu 22.04 con una plantilla de CloudFormation de extremo a extremo (deploy/cfn-train-runner.yaml); el runner es un servicio systemd que no se ejecuta como root y sirve un endpoint de salud en TCP 8080
  • Persistencia en su propio bucket de registro de S3 (sus datos nunca salen de su cuenta) más una verificación de derechos RegisterUsage de tipo fail-closed en el arranque

Casos de uso

Ejecuciones de entrenamiento de PyTorch a gran escala que crean checkpoints con frecuencia y quieren reducir el coste de almacenamiento en S3 y los bytes transferidos

Cargas de trabajo donde el estado del optimizador domina y se desean pausas de guardado/carga más cortas

Pipelines de entrenamiento que no toleran ninguna pérdida ni cuantización y necesitan una restauración exacta a nivel de bit garantizada

Equipos cuyos datos se comprimen bien, como los checkpoints de tipo all-bf16 o de optimizadores de baja precisión

Preguntas frecuentes

¿Es la compresión realmente sin pérdidas?

Sí. La restauración es siempre idéntica byte a byte, verificada para pesos de bf16/fp16/fp32 y el estado del optimizador fp32 frente a patrones de bits adversarios (NaN, +/-Inf, desnormalizados, -0.0). La propia construcción de la AMI falla a menos que un ciclo de compresión->descompresión en GPU sea exacto a nivel de bit, por lo que un códec con un reensamblado de planos defectuoso nunca llega a la imagen del cliente.

¿Cuánto se comprimirá?

Depende de los datos. Los checkpoints de tipo all-bf16 / optimizador de baja precisión se comprimen bien (y mejor a escala), mientras que los checkpoints con predominancia de fp32 guardados de forma muy espaciada se comprimen poco. Somos honestos sobre dónde es útil y no afirmamos una tasa de compresión fija. La compresión es siempre sin pérdidas y nunca expande un blob más allá de una pequeña cabecera fija.

¿Dónde se almacenan mis checkpoints?

Los checkpoints comprimidos se guardan en el bucket de registro de Amazon S3 que configure y nunca salen de su cuenta. Usted inicia la AMI dentro de su propia VPC, y su código de entrenamiento de PyTorch escribe los checkpoints con s4weights.save / s4weights.load (o la cadena de deltas save_checkpoint / load_checkpoint), que comprime cada tensor en la GPU y almacena checkpoints comprimidos exactos a nivel de bits en su registro de S3.

¿En qué se ejecuta y cómo se factura?

Se ejecuta en instancias de GPU g6 o g6e, configuradas de extremo a extremo mediante la plantilla de CloudFormation incluida (deploy/cfn-train-runner.yaml). La facturación es por hora de instancia con una opción anual. AWS mide las horas de instancia en funcionamiento de forma automática, y el runner llama a RegisterUsage una vez en el arranque como verificación de derechos de tipo fail-closed (una instancia sin autorización se niega a arrancar).

¿Es fácil de integrar en mi código de entrenamiento de PyTorch?

Es de integración directa. Escribe los checkpoints con los transparentes s4weights.save / s4weights.load, o usa save_checkpoint / load_checkpoint para el almacenamiento de checkpoints base->delta. Cada tensor se comprime en la GPU y, para guardados frecuentes, también se almacena y comprime la diferencia XOR de bytes entre checkpoints consecutivos.

Modelo de precios

Tarifa horaria de software + GPU EC2 (g6 / g6e). Medido por tipo de instancia, opción anual disponible.

Obtener en AWS Marketplace