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 日开启——比权重可下载的时间早三天——正因如此，这些数字才得以存在，而不是被许诺日后补上。

“day zero”在这里是什么意思，以及为什么时机才是有趣的部分

框架支持通常与模型发布同时宣布，然后在数周后才交付。SGLang 的情况则相反。该实现是针对一个尚未公开的检查点编写的，这迫使作者处理真实架构，而不是规格说明书：扩散 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 归一化并更改了 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×）。

这些数据有两点诚实的前置说明。第一，它们是单次请求的延迟，而 {{1}}4090{{/1}} 那一行只测了去噪 —— 文本编码器和 VAE 都在计时范围之外。第二，{{2}}SGLang{{/2}} 的作者将更广泛的验证定位为功能性验证，而非评估性验证：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 通道是真实存在的，并且能经受量化；但对于在头发、毛发或玻璃上边缘是否干净，它什么也没说。

一个带有经过验证的透明路径的服务栈，其实用价值在于它能把三工具流水线变成一次调用。带 alpha 的生成、在已有 alpha 的图像内部编辑，以及将主体从普通 RGB 照片中提取到透明图层，这些都走同一个端点。

如果你不自己运行 GPU，这适用于什么情况

Qwen-Image-2.1 发布中令人尴尬的一点是，并没有可调用的托管端点。权重下载大约有 33 GB，生成组件是一个 7B 扩散 Transformer，搭配 Qwen3-VL 8B 文本编码器，而整个东西都依据 2026 年 9 月 20 日的《Qwen 研究许可协议》发布——仅限非商业用途，商业部署需要从供应商处获得单独许可。所以 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 的商业使用没有已公布的价格或条款清单，而在此之前，对于任何要交付给客户的东西来说，非商业限制就是全部关键。