Qwen-Image-2.1 LoRA：有哪些適配器、訓練一個需要什麼，以及授權條款實際上怎麼說

針對 Qwen-Image-2.1這個由廠商推出、統一用來生成與編輯影像的模型，確實存在著一個真實的低秩調適（LoRA）適配器生態系，而廠商那一方幾乎沒有任何相關文件。本頁面是針對讀者經常會一起鍵入的四個問題所提供的常設解答：真的有人為這個模型製作適配器嗎？它們棲身何處？訓練一個要付出什麼？授權條款又允許你拿產出的成果做什麼？這不是一篇發布稿。Qwen-Image-2.1 於 2026 年 9 月 20 日開源，其加速版本 Qwen-Image-2.1-Turbo則於 2026 年 10 月 9 日接續推出；這兩個日期出現在這裡，只是為了指認本頁所談的是哪些檢查點，並不是要報導任何消息。

簡短版：適配器數量在數百個以內，它們大多是個人從業者發布的角色與風格作品；訓練其中一個的流程，已由至少三個第三方工具鏈從頭到尾記錄下來，並附有公開的記憶體用量測量數據；而授權條款——對這一代影像模型而言並非 Apache 授權——重申了對衍生作品的非商業限制，但許多適配器本身並未將這項限制延續下去。

用兩句話說明 LoRA 是什麼，然後是模型

LoRA 是一小組低秩權重差值，會在載入時加入凍結的基礎檢查點，並依名稱指定到特定模組；它不是模型，而是一種修補，會改變既有模型的行為。由於這些差值是針對特定權重訓練而成，適配器會綁定到它訓練時所用的檢查點，而這種綁定是設定旗標無法修復的。

這種綁定正是本頁專門討論 Qwen-Image-2.1、而非討論各種 LoRA 的根本原因。該檢查點是一個 32 層的單流擴散 Transformer，其視覺生成元件具備 7B 參數，搭配一個 Qwen3-VL 8B 文字編碼器，以及一個在 16× 空間壓縮下運作的 64 通道 RGBA VAE——這些數字全都出自廠商自家的模型卡與儲存庫，查閱日期為 2026 年 10 月 13 日。它在呼叫時設定取樣排程，而模型卡自身的範例採用 40 個推論步驟。這些細節對適配器而言沒有一項是無關緊要的：架構決定了檔案能觸及什麼，而排程則決定了以不同參數化方式訓練出來的適配器被要求做什麼。

針對這個模型，現存的有哪些，以及如何誠實地計數它。

以下的計數來自 Hugging Face API 與 Civitai API，兩者皆於 2026 年 10 月 13 日讀取；查詢方式值得特別說明，因為同一個問題會因你怎麼問而得到天差地遠的答案。

• 在 Hugging Face 上宣告 Qwen-Image-2.1 為其基礎模型的儲存庫： 323。

• 其中，同時帶有 lora 標籤的儲存庫：115。

• Civitai 上符合基礎模型篩選條件「Qwen 2.1」且類型設為 LoRA 的適配器：106。同一天稍早的一次查詢計為 105；該篩選條件是即時的，數字會變動，因此請將其視為一次讀數，而非總數。

這兩個數字都是下限，而非普查結果。Hugging Face 標籤是由上傳者套用的，因此作者若未加上該標籤，其轉接器就不會被該查詢看見；基礎模型的計數之所以大於 LoRA 的計數，正是因為它也會納入量化、合併與重新打包的模型。在 Civitai 上，不同方法之間的落差毫不含糊：直接以純文字搜尋「qwen image 2.1」會傳回 994 個不重複的模型，而其中大多數根本就不是這個檢查點的轉接器——同一組結果主要被工作流程貼文，以及所宣告基礎模型完全是另一種圖像生成的檔案所占據。請依基礎模型來篩選，而不是依搜尋框。

這兩個網站是這個生態系統的所在之處，而這也是對它們兩者唯一的主張：{{1}}Hugging Face{{/1}}是訓練紀錄與資料集發布的地方，{{2}}Civitai{{/2}}則是面向消費者的適配器及其周圍的{{3}}ComfyUI{{/3}}工作流程匯集之處，而兩者都不是品質訊號。任一網站上的檔案都可能是原創的訓練作品，也可能是他人作品的副本。

分辨原廠轉接器與重新包裝的轉接器

這是可檢查的，而且檢查大約需要一分鐘。取兩個看起來像同一個配接器的儲存庫。

akhaliq/Qwen-Image-2.1-Next-Scene-LoRA 建立於 2026 年 10 月 7 日。TechnoBaptist/Qwen-Image-2.1-Next-Scene-LoRA 建立於 2026 年 10 月 9 日。它們的 README 檔案位元組完全相同——長度相同、MD5 相同——而且這兩個儲存庫的檔案清單在所有 111 個項目上都一致。較晚的那個是較早那個的副本，描述及所有內容皆然。

較不明顯的情況是部分複製。developerjeremylive/Qwen-Image-2.1-Multiple-Angles-LoRA-etheroi內含 163 個檔案。其中同樣存在於akhaliq/Qwen-Image-2.1-Multiple-Angles-LoRA的 160 個檔案，每一個的檔案大小都完全相同，而這個儲存庫是對方 344 個檔案的嚴格子集。被留下來的是整個benchmarks/目錄、samples/底下各檢查點的範例網格，以及數個檢查點變體。轉接器權重都在，但證明這個轉接器確實如其所述發揮作用的證據卻不在。

所以，實際的檢驗並不是「它有沒有漂亮的卡片」，而是這張卡片是否承載著唯有實際跑過一趟才可能得到的東西：

• 訓練資料來自何處，並附上連結——角度適配器會標明其 Objaverse 來源與授權條款，並另行發布衍生的成對資料集。

• 訓練器與超參數，具體到 rank、alpha、學習率、步數與基礎精度的程度——足以讓其他人嘗試重現。

• 中間檢查點，而非僅有最終檔案，讓訓練曲線能被檢視，而不是只能被宣稱。

• 一份不是作者自我展示的評估，以及一個「適用範圍與限制」章節，點明該適配器做不好的地方。

一張只有觸發詞、強度範圍和一組精美樣本的卡片，除此之外什麼都沒有，並不能證明任何事。它也不能證明是重新打包——許多誠實的一次性轉接器，文件記錄就是這麼單薄。這只代表你沒有什麼可依據，而對一個你即將放進生產管線的檔案來說，這正是有用的結論。

一個人實際上要接受什麼訓練

先誠實地說清楚，因為這裡的落差很大：發布一個適配器很常見，而訓練一個則是不同量級的工作。有三項成本，而且每一項都是真實的。

基礎檢查點。 Qwen-Image-2.1 的三個元件——Transformer、文字編碼器與 VAE——合計約 33 GB，這是該儲存庫自行公佈的檔案大小總和，讀取於 2026 年 10 月 13 日。這就是正在被調適的對象，而且它不會因為你只在其上訓練一個小型補丁而縮小。

資料本身。LoRA 不像提示詞那樣，能從少數幾張圖像中學會一個概念。這個生態系統中記錄最完整的兩個轉接器，都把資料集當作第一級產物公開發表：相機控制轉接器的第一版以 5,028 組標註角度的配對進行訓練，第二版則用了 13,328 組；場景延續轉接器則以 1,144 組逐格進展配對進行訓練，每組配對的說明文字都由視覺模型撰寫。這兩者都是經過彙整建構的資料集，而非照片的集合——這些配對必須在訓練開始前先被生成、標註並取得授權，而且在其中一個案例裡，來源圖像還得先篩選出採寬鬆授權的物件，才能勉強使用。

運算部分。這是有公開實測數據、而非憑感覺判斷的部分。SimpleTuner 針對該模型的自家快速入門指南提供了 VRAM 預設值，另外也分別列出支撐這些預設值的記憶體冒煙測試：一個 512px 的配方在每一步都啟用梯度檢查點，通過了 24 GiB 的配置上限，同時尖峰時 PyTorch 配置了 20.06 GiB、保留了 21.10 GiB。一個多解析度配方在 32.49 / 41.21 GiB 下於 L40S 上通過，但在 32 GiB 上限下會耗盡記憶體。作者明確指出，那些是有限子集的記憶體檢查，而非吞吐量或收斂性測量，而且較低的預算是在 L40S 上模擬，而不是在它們對應的標稱顯示卡上實際執行。就發布內容來解讀，它們說明了簡單的一件事：這個模型的最低門檻是一張 24 GB 的顯示卡，而且只能在 512px 下運行；而 48 GB 以上才是該框架實際推薦的多解析度配方得以使用的門檻。

時間是較不張揚的成本，而幾乎沒有人會公布它。公開的是步數——24 GB 預設為 2,000 次更新，較大的預設為 4,000 次，每 250 步進行驗證與檢查點儲存——以及來自轉接器自身訓練記錄、為數千次的檢查點數量。SimpleTuner 的預設表格為每個 VRAM 等級提供更新預算，並直白地表示這些只是起點，唯有在檢視檢查點影像後才能延長。沒有人公布過可重現執行的實際時數，所以任何你看到被引用的耗時數字，都是某人的顯示卡與某人的資料集，而非一項規格。

話雖如此，其工具鏈確實相當完善，而這正是近期才出現變動、值得標註日期的部分。廠商指向 ModelScope 的 DiffSynth-Studio，其儲存庫提供了此檢查點可用的 LoRA 訓練腳本，另外也分別為 Turbo 變體提供了版本——只要單一次 accelerate launch，搭配 rank 32、AdamW 學習率 1e-4、五個 epoch、最大像素預算 1,048,576 以及梯度檢查點即可。SimpleTuner 的快速入門是公開資料中最詳盡的配方，而且它對自身限制的坦白程度非比尋常。ai-toolkit 在其支援的架構中同時列出 Qwen-Image-2.1 與 Qwen-Image-2.1-Turbo，而上述適配器中有兩個記錄了是以它訓練而成。此外，2026 年 10 月 12 日，musubi-tuner 合併了一個新增 Qwen-Image 2.1 支援的 pull request，涵蓋 LoRA 訓練、完整微調、訓練預覽，以及 Diffusers 與其自有 LoRA 格式之間的轉換；而要求此功能的需求單於 9 月 24 日開啟，至今仍處於開啟狀態。該合併比本頁日期早三天，而且它屬於工具鏈的變動，而非模型發布——這意味著多了一個可用的訓練器，並不代表模型本身有任何改變。

還有一個限制，會讓那些為其他架構訓練過 LoRA 的人栽跟頭。這個模型的輸出沒有 alpha 開關。它的 VAE 運作於四通道 RGBA 像素空間，第四個通道會被解碼為 alpha，因此透明效果完全由提示詞產生，別無其他來源——廠商自家的文件明確指出，整條管線中沒有任何與 alpha 相關的控制項。在不透明影像上訓練出來的適配器會改變提示詞所引導的分布；它並沒有另一個獨立的透明度旋鈕可以依靠。如果你的流程依賴去背效果，那是你所借用之基礎模型本身的特性，值得在投入一次訓練之前先測試一下。

授權條款對於您製作的轉接器有何規定

讀一下那個檔案，因為答案並不是一個聽起來很寬鬆的發布所暗示的那樣。Qwen-Image-2.1 是依據日期為 2026 年 9 月 20 日的 Qwen Research License Agreement 發布——一份 7,831 位元組的文件原封不動地被帶進 Turbo 儲存庫，而其副本在位元層級完全相同。它不是 Apache 2.0，而較早的 Qwen-Image 系列則是。

決定其中大部分的條款是授權條款。第2(a)條授權你「使用、重製、散布、複製、創作衍生作品，以及對」該等素材「進行修改」，接著對這一切設下上限：「僅限非商業目的」。第1(i)條將非商業定義為「僅限研究或評估目的」，這比「非營利」更狹窄——它並未排除內部商業使用。第2(b)條規定商業使用需要另行取得授權，並依協議所載地址提出申請。以此檢查點訓練而成的適配器是它的衍生作品，因此該限制會隨適配器一併移轉；它不會因為是你自己訓練的，就變得可作商業使用。

有兩件事值得注意，因為兩者都違背了常見的假設。

首先，這份授權條款並非對訓練保持沉默——它直接考慮了這件事。第 4(b) 條規定，如果你使用這些素材或其輸出成果來「建立、訓練、微調或改進一個會散布或提供他人使用的 AI 模型」，就必須在相關產品文件中顯著標示「Built with Qwen」或「Improved using Qwen」。因此，微調被明確點名，而它伴隨的是標示義務，而非權限問題。

第二，再散布受到明確允許，但附有條件。第 3 條允許您散布衍生作品，無論是以原始碼或目的碼形式，前提是您向收受者提供本協議副本、標示已修改的檔案，並保留一份內容為「Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved.」的聲明檔案。第 4(c) 條禁止將「Qwen」用作您衍生作品的主要名稱或識別標識——描述性使用則明確允許。第 5(a) 條確認您擁有自己的修改內容，但以遵守協議為條件。爭議受中國法律管轄，並由杭州的法院審理。

那些是前後一致、易讀的義務。令人不安的發現是，生態系有多常未達成這些義務。在研究本頁時所抽樣的適配器中，有一個——針對基礎檢查點的步驟蒸餾適配器——隨附授權條款文本與一份通知檔案，逐字載有必要的姓名標示字串，並在其卡片中設有授權區段，重申非商業限制與商業聯絡方式。其他數個，包括兩個下載次數最高的相機控制與場景延續適配器，宣告apache-2.0於其中繼資料中，卻完全未隨附授權檔案，也未包含任何姓名標示通知。它們的卡片並非主張對基礎權重擁有 Apache 權利；該中繼資料欄位單純有誤，而這正是下游工具會讀取的欄位。如果你是要以適配器為基礎進行開發的人，請自行閱讀基礎模型的授權條款，而不是信任適配器卡片上的標籤——而如果你是發布者，正確的封裝方式並不複雜，只是必須刻意去做。

相容性，以及關於「turbo」的那一件事

轉接器會在其訓練記錄所指名的檢查點上執行。對這裡大多數的轉接器而言，那個檢查點就是 Qwen-Image-2.1 本身，而那也是它們應該載入的地方。Turbo 檢查點是同一架構的微調版本，而不是另一個不同的模型——兩者共用模組樹，這就是為什麼以基礎模型訓練的轉接器極有可能可以載入 Turbo——但它在檢查點內部儲存了自己專屬的八步取樣排程，並執行一條該轉接器並未在其中受訓的去雜訊軌跡。這種組合是否能正確運作，沒有任何文件記載，連廠商也不例外。

另外還有一個命名陷阱：「turbo LoRA」這個說法涵蓋了兩種截然不同的產物：一種是訓練於 Turbo checkpoint 的 adapter，另一種則是把標準 checkpoint 變成少步版本的蒸餾 adapter。那些是不同的檔案，負責不同的工作。base checkpoint 與 Turbo 之間的取捨問題，以及 turbo adapter 的兩種含義，在這個主幹上都有自己的頁面——Qwen-Image-2.1-Turbo LoRA——而本頁不會變成它的第二份複本。如果你手上拿著 Turbo，以及一個名稱指向標準 checkpoint 的 adapter，在載入任何東西之前，請先讀那一頁。

另外兩個相鄰的問題也同樣另有所屬。量化檢查點——GGUF、FP8、INT4 等等——是另一個主題，有另一頁來說明；在量化流程中使用的 LoRA 是那一頁上的相容性備註，而不是這一頁的章節。而模型在特定工具中執行，又是另一個問題，有其自己的檔案清單與自己的失敗模式。

什麼會出錯，以及什麼尚未定案

這些失敗報告可歸結為三種原因，而每一項都是由實際做過這項工作的人記錄下來的，而非推論而來。

一個會載入卻什麼都不做的轉接器（adapter）。 最具體的案例是鍵名（key naming）不符：某個 adapter 自己的卡片上就寫明，其原始 trainer 格式的檔案採用該 trainer 的融合 MLP 鍵名，而 Diffusers 會「默默跳過」——載入成功、不會拋出任何錯誤，而該 adapter 也毫無作用。這個檔案在自己的載入器中能運作，換到主流的載入器就不行。這是檔案配置上的差異，而非基礎 checkpoint 的差異，在你怪罪其他任何東西之前，值得先將這一點排除。

一個會破壞不相關提示詞的適配器。這是學習率與訓練時長的問題，而且有實測數據：在一份已發表的消融實驗中，以 3e-4 進行的某次訓練「到第 500 次更新時，已嚴重劣化全部四個驗證提示詞」，無關的主體——一隻狐狸、一幅肖像——都變成了訓練出來的概念。同一位作者較長訓練的研究則回報了相反的陷阱：某次訓練中，一個提示詞到第 3,500 次更新都持續改善，在第 4,000 次時退步，之後到第 10,000 次又恢復，因此一個糟糕的中間檢查點並不證明該次訓練失敗。第二項發現被明確標註為來自單次訓練與單一驗證種子的定性進展，並未量測測試誤差曲線，且該恢復被描述為取決於提示詞。把它當作保留每 250 步檢查點的理由，而不是一套配方。

一個表現良好、隨後產生複合效應的適配器。 場景延續適配器記錄了在串接使用時可量測的退化：以強度 0.9 進行的單純串接，到了第三或第四跳時，底片顆粒會累積成可見的色彩雜訊；而作者經驗證的變通做法是將強度設在 0.7 或以下，並對每個串接輸入套用半像素高斯模糊。同一張卡片也坦承，後段跳躍的轉換仍維持保守，並指出這是訓練資料的限制，而非設定問題。

在这一切之下潜伏着的，是一组真正尚未确立的事项，而它们值得被明确指出，而不是被含糊带过。没有人发表过 Qwen-Image-2.1 与 Qwen-Image-2.1-Turbo 之间的品质比较，因此没有基准可用来判断任何适配器对两者各自造成什么影响。也没有人发表过标准检查点适配器在 Turbo 上是否运作正常。供应商只在专案储存库的 ModelScope 区段中记录过一次 LoRA 训练，并指向一个第三方框架；模型卡本身不含任何适配器指引，而该检查点的文字编码器是社群已经开始另行重新发布的元件，这本身又是另一个相容性问题。而本页上的每一个数字，都是某一天对已存在两、三周生态系所做的快照——Civitai 的筛选条件与 Hugging Face 的基础模型查询，到下个月都会失准，而且只会变得更多。

如果你正在決定今天要做什麼，在所有那些缺口下仍能成立的流程其實很短。先讀 adapter 的訓練紀錄，而不是它的樣本——如果沒有紀錄，就把該檔案當作未標示歸屬，並在以其為基礎之前，先用你自己的提示詞測試它。將 adapter 與其紀錄所指定的 checkpoint 配對；如果你用的是 Turbo，先讀 Turbo 頁面。在斷定檔案壞掉之前，先確認它是哪種載入器格式。並讀一次基礎授權條款，因為不論 adapter 的卡片如何自稱，它都約束著這個 adapter。然後挑選你的訓練器，從你的顯示卡支援的最小 VRAM 預設開始，並評估 checkpoint 網格，而不是最終檔案。