129
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Sep 2023
129 points (97.8% liked)
Technology
34806 readers
215 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
Skimming through the linked paper, I noticed this:
So it sounds like the model parameters needed to decompress the file are included in the file itself.
So, you'll have to use the same LLM to decompress the data? For example, if your friend send you an archive compressed with this LLM, then you won't be able to decompress it without downloading the same LLM?
This is not dissimilar to regular compression algorithms. If I compress a folder using the 7zip format (.7z) the end user needs to use 7zip to decompress it since it is a proprietary algorithm. (I know Windows 11 is getting 7zip support)
Except LLMs tend to be very big compared to standard decompression programs and often requires GPU with adequate VRAM in order to work reasonably fast enough. This is a very big usability issue IMO. If decompression can be done with a smaller and faster program (maybe also generated by the LLM?), it can be very useful and see pretty wide adoption (e.g. for future game devs who want to reduce their game size from 150GB to 130GB).
I don't know how this would apply to decompression models in actuality, but in general, deep learning is VRAM intensive only during the training process, that's because they train multiple batches of data at once for generalization, and all those batches of data need to be stored in ram.
But once the model is trained, the end user is only going to input data one by one, so VRAM usually is not an issue. There are also light weight models that are designed to be run on lower end hardware.
Training tends to be more compute intensive while inference is more likely to be able to be ran on a smaller hardware foot print.
The neater idea would be a standard model or set of models, so that a 30G program can be used on ~80% of target case, games and video seem good canidates for this.