- Ajuste fino com LoRA treina um pequeno conjunto de pesos adaptadores em vez do modelo completo — tipicamente 1–5% dos parâmetros totais — permitindo ajustar um modelo de 7B em uma única GPU de consumo.
- QLoRA adiciona quantização de 4 bits ao modelo base congelado, reduzindo ainda mais a VRAM: um modelo de 7B cabe em ~6 GB, e um de 13B em ~10 GB.
- Rank (r) e alpha são os dois parâmetros que controlam o quanto o adaptador pode alterar o comportamento do modelo. Comece com r=16 e alpha=32.
- O ajuste fino muitas vezes não é a ferramenta adequada. Se o seu problema for falta de conhecimento, use RAG. Se for formatação ou tom, melhore primeiro o seu prompt do sistema.
O ajuste fino com LoRA (Low-Rank Adaptation) é um método eficiente em parâmetros para adaptar um modelo de linguagem pré-treinado a uma tarefa específica. Em vez de atualizar todos os pesos do modelo, a LoRA congela os pesos originais e injeta pequenas matrizes treináveis nas camadas de atenção. O resultado é um adaptador — um arquivo frequentemente menor que 100 MB — que se acopla ao modelo base no momento da inferência. Você obtém comportamento especializado sem re-treinar bilhões de parâmetros.
Como funciona a LoRA
Uma matriz de pesos padrão de transformer pode ser 4096 × 4096. A LoRA decompõe a atualização dessa matriz em duas matrizes muito menores: uma de dimensão 4096 × r e outra de r × 4096, onde r é o rank (comumente entre 4 e 64). Durante o treinamento, apenas essas matrizes de baixo rank são atualizadas. Na inferência, o produto dessas duas matrizes menores é somado novamente à matriz original congelada — sem latência adicional na maioria das implementações, pois o adaptador é mesclado antes da implantação.
Isso é relevante para o hardware: como os pesos do modelo base estão congelados, eles não exigem estados do otimizador nem gradientes. Apenas os parâmetros do adaptador exigem isso. É por isso que os requisitos de VRAM caem drasticamente em comparação com o ajuste fino completo.
LoRA versus QLoRA
| Método | Precisão do modelo base | Precisão do adaptador | VRAM para modelo de 7B (treinamento) | 13B VRAM (treinamento) |
|---|---|---|---|---|
| Ajuste fino completo | bf16/fp16 | — | ~60 GB | ~110 GB |
| LoRA | bf16/fp16 | bf16/fp16 | ~16 GB | ~28 GB |
| QLoRA | 4 bits (NF4) | bf16/fp16 | ~6 GB | ~10 GB |
QLoRA, introduzida por Dettmers et al. (2023), carrega o modelo base com quantização de 4 bits em NormalFloat (NF4) e mantém o adaptador em precisão total. O treinamento é mais lento do que o LoRA padrão devido à sobrecarga de desquantização em cada passagem direta (forward pass), mas as economias de VRAM permitem treinar modelos de 13B e 70B em hardware acessível à maioria dos usuários. A qualidade em comparação com o LoRA completo é geralmente desprezível para ajustes finos específicos de tarefa; em tarefas complexas de raciocínio, pode haver alguma degradação.
Antes de investir em hardware, execute seu modelo-alvo no Calculadora de VRAM — ele leva em conta o tamanho do lote e o comprimento da sequência, ambos os quais alteram significativamente os valores.
Rank e Alpha: O que eles realmente fazem
Rank (r) controla a capacidade expressiva do adaptador. Um rank de 4 adiciona muito poucos parâmetros e produz mudanças sutis; um rank de 64 confere ao adaptador maior capacidade de remodelar o comportamento do modelo, mas aumenta o consumo de VRAM e o risco de sobreajuste.
Alpha (α) é um fator de escalonamento aplicado à saída do LoRA antes de ser somada aos pesos congelados. A taxa de aprendizado efetiva do adaptador escala com α / r. Manter alpha igual ao dobro do rank (por exemplo, r=16, alpha=32) é o ponto de partida mais comum e funciona bem na prática.
| Uso | r recomendado | alpha recomendado |
|---|---|---|
| Mudança de estilo / tom | 4–8 | 8–16 |
| Perguntas e respostas especializadas por domínio | 16 | 32 |
| Novo formato de tarefa (ex.: chamada de função) | 32–64 | 64–128 |
| Mudança complexa de comportamento | 64 | 128 |
Um rank mais alto nem sempre significa melhores resultados. Para a maioria dos ajustes finos voltados ao seguimento de instruções, r=16 é suficiente. Se a perda de validação não estiver melhorando, aumente o rank ou adicione mais dados antes de aumentar o número de épocas.
Requisitos realistas de VRAM e tempo
Os valores abaixo assumem QLoRA com tamanho de lote igual a 1 e comprimento de sequência de 2048. Configurações multi-GPU escalonam aproximadamente de forma linear com a VRAM, mas exigem configuração com FSDP ou DeepSpeed.
| Tamanho do modelo | GPU mínima | GPU confortável | ~1000 passos (A100) |
|---|---|---|---|
| 3B | RTX 3060 (12 GB) | RTX 4070 (12 GB) | ~5 minutos |
| 7B | RTX 3060 (12 GB) | RTX 4080 (16 GB) | ~15 minutos |
| 13B | RTX 3090 (24 GB) | RTX 4090 (24 GB) | ~30 min |
| 34B | 2× RTX 3090 | A100 40 GB | ~90 minutos |
| 70B | 2× A100 40 GB | 4× A100 | ~4 horas |
Os custos na nuvem variam. Um único A100 de 80 GB na Lambda Labs custa cerca de USD 1,50–2,00 por hora, conforme dados de meados de 2026. Um ajuste fino QLoRA de um modelo de 7B com 50 mil exemplos normalmente é concluído em menos de duas horas — bem abaixo de USD 5. Para decisões de compra de GPU, consulte o guia de GPUs para LLMs locais.
Ferramentas: Como realmente executar um ajuste fino com LoRA
Os dois frameworks dominantes são Hugging Face TRL + PEFT e Axolotl. Ambos suportam LoRA e QLoRA. Unsloth é uma opção popular alternativa que alcança treinamento duas vezes mais rápido por meio de kernels CUDA personalizados.
Exemplo mínimo com TRL + PEFT (Python)
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer, SFTConfig
import torch
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Meta-Llama-3-8B-Instruct",
quantization_config=bnb_config,
device_map="auto",
)
lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora_config)
trainer = SFTTrainer(
model=model,
train_dataset=your_dataset, # espera coluna "text"
args=SFTConfig(output_dir="./output", num_train_epochs=3),
)
trainer.train()
model.save_pretrained("./my-lora-adapter")
O adaptador salvo em ./my-lora-adapter tem tipicamente entre 50 e 300 MB. Combine-o ao modelo base para inferência mais rápida usando model.merge_and_unload() antes de salvar.
Axolotl (orientado por configuração)
O Axolotl gerencia todo o pipeline a partir de um arquivo YAML, facilitando a reprodução de execuções. Instale com pip install axolotl, então:
# config.yml
base_model: meta-llama/Meta-Llama-3-8B-Instruct
load_in_4bit: true
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
datasets:
- path: ./data/train.jsonl
type: alpaca
output_dir: ./output
num_epochs: 3
accelerate launch -m axolotl.cli.train config.yml
Quando o ajuste fino é a ferramenta errada
O ajuste fino com LoRA resolve um problema específico: alterar como o comportamento ou as respostas de um modelo. Ele não injeta de forma confiável conhecimento factual. Se seu caso de uso se enquadra em uma dessas categorias, uma abordagem diferente produzirá melhores resultados com menos esforço:
- O modelo carece de conhecimento atual ou proprietário. Utilize geração aumentada por recuperação (RAG). O ajuste fino com base em fatos gera modelos que apresentam alucinações com alta confiança sobre qualquer coisa fora do escopo dos dados de treinamento.
- Você precisa que o modelo siga instruções específicas. Experimente primeiro um prompt de sistema detalhado. Um prompt bem projetado em um modelo base capaz frequentemente supera um modelo menor ajustado finamente na mesma tarefa.
- Você possui menos de cerca de 500 exemplos de alta qualidade. A razão sinal-ruído é muito baixa; o modelo provavelmente sofrerá sobreajuste. Amplie sua base de dados ou utilize a técnica de poucos exemplos (few-shot prompting) em vez disso.
- Você está desenvolvendo um protótipo. O ajuste fino fixa um comportamento. Utilize a API e itere nos prompts até que o comportamento se torne estável; só então considere o ajuste fino para reduzir os custos por token em escala. A Calculadora de custos de API ajuda a quantificar o momento em que ajustar finamente um modelo local torna-se mais econômico do que pagar por token.
Se você estiver avaliando, a longo prazo, um modelo local ajustado finamente contra uma API hospedada, a calculadora de ponto de equilíbrio entre hospedagem local e uso de API fornece o ponto de inflexão com base no seu volume de uso e nos custos da GPU.
Perguntas frequentes
Quanta quantidade de dados é necessária para ajuste fino com LoRA?
Para seguir instruções ou alterar estilo, 500–2.000 exemplos de alta qualidade e diversificados costumam ser suficientes. Para adaptação complexa a um domínio específico, 5.000–20.000 exemplos geram resultados mais robustos. A qualidade importa muito mais do que a quantidade — 200 exemplos cuidadosamente curados superam 2.000 exemplos ruidosos.
É possível executar inferência com LoRA em hardware de consumo?
Sim. Um adaptador mesclado não acrescenta sobrecarga alguma à inferência em comparação com o modelo base. Um adaptador não mesclado adiciona uma pequena quantidade de cálculo a cada passo direto (forward pass). Tanto o llama.cpp quanto o Ollama suportam carregar diretamente adaptadores LoRA convertidos para o formato GGUF. Consulte o Guia de requisitos de VRAM para obter dados sobre o uso de memória exclusivamente durante a inferência.
Qual é a diferença entre LoRA e ajuste fino completo?
O ajuste fino completo atualiza todos os pesos do modelo e exige armazenar os estados do otimizador para cada um deles — aproximadamente 16–20 bytes por parâmetro, em precisão mista com o otimizador Adam. Já o LoRA atualiza apenas as matrizes de adaptadores de baixo posto, reduzindo drasticamente o número de parâmetros treináveis em um fator de 10 a 1.000 vezes. A troca envolve capacidade: o ajuste fino completo pode remodelar o modelo de forma mais abrangente, mas, para a maioria das tarefas práticas, o LoRA atinge desempenho equivalente.
Quais camadas devo direcionar com LoRA?
As camadas de projeção de atenção (q_proj e v_proj) são os alvos mais comuns e funcionam bem na maioria das tarefas. Incluir também k_proj, o_proje as camadas da MLP (gate_proj, up_proj, down_proj) aumenta a capacidade, ao custo de maior consumo de VRAM e tempo ligeiramente maior de treinamento. Se a VRAM for limitada, comece apenas com as projeções q e v.
QLoRA produz um modelo pior do que LoRA completo?
Para a maioria dos ajustes finos voltados a tarefas específicas, a diferença é desprezível. Benchmarks publicados mostram QLoRA dentro de 1–2 pontos percentuais do LoRA completo em avaliações-padrão. Essa lacuna pode aumentar em tarefas complexas de raciocínio com conjuntos de dados muito pequenos, pois o ruído introduzido pela quantização se acumula quando há pouco sinal útil. Se a precisão for crítica e você dispuser de VRAM suficiente, prefira LoRA sobre um modelo base em bf16.
Como avaliar se meu ajuste fino realmente ajudou?
Reserve 10–20% dos seus dados como conjunto de validação e acompanhe a perda de validação durante o treinamento. Interrompa o treinamento quando a perda de validação deixar de melhorar (early stopping). Em seguida, realize avaliações específicas para a tarefa: para classificação, meça a acurácia em exemplos reservados; para geração, utilize revisão humana ou uma configuração de LLM como juiz em 50–100 exemplos. Uma queda na perda de validação que não se traduz em melhor desempenho na tarefa indica uma incompatibilidade de distribuição entre seus dados de treinamento e as entradas reais.
