【AIGC】扩散模型加速:从Flow Matching到Rectified Flow再到Reflow

近年来,生成模型领域在见证了GAN和扩散模型的辉煌之后,迎来了一股新的浪潮——基于连续归一化流(CNF)的模型。特别是Flow Matching (FM), Rectified Flow (RF) 和 Reflow这一系列工作的出现,通过解决传统流模型训练和采样的痛点,实现了生成质量与采样速度的显著突破。本文旨在梳理这三者之间的脉络关系,解析其技术核心,帮助读者理解这一条清晰的技术演进路线。


引言

在追求高质量、高效率的生成模型道路上,扩散模型(Diffusion Models)无疑是当前的一座高峰。然而,其迭代式的采样过程带来的高昂时间成本,也限制了其在诸多实时应用场景中的部署。一个核心问题随之而来:我们能否构建一个模型,既拥有媲美扩散模型的生成能力,又具备GAN一样的高效采样速度?

Flow-based模型为此提供了一条极具潜力的解决路径。而Flow Matching、Rectified Flow与Reflow的相继提出,正是这条路径上的三个关键里程碑。它们并非孤立的技术,而是一个层层递进、不断优化的演进过程。

一、基石:Flow Matching (FM) - 一种高效的流模型训练框架

要理解后续的工作,首先必须掌握Flow Matching (FM) 的核心思想。传统的连续归一化流(CNF)在训练时,需要依赖常微分方程(ODE)求解器来计算精确的概率对数似然,这一过程计算量巨大且数值不稳定。

Flow Matching 则另辟蹊径,提出了一种simulation-free的训练范式。它将复杂的概率流学习问题,巧妙地转化为了一个简单直接的向量场回归问题。

核心思想

给定源分布π0\pi_0π0​(通常是标准正态分布)中的样本x0x_0x0​和目标分布π1\pi_1π1​(真实数据)中的样本x1x_1x1​,FM的目标是学习一个时变向量场(vector field)v(x,t)v(x, t)v(x,t),这个向量场能够驱动一个ODE,将x0x_0x0​在t=0t=0t=0时平滑地变换到t=1t=1t=1时的x1x_1x1​。

关键在于,FM通过一个回归损失函数,直接让神经网络预测的向量场vθ(xt,t)v_\theta(x_t, t)vθ​(xt​,t)去“匹配”一个预先定义好的、连接x0x_0x0​和x1x_1x1​的条件概率路径πt(x∣x0,x1)\pi_t(x|x_0, x_1)πt​(x∣x0​,x1​)上的目标向量场ut(x∣x0,x1)u_t(x|x_0, x_1)ut​(x∣x0​,x1​)。

LFM=Et,πt(x∣x0,x1),π(x0,x1)[∥vθ(x,t)−ut(x∣x0,x1)∥2]\mathcal{L}_{FM} = \mathbb{E}_{t, \pi_t(x|x_0, x_1), \pi(x_0, x_1)} [\| v_\theta(x, t) - u_t(x|x_0, x_1) \|^2]LFM​=Et,πt​(x∣x0​,x1​),π(x0​,x1​)​[∥vθ​(x,t)−ut​(x∣x0​,x1​)∥2]

这个框架的革命性在于:

  1. 无需ODE求解:训练过程中完全摆脱了对ODE求解器的依赖,使得训练过程变得极其高效和稳定。
  2. 高度灵活:可以选择不同的条件概率路径πt\pi_tπt​,为后续的优化(如Rectified Flow)埋下了伏笔。

简单来说,Flow Matching是一个通用的、强大的训练方法论,它为后续流模型的构建铺平了道路。

二、目标:Rectified Flow (RF) - 追求最“直”的变换路径

既然Flow Matching允许我们选择任意路径,那么一个自然的问题是:什么样的路径是“最优”的?

Rectified Flow (RF) 给出了一个清晰的答案:直线路径

想象一下,如果从随机噪声到目标图像的变换路径是一条笔直的线段,那么在采样时,我们就不需要用很多小步长去小心翼翼地逼近一条弯曲的轨迹。理论上,一个足够大的步长,甚至一步就能从起点到达终点。

核心思想

RF是FM框架下的一个特定目标实现。它通过最简单的配对方式——从源分布和目标分布中随机抽取样本对(x0,x1)(x_0, x_1)(x0​,x1​),然后强制模型学习连接这对样本的直线路径上的向量场。这条直线路径可以表示为:

xt=(1−t)x0+tx1,t∈[0,1]x_t = (1-t)x_0 + t x_1, \quad t \in [0, 1]xt​=(1−t)x0​+tx1​,t∈[0,1]

对应的目标向量场也极其简单,就是这两个点的差值:ut=x1−x0u_t = x_1 - x_0ut​=x1​−x0​。

带来的优势

  • 采样效率极大提升:由于路径是近似直线的,使用简单的欧拉法进行采样时,可以用非常少的步数(Number of Function Evaluations, NFE),例如10步甚至更少,就能生成高质量的样本。
  • 一步生成潜力:在理论上,如果路径完全笔直,一步欧拉法(x1=x0+v(x0,0)x_1 = x_0 + v(x_0, 0)x1​=x0​+v(x0​,0))就能完成生成,这为实现超实时生成提供了可能。
  • 与最优传输的联系:RF被证明与最优传输(Optimal Transport)问题有着深刻的内在联系,为模型提供了坚实的理论基础。

因此,Rectified Flow不再仅仅是一个训练框架,而是一个以“路径拉直”为明确目标的具体模型,它将FM的潜力转化为了实实在在的采样效率。

三、优化:Reflow - 迭代式的路径再矫正

尽管RF的目标是学习直线路径,但在单次训练中,由于数据分布的高度复杂性,学习到的ODE轨迹场仍然会存在一定的弯曲。我们能否让这条路径变得更直呢?

Reflow 技术为此而生。它不是一个全新的模型,而是一种迭代式的模型优化(或蒸馏)流程。

核心流程

  1. 训练一个初始RF模型:我们称之为“教师模型” (M0M_0M0​)。
  2. 生成新的数据对:使用M0M_0M0​从噪声x0x_0x0​生成一批样本x1′x_1'x1′​。现在我们有了一批新的、由模型自身生成的“输入-输出”对 (x0,x1′)(x_0, x_1')(x0​,x1′​)。
  3. 重新训练:使用这些新的数据对(x0,x1′)(x_0, x_1')(x0​,x1′​)去训练一个全新的RF模型,我们称之为“学生模型” (M1M_1M1​)。

这个过程为什么有效?因为由M0M_0M0​生成的(x0,x1′)(x_0, x_1')(x0​,x1′​)数据对,其内在的变换路径已经比随机采样的真实数据对要“直”得多了。让M1M_1M1​在这些更加“规整”的数据上进行学习,其学到的向量场自然会更加接近理想的直线状态。

这个过程可以重复多次(Reflow 2次,3次…)。每一次Reflow,都像是在对模型的变换路径做一次“矫正”和“提纯”。

带来的提升

  • 极致的采样加速:每经过一轮Reflow,模型达到同等生成质量所需的采样步数(NFE)都会显著下降。经过2-3轮Reflow的模型,通常可以实现高质量的一步生成
  • 性能提升:在一些任务上,Reflow不仅能提升速度,还能小幅提升生成的样本质量(如FID分数)。

Reflow是一种精益求精的优化技术,它将RF的“路径拉直”理念贯彻到底,最终实现了生成模型在速度和质量上的又一次飞跃。

总结:三者的关系

我们可以用一个简单的关系图来总结这三者的关系:

Flow Matching (通用训练框架) → Rectified Flow (追求直线路径的目标模型) → Reflow (迭代优化技术)

概念定位核心思想主要贡献
Flow Matching训练框架将流模型训练转化为向量场回归解决了CNF训练不稳、计算量大的问题
Rectified Flow具体模型/目标学习分布之间的直线变换路径大幅提升采样效率,实现少步生成
Reflow优化技术利用模型自身生成的数据对,迭代拉直路径实现极致的采样加速,达成高质量一步生成

从FM的范式革新,到RF对效率的极致追求,再到Reflow的精细打磨,我们看到了一条清晰且优雅的技术演进路线。对于追求模型效率和性能的开发者与研究者而言,理解这一脉络是至关重要的。

Read more

字节全员涨薪 35%,L3 年薪 150 万:前端人的“贫富差距”,正在被马太效应彻底拉大...

字节全员涨薪 35%,L3 年薪 150 万:前端人的“贫富差距”,正在被马太效应彻底拉大...

大家好,我是 Sunday。 昨天是 12 月 19 号,周五。原本应该是一个等待放假的好日子😂。但是!整个互联网圈子,尤其是技术圈,被一封邮件彻底炸醒了。 相信大家在群里、朋友圈里都刷屏了:字节跳动全员涨薪。 说实话,当看到这个消息的时候,我就在想:“我当年咋没遇到这么好的时候啊?” 现在很多同学总在说“寒冬”,总在说“降本增效”,总觉得大环境不行了。但字节跳动反手就给了这个观点一记响亮的耳光: 薪资投入提升 35%,调薪投入提升 1.5 倍,L3 职级(原 2-2,大致相当于之前的 阿里 P7)年薪拉高到 90w-150w。 这说明了什么? 这说明,这个行业从来就不缺钱,缺的是值得这笔钱的人。 今天这篇文章,我想把那些新闻通稿撇在一边,单纯从一个技术人、一个教育者的角度,

Flutter 组件 spry 适配鸿蒙 HarmonyOS 实战:轻量化 Web 框架,构建高性能端侧微服务与 Middleware 治理架构

Flutter 组件 spry 适配鸿蒙 HarmonyOS 实战:轻量化 Web 框架,构建高性能端侧微服务与 Middleware 治理架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 spry 适配鸿蒙 HarmonyOS 实战:轻量化 Web 框架,构建高性能端侧微服务与 Middleware 治理架构 前言 在鸿蒙(OpenHarmony)生态迈向全场景分布式协同、涉及设备端侧 API 暴露、轻量化资源服务镜像及严苛的跨端 RPC 通信背景下,如何实现一套既能保持极低内存足迹(Footprint)、又能提供类似后端(Node.js/Koa)般丝滑开发体验且具备全异步处理能力的“端侧 Web 基座”,已成为决定应用分布式自治能力与全栈同构效率的关键。在鸿蒙设备这类强调 AOT 极致效能与背景任务严格限制的环境下,如果应用依然采用重量级的 HTTP 服务端,由于由于进程级的上下文切换开销,极易由于由于“算力溢出”导致鸿蒙应用在作为服务端响应时发生明显的电量损耗。 我们需要一种能够解耦路由逻辑、支持

前端微前端架构:大项目的救命稻草还是自找麻烦?

前端微前端架构:大项目的救命稻草还是自找麻烦? 毒舌时刻 微前端?听起来就像是一群前端工程师为了显得自己很高级,特意发明的复杂术语。不就是把一个大应用拆成几个小应用嘛,至于搞得这么玄乎吗? 你以为拆成微前端就能解决所有问题?别做梦了!到时候你会发现,调试变得更麻烦了,部署变得更复杂了,甚至连样式都可能互相冲突。 为什么你需要这个 1. 大型应用的可维护性:当你的应用变得越来越大,单靠一个团队已经无法高效维护时,微前端可以让不同团队独立开发和部署各自的模块。 2. 技术栈的灵活性:不同的微前端可以使用不同的技术栈,比如一个模块用React,另一个模块用Vue,这样可以根据团队的专长选择最合适的技术。 3. 独立部署:微前端可以独立部署,不需要整个应用一起发布,这样可以减少发布风险,加快发布速度。 4. 团队协作:不同团队可以独立开发各自的微前端,减少代码冲突和沟通成本。 反面教材 // 这是一个典型的单体应用结构 import React from 'react'; import ReactDOM from 'react-dom'

AI Infra Baseline 的构想

AI Infra Baseline 的构想

引言 很多 AI 系统一开始都能跑,跑着跑着就容易变乱。 经常出现请求入口混乱、Agent 被滥用、状态乱放、推理层职责混乱、GPU 资源利用低等问题。 轻则响应慢,影响客户体验。 重则成本失控,系统崩溃。 设计这个基线,核心目标是在可控前提下,收敛复杂度,实现可复用。 常见问题 1、请求入口混乱 有人直接调模型,有人自己接工具,有人另外起一套 Agent 流程。 如果整个平台没有统一管控,限流、优先级、资源分配这些东西也很难真正生效。 同样一批请求,有些走平台,有些绕过去直接打 GPU,整套系统越来越难控。 2、Agent 被滥用 很多任务其实普通推理就够了。 有时候为了炫技,什么都往 Agent 里塞。 这样做下来,延迟高了,成本上去了,链路也更复杂。 一个本来一句话就能答完的问题,