Configurações de treino LoRA: o que funciona e o que não
Quais configurações de LoRA funcionam de fato e como testá-las você mesmo.
On this page
- TL;DR
- Configurações LoRA confirmadas pela documentação
- Configurações que não podem ser verificadas
- A alegação sobre imagens de regularização
- Corte manual vs. bucketing por aspect ratio
- WD14 tagging e edição de tags
- Como rodar sua própria comparação controlada
- Erros e correções comuns
- Perguntas frequentes
- Sources
Configurações de treino LoRA: o que funciona e o que não
TL;DR
- Corte manual em vez de bucketing é uma escolha de fluxo de trabalho, não uma técnica comprovada. As duas opções existem nas ferramentas; não há comparação controlada.
- Remover imagens de regularização geradas automaticamente ajudou um usuário, mas não há teste A/B que sustente isso. O mecanismo é plausível, mas continua sendo uma única observação.
- Poucas repetições com muitos epochs (5/50) vs. muitas repetições com poucos epochs (10/20) é uma troca não testada. As docs não prescrevem nenhuma das duas.
- Rank 64 com alpha 32 segue a regra documentada de alpha ≈ 0,5 × dim, mas não há evidência de que essa combinação supere as alternativas.
- "15–20 minutos em RTX 3080" não pode ser verificado de forma independente — depende do tamanho do dataset, do tamanho do lote e do checkpoint.
Configurações LoRA confirmadas pela documentação
Várias configurações da comunidade se alinham com a documentação oficial do Kohya_ss sd-scripts [1,2]. As alegações vêm de posts do Civitai: o guia de treino LoRA de doublerig e a proposta de laboratórios de treino da TecnoIA.
| Configuração | Alegação da comunidade | Padrão documentado / faixa | Veredito | Source |
|---|---|---|---|---|
| Taxa de aprendizado | 0,0001 para U-Net e codificador de texto | 1e-4 como ponto de partida comum (1e-4 a 1e-3) | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| Agendador de LR | cosine with restarts | cosine_with_restarts é opção suportada | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| Precisão mista | bf16 em RTX série 30 | bf16 e fp16 são suportados; bf16 é preferencial se a GPU suportar | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| Salvar a cada N epochs | 1 | --save_every_n_epochs N é documentado | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| MaxTrainEpochs vs. maxTrainSteps | Epoch tem precedência | Se max_train_epochs for definido, ele sobrepõe max_train_steps | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| Alpha ≈ metade de dim | alpha 32 com rank 64 | "geralmente recomendado definir em cerca de metade do valor de network_dim" | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| Faixa de network dim | Rank 64 usado | "Valores entre 4 e 128 são comumente usados" | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
| Network dim SDXL | N/A na fonte | 32 ou 64 são frequentemente testados para SDXL | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network_advanced.md |
| Taxa de aprendizado SDXL | N/A na fonte | 1e-4 ~ 4e-5 para U-Net, 1e-5 ~ 2e-5 para codificadores de texto | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network_advanced.md |
| Gradient checkpointing | Não está na fonte | "reduz significativamente o uso de memória, mas diminui um pouco a velocidade" | Confirmado [1] | https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md |
Nota de terminologia: a fonte da comunidade escreve "Koya_ss". O nome correto é Kohya_ss (kohya-ss/sd-scripts) [1] — uma grafia errada, não uma ferramenta diferente.
Configurações que não podem ser verificadas
Essas configurações específicas aparecem apenas como recomendações pessoais, sem corroboração independente:
- Rank 64 / alpha 32 com cosine_with_restarts e 12 ciclos de LR — cada componente é documentado, mas não há teste controlado comparando isso com alternativas como rank 32 com LR constante.
- 5 repetições / 50 epochs vs. 10 repetições / 20 epochs — a autocorreção do autor ("Edit 7-19") é uma única observação, não uma descoberta replicada.
- "LoRA completo em 15–20 minutos em RTX 3080" — depende do tamanho do dataset (225 e 79 imagens na fonte), do tamanho do lote e do checkpoint. Não existe benchmark.
Trate essas opções como pontos de partida para seus próprios testes, não como recomendações baseadas em evidências.
A alegação sobre imagens de regularização
A alegação mais marcante: remover 2.500 imagens de regularização geradas automaticamente melhorou a qualidade da LoRA (No Need LoRA, Kisaku_KK77). O autor relata ter passado de "resultados OK a ruins" para "muito bons" depois de descartá-las.
O mecanismo é plausível: imagens geradas automaticamente e legendadas a partir do modelo de origem podem criar um laço de feedback em que a LoRA reproduz os vieses do modelo de origem em vez de aprender o conceito do dataset — um risco conhecido de ajuste fino.
Mas foi não controlado. O autor não comparou com/sem lado a lado, nem isolou as imagens de regularização como única variável (a curadoria do dataset, o corte e a edição de tags mudaram ao mesmo tempo). Um teste controlado treinaria duas LoRAs com datasets idênticos, exceto pelas imagens de regularização, e avaliaria às cegas.
Corte manual vs. bucketing por aspect ratio
O autor abandonou o bucketing e cortou manualmente para 512×512 usando Inbac [3], citando controle sobre a composição e um treino mais suave.
O Kohya_ss suporta as duas formas via enable_bucket no TOML do dataset [1]. O bucketing agrupa por aspect ratio para evitar distorção — crítico para imagens não quadradas. O corte manual dá controle no nível do quadro, mas descarta a diversidade de aspect ratio.
Não existe comparação controlada. Escolha com base nos seus dados: se as imagens forem quase quadradas e curadas, o corte manual funciona. Se os aspect ratios variarem, o bucketing evita cortes agressivos.
WD14 tagging e edição de tags
O fluxo usa a tagger WD14 (no Automatic1111 e no sd-scripts) para legendar automaticamente, depois o BooruDatasetTagManager [4,5] para editar. O autor remove tags de cor dos olhos e de cor do cabelo porque a tagger "erra muito."
O propósito documentado do BooruDatasetTagManager é um editor de tags para datasets de hypernetwork, embedding e LoRA, com edição em lote e auto-tagging via AiApiServer [4]. Ele suporta tags ponderadas, tradução e autocompletar no estilo booru [4].
Se os erros de cor de olhos/cabelo do WD14 são comuns o suficiente para justificar remoção rotineira não foi testado. A prática é uma heurística razoável, mas pode descartar informação semântica que ajuda a distinguir assuntos parecidos.
Como rodar sua própria comparação controlada
Issole uma variável por vez:
- Escolha um modelo base fixo. (sd-legacy/stable-diffusion-v1-5 no HuggingFace é amplamente usado.)
- Prepare dois datasets idênticos. Mesmas imagens, legendas e divisões de treino/teste. Só a variável testada difere.
- Registre cada run. Salve saídas por epoch, por prompt, com seeds fixos. O Kohya_ss suporta --save_state para isso.
- Avalie às cegas. Uma segunda pessoa (ou você mesmo após um atraso) ranqueia as saídas sem saber quais configurações as produziram.
- Meça, não chute. Use prompts de avaliação consistentes e compare lado a lado.
Todas as configurações mencionadas pela comunidade (network_dim, network_alpha, learning_rate, lr_scheduler, mixed_precision, save_every_n_epochs) são argumentos de linha de comando do Kohya_ss [1], o que torna as trocas de uma única variável simples. Veja nosso guia de treino LoRA Kohya_ss para uma referência completa de flags.
Erros e correções comuns
| Erro | Causa | Correção |
|---|---|---|
| "Koya_ss" em vez de Kohya_ss | O repositório é kohya-ss/sd-scripts [1] | Clone kohya-ss/sd-scripts, não um fork com nome semelhante |
| Esperar 20 epochs como "o número certo" | O autor diz que não usa 20, mas queria épocas suficientes para encontrar o ponto ideal (No Need LoRA) | Rode mais epochs, salve cada um e avalie qual checkpoint é o melhor |
| Usar fp16 em RTX série 30 (Ampere) | bf16 e fp16 são suportados; bf16 é preferencial se a GPU suportar [1] | Use bf16 quando disponível; fp16 é para hardware mais antigo |
| Deixar imagens de regularização no dataset | O autor descobriu que pioraram os resultados (No Need LoRA) | Teste com e sem imagens geradas automaticamente, avaliando às cegas |
Perguntas frequentes
Qual é o melhor network rank para treino LoRA? Não existe um melhor universal. Ranks de 4 a 128 são comuns; as docs usam 16 como padrão [1]. Ranks mais altos aumentam expressividade, tamanho do arquivo e custo computacional. Rank 64 serve para conceitos complexos, mas produz arquivos maiores.
Devo usar cosine_with_restarts ou taxa de aprendizado constante? Ambos são válidos [1]. Cosine_with_restarts eleva periodicamente a LR (num_cycles controla as reinicializações [2]), o que pode ajudar a escapar de mínimos locais em runs longos. A constante é mais simples e eficaz para muitos fluxos de trabalho.
Quantas repetições preciso? A fonte usou 10 repetições para 225 imagens e 20 para 79, sugerindo depois 5/50 como alternativa. Não há evidência a favor de nenhuma. As docs não prescrevem contagens de repetição. Comece com o que cabe no seu orçamento e avalie a qualidade da saída em relação à contagem de steps. Alegações do post No Need LoRA.
Posso usar SD v1.5 para treinar LoRA e aplicar a LoRA em outros modelos? O autor relata ter treinado em sd-legacy/stable-diffusion-v1-5 e testado com Photon V1 e Reliberate V10 (ver No Need LoRA). A transferibilidade de LoRA entre modelos não está documentada em nenhuma fonte verificada. Os resultados variam conforme a arquitetura de destino e a compatibilidade do checkpoint base. Veja nosso guia de compatibilidade LoRA entre modelos para mais.
Que precisão mista devo usar? Use bf16 se sua GPU suportar (Ampere e mais novas); fp16 em hardware mais antigo [1]. bf16 reduz VRAM e pode melhorar a velocidade em GPUs suportadas. Volte para fp16 se bf16 for instável.
O corte manual é melhor que o bucketing por aspect ratio? Nenhum é sistematicamente melhor [1]. O bucketing evita distorção em imagens não quadradas; o corte manual dá controle no nível do quadro. Ambos são suportados.
Como sei qual epoch é o ponto ideal? Salve a cada epoch (save_every_n_epochs=1) e avalie os epochs diferentes. O autor recomenda começar pelo epoch 10 e seguir em frente ou voltar (No Need LoRA).
Qual é a diferença entre network_dim e network_alpha? Network_dim é o rank da LoRA — a dimensionalidade da matriz adaptadora. Network_alpha escala os pesos da LoRA durante o treino; as docs recomendam ~metade de network_dim [1]. Uma LoRA de rank 64 com alpha 32 treina com metade da LR efetiva de rank 64 com alpha 64.
Sources
- https://civitai.com/articles/1161 — Guia de treino LoRA de doublerig (Jul 2023)
- https://civitai.com/articles/1019 — Proposta de laboratórios de treino organizados da TecnoIA (Jul 2023)
- https://civitai.com/articles/11684 — Post No Need LoRA de Kisaku_KK77 (Fev 2025)
- https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md — Docs oficiais de treino LoRA do Kohya_ss; confirma network_dim, network_alpha, learning_rate, lr_scheduler, mixed_precision
- https://github.com/weclaw1/inbac — Inbac: cortador interativo de imagens em lote; confirma instalação pip, seleção de aspect-ratio, resize
- https://github.com/starik222/BooruDatasetTagManager — BooruDatasetTagManager; confirma edição de tags de dataset, auto-tagging, fluxos multi-imagem
- https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network_advanced.md — Docs avançadas do Kohya_ss; confirma orientação network_dim SDXL e num_cycles do agendador LR
- https://huggingface.co/sd-legacy/stable-diffusion-v1-5 — Model card do sd-legacy/stable-diffusion-v1-5 no HuggingFace; confirma checkpoint, dados de treino (595k steps a 512×512 no laion-aesthetics v2 5+), frameworks compatíveis
- https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Features#wd14-tagger — Wiki do WebUI; confirma tagger WD14 como recurso de auto-tagging