Qwen-Image-2.1 LoRA: Vilka adaptrar finns, vad träning av en innebär och vad licensen faktiskt säger

Det finns ett verkligt ekosystem av adaptrar för low-rank-adaptation (LoRA) för Qwen-Image-2.1, leverantörens enhetliga bildmodell för både generering och redigering, och det finns nästan ingen dokumentation om detta från leverantörens sida. Den här sidan är det stående svaret på fyra frågor som en läsare skriver in tillsammans: tillverkar någon faktiskt adaptrar för den här modellen, var finns de, vad krävs för att träna en, och vad tillåter licensen att du gör med resultatet. Det är inte en lanseringsartikel. Qwen-Image-2.1 släpptes med öppen källkod den 20 september 2026 och dess accelererade syskon Qwen-Image-2.1-Turbo följde den 9 oktober 2026; båda datumen finns här bara för att identifiera vilka checkpoints den här sidan handlar om, inte för att rapportera något.

Den korta versionen: adaptrar finns i låga hundratal, de är mestadels karaktärs- och stilarbeten publicerade av enskilda utövare, att träna en dokumenteras från början till slut av minst tre tredjepartsverktygskedjor med publicerade minnesmätningar, och licensen — som inte är Apache för den här generationen av bildmodellerna — upprepar en icke-kommersiell begränsning på derivatet som många av adaptrarna själva inte för vidare.

Två meningar om vad en LoRA är, och sedan modellen

En LoRA är en liten uppsättning viktdeltan av låg rang som läggs till en fryst bascheckpoint vid laddningstillfället och adresseras till specifika moduler med namn; den är inte en modell, den är en patch som ändrar hur en befintlig modell beter sig. Eftersom deltana tränas mot specifika vikter är en adapter bunden till den checkpoint den tränades på, på ett sätt som en konfigurationsflagga inte kan åtgärda.

Den kopplingen är hela anledningen till att den här sidan specifikt handlar om Qwen-Image-2.1 snarare än om LoRAs. Checkpointen är en 32-lagrig single-stream-diffusionstransformer med 7B parametrar i sin visuella genereringskomponent, en Qwen3-VL 8B-textkodare och en 64-kanalig RGBA-VAE som arbetar med 16× rumslig komprimering – alla siffror från leverantörens eget modellkort och repo, lästa den 13 oktober 2026. Den ställer in sitt samplingsschema vid anropstillfället, med 40 inferenssteg i kortets egna exempel. Ingen av dessa detaljer är ovidkommande för adaptrar: arkitekturen avgör vad en fil kan adressera, och schemat avgör vad en adapter som tränats vid en annan parametrisering ombeds att göra.

Vad finns det för den här modellen, och hur räknar man det ärligt?

Siffrorna nedan kommer från Hugging Face-API:t och Civitai-API:t, båda avlästa den 13 oktober 2026, och frågan är viktig nog att nämna, eftersom samma fråga ger helt olika svar beroende på hur man ställer den.

• Repositorier på Hugging Face som anger Qwen-Image-2.1 som sin basmodell: 323.

• Av dessa är det lora repositorier som också har taggen 115.

• Adaptrar på Civitai som matchar ett basmodellsfilter för "Qwen 2.1" med typen inställd på LoRA: 106. En tidigare genomgång samma dag räknade 105; filtret är live och antalet ändras, så behandla det som en avläsning snarare än en totalsumma.

Båda siffrorna är golv, inte folkräkningar. Hugging Face-taggen sätts av uppladdaren, så en adapter vars författare inte har taggat den är osynlig för den sökningen; antalet basmodeller är större än antalet LoRA just eftersom det också fångar kvantiseringar, sammanslagningar och ompaketeringar. På Civitai är gapet mellan metoderna tydligt: en fritextsökning efter "qwen image 2.1" returnerar 994 unika modeller, och de flesta av dem är inte alls den här checkpointens adaptrar — samma resultatuppsättning domineras av arbetsflödesinlägg och av filer vars deklarerade basmodell är en helt annan bildgenerering. Filtrera på basmodellen, inte i sökrutan.

Båda sajterna är där detta ekosystem lever, och det är det enda påståendet som görs om någon av dem: Hugging Face är där träningsposterna och dataseten publiceras, Civitai är där de konsumentinriktade adapterarna och ComfyUI-arbetsflödena runt dem samlas, och ingendera är en kvalitetssignal. En fil på endera kan vara ett originalverk av tränat arbete eller en kopia av någon annans.

Att skilja en originaladapter från en ompaketerad

Detta går att kontrollera, och kontrollen tar ungefär en minut. Ta två repositorier som ser ut som samma adapter.

akhaliq/Qwen-Image-2.1-Next-Scene-LoRA skapades den 7 oktober 2026. TechnoBaptist/Qwen-Image-2.1-Next-Scene-LoRA skapades den 9 oktober 2026. Deras README-filer är byte-identiska – samma längd, samma MD5 – och de två reponas fillistor matchar över alla 111 poster. Den senare är en kopia av den tidigare, inklusive beskrivning.

Det mindre uppenbara fallet är den partiella kopian. developerjeremylive/Qwen-Image-2.1-Multiple-Angles-LoRA-etheroi innehåller 163 filer. Var och en av de 160 som också finns i akhaliq/Qwen-Image-2.1-Multiple-Angles-LoRA är identisk i storlek, och repot är en strikt delmängd av den senares 344 filer. Det som lämnades kvar är hela benchmarks/-katalogen, exempelrutnäten per checkpoint under samples/, och flera checkpointvarianter. Adaptervikterna finns. Beviset för att adaptern gör vad den säger finns inte.

Så det praktiska testet är inte ”har det ett fint kort”. Det är huruvida kortet bär på de saker som bara kan komma från att ha genomfört rundan:

• Var träningsdatan kom ifrån, med en länk — vinkeladaptern anger sin Objaverse-källa och sin licens, och publicerar de härledda pardatasetten separat.

• Tränaren och hyperparametrarna, på nivån för rang, alfa, inlärningstakt, antal steg och basprecision — tillräckligt för att någon annan ska kunna försöka återskapa den.

• Mellanliggande checkpoints i stället för endast en slutlig fil, så att träningskurvan går att granska i stället för att påstås.

• En utvärdering som inte är författarens skyltfönster, och ett avsnitt om "omfattning och begränsningar" som namnger vad adaptern gör dåligt.

Ett kort med ett triggerord, ett styrkeintervall och en uppsättning fina exempel, och inget annat, är inte bevis för någonting. Det är inte heller bevis för en repack — många ärliga engångsadaptrar dokumenteras så tunt. Det betyder bara att du inte har något att gå på, vilket för en fil som du är på väg att lägga in i en produktionspipeline är den användbara slutsatsen.

Vilken utbildning man faktiskt genomgår

Den ärliga formuleringen först, eftersom gapet här är stort: att publicera en adapter är vanligt, och att träna en är en helt annan sorts åtagande. Det finns tre kostnader och de är alla verkliga.

Bascheckpointen. De tre komponenterna i Qwen-Image-2.1 uppgår till ungefär 33 GB fördelat på transformatorn, textkodaren och VAE — det är summan av arkivets egna publicerade filstorlekar, avlästa den 13 oktober 2026. Det är det som anpassas, och det krymper inte för att du bara tränar en liten patch ovanpå det.

Datan. En LoRA lär sig inte ett koncept från en handfull bilder på det sätt som en prompt gör. De två bäst dokumenterade adaptrarna i detta ekosystem publicerade sina dataset som förstklassiga artefakter: kamerakontrolladaptern tränades på 5 028 vinkelmärkta par i sin första version och 13 328 i sin andra; scenfortsättningsadaptern tränades på 1 144 bildruta-till-bildruta-förloppspar, med bildtexter skrivna av en visionsmodell för varje par. Båda dessa är sammansatta dataset, inte samlingar av fotografier – paren måste genereras, märkas och licensieras innan träningen började, och i ett fall måste källbildmaterialet filtreras ned till tillåtligt licensierade objekt innan det kunde användas över huvud taget.

Beräkningskapaciteten. Det här är delen med publicerade mätningar i stället för vibbar. SimpleTuners egen snabbstart för modellen ger VRAM-förinställningar och, separat, minnes-smoketesterna bakom dem: ett 512px-recept med gradient checkpointing vid varje steg klarade en allokeringsgräns på 24 GiB, medan det toppade på 20,06 GiB allokerat och 21,10 GiB reserverat av PyTorch. Ett recept för flera upplösningar vid 32,49 / 41,21 GiB klarade sig på ett L40S men fick slut på minne under ett tak på 32 GiB. Författarna är tydliga med att dessa är minneskontroller på en begränsad delmängd, inte mätningar av genomströmning eller konvergens, och att de lägre budgetarna simulerades på ett L40S i stället för att köras på deras nominella kort. Läst som publicerat säger de något enkelt: minimikravet för den här modellen är ett 24 GB-kort som endast körs vid 512px, och 48 GB eller mer är där recepten för flera upplösningar som ramverket faktiskt rekommenderar blir tillgängliga.

Tid är den tystare kostnaden, och nästan ingen publicerar den. Det som är offentligt är antalet steg – 2 000 uppdateringar i 24 GB-förinställningen, 4 000 i de större, med validering och checkpointning var 250:e uppdatering – och checkpointantal i låga tusental från adaptrarnas egna träningsloggar. SimpleTuners förinställningstabell anger uppdateringsbudgetar för varje VRAM-nivå och säger rent ut att de är utgångspunkter som bara bör utökas efter att man har granskat checkpointbilderna. Ingen har publicerat väggklockstimmar för en reproducerbar körning, så varje siffra du ser citerad för hur lång tid detta tar är någons grafikkort och någons dataset, inte en specifikation.

Mot det står att verktygsstödet är genuint bra, och detta är den del som förändrades tillräckligt nyligen för att vara värd att tidsbestämma. Leverantören pekar på ModelScopes DiffSynth-Studio, vars repo levererar ett fungerande LoRA-träningsskript för denna checkpoint och, separat, för Turbo-varianten – en enda accelerate launch med rank 32, AdamW vid 1e-4, fem epoker, en maximal pixelbudget på 1 048 576 och gradient checkpointing. SimpleTuners snabbstart är det mest detaljerade offentliga receptet, och den är ovanligt ärlig om sina egna begränsningar. ai-toolkit listar både Qwen-Image-2.1 och Qwen-Image-2.1-Turbo bland sina stödda arkitekturer, och två av adaptrarna som beskrivs ovan uppger att de har tränats med det. Och den 12 oktober 2026 sammanslog musubi-tuner en pull request som lade till stöd för Qwen-Image 2.1, vilket omfattar LoRA-träning, full finjustering, träningsförhandsvisningar och konvertering mellan Diffusers och dess eget LoRA-format; funktionsförfrågan som begärde det, öppnad den 24 september, är fortfarande öppen. Den sammanslagningen är tre dagar före datumet på den här sidan och det är en förändring i verktygsstödet snarare än ett modellsläpp — det betyder att en fjärde tränare blev tillgänglig, inte att något hos modellen förändrades.

Det finns ytterligare en begränsning som fångar dem som har tränat LoRA:er för andra arkitekturer. Den här modellens utdata har ingen alfabrytare. VAE:n arbetar i ett RGBA-pixelrum med fyra kanaler och den fjärde kanalen avkodas som alfa, så transparens skapas av prompten och inget annat – leverantörens egen dokumentation säger att det inte finns någon alfarelaterad styrning någonstans i pipelinen. En adapter som tränats på ogenomskinliga bilder förändrar den fördelning som prompten styr; den har inget separat transparensreglage att falla tillbaka på. Om din pipeline är beroende av utklipp är det en egenskap hos basmodellen du lånar, och det är värt att testa innan du satsar en träningskörning på den.

Vad licensen säger om adaptern du gör

Läs filen, eftersom svaret inte är vad en utgåva som låter tillåtande skulle antyda. Qwen-Image-2.1 släpps under Qwen Research License Agreement daterat den 20 september 2026 – ett dokument på 7 831 byte som har förts oförändrat in i Turbo-repositoriet, vars kopia är byte-identisk. Den är inte Apache 2.0, vilket den tidigare Qwen-Image-serien däremot var.

Den klausul som avgör det mesta av detta är beviljandet. Avsnitt 2(a) ger dig licens att "använda, reproducera, distribuera, kopiera, skapa derivatverk av och göra ändringar i" materialet, och begränsar sedan allt detta: "ENDAST FÖR ICKE-KOMMERSIELLA ÄNDAMÅL". Avsnitt 1(i) definierar icke-kommersiell som "endast för forsknings- eller utvärderingsändamål", vilket är snävare än "icke-vinstdrivande" — det undantar inte intern affärsanvändning. Avsnitt 2(b) säger att kommersiell användning kräver en separat licens, som ska begäras på den adress som avtalet anger. En adapter som tränats på denna checkpoint är ett derivatverk av den, så begränsningen följer med adaptern; den blir inte kommersiellt användbar bara för att du själv har tränat den.

Två saker är värda att notera, eftersom båda går emot vanliga antaganden.

För det första är licensen inte tyst om träning – den behandlar det direkt. Avsnitt 4(b) säger att om du använder materialet eller dess utdata för att "skapa, träna, finjustera eller förbättra en AI-modell som distribueras eller görs tillgänglig", måste du på ett framträdande sätt visa "Built with Qwen" eller "Improved using Qwen" i den relaterade produktdokumentationen. Så finjustering behandlas vid namn, och det medför en märkningsskyldighet snarare än en tillståndsfråga.

För det andra är vidaredistribution uttryckligen tillåten, med vissa villkor. Avsnitt 3 tillåter dig att distribuera derivatverk, i källkods- eller objektkodsform, förutsatt att du ger mottagarna en kopia av avtalet, markerar modifierade filer och behåller en notisfil med texten "Qwen är licensierad under Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. Med ensamrätt." Avsnitt 4(c) förbjuder användning av "Qwen" som primärt namn eller identifierare för ditt derivatverk — beskrivande användning är uttryckligen tillåten. Avsnitt 5(a) bekräftar att du äger dina ändringar, under förutsättning att du följer villkoren. Tvister regleras av kinesisk lag, i domstolarna i Hangzhou.

De är sammanhängande, läsbara skyldigheter. Det obehagliga fyndet är hur ofta ekosystemet inte uppfyller dem. Bland de adaptrar som granskades när den här sidan togs fram finns en – en stegdestillationsadapter för bascheckpointen – som levererar licenstexten och en NOTICE-fil med den obligatoriska attribueringssträngen ordagrant, plus ett licensavsnitt i sitt modellkort som upprepar den icke-kommersiella begränsningen och den kommersiella kontaktuppgiften. Flera andra, inklusive två av de mest nedladdade adaptrarna för kamerakontroll och scenfortsättning, anger apache-2.0 i sin metadata, levererar ingen licensfil alls och innehåller ingen attribueringsnotis. Deras kort gör inte anspråk på Apache-rättigheter till basvikterna; metadatafältet är helt enkelt fel, och det är fältet som ett nedströmsverktyg kommer att läsa. Om du är den som bygger vidare på en adapter bör du själv läsa basmodellens licens i stället för att lita på taggen på adapterns kort – och om du är den som publicerar är rätt paketering inte komplicerad, den måste bara göras med avsikt.

Kompatibilitet, och det enda med "turbo"

En adapter körs på den checkpoint som dess träningspost anger. För de flesta av adaptrarna här är det Qwen-Image-2.1 själv, och det är där de bör laddas. Turbo-checkpointen är en finjustering av samma arkitektur snarare än en annan modell – de två delar sitt modulträd, vilket är anledningen till att en bas-tränad adapter med stor sannolikhet kommer att kunna laddas in på Turbo – men den lagrar sitt eget åttastegssamplingsschema i checkpointen och kör en denoising-bana som adaptern inte har tränats i. Huruvida den kombinationen beter sig korrekt dokumenteras inte av någon, inklusive leverantören.

Det finns också en namnfälla: frasen "turbo LoRA" täcker två motsatta artefakter, en adapter tränad på Turbo-checkpointen och en destillationsadapter som gör om standard-checkpointen till en fåstegsversion. Det är olika filer som gör olika saker. Frågan om bas-checkpoint kontra Turbo, och de två betydelserna av turbo-adaptern, har sin egen sida i den här stammen — Qwen-Image-2.1-Turbo LoRA — och den här sidan kommer inte att bli en andra kopia av den. Om du har Turbo och en adapter som namnger standard-checkpointen, läs den sidan innan du laddar något.

Två angränsande frågor hör också hemma någon annanstans. Kvantiserade checkpoints – GGUF, FP8, INT4 och resten – är ett annat ämne med en annan sida; en LoRA som används i en kvantiserad pipeline är en kompatibilitetsnotis på den sidan, inte ett avsnitt på den här. Och modellen som körs i ett specifikt verktyg är återigen en egen fråga, med sina egna fillistor och sina egna felmoder.

Vad som går sönder, och vad som inte är avgjort

Felrapporterna klustrar i tre orsaker, och var och en av dem har dokumenterats av någon som utförde arbetet i stället för att ha antagits.

En adapter som laddas och inte gör något. Det mest konkreta fallet är en namnkonflikt för nycklar: en adapters eget modellkort säger att dess råa filer i tränarformat använder den tränarens sammanslagna MLP-nyckelnamngivning, som Diffusers ”tyst hoppar över” — laddningen lyckas, inget fel uppstår och adaptern har ingen effekt. Filen fungerar med sin egen laddare och inte med den allmänt använda. Det är en skillnad i fillayout, inte i bascheckpoint, och det är värt att utesluta innan du skyller på något annat.

En adapter som förstör orelaterade prompter. Detta är ett problem med inlärningshastighet och varaktighet, och det finns en mätning: i en publicerad ablation försämrade en körning vid 3e-4 "alla fyra valideringsprompterna allvarligt vid uppdatering 500", där orelaterade motiv – en räv, ett porträtt – förvandlades till det tränade konceptet. Samma författares längre träningsstudie rapporterar den motsatta fällan: i en körning förbättrades en prompt fram till uppdatering 3 500, försämrades vid 4 000 och återhämtade sig fram till 10 000, så en dålig mellanliggande checkpoint är inte bevis för att körningen misslyckades. Den andra upptäckten betecknas uttryckligen som en kvalitativ progression från en enda körning och ett enda valideringsseed, utan att någon testfelskurva mättes och med återhämtningen beskriven som promptberoende. Se det som ett skäl att behålla varje 250-stegs-checkpoint, inte som ett recept.

En adapter som uppför sig, sedan förstärks. Scenfortsättningsadaptern dokumenterar en uppmätt försämring vid kedjad användning: naiv kedjning vid styrka 0,9 ackumulerar filmkorn till synligt färgbrus vid tredje eller fjärde steget, och författarens verifierade lösning är styrka på eller under 0,7 plus en gaussisk oskärpa på en halv pixel på varje kedjad indata. Samma kort är uppriktigt om att transformationer i sena steg förblir konservativa, och anger det som en begränsning i träningsdatan snarare än ett inställningsproblem.

Under allt detta ligger en rad saker som verkligen inte är fastställda, och de förtjänar att nämnas snarare än att fyllas i. Ingen har publicerat en kvalitetsjämförelse mellan Qwen-Image-2.1 och Qwen-Image-2.1-Turbo, så det finns ingen baslinje att bedöma vad någon adapter gör med någon av dem mot. Ingen har publicerat huruvida en standardcheckpoint-adapter fungerar korrekt på Turbo. Tillverkaren dokumenterar LoRA-träning bara en gång, i ModelScope-avsnittet i projektförrådet, och pekar då på ett tredjepartsramverk; själva modellkortet innehåller ingen vägledning om adaptrar, och checkpointens textkodare är en komponent som communityn redan har börjat återpublicera separat, vilket är en egen kompatibilitetsfråga. Och varje siffra på den här sidan är en ögonblicksbild av ett två till tre veckor gammalt ekosystem avläst en enda dag — Civitai-filtret och Hugging Face-frågan om basmodeller kommer båda att vara fel nästa månad, i riktning mot fler.

Om du funderar på vad du ska göra i dag är den sekvens som klarar alla dessa luckor kort. Börja med att läsa adapterns träningsprotokoll, inte dess prover – om det inte finns något protokoll, behandla filen som otillskriven och testa den med din egen prompt innan du bygger vidare på den. Matcha adaptern mot den checkpoint som dess protokoll anger, och om du kör Turbo läser du Turbo-sidan först. Kontrollera vilket loader-format filen har innan du drar slutsatsen att den är trasig. Och läs baslicensen en gång, eftersom den styr adaptern oavsett vad adapterns kort påstår om den. Välj sedan din tränare, börja med den minsta VRAM-förinställning som ditt kort stöder, och bedöm checkpoint-rutnätet i stället för den slutliga filen.