如果你手边恰好有一台 NVIDIA DGX Spark又想跑 Stable Diffusion 3.5我猜你大概率会选择 ComfyUI 来折腾工作流。这三个词放在一起本身就是一句非常典型的“本地 AI 绘画全家桶”宣言DGX Spark 负责把算力放到你桌上Stable Diffusion 3.5 负责提供模型能力ComfyUI 负责把模型能力变成可复现的图表链路。这篇记录不是官方文档复述而是我从零开始在这台设备上装环境、下模型、搭工作流、出第一张图的全过程复盘。里面包含了我的选型理由、踩过的坑、调参思路以及最后沉淀下来的可复用方案适合有 Linux 基础、想认真玩本地生图的人参考。1. 先认清这台机器的底子DGX Spark 到底能干什么1.1 DGX Spark 是什么层级的产品DGX Spark 不是传统意义上的游戏显卡工作站它的核心是 NVIDIA 定制的 GB10 Grace Blackwell 超级芯片CPU、GPU、内存控制器做到了一颗芯片里。对不熟悉这条产品线的读者可以把它理解成“把 NVIDIA 数据中心里的某些能力压缩到一台桌面主机里”但又和普通 PC 装一块 RTX 显卡完全不同它拥有 128GB 统一内存CPU 与 GPU 共享同一个内存池不需要搬运显存数据。这一点对 Stable Diffusion 3.5 这类大模型极其重要。SD3.5 的 Large 版有 8B 参数外加 T5-XXL 文本编码器整体权重要超过 20GB。常规 24GB 显存高端显卡可以勉强跑低精度但并行处理长文本、大 batch、多模型同时驻留时非常局促。而 DGX Spark 的统一内存池让我不用反复思考“显存够不够”直接以模型推理时的实际驻留需求为上限128GB 在这类场景里属于非常宽裕的配置。1.2 为什么它适合本地部署 SD3.5本地部署 Stable Diffusion 3.5 的常见痛点有三个显存不够、驱动不兼容、模型文件太大。前两个在好一点的 PC 上也能解决但第三个很麻烦调用云端 GPU 会涉及数据上传和排队完全本地化的机器在执行长流程实验时会顺手很多。DGX Spark 的设计目标就是“本地跑大模型”SD3.5 恰恰是目标场景之一。它的计算能力跑 Medium 版2.5B非常轻松跑 Large 版8B也完全可行FP8 精度下模型加载速度和推理速度依然处于可用区间。再加上 ComfyUI 的节点式工作流对硬件访问是动态的模型可以在链路上按需加载和统一内存的特性很匹配。我实际部署下来的感觉是这不是一台“凑合能跑”的机器而是一台“为这类负载专门优化过”的机器。2. 部署前最纠结的三个选型问题动手安装之前有三件事会卡住所有人用什么方式管理 Python 环境、装哪个版本的 ComfyUI、选 SD3.5 的哪一档模型。我按自己试过的路径把这三个问题聊透。2.1 容器派还是裸机派DGX Spark 的 CPU 是 Arm 架构这一点很容易被忽略。普通桌面 Ubuntu 的 Python 环境、PyTorch 轮子、各种科学计算库大多默认按 x86 架构编译。你在 x86 上养成的那套“创建 conda 环境、pip install 就完事”的流程到了 Arm 机器上不一定每次都能拿到预编译包经常绕进源码编译的深坑。所以我强烈推荐容器方案直接使用 NVIDIA 官方发布的 PyTorch NGC 容器镜像。这个镜像内置了匹配 Blackwell 架构的 PyTorch、CUDA 运行库以及部分常用 Python 包是 NVIDIA 针对 DGX 系列机器做好的“标准环境”。在容器里装 ComfyUI 等于站在官方肩膀上省掉了一堆 Arm 架构上的兼容性调试。提示宿主机只需要装好 NVIDIA 驱动和容器运行时即可。不要试图在裸机上复刻整个深度学习环境除非你有充足的时间玩编译排查。2.2 从源码装 ComfyUI 还是用桌面版ComfyUI 官方现在提供了桌面版安装包双击就能跑界面也比以前友好很多。但我个人在 DGX Spark 这种特殊硬件上更推荐用源码方式部署原因有三桌面版的依赖是全套打包的万一某个组件和 Blackwell 驱动不匹配你很难单独替换源码方式可以直接挂在 NGC 容器里利用官方维护的 PyTorch 构建版本兼容性最有保障后续你要做二次开发、接入自定义节点、调整启动参数源码目录更顺手。源码部署听起来麻烦其实就三步git clone 仓库、安装 requirements、启动 main.py。配合 NGC 容器里的 Python 环境整个过程十分钟以内就能完成。2.3 模型版本怎么选SD3.5 官方提供了多个版本我建议按使用目标来选而不是盲目追大Medium 版2.5B 参数文件体积小加载快适合日常工作流、快速调参和批量测试画质在普通分辨率场景下完全够用。Large 版8B 参数细节表现力更强适合做大图、复杂构图和后期精修。在 DGX Spark 上跑起来毫无压力所以我最终以 Large 版为主。Turb 蒸馏版部分版本经过加速蒸馏能用更少的采样步数产出结果适合求速度的草稿阶段但精细控制不如完整版。文本编码器方面SD3.5 依赖三个编码器共同作用包括两个 CLIP 模型和 T5-XXL。完整版的大型模型权重加上文本编码器下载体积接近几十 GB。如果你只是体验可以从 Medium 版开始等熟悉了再换 Large。3. 实操记录从 NGC 容器到 ComfyUI 启动3.1 拉取 NGC PyTorch 容器并进入工作区我在 DGX Spark 上部署的第一步是启动一个交互式容器。命令大致是这样的docker run -it --rm \ --name comfyui-dgx \ --runtime nvidia \ --network host \ -v $HOME/ComfyUI:/workspace/ComfyUI \ -v $HOME/models:/workspace/models \ nvcr.io/nvidia/pytorch:25.02 \ bash说明一下参数含义--runtime nvidia让容器访问 NVIDIA GPU 资源--network host直接用宿主机网络避免端口映射带来的意外麻烦两个-v把 ComfyUI 源码目录和模型目录挂载进容器保证后续你在容器里下载的模型、生成的图片都能在宿主机直接看到。实际上你不需要预先建好$HOME/ComfyUI目录挂载路径不存在时 Docker 会自动创建。进入容器后跑一下nvidia-smi能看到 GPU 和统一内存信息就说明环境正常。注意如果拉取镜像非常慢请先从容器加速角度排查网络和镜像源配置这不是代码层面的问题。3.2 安装 ComfyUI 本体容器起来之后我在工作目录里拉取 ComfyUI 源码cd /workspace git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUIComfyUI 的requirements.txt里包含torch、torchvision、numpy、opencv-python等常规依赖。因为这些包在 NGC PyTorch 容器里大多已经装好我不需要重新 full install只需要补装项目额外需要的部分pip install -r requirements.txt如果你用的是我上面的容器这一步会很快因为 torch 已经就位。真正坑人的是那些没有预装的小依赖比如safetensors、einops、transformers不过这些在 PyPI 上都有 Arm 的 wheel直接 pip 就能装不需要编译。3.3 首次启动 ComfyUI 并确认能访问页面启动命令没有特殊技巧关键是加--listen参数否则默认只监听本地回环地址你从同一台机器的浏览器里能访问但从局域网其他设备访问会不通python main.py --listen 0.0.0.0 --port 8188初次启动时ComfyUI 会在models目录下自动生成checkpoints、text_encoders、diffusion_models、vae等子目录。看到日志里出现类似To see the GUI go to: http://0.0.0.0:8188的信息就说明服务已经起来了。此时在浏览器打开http://机器IP:8188应该能看到 ComfyUI 的空画布界面。这时候界面里没有任何模型可选是正常的下一步要把 SD3.5 的权重放进对应目录。4. 模型权重的下载与摆放别在这一步翻车4.1 SD3.5 权重文件到底有哪些SD3.5 和早期 Stable Diffusion 最明显的区别是“模型拆得更细”。传统 SD1.5 只有一个unet加一个vaeSD3.5 则把核心生成模型、文本编码器、VAE 拆开提供完整版 Large 的文件列表大致是这样的主模型sd3.5_large.safetensors或 FP8 版本负责图像生成的主要计算T5-XXL 文本编码器负责把长文本提示词理解成模型能用的向量CLIP-L 和 CLIP-G 文本编码器两个互补的短文本编码器VAE负责把潜空间图像解码成像素图SD3.5 的 VAE 通常是独立的如果你下载的是官方“合并版 checkpoint”那主模型和文本编码器会打包在一个文件里放checkpoints目录即可。如果你下载的是“一拆三版”则要分别放在diffusion_models和text_encoders目录。4.2 新手推荐用合并版进阶再玩拆分版对于第一次在 DGX Spark 上部署的用户我最推荐下载官方发布的 FP8 合并版 checkpoint。FP8 精度在 8B 模型上能把权重体积压到大约 8GB 左右对 DGX Spark 来说不是负担同时生成画质和 FP16 的差距在肉眼层面并不明显。合并版的好处是 ComfyUI 的Load Checkpoint节点会一次性把 MODEL、CLIP、VAE 三种输出都给你工作流连线最简单。拆分版的好处是你可以自由混合不同版本的文本编码器或者只替换生成模型适合对构图原理有深入研究需求的人。两者不冲突先跑通合并版再去折腾拆分版即可。4.3 目录结构和文件命名建议ComfyUI 只按目录识别模型类型不校验文件名。但良好的命名习惯能避免你后期看图钓鱼。下面是我常用的一套摆放方式models/ ├── checkpoints/ │ └── sd3.5_large_fp8.safetensors ├── diffusion_models/ │ ├── sd3.5_large.safetensors │ └── sd3.5_large_turbo.safetensors ├── text_encoders/ │ ├── t5xxl_fp8.safetensors │ ├── clip_l.safetensors │ └── clip_g.safetensors └── vae/ └── sd3.5_vae.safetensors下载方式就一句话从 Hugging Face 或 ModelScope 的官方仓库把上述文件下载到宿主机对应目录。因为模型文件很大命令行里建议用wget或对应命令行工具直接拉到目标位置不要用浏览器下到一半断掉再重传。提示下载完成后记得检查文件大小是否和仓库标注一致。SD3.5 的大文件经常有人传了一晚上最后发现是完整性校验失败放在 ComfyUI 里加载报错。5. 手搭 ComfyUI 工作流跑通第一张 SD3.5 图5.1 从空白画布开始搭文生图链路ComfyUI 打开后是一张空白画布需要自己往画布上加节点。文生图的基础链路由这几个节点组成Load Checkpoint加载你已经放好的sd3.5_large_fp8.safetensors输出 MODEL、CLIP、VAE 三个接口CLIP Text Encode (Prompt)需要两个一个写正面提示词一个写负面提示词输入都接 Load Checkpoint 的 CLIP 输出Empty Latent Image设置出图画布尺寸推荐 1024 宽 1024 高KSampler采样核心节点接收 MODEL、正面条件、负面条件、潜空间图像VAE Decode把采样结果从潜空间解码成像素图Save Image保存到output目录连线的逻辑可以这样理解Load Checkpoint提供了计算资源和文本理解能力正面提示词负责告诉模型“我要什么”负面提示词负责告诉模型“我不要什么”Empty Latent Image定义了一张空白画布KSampler在这个画布上一遍遍迭代绘制最后VAE Decode把“压缩抽象过程”翻译成一张真实图片。我第一次搭建时容易搞混的是 KSampler 的输入它需要同时接 MODEL、CONDITIONING 和 LATENT。注意 CLIP 的输出不是文字本身而是经过编码器处理后的条件向量必须连接到 KSampler 的positive和negative端口。5.2 关键参数怎么填看得出你入门没有在 KSampler 节点里有五个参数决定生成效果seed、steps、cfg、sampler_name、scheduler。steps采样步数。SD3.5 的完整版我习惯用 28 到 30 步。对新手来说低于 20 步容易出细节不完整的图过高比如 50 步边际收益很低只是浪费时间。cfg提示词引导强度。SD3.5 和旧版模型很不一样不要按 SD1.5 的习惯设成 7 或 8。它默认在引导机制上做了调整建议从 1.0 起步最高不要超过 3.0。过高的 cfg 会让色彩发灰、光影生硬。sampler_name推荐dpmpp_2m这是一个在稳定性和细节表现之间非常均衡的采样器。scheduler强烈推荐sgm_uniform。SD3.5 官方在 ComfyUI 里搭配这个调度器表现最稳很多新手图崩其实是 scheduler 选错。seed随机数种子。想要复现同一张图就锁定 seed想要探索不同构图就让它随机变化。下面是一套可以照抄的参数开场值steps: 28 cfg: 1.0 sampler_name: dpmpp_2m scheduler: sgm_uniform denoise: 1.0正面提示词可以先用一段简单描述比如“a wooden table with a cup of coffee, soft morning light”。负面提示词在 SD3.5 里其实可以写得很短因为它有内置的扰动注意力引导机制过度依赖负面提示词反而会限制构图。我一般只填“low quality, blurry”这类基础项。5.3 进阶玩法Turbo 蒸馏版和自定义链路的扩展方向如果你对出图速度有要求强烈建议下载 SD3.5 Large Turbo 版。它属于蒸馏模型可以把采样步数压到 4 到 8 步单张图的迭代时间大幅缩短。Turbo 版在 ComfyUI 里的用法几乎一样只需要把 KSampler 的steps改成 4cfg保持 1.0scheduler仍然选sgm_uniform。跑通基础文生图之后你还可以继续往画布上加节点比如加入ControlNet做姿态控制、加入LoRA加载器做风格微调、接入IPAdapter参考其他图片的构图。DGX Spark 的算力完全撑得住这些高级节点的串联尤其是多个模型同时驻留时统一内存的优势特别明显。我不建议一开始就堆一堆自定义节点先把基础链路跑顺再逐步叠加“理解链路”才是正确的进阶节奏。6. 高频报错与性能排查把我的排雷清单给你6.1 统一内存到底代表什么不是让你无限加载模型DGX Spark 虽然有 128GB 统一内存但它本质上是一个大内存池GPU 计算仍需要合适的内存布局和算力匹配。不要误以为“内存大就能让所有模型同时驻留不卡顿”。当你同时加载一个 8B 主模型、T5 编码器、ControlNet、多个 LoRA 时请求的数据传输路径还是会变长。我在实际使用中遇到的第一个怪现象是加载多个自定义模型后生成速度反而明显下降因为内存带宽消耗接近饱和。解决方案很简单在 ComfyUI 界面里不用的模型及时卸载或者把Empty Latent Image的 batch size 保持在 1。不要并发提交大量任务让它老老实实一次跑一张。6.2 加载模型报错 CUDA OOM 的隐藏原因按说 128GB 统一内存不太容易 OOM但你在容器里跑时PyTorch 的显存分配策略可能对统一内存机器的处理不够激进。我在部署中撞到过一次CUDA out of memory当时加载的是 Large 版模型加 T5 全精度编码器排除了模型体积问题之后发现是内存碎片导致的。解决思路有两个一是在启动 ComfyUI 前设置环境变量让 PyTorch 对分块显存更友好export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True二是改用 FP8 版本的 T5 编码器。全精度 T5 在统一内存机器上会占掉非常多空间FP8 版则能把文本编码部分的占用降一个量级画质损失几乎看不出来。这两条都建议一起做。6.3 出图速度变慢先检查随机数生成和后台任务我的一个真实体会是SD3.5 的速度瓶颈很多时候不是 GPU 计算本身而是整个系统同时在做太多事。DGX Spark 桌面主机的定位很容易让人忽略散热和电源策略长时间满载运行时核心温度升高可能会让设备降频。排查速度变慢时先看一眼nvidia-smi的功耗和温度再考虑是不是模型版本的问题。另一个影响速度的因素是随机数种子和提示词长度。T5-XXL 在长文本场景下的计算量很大如果你把整篇文案塞进提示词采样速度会明显变慢。合理控制提示词长度让 T5 发挥它擅长的高层语义理解即可不要把它当成“无限长度输入口”。6.4 常见问题速查表现象可能原因解决动作浏览器打开 8188 端口无响应ComfyUI 没加--listen启动时加--listen 0.0.0.0模型加载报错提示文件损坏下载不完整核对模型文件大小和仓库标注是否一致出图分辨率要求超出预期cfg 过高或 scheduler 错误cfg 降至 1.0scheduler 改为sgm_uniform多条 prompt 出图均偏灰暗负面提示词过重精简负面提示词优先靠模型内置引导CUDA OOM多个大模型同时驻留设置PYTORCH_CUDA_ALLOC_CONFedge只保留当前工作流用到的模型生成过程中断且日志无明确报错内存碎片、温度降频重启容器观察功耗温度降低 batch size渲染很快但图片有点糊步数不足完整版调到 28 步以上Turbo 版保持 4 步即可另外初始 seed 随机变化也会让人误以为参数变了导致结果抖动。对比测试前记得在 KSampler 里手动固定 seed将变量控制在单一维度否则永远没法判断是提示词问题还是随机性影响。7. 最后再分享两个部署心得如果让我重新部署一次我最想跳过的是在裸机上折腾 Python 虚拟环境那段。DGX Spark 的 Arm 架构决定了它最适合容器化部署而 NGC PyTorch 容器就是磨好的刀。后来我每次手动跑 ComfyUI都会沿用同样的容器命令只是换不同的挂载目录非常省心。还有一个小心得是模型下载阶段一定要留有足够的时间余量。SD3.5 的 Large 版加文本编码器不是一个小文件很多部署失败案例都发生在下载中断和重复下载上。最稳妥的做法是先下载到宿主机一个单独的临时目录确认完整性后再复制或软链接到 ComfyUI 的models目录能省掉你后面排查模型加载错误的大量时间。
如果你手边恰好有一台 NVIDIA DGX Spark又想跑 Stable Diffusion 3.5我猜你大概率会选择 ComfyUI 来折腾工作流。这三个词放在一起本身就是一句非常典型的“本地 AI 绘画全家桶”宣言DGX Spark 负责把算力放到你桌上Stable Diffusion 3.5 负责提供模型能力ComfyUI 负责把模型能力变成可复现的图表链路。这篇记录不是官方文档复述而是我从零开始在这台设备上装环境、下模型、搭工作流、出第一张图的全过程复盘。里面包含了我的选型理由、踩过的坑、调参思路以及最后沉淀下来的可复用方案适合有 Linux 基础、想认真玩本地生图的人参考。1. 先认清这台机器的底子DGX Spark 到底能干什么1.1 DGX Spark 是什么层级的产品DGX Spark 不是传统意义上的游戏显卡工作站它的核心是 NVIDIA 定制的 GB10 Grace Blackwell 超级芯片CPU、GPU、内存控制器做到了一颗芯片里。对不熟悉这条产品线的读者可以把它理解成“把 NVIDIA 数据中心里的某些能力压缩到一台桌面主机里”但又和普通 PC 装一块 RTX 显卡完全不同它拥有 128GB 统一内存CPU 与 GPU 共享同一个内存池不需要搬运显存数据。这一点对 Stable Diffusion 3.5 这类大模型极其重要。SD3.5 的 Large 版有 8B 参数外加 T5-XXL 文本编码器整体权重要超过 20GB。常规 24GB 显存高端显卡可以勉强跑低精度但并行处理长文本、大 batch、多模型同时驻留时非常局促。而 DGX Spark 的统一内存池让我不用反复思考“显存够不够”直接以模型推理时的实际驻留需求为上限128GB 在这类场景里属于非常宽裕的配置。1.2 为什么它适合本地部署 SD3.5本地部署 Stable Diffusion 3.5 的常见痛点有三个显存不够、驱动不兼容、模型文件太大。前两个在好一点的 PC 上也能解决但第三个很麻烦调用云端 GPU 会涉及数据上传和排队完全本地化的机器在执行长流程实验时会顺手很多。DGX Spark 的设计目标就是“本地跑大模型”SD3.5 恰恰是目标场景之一。它的计算能力跑 Medium 版2.5B非常轻松跑 Large 版8B也完全可行FP8 精度下模型加载速度和推理速度依然处于可用区间。再加上 ComfyUI 的节点式工作流对硬件访问是动态的模型可以在链路上按需加载和统一内存的特性很匹配。我实际部署下来的感觉是这不是一台“凑合能跑”的机器而是一台“为这类负载专门优化过”的机器。2. 部署前最纠结的三个选型问题动手安装之前有三件事会卡住所有人用什么方式管理 Python 环境、装哪个版本的 ComfyUI、选 SD3.5 的哪一档模型。我按自己试过的路径把这三个问题聊透。2.1 容器派还是裸机派DGX Spark 的 CPU 是 Arm 架构这一点很容易被忽略。普通桌面 Ubuntu 的 Python 环境、PyTorch 轮子、各种科学计算库大多默认按 x86 架构编译。你在 x86 上养成的那套“创建 conda 环境、pip install 就完事”的流程到了 Arm 机器上不一定每次都能拿到预编译包经常绕进源码编译的深坑。所以我强烈推荐容器方案直接使用 NVIDIA 官方发布的 PyTorch NGC 容器镜像。这个镜像内置了匹配 Blackwell 架构的 PyTorch、CUDA 运行库以及部分常用 Python 包是 NVIDIA 针对 DGX 系列机器做好的“标准环境”。在容器里装 ComfyUI 等于站在官方肩膀上省掉了一堆 Arm 架构上的兼容性调试。提示宿主机只需要装好 NVIDIA 驱动和容器运行时即可。不要试图在裸机上复刻整个深度学习环境除非你有充足的时间玩编译排查。2.2 从源码装 ComfyUI 还是用桌面版ComfyUI 官方现在提供了桌面版安装包双击就能跑界面也比以前友好很多。但我个人在 DGX Spark 这种特殊硬件上更推荐用源码方式部署原因有三桌面版的依赖是全套打包的万一某个组件和 Blackwell 驱动不匹配你很难单独替换源码方式可以直接挂在 NGC 容器里利用官方维护的 PyTorch 构建版本兼容性最有保障后续你要做二次开发、接入自定义节点、调整启动参数源码目录更顺手。源码部署听起来麻烦其实就三步git clone 仓库、安装 requirements、启动 main.py。配合 NGC 容器里的 Python 环境整个过程十分钟以内就能完成。2.3 模型版本怎么选SD3.5 官方提供了多个版本我建议按使用目标来选而不是盲目追大Medium 版2.5B 参数文件体积小加载快适合日常工作流、快速调参和批量测试画质在普通分辨率场景下完全够用。Large 版8B 参数细节表现力更强适合做大图、复杂构图和后期精修。在 DGX Spark 上跑起来毫无压力所以我最终以 Large 版为主。Turb 蒸馏版部分版本经过加速蒸馏能用更少的采样步数产出结果适合求速度的草稿阶段但精细控制不如完整版。文本编码器方面SD3.5 依赖三个编码器共同作用包括两个 CLIP 模型和 T5-XXL。完整版的大型模型权重加上文本编码器下载体积接近几十 GB。如果你只是体验可以从 Medium 版开始等熟悉了再换 Large。3. 实操记录从 NGC 容器到 ComfyUI 启动3.1 拉取 NGC PyTorch 容器并进入工作区我在 DGX Spark 上部署的第一步是启动一个交互式容器。命令大致是这样的docker run -it --rm \ --name comfyui-dgx \ --runtime nvidia \ --network host \ -v $HOME/ComfyUI:/workspace/ComfyUI \ -v $HOME/models:/workspace/models \ nvcr.io/nvidia/pytorch:25.02 \ bash说明一下参数含义--runtime nvidia让容器访问 NVIDIA GPU 资源--network host直接用宿主机网络避免端口映射带来的意外麻烦两个-v把 ComfyUI 源码目录和模型目录挂载进容器保证后续你在容器里下载的模型、生成的图片都能在宿主机直接看到。实际上你不需要预先建好$HOME/ComfyUI目录挂载路径不存在时 Docker 会自动创建。进入容器后跑一下nvidia-smi能看到 GPU 和统一内存信息就说明环境正常。注意如果拉取镜像非常慢请先从容器加速角度排查网络和镜像源配置这不是代码层面的问题。3.2 安装 ComfyUI 本体容器起来之后我在工作目录里拉取 ComfyUI 源码cd /workspace git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUIComfyUI 的requirements.txt里包含torch、torchvision、numpy、opencv-python等常规依赖。因为这些包在 NGC PyTorch 容器里大多已经装好我不需要重新 full install只需要补装项目额外需要的部分pip install -r requirements.txt如果你用的是我上面的容器这一步会很快因为 torch 已经就位。真正坑人的是那些没有预装的小依赖比如safetensors、einops、transformers不过这些在 PyPI 上都有 Arm 的 wheel直接 pip 就能装不需要编译。3.3 首次启动 ComfyUI 并确认能访问页面启动命令没有特殊技巧关键是加--listen参数否则默认只监听本地回环地址你从同一台机器的浏览器里能访问但从局域网其他设备访问会不通python main.py --listen 0.0.0.0 --port 8188初次启动时ComfyUI 会在models目录下自动生成checkpoints、text_encoders、diffusion_models、vae等子目录。看到日志里出现类似To see the GUI go to: http://0.0.0.0:8188的信息就说明服务已经起来了。此时在浏览器打开http://机器IP:8188应该能看到 ComfyUI 的空画布界面。这时候界面里没有任何模型可选是正常的下一步要把 SD3.5 的权重放进对应目录。4. 模型权重的下载与摆放别在这一步翻车4.1 SD3.5 权重文件到底有哪些SD3.5 和早期 Stable Diffusion 最明显的区别是“模型拆得更细”。传统 SD1.5 只有一个unet加一个vaeSD3.5 则把核心生成模型、文本编码器、VAE 拆开提供完整版 Large 的文件列表大致是这样的主模型sd3.5_large.safetensors或 FP8 版本负责图像生成的主要计算T5-XXL 文本编码器负责把长文本提示词理解成模型能用的向量CLIP-L 和 CLIP-G 文本编码器两个互补的短文本编码器VAE负责把潜空间图像解码成像素图SD3.5 的 VAE 通常是独立的如果你下载的是官方“合并版 checkpoint”那主模型和文本编码器会打包在一个文件里放checkpoints目录即可。如果你下载的是“一拆三版”则要分别放在diffusion_models和text_encoders目录。4.2 新手推荐用合并版进阶再玩拆分版对于第一次在 DGX Spark 上部署的用户我最推荐下载官方发布的 FP8 合并版 checkpoint。FP8 精度在 8B 模型上能把权重体积压到大约 8GB 左右对 DGX Spark 来说不是负担同时生成画质和 FP16 的差距在肉眼层面并不明显。合并版的好处是 ComfyUI 的Load Checkpoint节点会一次性把 MODEL、CLIP、VAE 三种输出都给你工作流连线最简单。拆分版的好处是你可以自由混合不同版本的文本编码器或者只替换生成模型适合对构图原理有深入研究需求的人。两者不冲突先跑通合并版再去折腾拆分版即可。4.3 目录结构和文件命名建议ComfyUI 只按目录识别模型类型不校验文件名。但良好的命名习惯能避免你后期看图钓鱼。下面是我常用的一套摆放方式models/ ├── checkpoints/ │ └── sd3.5_large_fp8.safetensors ├── diffusion_models/ │ ├── sd3.5_large.safetensors │ └── sd3.5_large_turbo.safetensors ├── text_encoders/ │ ├── t5xxl_fp8.safetensors │ ├── clip_l.safetensors │ └── clip_g.safetensors └── vae/ └── sd3.5_vae.safetensors下载方式就一句话从 Hugging Face 或 ModelScope 的官方仓库把上述文件下载到宿主机对应目录。因为模型文件很大命令行里建议用wget或对应命令行工具直接拉到目标位置不要用浏览器下到一半断掉再重传。提示下载完成后记得检查文件大小是否和仓库标注一致。SD3.5 的大文件经常有人传了一晚上最后发现是完整性校验失败放在 ComfyUI 里加载报错。5. 手搭 ComfyUI 工作流跑通第一张 SD3.5 图5.1 从空白画布开始搭文生图链路ComfyUI 打开后是一张空白画布需要自己往画布上加节点。文生图的基础链路由这几个节点组成Load Checkpoint加载你已经放好的sd3.5_large_fp8.safetensors输出 MODEL、CLIP、VAE 三个接口CLIP Text Encode (Prompt)需要两个一个写正面提示词一个写负面提示词输入都接 Load Checkpoint 的 CLIP 输出Empty Latent Image设置出图画布尺寸推荐 1024 宽 1024 高KSampler采样核心节点接收 MODEL、正面条件、负面条件、潜空间图像VAE Decode把采样结果从潜空间解码成像素图Save Image保存到output目录连线的逻辑可以这样理解Load Checkpoint提供了计算资源和文本理解能力正面提示词负责告诉模型“我要什么”负面提示词负责告诉模型“我不要什么”Empty Latent Image定义了一张空白画布KSampler在这个画布上一遍遍迭代绘制最后VAE Decode把“压缩抽象过程”翻译成一张真实图片。我第一次搭建时容易搞混的是 KSampler 的输入它需要同时接 MODEL、CONDITIONING 和 LATENT。注意 CLIP 的输出不是文字本身而是经过编码器处理后的条件向量必须连接到 KSampler 的positive和negative端口。5.2 关键参数怎么填看得出你入门没有在 KSampler 节点里有五个参数决定生成效果seed、steps、cfg、sampler_name、scheduler。steps采样步数。SD3.5 的完整版我习惯用 28 到 30 步。对新手来说低于 20 步容易出细节不完整的图过高比如 50 步边际收益很低只是浪费时间。cfg提示词引导强度。SD3.5 和旧版模型很不一样不要按 SD1.5 的习惯设成 7 或 8。它默认在引导机制上做了调整建议从 1.0 起步最高不要超过 3.0。过高的 cfg 会让色彩发灰、光影生硬。sampler_name推荐dpmpp_2m这是一个在稳定性和细节表现之间非常均衡的采样器。scheduler强烈推荐sgm_uniform。SD3.5 官方在 ComfyUI 里搭配这个调度器表现最稳很多新手图崩其实是 scheduler 选错。seed随机数种子。想要复现同一张图就锁定 seed想要探索不同构图就让它随机变化。下面是一套可以照抄的参数开场值steps: 28 cfg: 1.0 sampler_name: dpmpp_2m scheduler: sgm_uniform denoise: 1.0正面提示词可以先用一段简单描述比如“a wooden table with a cup of coffee, soft morning light”。负面提示词在 SD3.5 里其实可以写得很短因为它有内置的扰动注意力引导机制过度依赖负面提示词反而会限制构图。我一般只填“low quality, blurry”这类基础项。5.3 进阶玩法Turbo 蒸馏版和自定义链路的扩展方向如果你对出图速度有要求强烈建议下载 SD3.5 Large Turbo 版。它属于蒸馏模型可以把采样步数压到 4 到 8 步单张图的迭代时间大幅缩短。Turbo 版在 ComfyUI 里的用法几乎一样只需要把 KSampler 的steps改成 4cfg保持 1.0scheduler仍然选sgm_uniform。跑通基础文生图之后你还可以继续往画布上加节点比如加入ControlNet做姿态控制、加入LoRA加载器做风格微调、接入IPAdapter参考其他图片的构图。DGX Spark 的算力完全撑得住这些高级节点的串联尤其是多个模型同时驻留时统一内存的优势特别明显。我不建议一开始就堆一堆自定义节点先把基础链路跑顺再逐步叠加“理解链路”才是正确的进阶节奏。6. 高频报错与性能排查把我的排雷清单给你6.1 统一内存到底代表什么不是让你无限加载模型DGX Spark 虽然有 128GB 统一内存但它本质上是一个大内存池GPU 计算仍需要合适的内存布局和算力匹配。不要误以为“内存大就能让所有模型同时驻留不卡顿”。当你同时加载一个 8B 主模型、T5 编码器、ControlNet、多个 LoRA 时请求的数据传输路径还是会变长。我在实际使用中遇到的第一个怪现象是加载多个自定义模型后生成速度反而明显下降因为内存带宽消耗接近饱和。解决方案很简单在 ComfyUI 界面里不用的模型及时卸载或者把Empty Latent Image的 batch size 保持在 1。不要并发提交大量任务让它老老实实一次跑一张。6.2 加载模型报错 CUDA OOM 的隐藏原因按说 128GB 统一内存不太容易 OOM但你在容器里跑时PyTorch 的显存分配策略可能对统一内存机器的处理不够激进。我在部署中撞到过一次CUDA out of memory当时加载的是 Large 版模型加 T5 全精度编码器排除了模型体积问题之后发现是内存碎片导致的。解决思路有两个一是在启动 ComfyUI 前设置环境变量让 PyTorch 对分块显存更友好export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True二是改用 FP8 版本的 T5 编码器。全精度 T5 在统一内存机器上会占掉非常多空间FP8 版则能把文本编码部分的占用降一个量级画质损失几乎看不出来。这两条都建议一起做。6.3 出图速度变慢先检查随机数生成和后台任务我的一个真实体会是SD3.5 的速度瓶颈很多时候不是 GPU 计算本身而是整个系统同时在做太多事。DGX Spark 桌面主机的定位很容易让人忽略散热和电源策略长时间满载运行时核心温度升高可能会让设备降频。排查速度变慢时先看一眼nvidia-smi的功耗和温度再考虑是不是模型版本的问题。另一个影响速度的因素是随机数种子和提示词长度。T5-XXL 在长文本场景下的计算量很大如果你把整篇文案塞进提示词采样速度会明显变慢。合理控制提示词长度让 T5 发挥它擅长的高层语义理解即可不要把它当成“无限长度输入口”。6.4 常见问题速查表现象可能原因解决动作浏览器打开 8188 端口无响应ComfyUI 没加--listen启动时加--listen 0.0.0.0模型加载报错提示文件损坏下载不完整核对模型文件大小和仓库标注是否一致出图分辨率要求超出预期cfg 过高或 scheduler 错误cfg 降至 1.0scheduler 改为sgm_uniform多条 prompt 出图均偏灰暗负面提示词过重精简负面提示词优先靠模型内置引导CUDA OOM多个大模型同时驻留设置PYTORCH_CUDA_ALLOC_CONFedge只保留当前工作流用到的模型生成过程中断且日志无明确报错内存碎片、温度降频重启容器观察功耗温度降低 batch size渲染很快但图片有点糊步数不足完整版调到 28 步以上Turbo 版保持 4 步即可另外初始 seed 随机变化也会让人误以为参数变了导致结果抖动。对比测试前记得在 KSampler 里手动固定 seed将变量控制在单一维度否则永远没法判断是提示词问题还是随机性影响。7. 最后再分享两个部署心得如果让我重新部署一次我最想跳过的是在裸机上折腾 Python 虚拟环境那段。DGX Spark 的 Arm 架构决定了它最适合容器化部署而 NGC PyTorch 容器就是磨好的刀。后来我每次手动跑 ComfyUI都会沿用同样的容器命令只是换不同的挂载目录非常省心。还有一个小心得是模型下载阶段一定要留有足够的时间余量。SD3.5 的 Large 版加文本编码器不是一个小文件很多部署失败案例都发生在下载中断和重复下载上。最稳妥的做法是先下载到宿主机一个单独的临时目录确认完整性后再复制或软链接到 ComfyUI 的models目录能省掉你后面排查模型加载错误的大量时间。
空间解法)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
