视频生成 infra：瓶颈与取舍

LLM serving 的直觉在视频生成上逐条失效：合批、加速、质量与流式服务。

LLM serving 已经积累了一套相对成熟的直觉：decode 受内存带宽限制，合批几乎可以白赚吞吐；speculative decoding 能在不改变输出分布的前提下加速；KV cache 是显存的主要占用；TTFT 与 TBT 刻画用户体验。视频生成推理看起来是相近的问题——同样是 Transformer，同样涉及调度、并行与显存管理——但上面这几条直觉几乎逐条失效。

本文记录这些直觉在哪里失效、为什么失效。公开材料大多是论文的成功部分或厂商的最终方案，“看起来合理却走不通”的那一层很少被写下来，而本文的起点正是一次没有收益的 batching 尝试。文中的数字分三类：按公开模型配置推得的估算、单张 A100 上的实测（图中标为“实测”），以及少量个人观察；均注明条件，都不是完整的 benchmark。

01Batching：算术强度决定合批空间

最初的设想是把 LLM 的 continuous batching 搬过来：即使 DiT 的主体是 compute-bound，其中的 memory-bound 操作或许仍能从合批中获益，于是按 denoising step 的边界做 co-batch。在 5B 模型、长 chunk 的配置下，profile 显示瓶颈仍是计算，co-batch 也没有带来预期收益。

事后看，这个结果可以从算术强度直接推出。对 M 个 token、隐藏维度 d 的线性层，计算量为 2Md²，bf16 下的读写量约为 2(2Md + d²) 字节：

\[I = \frac{2Md^2}{2(2Md + d^2)} = \frac{Md}{2M + d}\quad \text{FLOP/byte}\]

负载	每次前向的 token 数 M	强度 I
LLM decode，batch 1	1	≈ 1
LLM decode，batch 32	32	≈ 31
Wan 1.3B，480p、81 帧，batch 1	32,760	≈ 750
同上，batch 4	131,040	≈ 763

LLM 行取 d = 4096，Wan 行取 d = 1536；81 帧经 VAE 压缩为 21 个 latent 帧，每帧 1,560 token。H100 SXM 的 bf16 稠密算力约 989 TFLOPS、HBM 带宽约 3.35 TB/s，拐点约 295 FLOP/byte。只计线性层，不含 attention 与逐元素算子。

LLM decode 中，batch 从 1 增至 32，强度提高约 30 倍，仍在拐点以下，合批的收益几乎线性。视频 DiT 的单个请求已经远超拐点，batch 再大也只是把 I 推向 d/2 = 768 的上限：从 batch 1 到 4，强度只提高约 2%。

合批后的 DiT 吞吐实测 · NVIDIA A100-SXM4-40GB

实测吞吐线性扩展

batch 1

×1.00

batch 2

×1.01

batch 4

×1.01

相对 batch 1 的视频吞吐，只计 DiT，VAE 未运行；虚线为吞吐随 batch 线性增长的情形。NVIDIA A100-SXM4-40GB × 1 · Wan2.1-T2V-1.3B-Diffusers · 832×480，81 帧 · DiT bf16 / VAE float32 · diffusers 0.36.0；8 步，CFG 5.0（每步 2 次前向）；3 次重复取中位数。

换成更大的模型，结论不变：Wan2.2 TI2V 5B 在 720p、121 帧下（每次前向 27,280 token），batch 2 的 DiT 吞吐仍是 batch 1 的 1.00 倍；batch 3 起，即使把文本编码器移出显存，40 GB 的 A100 也放不下。合批不仅不提高吞吐，还会先撞上显存上限。

反过来解 I < 295，得到 M < 295d / (d − 590)：d = 1536 时约 480 token，d = 5120 时约 330 token。只有单次前向的 token 数降到几百量级，线性层才回到 memory-bound 区间，例如低分辨率的文生图，或非常短的片段。

那么“利用其中的 memory-bound 操作”为什么也不成立？norm、激活、RoPE 这类逐元素算子确实受带宽限制，但它们的强度与 batch 无关：合批只是把读写和计算按同样倍数放大，比例不变。这类开销更适合用 kernel fusion 处理，而不是合批。

因此，这类负载的调度重心不在“凑 batch”，而在何时启动、放在哪台机器、分配多少 GPU。SlackServe 在 SLO 约束下同时调整 GPU 资源、步数与分辨率；TetriServe 面向文生图，按 step 调整每个请求的序列并行度；GF-DiT 研究弹性的并行分配。三者调的都是“给多少卡、怎么切”，而不是“合多少请求”。

02加速：先看它改变哪一项

一次生成请求流程示意 · 宽度不代表耗时

文本编码一次

DiT 去噪重复 N 步

VAE 解码一次

↓ N少步蒸馏

↓ t_step稀疏 / 量化 / 算子优化

↑ GSP / 通信取舍

减少步数、缩短单步、增加 GPU：改变的是不同变量，不能直接相乘各自的加速比。

\[\begin{aligned} T(G) &\approx T_{\mathrm{other}}(G) + N\,t_{\mathrm{step}}(G) \\ C &= G\,T(G) \end{aligned}\]

N 为步数，G 为 GPU 数；t_step 含未被隐藏的通信，T_other 汇总编码、解码等开销。C 为请求占用 G 张卡期间的 GPU-seconds。

按这个分解，常见手段的收益大致可以排序为：步数蒸馏 ≫ 稀疏 attention ≈ 量化 > diffusion cache > VAE 优化。排序依据是每种手段能改变哪一项、上限在哪里，而不是某组具体实测；模型、分辨率与时长不同，排序可能变化。kernel fusion 不容易放进这个排序：它的收益主要取决于基线实现已经融合了多少。

步数蒸馏改变 N。 DMD2、rCM 等方法可将 20–50 步压缩到 4 步左右，蒸馏后的模型通常也不再需要 CFG，等于再省去一半计算。它的代价在质量和训练成本上，而不在推理系统里。

稀疏 attention 只改变 t_step 中 attention 的部分，收益受 Amdahl 定律约束。设 attention 占单步计算的比例为 p、自身加速 s 倍：

\[S_{\mathrm{step}} = \frac{1}{(1-p) + p/s} \;\le\; \frac{1}{1-p}\]

按 FLOPs 估算，Wan 1.3B 在 480p、81 帧下 p 约为 0.7，即使 attention 完全消失，单步加速也不超过约 3.4×。attention 的计算随 token 数平方增长，分辨率与时长越大，p 越高，上限随之提高。

上面的 p 是按 FLOPs 估算的，按 kernel 时间算会更低。下图在 A100 上实测（bf16，PyTorch SDPA 的 FlashAttention 内核，diffusers 默认实现）：attention 约占 52%，对应的单步上限约 2.1×；另有约 29% 落在 norm、调制、类型转换等逐元素算子上，这些算子的 FLOPs 可以忽略，时间却不能。

单步 DiT 的 GPU 时间构成实测 · NVIDIA A100-SXM4-40GB

GEMMAttention其他

19%52%29%

一次 2 步、无 CFG 的 DiT 推理中 GPU kernel 时间的占比；kernel 按名称归类，归类依据见 results/profile_top.csv。NVIDIA A100-SXM4-40GB × 1 · Wan2.1-T2V-1.3B-Diffusers · 832×480，81 帧 · DiT bf16 / VAE float32 · diffusers 0.36.0。

同样的测量换到 Wan2.2 TI2V 5B（720p、121 帧，d = 3072）上，attention 只占约 39%，单步上限约 1.6×：隐藏维度更大、token 数更少时，线性层的份额随之上升。

量化同样作用于 t_step。 FP8 相对 bf16 的峰值算力为 2 倍，这是线性层的理论上限；SageAttention 一类方法把量化延伸到 attention。实际收益取决于 kernel 实现与可接受的精度损失。

diffusion cache 跳过相邻相似步的部分计算。它依赖相邻步之间的相似性；少步模型中每一步的变化更大，可复用的空间相应缩小，质量也更难控制。

kernel fusion 作用于单步之内的逐元素算子。 这些算子的 FLOPs 可以忽略，在前面的 profile 图里却占了约 29% 的 kernel 时间；把 norm、调制、类型转换融进相邻的 kernel，能直接缩短 t_step。不过这个比例来自 diffusers 的默认实现，没有开 torch.compile；在已经做过融合的推理框架里，剩下的空间会小得多。

VAE 优化处理的是单步之外的开销。 它在 50 步的模型上不显眼，但 N 越小，T_other 的占比越高：蒸馏之后，编码、解码与数据搬运可能从可以忽略变为不可忽略。单步快，不等于端到端同样快；延迟低，也不等于用卡更省。

下图的 A100 实测中，50 步、带 CFG 时 VAE 解码只占端到端时间的约 3%；同一 checkpoint 只跑 4 步、关闭 CFG 时，这一比例升至约 43%（VAE 为 float32、未开 tiling）。

端到端时间分解实测 · NVIDIA A100-SXM4-40GB

文本编码DiT 去噪VAE 解码其他

50 步 · CFG

97%

183.8 s

4 步 · 无 CFG

56%43%

12.8 s

各阶段占端到端时间的比例，右侧为总时长。少步配置使用同一个未蒸馏的 checkpoint，只用来测时间，画质不可用。NVIDIA A100-SXM4-40GB × 1 · Wan2.1-T2V-1.3B-Diffusers · 832×480，81 帧 · DiT bf16 / VAE float32 · diffusers 0.36.0；3 次重复取中位数。

VAE 的开销不只体现在时间上：解码阶段的激活随分辨率和帧数增长。在下图的 480p、81 帧配置下，float32 VAE 解码的显存峰值已经比 DiT 去噪高约 6.7 GB；开启 tiling 后降到与 DiT 相当，代价是解码时间（这里未测）。

各阶段的显存峰值实测 · NVIDIA A100-SXM4-40GB

文本编码

14.0 GB

DiT 去噪

15.3 GB

VAE 解码

22.0 GB

VAE 解码（tiling）

15.6 GB

每个阶段内 torch.cuda.max_memory_allocated() 的峰值，包含常驻的模型权重（13.8 GB）。NVIDIA A100-SXM4-40GB × 1 · Wan2.1-T2V-1.3B-Diffusers · 832×480，81 帧 · DiT bf16 / VAE float32 · diffusers 0.36.0。

各项加速比不能直接相乘，还有一个多卡上的原因：稀疏 attention 减少了计算，若仍传完整的 K/V，Ring 用来覆盖通信的计算时间也会缩短。单卡收益需要放回多卡配置中重新估算。

试算步数、GPU 数与通信开销展开计算器

解析估算，用于看趋势；默认参数未经实测校准。

03质量：比速度更硬的约束

LLM 推理中，最有影响力的加速之一是无损的：speculative decoding 可以保证输出分布不变。视频生成中，收益较大的加速——蒸馏、稀疏、量化、cache——几乎都是有损的。质量评估本身也缺少像准确率那样廉价、可靠的指标，这使得每一项加速都需要额外的评估成本。

并行也可能改变结果。 序列并行的切分方式、规约顺序、attention backend 不同，浮点结果就会不同；去噪过程可能放大这些初始差异，多卡与单卡的输出在视觉上未必一致。对需要复现或做 A/B 对比的场景，这一点需要事先确认。

时长受训练分布限制。 双向模型的可用时长通常接近训练时长，超出后容易出现重复或结构崩坏。直接拉长序列涉及位置编码的外推，并不是推理系统能单独解决的问题。

改动推理流程的风险，大于看上去的程度。 往双向模型注入上一段的 K/V、增加额外的融合模块，看起来都能补上跨段信息；但在个人的尝试中，这类改动首先带来的是画质不稳定。可能的原因包括位置编码错位与训练–推理不一致，这两点尚未逐一隔离验证。信息传进去了，不代表模型能按预期使用它。

与之相对，视频模型对文本条件非常敏感。在不重新训练的前提下，更完整、更一致的文本描述，可能比修改推理流程更有助于跨段一致性。这是现阶段实验后的选择，还不是通用结论。

04AR：算得快，还要赶上播放

CausVid、Self Forcing 等因果生成模型让视频可以逐段输出。服务指标可以和 LLM 类比：首段等待近似 TTFT，段间间隔近似 TBT。区别在于播放缓冲：只要下一段在缓冲耗尽前完成，段间间隔本身对用户不可见。同样的生成速度，面对不同的缓冲余量，体验可能完全不同。

同一完成时间，不同卡顿风险时序示意

现在下一 chunk 完成

流 A

可播放缓冲

流 B

缓冲

等待

虚线处完成下一段。流 A 的缓冲足够覆盖这次生成，流 B 会先耗尽缓冲。图中长度仅用于说明关系。

SlackServe 正是用剩余可播放时间组织资源分配。更贴近用户体验的服务目标因此是：首段等待、播放卡顿、控制响应，以及在这些约束下能承载多少条流。

自回归也让 KV cache 回到了视频生成中。历史 KV 直接占用多流共享的显存预算，按 bf16 普通多头 attention 估算：

\[M_{\mathrm{KV}} = 4 L d\,n_{\mathrm{history}}\quad\text{bytes}\]

每条流的历史 KV容量估算 · GB

1 帧

0.29

4 帧

1.15

16 帧

4.60

帧指 latent 帧。采用 Wan2.1 1.3B 的维度：L = 30、d = 1536，480 × 832 下每帧 1,560 tokens。仅估算同尺寸 AR 模型的 KV，不含权重、激活，也不意味着该双向 checkpoint 原生支持历史缓存。

目前主流的 AR 视频模型大多只在局部窗口内做 attention；LongLive 额外保留首帧作为 sink，思路与 StreamingLLM 一致。窗口本身就是最简单的 KV 压缩：它给每条流的显存设了上限，代价是窗口之外的内容被遗忘。

2026 年起，生成侧开始出现更细的 KV 压缩：Quant VideoGen 将 KV 量化到 2 bit，DensityKV 与 FrameFold 在固定预算下筛选或合并历史 KV。视频理解侧更早开始做这件事，InfiniPot-V 等工作在流式视频问答中压缩视觉 token 的 KV。

两边的问题并不相同。理解侧压缩是为了省显存，KV 只被问题读取，还可以按问题挑选 token。生成侧的窗口已经限住了显存，压缩更多是为了在同等预算下记住更远的历史；而每一次压缩误差，都会作为后续所有 chunk、所有去噪步的条件被反复使用，并可能逐段累积为漂移。理解侧基于重要性的筛选启发式，因此未必能直接迁移到生成侧。

history 长度、可容纳流数与生成质量，需要作为同一个服务问题来权衡。这是本文认为最值得投入的方向之一。

05框架：并行库与服务系统

以下基于 2026 年 10 月底的开源代码，各项目迭代很快，细节可能已经变化。

xDiT 是单请求的并行推理库：USP（Ulysses 与 Ring 的组合）、PipeFusion、CFG 并行，封装 diffusers 的管线。它回答“一个请求如何切到多张卡上”，不负责多请求调度。SGLang Diffusion 与 vLLM-Omni 的并行状态管理代码都可以追溯到它。
SGLang Diffusion 在类似的并行能力之上加了服务层：CFG、TP 与序列并行的组合，编码、去噪、解码可以分离部署，支持多种 attention backend，并对部分模型（如 Wan2.1）提供动态合批。它还按 exact、lossless、high 三档区分加速选项对输出的影响，这与第 03 节的问题直接相关。
vLLM-Omni 以全模态模型为目标，扩散部分有请求级与 step 级两种执行方式；step 级执行在视频模型上目前只覆盖少数几个，且为单请求。它的特色在于 AR 模型与 DiT 之间的 KV 传递，面向的是“LLM + 扩散”组合的模型。

结合第 01 节，这两个服务框架做合批与 step 级调度，价值可能主要不在提高视频请求的吞吐：图像或低分辨率请求仍处在合批有效的区间；step 粒度的执行为抢占、交错与资源调整提供了切入点；统一的请求接口也便于和 LLM 服务共用基础设施。对高分辨率视频请求，合批本身大概率不是收益来源。

06值得关注的方向

并非每个方向都有 infra 的空间，但以下几个方向会改变推理系统要解决的问题：

AR-DiT 与长视频。 突破训练时长的限制，KV cache 随之回归，第 04 节的服务问题随之出现。
线性注意力与混合注意力。 SANA-Video、Video DeltaNet 等工作降低长序列的成本；目前开源的视频模型仍少，系统层面的优化还缺少落地对象。
Agentic 生成。 LLM 规划分镜，VLM 评估质量，视频模型执行生成。多个候选可以共享文本编码，并借低成本预览提前淘汰，调度对象从单个请求变为一张工作流图。
3D 记忆与程序化场景。 在显式场景表示上编辑更容易保证一致性，视频模型的角色趋近渲染器，对推理系统的要求也会随之改变。

回头看，视频生成推理与 LLM 推理共享许多组件，但瓶颈的位置不同：它不在带宽，而在计算；不在合批，而在资源分配；不在无损加速，而在质量约束。把 LLM serving 的方法直接搬过来之前，先确认它依赖的那条假设是否仍然成立。

2026 年 10 月。个人观察限于所述配置；画质对照待补。示意图、强度与容量为按公开配置的估算；标有“实测”的图来自单张 A100，配置见各图图注。