文生图领域的 Scaling 讨论过去总是围绕参数量、数据量和算力三个维度展开。字节 Seed 团队相关的公开分享将“新变量”这个词带入文生图社区后讨论重心开始从模型规模转向训练配方同样放大模型为什么有的效果显著提升有的却出现训练不稳、生成退化调整噪声计划、条件丢弃比例、时间步采样权重这类细节变化往往比单纯加大参数量更直接。理解这些变量才算真正理解文生图模型如何 Scaling。这篇文章按可复现的路线来组织先讲清楚概念再搭建一个最小可实验环境然后用控制变量的脚本验证关键因子最后补充排错路径和生产建议。适合正在做扩散模型训练、微调、推理部署的工程师也适合想深入了解文生图原理的读者。文章里的代码和配置都偏工程化落地时可以根据自己的模型、显存和任务场景调整。1. 文生图 Scaling 在聊什么从模型规模到训练配方1.1 传统 Scaling 视角参数量、数据量、计算量语言模型领域的 Scaling Law 已经足够深入人心。模型参数增多、训练数据扩大、计算量提升通常会在损失值、下游任务指标上表现出可预测的下降趋势。基于这个规律很多团队做扩展实验时第一反应就是放大模型或加大数据集。文生图模型早期也沿用这套思路。模型从 VQGAN 时代的几千万参数一路扩到 Stable Diffusion、SDXL、Flux 等单位参数量显著增长训练数据也从几亿张图扩大到数十亿图文对。这种“堆规模”的方式确实带来了更细腻的纹理、更强的语义理解但进入大规模训练后问题开始出现部分实验在参数量翻倍后收益有限甚至出现训练震荡、生成图像结构崩坏、同一 prompt 下多样性下降等反直觉现象。这说明文生图模型不能简单照搬语言模型的 Scaling Law。扩散模型的训练目标不是下一个 token而是从噪声中还原图像的整个概率分布。模型需要同时处理不同噪声强度下的去噪任务这会让“参数量、数据量、算力”三个常规变量之外出现一批过去被当作默认超参、实际上会显著影响 Scaling 曲线的新变量。1.2 为什么扩散模型不能直接套用语言模型的 Scaling Law语言模型的训练序列存在明确的因果顺序模型只需要预测下一个 token损失函数单一且稳定。扩散模型的训练则复杂得多输入图像经过 VAE 编码成潜变量后前向过程按某个噪声调度逐步加噪训练时随机采样一个时间步让模型预测噪声。不同时间步的难度差异极大低噪声步负责恢复细节高噪声步负责生成整体结构。如果把这些时间步视为“任务”那么文生图模型的 Scaling 本质上是在同一个模型中同时学习成千上万个难度不同的去噪子任务。单纯放大参数不一定能自动均衡所有时间步的学习效果。有些时间步可能欠拟合有些时间步可能过拟合有些损失项权重过高会把模型精力带偏。这就是为什么有的团队发现修改噪声计划、时间步采样权重、条件丢弃比例效果比增加参数更明显。1.3 “新变量”到底指什么从工程角度看文生图 Scaling 的新变量可以分为三类训练配方变量、数据变量、推理变量。它们共同决定一个模型从“能出图”到“出好图”的 Scaling 效率。下表是这些变量的大类速查变量类别典型变量影响对象容易被忽略的原因训练配方噪声计划、时间步采样权重、损失项配比、条件丢弃概率训练稳定性、生成质量默认值通常可用不对比很难发现差异数据变量图文对质量、宽高比、重复度、文本质量语义对齐、多样性、风格覆盖清洗成本高常被当作固定输入推理变量采样步数、CFG 权重、引导重缩放、解码器选项最终图像质感和推理成本训练和推理脚本经常分离缺少统一评估基础设施batch size、学习率、混合精度、随机种子训练曲线和复现性报告里很少写完整换环境后结果漂移这些变量的共同点是它们都可以被显式控制也都可以做消融实验。文章后面会逐个展开。2. 先搭一个可实验的文生图环境才能验证 Scaling 因子理论讨论容易悬浮验证一个变量是否有效必须有可重复运行的实验环境。这里的建议是先跑通最小生成链路再研究训练或推理参数。2.1 本地最小环境Python、CUDA、PyTorch学习环境和生产环境对硬件的要求差异很大。如果只做推理参数调节一张 8GB 以上显存的 NVIDIA 显卡就够最低可以用 CPU 跑但速度会很慢。如果做模型微调或从小规模开始验证训练配方建议显存不低于 16GB并根据模型大小预留额外空间。推荐环境如下组件建议配置说明Python3.10 或 3.11兼容大部分深度学习库CUDA11.8 或 12.x与 PyTorch 版本匹配PyTorch2.x支持 torch.compile 和更好算子融合Diffusers0.27 及以上仅作参考实际按模型要求安装显存推理 8GB 起训练 16GB 起越小越需要优化手段创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install --upgrade pip pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install diffusers transformers accelerate safetensors安装完成后先验证 PyTorch 能识别 GPUpython -c import torch; print(torch.__version__, torch.cuda.is_available())正常输出类似2.3.0cu121 True。如果输出False先检查驱动和 PyTorch 的 CUDA 版本是否匹配不要急着继续装模型。2.2 用 Diffusers 加载一个开源文生图模型以 Stable Diffusion 系列为例用 diffusers 加载模型的代码很短from diffusers import StableDiffusionPipeline import torch model_id stabilityai/stable-diffusion-2-1 pipe StableDiffusionPipeline.from_pretrained( model_id, torch_dtypetorch.float16, safety_checkerNone, requires_safety_checkerFalse, ) pipe.to(cuda) pipe.enable_attention_slicing()这里使用torch.float16可以大幅降低显存占用enable_attention_slicing()是一种空间换时间的优化方式适合显存不足时使用。需要注意不同模型对 dtype 和 safety checker 的支持不同实际使用时要先确认模型许可证和运行要求。生成一张图的示例prompt a small orange cat sitting on a wooden bench, soft light image pipe( prompt, num_inference_steps25, guidance_scale7.5, generatortorch.Generator(cuda).manual_seed(0), ).images[0] image.save(output.png)这段代码里的num_inference_steps、guidance_scale、manual_seed就是后续做变量对比时经常要控制的对象。2.3 用 ComfyUI 做工作流化验证ComfyUI 在文生图社区里流行是因为它把生成过程拆成节点每个节点都能单独调整。对研究 Scaling 变量的人来说它有两个实际价值一是可以保存完整工作流 JSON方便复现二是在不写代码的情况下快速测试采样器、步数、CFG、模型权重等参数。如果想要在本地部署可以直接从 ComfyUI 官方仓库拉取代码然后安装依赖git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI pip install -r requirements.txt python main.py启动后浏览器访问默认地址把模型放入models/checkpoints目录就可以拖拽节点生成图片。ComfyUI 生成的工作流 JSON 适合做实验记录因为它包含采样器名称、步数、CFG、种子、模型路径等关键信息。2.4 免费在线测试页面适合做什么网上有一些免费的文生图测试网页适合快速体验模型效果但不适合做严谨的 Scaling 实验。主要原因有三个随机种子通常不可控无法复现同一条件。低优先级任务排队导致采样参数与实际运行参数不一致。无法查看中间日志和模型加载细节问题排查受限。建议的用法是用在线页面快速筛选 prompt 风格和大致参数范围确定可行方向后再回到本地脚本或 ComfyUI 中做严格对比。3. 影响文生图 Scaling 的关键变量从训练到推理3.1 噪声计划和时间步采样训练时最容易被忽略的变量很多文生图模型的训练代码中时间步t是均匀采样的损失权重也常使用1。这看起来公平但扩散模型对不同t的学习难度并不一致。较小时的t接近原图模型做的是细节修复较大的t接近纯噪声模型做的是整体结构生成。如果每个时间步权重相同模型能力上移后容易出现高噪声区域欠拟合、低噪声区域过拟合的问题。常见的处理是调整时间步采样分布让模型把更多容量花在困难时间步上或使用不同的噪声调度使加噪过程在不同阶段保持合适信噪比。训练代码中通常有一行类似这样的逻辑t torch.randint(0, num_train_timesteps, (batch_size,), devicedevice)如果只做均匀随机采样后续想要分析模型在各时间步的表现可以在训练循环中加上分桶统计t_bucket t // (num_train_timesteps // 10) bucket_counts torch.bincount(t_bucket, minlength10)这样能看到每个时间步区间的样本量分布。实际项目中修改时间步采样权重前先保存 baseline 模型再尝试加权采样比如让高噪声区域获得更高权重然后用验证集评估整体生成质量。这类改动往往比调整学习率更有效但也更容易引入训练不稳。3.2 条件注入与 loss 配比CFG 权重不是越大越好扩散模型训练时文本条件不会以 100% 概率输入。常见做法是随机丢弃部分条件让模型学会无条件生成。这个条件丢弃概率直接影响训练后的可控性。丢弃概率太低模型可能过度依赖文本丢弃概率太高可能出现训练不稳或生成内容漂移。推理时CFGClassifier-Free Guidance用有条件输出和无条件输出的差值来放大文本影响公式可以简化成final_noise unconditional_noise guidance_scale * (conditional_noise - unconditional_noise)看到这个公式就应该明白guidance_scale不是越大越好。调大 CFG 会让图像更贴 prompt但也会增加色彩饱和、边缘伪影和构图僵硬。调小 CFG 会让模型更自由但可能偏离语义。很多项目把 7.5 当作默认值实际最优值会随模型、步数、prompt 风格变化。训练侧也应该关注文本编码器和 UNet 的输出配比。如果文本嵌入维度提升但 UNet 的 cross-attention 层没有同步扩大容量文本条件会成为 Scaling 的瓶颈。简单增大 UNet 参数量不一定能提升语义跟随能力。3.3 VAE 与文本编码器的瓶颈效应文生图模型通常由文本编码器、VAE、去噪网络三部分组成。Scaling 实验如果只放大去噪网络而 VAE 或文本编码器不变最终效果会受限于两部分瓶颈。VAE 负责把图像压缩到潜空间再由 UNet 去噪。如果 VAE 的下采样倍率过高、潜变量通道过窄细节信息会在压缩过程中丢失。即使去噪网络能力再强也无法恢复已经丢失的信息。做超分辨率、精细纹理相关任务时VAE 是优先检查的变量之一。文本编码器决定模型能理解多复杂的 prompt。早期 CLIP 文本编码器长度通常限制在 77 个 token长文本和细粒度属性容易被截断。后来一些模型改用更大的文本编码器或同时使用多个文本编码器明显提升了复杂语义跟随能力。如果只追求更大 UNet文本编码器不变长 prompt 下的生成能力很快触顶。3.4 数据质量、宽高比与去重策略Scaling 扩数据时最容易出现的误区是只关注图片数量不关注图文对质量。文生图模型的跨模态对齐质量由图片与文本匹配程度决定。图文错配、描述过于笼统、文本噪声多的数据会让模型学到错误的关联。宽高比也是一个常被忽略的变量。直接 resize 到 1024x1024 会让图片内容变形损失语义。正确做法是在数据处理阶段做边缘裁剪、填充或按宽高比分桶训练。很多训练框架支持在不同 batch 中使用不同分辨率这时需要注意 batch 内 tensor shape 的一致性。数据去重同样重要。公开数据集中常存在大量近似重复图片如果不去重模型会对高频样本过拟合导致生成结果单一、多样性下降。在大规模训练前建议先用感知哈希或特征向量做聚类去重并把去重结果保存成 manifest 文件后续复现时可以直接复用。变量推荐验证方式效果偏差可能出现的表现噪声计划固定其他参数只切换调度器生成图整体过亮、过暗或结构崩溃时间步采样权重记录时间步分布并分桶统计细节修不好或构图不稳定条件丢弃概率从 0.05 到 0.2 逐步消融语义偏移、文本完全被忽略VAE替换不同 VAE 文件细节模糊、色彩失真数据宽高比对比中心裁剪与直接 resize物体形状拉伸、构图偏移4. 用最小脚本验证不同变量对生成效果的影响4.1 固定随机种子控制变量变量验证最怕多个条件同时变化。采样过程本身就是随机过程如果不固定种子同一 prompt、同一模型、同一参数也可能得到完全不同的图。做实验时第一步就是固定随机种子。推荐用循环方式批量生成并记录 seedfrom diffusers import StableDiffusionPipeline import torch pipe StableDiffusionPipeline.from_pretrained( stabilityai/stable-diffusion-2-1, torch_dtypetorch.float16, safety_checkerNone, requires_safety_checkerFalse, ).to(cuda) prompt a small orange cat sitting on a wooden bench, soft light for steps in [10, 20, 30, 40]: for seed in [0, 42, 1234]: generator torch.Generator(cuda).manual_seed(seed) image pipe( prompt, num_inference_stepssteps, guidance_scale7.5, generatorgenerator, ).images[0] image.save(fsteps_{steps}_seed_{seed}.png)这段脚本会生成 12 张图输出文件名包含步数和种子方便后续对照。注意不同 diffusers 版本和不同采样器会改变随机数使用方式记录环境版本同样重要。4.2 调整采样步数与 CFG 的对比实验采样步数和 CFG 是推理阶段最常用的两个变量。步数从 10 到 50 变化时图像质量通常先提升后平稳甚至可能因为过采样出现伪影。CFG 从 1 到 12 变化时图像往往从“多样性高、语义弱”过渡到“语义强、风格僵”最优区间集中在 5 到 9。可以写一个对比函数def generate_grid(prompt, steps_list, cfg_list, seed): for steps in steps_list: for cfg in cfg_list: generator torch.Generator(cuda).manual_seed(seed) image pipe( prompt, num_inference_stepssteps, guidance_scalecfg, generatorgenerator, ).images[0] image.save(fgrid_s{steps}_c{cfg}.png)保存后可以用看图工具切成多宫格对比。重点看两处一是主体结构和 prompt 是否一致二是细节纹理是否存在过锐、色彩溢出、阴影杂乱。4.3 观察指标FID、CLIP Score 与主观质量只看单张图会陷入随机性。严谨的变量评估需要有批量生成和量化指标。FID 依赖一个统计分布真实的图片集合计算成本较高CLIP Score 可以用 CLIP 模型计算生成图和 prompt 的匹配程度比较适合验证语义跟随能力。CLIP Score 的简化计算方式from PIL import Image import torch import torch.nn.functional as F from transformers import CLIPProcessor, CLIPModel model CLIPModel.from_pretrained(openai/clip-vit-base-patch32) processor CLIPProcessor.from_pretrained(openai/clip-vit-base-patch32) image Image.open(output.png) inputs processor(text[prompt], images[image], return_tensorspt, paddingTrue) with torch.no_grad(): outputs model(**inputs) logits_per_image outputs.logits_per_image probs logits_per_image.softmax(dim1) print(probs.item())CLIP Score 不是越高越好它只能衡量 prompt 与图像分布的匹配程度不能衡量图像质量和美观度。最终结论必须以“客观指标 多轮人工评估”结合避免被单一指标带偏。4.4 结果记录与复现实验记录至少要包含以下字段字段示例prompta small orange cat sitting on a wooden bench模型标识stabilityai/sd-2-1采样器DPM 2M Karras步数25CFG7.5seed42分辨率768x768耗时3.2s显存占用6.1GB人工评分4/5CLIP Score0.3245复现时尽量把工作流保存为 JSON 或 Python 脚本而不是只保存结果图。结果图只能展示最终输出不能还原完整参数链路。5. Scaling 从训练走向推理无损缩放与延迟优化5.1 推理阶段的无损缩放思路训练阶段的 Scaling 是放大模型和提升质量。推理阶段的 Scaling 目标正好相反是压缩成本、减少延迟同时尽量不损失质量。这里的“缩放”指的不是缩小模型参数而是缩放采样步数、计算精度和批处理规模。一个常见误解是推理步数减少一定会损失质量。实际并非如此。部分采样器在步数减少时依然能保持不错效果例如 DPM、Euler a 等在低步数下比 DDIM 更稳定。另一个方向是引入蒸馏模型通过让大模型在少步数下输出接近多步采样的结果从而在推理时实现“无损”缩放。5.2 降低采样步数蒸馏、一致性模型与 LoRA蒸馏类模型把多步采样能力压缩到单步或少数步。常见的方案包括 Consistency Models、Latent Consistency Models、SDXL Turbo 等。这些模型不一定需要重新训练完整底座也可能只是一个 LoRA 或一个小的推理适配器。使用 LoRA 做推理加速时加载方式与普通微调模型类似pipe.load_lora_weights(path/to/lora, adapter_namefast_generate) pipe.set_adapters([fast_generate], adapter_weights[1.0])LoRA 优势是不改变模型整体结构文件体积小切换方便。但要注意 LoRA 与底座模型的版本匹配混用不同底座可能导致布局崩坏和风格偏移。5.3 批量生成和显存占用控制推理服务中常见瓶颈是显存不足而不是计算不够。批量生成可以提升吞吐但 batch size 增大会线性增加显存。稳定做法是先固定单图显存峰值再逐步提高 batch 直到 OOM 边界。显存不足时可以按顺序尝试pipe.enable_attention_slicing() pipe.enable_vae_slicing() pipe.enable_model_cpu_offload()这些方法会降低峰值显存但会增加少量 CPU 传输时间。如果生产环境对延迟敏感更推荐使用算子融合、TensorRT、ONNX Runtime 或 bfloat16 推理。使用这些方案前要先确认目标 GPU 的算子支持范围。5.4 模型压缩与部署部署到生产环境时模型格式、推理引擎和业务指标要一同考虑。常见选择包括 PyTorch 原生服务、ONNX Runtime、TensorRT、vLLM 等。文生图模型不仅包含 UNet还包含文本编码器和 VAE压缩时三者都要单独验证。训练和推理分离后必须保留一份完整的“推理配置快照”。快照内容包括模型仓库地址、commit hash、LoRA 文件 hash、采样器名称、步数、CFG、dtype、attention slicing 开关等。没有这份快照生产环境的偶发图像异常很难定位。6. 常见坑与排查清单6.1 复现实验时结果不一致现象同样代码、同样 prompt、同样参数换一台机器后生成图完全不同。常见原因随机种子没有固定或固定方式不一致。GPU 算子存在非确定性比如 cuDNN 的 autotune 选择不同算法。diffusers、transformers、PyTorch 版本不同。模型权重使用了不同精度fp16 与 bf16 的结果会有差异。检查方式python -c import torch; print(torch.__version__) python -c import diffusers; print(diffusers.__version__)解决建议在实验脚本开头统一设置环境变量并记录依赖版本export CUBLAS_WORKSPACE_CONFIG:4096:8同时把要求使用确定性算法的开关显式写到代码里。不要只依赖程序随机种子。6.2 采样步数与 CFG 调参无效现象修改步数或 CFG 后生成效果几乎不变或只在很小范围内波动。常见原因改了参数但实际上没有传进 pipeline。多个 pipeline 实例并存实际使用的是旧实例。采样器内部默认覆盖了 CFG 相关设置。模型本身是蒸馏模型对步数变化不敏感。排查方式把输入参数打印出来与输出文件命名对照。比如print(fsteps{steps}, cfg{cfg}) image.save(fout_{steps}_{cfg}.png)如果文件名和实际参数一致但效果仍不变考虑切换到另一个采样器再试。不要只盯着步数和 CFGeta、guidance_rescale、strength等次生参数也可能起决定性作用。6.3 显存溢出与速度过慢现象CUDA OutOfMemory 或单张图推理耗时过长。常见原因使用 fp32 推理。没有启用 attention slicing。batch size 设置过大。图片分辨率超过训练初始分辨率太多。处理顺序切换到 fp16 或 bf16。打开 attention slicing 和 VAE slicing。降低 batch size。降低输出分辨率或分块处理。使用 CPU offload。生产环境建议提前压测不要等上线后流量峰值再调。6.4 图片出现伪影、色彩失真、语义偏移现象图像中频繁出现水渍感、边缘重影、颜色溢出、主体与 prompt 不匹配。常见原因CFG 过高导致过饱和和伪影。VAE 版本与底座模型不匹配。噪声调度器选择错误。文本条件在训练时被丢弃但推理时 CFG 使用不当。低步数下使用不合适的采样器。排查表现象优先检查处理建议颜色过饱和CFG、采样器降低 CFG开启 guidance rescale边缘重影VAE、步数更换正确 VAE或提高步数人像五官崩坏去噪阶段权重从高噪声步是否均匀开始排查语义偏移文本编码器、条件丢弃概率增加 prompt 长度检查 token 截断整图灰暗噪声调度、精度对比 fp16/bf16 输出检查调度器参数7. 实践建议把 Scaling 变量变成可管理的实验体系7.1 先做小规模消融再放大资源不要一开始就在大规模机器上跑完整参数消融。先在单卡或小批量上建立 baseline固定所有默认参数然后每次只改动一个变量。等确认这个变量在小规模上有效再放大资源验证。小规模实验适合使用较低分辨率和较少训练步数例如先跑 256x256 的扩散模型而不是一上来就做 1024x1024 的完整训练。目的是观察趋势不是追求最终质量。7.2 从日志到实验记录的完整清单以下清单可以直接复制到项目 README 或 experiment 目录模型结构UNet、VAE、文本编码器的版本。训练数据图片数量、文本质量、处理器版本。优化器学习率、beta、weight decay。噪声计划调度器名称和关键参数。时间步采样是否加权、分桶方式。条件丢弃概率值。训练精度fp16、bf16、fp32。随机种子。采样器推理阶段使用名称。推理配置步数、CFG、分辨率、negative prompt。指标FID、CLIP Score、人工评分。这份清单越大越容易发现“看似无关的配置其实决定了实验成败”。7.3 对比表训练相关变量、推理相关变量、基础设施变量类型变量推荐默认值参考调参副作用训练学习率1e-5 到 1e-4过大会训练不稳过小收敛慢训练时间步采样权重均匀或按 SNR 加权权重不合理会导致某阶段拟合差训练条件丢弃概率0.05 到 0.15过小语义过拟合过大控制力弱推理CFG5 到 9过大约束强过小语义弱推理采样步数20 到 40过高会过采样过低缺细节基础设施batch size显存允许的最大值过大会梯度不稳过小训练慢基础设施随机种子固定多组只固定一组可能得到偶然结论7.4 可以继续深入的方向文生图 Scaling 的新变量还没有形成统一理论但实验方法已经非常明确。下一步可以从以下几个方向继续深入对噪声调度和信噪比做系统消融记录各时间步的损失曲线。对数据集中文本与图像的匹配质量做自动化评分而不是只看人工筛选。将推理阶段的采样器和训练阶段的时间步采样统一到同一套评估 pipeline 中。研究多种模态编码器容量匹配问题而不是单独放大 UNet。对普通开发者来说最有价值的练习是拿一个开源小模型固定住训练和推理的默认配置然后每次只改动一项记录指标变化。做完 10 组以上对照实验后你会发现自己对“文生图为什么可以 Scaling”的判断比只读论文要准确得多。
