企业官网建设流程全解析

手头有一台 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.5

SD 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 python=3.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 里的参数直接决定出图质量和速度，我给出一个经过实测的基础配置，新手按这个参数跑不容易翻车：

这几个参数里最容易搞错的是 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 模型加载报错对照表

我在部署过程中记录了几类高频报错，整理成表，按这个顺藤摸瓜基本能解决：

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 配置都整理成模板文件，后面真正做项目的时候会省非常多的时间。