ComfyUI 运行 SD3.5：低显存 FP8 工作流配置与排错

显卡只有 8GB 甚至更少，又想在本地跑 Stable Diffusion 3.5，很多人第一步就卡住了：要么模型加载时直接报显存不足，要么文本编码器没放对位置，节点一片飘红。其实 SD3.5 对低显存用户并不算友好，但官方提供了 FP8 版本的权重，再配合 ComfyUI 的几项内存设置，8GB 到 12GB 的卡是能跑起来的。这篇就按"准备文件、导入工作流、运行、验证、排错"的顺序，把低显存下 FP8 工作流的落地路径讲清楚。

需要说明的是，下面涉及的模型文件名、仓库路径都来自 Comfy-Org 官方的 SD3.5 示例说明，发布前请以 ComfyUI 官方工作流和 Hugging Face 上的实际文件为准，官方偶尔会调整文件命名。

先搞清楚：FP8 为什么能省显存

SD3.5 的完整权重是 FP16 精度，对低显存卡压力很大。FP8 的思路是把模型权重用 8 位浮点存储，占用大致是 FP16 的一半，加载时显存压力明显下降。代价是数值精度降低，极端情况下细节会有轻微损失，但在大多数出图场景里肉眼很难分辨。

对低显存用户来说，FP8 不是"可选优化"，而是能不能跑起来的分界线。另外有一点要先建立概念：ComfyUI 里一张图能不能出来，吃的是三块东西——主模型（checkpoint）、文本编码器（text encoder，也就是 CLIP 和 T5）、以及采样过程中的中间张量。FP8 主要压的是前两块，后面的显存设置管的是第三块。

还有个容易忽略的点：SD3.5 有两个规格，一个是 80 亿参数的 large 模型，一个是 25 亿参数的 medium 模型。medium 更快、占用更少，画质上可能略逊一筹。显存特别紧张的话，不必死磕 large，medium 往往是更现实的起点。

准备阶段：模型和文本编码器放对位置

SD3.5 的工作流和 SDXL 不太一样，它把文本编码器单独拆出来，需要你手动下载三个编码器文件。按官方示例的说法，第一步是准备这几个文件（如果你之前跑过 SD3、Flux，可能已经有了）：

• clip_l.safetensors
• clip_g.safetensors
• t5xxl 系列（二选一，见下）

这些文件在 Comfy-Org 的 stable-diffusion-3.5-fp8 仓库里都能找到。关键是 t5xxl 要按内存情况选：

注意这里说的是系统内存（RAM），不是显存。T5 这个文本编码器本身很大，低配机器选 FP8 版本能少占不少内存。

下载完以后，三个文本编码器都要放进这个目录：

ComfyUI/models/text_encoders/

主模型（SD3.5 的 FP8 checkpoint）则放在：

ComfyUI/models/checkpoints/

路径放错是新手最常见的翻车点。ComfyUI 只会在这些固定目录里扫描文件，放到桌面或下载文件夹里，节点下拉框是找不到的。放好后记得在 ComfyUI 界面右上角刷新一下，或者重启服务，让它重新扫描。

导入并运行 FP8 工作流

文件就位后，就可以上工作流了。推荐直接用官方 SD3.5 示例工作流，它已经把节点连接关系配好，低配用户不用自己从零连线。

导入步骤大致是这样：

1. 启动 ComfyUI，打开网页界面。
2. 把官方提供的工作流文件（通常是一张带元数据的 PNG 图或一个 JSON 文件）直接拖进 ComfyUI 画布，它会自动还原整套节点。
3. 在加载模型的节点里，确认下拉框选中的是你下载的 SD3.5 FP8 checkpoint。
4. 在三个文本编码器加载节点里，分别选上 clip_l、clip_g 和你那版 t5xxl。
5. 填好正向、负向提示词，点击运行（队列提示词）。

和 SDXL 单文件 checkpoint 不同，SD3.5 这套是"主模型 + 三个编码器"分开加载的结构。所以如果你拖进来的工作流里有多个加载节点，不要慌，那是正常的，逐个把文件对应上就行。

第一次运行会比较慢，因为模型要从硬盘加载进显存/内存。耐心等它跑完一轮，后面再出图就快了。

低显存关键设置：让它真的能跑完

光有 FP8 还不够，低显存卡在采样阶段仍可能爆显存。ComfyUI 自带几个启动参数和优化手段，是低配用户的救命稻草。

最常用的是启动时加显存模式参数。显存特别小的，用低显存模式：

python main.py --lowvram

--lowvram 的核心逻辑是把模型拆分，不常用的部分暂时放到系统内存里，需要时再调进显存，用速度换空间。显存实在太小还可以试更激进的模式，但越激进越慢，够用就好，不要一上来就开到底。

除了启动参数，还有几项优化值得一起开：

• 注意力优化：启用 xformers 或 SDP 注意力，能在几乎不影响画质的前提下省下一块显存。
• 分块 VAE 解码（Tiled VAE）：出图最后一步解码时，VAE 容易成为显存尖峰。分块解码把大图拆成小块处理，专治"前面都好好的，最后一步爆显存"。
• 模型卸载：让编码器和主模型按需顺序加载，而不是一次性全塞进显存。

按资料里给出的经验，注意力优化 + 分块 VAE + 模型卸载组合起来，大约能省下 4 到 8GB 显存，而速度影响很小。对 8GB、12GB 的卡来说，这几项基本是默认就该开的。

分辨率也要量力而行。SD3.5 原生分辨率较高，低显存卡建议先从较低分辨率试跑，确认流程通了、能稳定出图，再逐步往上加。先求能跑，再求跑得好。

验证：怎么判断工作流真的配对了

跑完第一张图，别光看好不好看，先确认几件事，判断工作流是不是真的按预期在工作：

• 是否完整出图：进度条走到 100%、最后能看到成品图，说明从加载到 VAE 解码整条链路都通了。
• 显存是否稳定：用 nvidia-smi 盯一下显存占用，看它在采样阶段的峰值，离爆满还有没有余量。命令如下：

nvidia-smi

• 文本是否被正确理解：改一两个提示词关键词，看出图内容有没有跟着变。如果怎么改都没反应，很可能是某个文本编码器没加载对。
• 控制台日志：ComfyUI 的终端窗口会打印加载了哪些模型、有没有警告，这是排错时第一个该看的地方。

能稳定跑完、显存有余量、提示词有响应，这套 FP8 工作流就算落地成功了。

常见故障排查

即便按上面做了，低配环境还是容易出各种状况。下面是几类高频问题和检查思路。

模型加载失败 / 节点里找不到文件

这类问题九成是路径或文件本身的问题，按顺序排查：

• 确认文本编码器确实在 ComfyUI/models/text_encoders/，checkpoint 在 ComfyUI/models/checkpoints/，没放错目录。
• 下拉框里看不到文件，先点刷新或重启 ComfyUI，让它重新扫描目录。
• 检查文件是不是下载完整。网络中断导致的半截文件，大小对不上，加载时会报错。
• 文件名别乱改。工作流节点按你选中的文件工作，但下载时如果文件损坏或是网页另存成了 HTML，就会出问题。

显存不足（out of memory）

报 OOM 一般出现在加载或采样阶段，按这个顺序往下压：

1. 确认用的是 FP8 的 checkpoint 和 FP8 的 t5xxl，而不是误用了 FP16 版本。
2. 加上 --lowvram 启动参数。
3. 开启注意力优化和分块 VAE 解码。
4. 把出图分辨率降下来，批量大小（batch size）设为 1。
5. 实在跑不动，就从 large 模型换成 medium 模型，它占用更小、更快。

一个常见的坑是：OOM 发生在最后 VAE 解码那一步，前面采样都正常。这种情况优先开分块 VAE，往往一招就解决。

速度慢到难以接受

低显存模式用速度换空间，慢是正常的，但如果慢得离谱，检查：

• 是不是开了过于激进的显存模式，适当放宽。
• 系统内存是不是也满了。T5 编码器很吃内存，内存不足会疯狂使用硬盘交换，拖慢全局。
• t5xxl 选的是不是和你机器匹配的版本，内存不够却硬上 FP16 版，会非常吃力。

下面把这几类问题整理成一张速查表，方便对照：

下一步可以怎么调

把 FP8 工作流稳定跑起来之后，再谈优化就有空间了。如果显存还有余量，可以试着把 t5xxl 换回 FP16 版本看看文本理解有没有提升；如果你用的是 medium 模型且对细节不满意，内存条件允许时可以尝试 large 模型做对比。分辨率也可以在显存峰值允许的范围内一点点往上加，每加一档都用 nvidia-smi 观察峰值变化，找到你这张卡的稳定上限。

核心思路始终是：先用 FP8 加内存优化把流程跑通，确认每一步都正常，再在显存余量允许的前提下逐项往上调。对低显存用户来说，能稳定复现地出图，远比一次性堆满参数更重要。