Qwen-Image-2.1-Turbo 對比 Qwen-Image-2.1：基礎檢查點與加速版本之間究竟有什麼改變

相同的 7B 視覺生成元件。相同的 32 層單流 DiT。相同的七種解析度預設，相同的生成與編輯介面，相同的 pipeline 類別來載入它。Qwen-Image-2.1-Turbo 與 Qwen-Image-2.1 並非讓你在能力上二選一的兩個模型——Turbo 檢查點是基礎模型的微調版本，而該儲存庫也在自身的 metadata 中如此說明。區隔兩者的是單一的取樣軌跡，以及該軌跡的儲存方式。一個執行四十步。另一個執行八步，並且在呼叫時拒絕接受其他設定。關於這對模型的一切有趣之處，都在第二句話裡。

先從相同的部分開始

在探討差異之前，值得先梳理相同之處，因為它比「Turbo」這個標籤所暗示的更為廣泛，而這正是讓這次替換具有吸引力的原因。

• 架構。Turbo 卡上指出，它「採用與 Qwen-Image-2.1 相同的 7B 視覺生成架構」。該專案將這個元件描述為橫跨 32 層 Single-Stream DiT 的 7B 參數。Turbo 儲存庫中沒有任何內容宣告更小、經剪枝或重新架構的主幹。

• 功能特色。兩個檢查點都被描述為可執行文字生圖與圖像編輯。Turbo 沿用基礎模型的功能範疇，而非重新加以陳述：基礎模型的說明卡記載了原生 RGBA 透明度、最多 10 張參考圖像，以及以圓圈、手繪標註或獨立遮罩指定的局部編輯，並可保持人物與產品的身分特徵。

• 解析度。Turbo 的模型卡寫著「使用與 Qwen-Image-2.1 相同的解析度預設」，接著列出這些：1:1 為 2048 × 2048、4:3 為 2400 × 1792、3:4 為 1792 × 2400、3:2 為 2528 × 1696、2:3 為 1696 × 2528、16:9 為 2752 × 1536，以及 9:16 為 1536 × 2752。基礎模型的模型卡列出了完全相同的表格。兩張模型卡的範例都採用 2048 這個解析度等級。

• 載入路徑。兩者都透過 Diffusers 中的 QwenImage21Pipeline 載入。Turbo 卡片的快速入門即是基礎卡片的快速入門，只是更換了檢查點名稱，並將 bfloat16 拼寫為 dtype 而非 torch_dtype。

• 書面文件。兩者皆依 Qwen-Image-2.1 Research License Agreement 授權，兩者的 license 欄位皆標示為 other，並帶有 license_name: qwen-research，而且兩者的儲存庫中，權重旁邊都放有一份 LICENSE 檔案。

如果你已經把 Qwen-Image-2.1 接好了，那麼，遷移範圍其實真的很小。而這正是為什麼那個行為不如你預期的引數，值得好好深究。

排程已從你的程式碼中移出，改放到檢查點裡

在基礎模型上，步數由你決定。Qwen-Image-2.1 模型卡的文字轉圖像範例、其編輯範例，以及其 RGBA 透明度範例，全都傳入 num_inference_steps=40，而這個數字是依一般 Diffusers 做法在呼叫時傳入的引數。那張模型卡上沒有任何內容告訴你，該檢查點對排程有自己的意見。

在 Turbo 上，排程是檢查點的中繼資料。卡片指出該檢查點「包含其建議的取樣排程，因此無需手動設定排程器即可直接使用」，接著在取樣區段中具體說明這在實務上代表什麼：「建議的 8 步取樣排程會隨檢查點儲存並自動載入。單獨設定 num_inference_steps 並不會覆寫它。」

接下來有兩件事，而這兩件事都很容易朝相反的方向出錯。

第一點是，八步並不是一個你可以向上調整的預設值。如果你想知道 Turbo 在十二步或二十步下會是什麼模樣，這張卡告訴你，唯一的途徑是明確地在呼叫時傳入 sigmas 引數——接著便關上了實驗的大門，指出其他排程「尚未針對此檢查點進行評估」。這等於是廠商在告訴你，八步配置是他們背書的那一個，而其他任何選擇都是你獨自踏入的未探索領域。這是一句異常誠實的話，應該被解讀為一道界線，而不是一份邀請。

第二個是沒有附帶任何錯誤訊息的重現陷阱。拿基礎模型的範例，把儲存庫字串改成 Turbo 檢查點，保留 num_inference_steps=40 不動，程式就會執行。它不會警告你。它會使用已儲存的八步排程產生一張影像，而且不會是 Turbo 展示所顯示的輸出，因為那個四十從來沒有被讀取。這是一種看起來毫無故障的失效模式——渲染完成、影像看似合理，而唯一能發現的方法，就是你主動去尋找差異。它旁邊還埋著第二個相依性：該檢查點需要一個能理解管線配置取樣 sigma 的 Diffusers 組建，這是在 PR #14950 中加入的，而在撰寫本文時，它位於 Diffusers 原始碼樹中，而不是某個已標記的發行版本。所述安裝內容是與 CUDA 相容的 PyTorch 組建，加上 Diffusers 原始碼、transformers>=5.17.0、accelerate 和 pillow。

什麼為你沒走的那 32 步買單？

這張卡片列出了兩種機制，兩者都值得了解，因為它們說明了 Turbo 檢查點假設你會如何呼叫它。

• CFG 1 預設值。「生成預設使用 CFG=1。」在無分類器引導（classifier-free guidance）縮放值為 1 時，模型不會執行 CFG 通常所需的第二次無條件傳遞——這正是軌跡得以縮短、而非單純被截斷的主要原因之一。這也意味著基礎模型調整引導縮放值的習慣無法沿用；這裡沒有什麼可調的，而這張卡片也未提供任何可供調整的引導建議。

• 前綴 KV 快取。Turbo 的說明卡寫道：「前綴 KV 快取會在去噪步驟之間重複使用文字與參考影像的上下文。」這是沿用既有機制，而非專為這個加速檢查點新增的功能：Qwen-Image-2.1 的發布公告將前綴 KV 快取重用列為基礎模型四項主要改良之一，與混合粒度注意力並列；而基礎模型的零日（day-zero）服務整合——專案新聞列表中的 vLLM-Omni 與 SGLang 項目——也明確將前綴 KV 快取列為其支援的功能之一。在四十步的迴圈中，這種重用只是一項最佳化。但在八步的迴圈中，它的重要性相對更高，因為每個快取的步驟佔總工作量的比例更大。

卡片未提及任何蒸餾技術。基礎模型的 Qwen-Image-2.1 卡片與專案 README 描述的是架構與能力；Turbo 卡片描述的則是機制。如果你試圖推論八個步驟在品質方面要付出什麼代價，這個儲存庫並沒有提供任何可供推理的方法——只有一套排程和一組展示圖像。

步數不是基準。

這是比較之中，誠實的答案就是無從比較的那一部分，而其中緣由值得直言不諱。

• Turbo 檢查點沒有已公布的評分。其模型卡未附帶任何形式的評估數字。Turbo 沒有 Qwen-Image-Bench 結果，沒有與基礎檢查點的並列比較，沒有針對步數的消融分析，也沒有顯示品質何時趨於平緩的表。

• 基礎檢查點的分數是廠商回報的。Qwen-Image-2.1 系列唯一的頭條數字，是基礎模型自身的 Qwen-Image-Bench 結果，由廠商針對基礎檢查點所回報。這並非 Turbo 檢查點的實測值，不應轉移到它身上——加速正是預期會改變這類數字的那個因素，而廠商並未說明影響幅度有多大。

• 兩張模型卡都沒有提供時間或記憶體資訊。無論是哪一個檢查點，都沒有延遲數據、吞吐量數據或記憶體佔用量，而兩張模型卡也都未註明其範例是在什麼硬體上執行的。基礎模型的模型卡至少還有一節說明記憶體最佳化；Turbo 的模型卡記錄了安裝、生成、編輯、取樣與長寬比，然後就沒了。

因此，目前支持 Turbo 勝過基礎 checkpoint 的論據，是一個關於設計意圖、而非關於實測結果的論據。在相同架構與相同 2048 解析度層級下，八個步驟每張影像的成本理應大幅降低。「大幅」在這句話裡承擔了實實在在的作用，而要把它換成一個具體數字，唯一的方法就是在你自己的實際工作負載上分別跑過這兩個 checkpoint，而這也是唯一能得知縮短後的取樣軌跡會對你在意的那些特定影像造成什麼影響的方法。

其他東西都沒有移動，包括授權在內

有兩件事，讀者可能會合理地預期已經改變，但實際上卻沒有。

首先是生態系統。當 Qwen-Image-2.1 於 2026 年 9 月 20 日推出時，該專案的新聞清單在同一天記錄了五項各自獨立的首日整合：透過 PR #14804 提供 Diffusers 支援、原生 ComfyUI 支援並發布用於文字轉圖像與編輯的工作流程範本、vLLM-Omni 支援並具備逐步執行、CUDA Graph 解碼、FP8 量化與張量平行、SGLang 支援並具備 Cache-DiT 與元件卸載，以及來自 LightX2V 專案的加速。日期為 2026 年 10 月 9 日、涵蓋 Qwen-Image-2.1-Turbo 的條目記錄了該檢查點本身，以及一則註記：Pro 與 Turbo API 已在 Alibaba Cloud Model Studio 上線。Turbo 沒有首日框架清單，而新聞清單中的每一項框架條目仍指向基礎模型。Turbo 檢查點透過一個早已存在的管線類別載入；對其已儲存排程的支援是唯一新增的部分，而且是透過 Diffusers 原始碼而非帶標籤的發行版本提供。

第二個是授權條款。Turbo 搭載的是 Qwen Research License Agreement，與基礎模型完全相同。加速並沒有附帶商業例外、獨立層級或條款放寬——非商業限制既適用於基礎模型，也同樣適用於微調版本。該儲存庫自身的中繼資料與權重旁的授權檔案就是證據；模型卡的授權區段只有一句話，指向同一份協議。如果八步之所以對你重要，是因為它讓模型便宜到足以放進產品中，那麼授權條款正是阻礙；而必須為此負責的是供應商——不是這個儲存庫。

託管端點，以及 OrcaRouter 的定位

OrcaRouter 既不路由 Qwen-Image-2.1-Turbo，也不路由 Qwen-Image-2.1。兩者皆不在我們的目錄中，而此處沒有任何內容構成提供其中任一的要約。若你想要它們，你的途徑會是供應商自家的託管 API、若干第三方平台，或是搭配組建版本夠新、足以處理 Turbo 檢查點所儲存之取樣排程的 Diffusers 的權重。

OrcaRouter 在這項特定比較中之所以相關，在於當自行託管檢查點不再是最佳答案時，你所做的那個替換。從你自己執行的開放權重模型轉移到託管的圖像端點，不只是模型的改變——而是失敗模式的改變。本機程序的失敗方式你看得見；託管端點的失敗方式則取決於是由哪個供應商回應，以及當其中一個在請求進行中效能下降時會發生什麼事。 OrcaRouter 將 200 多個模型置於單一相容於 OpenAI 的端點之後，並以不加價的方式原樣傳遞供應商標價，因此廠商降價當天就會反映在我們這邊，而不必等待重新定價的流程。 除此之外，它還加入了跨供應商的自動容錯移轉、用來指定請求可使用哪些模型與供應商的路由 DSL，以及將多個模型組合成單次呼叫的模型融合。 我們所串接的圖像模型是 OpenAI GPT-Image 系列、Google 的 Imagen 4 各層級（包括 fast 與 ultra 變體）、Google 的 Gemini 圖像預覽端點，以及 xAI 的 Grok Imagine 圖像端點。

具體來說：如果你是在兩個 Qwen 檢查點之間做選擇，那是一個自行託管的決策，而偏好其中一個而非另一個的原因在於排程行為與步數。如果你真正需要的是在生產環境中取得影像，而不必擁有 GPU，那才是我們有能力協助的決策，而那是另一個不同的決策。

簡短版本

• 選擇 Qwen-Image-2.1，若你希望檢查點的取樣行為與其文件相符、若你需要調整步數或探索排程，或者你想要在推出首日即獲得 Diffusers、ComfyUI、vLLM-Omni、SGLang 與 LightX2V 支援的版本。

• 如果你想要相同的架構與相同的能力，但軌跡大幅縮短，請選擇 Qwen-Image-2.1-Turbo，並且願意將八個步驟視為固定不變，以及願意從原始碼安裝 Diffusers 來載入它。

• 無論哪種方式，授權條款都相同，而且別期望加速檢查點有已發布的品質數據可供與基礎版本比較。步數減少是真實且有文件記載的。它犧牲多少影像品質則沒有任何地方記載，而且再怎麼讀那兩張卡也無法告訴你——那個答案只存在於你自己的硬體上，並取決於你自己的提示詞。