★ FEATURED ARTICLE 手头有一台 NVIDIA DGX Spark想跑 Stable Diffusion 3.5 加速出图但发现网上资料大多是给普通工作站甚至云 GPU 准备的直接照搬到这台机器上要么驱动不对路要么依赖装崩要么根本吃不满这张卡。我自己在这台机器上折腾了一个周末把环境、模型、ComfyUI 全部跑通中间踩了不少坑这篇文章就把整个部署过程和调优细节完整写出来。先说明一下这台设备的定位。DGX Spark 说白了就是一台把超大显存、高带宽内存和专用加速单元整合在一起的小型个人 AI 工作站它在本地跑生成模型时最大的优势是显存容量大、内存带宽高非常适合直接跑 SD 3.5 这种对显存和带宽都极其敏感的模型同时因为它本质上还是基于 Linux 的系统软件栈和大规模服务器完全一致所以在上面搭 ComfyUI 的环境路径其实也适用于任何一台搭载了相同型号加速卡的 Linux 机器。这篇文章适合三类人一类是刚拿到 DGX Spark 正准备用它跑 ComfyUI 但无从下手的人一类是手里有其他大显存 Linux 工作站想参照这套流程部署 SD 3.5 的人还有一类是已经在用 ComfyUI 但想了解如何针对大显存设备做推理配置调整的人。1. 部署前必须想清楚的三件事1.1 为什么选 SD 3.5 而不是 SDXL 或 SD 1.5SD 3.5 和之前几代模型最大的不同在于它内部采用了三套独立的文本编码器把 T5、CLIP-L 和 CLIP-G 的输出融合后再引导图像生成。这个设计在提示词理解上带来的提升非常明显——写复杂场景、指定多个物体、描述光影关系时SD 3.5 对文字的遵从度远高于 SDXL尤其是长句和带有否定语义的提示词SDXL 经常会漏掉细节而 SD 3.5 大部分时候都能正确给到画面里。代价是模型体积变大推理时文本编码部分的计算量也明显增加。DGX Spark 的显存足够大跑 SD 3.5 完全不用像普通 8GB 显卡那样反复做模型卸载和重载整个管线可以直接驻留在显存里。我在实际测试中图生图连续批量出图时单张速度虽然比小显存设备只快一个量级但批与批之间几乎没有停顿瓶颈基本都落在采样迭代上而不是显存换入换出上这一点是这台设备最值得利用的地方。1.2 显存、带宽和工作负载之间的平衡很多人以为只要显存够大就能无脑拉高分辨率其实不完全是。图像生成的计算量主要由像素数量、采样步数和模型宽度决定显存决定的是你能不能一次性把模型参数和中间特征全部放下而内存带宽决定了每一步迭代读取权重和写入特征的速度。DGX Spark 的显存带宽明显高于普通显卡所以采样迭代的核心循环跑起来要快得多。但这台设备也有一个特性需要注意它的加速单元对 FP8 和低精度计算支持得非常充分但对 FP16 的支持反而不是默认最优路径。这意味着你在配置 ComfyUI 时应当优先考虑把模型加载成 FP8 格式这既省显存又不会明显损失画质。不要在还没测试的情况下直接套用普通工作站的 FP16 配置那样等于主动放弃了这台设备的性能优势。1.3 ComfyUI 为什么比 A1111 更适合这种设备我自己在普通显卡上用 A1111 用了很久但在 DGX Spark 上我强烈建议用 ComfyUI。原因有两个层面一是工作流的显存管理ComfyUI 的节点式执行引擎可以把不需要的中间结果及时释放掉同样一个生成任务ComfyUI 的峰值显存占用往往比 A1111 低不少这在大分辨率出图时非常关键二是可复现性ComfyUI 的整个工作流是可以导出成 JSON 文件的你把工作流文件和模型放一起下次打开直接拖拽进去就能恢复一模一样的管线这对需要反复调整参数、做实验的人来说太重要了。2. 环境准备把系统、驱动和基础依赖一次弄对2.1 确认系统版本和内核状态拿到 DGX Spark 后第一步不是急着装东西而是先确认系统版本。设备出厂自带的系统通常已经预装了驱动和基础库但你不知道具体版本号直接装新依赖很容易把系统的驱动包弄坏。我建议先跑一段检查命令把所有关键信息记录下来cat /etc/os-release uname -r nvidia-smi nvcc --version python3 --version这三个输出分别告诉你系统版本、内核版本、驱动和加速栈版本。下一步不管是装 PyTorch 还是跑 ComfyUI都需要根据这里的 CUDA 版本去选择对应的预编译包。如果系统里没有 nvidia-smi先别急着装驱动先确认是不是出厂镜像太老联系设备供应商确认后再处理。提示一定不要直接在系统自带 Python 环境里装包。DGX Spark 的系统 Python 可能被系统组件依赖一旦你覆盖了某些基础库的版本轻则 ComfyUI 启动报错重则整个桌面环境出问题。建议从第一步就使用虚拟环境。2.2 创建独立的 Python 环境我强烈建议用 conda 或 venv 建一个独立环境。DGX Spark 属于 ARM 架构部分预编译 wheel 包可能没有对应的 ARM 版本使用 conda 的好处是它可以帮你处理部分依赖兼容问题尤其在 ARM Linux 上 conda 的包管理比 pip 更完整。conda create -n sd35 python3.10 conda activate sd35选 Python 3.10 不是随便定的。我实测下来ComfyUI 官方代码在 3.10 和 3.11 上都能跑但 3.10 的第三方兼容库最全尤其是涉及自定义节点和模型格式转换的工具时3.10 几乎没有踩到过依赖缺失的问题。如果以后要装一些老的自定义节点3.10 的优势会更明显。2.3 PyTorch 版本选择逻辑PyTorch 的安装是整个环境准备里最容易踩坑的一步。因为 DGX Spark 的加速栈和标准 CUDA 有差异直接 pip install torch 装出来的默认版本几乎肯定跑不出加速效果甚至可能直接用不了。这里的正确逻辑是先看 nvidia-smi 显示的驱动版本再到 PyTorch 官网的安装命令生成器里选择对应的 CUDA 版本。以我测试时的环境为例驱动支持的 CUDA 版本是 12.x所以安装命令大致是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完以后必须验证 GPU 是否真的可用这一步千万不能跳过import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果 torch.cuda.is_available() 返回 False说明 PyTorch 编译时没有找到对应的加速支持这时候不要试着重装系统先把 torch 卸掉然后去 PyTorch 官网找与你驱动版本完全匹配的 wheel 包。我在排查过程中发现很多报错都源于 PyTorch 版本与驱动 CUDA 版本不完全匹配用官方 index-url 安装时一定要严格对应版本号不能用 latest。3. 下载和准备 SD 3.5 模型文件3.1 模型文件结构说明SD 3.5 的发布包和 SDXL 结构完全不同。它发布的不是一个单独的 ckpt 文件而是一组分工明确的分文件部署的时候必须全部拿到。核心包含主模型文件通常是 .safetensors 格式负责生成图像的骨干网络三个文本编码器文件——T5 系列编码器文件、CLIP-L 文件、CLIP-G 文件还有一个文本编码器配置文件和主模型配置文件。第一次接触这个结构的人很容易犯一个错误只下载了主模型就开始跑结果加载时报错说找不到 text encoder。三个文本编码器一个都不能少它们的文件名通常非常相似下载时注意看清前缀和大小T5 那个文件会明显比其他两个大很多。3.2 模型存放目录规范ComfyUI 对模型目录有固定要求。进入 ComfyUI 根目录后找到 models 文件夹把主模型放进 models/checkpoints文本编码器分别放进 models/text_encoders 或 models/clip。如果你看到一个模型有多个子文件比如 split_files 结构要按 ComfyUI 的说明放到对应的子目录里不能全部堆在一个文件夹否则前端加载时根本识别不到。我自己习惯把 SD 3.5 相关的所有文件单独放到一个文件夹里管理比如models/ checkpoints/sd3.5/ text_encoders/sd3.5/这样后续升级模型版本或者做 A/B 测试的时候直接换目录名就行不会污染其他模型的目录结构。3.3 校验文件完整性模型文件动辄几十 GB下载过程中断或者从网盘转存产生损坏是常有的事。我遇到过最恶心的情况是模型下载到 99% 断掉重新续传后文件本身不完整ComfyUI 加载时报错只说模型结构不匹配完全没提示文件损坏。建议下载完成后对比发布方提供的 SHA256 校验值Linux 下一条命令就能完成sha256sum ./model_file.safetensors对比输出结果和官方校验值是否一致不一致就重新下载。这一步看起来繁琐但能帮你把后面排查问题的时间省掉一大半。4. ComfyUI 本身的部署和启动4.1 获取代码与安装依赖ComfyUI 的代码直接拉官方仓库就可以。git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI pip install -r requirements.txt拉到本地后先看目录下是否有 requirements.txt 和 pyproject.toml不同时期仓库结构会有变化。如果你是更早之前装过然后重新拉代码更新注意先执行 pip install -r requirements.txt 更新依赖避免旧依赖版本和新代码不适配。4.2 启动参数优化ComfyUI 默认启动参数是针对普通显卡配置的在 DGX Spark 上必须调整。我的建议启动命令是python main.py --listen 0.0.0.0 --port 8188 --use-pytorch-cross-attention--listen 0.0.0.0 是为了局域网访问如果你只在机器本机操作可以去掉--use-pytorch-cross-attention 这个参数很关键它让交叉注意力计算走 PyTorch 的原生实现在部分设备上比 ComfyUI 自带优化版本更稳定。如果你发现生成图像时显存占用异常高还可以加 --reserve-memory 参数但建议先用默认值跑通再根据监控数据决定要不要调整。启动成功的标志是终端出现 To see the GUI go to http://... 的提示然后浏览器访问 http://localhost:8188 就能看到工作流界面。如果启动就报错大概率是依赖冲突回头检查第 2.3 步的 PyTorch 安装。4.3 确认 GPU 加速已生效很多人在这一步容易遗漏ComfyUI 虽然能启动但实际可能并没有走加速。在生成第一张图之前先留意终端日志里有没有类似 Using device: cuda 的输出如果显示的是 cpu说明 PyTorch 没有正确识别加速设备这时候回到第 2.3 步重新检查安装版本。5. 从零搭建一个 SD 3.5 基础文生图工作流5.1 关键节点的配置逻辑ComfyUI 界面打开后默认可能是空白画布也可能自带一个简单工作流。我的建议是从空白画布开始手动搭建一个最基础的文生图管线这样你能清楚掌握每个节点的作用。三个最底层的节点是必不可少的CheckpointLoaderSimple负责加载主模型CLIPTextEncode负责把提示词编码成模型可用的条件向量EmptyLatentImage生成一个初始潜空间图像。然后接上 KSampler负责执行采样迭代最后通过 VAEDecode 解码成像素图像用 SaveImage 保存。SD 3.5 有一个特殊之处你可以选择用三个文本编码器还是两个。完整使用三个编码器时CLIPTextEncode 节点需要同时接收三个编码器的输出这个工作流在 ComfyUI 里配置起来稍微复杂但效果最好。如果你只想快速出图用两个编码器的模式也能跑只是提示词理解能力会下降。我建议优先用完整三编码器工作流这才是 SD 3.5 的真实实力。5.2 KSampler 核心参数怎么定KSampler 里的参数直接决定出图质量和速度我给出一个经过实测的基础配置新手按这个参数跑不容易翻车参数推荐值说明seed-1随机每次生成不同结果固定后用于复现steps28SD 3.5 的默认推荐步数不要低于 20cfg4.5SD 3.5 对 cfg 敏感过高画面过饱和sampler_nameeuler稳定且速度均衡schedulernormal与 euler 搭配效果最佳denoise1.0文生图保持默认图生图时降低这几个参数里最容易搞错的是 cfg。SD 3.5 的 cfg 最佳区间在 4 到 5 之间比 SDXL 的 6 到 7 低不少。我第一次用 SDXL 的习惯直接把 cfg 拉到 7出来的图颜色浓到发黑后来降到 4.5 才正常。原因在于 SD 3.5 的三编码器结构下模型对提示词的响应本来就强过高的 cfg 反而会导致过度补偿。5.3 首次出图可能遇到的加载问题工作流搭好并点击 Queue 后第一次加载模型可能要等一段时间因为需要把几十 GB 的模型读入显存这个过程在机械硬盘上可能要几分钟在 NVMe 固态上会快很多。如果等了很久还是报错最常见的原因是用 SaveImage 节点时输出目录权限不对确保可写路径存在或者模型加载失败回去检查第 3.3 步的文件完整性。6. 性能调优把 DGX Spark 的硬件优势真正吃透6.1 模型加载格式的对比与选择SD 3.5 主模型可以以原生 FP16 格式加载也可以转换成 FP8。FP16 是模型发布时的默认格式而 FP8 是把模型权重压缩成 8 位浮点格式体积直接减半加载速度更快推理时显存占用更低。我从实测角度看FP8 的画质损失在正常肉眼观察下几乎感知不到尤其在输出分辨率不超过 1024 的情况下。如果你的设备显存足够大FP16 的极致画质理论上更稳妥但如果你想同时跑多张图或者提高批量大小FP8 是明显更好的选择。ComfyUI 加载 checkpoint 时通常会在加载器节点里提供精度选项选择 FP8 即可也可以提前用转换脚本处理模型文件。6.2 批量出图与并发任务配置DGX Spark 的多任务能力比普通显卡强很多但前提是配置要跟得上。ComfyUI 支持在同一个工作流里设置 batch_size也就是一次任务生成多张图。这个参数不是越大越好因为批量越大单张图的生成时间差异不大但显存占用会线性增长。我在测试中batch_size 从 1 提到 4单张速度下降约 15%显存占用增加了 2 倍左右。具体最优值取决于你的分辨率设置和模型精度一般从 batch_size 2 开始试逐步往上加直到显存占用接近极限但不爆显存为止。如果你想同时跑多个不同的工作流任务ComfyUI 默认是单任务队列任务会排队执行。可以用 --cuda-device 参数配合多 GPU 配置实现并行但 DGX Spark 的加速单元逻辑和普通多卡有差异不建议新手一上来就搞多任务并行先把单任务跑顺再说。6.3 分辨率与显存的实际关系SD 3.5 原生训练分辨率是 1024x1024出图分辨率在这个附近效果最稳。很多人一开始就拉到 2048结果发现显存爆了或者画面构图失衡。我建议的通用策略是先用 1024 出图再用图生图节点把图像放大到目标分辨率而不是直接生成大图。分阶段放大的好处有两个一是避免了高分辨率下 SD 3.5 常见的物体重复问题二是显存占用被拆分成两段整体峰值更低。在实际测试中1024 直接拉到 2048 的放大效果比直接用 2048 生成的效果要好很多各种边缘畸变和错误纹理都更少。7. 常见问题与排查技巧实录7.1 模型加载报错对照表我在部署过程中记录了几类高频报错整理成表按这个顺藤摸瓜基本能解决报错表现可能原因解决动作KeyError: text_encoders文本编码器文件未下载或目录错误检查三个编码器是否齐全确认目录为 models/text_encodersAssertionError: model_config主模型文件损坏或格式不匹配重新下载并校验 SHA256CUDA out of memory分辨率过高或 batch 太大降低 batch_size 或分辨率切换 FP8AttributeError: NoneType object模型加载精度设置冲突在加载器节点重新选择模型精度RuntimeError: CUDA errorPyTorch 版本与驱动不匹配重新安装匹配的 PyTorch 版本7.2 生成速度忽快忽慢的玄学问题有一次我发现同一参数下出图速度时快时慢查了半天发现是系统在后台跑了其他任务。DGX Spark 的系统资源是共享的如果同时有大量 CPU 任务在跑模型加载和图像解码部分就会变慢但采样迭代阶段受影响较小。如果你发现类似情况用 htop 或 nvidia-smi 查看当前资源占用把后台任务清理掉再试。还有一个很容易忽略的点第一次生成时模型加载时间不算在生成时间内第二次生成会快很多因为模型已经在显存里驻留了。如果你看到的第一次速度远慢于后续不用慌这不是配置问题。7.3 自定义节点兼容性问题SD 3.5 发布后很多早期自定义节点没有及时适配三编码器结构导致工作流加载时节点报红。我的建议是尽量选择明确标注支持 SD3 的节点如果某个节点报错且报错信息指向编码器数量大概率是这个节点不支持三编码器。可以把工作流里对应的节点替换成官方原生节点先把基础跑通再逐步替换成自定义节点。8. 部署完成后的几个进阶思路基础工作流跑通后这里还有几个方向可以继续深入。一是尝试图生图工作流。把 VAEDecode 的输出接到一个图像加载节点上通过 denoise 参数控制重绘程度。denoise 在 0.4 到 0.6 之间时SD 3.5 能保留原图构图并重绘细节这对做草图渲染和风格迁移很有用。二是利用大显存跑高分辨率修复。用 ControlNet 或直接图生图放大把 1024 的图放大到 4K 甚至更高大显存让这个过程不需要频繁换入换出整条管线一气呵成。三是结合 LoRA。SD 3.5 发布后社区已经积累了不少 LoRA 模型ComfyUI 的 LoraLoader 节点可以直接加载。DGX Spark 上跑 LoRA 几乎没有额外性能负担因为 LoRA 注入的参数极小不会显著影响显存和速度。我个人在实际操作中的一个体会是这台设备最舒服的用法不是追求单张图的出图速度而是让它稳定地跑批量任务。模型加载完成后把一批提示词排进队列它可以在较短时间内连续出几十张图整个过程不用人工干预。从这个角度看它更像一台微型生成服务器而不是传统意义上的单卡显卡。如果你有机会长期使用它建议在工作流跑通后把常用的提示词、参数组合、LoRA 配置都整理成模板文件后面真正做项目的时候会省非常多的时间。
阅读完成 · 觉得有帮助？
