企业官网建设流程全解析

很多做 AI 应用的团队都有一种误解：文生图服务的延迟，主要取决于模型参数量，想降低延迟就只能换更贵的 GPU。但真正在生产环境部署过 Qwen-Image 这类扩散模型的工程师会知道，瓶颈往往不在“算得慢”，而在“等得久”。请求在调度器里排队、去噪步骤之间反复读写显存、每一步都启动独立的 Python 算子、完全不做中间结果复用，这些开销在工程层面全部可控。

Baseten 最近公开的一个优化案例很有代表性：用 SGLang 搭配 B300 部署 Qwen-Image，端到端延迟下降了 42.3%。表面看，这是一个“换新硬件”的新闻；但懂推理服务的人会立刻意识到，单靠换卡不可能凭空省出四成延迟。真正起作用的一定是组合优化：B300 提供了更大的显存带宽底座，SGLang 则把请求调度、去噪循环、缓存复用整合到同一套框架里，Baseten 再把两者调到合适的配置。

这篇文章想把这套组合拳拆开来讲：图像生成请求的延迟到底从哪里来；SGLang 为什么适合承接 Qwen-Image 这类视觉生成负载；B300 在中间扮演什么角色；如果你要在自己的环境里复现类似优化，应该从哪一步开始，以及最容易踩到哪些坑。这里的重点不是记住 42.3% 这个数字，而是理解它背后的工程判断。

1. 为什么图像生成延迟比文本生成更难优化

文本生成模型的输出是 token，用户看到“首字”只需要几百毫秒，后续内容可以边生成边显示。图像生成模型完全不同，用户看到一张图之前，服务端已经把整个去噪过程全部跑完，期间用户只能等待。也就是说，交互式图像应用的体验好坏，几乎完全取决于端到端延迟，而不是每秒能生成多少张图。

吞吐高不等于延迟低。GPU 利用率很高的服务，如果调度器不做区分，新请求可能要在队列里等好几个批次。对文本生成来说，这种等待偶尔还能接受；对图像生成来说，额外多等几秒，用户可能已经离开了页面。因此，图像生成服务的性能指标体系，必须把延迟放在最前面。

文本生成和图像生成的核心差异，可以归纳为一张表：

这张表解释了标题里 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 的对比也是社区里高频出现的问题。两者都是优秀的推理服务框架，但设计取舍有明显差异：

图像生成这种“中间结果复用价值极高”的工作负载，与 SGLang 的设计思路天然契合。这也是为什么 Baseten 会选择它，而不是继续沿用传统的批处理方案。

2.3 B300：更大的显存带宽意味着什么

B300 属于英伟达 Blackwell 系列面向大规模推理的演进版本。相比上一代 GPU，它的迭代重点集中在显存容量和显存带宽。这里不具体堆参数，只说它对图像生成产生的决定性影响。

扩散模型的去噪循环，每个 step 都要把整份激活张量写入显存、读回、再写入下一层。整个过程里 GPU 算力不一定时刻吃满，显存带宽却很容易打满。如果带宽不够，算力再高也只能等着数据搬运。B300 在带宽上的提升，相当于给去噪 pipeline 加宽了数据通路，让每一步计算都能更快拿到数据。

但必须强调：带宽要真正转化为延迟收益，框架必须先做好两件事。一是把请求切分到合适的 GPU 并行粒度，二是减少无意义的显存读写。如果框架依旧在 step 之间频繁等待，或者对同一份中间特征反复拷贝，带宽升级也会被调度开销吃掉。B300 是必要条件，不是充分条件。

3. 延迟到底从哪里来：一次 Qwen-Image 请求的链路拆解

要优化延迟，就必须先把链路拆开。一次典型的 Qwen-Image 请求，大致会经历以下阶段：

1. 网关接收 HTTP 请求，进行鉴权、路由、限流。
2. 文本编码：把用户输入的 prompt 转成语义向量。
3. 扩散去噪循环：执行一定数量的步，在潜空间里逐步生成图像。
4. VAE 解码：把潜变量还原成像素图。
5. 结果编码和返回：图像序列化为 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 脚本分发到 GPU，CPU 与 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 很难继续缩短。

组合优化的执行过程也不是“一键开启”。更常见的路径是先压测找瓶颈，再逐项调整：

1. 在现有硬件上先用 SGLang 部署 Qwen-Image，跑一轮基准，记录吞吐、p50、p95、显存占用和 GPU 利用率。
2. 开启缓存和 CUDA Graph，观测延迟变化。如果变化不明显，说明瓶颈不在计算启动，而在访存或排队。
3. 换到 B300 或更高带宽硬件，保留上一轮框架配置，再跑一轮压测。
4. 根据结果调整并发上限、静态显存占比、batch 大小。
5. 最后关注极端场景：请求密集到达时 p95 是否恶化，长 prompt 是否拖慢第一条请求。

这套流程并不神秘，但每一步都要用数据做决策。42.3% 只属于特定测试条件。真正值得复制的是这个“先指标化，再逐项对比”的方法论。

6. 最小可复现的延迟优化与验证示例

下面的示例用来跑通“服务启动 + 请求测量”的完整链路。具体参数会因为版本和环境不同，但步骤可以照做。

6.1 环境准备

• 操作系统：Linux 发行版，生产环境推荐 Ubuntu Server。
• Python：3.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