SGLang-Diffusion 於首日即支援 Qwen-Image-2.1：在單張 B200 上僅需 2.75 秒即可生成

Qwen-Image-2.1 於 2026 年 9 月 20 日正式發布，而 SGLang-Diffusion 團隊早已為它準備好服務路徑。零日支援涵蓋了該模型的三項工作——文字轉圖像生成、多圖像編輯，以及透明 RGBA 輸出——並且伴隨著一件比合併的拉取請求更罕見的事：在具名硬體上測得的延遲，並隨產生該數據的配置一併發布。在單一 NVIDIA B200 上，1024×1024、40 步，SGLang 的數字落在生成 2.748 秒、編輯 3.358 秒。支援的拉取請求 sgl-project/sglang#39983 於 9 月 17 日開啟——比權重可供下載早三天——這正是這些數字之所以存在，而非被承諾日後補上的原因。

「零日」在這裡是什麼意思，以及為什麼時機才是真正有趣的部分

框架支援通常會與模型發布同時宣布，卻要再過數週才交付。SGLang 的情況恰恰相反。這份實作是針對當時尚未公開的檢查點所撰寫，這迫使作者必須處理真實的架構，而非規格文件：diffusion transformer、64 通道 RGBA VAE、Qwen3-VL 條件化、多參考影像輸入，以及 RGBA 輸入與輸出。

這就是為什麼比起能力清單，更應該信任延遲表。一個從未實際提供服務的模型沒有實測數據；而一個數字若附帶其硬體、解析度、步數與精度，任何擁有同一張顯卡的人都能加以核查。SGLang 的數據被標示為特定配置，而不是對該模型的一般性宣稱。

其餘的工具鏈也在同一個時間窗口內到位。ComfyUI 推出了原生支援，Diffusers 合併了 QwenImage21Pipeline，vLLM-Omni 新增了逐步執行與 FP8 量化，而 LightX2V 則透過 ROCm 新增了支援 AMD Radeon 的加速功能。框架是發布內容中決定實驗室以外任何人能否使用它的關鍵部分。

數字，以及它們沒有說出口的事

SGLang 這項工作公布的是每請求延遲，而不是吞吐量。當你要規劃的是服務規模，而不是跑示範時，這個區別就很重要：單次 2.7 秒的生成告訴你的是往返時間，而不是一張卡能承載多少同時使用者。已公布的配置全都採用 1024×1024 與 40 步：

• B200、常駐權重、FlashAttention — 生成 2.748 秒、編輯 3.358 秒，這是在 Q/K-norm 修正與 LayerNorm 調整之後的結果，兩者各自又省下了幾個百分點。
• RTX PRO 6000 Blackwell、96 GB、常駐 — 在 40.1 GiB 峰值佔用下，生成 8.23 秒、編輯 9.85 秒；將擴散 Transformer 卸載後為 10.28 秒與 10.66 秒，峰值降至 26.1 GiB。
• DGX Spark、1× GB10、eager、完整 VAE 解碼 — 生成 35.36 秒、編輯 42.23 秒，透明變體則為 35.49 秒與 42.21 秒。這些數字包含 PNG 序列化。可中斷的 CUDA graphs 產生完全相同的像素，且沒有可量測的速度效益（35.96 秒對上 35.64 秒），而批次處理與多 Spark 配置則完全未進行基準測試。
• RTX 4090、24 GB、逐層卸載、僅去噪 — 搭配 SDPA 的基礎 BF16 為 26.69 秒，搭配 Cache-DiT 為 10.31 秒（2.59×），Cache-DiT 加上 INT8 核心集為 5.59 秒（4.77×），再加上 Sage attention 則為 4.74 秒（5.63×）。

這些數據列附帶兩點必須誠實說明的但書。第一，它們屬於單次請求的延遲，而且 4090 那一列只量測去雜訊階段——文字編碼器與 VAE 並不列入計時。第二，SGLang 作者把更廣泛的驗證定位為功能性驗證，而非評價性驗證：BF16 輸出在不同配置下並非位元完全一致，而量化或張量平行也會改變這些數字。更快且不同，並不等同於更快且更好。

為什麼透明輸出路徑才是值得關注的那一個

RGBA 是這款模型與多數團隊早已在呼叫的圖像端點最大的不同，也是服務起來最彆扭的地方。Qwen-Image-2.1 在把 alpha 通道當作一等元件的潛在空間中進行去噪，並透過具備 16× 空間壓縮的 64 通道 RGBA VAE 來完成。透明度不是靠分割模型事後外掛上去的後處理；它是取樣器直接產出的結果。

要好好支援那種輸出，比支援 RGB 更困難。輸出更大，VAE 有更多通道要解碼，而且請求還帶著一個排程器必須路由的額外模式位元。SGLang 的驗證正好涵蓋了那個層面——透明的 PNG 輸出、alpha 在完整的 0–255 範圍內都保留，以及在單一樣本中達到 60.69 dB 的 RGBA PSNR，而 FP8 配置也通過了透明生成。那是正確性檢查，而不是品質基準，作者也這麼說。它確立了 alpha 通道是真實的，並且能在量化後保留下來；它完全沒有說明在頭髮、毛皮或玻璃上的邊緣是否乾淨。

一套具備經過驗證之透明度路徑的 serving stack，其實際價值在於把三工具管線化為一次呼叫。帶 alpha 的生成、在已有 alpha 的影像內進行編輯，以及將主體從一般 RGB 照片中抽取到透明圖層，全都經由同一個端點完成。

如果你不是自己執行 GPU，這適用於什麼情況

Qwen-Image-2.1 發布後最尷尬的地方，在於沒有代管端點可以呼叫。權重大約要下載 33 GB，生成元件是 7B 的擴散 Transformer，搭配 Qwen3-VL 8B 文字編碼器，而整包是以 2026 年 9 月 20 日簽署的 Qwen Research License Agreement 發布——僅限非商業使用，商業部署需向廠商另行取得授權。所以 SGLang 的這套做法並不是 API 的替代方案。它就是 API，而你就是那個營運的人。

這改變了路由層的用途。OrcaRouter 以供應商定價、零加成，將 200 多個模型置於單一 OpenAI 相容端點之後，並提供跨供應商的自動容錯移轉、用於組合備援的路由 DSL，以及用於面板式呼叫的模型融合——但它不路由任何版本的 Qwen-Image 模型，而 Qwen-Image-2.1 永遠不會成為你能在那裡呼叫的路由。實際可行的架構是拆分式架構：透過 SGLang 在你自己的硬體上執行 Qwen-Image-2.1，以處理透明與多參考的工作，其餘一切則透過單一金鑰送往託管的圖像模型。我們的目錄涵蓋 OpenAI GPT-Image 系列、Google 的 Imagen 4 各層級與 Gemini 圖像預覽版，以及 xAI 的 Grok Imagine 圖像端點，全部以原定價轉嫁，因此其中任何一家供應商的價格變動，我們這邊當天就會生效。

一次部署實際上長什麼樣子

SGLang 文件為這個模型提供了一份 cookbook，內含各 GPU 的指令，而建議的伺服器啟動方式只有一行——sglang serve --model-path Qwen/Qwen-Image-2.1 --performance-mode speed。文字轉圖片的請求支援選擇性啟用的動態批次處理；圖片編輯請求則以另一條獨立路徑處理，而單一請求可回傳多個輸出結果。

實際已驗證的配置範圍，比相容性矩陣所暗示的更窄。H200、B200、RTX PRO 6000 96 GB、RTX 5090 與 RTX 4090 已涵蓋 1024×1024、40 步的生成與編輯，包括其透明變體，另加上多 GPU 張量平行、Ulysses 與 Ring attention、逐層卸載、平行分塊 VAE 解碼、Cache-DiT、CUDA graphs，以及線上與序列化 FP8 量化。RTX PRO 6000 上的多 GPU 與 NVFP4 配方仍未驗證，而多主機 RDMA 與多 rank 分離式角色則尚未涵蓋。如果你的計畫涉及四張卡與一套 fabric，那你就領先於已發表的證據。

接下來要留意兩件事。第一是是否有人公布吞吐量而非延遲——併發數量才是把 2.7 秒這個數字變成容量規劃的關鍵。第二是授權條款：Qwen-Image-2.1 的商業使用沒有公布價格或條款清單，而在有之前，對任何要交付給客戶的東西來說，非商業限制就是全部。