Checkpoint tegenover LoRA: wat is het verschil?
Een modelcheckpoint legt de modelstatus op een bepaald moment vast; in gemeenschappen rond beeldgeneratie betekent ‘checkpoint’ vaak een laadbare set volledige modelgewichten. Een LoRA bewaart een veel kleinere geleerde update die op een compatibel basismodel wordt toegepast. Het checkpoint kan zelfstandig in de doelpipeline werken; de LoRA bevat die basis niet.

‘Checkpoint’ heeft twee verwante betekenissen
Tijdens training is een checkpoint een opgeslagen status van waaruit werk kan worden geëvalueerd of hervat. Het kan modelgewichten, optimizerstatus, schedulerstatus, de status van de generator voor willekeurige getallen en trainingsmetadata omvatten. Een inferentiecheckpoint is vaak een slankere export met de gewichten en configuratie die nodig zijn om een model voor gebruik te laden.
In gemeenschappen rond Stable Diffusion is ‘checkpoint’ ook een afkorting voor een hoofdmodelbestand dat in een UI wordt geselecteerd. Dit garandeert niet dat elke afhankelijkheid is ingebed. Een pipeline kan nog steeds een VAE, tekstencoder, tokenizer of configuratie vereisen die door de toepassing of het bijbehorende pakket wordt geleverd. Definieer ‘volledig’ altijd ten opzichte van de loader die je wilt herstellen.
Een LoRA is een geleerde update, geen tweede volledig model
Low-Rank Adaptation houdt de voorgetrainde gewichten bevroren en leert een low-rank update voor geselecteerde lagen. Bij inferentie kan een framework die update dynamisch op de basis toepassen of in een afgeleide kopie integreren. De adapter is klein omdat hij de update bewaart — niet omdat hij in het geheim elk basisgewicht comprimeert.
Deze afhankelijkheid is het centrale verschil tussen checkpoint en LoRA. Van een LoRA met portretstijl die voor één Stable Diffusion-familie is getraind, mag je niet aannemen dat deze met een andere architectuur werkt. Een taalmodeladapter hangt evenzeer af van het basismodel en de doelmodules die in de configuratie zijn beschreven.
Praktische vergelijking
| Vraag | Modelcheckpoint | LoRA |
|---|---|---|
| Wat het opslaat | Brede modelstatus; soms aanvullende trainingsstatus | Low-rank adaptergewichten en configuratie |
| Kan het zelfstandig draaien? | Vaak laadbaar als hoofdmodel in de bedoelde pipeline | Nee; het heeft een compatibele basis en loader nodig |
| Typisch gebruik | Basismodel, volledige finetune, mijlpaal of hervattingspunt | Efficiënte specialisatie, aanpassing van stijl, onderwerp of taak |
| Opslag | Doorgaans veel groter omdat het veel meer status vertegenwoordigt | Doorgaans veel kleiner omdat alleen geselecteerde updates worden geleerd |
| Herstelvraag | Heb ik het volledige pakket of de trainingsstatus die ik nodig heb? | Heb ik de exacte compatibele basis, adapterconfiguratie en gewichten? |
Maakt het samenvoegen van een LoRA er een checkpoint van?
Een adapter in een basis integreren of ermee samenvoegen levert afgeleide gewichten op. Een tool kan die gewichten opslaan in een bestand dat doorgaans een checkpoint wordt genoemd, maar die uitvoer is niet de oorspronkelijke basis en behoudt niet noodzakelijkerwijs een zuivere, omkeerbare scheiding tussen basis en adapter. Zwevendekommabewerkingen, dtype-conversie en exportkeuzes kunnen het resultaat allemaal beïnvloeden.
Behoud de niet-geïntegreerde adapter en exacte basis wanneer je de sterkte wilt wijzigen, adapters wilt combineren of de samenvoeging wilt reproduceren. Behoud ook het samengevoegde artefact wanneer juist dat deploymentbestand operationeel belangrijk is. Verwijder de bronnen niet alleen omdat één samengevoegd bestand eenmaal succesvol is geladen.
Wat je tijdens finetuning bewaart
Bij een actieve run zijn tussentijdse checkpoints nuttig voor evaluatie en herstel na een onderbreking. Behoud na voltooiing van de run de mijlpalen die een echte vraag beantwoorden: de gekozen uiteindelijke adapter, een of meer verdedigbare vergelijkingscheckpoints, configuratie, trainingscode of -opdracht, datasetreferentie en evaluatierecord. De gids over LoRA-trainingscheckpoints behandelt dit als een reproduceerbaarheidsbeslissing in plaats van een algemeen ‘alles bewaren’.
Een uiteindelijke adapter is geen hervatbare trainingsstatus. Geëxporteerde LoRA-gewichten kunnen voldoende zijn voor inferentie terwijl de status van optimizer en scheduler die nodig is om training exact voort te zetten, ontbreekt.
Archiveer families, geen geïsoleerde bestandsnamen
Een nuttige LoRA-familie omvat voldoende context om de compatibele basis te identificeren en verkrijgen. Wanneer de basis zeldzaam, privé of lokaal gewijzigd is, bewaar je haar samen met de adapter. Een checkpointfamilie kan begeleidende onderdelen omvatten die de runtime tijdens de eerste laadbewerking ongemerkt leverde.
Tensor Archive helpt geselecteerde lokale tensors als verwante familie te behouden en verifiëren. Het gokt geen compatibiliteit op basis van een bestandsnaam, reconstrueert geen ontbrekende trainingsstatus en maakt van een LoRA geen zelfstandig basismodel.
Ga verder met het artefact dat je hebt
Als de adapterextensie het verwarrende deel is, lees dan wat een LoRA-bestand bevat. Als je een trainingsmethode kiest, gebruik dan LoRA tegenover QLoRA. Als opslagdruk de vraag veroorzaakt, bekijk dan hoe je schijfruimte vrijmaakt zonder LoRA-gewichten te wijzigen.
Bronnen
- LoRA: Low-Rank Adaptation of Large Language Models — de oorspronkelijke methode en het ontwerp met bevroren basis en low-rank update.
- Hugging Face PEFT: LoRA — huidige adapterconfiguratie en implementatie van doelmodules.
- Checkpointindeling van Hugging Face PEFT — adaptergewichten, configuratie en afhankelijkheid van het basismodel.
- Diffusers: adapters laden — LoRA-adapters laden, uit het geheugen halen en integreren in diffusiepipelines.