Hugging Face compara todas as alternativas ao LoRA: qual método vence no ajuste fino de LLMs

O LoRA virou o padrão de fato no ajuste fino de grandes modelos de linguagem: é barato, rápido e funciona quase em qualquer lugar sem surpresas. A Hugging Face decidiu fazer uma pergunta honesta: dá para fazer melhor e, se der, quando?

Por que o LoRA mantém a liderança

O LoRA (Low-Rank Adaptation) funciona de forma simples: em vez de atualizar os bilhões de pesos do modelo, o método adiciona um par de matrizes pequenas de baixo rank às camadas principais. O número de parâmetros treináveis cai de 10 a 1000 vezes. Isso torna o ajuste fino viável até em GPUs de consumo.

Por isso o LoRA está em toda parte: é usado para retreinar Llama e Mistral, criar estilos personalizados no Stable Diffusion e adaptar LLMs corporativos às particularidades de um domínio. A biblioteca PEFT da Hugging Face soma centenas de milhares de downloads por semana.

Mas o LoRA tem pontos fracos. Com ranks altos de matriz (rank=64 ou mais), o treinamento fica instável. Em tarefas que exigem transmitir com precisão conhecimento factual, o método às vezes perde para o ajuste fino completo. E sob limites rígidos de memória, como ao treinar em uma única placa de vídeo barata, até o LoRA pode ser exigente demais.

O que a Hugging Face testou

A equipe usou a biblioteca PEFT e fez uma comparação sistemática do LoRA com cinco alternativas em tarefas downstream reais:

• DoRA: decompõe os pesos em direção e magnitude e os atualiza de forma independente, aproximando o comportamento do ajuste fino completo
• LoRA+: uma ideia simples: as matrizes A e B são treinadas com learning rates diferentes, e a B recebe uma lr mais alta para acelerar a convergência
• rsLoRA: um fator de normalização que estabiliza os gradientes em valores altos de rank
• VeRA: matrizes aleatórias congeladas; só pequenos vetores de escala são treinados, com dezenas de vezes menos parâmetros que o LoRA
• GaLore: projeta os próprios gradientes em um espaço de baixo rank, economizando memória do otimizador sem mudar a arquitetura dos pesos

Métricas: qualidade em tarefas de controle (NLU, seguimento de instruções, sumarização), pico de consumo de memória da GPU e velocidade de uma época de treinamento.

Quem pressiona o líder

Não há um vencedor claro: cada método tem seu perfil.

O DoRA entrega, de forma consistente, qualidade um pouco melhor que o LoRA com o mesmo número de parâmetros e a mesma memória. A diferença aparece mais em tarefas de seguimento de instruções e raciocínio. O preço é um tempo de treinamento um pouco maior, por causa da decomposição extra dos pesos.

O rsLoRA não melhora a qualidade básica, mas elimina a instabilidade em ranks altos. Se você precisa de rank=128 ou mais, o rsLoRA é praticamente obrigatório; o LoRA clássico começa a "flutuar" ali.

O VeRA é interessante para cenários com limites rígidos de tamanho do adaptador, como servir milhares de adaptadores de usuários em um servidor, mas perde um pouco em qualidade.

"O

LoRA continua sendo a melhor escolha padrão, mas conhecer as alternativas permite extrair o máximo em condições específicas", resumem os autores do estudo.

O GaLore permite treinar em GPUs com pouca VRAM sem mudar a arquitetura dos pesos. Serve para pré-treinamento ou pré-treinamento continuado, quando é preciso trabalhar com todos os pesos mas a memória é catastroficamente escassa. O treinamento, porém, fica visivelmente mais lento.

O que isso significa

O ecossistema PEFT está amadurecendo: em vez de um único método universal para todos os casos, forma-se um conjunto de ferramentas. Para as equipes de produto, isso significa uma coisa: antes de escolher um método de ajuste fino, vale gastar uma hora em um benchmark comparativo na sua própria tarefa, em vez de usar o LoRA por inércia. As chances de uma alternativa trazer um ganho perceptível no seu cenário são hoje maiores do que nunca.