llmzip, komprimering som gjetter neste token
En tapsfri kompressor som bytter ut ordboken med en språkmodell. Hvert token koster bare overraskelsen sin, altså -log2 P(token), aritmetisk kodet ned til en brøkdel av en bit fra den grensen. En GPT-2 på 124M parametere slår gzip med 2,8x. En modell på 0,5B kommer opp i 9,4x.
Ideen
Komprimering og prediksjon er samme problem i to forskjellige kostymer. Shannon satte
vekslingskursen for lenge siden: et symbol modellen din ventet med sannsynlighet
p, er verdt nøyaktig -log2 p bit, og ingen koder kan gjøre
det bedre i snitt. Klassiske kompressorer bærer med seg en svak modell, et glidende
vindu av tekst de allerede har sett, og bruker mesteparten av bitene sine på den
delen av språket de ikke klarer å forutse.
En språkmodell er en veldig god modell av nettopp det. llmzip kjører derfor modellen gjennom teksten ett token om gangen, tar hele sannsynlighetsfordelingen den lager for neste token, og aritmetisk-koder tokenet som faktisk kom, mot den fordelingen. Forutsigbar tekst koster nesten ingenting. Bare overraskelsene koster bit. Dekomprimeringen spiller av den samme løkken: samme modell, samme kontekst, samme fordeling, slik at dekoderen kan reversere hvert steg.
Tallene
Målt på et utdrag av enwik9 på 32 251 byte, korpuset fra Hutter-prisen, slik at forholdstallene er direkte sammenlignbare på tvers av metodene. Ratio er rå størrelse delt på komprimert størrelse, og bit/tegn er det samme tallet sett fra den andre siden, der vanlig tekst ligger på 8 bit/tegn.
| Metode | Størrelse | Ratio | Bit/tegn |
|---|---|---|---|
| llmzip · Qwen2.5-0.5B | 3 424 B | 9,42x | 0,849 |
| llmzip · SmolLM2-135M | 3 544 B | 9,10x | 0,879 |
| llmzip · gpt2-medium | 3 971 B | 8,12x | 0,985 |
| llmzip · gpt2 (124M) | 4 467 B | 7,22x | 1,108 |
| llmzip · distilgpt2 | 5 233 B | 6,16x | 1,298 |
| brotli -11 | 9 891 B | 3,26x | 2,454 |
| bzip2 -9 | 11 239 B | 2,87x | 2,788 |
| lzma -9e | 11 696 B | 2,76x | 2,901 |
| gzip -9 | 12 307 B | 2,62x | 3,053 |
Det ærlige forbeholdet, som også står i repoet: dette er et utdrag på 32 KB, ikke hele gigabyten, så tallene kan ikke sammenlignes med publiserte enwik9-rekorder. Utdraget trekker i disfavør av de klassiske koderne, ikke i favør, for gzip og lzma tjener tallene sine på å bygge store ordbøker over lange filer, og 32 KB gir dem ikke på langt nær nok plass. Les tabellen som en rettferdig sammenligning i liten skala, ikke som et rekordforsøk.
Kurven for modellstørrelse er det mest interessante. Fra 82M til 494M parametere kjøper deg 1,5x bedre ratio, og rekkefølgen følger kvaliteten på modellen, ikke størrelsen: SmolLM2 på 135M slår gpt2-medium på 355M rett og slett fordi den er den bedre prediktoren. Kompresjonsrate viser seg å være en ryddig og jukse-sikker måte å måle hvor godt en modell faktisk forstår tekst.
To måter å bruke prediksjonen på, og hvorfor den ene taper
Den åpenbare varianten, den folk vanligvis griper til først, er å sortere vokabularet etter sannsynlighet og sende indeksen til det riktige tokenet. Rang 0 dominerer, strømmen ser triviell ut å komprimere, og llmzip gjør denne varianten skikkelig, med en adaptiv aritmetisk koder oppå indeksstrømmen i stedet for en naiv entropikoder.
Den taper likevel med rundt 10 prosent. En rang kaster bort modellens sikkerhet. "Mest sannsynlige token" er ikke den samme påstanden som "p = 0,9 og ikke p = 0,3", og den forskjellen er ekte bit som rangrepresentasjonen allerede har kastet før koderen i det hele tatt får se dem. Å kode mot hele fordelingen tar vare på dem.
Ikke komprimer resultatet en gang til
Å kjøre en vanlig kompressor over et llmzip-arkiv gjør det større, hver eneste gang. Målt på 902 byte med nyttelast: zlib +1,2 %, gzip +2,5 %, lzma +6,9 %, bzip2 +28 %, brotli +0,4 %, zstd +1,1 %. Byteentropien i nyttelasten er 7,767 av 8, og ekte tilfeldige byte av samme lengde havner på 7,72 til 7,82, så det er ingen struktur igjen å finne.
Det resultatet er garantert, ikke flaks, og det er den ryddigste måten å sjekke at koderen faktisk virker: hvis en runde til kunne krympe resultatet, var ikke første runde optimal. Det som var verdt å krympe, var headeren, en fast kostnad på hvert arkiv og 11 prosent av et arkiv på 1 KB. Å pakke versjonsmetadataene som en avgrenset streng i stedet for JSON tok den fra 112 byte til 69.
Hva det koster
- Modellen er ordboken, og den ligger ikke i arkivet. Begge ender trenger nøyaktig samme modell. Uten den er arkivet verdiløst.
- Dekoding krever bit-eksakt reproduserbarhet. En annen dtype, trådtelling, enhet eller torch-versjon endrer sannsynlighetene på siste desimal, og det er nok til å ta den aritmetiske dekoderen ut av synk og ødelegge alt som kommer etterpå. Arkivet lagrer alt sammen, låser trådtellingen ved dekoding og bærer en digest. Komprimeringen kjører sitt eget resultat gjennom en full runde tilbake og nekter å skrive et arkiv som ikke lar seg dekode.
- Det er tregt. 6 til 45 token i sekundet på CPU avhengig av modell, og dekomprimering koster nøyaktig like mye som komprimering, siden den kjører de samme forover-passene. Ratio er den eneste aksen der dette vinner, og der vinner det stort.
- Bare UTF-8. Hvis tokenizeren ikke er byte-eksakt på inndataene, faller arkivet tilbake til ren LZMA i stedet for å miste data.