先聊点没写在文档里的东西我为什么现在才写这一篇两年前我第一次跑通 stable diffusion 的时候被一群教程带着把 webui 里那些滑杆推来推去最后出来一张不错的脸就觉得自己懂了。后来真正要把 diffusion 模型部署到生产环境、要批量出图、要控制显存占用、要在老显卡上抠性能的时候才发现自己脑子里那点东西全是散的。所以这个系列我压了很久没动笔就是因为怕写成一堆概念名词的堆砌大家看完觉得“讲得挺全”回头自己动手还是不知从哪开始。这个“总纲篇”就是我想了很久之后决定先写的东西不直接教某个具体操作而是把 diffusion 推理这件事从原理到工程、从模型到参数、从工具到瓶颈完整地串一遍。适合两类人看第一类是刚把 stable diffusion 跑通、但想搞清楚“为什么换了采样器差别这么大”“为什么我的显卡占用这么低却这么慢”的人第二类是准备把 diffusion 模型接进自己的产品、服务需要做推理加速和性能优化的人。我尽量讲人话能用类比说明白的不用公式硬砸但涉及关键参数的地方不回避计算因为后面每一篇我们都要跟显存、跟耗时、跟画质打交道。现在先把这个体系搭起来。1. 内容整体设计与思路拆解1.1 推理到底是个什么过程说个最直白的比喻训练是“学画画”推理是“照着感觉把画画出来”。训练阶段模型看了海量图文对学会了“文本描述”和“图像内容”之间的对应关系权重全部冻结之后它就是一个拿着画笔的熟手。推理阶段我们给它一句话prompt它从一张纯噪声图开始一步步“去噪”最终还原出符合描述的图像。diffusion 模型全名是 denoising diffusion probabilistic model核心机制就是前向过程不断加噪、反向过程不断去噪。前向过程是数学上定义好的把一张干净图片逐步污染成高斯噪声反向过程是模型要学的给定一个带噪图像和当前步数预测出噪声然后减掉它。真正跑推理的时候我们只执行反向过程而且不是完整的一千步而是用采样器把步数压缩到几十步甚至几步。这里有个新手普遍绕不过去的弯扩散模型本身并不“生成”图像它是在“去噪”。所以 stable diffusion 整个推理链路其实是这样的文本编码器把 Prompt 变成条件向量VAE 把图像从像素空间压缩到潜空间UNet或 DiT在潜空间里做去噪迭代最后 VAE 解码器再把潜变量还原成像素图。四个组件各干各的活任何一个环节出问题都会直接反映在出图效果和速度上。1.2 为什么推理速度和显存会成为核心痛点很多人第一次跑 stable diffusion 是在自己的消费级显卡上跑通之后第一反应是“好慢”。慢在哪去噪迭代是循环每一步都要让 UNet 做一次完整的前向传播。假设默认 30 步那就是 30 次 UNet 前向每一步还要跟时间步 embedding、文本条件做交叉注意力。这还不算 VAE 解码也不算模型加载的时间。显存问题就更好理解了UNet 本身参数就有近 0.9BSD1.5 系FP16 下光权重就接近 2GB推理过程中的中间激活值、注意力矩阵、噪声预测的临时变量都会占用显存。SDXL 的 UNet 更大FLUX 直接换成了 DiT 架构参数更多。所以“显存不够”不是玄学是数学权重 激活 临时张量 解码缓冲四样加在一起超了就爆。我后来接触推理引擎优化才明白那些加速框架到底在优化什么不是魔法而是从“算得少”“搬得少”“存得巧”三个方向下手。算得少是剪枝蒸馏量化搬得少是算子融合和 Kernel 优化存得巧是显存复用、offload 和内存管理。理解了这一层才能在选工具的时候不盲目跟风。1.3 这套总纲想帮你建立的能力地图我给整个系列规划了“由上到下、由原理到工程”的路线这一篇总纲先做全局梳理后面每一篇再单独深入一个主题。顺序大概是模型选型篇SD1.5、SDXL、FLUX 这些底座模型各自适合什么场景LoRA、ControlNet 怎么接入推理链路采样器与参数篇DDIM、DPM、Euler 这些采样器到底在调什么CFG、步数、种子怎么搭配显存优化篇FP16、xformers、模型 offload、低显存推理的各种手段推理引擎篇webui、ComfyUI、diffusers 库、TensorRT、ONNX Runtime、OpenVINO 这些方案的差异和适用场景性能分析与实战篇怎么用 profiling 工具定位瓶颈怎么针对性优化服务化部署篇模型怎么封装成 API批量请求怎么做排队生产环境怎么稳定运行。这一篇后面提到的具体内容和参数会在对应篇章展开不会只挖坑不填。2. 核心细节解析与实操要点2.1 先认识四个核心组件文本编码器、VAE、UNet/DiT、调度器文本编码器负责把 Prompt 转换成模型能理解的向量表示。SD1.5 用的是 CLIP ViT-LSDXL 用两个 CLIP 模型然后拼接FLUX 用的是 T5 加 CLIP 的组合。文本编码器输出的是一个 token 序列的 embeddings之后会拼上时间步 embedding 一起进入去噪网络。很多人遇到“写了很长的英文 Prompt 但后半段没生效”的问题根源就是文本编码器有 token 上限SD1.5 是 77SDXL 也是 77虽然有两个编码器超出部分被截断了。VAE变分自编码器承担图像在像素空间和潜空间之间的转换。stable diffusion 最开始的版本用 EMA 版本 VAE细节和色彩表现都比较一般后来社区搞出了 x4-upscaler 版本和 fp16-fix 版本出图清晰度和颜色有明显改善。VAE 推理本身的 cost 并不高但在低显存设备上decoder 那一下也会成为显存尖峰很多“图快出来的时候爆显存”的案例都跟 VAE 解码有关。UNet 或 DiT是真正的去噪主干。SD1.5 和 SDXL 用的是 UNet结构是“下采样-中间层-上采样”的 U 形网络里面对每个分辨率层级做 ResNet 块和 Transformer 块用交叉注意力把文本条件融合进来。FLUX、SD3 这些新模型换成了 DiTDiffusion Transformer结构上最大的区别是取消了 U 形下采样上采样结构直接对所有 token 做全局注意力。DiT 对文本理解更强、图像质量更好但计算量更大对推理优化要求更高。调度器Scheduler是很多人忽略但其实影响巨大的组件。调度器决定了两件事每一步怎么根据模型预测的噪声去更新当前图像。不同调度器意味着不同的噪声调度策略和更新公式。DDIM 是确定性采样步数可以很少DPM 系列在数学上推导了更高效的求解过程用较少的步数就能逼近完整 SDE/ODE 解。跑图时你会发现“同一个种子、同一个 Prompt换采样器出来的图不一样”就是因为采样轨迹不同。2.2 文本编码、时间步嵌入、采样这些环节分别卡在哪推理链路可以切成三段看条件准备、迭代去噪、图像解码。条件准备阶段文本编码器要把 Prompt 跑一遍通常耗时几十毫秒到几百毫秒不等虽然占比不大但长文本或者用了 T5 这种大编码器时这段也不容忽视。迭代去噪阶段是绝对的大头。以 SD1.5 在 RTX 3060 上为例512x512、20 步 Euler、CFG7大约在 5~7 秒。这期间 UNet 为主干的每次前向大概占 200~300ms20 步就是 4~6 秒。SDXL 在同样条件下要翻倍甚至更多因为 UNet 参数和分辨率都上去了SDXL 原生只出 1024x1024。FLUX 更重哪怕是 dev 版本一次出图在消费级显卡上都是按十秒算的。图像解码阶段VAE decoder 把 8 倍下采样的潜变量还原成原分辨率。这个阶段主要吃显存512x512 下问题不大到 1024x1024 或者更高分辨率、batch 再大一点VAE 解码的显存尖峰就会非常明显。这三段里迭代去噪是优化优先级最高的因为耗时占比最大。但显存优化恰恰不能只看 UNet很多时候是“解码爆了显存”或者“模型切换时峰值过高”这就是工程上容易踩的坑。2.3 显存占用怎么估为什么经常“算得好好的却爆了”推理时的显存占用可以粗略分成四块模型权重、中间激活、临时张量、框架缓存。模型权重相对好估SD1.5 的 UNet 在 FP16 下约 1.7GBVAE 和文本编码器加起来再加几百 MBSDXL 的 UNet FP16 约 5.2GBFLUX.1-dev 整套 FP16 大约 34GB。FP32 直接翻倍。中间激活是最容易被低估的部分。激活值是前向传播过程中每一层的临时输出分辨率越高、batch 越大激活值越夸张。做一次 1024x1024 SDXL 推理如果 batch 为 1激活峰值可能到 2~4GB如果 batch 到 4不是线性四倍因为有些层有缓存复用但整体上涨依然明显。临时张量指的是注意力分数、噪声预测输出等也会挤占一部分。框架缓存就更隐蔽了。PyTorch 的 CUDA caching allocator 会保留显存不立刻释放为的是避免反复申请释放的开销。所以经常出现“torch.cuda.max_memory_allocated 明明不高但 nvidia-smi 显示占用很高”的现象这不一定泄漏只是缓存策略。排障的时候别被 nvidia-smi 的数值吓到先看实际分配。估算公式很简单峰值显存 ≈ 模型权重 最大激活值 最大临时张量 解码峰值。以 8GB 显存跑 SDXL 为例模型权重 FP16 约 6GB 出头激活一上来就爆这就是为什么很多人 8GB 跑 SDXL 很难受必须开 offload 或者切到低显存优化模式。理解了这四块再看各种优化手段就会很清楚它到底在压哪一块。2.4 模型选型怎么配场景LoRA 和 ControlNet 改变了什么底座模型选型这事我直接用经验排个优先级想要最省资源、显卡只有 4~6GBSD1.5 依然是最稳的选择成熟生态 大量开源 LoRA 都能直接用想要质量明显提升、显存 8GB 以上SDXL 值得换尤其画质细腻度和文本理解都比 1.5 好不少RTX 4060 级别就能跑想要最强的 prompt 遵循和画面质量不差显存FLUX.1-dev 是目前社区共识里的摸高选择但部署成本和推理耗时都高不少。LoRA 是低秩适配层训练时冻结原模型、只训练一个很小的低秩矩阵推理时叠加权重不改变原模型结构。它的意义在于“用一个很小的文件给模型注入风格或者角色特征”运行时不需要重训模型加载 LoRA 只增加少量额外计算。ControlNet 则是额外的小网络接受边缘图、深度图、姿态图等条件输入在推理时通过额外条件引导 UNet 的去噪过程。它的出现让“精确控制构图”成为可能但这家伙非常吃显存和显存带宽很多人 SD1.5 打印一张带 ControlNet 的图就明显卡顿这是正常的。3. 实操过程与核心环节实现3.1 本地推理环境搭建从“能跑”到“跑得好”我在本地搭建和调优推理环境已经花了很多时间最典型的配置有三个Windows NVIDIA 显卡用 WebUI 或 ComfyUI 入门Linux 服务器 NVIDIA 显卡用 diffusers 脚本或 ComfyUI 做批量生成老一点的核显或 CPU 用 OpenVINO 或 ONNX Runtime 做部署探索。如果纯粹为了学习我建议从 diffusers 库开始因为它的 API 设计得很规整能让你清楚看到每一步发生了什么。举个例子用 diffusers 加载 SD1.5 并推理的完整流程大概长这样import torch from diffusers import StableDiffusionPipeline pipe StableDiffusionPipeline.from_pretrained( runwayml/stable-diffusion-v1-5, torch_dtypetorch.float16, safety_checkerNone ) pipe pipe.to(cuda) g torch.Generator(devicecuda) g.manual_seed(42) image pipe( a photo of a cat holding a sign that says Hello Diffusion, num_inference_steps30, guidance_scale7.5, generatorg, ).images[0] image.save(sample.png)这段代码展示了完整的四个组件协作过程。注意我加了torch_dtypetorch.float16这就是一个最基础的显存减半手段。Generator手动固定了种子种子固定时采样器路径确定才能复现实验。guidance_scale设 7.5 是 SD1.5 时代比较常用的 CFG 值。这里每一步的调用底层都在经历“文本编码 - UNet 去噪循环 - VAE 解码”的完整链路。如果是为了出图效率我强烈建议直接上 ComfyUI。它的核心优势是“把整个流程做成图”每个节点显式控制加载哪个模型、用哪个采样器、怎么连接 LoRA 和 ControlNet对理解整个推理流程帮助极大。而且 ComfyUI 默认就做了很多显存复用和优化同样 8GB 显存跑 SDXL 的体验比早期 WebUI 顺畅不少。3.2 参数选择的过程步数、CFG、采样器怎么组合才不玄学先说步数。步数越多去噪过程越精细但收益递减。SD1.5 用 Euler 或 DDIM20 步已经能出不错的图DPM 2M Karras 通常 20~30 步到了 SDXL常用 30 步左右FLUX 官方推荐 50 步但社区测试过 20 步和 4 步蒸馏版本也已经可用。步数不是越高越好步数高到一定程度之后细节变化肉眼几乎不可见而耗时线性增加性价比很低。CFGguidance scale控制“无条件生成”和“有条件生成”的插值权重。字面理解是“跟 prompt 贴得多紧”CFG 太高容易过曝、色彩失真、边缘发硬太低则可能偏题。SD1.5 常用 7~9SDXL 常用 5~7FLUX 有点特殊官方模型没有 Classifier-Free Guidance 的独立支持但社区也有基于该架构的 CFG 用法。这个参数不是越大越好很多新手把 CFG 拉到 15 以上图会“烧焦”一样不是模型出问题了是权重失衡。采样器方面我总结一张表方便对照采样器特点推荐场景DDIM经典确定性采样步数可少复现实验、老版本模型Euler / Euler a简单快速适合宽泛风格日常快速出图DPM 2M / 2S质量好收敛快SDXL 及中高步数场景DPM SDE细节丰富偶有随机感追求纹理和细节时UniPC高效少步数效果不错低步数加速Restart多次重启噪声画质细节强慢讲究极限细节时这不是让你背参数表而是要理解组合逻辑低步数时优先用数学上收敛好的采样器DPM 2M追求速度时用 Euler需要复现实验用 DDIM。种子固定后这些参数组合路径是确定的但换采样器等同于换了整条采样轨迹所以效果差异巨大。3.3 实操中的三种模式单张生成、批量脚本、服务化封装单张生成是调试模型和提示词用的主要看效果。批量生成则是生产里最常做的事比如我用 diffusers 写过一个批量生成脚本核心逻辑是循环调用 pipeline搭配进度条和定时统计输出到指定目录。这里有个明显要注意的点——PyTorch 默认在循环里会反复申请释放显存如果每张图都从加载完整模型开始速度会慢得惊人。正确做法是把 pipeline 实例化一次循环里只换 Prompt这样模型权重常驻显存速度提升极快。服务化封装是另一回事。把 diffusers 的 pipeline 包装成 FastAPI 接口不难真正难的是并发请求时显存和调度的控制。一个 batch 请求进来如果同时跑多个去噪循环显存峰值会先爆掉如果串行排队吞吐上不去。服务化场景通常要配合推理引擎来做并发控制、请求队列和动态 batch这在后面服务化部署篇会详细展开。我还建议养成 profiling 的习惯每次跑一批图记录模型加载时间、首次推理时间、稳定推理时间、峰值显存。用torch.cuda.max_memory_allocated()和torch.cuda.synchronize()测时间别直接time.time()包一下就完事因为 PyTorch 是异步执行的不 synchronize 测出来的是提交任务的时间而不是真正跑完的时间。3.4 推理引擎选型WebUI、ComfyUI、diffusers、TensorRT、ONNX Runtime、OpenVINO很多人的困惑是“我该用哪个”。我的建议是学习用 diffusers 看清原理创作用 ComfyUI 提效生产环境要提速就上 TensorRT 或者 ONNX Runtime。先看 WebUI它的优势是插件生态极其丰富适合新手把各种 LoRA、ControlNet、超分扩展装起来直接玩。但底层它其实包裹了 diffusers 类似的逻辑优化空间和可定制性差一些跑高分辨率或批量任务时效率上不去。ComfyUI 是节点式图形化流程编辑器每个环节都暴露出来可以做非常精细的流程控制。它有“队列管理”和“显存自动管理”机制比较适合折腾优化和低显存场景。我自己已经全面切到 ComfyUI 作为本地主力工具因为它的可视化和可复现性对调试模型太有用了。TensorRT 的价值在于“用模型编译换推理速度”。它不是运行 PyTorch 的动态图而是把模型编译成优化后的静态引擎然后做层融合、精度校准、内存规划。同样一个 SDXL UNetTensorRT 优化后能快 30%~50%但换来的是不能随意改模型结构换一个 LoRA 就要重新 build engine。ONNX Runtime 是微软出品跨平台支持好CPU 也能跑通过图优化和不同的 execution provider 适配不同硬件。OpenVINO 则是 Intel 的方案CPU 核显友好之前那个热搜词“780M 核显推理用哪个推理工具最合适”其实答案就是 OpenVINO在核显上搭 OpenVINO 跑 SD 出图内存带宽利用得不错。说句实在话如果你只是自己玩出图TensorRT 带来的加速不一定值得折腾但如果你是做产品或者批量出图TensorRT 那 30%~50% 的提速就能直接转化为成本优势。4. 常见问题与排查技巧实录4.1 爆显存、黑图、青图、人像崩坏这四个经典问题怎么定位爆显存是最常见的报错通常是CUDA out of memory。先看是不是真的显存不够把nvidia-smi和torch.cuda.max_memory_allocated都打出来区分是“模型太大”还是“激活峰值太高”。8GB 跑 SDXL 爆了很正常别急着调代码先降分辨率、降 batch、开 offload。如果是 WebUI把“启用低显存模式”打开或者把“模型 offload 到 CPU”打开基本都是这个思路。黑图通常是采样过程崩了。常见原因有模型加载方式不对导致权重精度问题FP16 在某些 VAE 场景会出 NaN或者采样步数太少、CFG 极端、采样器和模型不匹配。最诡异的“青图”往往来自 VAE 问题尤其是 fp16 下的 VAE 数值溢出导致 color shifting换成 fp32 VAE 或修复版 VAE 基本能解决。人像崩坏则大概率是模型、LoRA、CFG 或负面 Prompt 的组合问题跟推理引擎关系不大多从提示词工程和模型匹配角度排查。4.2 耗时异常偏高先测 components 耗时再决定优化火力很多人一上来就换 TensorRT我觉得太激进。排查性能问题第一步是把各阶段耗时拆开量。用torch.profiler或者在 pipeline 的关键节点手动标记时间先看文本编码、UNet 各步、VAE 解码各占多少。如果 UNet 占比 80%那优化重心就是采样步数、精度、Kernel 优化如果 VAE 解码占比高得离谱可能不是模型问题是图像尺寸太大或解码实现没优化。另一个常见坑CPU 瓶颈被 GPU 掩盖。数据预处理、文本 token 化、Python 侧调度开销如果都堆在 CPUGPU 就喂不饱表现为 GPU 利用率忽高忽低、耗时高但显存不高。这时候优先优化数据流水线不是去换更贵的显卡。还有个很容易被忽略的问题Windows 下没有 WDDM 显存回收机制优化换到 Linux 跑同样模型有时快不少这是系统层级的差异。我实测下来最有价值的一次性能优化不是换引擎而是把模型的enable_attention_slicing打开在低显存时把注意力切块计算牺牲一点速度换显存空间反而让整体流程能跑起来。这种“以时间换空间”的思路往往比盲目升级硬件更实用。4.3 复现困难与不确定性种子、采样器、环境差异你是不是遇到过这种情况同一段 Prompt昨天出图和今天出图不一样大部分原因是环境没锁死。PyTorch 版本、CUDA 版本、diffusers 版本、GPU 型号不同算子 kernel 的选择可能不同浮点累加顺序也可能不同结果自然有细微差异。要严格复现除了固定种子和采样器最好把依赖版本和环境信息一起记录。我一般会在生成时输出一个 JSON 配置把 prompt、seed、steps、cfg、sampler、model hash 全存下来这样复盘和 bug 定位都方便。另外注意“torch 的随机性”如果你固定了种子但因为加载了额外的随机模块比如 dropout 在推理时未关闭结果同样会抖动。推理时模型必须切到 eval 模式diffusers 封装里做了但如果自己写底层调用千万别漏掉model.eval()。4.4 低配设备的现实选择notebook、核显、无独显机器怎么玩先说核显场景。780M 这种核显跑 SD 不是不能跑但要走 OpenVINO 或者 CPU 方案别硬凑 CUDA。核显的内存带宽其实不错配大内存之后跑 SD1.5 出 512x512 的图是可以的只是速度比独显慢许多。我建议的心态是“能跑通就行先用来学流程和调 Prompt不追求速度上线”。无独显笔记本同理CPU 推理推荐 ONNX Runtime 加 int8 动态量化。质量会打点折扣但流程能完整跑通代码也能写清楚。预算允许的话二手 8GB 显存的 NVIDIA 卡比如 RTX 3060 或 4060是玩 stable diffusion 最舒服的入门选择性价比极高。macOS 用户则会碰到另一个流派MPS 后端 MLX。Apple Silicon 统一内存架构在推理大模型上有天然优势mlx 4-bit 量化跑 27B 模型也不罕见。SD 推理在 Mac 上比较成熟的是用 diffusers 的 MPS 支持或者直接跑 ComfyUI 的 Apple Silicon 版本。如果你想在 MacBook Pro 上本地跑不是不可以只是显存统一内存和散热会限制速度如果常跑 1024 以上大图还是建议用桌面级 GPU。5. 模型解析与生态热点5.1 SD1.5、SDXL、SD3、FLUX三代底座模型的演进逻辑聊完工程再来聊模型本身因为选型直接影响推理资源配置。SD1.5 是第一代开源扩散模型的经典稳定版UNet 架构512x512 训练分辨率CLIP 文本编码。它的优势是轻、快、生态老大量 LoRA 和插件都优先支持它劣势是文本遵循一般复杂场景容易画崩画质上限不如新模型。SDXL 把底座换成了更大的 UNet引入两个 CLIP 文本编码器原生 1024x1024 训练分辨率。画质进步明显对长 Prompt 的理解更强。但模型权重翻了几倍显存需求水涨船高。SDXL 时代社区涌现了非常多高质量 checkpoint它是目前“质量与成本平衡”最舒服的模型之一。SD3 和 FLUX 则代表新的 DiT 方向。SD3 是 Stability AI 的第一代 DiTFLUX 是 Black Forest Labs 的作品两者都用 T5 文本编码器文本遵循能力质变。FLUX.1-dev 和 FLUX.1-schnell蒸馏版成为社区热点效果极好但模型体量也最大推理成本明显高于 SDXL。如果你只是“想看看新模型多强”用在线 Demo 体验想在本地长期使用必须接受显存和耗时的现实。这三代模型的演进本质上是“容量变大、架构变强、成本上升”的路线。选型不是越新越好而是看你的硬件、延迟、画质需求到底在哪个平衡点。5.2 为什么“量化”成了热搜常客精度、速度与显存的三角关系“qbf 推理”“4-bit 推理速度”“模型量化”这些热搜背后是同一个刚需让大模型在低配设备上跑起来。量化就是把 FP16/FP32 的权重降到 INT8 或 INT4用更小的位宽存权重推理时用低精度矩阵乘。代价是精度损失可能需要校准而且不同量化方案效果差异很大。对 diffusion 推理来说量化常见的坑是“质量崩坏”。UNet 里对噪声的预测非常敏感量化误差如果太大去噪路径就会偏离出来的图像出现色块、伪影。所以不是“上了 INT8 就万事大吉”要对比原图 PSNR 或感官质量。ONNX Runtime 的动态量化、TensorRT 的 PTQ、以及各家社区的 FP8 方案我在实验里都试过结论是如果追求速度必须量化请一定保留一个 FP16 或 FP32 的对比链路随时回归验证。另一个热点“stable diffusion android 1.1.2”是把 SD 移植到移动端的尝试。移动端内存和算力都受限通常需要把 UNet 做得极小蒸馏版再配合量化才能达到“能用的延迟”。这说明“推理加快”从来不只是算法库的活而是模型结构、量化、硬件调度一起配合的结果。5.3 当前热点里值得关注的几个方向Diffusion Policy、世界模型、多模态热搜里还有几个看似不搭边的关键词其实都指向 diffusion 的价值外溢。一个是diffusion policy这是机器人操作领域的模型把扩散模型用在“动作序列生成”上输入当前状态和目标输出一系列机器人动作。它和图像生成的相似点在于都是用去噪过程从随机噪声中生成目标序列。另一个是世界模型推理公式世界模型试图让模型在内部建立环境动态的预测能力。扩散模型天然适合做“下一帧预测”和“状态轨迹生成”所以世界模型里也开始出现 diffusion 的影子。这些方向本质上都在利用同一个核心能力从分布中采样生成。图像生成只是 diffusion 能力的一个舞台动作、视频、3D、具身智能里的扩散也会越来越常见。如果你只做图像生成这些可以当背景知识看但如果你的视野是“多模态和具身智能”那 diffusion 推理的研究不会只停留在出图上。6. 一个随手就能抄走的提效方案6.1 低显存 ComfyUI 的一个配置参考我给一张比较通用的“低显存跑 SDXL”配置你可以按自己的硬件微调显卡8GB 显存RTX 3060/4060 级别ComfyUI 设置--lowvram或--novram参数具体看显存大小模型SDXL 系列 checkpoint配 fp16 权重采样器DPM 2M Karras步数 25~30分辨率1024x1024 起步如果卡顿降到 768x768关掉“高分辨率修复”需要大图时另接一个 upscale 节点遇到 LoRA 叠加尽量选低 rank 的rank 16 以内降低显存压力。这个配置实测能流畅跑 SDXL 出图单张 1024x1024 大约 10~15 秒看显卡性能。想继续提速再考虑 TensorRT 转换。6.2 批量出图的正确姿势和显存清理技巧批量出图最忌讳的是“每张图都重新加载模型”。正确姿势是加载一次 pipeline然后在循环里只切换 prompt 和种子用torch.inference_mode()包住推理段每张图生成后del image并torch.cuda.empty_cache()防止缓存堆积。别每一张图就pipe pipe.to(cuda)这样等于手动制造显存碎片。还有个小技巧批量任务中途如果显存越来越低很可能是某个节点没有显式释放张量或者 attention 计算把临时张量留在了缓存里。torch.cuda.empty_cache()不是万能的它只释放未使用的缓存块真正的显存泄漏要从代码里找原因。排查时先固定 prompt 跑 10 张观察显存曲线如果逐步爬升大概率存在泄漏。6.3 在线服务化部署的一个注意点请求排队与动态 batch服务化部署 pipeline 时一个容易忽略的事实是GPU 推理天然适合批量处理但请求是乱序到达的。不要简单地“来一个请求就开一条推理线程”那样并发一高显存必爆。正确做法是维护请求队列把相近的请求凑成一个 batch 一起推理。diffusers 的 pipeline 原生支持batch_size但需要自己实现“攒批逻辑”。另一个注意点是超时和取消。推理任务动辄几秒甚至几十秒客户端早就等得不耐烦了服务端要设计任务状态查询接口提交任务、返回 task_id、异步查询结果而不是同步 HTTP 请求阻塞着等出图。这个模式在批量生成海报、素材生成的业务里非常刚需。最后分享一点实际经验这个系列我准备写的时候一直在纠结要不要把原理讲这么细。后来想想稳定扩散stable diffusion这一套东西真正值钱的不只是“你能跑出图”而是你能解释“为什么这张图长这样”“为什么这个参数是这个效果”。我在实际做推理加速、服务化部署的过程中遇到的大部分问题最后都回到了对原理的理解而不是对某个工具的记忆。所以这一篇总纲的意义就是先把地图摊开。后面每一篇都会是独立完整的实操文但你不必等全部看完再动手可以先跑起来遇到具体问题再回来查对应篇章。如果想第一时间看到后续文章或者对某个具体问题感兴趣可以留言给我我会把想看的主题优先安排。下一篇我打算先写采样器与参数篇因为这是每个跑过 stable diffusion 的人都迟早要面对的“玄学”。