Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by josalhor on Sunday April 28, 2024 @11:55AM
(#40189499)
I just skimmed over LoRA+ and DoRA and I see no reason why these improvements could not go hand in hand. Actually, LoRA+ seems to be about efficient training while DoRA seems about improving the ability to actually learn, making it significantly more robust. Although I still have my questions on how the improvements of LoRA+ would be applied to the magnitude vector.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by WithinReason on Sunday April 28, 2024 @11:50AM
(#40189472)
The two methods seem to be independent, wonder if you can combine them for even better performance.
Interestingly both seem to indirectly modify the optimisation process, in my opinion effectively trying to fix a bad optimiser. Seems like we still have a long way to go after Adam...
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by neodypsis on Sunday April 28, 2024 @03:02PM
(#40190917)
> Seems like we still have a long way to go after Adam...
A preprint in arxiv suggests that Adam works better than SGD for training LLMs due to the issue of class-imbalance [0]. It appears that scaling the gradient step helps with the training, for example, see another approach suggested in [1].
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by cuuupid on Sunday April 28, 2024 @10:40AM
(#40188941)
I’m struggling to understand from this paper whether the approach is better in the general sense (all cases, with wider models seeing greater benefits) or purely for wider models (with narrower models seeing detriment)?
If it’s the former this could effectively halve finetuning cost overnight which would go a significant way towards enabling a wider array of use cases for LoRA.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by sorenjan on Sunday April 28, 2024 @11:02AM
(#40189098)
This gets mentioned here everytime an article about LoRA is posted. Sometimes acronyms means multiple things, they're not in the same field so the risk of confusion beyond short headlines is negligible.
It's a bit like if someone reading a bicycling article and getting annoyed that FTP means Functional Threshold Power instead of File Transfer Protocol, or reading about machine learning and getting confused that MLP doesn't mean My Little Pony.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by the__alchemist on Sunday April 28, 2024 @11:54AM
(#40189496)
I think the reason this keeps coming up is encoded in your second sentence, in conjunction with the HN medium: LoRa and LoRA are both, unfortunately, things that the target audience are likely to be interested in and/or knowledgeable with, but a general audience is not.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by dragonwriter on Sunday April 28, 2024 @11:50AM
(#40189469)
> "computer science" and "computer science" are the same domain, it's not a good idea to use the same acronym.
But “radio communication" is not “computer science”, even though people sometimes plug radio transceivers into computers, just like “tv shows” aren't “computer science” just because people sometimes view or store their shows on a computer, and “bicycles” aren’t “computer science” because sometimes people mount computers on their bikes.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by rakoo on Sunday April 28, 2024 @03:16PM
(#40191050)
So instead of LoRa and anything else, everyone now has to say LoRa (the communication protocol) or LoRa (the large model thing). Having to add context all the time makes everything so much simpler !
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by nostrademons on Sunday April 28, 2024 @12:03PM
(#40189561)
"Computer science" isn't really one domain anymore - the field split into several subdomains in the 2010s. Just try to get a job as a "computer scientist" now - the recruiter would be like "No, are you a web developer? Mobile developer? Backend developer? Data scientist? Data engineer? Cloud engineer? AI engineer?
Machine learning developer?"
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by IshKebab on Sunday April 28, 2024 @12:28PM
(#40189728)
Yes but radio protocols and AI methods are a lot closer than most overlapping acronyms. This is obvious from the fact that it gets mentioned every time an article about LoRA is posted.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by mattlondon on Sunday April 28, 2024 @12:38PM
(#40189798)
But these are clearly both in the same field as everyone keeps saying mentioning it here! So clearly there is confusion. It certainly tricked me on first reading - "ah cool - efficient lora+ that sounds cool... Ah wait no it's just some machine learning spam"
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by kcorbitt on Sunday April 28, 2024 @11:21AM
(#40189258)
This specific variant "LoRA+" described in this paper is even harder to search for. I was doing some research on this technique recently and it turns out that "Lora+" matches with "Lora" in Discord search, which is quite unhelpful. :)
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by SquareWheel on Sunday April 28, 2024 @11:54AM
(#40189491)
Discord search is one of the worst I've ever used. They remap words like "localization" to "local", which makes it impossible to search for more specific terms.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by yau8edq12i on Sunday April 28, 2024 @10:40AM
(#40188945)
The acronym LoRA used in the context of deep learning (2021) is about seven years younger than the radio communication protocol called LoRa (2014). Type "lora" in a search engine and see what you get.
Re:LoRA+: Efficient Low Rank Adaptation of Large Models
by Scipio_Afri on Monday April 29, 2024 @01:40AM
(#40194836)
This uses less memory so you can do fine tuning or hardware with less vram but at a cost of taking longer on training - there is a throughput penalty, the paper detailing the technique shows something like a 15% decrease in throughput.
Interestingly both seem to indirectly modify the optimisation process, in my opinion effectively trying to fix a bad optimiser. Seems like we still have a long way to go after Adam...
A preprint in arxiv suggests that Adam works better than SGD for training LLMs due to the issue of class-imbalance [0]. It appears that scaling the gradient step helps with the training, for example, see another approach suggested in [1].
0. https://arxiv.org/pdf/2402.19449 1. https://arxiv.org/pdf/2402.02347
https://en.wikipedia.org/wiki/LoRa
If it’s the former this could effectively halve finetuning cost overnight which would go a significant way towards enabling a wider array of use cases for LoRA.
It's a bit like if someone reading a bicycling article and getting annoyed that FTP means Functional Threshold Power instead of File Transfer Protocol, or reading about machine learning and getting confused that MLP doesn't mean My Little Pony.
Also, both use a non-standard case mix.
Exactly. Like WiFi: from ancient times it has meant "Wife's Fidelity".
https://en.m.wikipedia.org/wiki/Crypto_naming_controversy
"computer science" and "tv shows" aren't the same domain, it's fine to have the same acronym.
"computer science" and "computer science" are the same domain, it's not a good idea to use the same acronym.
But “radio communication" is not “computer science”, even though people sometimes plug radio transceivers into computers, just like “tv shows” aren't “computer science” just because people sometimes view or store their shows on a computer, and “bicycles” aren’t “computer science” because sometimes people mount computers on their bikes.
I wonder why!
If the later please point out the alternatives.