Checkpoint vs. LoRA: vad är skillnaden?
En modellcheckpunkt sparar modellens tillstånd vid en viss tidpunkt; inom bildgenereringsgemenskaper betyder "checkpoint" ofta en laddbar uppsättning med fulla modellvikter. En LoRA sparar en mycket mindre lärd uppdatering som tillämpas på en kompatibel basmodell. Checkpunkten kan fungera ensam i målflödet; LoRA innehåller inte den basen.
"Checkpoint" har två relaterade betydelser
Under träning är en kontrollpunkt ett sparat tillstånd från vilket arbetet kan utvärderas eller återupptas. Den kan innehålla modellvikter, optimerarens tillstånd, schemaläggarens tillstånd, slumptalstillstånd och träningsmetadata. En kontrollpunkt för inferens är ofta en mindre export med de vikter och den konfiguration som krävs för att läsa in modellen för användning.
I Stable Diffusion-gemenskaper är "checkpoint" också kortform för en huvudmodellfil som har valts i ett gränssnitt. Det garanterar inte att alla beroenden är inbäddade. En pipeline kan fortfarande kräva en VAE, textkodare, tokenisering eller konfiguration som tillhandahålls av programvaran eller medföljande paket. Definiera alltid "fullständig" i förhållande till laddaren du avsiktar att återställa.
En LoRA är en inlärd uppdatering, inte en andra fullständig modell
Low-Rank Adaptation håller de förtillverkade vikterna oförändrade och lär sig en låg-rang-uppdatering för valda lager. Vid inferens kan ett ramverk tillämpa den här uppdateringen dynamiskt på den grundläggande modellen eller fosa den in i en härledd kopia. Adaptern är liten eftersom den sparar uppdateringen – inte eftersom den dolt komprimerar varje grundläggande vikt.
Detta beroende är den centrala skillnaden mellan checkpoint och LoRA. En porträttstil-LoRA som tränats för en Stable Diffusion-familj kan inte antas fungera med en annan arkitektur. En språkmodelladapter beror likaså på den basmodell och målmoduler som beskrivs i dess konfiguration.
Praktisk jämförelse
| Fråga | Kontrollpunkt | LoRA |
|---|---|---|
| Vad den lagrar | Bred modellstatus; ibland ytterligare träningsstatus | Lågrankstilläggsvärden och konfiguration |
| Kan den köras ensam? | Ofta laddbar som huvudmodell i sin avsedda pipeline | Nej; det kräver en kompatibel bas och laddare |
| Vanlig användning | Basmodell, full finjustering, målställe eller återupptagningspunkt | Effektiv specialisering, stil, ämne eller uppgiftsanpassning |
| Lagring | Vanligtvis mycket större eftersom det representerar mycket mer tillstånd | Vanligtvis mycket mindre eftersom endast valda uppdateringar lärs in. |
| Återställningsfråga | Har jag det fulla paketet eller träningsstatus som behöver? | Har jag den exakt kompatibla basen, adapterkonfigurationen och viktingarna? |
För att smälta en LoRA till en kontrollpunkt?
Att foga en adapter till en bas skapar härledda vikter. Ett verktyg kan spara dessa vikter i en fil som vanligtvis kallas en checkpoint, men det utgående resultatet är inte den ursprungliga basen och garanterar inte en ren, omvändbar separation mellan bas och adapter. Flyttalshantering, datatypskonvertering och val vid export kan alla påverka resultatet.
Håll kvar den osammanslagna tilläggsenheten och den exakta basen när du vill ändra styrka, kombinera tillägg eller återuppta sammanslagningen. Håll också kvar den sammanslagna produkten när det exakta distributionsfilen är operationellt viktig. Ta inte bort källorna bara därför att en sammanslagen fil laddades framgångsrikt en gång.
Vad som ska behållas vid finjustering
Under en aktiv körning är mellanliggande kontrollpunkter användbara för utvärdering och återhämtning efter avbrott. När körningen är klar bör du behålla de milstolpar som besvarar en verklig fråga: den valda slutliga adaptern, en eller flera försvarbara jämförelsekontrollpunkter, konfigurationen, träningskoden eller kommandot, en hänvisning till datauppsättningen och utvärderingsprotokollet. Guiden om kontrollpunkter vid LoRA-träning behandlar detta som ett beslut om reproducerbarhet, inte som en generell uppmaning att "behålla allt".
Ett slutligt anpassningslager är inte en återupptagbar träningsstatus. De exporterade LoRA-vikterna kan vara tillräckliga för inferens, medan optimerare och schemaläggarens tillstånd, som krävs för att fortsätta träna exakt, kan utelämnas.
Arkivera familjer, inte filnamn ensamma
En användbar LoRA-familj innehåller tillräckligt med sammanhang för att kunna identifiera och hämta den kompatibla basen. När basen är sällsynt, privat eller lokalt modifierad, behåll den tillsammans med adaptern. En checkpointsfamilj kan innehålla kompanjonskomponenter som körningen automatiskt laddade vid första inlägget.
Tensor Archive hjälper att behålla och verifiera valda lokala tensorer som en relaterad familj. Det gissar inte kompatibilitet från ett filnamn, återställer bristande träningsstatus eller gör en LoRA till en självständig basmodell.
Fortsätt med det artefakt du har.
Om det är den anpassningsutökning som är förvirrande, läs vad ett LoRA-fil innehåller. Om du väljer en träningsmetod, använd LoRA mot QLoRA. Om lagringstryck styr frågan, se hur du fria diskutrymme utan att ändra LoRA-vikter.
Källor
- LoRA: Low-Rank Adaptation of Large Language Models — den ursprungliga metoden och design med fast bas/låg-ranguppdatering.
- Hugging Face PEFT: LoRA — aktuell anpassningskonfiguration och målmodulsimplementering.
- Hugging Face PEFT-kontrollpunktsformat — anpassningsvikt, konfiguration och basmodellberoende.
- Diffusers: ladda anpassningar – ladda, avlägg och foga ihop LoRA-anpassningar med diffusionspipar.