之前在给团队搭建图像生成服务时最头疼的不是模型效果而是“慢”。用户输入一句 prompt等上 8 到 10 秒才看到图体验基本就崩了。后来看到 Baseten 公开的工程案例用 SGLang 推理框架 NVIDIA B300把 Qwen-Image 文生图延迟降低了 42.3%。这个数字很直接但仔细想会引出一串问题42.3% 是在什么配置下测出来的SGLang 凭什么能加速图像生成模型B300 相比上一代 GPU 究竟赢在哪里我们自己部署能不能复现类似效果本文围绕这个优化案例展开。我会先把 Baseten、SGLang、B300、Qwen-Image 这几个关键词讲清楚再拆解图像生成推理的延迟构成然后给出基于 SGLang 部署 Qwen-Image 的完整流程、性能测试方法以及生产环境常见的坑和最佳实践。文章内容更偏向工程落地视角适合正在做 AIGC 应用、模型服务化的后端工程师阅读也适合想了解图像生成推理优化原理的算法工程师。1. 图像生成服务的延迟困境先从业务视角看。文生图能力已经大量进入广告素材、电商主图、设计辅助、社交娱乐等场景。以电商为例运营人员需要批量生成商品场景图模型出图慢直接影响素材产出效率。to C 产品里用户等待时间超过 3 到 5 秒流失率就会明显上升。所以图像生成服务的延迟不只是“体验不好”而是直接决定产品能否在真实业务中跑通的核心指标这也是为什么近两年各大推理平台都在重点优化图像生成延迟。传统 LLM 服务主要关注首 token 延迟和生成吞吐图像生成模型则不同。一张 1024x1024 的图在 DiTDiffusion Transformer架构下需要经过几十次去噪迭代每次迭代都是一次完整的 Transformer 前向计算计算量非常可观。再加上文本编码和 VAE 解码整个流程的耗时动辄 5 到 10 秒这还是在单请求、显存充足的前提下。如果请求并发上来GPU 显存和算力被多个任务争抢延迟还会进一步恶化经常出现用户等了好几张图的时间才拿到第一张的情况。Qwen-Image 作为阿里 Qwen 团队开源的大规模图像生成模型效果上可以胜任中英文双语 prompt 的文生图、图生图、局部编辑等任务但 20B 的模型参数规模也决定了推理延迟不会低。如果部署在通用推理框架甚至直接用原生 PyTorch 脚本跑单张图的延迟可能到 10 秒以上并发场景下更是难以承受。模型效果越好、参数越大对推理侧的要求就越高这是 AIGC 团队普遍面临的现实压力。Baseten 的核心业务是帮助模型开发者在云端快速部署、扩展模型服务可以理解为“AI 模型服务的托管平台”。这类平台对推理延迟极其敏感因为每一项优化最终都会转化为客户的实际成本和用户体验。此次公开的 Qwen-Image 优化案例里SGLang 负责推理引擎层面的加速把模型的计算图、显存管理、请求调度统一编排好B300 负责硬件算力底座提供更强的访存带宽和计算能力。两者叠加最终把单次图像生成延迟降低了 42.3%。2. 核心组件拆解先搞清楚每个角色2.1 Qwen-Image开源图像生成模型的新选择Qwen-Image 是阿里 Qwen 团队在 2025 年发布的开源图像生成模型最大的特点是规模大、文本理解能力强、支持中英文双语输入。它有 20B 参数采用了 DiT 架构综合效果在当时开源模型中表现突出同时开放了商业使用的 Apache 2.0 协议这使它很快成为很多团队搭建私有文生图服务时的首选。相比 Stable Diffusion 系列Qwen-Image 的参数量大了一个数量级对应的是更强的 prompt 理解能力和更精细的生成质量。但规模带来的代价也很直接推理显存占用高单次生成的计算量成倍增加对部署环境的要求明显更高。20B 的模型权重即使在 FP16 精度下也接近 40GB再加上去噪过程中的中间激活、文本编码器的缓存一张 80GB 显存的 GPU 很可能只够处理单请求低并发。如果没有一套高效的推理框架来管理显存、调度请求、优化算子Qwen-Image 很难在真实业务里稳定运行更不要说支撑多用户同时访问。2.2 SGLang不只是一般的 LLM 推理框架SGLang 是由 UC Berkeley 等团队发起的开源推理框架全称是 Structured Generation Language最初主要面向大语言模型的高效推理。它最著名的特性之一是 RadixAttention能够自动复用 KV Cache在多次请求共享相同前缀时大幅减少重复计算。对于聊天机器人、代码补全这类前缀高度重复的场景SGLang 的缓存复用效果非常明显这也是它在 LLM 推理领域快速流行起来的重要原因。后来 SGLang 的定位逐渐从纯 LLM 扩展到了多模态和生成式模型。它提供的运行时 SRT 具备连续批处理、CUDA Graph、算子融合、显存管理器等能力并且对 OpenAI 兼容的 API 做了良好支持。换句话说SGLang 要解决的是“模型服务化”这一整层的问题而不仅仅是加速某一个模型的前向计算。在图像生成场景下它需要把文本编码、扩散去噪、VAE 解码三段链路统一编排起来同时处理请求排队、动态批处理、显存复用这些工程细节。在 Baseten 的 Qwen-Image 优化案例中SGLang 承担的角色就是推理引擎的核心层。没有这层引擎单纯换一张更强的 GPU延迟下降幅度很难达到 42.3% 这个量级。因为硬件算力再强如果框架没有针对模型做算子优化很多算力都浪费在低效的 kernel launch 和显存搬运上。2.3 B300新一代 GPU 的算力底座B300 属于 NVIDIA Blackwell Ultra 架构的新一代 GPU可以看作是 B200 系列的升级版本。关于它的具体显存容量、HBM 带宽、功耗等参数需要以 NVIDIA 官方发布的数据为准这里不过多展开。从架构演进的大方向上Blackwell 系列相比上一代 Hopper 系列在 FP4 稀疏算力、NVLink 互联带宽、HBM3e 显存带宽等方面都有明显提升这些对图像生成这种“计算密集 访存密集”的混合负载非常关键。为什么图像生成特别吃 GPU 的显存带宽DiT 模型的每次去噪迭代都需要读取模型权重和中间激活同时把结果写回显存。模型参数越大每次迭代的访存量越大。如果 GPU 显存带宽不足计算单元就会频繁等待数据搬运最终表现为“标称算力很高但实际跑不快”。这也是为什么从上一代 GPU 换到 B300 之后图像生成延迟会有明显下降除了算力提升更关键的是显存带宽的提升有效缓解了数据搬运瓶颈。当然硬件只是底座。B300 的算力优势需要通过推理框架的调度、算子实现、显存分配才能转化为真实的延迟收益。如果框架层面对模型的支持不好很多新硬件的优化算子根本没有被用到再强的 GPU 也发挥不出应有的水平。理解这一点很重要因为它解释了为什么性能优化案例总是“框架 硬件”一起出现而不是单方面谈硬件升级。2.4 Baseten模型服务托管平台的角色Baseten 是一个面向 AI 应用的模型推理平台用户可以把自己训练的模型或者开源模型部署到 Baseten 管理的 GPU 集群上平台负责容器编排、弹性伸缩、负载均衡、监控告警等繁琐的工程问题。在这种模式下推理框架和硬件的选型直接由平台的控制平面决定优化空间也比普通用户更大。普通开发者通常只能在自己的一台或几台 GPU 上做有限调优而 Baseten 可以跨机型、跨框架做系统的基准测试和方案筛选。Baseten 团队会持续做推理引擎的性能对比和基准测试把表现最好的方案沉淀到平台的部署模板里。这次的 Qwen-Image SGLang B300 组合就是他们在图像生成领域的一次工程化验证。所有优化手段最终落到一个清晰的业务指标上单次图像生成延迟降低了 42.3%。对于使用 Baseten 平台的开发者来说这意味着同样的用户体验目标可以换取更低的机器成本或者更少的 GPU 数量支撑同样的并发量。3. 图像生成推理的延迟构成3.1 一次文生图请求经历了什么要理解 42.3% 的延迟优化空间首先得搞清楚一次文生图请求的时间都花在哪里。以 Qwen-Image 为例完整链路大致可以分成三段。第一段是文本编码把用户输入的 prompt 通过 text encoder 转成文本向量。Qwen-Image 的文本理解能力强但这也意味着文本编码器的参数量和计算量不小。第二段是扩散去噪模型从随机噪声出发经过 N 步迭代逐步去除噪声得到最终的潜空间特征。这是整个链路中计算量最大的部分通常占据总耗时的 70% 到 85%是延迟优化的主战场。第三段是 VAE 解码把潜空间特征解码成像素级图像输出最终图片这一步相对轻量但也不能忽略。实际操作中服务端可能还会包含安全审核、图像后处理、超分放大、水印叠加等额外环节这些都会继续增加端到端延迟。关键点在于扩散去噪阶段N 次迭代是串行依赖的前一步的输出是后一步的输入无法并行。想让整体延迟下降最直接的手段就是减少每次去噪迭代的耗时而这主要依赖算子级优化和硬件算力提升。SGLang 和 B300 的优化本质上都是在针对这个核心部分做文章。3.2 计算瓶颈 vs 访存瓶颈图像生成推理有两个典型瓶颈计算瓶颈和访存瓶颈。计算瓶颈指 GPU 的算力成为主要限制比如 FP16 下的矩阵乘算子计算单元已经打满但数据搬运跟不上整体吞吐受限于 FLOPS。访存瓶颈则相反GPU 的计算单元大量时间在等待显存数据算力有富余但内存带宽不够用整体吞吐受限于 HBM 带宽。DiT 模型在中小 batch size 下通常更接近访存瓶颈。原因在于模型参数太大每次迭代都要把全部权重从显存读入计算单元权重读取的访存量非常大。对于 Qwen-Image 这种 20B 参数的模型单次前向计算需要读取的权重就有几十 GB显存带宽直接决定了理论下限。因此提升显存带宽往往比单纯提升算力更有效这也是 Blackwell 系列在 HBM 带宽上持续加码的根本原因。理解这一点就能看懂 Baseten 优化案例的本质B300 的 HBM3e 显存带宽解决了访存瓶颈SGLang 的算子融合和 CUDA Graph 优化解决了计算效率和启动开销问题。两者叠加效果自然是“1 1 2”。你在做自己项目的性能分析时也要先判断瓶颈属于哪一类再用对应手段去优化而不是盲目升级硬件。3.3 为什么 42.3% 的降幅值得关注42.3% 的延迟下降意味着什么做个简单换算如果基线延迟是 8 秒优化后约 4.6 秒如果基线是 6 秒优化后约 3.5 秒。在交互式应用里从 8 秒降到 4.6 秒的体感差异是质的飞越用户基本可以接受等待而不是直接流失。如果业务里用户每天生成几十万张图这个延迟差异对应的是 GPU 资源占用的大幅下降。更重要的是延迟下降可以换取吞吐提升。同样的 GPU 单位时间能完成更多张图的生成意味着单张图的渲染成本下降。在 AIGC 服务的成本模型中GPU 占绝大部分支出延迟优化直接对应成本优化。对于商业化团队来说这种“省钱 提体验”的组合是最有吸引力的优化方向也是平台类公司愿意花精力去做框架适配的原因。不过这里也要提醒42.3% 是 Baseten 在特定软硬件环境下的测试结果不代表任何环境都能复现。框架版本、GPU 型号、请求并发、图片分辨率、采样步数都会影响最终效果。我们在自己的项目里更应该关注的是方法论如何通过框架选型和硬件升级系统性降低图像生成延迟并用规范的压测方法验证收益。4. SGLang 加速图像生成的核心原理4.1 RadixAttention 与缓存复用SGLang 在 LLM 推理中让人熟知的特点是 RadixAttention它把 KV Cache 组织成前缀树结构允许不同请求之间共享相同的前缀缓存。当新的请求前缀与已缓存的历史请求匹配时直接复用缓存结果不再重复计算。在对话场景里多轮对话的开头部分往往完全一致缓存命中率很高省掉的重复计算非常可观。在图像生成场景里这种缓存复用思路同样有价值。比如图生图任务中多张生成图共享同一张参考图参考图的 VAE 编码结果可以只计算一次后续请求直接复用编码结果省去重复的视觉编码开销。再比如批量生成同一主体不同风格的图片时文本编码结果也可以复用。虽然图像生成场景下的缓存命中率不如 LLM 对话那么高但积少成多同样能降低平均延迟尤其在固定模板 prompt 的业务场景里收益明显。4.2 Continuous Batching 与调度效率传统推理服务的做法是“一个 batch 跑完再跑下一个”如果 batch 里的请求有快有慢慢的请求会拖累整个 batchGPU 利用率不高。SGLang 的 continuous batching 允许请求动态加入和退出一张图生成结束后新的请求可以立刻补位到 GPU 上开始计算GPU 始终有任务可做不会因为等待最慢的请求而空转。对图像生成服务来说
