AI data
Training data does not shrink itself.
A training run stores more than a model. It stores the dataset, the checkpoints, the optimizer state, the embeddings, and whatever the run generated. Accelerator time gets the meeting. The bytes left behind get the quiet invoice. Some of those bytes must stay hot so a job can resume. Most of them do not. Delete the ones you will not resume from. Shrink the ones you will still ship, archive, or share.
What makes AI training storage so expensive?
Checkpoints are large and frequent. Datasets are large and copied. Embeddings and generated media accumulate after the job. Hot storage is priced for speed, and leftover artifacts stay on it. Egress appears when you share a set or replicate a run. The bill is the copies you forgot to expire.
A checkpoint is a snapshot of weights and, often, optimizer state. Jobs save them so a failure does not throw away the run. AWS and Google have both written about checkpoint frequency as a cost and goodput problem: save too rarely and you lose work, save too often and you stall accelerators and fill disks. That literature is about their systems. It is not a qzip result. The planning fact is enough: decide how many checkpoints you need to restart, and stop treating every hour as permanent.
Datasets get copied more than they get updated. A training set lands in object storage, then on the cluster's local disk, then in another region because a second team asked. Each copy is capacity. The transfer between them is egress if that path is billed. Embeddings are the quiet cousin: a vector per document, kept forever, sometimes duplicated per experiment. Generated images and clips are the loud cousin, and the video page is the right spoke when the files are video. They share one property. Nobody wrote a retention rule.
Hot tiers exist so the next step of the job is fast. They are a bad place to keep last quarter's failed runs. Move milestone checkpoints, the ones you might evaluate or audit, to cheaper object storage if you will not load them this week. Delete intermediate checkpoints once a newer one is known good. That deletion is worth more than any compressor, and it is free to decide. Do it in the training script so a human does not have to remember.
How should I store model checkpoints without paying for all of them?
Keep the latest few on fast local disk so a restart is quick. Keep milestone checkpoints in object storage. Delete the rest once the newer snapshot is verified. Compress a checkpoint only after you know the format still has room and the trainer can load the compressed form. Measure a real snapshot.
Write the policy in the job, not in a wiki. Retain N latest checkpoints on the fast tier. Every K steps, copy one milestone out asynchronously so the accelerators are not waiting on a cold network. Expire milestones you will not compare. A checkpoint you cannot name an owner for is a candidate for deletion. This is ordinary lifecycle thinking applied to a file the cluster just wrote.
Compression of checkpoints is real engineering and also easy to overclaim. Numeric tensors may compress poorly compared with text logs. A published result for one codec on one model is not your model, and it is not our benchmark. Our published figure is enwik9 text, as of Oct 14, 2026, and a checkpoint is not that file. If checkpoints dominate your bill, send one. We will tell you the size that came back and whether the bytes match. If the gain is small, we will say that too.
The decompressor has to be there at restore. A smaller checkpoint that the job cannot read is downtime, not a saving. Count the decompressor in the total if you care about what you store plus what you need to unpack, the same way the text benchmark counts it. A ratio that hides the decompressor will not match the bytes you actually keep next to the file.
How do I cut the cost of training datasets and embeddings?
Stop copying the full set into every region and every experiment. Keep one durable copy, shard it, and sync increments. Store embeddings you still query. Delete embeddings for models you retired. Compress text and metadata around the tensors when a sample says those files shrink. Leave already-encoded media alone until you measure it.
A dataset duplicated per researcher is an egress and capacity story. Give people access to one bucket and a local cache, instead of a personal full copy. Incremental sync sends changes, not the corpus. That is a transfer design, covered on the egress page. It matters more than a compressor when the waste is duplicate full copies of an already dense set.
Text, JSON metadata, captions, and web dumps inside a training mix are often the compressible part. Image and audio files may already be encoded. Split the sample that way before you average a ratio across the mix. An average hides a corpus of text that would shrink and a corpus of JPEGs that will not. Report them separately. Then you can compress the part that pays.
Embeddings look small per row and large in total. They also go stale when the model that produced them is replaced. Tie retention to the model version. When the model is retired, the vectors are a backup decision, not a hot index. If you must keep them, they are bytes like any other, and the storage class should match how often you scan them. A vector database's RAM is the expensive tier. Object storage is the cheap tier. Do not leave a retired index in RAM because the job that built it has finished.
What about generated images, audio, and video?
Generated media piles up before anyone files it. Keep what you will ship or label, and expire the rest. Already-encoded video may not shrink under a general compressor. Uncompressed masters and sidecars might. The video page is the spoke for that workload. Send a sample of the files you store, not a screenshot of the bill.
Generation is a firehose. A product that renders variants will store variants unless a policy deletes the ones nobody picked. That policy is worth more than a codec argument. After you know which files are the product, look at their format. A delivery encode is often dense. A WAV, a raw image sequence, or a JSON sidecar of prompts may not be. Measure those separately.
Sharing a generated set with a customer or another region is egress. A smaller master helps only if you send the smaller form and the receiver can use it. If the contract requires a specific codec, you cannot swap the file for a zip and call the contract met. Lossless means the same bytes back, which is what you want for an archive of masters. It is not a way to smuggle a lower-bitrate encode past a spec.
We do not publish a video ratio. The video page says that, and this page repeats it so nobody pastes the text benchmark onto a pile of clips. If generated media is the bill, the sample is a representative folder of that media plus any sidecars. We will measure it on those files. The waitlist use case is AI infrastructure, and the data type can be mixed if the folder is not only checkpoints.
Questions.
How many checkpoints should I keep?
Keep enough recent ones to restart after a failure, plus the milestones you will evaluate or audit. Delete intermediate snapshots once a newer one is verified. The right count depends on how often the job fails and how long a restart takes. It is not every file the script has ever written.
Can I use the enwik9 ratio on a checkpoint or a dataset?
No. That 10.7027× figure is the enwik9 text file divided by the compressed file, as of Oct 14, 2026. Checkpoints and media are different bytes. Use the calculator with a ratio you assume, clearly labeled as an assumption, or send a sample for a real measurement.
Do embeddings and datasets compress well?
Text and repetitive metadata often do. Encoded images, audio, and packed numeric tensors often do less. Split the sample and measure each part. We will not quote a single AI ratio. There is not a published one from us yet.
Provider docs, not our price list.
Links checked Oct 21, 2026. Rates and rules on those pages can change.
Keep reading.
Send us a sample.
We will measure it on your files. We will not quote a savings number we have not measured. Write hello@qzip.ai or join the waitlist.