Cinco formas de fazer fine-tuning de um LLM sem um cluster caro: LoRA, QLoRA, Unsloth, DPO e GPU

Uma história comum: a equipe decide fazer o fine-tuning de um modelo aberto para a sua tarefa, olha os preços das GPUs na nuvem e adia a ideia para tempos melhores. Um erro. A maior parte da conta não vem de uma necessidade real, mas do hábito de fazer tudo "do jeito adulto": atualizar todos os pesos, manter o modelo em precisão total e alugar a placa mais poderosa. O KDnuggets analisou cinco técnicas que quebram esse hábito. Veja o que há por trás delas e como aplicá-las.

De onde vem a conta

No fine-tuning completo, a memória não guarda apenas o modelo em si. Ao lado dele ficam os gradientes e o estado do otimizador (no Adam, são mais dois números para cada parâmetro). Uma estimativa grosseira: um modelo de 7 bilhões de parâmetros exige mais de 100 GB de memória de vídeo. Isso já significa várias placas caras, e não apenas uma.

Todas as cinco técnicas atacam um de três pontos: quantos parâmetros treinamos, em que precisão guardamos o modelo e por qual hardware pagamos.

As cinco técnicas, em ordem

1. LoRA. Em vez de atualizar todos os pesos, congelamos o modelo e adicionamos às camadas pequenas matrizes treináveis, os adaptadores. Treina-se uma fração de um por cento dos parâmetros, e os gradientes e o estado do otimizador são calculados apenas para eles. O resultado é um adaptador de dezenas de megabytes, que pode ser armazenado separadamente e conectado ao modelo base. Para cada cliente ou tarefa, um arquivo próprio, e não uma cópia do modelo de 14 GB.

2. QLoRA. O mesmo LoRA, mas com o modelo base congelado comprimido para 4 bits. Os adaptadores, por sua vez, são treinados em precisão mais alta. Foi esse truque que permitiu fazer o fine-tuning de modelos em uma única placa de consumo ou um servidor de custo moderado. O preço é um passo de treinamento um pouco mais lento e um pequeno risco de perda de qualidade, por isso vale conferir o resultado na sua própria validação.

3. Unsloth. Não é um algoritmo novo, mas uma implementação otimizada: kernels reescritos e um uso mais econômico da memória. Para quem coloca a mão na massa, o importante é que ela se encaixa sobre a stack habitual (Hugging Face, PEFT, TRL) e entrega ganhos de velocidade e de VRAM sem mudar o método. É o passo mais barato em esforço: trocar o import e medir.

4. DPO. Se o objetivo não é ensinar algo novo ao modelo, mas ajustar o comportamento (tom, formato, recusas, estilo), o RLHF clássico, com um modelo de recompensa separado, é exagero. O DPO treina diretamente em pares "resposta boa / resposta ruim", sem modelo de recompensa e sem o ciclo de geração. Menos componentes, menos memória, menos pontos de falha. Reunir os dados é mais fácil do que parece: bastam logs em que o usuário escolheu uma de duas opções.

5. O tamanho certo de GPU. O item mais chato e o que mais pesa no bolso. Para QLoRA em um modelo da classe 7–8B, muitas vezes basta uma placa de 24 GB, e alugar um acelerador topo de linha "por precaução" significa pagar várias vezes mais por memória ociosa. Primeiro meça o pico de memória com um batch pequeno e só depois escolha a placa. Ajudam o gradient checkpointing, o acúmulo de gradientes e contextos curtos nos exemplos de treinamento.

Limitações e o que fazer

Nenhuma dessas técnicas substitui dados de qualidade. Mil exemplos limpos e bem selecionados costumam valer mais do que cem mil de lixo, e um método barato num dataset ruim entrega, barato, um modelo ruim. Além disso, LoRA e QLoRA são menos adequados quando é preciso mudar profundamente o conhecimento ou o idioma do modelo; para uma adaptação leve a um domínio e a um formato, funcionam muito bem.

A ordem prática de ação é esta:

• Comece com QLoRA em um modelo pequeno e uma única placa, adicionando o Unsloth se ele suportar a sua arquitetura.
• Monte logo uma validação com as suas próprias tarefas e compare com o modelo base e com o prompting: às vezes o fine-tuning nem é necessário.
• Se for preciso ajustar o jeito de responder, adicione o DPO sobre o adaptador já treinado.
• Escolha a GPU pela memória medida, e não pela tabela de preços do provedor.

Uma ressalva importante: descrevemos as abordagens a partir do anúncio do artigo do KDnuggets, e os números concretos de velocidade e memória dependem do modelo, do tamanho do contexto e das versões das bibliotecas. Verifique-os no seu próprio hardware antes de construir um orçamento sobre eles.