Lossless Tensor Compression as Program Synthesis
Jieke Shi, Junda He, Wenjia Jiang, Weifeng Sun, Shidong Pan, Zhensu Sun, Chengran Yang, Peixin Zhang, Yifan Jia, Zhou Yang, Thong Hoang, Xiwei Xu, Zhenchang Xing, David Lo
James / Sherry
cs.SE, cs.AI, cs.PL
2026-08-03
Brevis turns each tensor into a DSL program that rebuilds it bit-exact. On 10 checkpoints it shrinks 2.13 TB to 1.41 TB (33.9%), beating zstd, ZipNN and DFloat11.
Hugging Face now hosts more than 15 PB, with repository count climbing from 425 in April 2020 to 2.95 million today. Model checkpoints keep multiplying and growing, and the cost of archiving, transferring, and deploying them climbs with it. Lossy methods (quantization, pruning) change weights and cannot be used when bit-exact recovery is required. Among lossless options, general compressors (zstd, gzip) treat weights as a generic byte stream and miss tensor structure, while existing tensor-specific compressors (ZipNN, DFloat11) rely on fixed, format-locked pipelines that cannot capture patterns like repeated regions or floating-point bit planes.
Brevis aims to absorb that structure with a more general framework.
The core idea is to frame lossless tensor compression as program synthesis: given a tensor, synthesize a self-contained program that rebuilds it bit-exactly when executed. The compressed artifact is the program; decompression just runs it, with no search.
The team designed a typed domain-specific language (DSL) built on seven reversible operators:
Search is target-directed, working backward from the tensor. Every hole is paired with the exact byte stream it must produce, and applying an operator decomposes that stream into child outputs; only decompositions that satisfy the type constraints survive. To order the search, the system learns a production prior (per-operator probabilities under each context) from a small representative sample of tensors and runs a bounded A search, where g(s) is accumulated cost and h(s) is an admissible estimate from a relaxed grammar. Complete candidates are then chosen by exact serialized size. The decoder only parses and executes the program, with no prior and no search.
Across 10 public checkpoints (eight BF16, one FP32, one FP8; 420 shards; 2.13 TB total):
| Method | Llama-3.1-8B archive | Reduction |
| zstd | 12.38 GB | 22.91% |
| ZipNN | 10.66 GB | 33.63% |
| DFloat11 | 10.90 GB | 32.16% |
| Brevis | 10.58 GB | 34.13% |
Weight storage is a real cost line in AI infrastructure, especially for hosting platforms and large-model distribution. Brevis hands the job of finding structure to program synthesis, so it is not locked to a single fixed floating-point rearrangement pipeline the way ZipNN and DFloat11 are. That lets it work across dtypes (BF16, FP32, FP8) and modalities (language, audio, image generation), and any structure the DSL can express is fair game. For engineers it is a drop-in lossless layer for checkpoint pipelines, and a few percent at PB scale is real money.
The authors concede the evaluation covers only public checkpoints, with limited domain and format diversity; the current implementation synthesizes each tensor independently, and cross-tensor synthesis and accelerator-aware decoding are left to future work.
The magnitude of the gain is worth scrutinizing. Against a strong specialized baseline like ZipNN the pooled saving is only 0.72% more. For a single small model that is negligible; the value only shows up at PB-scale hosting and bulk distribution. The framework's power also depends on the DSL: any structure it cannot express falls back to the Lit operator, at which point the advantage disappears, and the paper does not report how often that happens.