把话说在前头：NVIDIA DGX Spark 这台机器和 Stable Diffusion 3.5 的组合，属于那种“听起来就很有搞头、实际上也真有搞头”的本地图像生成方案。但如果你以为插上电源、装个 ComfyUI、下载一个大模型文件就能出图，那大概率会被三个文本编码器、分体权重和莫名其妙的 dtype 报错折腾到怀疑人生。这篇就按我实际部署的路线，把 DGX Spark 跑 SD3.5 的全过程、推荐参数、实测手感以及高频坑位一次性说清楚。
这篇文章适合手里有 DGX Spark（或者同等内存规模的 AI 工作站）的技术爱好者、摄影师、设计师，也适合那些正准备入手这类设备、想先用软件栈评估值不值得的人。内容主线是按部署顺序走的：先讲清楚这套硬件和模型的匹配逻辑，再讲系统栈准备、权重摆放、ComfyUI 工作流搭建，最后是一组可参考的压测数据和排错清单。有不少细节是我反复翻车之后才想明白的，能帮你少走不少弯路。
1. 先梳理清楚这套组合的“脾气”：SD3.5 的体量、DGX Spark 的边界
1.1 SD3.5 不是 SDXL 的简单升级
不少人在 SD1.5、SDXL 时代养成了一个习惯：找一个完整的.safetensors文件，丢进models/checkpoints，然后用 CheckpointLoader 加载，完事。到了 Stable Diffusion 3.5，这套思路基本行不通。
原因在于 SD3.5 的架构发生了本质变化。它不再是“一个 UNet + 两个 CLIP 文本编码器”那么简单，而是基于 MMDiT（多模态扩散 Transformer），文本理解部分由三个编码器协同完成：CLIP-L、CLIP-G，以及体量巨大的 T5-XXL。主模型参数规模也上了一个台阶——SD3.5 Large 版本大约是 8B 参数级别，Medium 版本也有 2.5B 左右。
这里先给一张直观的对比表，方便你快速建立体量概念：
| 模型 | 主网络参数 | 文本编码器 | fp16 权重体积（近似） | 对显存的友好度 |
|---|---|---|---|---|
| SD1.5 | 0.9B | 单 CLIP | 2~4GB | 很友好，8GB 显存可玩 |
| SDXL | 2.6B | 双 CLIP | 5~7GB | 比较友好，12GB 起步舒服 |
| SD3.5 Medium | 2.5B | 三编码器 | 10GB 级别 | 至少 16GB，推荐 24GB |
| SD3.5 Large | 8B | 三编码器 | 20GB 级别 | 24GB 很紧张，内存越大越稳 |
你可以把三个文本编码器理解成三个“翻译官”，它们分别从不同维度理解你写的提示词，再由主网络统一融合成图像。翻译官多，意味着提示词的理解能力强很多，但代价就是显存和内存压力急剧上升。尤其是 T5-XXL 这个编码器，它本身就要占不少空间，很多“跑不了 SD3.5”的案例，根本不是主模型放不下，而是 T5 没地方放。
1.2 DGX Spark 的统一内存为什么正好踩中需求
DGX Spark 的核心优势不是“显存大”，而是整个 CPU 和 GPU 共享一套内存池。官方给的配置是 128GB 级别的统一内存，GPU 需要数据时不再像传统独立显卡那样，先把权重从内存搬运到显存，搬不动就频繁换页。它更像是把厨房和仓库打通了，素材就在手边，随取随用。
这个特性对 SD3.5 这种“体积大、但不需要超大带宽持续读写”的模型特别友好。我举个不算太严谨但很好理解的类比：普通 24GB 显存的显卡，相当于一个操作台面比较小的厨房，食材（权重）堆在仓库（系统内存）里，每做一道菜都要来回搬；DGX Spark 则是直接把仓库和厨房合并成一个开放式空间，厨具和食材都在台面上，转身就能拿到。
所以你别只盯着 DGX Spark 单卡算力去看，它的核心价值在于“模型常驻 + 频繁切换 + 批量出图”这三件事。你的模型加载时间会明显缩短，连续生成几十张图时，不会出现中期突然崩显存的情况。
1.3 本地部署的三个真正理由
有人会问，现在在线生图服务那么多，为什么还要本地部署？以我自己的使用场景，理由主要有三个：
一是隐私。一些工作流的参考图、产品图、人物素材不适合发到在线服务。本地生成意味着所有中间状态都留在自己机器里。
二是跨模型的批量操作。在线服务通常一次只给你一个模型接口，而本地 ComfyUI 可以同时准备多个 checkpoint，换着用、并且能自由组合 LoRA 或者不同的 VAE。
三是长期成本。如果每天要出几百张图，按在线服务的点数计算并不便宜。而 DGX Spark 这类设备虽然入手价格不低，但只要你跑的量够大，摊到每张图的成本会迅速降下来。
2. 部署前的三层准备：系统栈、Python、ComfyUI 本体
2.1 驱动和 CUDA：先确认“底层物业”是通的
拿到 DGX Spark 之后，最忌讳的事情就是直接去装 ComfyUI。驱动层没理顺，后面所有报错都会变得极其难排查。
第一件事是在终端跑一下：
nvidia-smi如果有正常的 GPU 信息输出，说明驱动已经识别到计算设备。如果这条命令没有任何输出，或者显示 GPU 处于不可用状态，那你需要先去 DGX 自带的系统面板或者 BIOS 层面确认 GPU 模式已经启用，必要时重启一下机器。
DGX Spark 出厂带的驱动版本通常不低，但未必是最新的。我的做法是：
sudo apt update sudo apt upgrade -y然后重新检查nvidia-smi显示的 CUDA 版本号。注意，这里 CUDA 版本不用刻意去装完整的 CUDA Toolkit，因为 PyTorch 的安装包自带 CUDA runtime，你只要保证驱动支持对应版本的 CUDA 就行。换句话说，驱动版本决定了你能用多少新的 CUDA，而不是你装了什么 CUDA 工具包。
2.2 Python 虚拟环境：给 ComfyUI 一间独立的厨房
ComfyUI 本身是纯 Python 项目，但它依赖的 PyTorch、transformers 等库对版本非常敏感。如果你直接在系统自带的 Python 环境里装，未来某天升级了系统包，ComfyUI 可能说崩就崩。
我推荐用venv或者 Conda 创建独立环境，Python 版本选 3.11。不是最新版本就一定最好——PyTorch 对 3.12、3.13 的支持虽然已经跟上，但生态里不少辅助库（比如图像预处理、节点插件）仍然以 3.10/3.11 为最稳妥目标。以下是一套我实测通过的创建流程：
python3 -m venv ~/comfy_env source ~/comfy_env/bin/activate pip install --upgrade pip pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128这里特意指定了 cu128 的 PyTorch wheel，而不是直接用默认的 PyPI 源。默认源给你的通常是 CPU 版本或者某个通用版本，在 DGX Spark 这种新架构上很容易出现“torch 能装上，但识别不到 GPU”的问题。你装完以后可以这样验证一下：
python -c "import torch; print(torch.cuda.is_available())"看到True，再继续往下走；如果看到False，优先检查你是不是装成了 CPU 版。
2.3 ComfyUI 本体：获取、装依赖、跑通启动流程
获取 ComfyUI 本体比较简单，直接把仓库克隆到本地：
git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI pip install -r requirements.txt依赖装完之后，你可以先用默认配置启动一次试试：
python main.py --listen 0.0.0.0 --port 8188如果看到类似 “Starting server” 以及端口监听日志，说明 ComfyUI 框架已经正常。此时浏览器访问http://127.0.0.1:8188，应该能打开默认前端界面。
要特别说一句：这里先不急着追求界面上的 Flux、SD3 模板能不能加载。第一次启动的目标只是确认“环境是健康的”。我见过太多人一上来就下载 SD3.5 大权重，然后卡在某个依赖导入错误上，结果分不清是权重问题还是环境问题。顺序很重要——先让空架子跑起来，再往里放东西。
3. 权重下载与目录摆放：这一步翻车率最高
3.1 官方权重包里的文件结构
SD3.5 的官方权重在 ModelScope 和 Hugging Face 上都能找到，以 Large 版为例，你下载下来会看到一堆分散的文件，而不是一个完整的 checkpoint。目录大致长这样：
stable-diffusion-3.5-large/ ├── text_encoders/ │ ├── clip_l.safetensors │ ├── clip_g.safetensors │ └── t5xxl_fp8_e4m3fn_scaled.safetensors ├── unet/ │ └── sd3.5_large.safetensors ├── vae/ │ └── sd3.5_large_vae.safetensors └── model_index.json这里你要先建立一个认知：SD3.5 不是“一个文件”，而是一组文件。主模型在unet目录里，文本编码器在text_encoders目录里，还有单独的 VAE。ComfyUI 不能像 SDXL 那样直接一个节点全搞定，它需要分别加载这几部分，再在工作流里把它们组合起来。
3.2 文件到底应该放进 ComfyUI 的哪个目录
ComfyUI 的models目录下面细分了checkpoints、unet、clip、vae等子目录。SD3.5 的分体权重如果放错位置，loader 根本扫描不到文件，界面下拉列表里自然也是空的。正确的放置策略是：
| 文件 | 目标目录 | 作用 |
|---|---|---|
sd3.5_large.safetensors | ComfyUI/models/unet/ | 主扩散模型 |
clip_l.safetensors | ComfyUI/models/clip/ | 文本编码器 L |
clip_g.safetensors | ComfyUI/models/clip/ | 文本编码器 G |
t5xxl_fp8_e4m3fn_scaled.safetensors | ComfyUI/models/clip/ | 文本编码器 T5 |
sd3.5_large_vae.safetensors | ComfyUI/models/vae/ | 图像解码器 |
如果你下载的是社区已经合并好的单文件 checkpoint（有些整合包会把主模型、文本编码器、VAE 打包进一个.safetensors），那就可以放models/checkpoints，用传统 CheckpointLoader 加载。但这个方式对初学者更简单，却少了一些灵活性，而且不同打包来源的文件质量参差不齐。我更推荐走分体加载的路线，因为官方文件至少版本可控、报错时容易定位。
3.3 下载校验与命名规范
权重文件动辄十几 GB，下载过程很难保证文件完整。ComfyUI 加载时如果报Error(s) in loading state_dict一类错误，优先怀疑文件本身有问题。
下载完成后建议先做一下校验。以 Hugging Face 为例，模型页面上会给出每个文件的 SHA256 值，本地可以用：
sha256sum ./stable-diffusion-3.5-large/unet/sd3.5_large.safetensors拿到哈希值以后和页面比对。连哈希都不一样，别犹豫，重新下载。文件损坏时强行加载，往往不是立刻崩溃，而是生成阶段出现各种灵异现象，比如画面偏色、崩块、出图完全是噪声。
命名方面，我个人的习惯是“版本 + 精度”明确写清楚，比如sd35_large_fp16.safetensors和sd35_medium_fp8.safetensors。千万不要用v2新.safetensors这类名字，等到你机器里堆了几十个模型文件，光凭文件名都能让你翻半天。
4. 工作流搭建：把节点拧成一条出图流水线
4.1 从分体权重出发的节点连接逻辑
如果你走的是官方分体权重路线，ComfyUI 工作流的起点不会是 CheckpointLoaderSimple，而是UNETLoader加上两个CLIPLoader。
用大白话描述流程就是：
UNETLoader加载sd3.5_large.safetensors，作为主生成网络。- 两个
CLIPLoader分别加载clip_l、clip_g，这是前两个文本编码器。 - 第三个
CLIPLoader（或者同一个 Loader 的第二路）加载t5xxl_fp8_e4m3fn_scaled.safetensors，并且把加载类型指定为sd3。 CLIPTextEncode接收上述 CLIP 组合，把你写的提示词编码成模型能理解的条件向量。EmptyLatentImage设置宽高和 batch size。- 以上所有内容汇入
KSampler，选定采样器、步数、CFG，开始采样。 VAELoader加载sd35_large_vae.safetensors，配合VAEDecode把潜在表示还原成像素图。- 最后
SaveImage输出。
用文字表达可能抽象一点，但你打开 ComfyUI 自带的工作流模板——特别是 SD3.5 对应的示例流程——会发现节点连接顺序基本就是这样。建议第一次运行时不要自己从零拖节点，先加载官方模板，确认能跑通，再一个个节点去理解。
4.2 采样参数：SD3.5 的推荐口径与调校
SD3.5 的采样参数和 SD1.5 时代差别很大。很多人拿着老经验，CFG 拉高到 12、15，步数设 20，结果出图要么过曝、要么糊成一团，还以为权重坏了。
下面这组参数是我在 DGX Spark 上反复实验后认为比较稳妥的起点：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| sampler_name | euler | 稳定、综合表现好 |
| scheduler | normal | 长步数下比较平稳 |
| steps | 28~40 | 30 步左右足够 |
| cfg | 3.0~7.0 | 大幅低于 SD1.5 的习惯 |
| width / height | 1024 / 1024 | 官方训练分辨率附近 |
| batch_size | 1~8 | 内存宽裕可适度提高 |
关于 CFG，我想多解释一句。SD3.5 和 SDXL 类似，对 CFG 非常敏感，超过 8 以后画面容易“焦糊”，细节全部烧掉。如果你想要更突出的风格化表达，甚至可以把 CFG 直接降到 1，走无分类器引导模式，这时代理负向提示词的输入可以直接留空。你会发现模型本身对提示词的理解能力已经很强，不需要靠拉高 CFG 来“强迫”模型执行你的指令。
4.3 保存与复现：别忽略 PNG 里嵌入的工作流信息
ComfyUI 默认会把当前工作流嵌入到保存的 PNG 文件信息里。这意味着你可以在任意一台装了 ComfyUI 的机器上，直接把这个 PNG 拖进界面，工作流就自动还原。
这个功能我强烈建议用起来。因为你调参调了一晚上终于出一张满意的图，第二天再想复现时，如果找不到当时的工作流 JSON，那种懊恼程度不亚于写代码没保存。把好的出图文件按日期和主题归档，就是最好的“参数笔记本”。
5. 实测手感：生成速度、内存占用和加速三板斧
5.1 一组可参考的实际数据
先说明一下，DGX Spark 的固件版本、驱动版本、ComfyUI 版本都会影响最终数值，所以下面这组数据仅供量级参考，不代表绝对性能基准。测试环境是官方 fp16 权重、1024x1024 输出、30 步 Euler、CFG 4.5：
| 图像尺寸 | 步数 | 单张耗时（约） | 采样进程峰值内存（约） |
|---|---|---|---|
| 512x512 | 30 | 1~2 秒 | 约 15~20GB |
| 1024x1024 | 30 | 4~7 秒 | 约 25~30GB |
| 2048x1024 | 30 | 15~25 秒 | 约 50GB 以上 |
| 1024x1024（batch 4） | 30 | 15~25 秒 | 约 45GB 以上 |
可以看到，512 级别图基本是秒出，1024 属于日常舒适区，而 2048 宽度虽然能跑，但耗时和内存需求会明显上涨。DGX Spark 的优势在这里体现得很清楚：传统 24GB 显存显卡在 2048 宽度下通常需要各种显存优化技巧，而它靠统一内存可以硬扛下来，只是速度慢一些而已。
5.2 加速思路：别盲目追求“全打满”
跑起来以后，很多人第一反应是想让它更快。我的建议是先判断瓶颈到底在哪，再决定优化方案。
一个很实用的观察方法是：
nvidia-smi -l 1盯着 GPU 利用率看。如果生成过程中 GPU 利用率一直很低，说明瓶颈可能在 CPU 侧——比如文本编码、VAE 解码、图像保存这些环节在拖后腿，这时候盲目加大 batch 只会让 CPU 更吃力。如果 GPU 利用率已经很高，那优化空间主要就在权重精度和采样策略上。
实际部署中，我验证有效的三招是：
第一，使用 fp8 权重。官方视角下 fp8 版主模型体积接近减半，加载更快，出图质量与 fp16 的差异在 1024 分辨率下几乎不可感知。如果你的目标是大量出草稿图，fp8 是很好的日常选择。
第二，善用 ComfyUI 的模型缓存机制。同一批图如果反复用同一个模型，不要在每张图之间重新加载。ComfyUI 默认会对已加载模型做缓存，但有些自定义节点或者手动 reload 会破坏缓存，注意别频繁执行“refresh 模型”类的按钮。
第三，批量队列一次排入多任务。比如连续生成 20 张 1024 图，把它放进一个 5 batch x 4 次的任务队列，比逐张单独排队省去不少调度开销。
还有一个容易忽视的点：不要同时开多个 ComfyUI 实例。统一内存虽然大，但不是无限资源，两个实例同时跑采样容易触发内存回收，反而相互拖慢。
6. 高发问题排雷：报错、黑图、糊图、性能异常
6.1 加载阶段的报错对照表
最先遇到的一批问题集中在模型加载阶段。下面是我整理的高频错误和对应的处理思路：
| 报错现象 | 常见原因 | 处理方式 |
|---|---|---|
Error(s) in loading state_dict for UNET... | 权重文件损坏，或文件与目录不匹配 | 校验 SHA256；确认 unet/clip/vae 没放反 |
Expected one or more tensors but got... | CLIP 类型指定错误 | 在 CLIPLoader 中选择sd3类型，而不是flux |
The file has been created with another version of ComfyUI | 工作流来自新版本 | 升级 ComfyUI 或手动替换节点 |
No module named ... | Python 环境依赖缺失 | 重新检查 requirements，重新安装对应包 |
| 界面下拉列表里看不到模型 | 文件放错目录或未刷新节点 | 检查 models/unet、models/clip、models/vae 路径 |
这些错误里最坑的是loading state_dict类报错，因为它会被很多不同原因触发。有时候你以为文件坏了，其实只是你在下载时用了旧版本权重；有时候你以为版本不对，哈希一算发现文件根本是半截的。所以遇到这类报错，我的排查次序永远是：先验哈希，再查目录，最后看版本。
6.2 黑图与糊图：问题不在显存，在参数
出图出现全黑，通常不是硬件问题，而是参数或 VAE 问题。最常见的情况是 CFG 设置得太高，或者采样器和步数搭配不合理。建议先把 CFG 压到 4 左右，步数提到 30，采样器换回 Euler 试一遍。
还有一种黑图原因比较隐蔽——VAE 没有正确加载。如果你只放了 unet 和 clip，VAE 输出端是空的，解码出来的自然是无效图像。屏幕上会出现一个看似正常生成、但保存时完全黑掉的图片。检查节点连线时，重点看VAEDecode的输入是否真的来自VAELoader。
至于糊图，九成原因是步数不足。SD3.5 在 20 步以下时纹理细节容易发虚，尤其是复杂场景、人物皮肤、布料纹理。2023 年以后开源模型的趋势是“步数越少越快”，但 SD3.5 的官方推荐口径仍然偏保守，20 步适合创意草稿，30 步以上才是成图的舒适区。
6.3 性能与内存异常：日志比猜答案靠谱
DGX Spark 这类机器有个特点：内存大，但单卡 GPU 带宽毕竟不是数据中心级，遇到高分辨率大 batch 时，采样还是会出现明显延迟。你需要区分“正常慢”和“异常慢”。
正常慢：2048 级别的图，时间明显比 1024 长，进程内存上升到几十 GB，GPU 利用率波动。异常慢：512 的图也要跑十几秒，而且 nvidia-smi 显示 GPU 利用率极低，同时系统内存持续上涨。
遇到异常慢，先看 ComfyUI 的控制台日志。日志里会有每个节点执行的耗时统计，一眼就能看到是哪一步在拖后腿。如果慢的是 CLIP 编码，多半是 T5 模型路径不对导致反复读取；如果慢的是解码，重点查 VAE 是否误用了不匹配的文件。养成看日志的习惯之后，绝大多数“灵异问题”都不再灵异。
最后补一段私房建议
部署完成以后，你会发现整台机器其实还有很大的折腾空间。我个人最推荐接下来尝试的是 ComfyUI 的 API 模式。它可以把你的 DGX Spark 变成一台局域网的生成服务器，前端写一个简单的页面，甚至接上其他自动化工具，批量出图就完全不用在界面里手动排队了。SD3.5 的提示词理解能力也比老模型强出一大截，配合 API 做更精细的批量风格化，才算真正把硬件利用率拉满。先说到这里，祝各位一次跑通，少翻车。
