Flux Tools 结构简析

Flux Tools 结构简析

BFL 这次一共发布了 Canny、Depth、Redux、Fill 四个 Tools 模型系列，分别对应我们熟悉的 ControlNets、Image Variation（IP Adapter）和 Inpainting 三种图片条件控制方法。虽然实现功能是相同的，但是其具体实现方法却与之前大为不同。笔者查看了官方源码，在此简单记录一下几种 Flux Tools 的具体结构。

Flux 标准结构简图

我们先简单回顾一下 Flux dev 的标准结构，注意这里的回顾是为下面介绍 Flux Tools 结构服务的，因此对于具体的模型细节不会展开讲，而只介绍与 Flux Tools 的适配有关的部分。

Flux 整体上延续了 SD3 的模型结构。首先由 VAE 将像素空间的图片编码到 Latent 空间，然后进行多步去噪生图。Flux 采用了 T5、CLIP 两种编码器来提取文本特征，分别通过直接输入和 adaLN 条件的形式来讲文本条件注入到模型中。此外，Flux 还引入了 RoPE 位置编码、单流 DiT 块等改进。

Control

首先来看空间结构控制的两个模型 Canny 和 Depth，这两种空间控制本次各自发布了 LoRA 和全量模型两种版本。

一张条件图，预处理得到 Canny/Depth 图之后，送入 vae 中进行编码得到 latent，然后拼接到 img 的通道维（dim=-1）。需要注意的是，既然这里拼接到了 img 的通道维，为了对应扩张的输入维度，我们 img embedder 这个线性层的输入维度也需要跟着扩张，这里实际从 64 扩张为了 128。

Redux / Fill

Redux 模型，最开始以为会是一个类似 IP Adapter。但实际上，只有闭源版本的 Flux Pro/Ultra Redux 可以实现与 IP Adapter 类似的功能。而开源版本的 Flux Dev Redux 只能做 Img Variation。具体来说，开源版本的 Redux 不接收文本 prompt 条件，或者严格来说：文本 prompt 条件的影响很小很小。官方代码中，Redux 的文本 prompt 直接写死为空 L194。这导致开源版本的 Redux 模型只能实现 Img Variation 纯图到图的功能。当然，近些天社区已经研发出通过注意力权重调整、注意力掩码的方法来使得 Redux 模型能够接收文本 prompt 条件。具体出图质量如何，还有待测试。

Redux 和 Fill 的条件控制方式彼此比较接近，而与 Control 不同。

Redux 中，首先将条件图片用 SigLIP 进行编码，然后经过 MLP 对齐维度之后，拼接到 txt 的token 维度上（dim=-2），相当于在文本 token 之后直接加了若干个 token 表示图片条件。

Fill 则是接收一个底图和一个掩码图，根据掩码图将底图对应区域抹除后，底图经过 vae 进行编码，与掩码图都经过 pack 之后，同时拼接到 txt 的 token 维度上。

总结

在基础模型结构切换到 (MM-)DiT 之后，Flux 官方选择通过拼接条件 token 来实现条件控制，这似乎与 MM-DiT 直接将文本作为输入来实现条件控制的设计思路一脉相承。在 Flux Tools 发布之前，第三方的 ControlNet、IP Adapter 却还是沿用之前 UNet 时代的外挂 Adapter 的方案。在 DiT 架构上，这两种条件控制方式相比有何优劣？实测条件控制效果与出图质量如何，兼容性、可插拔性方面是否会受到影响？在实际应用或训练时应该如何选择？都是仍待探究的问题。在 Fill、Canny/Depth 这种空间控制的问题，感觉上还是 ControlNet 的形式更合理一点？