S4 Weights
Lossless GPU checkpoint compression
面向 PyTorch training checkpoints（weights + optimizer state）的 GPU lossless compression codec。它对每个 tensor 做 byte-plane split，并在 GPU 上将 exponent plane 交给 ANS、mantissa 交给 GDeflate（nvCOMP），对 bf16、fp16 和 fp32 保持 bit-exact（lossless）。压缩后的 checkpoints 保存到你自己的 S3 bucket。以 g6 / g6e GPU AMI 交付。
S4 Weights 是一个透明、lossless codec，用于压缩 training run 写出的 checkpoints — model weights 和 optimizer state。恢复结果 byte-for-byte identical，并已针对每种受支持 dtype 上的对抗性 bit pattern（NaN、±Inf、denormal、-0.0）验证。对于频繁 checkpoint 的 run，它还会压缩连续 checkpoints 之间的 byte-XOR delta。AMI build 本身会在 build GPU 上执行 compress→decompress round-trip；若不是 bit-exact 则 build 失败，因此损坏的 plane reassembly 不会进入客户 image。你的 checkpoints 永远不会离开你自己的 VPC 和 S3 bucket。
面临挑战
大规模 PyTorch 训练会频繁写入检查点 — 即模型权重和优化器状态 — 因此它们在 Amazon S3 中占用的存储空间和传输的字节数会持续增加。更大的检查点还意味着每次保存/加载时暂停训练的停顿时间更长，从而增加了存储成本和 GPU 空闲时间。这些检查点是原始的 bf16/fp16/fp32 数值，不允许出现任何丢失或量子化，因此压缩必须是无损的才能被信赖使用。
工作原理
- 1
在 GPU 上拆分为字节平面
每个张量在 GPU 上拆分为符号、指数和尾数字节平面，每个平面均被分配给最适合的编解码器 — 指数平面进行 ANS 熵编码，尾数平面使用 GDeflate，符号平面执行比特打包（基于 NVIDIA nvCOMP 构建）。
- 2
压缩检查点之间的差分
对于频繁保存检查点的训练运行，S4 Weights 还会存储并压缩连续检查点之间的字节级 XOR 差分，当大多数权重在两次保存之间几乎没有移动时，该差分会比原始检查点小得多。
- 3
比特级完全还原，并保存到您自己的 S3
还原在字节级始终完全一致，已针对所有支持的 dtype 对对抗性比特模式（NaN、+/-Inf、非规格化数、-0.0）进行了验证。压缩后的检查点将持久化保存到您配置的 S3 存储桶中，且绝不会离开您的账户。
产品亮点
bf16 / fp16 / fp32 的 lossless（byte-for-byte），已针对对抗性 NaN / ±Inf / denormal / -0.0 验证。
byte-plane 拆分：exponent → ANS，mantissa → GPU（nvCOMP）上的 GDeflate；同时压缩 checkpoint 之间的 delta chain。
压缩后的 checkpoints 落在你自己 VPC 内的你自己的 S3 bucket；g6 / g6e GPU AMI。
包含内容
- GPU 无损检查点编解码器 — 实现 PyTorch 训练检查点（模型权重和优化器状态）的 bf16/fp16/fp32 比特级完全一致压缩
- 字节平面数据路径（指数平面 -> ANS，尾数平面 -> GDeflate，符号平面比特打包，在 GPU 上运行并基于 NVIDIA nvCOMP 构建）
- 连续检查点之间的字节级 XOR 差分链 — 在频繁保存时进一步节省空间，且绝不会使 blob 的膨胀超出微小的固定报头
- PyTorch 即插即用 API — 透明的 s4weights.save / s4weights.load，以及 base->delta 检查点存储（save_checkpoint / load_checkpoint）
- 对抗性比特模式验证 — 在所有支持 of dtype 上校验 NaN / +/-Inf / 非规格化数 / -0.0，且除非在构建用 GPU 上的压缩->解压往返过程比特完全一致，否则 AMI 构建本身会直接失败
- 基于 Ubuntu 22.04 的 g6/g6e GPU AMI，附带端到端 CloudFormation 模板（deploy/cfn-train-runner.yaml）；runner 是一个非 root 的 systemd 服务，在 TCP 8080 上提供健康检查端点
- 持久化到您自己的 S3 注册表存储桶（您的数据绝不会离开您的账户），加上启动时故障闭合的 RegisterUsage 授权检查
适用场景
频繁保存检查点且希望降低 S3 存储成本和传输字节数的大规模 PyTorch 训练任务
优化器状态占主导地位且希望缩短保存/加载停顿的工作负载
无法容忍任何损失或量化且需要保证比特级精确恢复的训练流水线
处理易于压缩的数据（例如全 bf16 或低精度优化器检查点）的团队
常见问题
压缩真的是无损的吗？
是的。恢复的数据始终逐字节完全一致，并针对 bf16/fp16/fp32 权重和 fp32 优化器状态的对抗性比特模式（NaN、+/-Inf、非正规数、-0.0）进行验证。AMI 构建本身在 GPU 压缩->解压的往返过程非比特精确时会直接失败，因此平面重构损坏的编解码器绝不会进入客户镜像中。
能压缩多少？
这取决于数据。全 bf16 / 低精度优化器检查点压缩效果很好（且规模越大效果越好），而保存间隔较长、以 fp32 为主的检查点则几乎无法压缩。我们对于其能发挥作用的场景保持坦诚，不宣称有固定的压缩率。压缩始终是无损的，且绝不会使 blob 的膨胀超出微小固定文件头的大小。
我的检查点保存在哪里？
压缩后的检查点将持久化保存到您配置的 Amazon S3 注册表存储桶中，并且绝不会离开您的账户。您在自己的 VPC 内启动 AMI，您的 PyTorch 训练代码使用 s4weights.save / s4weights.load（或增量链 save_checkpoint / load_checkpoint）写入检查点，该操作在 GPU 上压缩每个张量，并将比特级精确的压缩检查点持久化保存到您的 S3 注册表中。
它运行在什么实例上，如何计费？
It runs on g6 or g6e GPU instances, wired end-to-end by the bundled CloudFormation template (deploy/cfn-train-runner.yaml). Billing is per-instance-hour with an annual option. AWS meters the running instance-hours automatically, and the runner calls RegisterUsage once at boot as a fail-closed entitlement check (an unentitled instance refuses to start).
是否容易集成到我的 PyTorch 训练代码中？
它是即插即用的。您可以使用透明的 s4weights.save / s4weights.load 写入检查点，或者针对 base->delta 检查点存储使用 save_checkpoint / load_checkpoint。每个张量都会在 GPU 上进行压缩，对于频繁保存的场景，连续检查点之间的字节异或差分也会被存储并压缩。
计费模式
按小时计费的软件费用 + GPU EC2（g6 / g6e）。按 instance type 计量，提供年度选项。
