很多做 AI 应用的团队都有一种误解文生图服务的延迟主要取决于模型参数量想降低延迟就只能换更贵的 GPU。但真正在生产环境部署过 Qwen-Image 这类扩散模型的工程师会知道瓶颈往往不在“算得慢”而在“等得久”。请求在调度器里排队、去噪步骤之间反复读写显存、每一步都启动独立的 Python 算子、完全不做中间结果复用这些开销在工程层面全部可控。Baseten 最近公开的一个优化案例很有代表性用 SGLang 搭配 B300 部署 Qwen-Image端到端延迟下降了 42.3%。表面看这是一个“换新硬件”的新闻但懂推理服务的人会立刻意识到单靠换卡不可能凭空省出四成延迟。真正起作用的一定是组合优化B300 提供了更大的显存带宽底座SGLang 则把请求调度、去噪循环、缓存复用整合到同一套框架里Baseten 再把两者调到合适的配置。这篇文章想把这套组合拳拆开来讲图像生成请求的延迟到底从哪里来SGLang 为什么适合承接 Qwen-Image 这类视觉生成负载B300 在中间扮演什么角色如果你要在自己的环境里复现类似优化应该从哪一步开始以及最容易踩到哪些坑。这里的重点不是记住 42.3% 这个数字而是理解它背后的工程判断。1. 为什么图像生成延迟比文本生成更难优化文本生成模型的输出是 token用户看到“首字”只需要几百毫秒后续内容可以边生成边显示。图像生成模型完全不同用户看到一张图之前服务端已经把整个去噪过程全部跑完期间用户只能等待。也就是说交互式图像应用的体验好坏几乎完全取决于端到端延迟而不是每秒能生成多少张图。吞吐高不等于延迟低。GPU 利用率很高的服务如果调度器不做区分新请求可能要在队列里等好几个批次。对文本生成来说这种等待偶尔还能接受对图像生成来说额外多等几秒用户可能已经离开了页面。因此图像生成服务的性能指标体系必须把延迟放在最前面。文本生成和图像生成的核心差异可以归纳为一张表对比维度文本生成图像生成核心指标tokens/s、TTFT端到端延迟、p95计算模式自回归逐 token 解码扩散模型迭代多步去噪显存开销主要看 KV Cache激活、中间特征、VAE 解码都占显存优化重点预填充与解码分开调度去噪循环、显存带宽、计算图优化缓存价值提示词前缀缓存文本特征、去噪中间状态可复用用户体感边生成边输出必须等完整图像返回这张表解释了标题里 42.3% 的含金量。把平均延迟和 p95 同时打下来意味着在最差的请求条件下用户体验也依然稳得住。对很多增长型产品来说p95 的改善比平均吞吐提升更能直接转化为留存率。不过要泼一盆冷水公开案例的 42.3% 是在特定硬件、特定并发、特定模型版本下测出的数据。它不是一个普适指标而是一个方向。换到自己的请求分布和部署规模数字一定会变。我们真正能借鉴的是它的优化路径和排查思路。2. 这次优化的三个主角2.1 Qwen-Image不只是一个“画图模型”Qwen-Image 是阿里通义千问团队开源的一类文生图模型。与 LLM 不同的是它的服务端负载无法用一次 Transformer 推理概括。生产环境中请求至少会经过三部分文本编码器负责把提示词转成语义向量扩散主干负责在多步去噪中逐步生成图像的潜变量VAE 解码器把潜变量还原成真正的像素图。这三部分对计算资源的诉求并不一样。文本编码计算量小但它是后续所有步骤的输入必须低延迟完成。扩散主干计算量最大而且同一个请求要反复执行很多步是整条链路最耗时的地方。VAE 解码单次计算时间不算长但显存带宽占用很高图像分辨率越大越明显。所以部署 Qwen-Image 和部署一个 7B 对话模型是完全不同的工程。显存里不只是模型权重还包括多步去噪产生的中间特征。如果调度不当可能出现显存分配有余量、但显存带宽被打满、GPU 算力又在空转的情况。2.2 SGLang从 LLM 服务框架到多模态生成调度器SGLang 是开源的高性能推理服务框架核心设计目标是把大模型的复杂执行流程抽象成可调度的计算图。它最初以服务 LLM 闻名尤其在前缀缓存和连续批处理上做得比较深入。最近几年的演进方向是往多模态输入输出扩展像 Qwen-Image 这类视觉生成模型也被纳入同一套调度体系。这里有一个常见误解SGLang 只是 LLM 推理加速库。实际上它的调度器关心的是把每个请求拆成可调度的子任务并不在意子任务是生成下一个 token、回答视觉问题还是执行扩散模型的第 10 步去噪。当 Qwen-Image 接入之后调度器要做的就是把去噪循环中的每个步骤抽象成可执行单元统一安排执行顺序、显存占用和批处理边界。SGLang 与 vLLM 的对比也是社区里高频出现的问题。两者都是优秀的推理服务框架但设计取舍有明显差异对比项SGLangvLLM调度核心RadixAttention 前缀树缓存偏向把请求拆细PagedAttention 显存分页偏向吞吐稳定缓存能力支持前缀和中间结果复用复用粒度更高以 KV Cache 为主多模态缓存支持相对较晚多模态服务视觉理解、图像生成类模型支持度高主要以 LLM 和视觉理解模型为主适用场景追求低延迟、高复用比追求稳定吞吐、社区生态更庞大图像生成这种“中间结果复用价值极高”的工作负载与 SGLang 的设计思路天然契合。这也是为什么 Baseten 会选择它而不是继续沿用传统的批处理方案。2.3 B300更大的显存带宽意味着什么B300 属于英伟达 Blackwell 系列面向大规模推理的演进版本。相比上一代 GPU它的迭代重点集中在显存容量和显存带宽。这里不具体堆参数只说它对图像生成产生的决定性影响。扩散模型的去噪循环每个 step 都要把整份激活张量写入显存、读回、再写入下一层。整个过程里 GPU 算力不一定时刻吃满显存带宽却很容易打满。如果带宽不够算力再高也只能等着数据搬运。B300 在带宽上的提升相当于给去噪 pipeline 加宽了数据通路让每一步计算都能更快拿到数据。但必须强调带宽要真正转化为延迟收益框架必须先做好两件事。一是把请求切分到合适的 GPU 并行粒度二是减少无意义的显存读写。如果框架依旧在 step 之间频繁等待或者对同一份中间特征反复拷贝带宽升级也会被调度开销吃掉。B300 是必要条件不是充分条件。3. 延迟到底从哪里来一次 Qwen-Image 请求的链路拆解要优化延迟就必须先把链路拆开。一次典型的 Qwen-Image 请求大致会经历以下阶段网关接收 HTTP 请求进行鉴权、路由、限流。文本编码把用户输入的 prompt 转成语义向量。扩散去噪循环执行一定数量的步在潜空间里逐步生成图像。VAE 解码把潜变量还原成像素图。结果编码和返回图像序列化为 base64 或写入对象存储后返回 URL。从服务端工程师的视角看真正决定性能体感的是第 3 步。去噪循环要跑很多次前向计算每次前向又包含几十甚至上百个算子任何一个算子的启动开销、数据搬运、显存分配多做了都会在总延迟里被放大。很多团队第一次压测时会遇到这种情况GPU 利用率不低端到端延迟却很高。原因通常不是单一环节而是多个问题叠加并发请求之间相互排队单请求延迟被拖长。每个去噪 step 都重新分配显存碎片化严重。没有缓存文本编码结果相同 prompt 每次都重新计算。CUDA Graph 未开启Python 层反复调度算子启动开销占了可观比例。输出图像做序列化时重复拷贝最后一步拖慢整条链路。可以用一个简化公式来表达端到端延迟端到端延迟 ≈ 排队时间 文本编码时间 去噪步数 × 单步前向时间 VAE 解码时间 结果传输与序列化时间框架优化主要做三件事降低排队等待、降低单步前向时间、消除重复计算。硬件升级则主要作用于单步前向时间中的访存开销。Baseten 的 42.3% 大概率不是一个环节的功劳而是把几个环节同时压到了更接近理论下限的位置。4. SGLang 在图像生成场景里到底优化了什么这一章讲推理服务侧的框架机制。理解这些部署时就不需要黑盒试参数。4.1 调度与连续批处理SGLang 的调度器会持续接收请求而不是等一个请求处理完再发下一个。每个去噪 step 可以被看作一个独立计算单元调度器把不同请求的 step 拼到一个 batch 里执行只要总显存不超限。这个设计的收益很直观batch 变大GPU 利用率上升但调度器必须保证单个请求在队列里等待不会过久。并发上限、batch 上限、超时时间需要在生产环境里反复压测才能找到平衡点。在文本生成里连续批处理已经非常成熟。在图像生成里真正的难点是“去噪步数不同”的请求如何混排。如果模型允许提前终止调度器还能把步数少的请求和步数多的请求交错执行进一步提升整体吞吐同时不明显牺牲单请求延迟。4.2 中间结果缓存与复用SGLang 的 RadixAttention 原本用于复用 LLM 请求的前缀 KV Cache。迁移到图像生成场景后这个思想可以泛化为更广义的“中间结果缓存”。例如 prompt 不变时文本编码结果是可复用的同一批请求来自同一个用户时公共语义特征也可以复用。缓存命中率越高有效计算量越低延迟自然下降。但缓存不是免费的。缓存本身占显存命中判断也需要时间。对图像生成模型而言中间特征体积很大必须设置合理的缓存容量和淘汰策略。如果策略太激进可能为了极少数相同的 prompt 牺牲大量动态请求的显存。SGLang 的做法是把缓存放进调度逻辑按需分配、按访问频率淘汰而不是简单地“能存则存”。4.3 CUDA Graph 与编译优化图像生成单步前向的算子非常多。如果每个算子都从 Python 脚本分发到 GPUCPU 与 GPU 之间的切换成本会被放大。CUDA Graph 会把一串算子捕获成一个图一次启动执行一整段计算显著减少 Python 层的启动和调度开销。在 B300 这类新硬件上如果框架没有做计算图优化部分新算子可能无法享受到硬件指令集和内存布局的优化。开启 torch.compile 或 CUDA Graph 后算子融合、内存布局优化都会被自动纳入考虑。这是落地时经常被忽略的提速点很多人只盯显存和并发没有意识到短小算子密集的场景里启动开销占比可能高得惊人。4.4 显存规划图像生成模型推理时不会只吃一个静态大小的 KV Cache它还要分配中间激活、去噪临时张量、VAE 解码缓冲区。如果让默认的缓存分配器来管理很容易出现峰值显存过高、碎片化严重的问题。SGLang 通过显存池统一管理给不同类型的张量划分区域减少运行时分配次数。部署时常见的mem-fraction-static参数就是控制静态显存占比的。这个值不能盲目拉满。设置过高动态请求到达时没有余量容易 OOM设置太低显存利用率不足batch 和并发规模上不去。比较合适的做法是从 0.85 开始结合压测逐步微调。5. Baseten 的优化思路为什么是“组合拳”从公开信息看Baseten 的优化案例里至少包含三个变量Qwen-Image 模型、SGLang 框架、B300 硬件。要判断 42.3% 的延迟下降来自哪里最稳妥的理解是B300 提供了带宽基础SGLang 提供了调度与缓存能力Baseten 把这些能力组合到了正确的配置上。如果不是组合拳大概率会遇到两种失败只换 B300 不换框架模型能跑但调度逻辑还是老一套并发高时排队严重延迟改善有限。只换框架不换硬件缓存和计算图优化有效果但访存带宽依旧是瓶颈去噪 step 很难继续缩短。组合优化的执行过程也不是“一键开启”。更常见的路径是先压测找瓶颈再逐项调整在现有硬件上先用 SGLang 部署 Qwen-Image跑一轮基准记录吞吐、p50、p95、显存占用和 GPU 利用率。开启缓存和 CUDA Graph观测延迟变化。如果变化不明显说明瓶颈不在计算启动而在访存或排队。换到 B300 或更高带宽硬件保留上一轮框架配置再跑一轮压测。根据结果调整并发上限、静态显存占比、batch 大小。最后关注极端场景请求密集到达时 p95 是否恶化长 prompt 是否拖慢第一条请求。这套流程并不神秘但每一步都要用数据做决策。42.3% 只属于特定测试条件。真正值得复制的是这个“先指标化再逐项对比”的方法论。6. 最小可复现的延迟优化与验证示例下面的示例用来跑通“服务启动 请求测量”的完整链路。具体参数会因为版本和环境不同但步骤可以照做。6.1 环境准备操作系统Linux 发行版生产环境推荐 Ubuntu Server。Python3.10 或以上版本以 SGLang 官方要求为准。显卡NVIDIA GPU建议显存 48GB 以上。推理框架SGLang 最新稳定版。模型权重Qwen-Image 权重下载方式以官方发布说明为准。安装依赖时建议使用独立虚拟环境python3 -m venv qwen-image-env source qwen-image-env/bin/activate pip install --upgrade pip pip install sglang[all]6.2 启动 SGLang 服务不同版本启动参数略有差异以下使用常见形态。部分版本可能把--model-path简写为--model请以你安装版本的--help输出为准。python3 -m sglang.la