阿甘的博客 | Arganzheng's Blog

扩散模型推理基础设施（08）：三个引擎的对照导读——同一张图的请求在 SGLang Diffusion、vLLM-Omni 与 xDiT 里各走过什么

Three Engines Compared: One Request Through SGLang Diffusion, vLLM-Omni and xDiT

前七篇每篇末尾有一张对照表，指向三个引擎里实现同一机制的文件与类。这一篇把这些点连成线：一个”生成一张 FLUX 1024² 的图”的请求，在 SGLang Diffusion、vLLM-Omni 与 xDiT 里各自从哪里进来、经过哪些进程、哪些类、哪些函数，到哪里出去。三条线走完，三个引擎的取向就清楚了：SGLang Diffusion 把扩散塞进了 LLM serving 的结构（scheduler、worker、kernel 栈、warmup、CUDA graph 都复用），vLLM-Omni 为全模态模型设计了 stage 流水线（一个请求可以经过 LLM → DiT → TTS，扩散是其中一种 stage），xDiT 只做并行（把 diffusers 的...

Posted by arganzheng | September 12, 2026

扩散模型推理基础设施（07）：serving 形态——请求、批、三段分离、附件、异步任务与成本

Serving Diffusion Models: Request Shapes, Batching, Disaggregation, Add-ons, Async Jobs and Cost

前六篇的机制都在一个请求内部。这一篇把它们放进一个对外的服务：请求从 HTTP 进来、排队、被分到一组卡、跑三段、把图片或视频交回去、记一笔钱。LLM serving 的这一层（08 系列第三、四篇）围绕两件事组织——请求时长不可预测、memory-bound 下 batch 提吞吐——所以有连续批处理、抢占、KV 驻留。扩散的这一层围绕相反的两件事：请求时长在收到它时就完全确定（分辨率 × 步数 × CFG），batch 几乎不提吞吐（compute-bound）。于是调度像批处理系统而不像流处理系统：按时长排队、按形状分池、多实例横向扩，抢占只在步边界有意义。另外三个 LLM serving 没有的问题：三段的资源需求不同（文本编码器小且一次、DiT 重、V...

Posted by arganzheng | September 11, 2026

扩散模型推理基础设施（06）：少步与自回归——把步数变成系统参数

Few-Step and Autoregressive Generation: When the Step Count Becomes a System Parameter

前五篇都在一个前提下做交换：28 步、50 步，每步一次完整前向。步数 \(T\) 是第一篇账上最大的可调乘数，但前五篇没有动它——因为它不是系统能改的，是算法侧的：换更好的采样器（50 → 20 步）、步数蒸馏（→ 4 步、1 步）、guidance 蒸馏（去掉 CFG 的 ×2）。这一篇不讨论这些方法怎么做（在算法地图《多模态（08）：Latent diffusion、DiT 与文生图配方》），只讨论它们做成之后系统怎么变：当 FLUX.1-dev 的 28 步变成 FLUX.1-schnell 的 4 步、一张图从 4.3 s 变成 0.7 s，前五篇的结论哪些失效、哪些不变、哪些新问题出现。然后是一个更大的变化。视频模型一直是”一次前向处理整段视频的全...

Posted by arganzheng | September 10, 2026

扩散模型推理基础设施（05）：多卡并行——序列并行、CFG 并行与 PipeFusion，为什么不是张量并行

Multi-GPU Diffusion Inference: Sequence Parallelism, CFG Parallelism and PipeFusion

LLM serving 用多卡有两个理由：权重放不下（70B 的 140 GB 要切到几张卡上）、每步读权重的时间要切短（memory-bound，TP 让每张卡只读 1/p）。扩散推理的多卡理由不同：FLUX 的 22 GiB 一张卡放得下；单请求已经 compute-bound，多卡的目标是把一个请求的 FLOPs 分到 p 张卡上、让墙钟缩短 p 倍——而视频再加一个：14 GiB 的激活与几分钟的单卡时间让单卡本身不可接受。目标不同，切法就不同。切一个 DiT 前向有四种刀法：切序列（每张卡持有 \(N/p\) 个 token，attention 时交换 K / V 或交换 head——Ulysses、Ring、USP）、切 CFG 分支（条件与无条件各...

Posted by arganzheng | September 9, 2026

keynote 布局演示：给一份幻灯片配上讲稿

上面是可以翻页的幻灯片，下面是文字稿、参考资料和评论区

你现在看到的这一页就是 keynote 布局：头部不是标题图，而是一份嵌进来的在线幻灯片（方向键或点右下角箭头翻页，F 全屏，S 演讲者视图），往下滚就是这篇文章的正文——讲稿、补充说明、参考资料，文末照常有评论区、投票和阅读数。它解决的问题很具体：做完一次分享，幻灯片本身信息密度低，光放幻灯片没人看得懂；只写文章又丢了幻灯片的节奏。keynote 把两者放在一页：想快速过一遍看上面，想看细节读下面，想讨论去文末。一、怎么写三步。 1. 先有一份幻灯片。本站的幻灯片是 slides/ 目录下的 Markdown 文件，layout: slides，reveal.js 渲染。每份有两个地址：/slides/<名字>.html 是带缩略图、播...

Posted by arganzheng | September 9, 2026

扩散模型推理基础设施（04）：视频——长序列 attention 的账与稀疏化

Video Diffusion: The Long-Sequence Attention Bill and How Sparsity Pays It

第一篇的账里有一个翻转：FLUX 一步 74 TFLOPs 里 attention 占 20%，Wan2.1-14B 生成 5 秒 720p 的一步 6.5 PFLOPs 里 attention 占 72%，HunyuanVideo 129 帧占 87%。同样是 DiT，图像模型是 GEMM 负载，视频模型是 attention 负载——因为 \(N\) 从 4 千变成了 7 万到 12 万，\(4 L N^2 d\) 压过了 \(2 P_\text{tok} N\)。前两篇的手段在视频上仍然有效但不够：编译与量化只改线性项那 28%，跨步缓存跳的是整步；要动 attention 这 72%，需要另一类冗余——token 与 token 之间的冗余：一个 token...

Posted by arganzheng | September 8, 2026

扩散模型推理基础设施（03）：跨步冗余——TeaCache、First-Block Cache 一族的缓存与跳步

Temporal Redundancy Across Denoising Steps: TeaCache, First-Block Cache and Friends

第一篇的账里有一个乘数 \(T\)——28 步、50 步——每一步都是对整张 latent 的一次完整前向。第二篇把每步的 \(\eta\) 推高；这一篇问的是：这 28 步真的都要算吗？扩散采样沿一条平滑的轨迹走，相邻两步网络的输出常常只差百分之几；如果能在算之前就知道”这一步的输出和上一步差不多”，就可以直接拿上一步的结果，把一步的 74 TFLOPs 变成几乎为零。这是扩散推理特有的第一类冗余——时间冗余（temporal redundancy，这里的”时间”指去噪步而不是视频帧），LLM decode 里没有对应物：每个新 token 都是新的，没有”和上一步差不多”可言。从 2023 年的 DeepCache 到 2025 年的 Cache-DiT，...

Posted by arganzheng | September 7, 2026

扩散模型推理基础设施（02）：单卡执行——attention 后端、编译、FP8 / INT4 与 offload

Single-GPU Execution: Attention Backends, Compilation, FP8 / INT4 and Offloading

上一篇算出 FLUX.1-dev 一步 74 TFLOPs、eager 下 MFU 只有 0.31。这一篇讨论不改变这 74 TFLOPs（或改变得可控）的全部单卡手段：让同样的 FLOPs 跑得更快（换 attention 后端、编译、量化到 FP8 / INT4 用更快的 Tensor Core），以及让 31.5 GiB 的权重装进 24 GB 的卡（三段的 offload、逐层 offload、VAE 分块）。它们在账上改的是 \(\eta\) 与字节，不是 FLOPs 的公式。单卡优化的顺序有讲究：先做无损的（后端、编译、offload、VAE 分块——输出与基线 bit-exact 或只有浮点漂移），再做有损的（FP8、INT4、8-bit atte...

Posted by arganzheng | September 6, 2026

扩散模型推理基础设施（01）：负载画像——一次生成在 GPU 上发生什么

Workload Anatomy: FLOPs, Bytes and Seconds of One Diffusion Generation

一张 1024² 的图从 prompt 到像素，在 GPU 上是三段完全不同的计算：文本编码器跑一次，几百个 token、几十毫秒；去噪网络对整张 latent 做一次完整前向，重复几十步，占掉 97% 以上的时间；VAE 解码器跑一次，算力不多但显存峰值可能比前两段加起来还大。这三段各花多少 FLOP、多少字节、多少秒，是本系列后面八篇每一项优化的坐标系——不算清这张账，就不知道 TeaCache 省的是哪一项、序列并行切的是哪一项、蒸馏到 4 步改的是哪一个乘数。这一篇也要回答一个更根本的问题：为什么这种负载的推理系统与 LLM 的几乎没有重叠？答案不在模型结构（DiT 就是 Transformer），而在一个数字：一次去噪前向的算术强度是几千 FLOP/...

Posted by arganzheng | September 5, 2026

扩散模型推理基础设施：图像与视频生成的 serving（总纲）

Diffusion Model Inference Infrastructure: Serving Image and Video Generation

内容简介《扩散模型推理基础设施：从一次去噪到一个生成服务》是一组共九篇的系列文章，面向已经理解 LLM 推理引擎（vLLM 一类：请求、调度、KV cache、批处理、多卡）的工程师，系统讲解图像与视频生成模型——Stable Diffusion 3、FLUX、Qwen-Image、Wan、HunyuanVideo 一类——的推理是怎样一种负载，以及围绕它建立起来的一套与 LLM serving 几乎不重叠的基础设施：一次生成的三段（文本编码、几十步去噪、VAE 解码）各花多少算力、显存与时间；单卡上 attention 后端、编译、量化、offload 各能换回多少；相邻去噪步之间的冗余怎样被缓存与跳步利用；视频的十万级 token 序列让 attention...

Posted by arganzheng | September 4, 2026

Arganzheng's Blog