阿甘的博客 | Arganzheng's Blog

扩散模型推理基础设施（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

RL 后训练基础设施（09）：系列总结与通关自测

RL Post-Training Infrastructure: Series Recap and Final Self-Test

八篇正文回答了一个问题：一个 RL 后训练任务同时是一个推理服务和一个训练任务，这两样东西怎样共享一组 GPU，而不让任何一方在等另一方。第一篇把一步 RL 拆成三个作业加两次同步、算清 FLOP / 字节 / 秒三本账；第二篇把共置、分离、异步三种形态放在同一张账上比较；第三到第六篇各解决形态带来的一个问题——共置要切显存、任何形态都要同步权重、异步要补 off-policy 的修正、Agent 要调度环境；第七篇把每个机制落到 verl 的函数与进程上，第八篇把前七篇变成配置推导、指标面板与故障表。八篇反复回到同一个场景算账：Llama-3-8B、\(B = 512\)、\(G = 16\)、\(\bar L = 8\text{K}\)、64 × H100，一步...

Posted by arganzheng | September 3, 2026

RL 后训练基础设施（08）：配置、可观测与排障——从一张卡的比例到一条 hang 的排查

Configuration, Observability and Troubleshooting for RL Post-Training Systems

凌晨两点，告警：reward 曲线从上升变成平台，步时间没变，日志里没有报错。这一步是训到第 400 步的 32B 推理模型 GRPO，128 张卡，separate_async。可能的原因至少四个：staleness 涨了（回答变长、同步没跟上）；训推不一致变大了（某个实例的 vLLM 在上一次弹性扩容后版本不同）；某个沙箱池挂了、它上面的任务 reward 全是零；上一次权重同步漏了一部分参数（一个实例的 update_weights 超时，版本号却推进了）。它们在 reward 曲线上长得一样。十分钟内区分它们，靠的不是这十分钟里的机智，是开训前采集了哪些信号——这是本系列最后一篇的主题。前七篇建立了账（第一篇）、形态（第二篇）、四个机制（第三到六篇）、代...

Posted by arganzheng | September 3, 2026

RL 后训练基础设施（07）：verl 源码导读——从一个 GRPO 配置追到每个 worker

Reading verl: From One GRPO Config to Every Worker

前六篇每讲一个机制都给了 verl 里的落点：一个目录、一个类、一个函数名。这一篇把落点串成线。线的起点是一条命令——python -m verl.trainer.main_ppo algorithm.adv_estimator=grpo trainer.nnodes=1 trainer.n_gpus_per_node=8 ...——终点是 8 张卡上各自的进程在做什么、一个训练步的数据怎样在它们之间流动、一个 bf16 参数从优化器更新完成到推理引擎用它生成下一个 token 经过哪些函数。追完这条线，前六篇的”账”与”机制”就都有了代码的锚点；再看 slime 与 AReaL 在同一条线的哪几段做了不同的选择，就能分清哪些是这类系统的必然、哪些是 verl 的取...

Posted by arganzheng | September 2, 2026

RL 后训练基础设施（06）：Agentic rollout——多轮、工具、沙箱与环境服务

Agentic Rollout: Multi-Turn Trajectories, Tools, Sandboxes and Environment Services

前五篇的 rollout 是一件事：推理引擎批量生成。Agent 训练里它变成了一个分布式系统：模型生成一段，解析出工具调用，某个容器里跑一次测试（几十秒），结果追加进上下文，再生成——重复二十轮；同一时刻几千条这样的轨迹在跑，每条占着一个有状态的沙箱；reward 不是一个规则函数，是”测试通过了几个”。500 个代码任务 × \(G = 8\) × 20 轮是 8 万次容器执行，每次 30 秒就是 670 个 CPU·小时——与模型侧这一步的十几个 GPU·小时按价格算是同一量级；要在 30 分钟内跑完，需要 1300 到 1800 个并发沙箱，取决于沙箱能否在两轮之间释放。 GPU 这一侧在这 30 分钟里做了什么，是这篇更想回答的问题。答案不太好看：dec...

Posted by arganzheng | September 1, 2026

RL 后训练基础设施（05）：异步与 off-policy——把同步的墙拆掉之后要补什么

Asynchrony and Off-Policy: What You Owe After Tearing Down the Synchronization Wall

第二篇的结论是异步把长尾吞掉、把一步的墙钟从 12 分钟压到 5 分钟。代价写得很轻：”样本过期”。这一篇把这个代价展开——它其实是三个不同的东西，各有各的机制、各有各的信号，混在一起时 reward 曲线只会告诉你”变缓了”，不会告诉你为什么。第一个是 staleness：训练用第 \(t\) 步的权重更新，样本由第 \(t - k\) 步的权重生成，重要性比 \(\pi_\theta / \pi_{old}\) 偏离 1，PPO 的 clip 开始大量触发；更隐蔽的是，过期程度与回答长度相关——长回答生成得慢、更容易过期——所以”丢弃过期样本”这个看似中性的策略会系统性地丢掉长回答，改变训练数据的长度分布。第二个是训推不一致：推理引擎（vLLM，可能 FP8...

Posted by arganzheng | August 31, 2026

RL 后训练基础设施（04）：权重同步——从训练分片到推理分片

Weight Synchronization: From Training Shards to Inference Shards

每一步训练结束，优化器改完了参数，推理引擎里的那份权重就旧了。把新权重送过去听起来是一次拷贝——8B 模型 16 GB，NVLink 一秒、InfiniBand 几秒。但两边的权重不是同一个形状的东西：训练器里它是 FSDP 按第 0 维切成 64 份的 DTensor，或者 Megatron 的 TP = 4 × PP = 2 × EP = 8 分片，QKV 三个矩阵融合成一个、专家堆叠成一个大张量、名字是 decoder.layers.3.self_attention.linear_qkv.weight；推理引擎里它是 vLLM 按 TP = 8 切的列、专家按 EP = 4 分组、可能是 FP8 加一组 128 × 128 的块缩放、名字是 model.lay...

Posted by arganzheng | August 30, 2026

RL 后训练基础设施（03）：共置——训练器与推理引擎在同一组 GPU 上共存

Colocation: Handing GPU Memory Back and Forth Between Trainer and Rollout Engine

一个 32B 的模型在 8 张 H100 上做共置的 GRPO。训练时每张卡上要有 66 GB 的训练状态（16 字节 / 参数均分到 8 卡）加 8 GB 的参考模型；生成时每张卡上要有 8 GB 的推理权重副本（TP = 8）加尽量大的 KV 池。两样东西加起来 150 GB，卡只有 80 GB——所以每一步里显存要换两次主人：生成前训练状态搬到 CPU、推理引擎的权重与 KV 池挂回 GPU；训练前反过来。按 PCIe 的带宽算，一步两次切换搬 130 GB 左右、约 6 秒；步时间 5 分钟时是 2%。 2% 不值得写一篇。值得写的是这 6 秒之外的东西：推理引擎的 KV 池释放再建回来，里面的 prefix cache 全部作废；CUDA graph 捕...

Posted by arganzheng | August 29, 2026

Arganzheng's Blog