Checkpoint vs. LoRA: qual é a diferença?
Um checkpoint de modelo regista o estado do modelo num dado momento; nas comunidades de geração de imagens, «checkpoint» significa muitas vezes um conjunto carregável de pesos completos do modelo. Uma LoRA armazena uma atualização aprendida muito menor que é aplicada a um modelo base compatível. O checkpoint pode funcionar sozinho no pipeline de destino; a LoRA não contém essa base.
«Checkpoint» tem dois significados relacionados
Durante o treino, um checkpoint é um estado guardado a partir do qual o trabalho pode ser avaliado ou retomado. Pode incluir pesos do modelo, estado do otimizador, estado do agendador, estado do gerador de números aleatórios e metadados de treino. Um checkpoint de inferência é frequentemente uma exportação mais pequena que contém os pesos e a configuração necessários para carregar um modelo para utilização.
Nas comunidades Stable Diffusion, «checkpoint» também é uma forma abreviada de designar um ficheiro principal de modelo selecionado numa interface. Isso não garante que todas as dependências estejam incorporadas. Um pipeline pode continuar a exigir um VAE, codificador de texto, tokenizador ou configuração fornecidos pela aplicação ou pelo pacote complementar. Defina sempre «completo» relativamente ao carregador que pretende recuperar.
Uma LoRA é uma atualização aprendida, não um segundo modelo completo
A Low-Rank Adaptation mantém os pesos pré-treinados congelados e aprende uma atualização de baixo posto para camadas selecionadas. Durante a inferência, um framework pode aplicar essa atualização dinamicamente à base ou fundi-la numa cópia derivada. O adaptador é pequeno porque armazena a atualização — não porque comprima secretamente todos os pesos da base.
Esta dependência é a distinção central entre checkpoint e LoRA. Não se pode presumir que uma LoRA de estilo de retrato, treinada para uma família Stable Diffusion, funcione com outra arquitetura. Da mesma forma, um adaptador de modelos de linguagem depende do modelo base e dos módulos alvo descritos pela respetiva configuração.
Comparação prática
| Pergunta | Checkpoint de modelo | LoRA |
|---|---|---|
| O que armazena | Estado geral do modelo; por vezes, estado adicional de treino | Pesos e configuração do adaptador de baixo posto |
| Consegue funcionar sozinho? | Frequentemente carregável como modelo principal no pipeline a que se destina | Não; precisa de uma base e de um carregador compatíveis |
| Utilização típica | Modelo base, ajuste fino completo, marco ou ponto de retoma | Especialização eficiente, estilo, tema ou adaptação a uma tarefa |
| Armazenamento | Normalmente muito maior, porque representa muito mais estado | Normalmente muito menor, porque apenas se aprendem atualizações selecionadas |
| Pergunta de recuperação | Tenho o pacote completo ou o estado de treino de que preciso? | Tenho a base compatível exata, a configuração do adaptador e os pesos? |
Fundir uma LoRA transforma-a num checkpoint?
Fundir ou incorporar um adaptador numa base produz pesos derivados. Uma ferramenta pode guardar esses pesos num ficheiro habitualmente chamado checkpoint, mas esse resultado não é a base original nem preserva necessariamente uma separação clara e reversível entre base e adaptador. As operações de vírgula flutuante, a conversão de dtype e as opções de exportação podem afetar o resultado.
Conserve o adaptador não fundido e a base exata quando quiser alterar a intensidade, combinar adaptadores ou reproduzir a fusão. Conserve também o artefacto fundido quando esse ficheiro de implementação exato for importante para as operações. Não elimine as fontes apenas porque um ficheiro fundido foi carregado com êxito uma vez.
O que conservar durante o ajuste fino
Numa execução ativa, os checkpoints intermédios são úteis para avaliação e recuperação após uma interrupção. Quando a execução terminar, conserve os marcos que respondem a uma pergunta real: o adaptador final escolhido, um ou mais checkpoints de comparação justificáveis, a configuração, o código ou comando de treino, a referência do conjunto de dados e o registo de avaliação. O guia de checkpoints de treino de LoRA trata esta questão como uma decisão de reprodutibilidade, não como a regra geral «conservar tudo».
Um adaptador final não é um estado de treino retomável. Os pesos LoRA exportados podem bastar para inferência e, simultaneamente, omitir os estados do otimizador e do agendador necessários para continuar o treino exatamente.
Arquive famílias, não nomes de ficheiros isolados
Uma família LoRA útil inclui contexto suficiente para identificar e obter a base compatível. Quando a base é rara, privada ou modificada localmente, conserve-a junto do adaptador. Uma família de checkpoints pode incluir componentes complementares que o ambiente de execução forneceu silenciosamente durante o primeiro carregamento.
O Tensor Archive ajuda a conservar e verificar tensores locais selecionados como uma família relacionada. Não adivinha a compatibilidade através do nome de um ficheiro, não reconstrói um estado de treino em falta nem transforma uma LoRA num modelo base autónomo.
Continue com o artefacto que possui
Se a extensão do adaptador for a parte confusa, leia o que contém um ficheiro LoRA. Se estiver a escolher um método de treino, consulte LoRA vs. QLoRA. Se a pressão sobre o armazenamento motivou a pergunta, veja como libertar espaço em disco sem alterar os pesos LoRA.
Fontes
- LoRA: Low-Rank Adaptation of Large Language Models — o método original e o desenho de base congelada e atualização de baixo posto.
- Hugging Face PEFT: LoRA — configuração atual do adaptador e implementação dos módulos alvo.
- Formato de checkpoint PEFT do Hugging Face — pesos do adaptador, configuração e dependência do modelo base.
- Diffusers: carregar adaptadores — carregamento, remoção da memória e fusão de adaptadores LoRA com pipelines de difusão.