DiFlow：扩散模型工作流的微服务调度（SOSP 2026）
原题：DiFlow: A System for Micro-Serving Text-to-Image Diffusion Workflows
一句话总结：整条扩散工作流绑定一张 GPU 会重复装载共享模型，也无法只扩容瓶颈阶段。DiFlow 将模型执行编译为可独立调度的节点，用 GPU 直传张量、共享已加载模型和逐请求并行度选择来服务混合工作流；在所测真实轨迹上，以 90% SLO 达标率为门槛，最高承受基线 3 倍请求率（§7.2）。
问题与动机
不同用户工作流可能共用同一个基础扩散模型，却在条件控制、风格适配器或文本编码器上不同。单体部署会为每种组合复制基础模型；若只扩容某个热点 ControlNet，也得复制整条链。图 1 表明同一基础模型在多个工作流中出现，拆分节点能改变资源成本和扩容粒度（§1–§2）。
关键观察 / 隐含假设
- 共享与扩缩粒度错位：相同基础模型出现在多个工作流里，单体部署却按工作流复制。在两张 H800 上比较 ControlNet 和非 ControlNet 工作流，复用已加载模型使延迟最多降 40%、显存最多降 60%；只扩基础模型而非整条 SD3/Flux 工作流，模型加载造成的扩容延迟最多降 90%（§3.1、图 3–4）。前提是工作流确有共同模型且跨节点传输成本可控。
- 不同模型的延迟—吞吐曲线不同：基础扩散模型是主要耗时阶段；并行度固定为 1 会浪费空闲 GPU，固定为 2 又可能因为等待一对 GPU 而排队。四张 H800 上，逐请求选择并行度的平均服务速度相对两种固定策略分别快 1.3×、1.2×（§3.1、图 4）。
- 中间数据以 GPU 张量为主：SD3/Flux 工作流传输数据中 CUDA 张量占比超过 99%；一个带 ControlNet 的 SDXL 工作流传输 5.3 GiB。若节点拆分后还经 CPU 中转，理论上的共享收益可能被 PCIe 拖垮（§4.3.2）。
核心方法
从工作流代码到模型级 DAG
模型开发者实现 setup_io()、load()、execute()；工作流开发者通过模型调用和 add_patch() 描述依赖、适配器及 Python 控制流。编译器在注册时生成模型执行节点及逻辑数据流，请求到来时实例化该 DAG（§4.1–§4.3、图 5、表 1）。编译器还能把近似缓存改写为缓存查找节点，并把 LoRA 加载前移、与早期去噪步骤异步重叠（§4.2）。这比简单按函数切碎重要：它保留了扩散流程的重复去噪、ControlNet 与基础模型交错、适配器补丁等语义。
控制面：依赖就绪、批处理和准入
节点的非延迟输入满足后进入全局就绪队列。调度器将同模型节点合批，对候选 GPU 按数据获取时间、模型加载时间和推理时间估分，优先复用已加载副本（§5.1、算法 1）。每个 batch 可按当前空闲 GPU 数和该模型的有效并行上限选择潜变量并行度，因此相同模型的不同请求也可能用不同 GPU 数（§5.2）。准入控制估计在途请求剩余关键路径与新请求完成时间；若预测会错过 SLO，提前拒绝。论文的 SLO 达标率分母包含被拒请求，故不能靠随意拒绝提高指标（§5.3、§7.1）。
数据面：GPU 原生传输与延迟获取
每张 GPU 的 executor 带本地 data store，基于 NVSHMEM 通过 NVLink/RDMA 获取张量，避免 CPU 中转（§4.3.2、图 8）。默认 eager 获取要求输入完整后启动节点；deferred 获取让基础扩散模型先跑，到真正消费 ControlNet 输出时才阻塞等数据。这样 ControlNet 与基础模型计算可以重叠，而不必为了依赖关系串行化。中间张量不可变、最后一个消费者用完后可回收，这也是无需复杂一致性协议的关键假设。与 Janus-SOSP26 的多模型共置相比，DiFlow 还需要维护工作流 DAG 和跨 GPU 中间张量生命周期。
设计取舍
- 独立扩容换跨节点开销：节点可复用，但像 SDXL+ControlNet 的 5.3 GiB 张量流让 NVLink/RDMA 成为部署前提；若网络慢或节点跨很远，拆分可适得其反。
- 共享模型换干扰风险：不同租户和工作流共用基础模型时，排队与显存状态耦合。
- 自适应并行换策略复杂度：调度评分依赖离线测得的模型时间；请求分辨率、去噪步数、适配器组合变化时可能失准。
- 提前拒绝换已准入请求稳定性：它保护已接纳请求的 SLO，但新请求会被拒绝；必须同时看完成率和拒绝率。
实验与结果
- 评测边界：四种基础模型（SD3、SD3.5-Large、Flux-Schnell、Flux-Dev）组成 12 条工作流，2.5B–12B 参数、4–50 去噪步；真实硬件为 8–32 张 H800，256 GPU 规模通过模拟器评估。到达过程取真实文生图生产轨迹及其变体，基线为 Diffusers、Clockwork 风格 Diffusers-C、Shepherd 风格 Diffusers-S；相同输入的生成图像与 Diffusers 一致（§7.1、表 2）。
- 端到端：以所有提交请求中至少 90% 在截止时间内完成为目标，相比最强基线 Diffusers-S，最高容纳 3 倍到达率；在某些高负载设置 DiFlow 达标率仍 >90%，基线 <3%。SLO 时间默认为单请求独占推理时间的 2 倍（§7.2、图 9）。
- 突发、紧 SLO、硬件：Flux 混合工作流在 16 GPU 上，达标率在流量变异系数（CV）高 8 倍时仍保持较高；默认流量下 DiFlow 的 SLO scale=2 可超过 90%，基线要到 scale=12 才达到同水平；达 90% SLO 所需 GPU 最高少 3 倍。这里“8 倍突发”是 CV 倍数，不是平均请求速率 8 倍（§7.2、图 9）。
- 组件消融：16 GPU、Flux 混合工作流中，开启模型共享在三个到达率设置下让达标率分别由 86→100%、35→100%、22→92%；开启自适应并行在最严格 SLO scale=1 下提高达标率 19%（§7.3、图 10）。LoRA 热切换占 886 MiB、100 ms，避免重新加载 SD3 基础模型的 3.9 GiB、430 ms（§7.3）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| 模型级拆分提高容量使用 | 90% SLO 达标率下最高 3 倍到达率（§7.2、图 9） | 12 工作流，8–32 H800，生产轨迹变体 | 强（该集合） |
| 共享是关键收益源 | 关闭共享后达标率从 92% 降至 22%（最高负载点，§7.3、图 10） | Flux 混合工作流，16 H800 | 强（该消融） |
| 拆分没有破坏生成语义 | 与 Diffusers 同输入生成图像一致（§7.1） | 所测工作流输入 | 中 |
| 处理突发能力更强 | 到达过程 CV 扩大 8 倍时仍较高达标率（§7.2、图 9） | 平均到达率保持不变的重采样轨迹 | 中 |
批判性分析
论证链条
图 3–4 的单机共享、扩容和并行度测量分别支持三个设计动机；图 10 的关组件消融证实共享和自适应并行都有独立贡献。端到端 3 倍和 CV 8 倍来自不同自变量，不能相乘。图像一致性检查支持重排执行不改结果，但没有覆盖随机种子、算子版本与跨模型更新的所有组合。
假设压力测试
若工作流几乎没有共享模型，节点拆分会保留数据传输成本却失去复用收益。若生成步数非常少，中间数据传输可能占比较大；若租户隔离要求不能共用基础模型，调度空间会缩小。
实验可信度
12 条工作流、四种基础模型、真实生产到达轨迹、三种单体策略基线及关闭组件实验，比单一玩具工作流充分。但所有真实硬件结果最高 32 张 H800，256 GPU 是模拟；多租户隔离、跨区域网络和显著更高分辨率下，3 倍收益不能直接外推。核心指标是含拒绝请求的 SLO 达标率，仍应同时查看完成请求的 P99 和拒绝率。
系统性缺陷
跨节点执行要处理部分节点失败、模型版本兼容和中间张量生命周期。论文未充分讨论多租户共享基础模型时的访问隔离和计费归因。
局限与后续工作
- 扫描工作流共享率、图像分辨率、节点数量和网络带宽，找出拆分比单体部署更差的边界。
- 注入节点失败与模型版本不一致，测量重试是否会重复执行长迭代阶段。
相关
- 同会议：SOSP-2026；相邻系统：Janus-SOSP26 的多模型资源放置、ACDC-SOSP26 的离线吞吐优先调度。
- 全文：作者公开 PDF。