把话说在前头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.50.9B单 CLIP2~4GB很友好8GB 显存可玩SDXL2.6B双 CLIP5~7GB比较友好12GB 起步舒服SD3.5 Medium2.5B三编码器10GB 级别至少 16GB推荐 24GBSD3.5 Large8B三编码器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.safetensorsComfyUI/models/unet/主扩散模型clip_l.safetensorsComfyUI/models/clip/文本编码器 Lclip_g.safetensorsComfyUI/models/clip/文本编码器 Gt5xxl_fp8_e4m3fn_scaled.safetensorsComfyUI/models/clip/文本编码器 T5sd3.5_large_vae.safetensorsComfyUI/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_nameeuler稳定、综合表现好schedulernormal长步数下比较平稳steps28~4030 步左右足够cfg3.0~7.0大幅低于 SD1.5 的习惯width / height1024 / 1024官方训练分辨率附近batch_size1~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图像尺寸步数单张耗时约采样进程峰值内存约512x512301~2 秒约 15~20GB1024x1024304~7 秒约 25~30GB2048x10243015~25 秒约 50GB 以上1024x1024batch 43015~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类型而不是fluxThe 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 和 clipVAE 输出端是空的解码出来的自然是无效图像。屏幕上会出现一个看似正常生成、但保存时完全黑掉的图片。检查节点连线时重点看VAEDecode的输入是否真的来自VAELoader。至于糊图九成原因是步数不足。SD3.5 在 20 步以下时纹理细节容易发虚尤其是复杂场景、人物皮肤、布料纹理。2023 年以后开源模型的趋势是“步数越少越快”但 SD3.5 的官方推荐口径仍然偏保守20 步适合创意草稿30 步以上才是成图的舒适区。6.3 性能与内存异常日志比猜答案靠谱DGX Spark 这类机器有个特点内存大但单卡 GPU 带宽毕竟不是数据中心级遇到高分辨率大 batch 时采样还是会出现明显延迟。你需要区分“正常慢”和“异常慢”。正常慢2048 级别的图时间明显比 1024 长进程内存上升到几十 GBGPU 利用率波动。异常慢512 的图也要跑十几秒而且 nvidia-smi 显示 GPU 利用率极低同时系统内存持续上涨。遇到异常慢先看 ComfyUI 的控制台日志。日志里会有每个节点执行的耗时统计一眼就能看到是哪一步在拖后腿。如果慢的是 CLIP 编码多半是 T5 模型路径不对导致反复读取如果慢的是解码重点查 VAE 是否误用了不匹配的文件。养成看日志的习惯之后绝大多数“灵异问题”都不再灵异。最后补一段私房建议部署完成以后你会发现整台机器其实还有很大的折腾空间。我个人最推荐接下来尝试的是 ComfyUI 的 API 模式。它可以把你的 DGX Spark 变成一台局域网的生成服务器前端写一个简单的页面甚至接上其他自动化工具批量出图就完全不用在界面里手动排队了。SD3.5 的提示词理解能力也比老模型强出一大截配合 API 做更精细的批量风格化才算真正把硬件利用率拉满。先说到这里祝各位一次跑通少翻车。