GF-DiT：把 GPU 并行度当作可调度资源的扩散 Transformer 推理系统

笔记日期： 2026-06-14 笔记作者： Zhongzhu Zhou 论文标题： GF-DiT: Scheduling Parallelism for Diffusion Transformer Serving 作者： Xinwei Qiang, Yifan Hu, Shixuan Sun, Jing Yang, Han Zhao, Chen Chen, Yu Feng, Jingwen Leng, Minyi Guo arXiv： 2606.13501v1，2026-06-12 状态/场馆： arXiv 预印本（上海交通大学）

一句话总结

GF-DiT 把 GPU 并行度当成一等公民可调度资源，通过轨迹任务图（每个去噪步骤都是独立可重新调度的任务）和无组通信原语（group-free collectives，组建开销从 778 ms 降至约 60 μs），实现了在扩散 Transformer 推理过程中按需动态调整并行度，在图像/视频生成混合负载下吞吐量提升最高 6.01 倍、平均延迟降低最高 95%。

1. 前置知识

GF-DiT 涉及四个技术领域的交叉：扩散模型架构、GPU 集合通信、序列并行，以及推理系统调度。下面对每部分做深入铺垫。

1.1 扩散模型与去噪过程

扩散模型（Ho et al., 2020; Song et al., 2021）的核心思想是学习逆转一个逐步加噪的马尔科夫链。训练阶段，模型学习在各噪声级别上去除噪声；推理阶段，从纯高斯噪声 $x_T \sim \mathcal{N}(0, I)$ 出发，通过 $T$ 步迭代去噪生成图像或视频：

$$x_{t-1} = \frac{1}{\sqrt{\alpha_t}}\left(x_t - \frac{1 - \alpha_t}{\sqrt{1 - \bar{\alpha}_t}} \epsilon_\theta(x_t, t, c)\right) + \sigma_t z \tag{1}$$

其中 $\alpha_t$ 是噪声调度参数，$\bar{\alpha}_t = \prod_{s=1}^{t} \alpha_s$，$\epsilon_\theta(x_t, t, c)$ 是学到的去噪网络（受文本/图像提示词 $c$ 条件化），$\sigma_t$ 是步长相关的噪声系数，$z \sim \mathcal{N}(0, I)$ 是额外注入的噪声。

推理计算量的异构性：去噪网络 $\epsilon_\theta$ 需要被调用 $T$ 次（DDIM/流匹配采样器中 $T \in [20, 100]$）。单次调用的 FLOPs 正比于 latent 序列长度 $L$（图像分辨率越高、视频时长越长，$L$ 越大）。总计算量：

$$\text{FLOPs}_{\text{请求}} \approx T \times \text{FLOPs}_{\text{去噪器}}(L, d) \tag{2}$$

举个具体例子：生成 4 秒 1080p 视频（$L \approx 4096$，$T = 50$）与生成 256×256 缩略图（$L \approx 256$，$T = 20$）之间的计算量差距约为 400 倍。这是静态并行系统面临的核心挑战：无法用一套固定配置同时高效服务如此差异巨大的请求。

1.2 扩散 Transformer（DiT）架构

扩散 Transformer（Peebles & Xie, 2023）用 Transformer 骨干替代了早期扩散模型常用的 U-Net，将图像或视频的 latent 切分为 patch 并作为序列 token 输入 Transformer。典型结构如下：

输入 latent（图像/视频）
  → Patchify（例如 2×2 空间 patch）
  → 线性投影到 d_model 维
  → 加位置编码
  → N × DiT Block：
      |- AdaLN-Zero：用时间步 t 和条件 c 的嵌入调整 scale/shift
      |- 多头自注意力（双向，全 patch 之间）
      |- AdaLN-Zero
      |- 前馈网络（FFN）
  → Unpatchify
  → 输出噪声预测 ε 或干净图像预测 x₀

与 LLM Transformer 的关键区别：DiT 使用双向（非因果）自注意力，每个去噪步骤中所有 latent token 互相关注。这意味着：

• 没有 KV-cache 的递增累积（与自回归 LLM 不同）
• 每步注意力代价为 $O(L^2 d)$，对长序列（视频）非常昂贵
• 没有适合中途截断的”前缀完成”语义——一个步骤中间断掉无法得到语义完整的中间状态

现代主流 DiT 模型包括：万象（Wan 2.1）、混元视频（HunyuanVideo）、CogVideoX、Open-Sora 2.0、FLUX 等。

1.3 DiT 推理的三阶段流水线

每个 DiT 推理请求包含固定的三个阶段：

阶段一——文本/图像编码（Encode）：用 CLIP、T5 等编码器将提示词转化为条件嵌入 $c$。计算量很小（通常只有单次去噪步骤的 1/10 到 1/30），序列很短。GPU 并行度越高往往效率越低（通信开销超过计算收益）。最优 SP 度 = 1。

阶段二——去噪轨迹（Denoising）：DiT 模型执行 $T$ 步去噪，主导整个推理时间（>95%）。长序列视频从序列并行（SP）受益显著：$L = 4096$ 时，从 SP=1 到 SP=4 大致是线性加速；$L = 256$ 时，SP > 2 反而增加延迟（通信开销超过计算收益）。

阶段三——VAE 解码（Decode）：变分自编码器将最终的 denoised latent 解码为像素空间图像或视频帧。计算量适中，最优 SP 度通常在 2–4 之间，具体取决于分辨率。

静态并行的困境：现有系统（如 vLLM-Omni、SGLang Diffusion）给整个请求分配固定的 SP 度（例如 SP=4）：编码阶段浪费 3 个 GPU，小图片去噪反而变慢，VAE 解码可能略显不足。没有一个固定配置能在所有阶段、所有请求形状下都是最优的。

1.4 序列并行（Sequence Parallelism, SP）的原理与代价

序列并行将长度为 $L$ 的序列分散到 $P$ 个 GPU 上，每个 GPU 持有 $L/P$ 个 token 的本地数据。自注意力计算需要 All-Gather 操作（汇聚其他 GPU 的 K 和 V 矩阵）。

通信与计算的权衡：

$$\text{并行效率}(P) = \frac{\text{单 GPU 时间}}{P \times \text{多 GPU 时均时间}} \tag{3}$$

• 短序列：All-Gather 通信开销主导，效率远低于 $1$（加 GPU 反而变慢）
• 长序列：计算主导，效率趋近 $1$（接近线性加速）

这个特性决定了最优 SP 度随请求形状（序列长度）变化，是 GF-DiT 弹性并行的核心动机之一。

1.5 GPU 集合通信与 NCCL

GPU 集合通信（AllReduce、AllGather、ReduceScatter 等）是分布式深度学习的基础，NCCL（NVIDIA Collective Communications Library）是标准实现。

NCCL 通信子（communicator）：ncclComm_t 是一个不透明句柄，代表参与同一集合通信操作的一组 GPU。在任何集合通信执行之前，必须通过 ncclCommInitRank 完成通信子的初始化，涉及：

1. 引导（Bootstrap）：各 rank 通过带外服务器交换 IP 和端口
2. 拓扑检测：查询 NVLink、PCIe 和 NUMA 拓扑
3. 传输选择：决定使用 NVLink 还是 PCIe/网络
4. 环/树构建：构建最优集合通信路由
5. 缓冲区分配：分配 pinned host 和 device 内存

在静态系统中，这个初始化只在启动时发生一次，开销被平摊到成千上万个请求上。在弹性系统中，每次改变执行组成员都需要重新创建通信子——论文测量的开销高达 778 ms，远超单次去噪步骤的执行时间（50–200 ms），使得弹性并行在实践中完全不可行。

1.6 Head-of-Line（HOL）阻塞问题

来自网络包调度的经典问题：队列头部的大型请求阻塞了后面的小型请求。在 DiT 推理中，一个大型视频生成请求（需要 2 分钟计算）独占 SP=4 的 4 个 GPU，导致后续到达的小图片请求（只需几秒）必须等待，即使其他 GPU 空闲。

静态并行使 HOL 阻塞更严重：一旦请求开始，GPU 分配不可改变，系统无法中途抢占或重新分配资源。

2. 系统总览：GF-DiT 架构

GF-DiT 是一个运行时系统，位于推理前端（请求队列）和 GPU 执行层（DiT 模型计算）之间。整体架构如下：

graph TB
    FE["推理前端\n（请求队列）"] --> TG["轨迹任务图\n生成器"]
    TG --> RT["GF-DiT 运行时\n（异步执行器）"]
    RT --> PI["策略接口\n（可插拔调度器）"]
    PI --> GFC["无组通信原语\n（通信层）"]
    GFC --> GPU["GPU 工作进程\n（DiT 模型执行）"]
    GPU -- "任务完成 + 状态" --> RT
    RT -- "调度决策" --> PI

图 1：GF-DiT 系统架构。 请求被分解为轨迹任务图；异步运行时将调度决策暴露给可插拔策略接口；无组通信原语在约 60 μs 开销内完成 GPU 组重配置。

核心设计决策是将调度策略（每个任务应该用什么并行度？）与运行时机制（如何以给定并行度执行任务？）分离。这种分离使 GF-DiT 具有可编程性：相同的运行时支持截然不同的服务目标。

3. 核心抽象：可重新调度的轨迹任务

3.1 轨迹任务图（Trajectory Task Graph）

GF-DiT 将每个 DiT 请求表示为一个轨迹任务图——一个有向无环图（DAG），节点是轨迹任务，边是制品（artifact）依赖。

定义（轨迹任务）：轨迹任务 $\tau$ 代表一个语义上完整的 DiT 计算单元：或者是模型阶段（编码、VAE 解码、latent 准备），或者是单个去噪步骤 $t \in \{T, T-1, \ldots, 1\}$。完成任务 $\tau$ 产生一个定义明确、可转移的模型状态。

定义（制品）：制品 $a$ 是在任务之间传递信息的命名张量，例如：

• $a_{\text{embed}}$：编码器生成的条件嵌入，被所有去噪步骤消费
• $a_t$：去噪步骤 $t$ 生成的 latent 状态 $x_t$，被步骤 $t-1$ 消费
• $a_{\text{final}}$：最终 denoised latent $x_0$，被 VAE 解码器消费

一个含 4 步去噪的请求的轨迹任务图：

graph LR
    ENC["编码\n(文本→嵌入)"] --> D4["去噪\n步骤 T=4"]
    D4 --> D3["去噪\n步骤 T=3"]
    D3 --> D2["去噪\n步骤 T=2"]
    D2 --> D1["去噪\n步骤 T=1"]
    D1 --> DEC["VAE 解码\n(latent→像素)"]
    ENC -- "a_embed" --> D3
    ENC -- "a_embed" --> D2
    ENC -- "a_embed" --> D1

图 2：4 步去噪请求的轨迹任务图。 每个节点都是一个独立可调度的任务，边表示制品依赖（执行顺序）。条件嵌入 $a_{\text{embed}}$ 被所有去噪步骤共享。

3.2 为何步骤边界是安全的重新调度点

与 LLM 推理对比：在自回归 LLM 推理中，每生成一个 token，KV-cache 就增长一步，中间状态被完整保存——每个 token 边界都是安全的调度点。DiT 去噪本质上不同：单个去噪步骤内，DiT 对所有 latent token 做双向注意力，中途断开得不到语义有效的中间状态（部分更新的 latent 不能被 VAE 解码器解释）。唯一安全的调度点在步骤边界上。

步骤边界的安全性保证：完成去噪步骤 $t$ 会生成 latent $x_{t-1}$，这是去噪轨迹上的一个格式良好的张量。步骤 $t-1$ 以 $x_{t-1}$ 为输入，对步骤 $t$ 的内部状态一无所知（没有隐状态，没有进行中的计算）。运行时可以：

1. 将 $x_{t-1}$ 保存为逻辑制品
2. 将步骤 $t$ 使用的 GPU 归还资源池
3. 在下一次调度决策时，为步骤 $t-1$ 分配可能完全不同的 GPU 组合
4. 在不损失正确性的情况下继续计算

3.3 执行布局与策略接口

GF-DiT 的调度决策是一个从就绪轨迹任务到执行布局的函数：

$$\text{schedule}: \tau \mapsto (\mathcal{G}, \Pi) \tag{4}$$

其中：

• $\mathcal{G} = \{g_0, g_1, \ldots, g_{P-1}\}$ 是逻辑执行组——将共同执行这个任务的 GPU ID 有序集合
• $\Pi$ 是并行规格——例如 SP=4 表示在 4 个 GPU 上做序列并行，CP=2 表示上下文并行

策略（Policy） 实现调度函数，通过统一的策略接口：

class GFDiTPolicy:
    def schedule(self, ready_tasks: List[TrajectoryTask],
                 gpu_pool: GPUPool,
                 system_state: SystemState) -> Dict[TrajectoryTask, ExecutionLayout]:
        """
        输入：
          ready_tasks:  制品依赖已满足的就绪任务
          gpu_pool:     当前空闲的 GPU
          system_state: 队列长度、各请求进度、SLO 截止时间
        输出：
          就绪任务到执行布局的映射
        """
        raise NotImplementedError

基于这个统一接口，GF-DiT 支持多种调度策略：

策略类型	优化目标	调度逻辑
吞吐量导向	最大化请求/秒	分配最小可行 SP；最大化并发度
延迟导向	最小化平均延迟	为每个请求分配最大 SP
SLO 感知	最小化 SLO 违规率	优先调度最接近 deadline 的请求
公平调度	均衡化各请求服务速率	循环分配 GPU
自定义	用户自定义	对 system_state 的任意 Python 逻辑

3.4 预测性执行结构

使 GF-DiT 调度有效的一个关键属性是：DiT 请求的执行在开始之前就基本可预测。

请求在接入时就指定了输出分辨率（$H \times W$ 或 $H \times W \times F$）和去噪步骤数 $T$，运行时由此可以：

1. 计算 latent 序列长度：$L = (H \cdot W \cdot F) / (p^2 \cdot t_{\text{vae}})$，其中 $p$ 是 patch 大小，$t_{\text{vae}}$ 是 VAE 时间压缩率
2. 枚举轨迹任务：恰好 1 个编码任务 + $T$ 个去噪任务 + 1 个解码任务
3. 估计每任务代价：从离线性能表中查找

$$\hat{c}(\tau, P) = \text{lookup}(L_\tau, \text{model}, P) \tag{5}$$

其中 $L_\tau$ 是任务 $\tau$ 的 latent 序列长度，$P$ 是 SP 度。这个估计精度在几个百分点内，使策略能在执行前推理不同调度决策的后果。这与 LLM 推理形成对比——LLM 在生成完成之前无法知道输出长度。

算法 1：GF-DiT 主调度循环（伪代码）

算法 1：GF-DiT 主调度循环
─────────────────────────────────────────────────────
 1: 初始化：gpu_pool ← 所有 GPU；task_queues ← {}
 2: while 推理系统运行中 do
 3:   # 请求接入
 4:   for 到达队列中的每个新请求 r do
 5:     G_r ← build_trajectory_task_graph(r)
 6:     task_queues.add(G_r)
 7:   end for
 8:
 9:   # 识别就绪任务（依赖已满足）
10:   ready ← {τ ∈ task_queues : τ 的所有制品都已就绪}
11:
12:   # 策略决策
13:   decisions ← policy.schedule(ready, gpu_pool, system_state)
14:
15:   # 派发已调度任务
16:   for 每个 (τ, layout) ∈ decisions do
17:     gpu_pool.reserve(layout.group)
18:     async_execute(τ, layout)    # 非阻塞；GPU 工作进程执行
19:   end for
20:
21:   # 处理完成事件（事件驱动）
22:   for 每个完成的任务 τ_done do
23:     gpu_pool.release(τ_done.group)
24:     publish_artifacts(τ_done)        # 使输出制品可用
25:     if τ_done.request.is_complete() then
26:       deliver_response(τ_done.request)
27:     end if
28:   end for
29: end while

这个循环是完全异步的：任务派发（第 18 行）不阻塞，完成事件驱动——使调度器可以同时向不同 GPU 组派发多个任务，并在完成时立即响应。

4. 无组通信原语：消除通信子开销

这是 GF-DiT 技术上最具新颖性的贡献。

4.1 根因分析：为何 NCCL 通信子初始化那么慢？

NCCL 通信子初始化（ncclCommInitRank）包含以下步骤：

步骤 1——引导（Bootstrap）：所有 rank 通过带外引导服务器交换 IP 地址和端口，建立 TCP 连接以完成汇聚。

步骤 2——拓扑检测：NCCL 查询操作系统和 CUDA 驱动程序，发现 NVLink、PCIe 和 NUMA 拓扑。

步骤 3——传输选择：根据拓扑为每对 rank 决定使用 NVLink（快，低延迟）还是 PCIe/网络（慢）。

步骤 4——环/树构建：为 AllReduce 构建最优环，为 Broadcast/Reduce 构建最优树。

步骤 5——缓冲区分配：每个 rank 分配 pinned 主机内存和设备内存作为通信缓冲区。

在静态推理系统中，以上步骤在启动时执行一次，开销被平摊到数千个请求上，可以忽略不计。在弹性系统中，每次更改执行组成员（例如从 SP=4 切换到 SP=2）都需要重新执行所有步骤——论文实测开销达 778 ms。由于单次去噪步骤只需 50–200 ms，组建开销是计算时间的 3–15 倍，弹性并行在实践中完全无法落地。

4.2 无组通信原语的设计

GF-DiT 的洞察是：对于推理工作负载，系统拓扑在启动时就已确定，传输选择也固定不变。无组通信原语利用这一点，用逻辑组描述符引用预先建立的点对点通信通道，完全跳过通信子初始化阶段。

定义（逻辑组描述符）：$\mathcal{D} = (G, \Pi, \text{layout})$ 指定：

• $G = \{g_0, \ldots, g_{P-1}\}$：参与此次集合通信的 GPU ID 集合
• $\Pi$：并行规格（SP/TP 度）
• $\text{layout}$：数据张量当前在 $G$ 中各 GPU 上的分片方式

不同于分配新的通信缓冲区并构建传输树，无组通信原语使用覆盖系统中所有 GPU 对的预分配通信池，在运行时通过逻辑描述符选择所需子集。

算法 2：无组 AllGather

算法 2：无组 AllGather(tensor x, descriptor D)
─────────────────────────────────────────────────────────
输入：x = 本地持有的分片（大小 L/P × d）
      D = {G = {g₀,...,g_{P-1}}, P, layout="序列并行"}
输出：y = 完整张量（大小 L × d），对 G 中所有 rank 可用

 1: rank ← local_rank_in(D.G)   # O(1) 字典查找，无网络调用
 2: y ← allocate_output(L × d)
 3: # 将本地分片复制到对应位置
 4: y[rank*(L/P) : (rank+1)*(L/P), :] ← x
 5:
 6: # 使用预建立的通信通道与其他 rank 交换数据
 7: for step in 1 .. P-1 do
 8:   send_rank ← (rank + step) mod P     # 环式通信伙伴
 9:   recv_rank ← (rank - step) mod P
10:   src_slice ← (send_rank*(L/P), (send_rank+1)*(L/P))
11:   # 使用 (rank, send_rank) 对预分配的 NVLink/PCIe 缓冲区
12:   async_send(channel[rank, send_rank], x, tag=step)
13:   async_recv(channel[recv_rank, rank], y[src_slice], tag=step)
14: end for
15: wait_all()    # 仅在 D.G 内的 P 个 rank 之间做屏障
16: return y

与 NCCL 的关键区别：第 1 行（local_rank_in(D.G)）是 O(1) 字典查找，无网络同步。第 12–13 行使用全局通信池中预建立的点对点通道——不存在组初始化阶段。第 15 行的屏障只涉及 $P$ 个 rank，使用轻量级 CUDA 事件而非 NCCL 同步原语。

4.3 开销对比

方法	组建时间	每次集合通信额外开销
NCCL ncclCommInitRank	~778 ms	~0（已平摊）
GF-DiT 无组通信原语	~60 μs	~5–10 μs（描述符查找）
加速比	~13,000×	—

13,000 倍的组建加速是弹性并行可落地的基础。假设一个去噪步骤在 2 个 GPU 上需要 100 ms，组建新通信组的开销现在只占步骤时间的 0.06%，而非 778%——彻底可以忽略不计。

4.4 布局感知制品迁移

当两个相邻轨迹任务的 SP 度不同时，制品（latent 张量）必须重分片以匹配新布局。

例子：任务 $\tau_t$ 以 SP=4 执行（张量 $x_{t-1}$ 分布在 GPU 0–3 上，每个持有 $L/4$ 的分片）。任务 $\tau_{t-1}$ 以 SP=2 执行（GPU 0–1）。制品 $a_{t-1} = x_{t-1}$ 必须先从 4 个分片汇聚（All-Gather），再重新切分为 2 个分片。

GF-DiT 自动化处理布局感知制品迁移：

$$\text{migrate}(a, \mathcal{D}_{\text{src}}, \mathcal{D}_{\text{dst}}) = \text{shard}(\text{gather}(a, \mathcal{D}_{\text{src}}), \mathcal{D}_{\text{dst}}) \tag{6}$$

迁移本身使用同一套无组通信原语实现（AllGather 撤销源分片，ReduceScatter 或 slice 应用目标分片），无需额外的通信子开销。

迁移代价：对于典型的 latent 张量（例如 1 GB 视频 latent），SP=4 到 SP=2 的迁移需要通过 NVLink 移动约 0.5 GB 数据（NVLink 带宽 600 GB/s，耗时约 1 ms），远小于任务执行时间（50–500 ms），还可与 CPU 上的下一次调度决策重叠执行，从而几乎完全隐藏。

5. 运行时实现

5.1 异步执行模型

GF-DiT 运行时实现完全异步的事件驱动执行。核心数据结构：

制品存储（ArtifactStore）：
  {artifact_id → (tensor_data, layout_descriptor, gpu_locations)}

任务队列（TaskQueue）：
  {task_id → TrajectoryTask}

待完成集合（PendingCompletions）：
  {future → (task_id, completion_callback)}

调度循环运行在 CPU 上，完全非阻塞——它从不等待 GPU 任务完成后再做下一次调度决策。这允许系统同时在不同 GPU 组上并发执行多个任务：

graph TB
    subgraph "GPU 0-3 (SP=4)"
        VA["视频请求 A：去噪步骤 30 (200ms)"]
    end
    subgraph "GPU 4-5 (SP=2)"
        IB["图像请求 B：编码 (50ms) → 去噪 (150ms)"]
    end
    subgraph "GPU 6 (SP=1)"
        DC["请求 C：VAE 解码 (80ms) → 空闲 → 新编码"]
    end
    subgraph "GPU 7 (SP=1)"
        ND["请求 D：编码 (50ms) → 去噪"]
    end

图 3：GF-DiT 在 8 个 GPU 上的弹性并发执行。 同一时刻，GPU 组 0–3（SP=4）处理大型视频去噪步骤；GPU 4–5（SP=2）服务中型图像请求；GPU 6 和 7 独立服务两个轻量请求。在静态并行系统下，8 个 GPU 会被单一配置锁定，无法实现这种并发。使用代价估计器（公式 5）预测任务执行时间，回放真实请求 trace。

仿真为何对 DiT 有效：因为 DiT 请求执行是可预测的（第 3.4 节），仿真精度高。这与 LLM 推理仿真形成对比——LLM 的输出长度在生成完成前未知，仿真必须依赖输出长度分布假设。

仿真工作流：

1. 收集代表性请求 trace（负载形状分布）
2. 用候选策略 + 性能数据表运行仿真
3. 测量仿真吞吐量、延迟 CDF、SLO 违规率
4. 在部署到真实 GPU 硬件之前选择或调优最优策略

5.3 SLO 感知调度策略示例

算法 3：SLO 感知调度策略

算法 3：SLO 感知调度（Schedule）
─────────────────────────────────────────────────────
输入：就绪任务 T、GPU 池 P、系统状态 S
输出：assignment: TrajectoryTask → ExecutionLayout

 1: assignments ← {}
 2: # 按紧急程度（距 deadline 剩余时间）排序就绪任务
 3: sorted_tasks ← sort(T, key=lambda τ: deadline(τ) - now())
 4:
 5: for τ in sorted_tasks do
 6:   remaining_work ← Σ_{τ' 在 τ 之后} ĉ(τ', 1)   # 最小并行度估计
 7:   time_budget ← deadline(τ.request) - now() - remaining_work
 8:
 9:   # 二分查找满足 deadline 的最小 SP 度
10:   best_SP ← 1
11:   for P_candidate in [1, 2, 4, 8] do
12:     if ĉ(τ, P_candidate) ≤ time_budget / remaining_steps(τ) then
13:       best_SP ← P_candidate   # 用满足需求的最小并行度
14:       break                    # 保留 GPU 给其他请求
15:     end if
16:   end for
17:
18:   # 若 GPU 充足则分配
19:   if gpu_pool.available() ≥ best_SP then
20:     G ← gpu_pool.allocate(best_SP)
21:     assignments[τ] ← ExecutionLayout(G, best_SP)
22:   end if
23: end for
24: return assignments

SLO 感知策略为每个任务分配恰好足够满足 deadline 的最小 SP 度，将多余的 GPU 释放给其他请求。在重负载场景下，这比延迟最小化策略（始终分配最大 SP）能显著提升整体 SLO 达成率，因为增加了系统并发度。

6. 实验评估

6.1 实验设置

GF-DiT 在 vLLM-Omni 中实现，在代表性负载上进行评估：

模型：Wan 2.1（T2V），HunyuanVideo（T2V），FLUX（T2I）

基线：

• 静态 SP4：固定 4-GPU 序列并行（现有主流方案）
• 静态 SP1：单 GPU 执行（无并行）
• Oracle：拥有完美未来知识的理想调度器

负载：

• 混合视频+图像请求（异构分辨率）
• 泊松到达过程（不同负载强度 λ）
• SLO 目标：P95 延迟 < K × 最小请求延迟

6.2 主要实验结果

吞吐量：在混合负载下，GF-DiT 相比静态 SP4 最多提升 6.01 倍。收益来自两个来源：①小请求不再在大请求后面等待（消除 HOL 阻塞）；②从过度配置阶段释放的 GPU 可以为额外的并发请求服务。

延迟：相比静态 SP4，平均延迟最多降低 95%。主要驱动因素是消除 HOL 阻塞：原本需要等待几分钟视频生成完成的图像请求，现在可以在空闲 GPU 上几毫秒内开始执行。

SLO 达成率：SLO 违规率最多降低 90%。SLO 感知策略（算法 3）特别有效：能提前识别面临 deadline 风险的请求并主动分配更多 GPU。

通信开销：无组通信原语将通信组建时间从 778 ms 降至约 60 μs。对于 $T = 50$ 个去噪步骤、每步可能发生 SP 变更的典型请求，这节省了高达 50 × 778 ms ≈ 39 秒的组建开销，而若用朴素弹性实现（标准 NCCL）则需承担。

pie title 各调度策略归一化吞吐量占比（SP4基线=1.0倍）
    "静态 SP1 (0.5倍)" : 0.5
    "静态 SP4 基线 (1.0倍)" : 1.0
    "GF-DiT 吞吐导向 (6.01倍)" : 6.01
    "GF-DiT SLO 感知 (4.8倍)" : 4.8

图 4：各调度策略吞吐量对比（论文结果示意值）。绝对吞吐量：静态 SP1 (0.5x)、静态 SP4 (1.0x，基线)、GF-DiT 吞吐导向 (6.01x)、GF-DiT SLO 感知 (4.8x)。GF-DiT 吞吐量导向策略相比静态 SP4 基线达到 6.01 倍；SLO 感知策略以适度吞吐量换取更好的 deadline 合规性。

6.3 各阶段异构性的实验验证

论文的动机实验（原文第 2 节）对各阶段的并行加速效果做了精细测量：

编码阶段（文本编码器）：随 SP 度从 1 增至 8，执行时间基本持平甚至上升——计算太轻量，GPU 间通信开销主导。最优 SP = 1。

去噪阶段（DiT 模型）：

• 大型视频请求（$L = 4096$）：从 SP=1 到 SP=4 近乎线性加速，SP=4 到 SP=8 次线性加速
• 小型图像请求（$L = 256$）：超过 SP=2 后延迟反而上升

VAE 解码阶段：适度加速，最优 SP 在 2–4 之间，取决于分辨率。

这些测量直接说明了问题所在：固定 SP=4 对编码阶段浪费 3 个 GPU，对小图像去噪反而有害，对 VAE 解码配置可能不当。GF-DiT 对所有这些情况动态处理——根据策略，每个阶段分配恰当的 SP 度。

6.4 制品迁移开销

论文测量了 latent 制品在不同 SP 配置间迁移的代价。对于典型的视频 latent 张量（500 MB–1 GB），迁移耗时 2–8 ms，远小于去噪步骤延迟（50–500 ms）。迁移还可与 CPU 上的调度决策计算重叠，净开销几乎为零。

7. 与相关工作的比较

系统	并行策略	调度粒度	组重配置	DiT 专用
vLLM-Omni（静态）	固定 SP	请求级	不适用	是
SGLang Diffusion	固定 SP	请求级	不适用	是
Alpa	静态自动并行	训练专用	不适用	否
Llumnix	可迁移请求	实例级	VM 迁移	LLM 专用
GF-DiT	弹性 SP，每任务	任务级	60 μs 无组通信	是

对比 Alpa：Alpa（OSDI 2022）自动化了训练的并行化策略选择，但产生的是静态计划——不在运行时适应。而且它面向训练，不面向推理。

对比 Llumnix：Llumnix（OSDI 2024）支持 LLM 请求在推理实例间的实时迁移。GF-DiT 是互补的——它在单个多 GPU 部署内操作，在任务粒度（而非实例粒度）上适配并行度。Llumnix 迁移请求；GF-DiT 适配请求的执行方式。

对比 disaggregated prefill-decode：DistServe（OSDI 2024）将 LLM 的 prefill 和 decode 分离到不同的 GPU 池。DiT 推理没有对等的 prefill/decode 区分（每个去噪步骤都像”decode”），因此 disaggregation 设计不直接适用。GF-DiT 的弹性调度是针对 DiT 工作负载更细粒度的解决方案。

8. 批判性分析：不足与可改进之处

8.1 不好的地方与缺陷

(a) 基线对比不充分：论文只对比了两个静态并行基线（SP1 和 SP4），缺少关键的”聪明静态”基线：

• 固定的阶段级并行（编码用 SP=1，去噪用 SP=4，解码用 SP=2）将捕捉第 2.3(a) 节识别的大部分阶段异构性收益，而无需任何运行时弹性。论文没有报告这个基线，难以评估细粒度任务级适配相比简单阶段级静态配置的额外价值。
• 基于抢占的方法：在阶段边界实现请求抢占（保存 latent 状态，让出 GPU）可以在不需要弹性并行度的情况下缓解 HOL 阻塞。论文没有实验评估这个”草人”基线。

(b) 6.01 倍的收益特异性：这个头条数据是在静态 SP4 配置恰好匹配最差的混合负载上获得的。论文没有报告同构负载（全视频或全图像）的结果，也没有展示不同负载组合下的收益分布，难以评估鲁棒性。

(c) 评估硬件范围有限：实验在 NVIDIA GPU 集群上进行，无组通信原语用 NCCL 模型描述。论文没有评估 AMD GPU（RCCL）或自定义互连（Google TPU ICI、AWS NeuronLink），不同硬件上的组建开销可能与 778 ms 有显著差异，限制了结论的普适性。

(d) 迁移代价数据不完整：“2–8 ms” 的制品迁移数据缺少分模型、分分辨率的明细。对于小模型、低分辨率（去噪步骤只需 ~10 ms）的场景，迁移开销可能不可忽略。

8.2 作者淡化或回避的局限

(a) 预建通信通道的初始化假设：无组通信原语假设系统启动时就预建了所有 GPU 对之间的点对点通信通道。对于大规模集群（例如 256 个 GPU），需要预建 $O(N^2)$ 条通道，论文未量化这一启动代价，也未讨论预分配通信缓冲区的内存占用。

(b) 突发流量下的策略稳定性：论文在泊松到达过程（方差较低）下评估策略。实际生产 DiT 工作负载存在突发模式（社交媒体活动、游戏事件）。论文未刻画 GF-DiT 在大量大型请求同时到达时的行为——而这恰恰是弹性并行最被需要、同时调度最困难的场景。

(c) 多模型异构性：GF-DiT 在同族模型上评估（所有都是大型 T2V/T2I DiT）。生产推理系统可能同时服务多个不同 DiT 模型，具有不同的权重布局和分片策略。论文未评估模型间切换的开销。

(d) 故障容错缺失：论文不涉及 GPU 故障场景。若执行组中某 GPU 在任务执行过程中故障，GF-DiT 运行时没有机制恢复请求的制品状态并将其重新分配给其他组。这对长时间运行的视频生成作业是严重的运维隐患。

8.3 可以改进的地方

(a) 增加固定阶段级并行基线：最自然的消融是固定每阶段的 SP 度（编码 SP=1，去噪 SP=4，解码 SP=2），而不做任务级动态适配。这个基线会揭示：GF-DiT 的收益有多少来自阶段级异构性（已有文献记录），有多少来自更细粒度的任务级适配（GF-DiT 的核心主张）。如果固定阶段级基线能捕获 70–80% 的收益，完整弹性并行的论证就被削弱；若仅捕获 <30%，则细粒度适配的必要性得到有力支持。

(b) 刻画策略与 Oracle 的差距：使用多种负载分布运行 Oracle 策略（利用离线未来知识），量化 GF-DiT 各策略与 Oracle 的差距。这将（i）界定改进空间，（ii）验证 GF-DiT 策略是否接近最优，或是否存在大幅改进余地。

(c) 将无组通信原语扩展到异构硬件：在 AMD ROCm/RCCL 上评估无组通信原语，确保实现不依赖 NCCL 特定内部机制。鉴于 AMD GPU 在 AI 基础设施中的日益普及，这将显著扩大论文的适用范围。

(d) 将抢占作为对比基线和补充机制：实现基于阶段边界的请求抢占（checkpoint-restore 语义），将其作为独立机制与 GF-DiT 弹性并行对比评估。抢占允许大型视频请求在阶段之间让出 GPU 给短请求，无需组重配置。比较将阐明哪种设计选择更有效，以及组合使用是否更有价值。

(e) 故障处理扩展：为制品存储增加检查点功能（将轨迹任务状态检查点到主机内存或存储），使中断的请求能在 GPU 故障或抢占后恢复，代价是适度的迁移开销。

9. 更广泛的影响与未来方向

GF-DiT 的核心抽象——将并行度视为可调度资源而非静态部署参数——在 DiT 推理之外具有重要意义：

推测解码中的弹性调度：推测解码在小草稿模型和大验证模型之间交替，每步都在两种执行配置间切换。GF-DiT 风格的弹性调度器可以根据接受率模式自适应地为草稿和验证阶段分配 GPU，减少验证阶段的空闲时间。

多模态推理：生产系统服务文本、图像、视频、音频的混合请求，计算需求差异巨大。GF-DiT 的框架可以扩展为通用的多模态推理系统，跨模态边界自适应地调整 GPU 分配。

弹性检查点训练：轨迹任务抽象（每步产生可转移状态）类似于训练中的微步检查点。支持微步检查点和恢复的训练系统可以使用 GF-DiT 的无组通信原语，在训练过程中支持弹性 GPU 分配——例如，在不中断训练的情况下临时下线部分 GPU 进行维护。

10. 总结

GF-DiT 提出了一个令人信服的论点：GPU 并行度应该是可调度的资源，而不是静态部署参数。其两个核心创新——可重新调度的轨迹任务和无组通信原语——共同解决了弹性 DiT 推理的两个根本障碍：找到安全的”切入点”来中途改变 GPU 分配，以及让组重配置足够廉价从而每任务都可使用。

实验结果（6.01 倍吞吐量、95% 延迟降低、90% SLO 违规率降低）令人印象深刻，尽管如第 8 节所讨论，评估范围可以更广，若干重要基线缺失。无组通信原语技术（将组建开销从 778 ms 降至 60 μs）是技术上最具新颖性的贡献，也最可能产生持久影响——它是任何需要动态组合 GPU 通信组的系统的有价值原语。

对于从事生成式 AI 推理系统的工程师：核心启示是，部署时静态选择的并行度配置将随着负载异构性的增长越来越成为瓶颈。GF-DiT 提供的轨迹任务抽象和策略接口，是向动态并行度管理迈进的一条有原则的路径。剩余的主要挑战是开发在突发性、不可预测的真实生产流量下能良好适应的鲁棒策略——这也是主要的开放研究机会所在。

附录 A：DDIM 与流匹配采样器——为何生产中 T 很小

现代生产 DiT 模型不使用需要 $T = 1000$ 步的原始 DDPM 采样器。两类加速采样器在部署系统中普遍使用：

A.1 DDIM：确定性隐式采样

DDIM（Song et al., 2021）将逆过程改写为确定性 ODE。更新规则为：

$$x_{t-1} = \sqrt{\bar{\alpha}_{t-1}} \underbrace{\left(\frac{x_t - \sqrt{1-\bar{\alpha}_t} \epsilon_\theta(x_t, t)}{\sqrt{\bar{\alpha}_t}}\right)}_{\text{预测的 } x_0} + \underbrace{\sqrt{1 - \bar{\alpha}_{t-1} - \sigma_t^2} \cdot \epsilon_\theta(x_t, t)}_{\text{"方向"项}} + \underbrace{\sigma_t \epsilon_t}_{\text{可选噪声}} \tag{A.1}$$

令 $\sigma_t = 0$ 使 DDIM 完全确定性。由于采样器跳过中间时间步，$T$ 可以降低至 20–50 步而不显著损失质量。每步仍需要完整的 DiT 模型前向传播——单步计算量不变，但步骤数大幅减少。

对 GF-DiT 的意义：以 $T = 20$ 为例，一个请求共有 22 个轨迹任务（1 个编码 + 20 个去噪 + 1 个解码）。调度循环每个请求最多执行 22 次——足以在每个去噪步骤有意义地调整并行度。

A.2 流匹配（Flow Matching）：连续时间直线轨迹

流匹配（Lipman et al., 2022; Liu et al., 2022）定义了一个将噪声 $x_0 \sim \mathcal{N}(0, I)$ 沿直线（或近直线）轨迹映射到数据 $x_1 \sim p_{\text{data}}$ 的速度场。模型被训练为预测速度场 $v_\theta(x, t)$，使得：

$$\frac{dx}{dt} = v_\theta(x, t), \quad x(0) = x_0 \sim \mathcal{N}(0, I), \quad x(1) = \text{数据样本} \tag{A.2}$$

核心优势：由于轨迹是直线的，积分从噪声到数据所需的步骤更少（蒸馏模型中甚至只需 1–8 步）。多个生产模型（FLUX、Stable Diffusion 3、CogVideoX）使用流匹配。

对 GF-DiT 的意义：使用 8 步采样的流匹配模型只有 10 个轨迹任务——调度机会极少。GF-DiT 对使用 20–50+ 步去噪（DDIM）的模型或多步流匹配最有价值。这是一个重要的实践局限：对于 1–4 步的激进蒸馏模型，轨迹任务图极短，弹性调度的收益极小。

附录 B：NVLink 与 PCIe——为何互连拓扑至关重要

GF-DiT 的无组通信原语利用预建立的点对点通信通道。这些通道的性能极大地依赖于互连拓扑。

B.1 NVLink

NVLink 是 NVIDIA 的高带宽 GPU 互连，可在 DGX/HGX 系统中单节点内的 GPU 之间使用：

NVLink 代次	单链路带宽	双向总带宽
NVLink 3.0（A100）	25 GB/s	600 GB/s
NVLink 4.0（H100）	50 GB/s	900 GB/s

通过 NVLink，在 2 个 GPU 之间传输 1 GB latent 张量大约需要 1.7 ms（A100）或 1.1 ms（H100）。这就是为什么 GF-DiT 报告的迁移开销为 2–8 ms——由大型 latent 的 NVLink 传输主导。

B.2 PCIe

对于不同节点上（或同节点内无 NVLink）的 GPU，通信路径经过 PCIe（~64 GB/s）和网络层（RoCE/InfiniBand，400 Gb/s = 50 GB/s）。跨节点传输 1 GB latent 大约需要 20–40 ms，与去噪步骤时间相比可能不可忽略。GF-DiT 的制品迁移在单个 NVLink 连接的服务器内效率最高。

实践意义：论文报告的 2–8 ms 迁移开销是乐观估计——它适用于 NVLink 连接的 GPU。对于大型模型所需的多节点 DiT 推理，迁移代价可能高出 5–20 倍。这是论文评估的一个盲点（第 8.1 节已讨论）。

附录 C：详细案例——混合请求批次的弹性 SP 调度追踪

为了使调度算法具体化，以下是 GF-DiT 在 8-GPU 系统上调度两个请求批次的逐步追踪。

设置：

• 请求 A：720p 4 秒视频，T=30 去噪步骤（计算密集）
• 请求 B：512×512 图像，T=20 去噪步骤（计算轻量）
• 策略：SLO 感知（算法 3），请求 A 截止 60 秒，请求 B 截止 5 秒

初始状态（t=0）：

• 请求 A 接入，创建轨迹任务 A-enc、A-den[30..1]、A-dec
• 请求 B 接入，创建轨迹任务 B-enc、B-den[20..1]、B-dec
• 所有 8 个 GPU 空闲
• 就绪任务：{A-enc, B-enc}

调度决策 t=0：

策略评估 A-enc 和 B-enc：
  A-enc：ĉ(A-enc, 1) = 5ms；紧急程度 = 60s - ε（较宽松）
  B-enc：ĉ(B-enc, 1) = 2ms；紧急程度 = 5s - ε（较紧迫）
  SLO 策略：优先调度 B-enc（deadline 更紧）
  → B-enc：布局 = {GPU 0, SP=1}（编码在 SP=1 时最快）
  → A-enc：布局 = {GPU 1, SP=1}（同理）
  → GPU 2–7 保持空闲

编码完成后（t≈7ms）：

• 就绪任务：{A-den[30], B-den[20]}

调度决策 t=7ms：

策略评估：
  A-den[30]：L_A = 4096（视频）
    ĉ(A-den, 2) = 210ms，ĉ(A-den, 4) = 110ms
    时间预算 = 60s / 30 步 = 2000ms/步 → 任何 SP 都足够
    SLO 策略：用最小可行 SP → SP=2（210ms ≤ 2000ms，且节省 GPU）
  B-den[20]：L_B = 256（图像）
    ĉ(B-den, 1) = 15ms，ĉ(B-den, 2) = 18ms（通信开销！比 SP=1 更慢）
    时间预算 = 5s / 20 步 = 250ms/步 → SP=1 最优
  → A-den[30]：布局 = {GPU 2, GPU 3, SP=2}
  → B-den[20]：布局 = {GPU 0, SP=1}
  → GPU 1、4–7 保持空闲（可供新请求使用）

这个追踪说明了关键的策略权衡：

1. 编码始终在 SP=1 运行（短序列，通信主导）
2. 视频去噪用 SP=2（而非 SP=8），因为 SLO 预算宽松——节省 GPU 以提升并发
3. 图像去噪用 SP=1，因为 SP=2 对短序列反而更慢
4. 4 个 GPU 保持空闲，可供新到达的请求使用

在静态 SP=4 系统下，请求 B 的编码和去噪必须等待请求 A 释放其 4-GPU 分配——仅去噪等待时间就是 210ms × 30 = 6.3 秒，直接超过了 B 的 5 秒 SLO 截止时间。GF-DiT 立即调度 B，使其在 ≈7ms + 20×15ms = 307ms 内完成，远优于 5 秒 SLO。

附录 D：各阶段延迟随 SP 度变化（可视化）

graph LR
    subgraph "编码阶段（短序列）"
        E1["SP=1: 5ms"] --> E2["SP=2: 5ms"] --> E4["SP=4: 6ms"] --> E8["SP=8: 8ms"]
    end
    subgraph "去噪阶段（L=256 小图像）"
        D1["SP=1: 15ms"] --> D2["SP=2: 18ms"] --> D4["SP=4: 28ms"] --> D8["SP=8: 55ms"]
    end
    subgraph "去噪阶段（L=4096 大视频）"
        V1["SP=1: 400ms"] --> V2["SP=2: 210ms"] --> V4["SP=4: 110ms"] --> V8["SP=8: 70ms"]
    end

图 5：各阶段延迟随 SP 度变化。 编码被通信开销主导，不受益于并行。小图像去噪在 SP>2 后性能退化。大视频去噪在 SP=4 以上仍能良好扩展。没有任何固定 SP 配置对三个场景都是最优的。

附录 E：无组通信的环式 AllGather 通信模式详解

为了加深对无组 AllGather（算法 2）的理解，以 P=4 个 GPU 的环式 AllGather 为例做详细拆解：

输入：每个 GPU 持有大小为 $L/4 \times d$ 的本地分片

目标：所有 GPU 都获得完整的 $L \times d$ 张量

环式通信流程（共 3 轮，P-1=3）：

初始状态：
  GPU 0: [shard0]      GPU 1: [shard1]      GPU 2: [shard2]      GPU 3: [shard3]

轮1（step=1）：每个 GPU 将自己的 shard 发给"右邻居"（(rank+1) mod 4）：
  GPU 0 → GPU 1: shard0    GPU 1 → GPU 2: shard1
  GPU 2 → GPU 3: shard2    GPU 3 → GPU 0: shard3
  状态：
  GPU 0: [shard0, shard3]   GPU 1: [shard0, shard1]
  GPU 2: [shard1, shard2]   GPU 3: [shard2, shard3]

轮2（step=2）：继续向右传递：
  GPU 0 → GPU 1: shard3    GPU 1 → GPU 2: shard0
  GPU 2 → GPU 3: shard1    GPU 3 → GPU 0: shard2
  状态：
  GPU 0: [shard0, shard2, shard3]   GPU 1: [shard0, shard1, shard3]
  GPU 2: [shard0, shard1, shard2]   GPU 3: [shard1, shard2, shard3]

轮3（step=3）：最后一轮：
  → 所有 GPU 拥有完整张量 [shard0, shard1, shard2, shard3]

无组实现的关键：channel[rank, send_rank] 是预分配的 NVLink/PCIe 点对点缓冲区，在系统启动时对所有 GPU 对建立。运行时只需要查找 $(i, j)$ 对应的通道——没有任何集群级同步、没有 TCP 连接建立、没有 NCCL 状态机初始化。这就是 778 ms → 60 μs 跨越式减少的原因。

附录 F：GF-DiT 对比 LLM 推理系统设计的关键差异

理解 GF-DiT 的设计选择，有助于与读者熟悉的 LLM 推理系统（如 vLLM、SGLang、TensorRT-LLM）进行对比。

维度	LLM 推理	DiT 推理（GF-DiT）
迭代结构	自回归，每步生成 1 token	去噪，每步精炼整个 latent
内部状态	KV-cache（随步骤增长）	Latent 张量（大小固定）
安全调度点	每个 token 边界	每个步骤/阶段边界
输出长度	运行时未知（影响调度）	运行时已知（便于预测）
并行策略	TP+PP（权重大）	SP（latent 序列长）
并行最优度	通常对请求固定	随阶段和请求形状变化
批处理方式	连续批处理（continuous batching）	轨迹任务级并发调度

最重要的差异是输出长度的可预测性：LLM 不知道会生成多少 token，调度器必须依赖统计估计；DiT 在接入时就知道需要多少步（$T$）和每步的计算量（由分辨率决定），使调度决策可以更精确地优化。

另一个关键差异是内部状态大小：LLM 的 KV-cache 可以增长到 GB 级别并难以在 GPU 间迁移；DiT 的 latent 张量大小固定（通常几十到几百 MB），是 GF-DiT 制品迁移低代价的物质基础。

附录 G：请求生命周期状态机

为使运行时行为更加精确，以下是 GF-DiT 中单个 DiT 请求的状态机：

stateDiagram-v2
    [*] --> 已接入 : 请求到达
    已接入 --> 任务就绪 : 轨迹任务图构建完成
    任务就绪 --> 执行中 : 策略分配执行布局
    执行中 --> 任务就绪 : 任务完成、制品发布
    执行中 --> 制品迁移中 : SP 度发生变化
    制品迁移中 --> 执行中 : 迁移完成、新布局已应用
    任务就绪 --> 已完成 : 所有任务完成
    已完成 --> [*] : 返回生成结果

图 7：GF-DiT 单请求生命周期状态机。 每个轨迹任务在”任务就绪”和”执行中”之间循环。当策略在两个任务之间改变 SP 度时，运行时透明地进入”制品迁移中”状态，对 latent 张量重分片后再派发下一个任务。整个过程对应用层不可见——客户端只感知到请求经过一段时间后返回生成的图像或视频。

参考文献

• Peebles, W. & Xie, S. (2023). Scalable Diffusion Models with Transformers. ICCV 2023.
• Ho, J. et al. (2020). Denoising Diffusion Probabilistic Models. NeurIPS 2020.
• Song, J. et al. (2021). Denoising Diffusion Implicit Models. ICLR 2021.
• vLLM-Omni：vLLM 对全模态（扩散+语言）推理的扩展
• SGLang Diffusion：SGLang 推理框架的扩散模型支持版本
• Zheng, L. et al. (2023). Efficiently Programming Large Language Models using SGLang. arXiv 2312.07104.
• Qiang, X. et al. (2026). GF-DiT: Scheduling Parallelism for Diffusion Transformer Serving. arXiv 2606.13501.
• Alpa：Zheng et al. (2022). Alpa: Automating Inter- and Intra-Operator Parallelism for Distributed Deep Learning. OSDI 2022.
• Llumnix：Sun et al. (2024). Llumnix: Dynamic Scheduling for Large Language Model Serving. OSDI 2024.
• DistServe：Zhong et al. (2024). DistServe: Disaggregating Prefill and Decoding for Goodput-Optimized Large Language Model Serving. OSDI 2024.