ArtificialGuyBR

Home / Blog / Training LoRAs

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.

6 sources cited Training LoRAs

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çãoAlegação da comunidadePadrão documentado / faixaVereditoSource
Taxa de aprendizado0,0001 para U-Net e codificador de texto1e-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 LRcosine with restartscosine_with_restarts é opção suportadaConfirmado [1]https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md
Precisão mistabf16 em RTX série 30bf16 e fp16 são suportados; bf16 é preferencial se a GPU suportarConfirmado [1]https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md
Salvar a cada N epochs1--save_every_n_epochs N é documentadoConfirmado [1]https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md
MaxTrainEpochs vs. maxTrainStepsEpoch tem precedênciaSe max_train_epochs for definido, ele sobrepõe max_train_stepsConfirmado [1]https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md
Alpha ≈ metade de dimalpha 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 dimRank 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 SDXLN/A na fonte32 ou 64 são frequentemente testados para SDXLConfirmado [1]https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network_advanced.md
Taxa de aprendizado SDXLN/A na fonte1e-4 ~ 4e-5 para U-Net, 1e-5 ~ 2e-5 para codificadores de textoConfirmado [1]https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network_advanced.md
Gradient checkpointingNã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:

  1. Escolha um modelo base fixo. (sd-legacy/stable-diffusion-v1-5 no HuggingFace é amplamente usado.)
  2. Prepare dois datasets idênticos. Mesmas imagens, legendas e divisões de treino/teste. Só a variável testada difere.
  3. Registre cada run. Salve saídas por epoch, por prompt, com seeds fixos. O Kohya_ss suporta --save_state para isso.
  4. Avalie às cegas. Uma segunda pessoa (ou você mesmo após um atraso) ranqueia as saídas sem saber quais configurações as produziram.
  5. 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

ErroCausaCorreção
"Koya_ss" em vez de Kohya_ssO 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 datasetO 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