LLMZip: Lossless Text Compression using Large Language Models · HackerPapers discussions

LLMZip: Lossless Text Compression using Large Language Models — mentioned by adamgordonbell

Tue, 11 Aug 2026 20:51:44 GMT

And also the LLM version, and LLMZip https://bellard.org/ts_zip/ https://arxiv.org/abs/2306.04050

Paper and discussion history. A mention is not an endorsement.

LLMZip: Lossless Text Compression using Large Language Models — HN submission

Tue, 04 Nov 2025 01:49:04 GMT

LLMZip: Lossless Text Compression Using Large Language Models

2 points; 4 discussion replies on HN. Paper and source history. A submission is not an endorsement.

LLMZip: Lossless Text Compression using Large Language Models — mentioned by avidiax

Mon, 21 Jul 2025 21:46:17 GMT

You can get much better than that by taking a well-known LLM model and encoding a series of offsets from the most likely sequence of tokens, especially if you are OK with the message being slightly different. https://arxiv.org/abs/2306.04050 https://bellard.org/ts_zip/

Paper and discussion history. A mention is not an endorsement.

LLMZip: Lossless Text Compression using Large Language Models — mentioned by PaulHoule

Mon, 09 Sep 2024 14:26:51 GMT

To tease out the issues: I see the BPE algorithm as similar to Huffman coding in the way it builds the token list by creating, at any point, a token that is optimal in "compressing" the data in that it represents a commonly occuring sequence. As BPE is going to create tokens for frequent words it is going to gain over just representing over single-byte tokens like "a" or 0xb7 however you get a loss in that "a" is getting puffed up to two bytes or more. In an ordinary implementation of BPE I think the order of the token ids is not relevant so depending on how it was coded up I wouldn't depend…

Paper and discussion history. A mention is not an endorsement.

LLMZip: Lossless Text Compression using Large Language Models — mentioned by eru

Mon, 04 Mar 2024 05:43:37 GMT

Two possible implementation: (1) Take your data as a stream. Use your machine learning gadget to give you the (predicted) probability for each of the possible next tokens. Then use those probability in arithmetic coding to specify which token actually came next. (2) Take your data D. Apply lossy compression to it. Store the result L := lossy(D). Also compute the residue R := D - uncompress(L). If your lossy compression is good, R will be mostly zeroes (and only a few actually differences), so it will compress well with a lossless compression algorithm. Approach (1) is a more sophisticated…

Paper and discussion history. A mention is not an endorsement.

LLMZip: Lossless Text Compression using Large Language Models — mentioned by bcjordan

Tue, 04 Jul 2023 13:23:47 GMT

Paper: https://arxiv.org/abs/2306.04050 > We provide new estimates of an asymptotic upper bound on the entropy of English using the large language model LLaMA-7B as a predictor for the next token given a window of past tokens. > Preliminary results from limited experiments suggest that our scheme outperforms state-of-the-art text compression schemes such as BSC, ZPAQ, and paq8h.

Paper and discussion history. A mention is not an endorsement.