this post was submitted on 27 Sep 2023
93 points (95.1% liked)

Technology

59441 readers
3637 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] rubikcuber@programming.dev 33 points 1 year ago (2 children)

The research specifically looked at lossless algorithms, so gzip

"For example, the 70-billion parameter Chinchilla model impressively compressed data to 8.3% of its original size, significantly outperforming gzip and LZMA2, which managed 32.3% and 23% respectively."

However they do say that it's not especially practical at the moment, given that gzip is a tiny executable compared to the many gigabytes of the LLM's dataset.

[–] NaibofTabr@infosec.pub 9 points 1 year ago (1 children)

Do you need the dataset to do the compression? Is the trained model not effective on its own?

[–] Tibert@compuverse.uk 12 points 1 year ago (1 children)

Well from the article a dataset is required, but not always the heavier one.

Tho it doesn't solve the speed issue, where the llm will take a lot more time to do the compression.

gzip can compress 1GB of text in less than a minute on a CPU, an LLM with 3.2 million parameters requires an hour to compress

[–] Aceticon@lemmy.world 4 points 1 year ago* (last edited 1 year ago)

Run-length encoding algorithms (like the ones in GZIP) aren't especially amazing at compression, they're more of a balance between speed and compression ability plus they're meant to compress streams of bytes as the bytes come in.

There are better algorithms from achieving maximum compression such as substitution ones (were bytes and sets of bytes are replaced by bit sequences, the most common ones getting the shortest bit sequence, the second most common the second shortest one and so on) but they're significantly slower and need to analyse the entire file to be compressed before compressing it (and the better you want the compression to be, the more complex the analysis and the slower it gets).

Maybe the LLMs can determine upfront the most common character patterns (I use "patterns" here because it might be something more complex that mere sequences, for example a pattern could be for characters in slots 0, 3 and 4 whilst a sequence would be limited to 0, 1 and 2) and are thus much faster and more thorough at doing the analysis stage or just use it as a pre-analysed frequency model for character patterns in a given language which is superior to general run-length encoding compression (whose frequence "analysis"-ish is done as the bytes in the stream are coming in).

PS: I might be using the wrong english language terms here as I learned this compression stuff way back at Uni and in a different language.