S4 Weights
Compression lossless GPU de checkpoints
Un codec de compression lossless GPU pour les checkpoints d’entraînement PyTorch (poids + état de l’optimiseur). Il découpe chaque tenseur en byte-planes et route le plan d’exposant via ANS et la mantisse via GDeflate (nvCOMP) sur le GPU, en restant bit-exact (lossless) pour bf16, fp16 et fp32. Les checkpoints compressés sont conservés dans votre propre bucket S3. Fourni comme AMI GPU g6 / g6e.
S4 Weights est un codec transparent et lossless pour les checkpoints écrits par une exécution d’entraînement — les poids du modèle et l’état de l’optimiseur. La restauration est identique byte-for-byte, vérifiée contre des motifs de bits adversariaux (NaN, ±Inf, denormal, -0.0) sur chaque dtype pris en charge. Pour les exécutions qui checkpointent fréquemment, il compresse aussi le delta byte-XOR entre checkpoints consécutifs. Le build de l’AMI échoue lui-même si un aller-retour compress→decompress n’est pas bit-exact sur le GPU de build, donc un réassemblage de plans cassé n’atteint jamais une image client. Vos checkpoints ne quittent jamais votre propre VPC ni votre bucket S3.
Le problème
Les grands entraînements PyTorch écrivent fréquemment des checkpoints — les poids du modèle et l'état de l'optimiseur —, de sorte que le stockage qu'ils occupent dans Amazon S3 et les octets transférés ne cessent d'augmenter. Des checkpoints plus volumineux signifient également des temps d'arrêt de sauvegarde/chargement plus longs qui interrompent l'entraînement à chaque fois, accumulant à la fois les coûts de stockage et le temps d'inactivité des GPU. Ces checkpoints sont les valeurs brutes en bf16/fp16/fp32, où toute perte ou quantification est inacceptable, la compression doit donc être sans perte pour être fiable.
Fonctionnement
- 1
Diviser en plans d'octets sur le GPU
Chaque tenseur est divisé sur le GPU en plans d'octets de signe, d'exposant et de mantisse, et chaque plan est dirigé vers le codec approprié — le plan d'exposant via le codage entropique ANS, la mantisse via GDeflate et le plan de signe par bit-packing (basé sur NVIDIA nvCOMP).
- 2
Compresser le delta entre les checkpoints
Pour les entraînements qui effectuent fréquemment des checkpoints, S4 Weights stocke et compresse également le delta XOR d'octets entre checkpoints consécutifs, qui est beaucoup plus petit lorsque la plupart des poids bougent à peine entre les sauvegardes.
- 3
Restauration identique au bit près, persistance dans votre propre S3
La restauration est toujours identique octet par octet, validée contre des configurations de bits adverses (NaN, +/-Inf, dénormal, -0.0) pour chaque dtype pris en charge. Les checkpoints compressés sont conservés dans le bucket S3 que vous configurez et ne quittent jamais votre compte.
Points forts
Lossless (byte-for-byte) pour bf16 / fp16 / fp32, vérifié contre des motifs adversariaux NaN / ±Inf / denormal / -0.0.
Découpage en byte-planes : exposant → ANS, mantisse → GDeflate sur le GPU (nvCOMP) ; compresse aussi la chaîne de deltas entre checkpoints.
Les checkpoints compressés arrivent dans votre propre bucket S3 à l’intérieur de votre propre VPC ; AMI GPU g6 / g6e.
Ce qui est inclus
- Codec de checkpoint sans perte sur GPU — compression identique au bit près des checkpoints d'entraînement PyTorch (poids du modèle et état de l'optimiseur) pour bf16/fp16/fp32
- Chemin de données par plans d'octets (plan d'exposant -> ANS, plan de mantisse -> GDeflate, plan de signe bit-packed, s'exécutant sur le GPU et basé sur NVIDIA nvCOMP)
- Chaîne de deltas XOR d'octets entre checkpoints consécutifs — économies supplémentaires sur les sauvegardes fréquentes, sans jamais étendre un blob au-delà d'un petit en-tête fixe
- API PyTorch drop-in — s4weights.save / s4weights.load transparents, plus un store de checkpoints base->delta (save_checkpoint / load_checkpoint)
- Vérification des configurations de bits adverses — NaN / +/-Inf / dénormal / -0.0 vérifiés sur chaque dtype pris en charge, et le build de l'AMI lui-même échoue à moins qu'un aller-retour compression->décompression sur GPU ne soit identique au bit près
- AMI GPU g6/g6e basée sur Ubuntu 22.04 avec un modèle CloudFormation de bout en bout (deploy/cfn-train-runner.yaml) ; le runner est un service systemd non root exposant un endpoint de santé sur TCP 8080
- Persistance sur votre propre bucket de registre S3 (vos données ne quittent jamais votre compte) plus une vérification des droits RegisterUsage en mode fail-closed au démarrage
Cas d'usage
Entraînements PyTorch de grande envergure qui effectuent fréquemment des checkpoints et souhaitent réduire les coûts de stockage S3 et les octets transférés
Charges de travail où l'état de l'optimiseur domine et où vous souhaitez réduire les blocages de sauvegarde/chargement
Pipelines d'entraînement qui ne tolèrent aucune perte ni quantification et nécessitent une restauration identique au bit près
Équipes dont les données se compressent bien, telles que les checkpoints all-bf16 ou d'optimiseurs à faible précision
FAQ
La compression est-elle vraiment sans perte ?
Oui. La restauration est toujours identique à l'octet près, vérifiée pour les poids bf16/fp16/fp32 et l'état de l'optimiseur fp32 par rapport à des configurations de bits hostiles (NaN, +/-Inf, dénormal, -0.0). Le build de l'AMI lui-même échoue à moins qu'un aller-retour compression->décompression sur GPU soit identique au bit près, de sorte qu'un codec avec un réassemblage de plans défectueux n'atteint jamais l'image d'un client.
Quel est le taux de compression ?
Cela dépend des données. Les checkpoints all-bf16 / d'optimiseurs à faible précision se compressent bien (et encore mieux à grande échelle), tandis que les checkpoints riches en fp32 sauvegardés à intervalles éloignés se compressent peu. Nous sommes honnêtes sur les cas où cela aide et ne revendiquons pas de taux fixe. La compression est toujours sans perte et ne dilate jamais un blob au-delà d'un petit en-tête fixe.
Où sont stockés mes checkpoints ?
Les checkpoints compressés persistent dans le bucket de registre Amazon S3 que vous configurez et ne quittent jamais votre compte. Vous lancez l'AMI dans votre propre VPC, et votre code d'entraînement PyTorch écrit des checkpoints avec s4weights.save / s4weights.load (ou save_checkpoint / load_checkpoint pour la chaîne delta), ce qui compresse chaque tenseur sur le GPU et conserve des checkpoints compressés identiques au bit près dans votre registre S3.
Sur quoi fonctionne-t-il et comment est-il facturé ?
Il fonctionne sur des instances GPU g6 ou g6e, configurées de bout en bout par le modèle CloudFormation fourni (deploy/cfn-train-runner.yaml). La facturation se fait par heure d'instance avec une option annuelle. AWS comptabilise automatiquement les heures d'instance actives, et le runner appelle RegisterUsage une fois au démarrage comme vérification des droits en mode fail-closed (une instance non autorisée refuse de démarrer).
Est-il facile de l'intégrer dans mon code d'entraînement PyTorch ?
L'intégration est immédiate (drop-in). Vous écrivez les checkpoints avec les fonctions transparentes s4weights.save / s4weights.load, ou utilisez save_checkpoint / load_checkpoint pour le stockage de checkpoints base->delta. Chaque tenseur est compressé sur le GPU, et pour les sauvegardes fréquentes, le delta byte-XOR entre checkpoints consécutifs est également stocké et compressé.
Modèle de tarification
Frais logiciels horaires + GPU EC2 (g6 / g6e). Facturation à l’usage par type d’instance, option annuelle disponible.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch