很多人拿到DGX Spark之后第一件事就是装ComfyUI我也不例外。这台设备本身就是为了本地AI推理准备的128GB统一内存加上一块强劲的GPU核心从纸面上看就是为Stable Diffusion工作流量身定制的玩具。但真正动手装ComfyUI的时候我发现自己以前积累的安装经验几乎全部作废了——网上的教程九成都是写给x86_64架构普通PC的照抄的结果是各种报错、白屏、进程卡死。这篇文章就是我完整走过一遍安装过程之后写下来的实操记录从环境体检、PyTorch安装、ComfyUI本体启动到Manager插件、踩坑排查和性能调优全部覆盖。无论你手里已经有一台DGX Spark还是在犹豫要不要入手只要想在Linux ARM64环境下把ComfyUI跑起来这份记录应该能帮你省掉大部分弯路。1. 为什么网上教程在DGX Spark上多数失灵先认清三件事1.1 DGX Spark的本质是ARM64主机不是普通GPU台式机DGX Spark看起来像一台小主机但它和普通PC在底层根本不是一回事。它的CPU核心是基于ARM架构设计的系统跑的是定制Linux发行版GPU则是高度集成的AI推理核心和系统内存共享同一片物理内存。这个架构带来的第一波冲击发生在安装任何软件时pip install、apt install、conda install拿到的默认安装包都是给x86_64架构编译的。如果下载源没有匹配的ARM版本要么安装失败要么Python解释器会尝试直接在本地源码编译。后者才是真正的噩梦——编译一个普通库可能要花几十分钟期间机器看起来像死机一样实际上是在拿全程CPU算力跟源码较劲。我建议在安装一切之前先熟读这条命令uname -m输出aarch64就说明这台机器走的是ARM64生态。后面所有软件选型都要以这个为前提。1.2 统一内存不等于显存无限只是让“能跑”和“跑得稳”分开了DGX Spark把CPU内存和GPU显存做成了统一内存池好处是当你需要加载一个很大的模型时不会被传统显卡那十几GB显存卡死。ComfyUI在跑SDXL、甚至更大的模型时都能用“内存换显存”的思路硬扛下来。但代价是你不能再像以前用N卡那样通过nvidia-smi看一个清晰的独立显存数值。系统内存总量128GB其中真正被GPU驱动划定用于推理的部分会动态波动。这导致一个常见误区任务管理器里明明还有90GB内存ComfyUI却报CUDA Out Of Memory。对初学者来说统一内存带来的最直接体验是第一次启动ComfyUI时它能加载的模型比想象中多但速度比预期慢。因为一旦显存池不够推理就会回到内存兜底整个过程会明显吃力。后续跑工作流时先开小分辨率验证流程再决定要不要开大图是这套硬件上最安全的节奏。1.3 常见的安装教程在架构、系统、驱动三层都默认了“普通PC”具体拆开看网上教程假设的环境和DGX Spark实际环境有三处核心差异架构教程里的Python轮子和二进制包几乎全是x86_64。系统很多教程假设你用Ubuntu桌面版直接apt install某些依赖库。DGX Spark的精简Linux镜像未必有同样包名。驱动层教程里经常让你去官网装驱动的操作在这里完全不需要驱动已经集成在系统里但对应的CUDA版本你就没得选了必须跟着系统走。搞清楚这三件事之后安装策略就变成了给ARM64找对版本的Python包、用系统自带的驱动和CUDA对齐PyTorch版本、尽量少碰系统级依赖。剩下的就是按部就班。2. 环境体检清单装软件之前先花5分钟摸清家底2.1 一步一步确认系统状态我每次在新机器上装环境都会先跑一组检查命令把关键信息记录下来。这组命令在DGX Spark上尤其重要因为到手设备不能默认“它已经是最新的了”。cat /etc/os-release uname -r nvidia-smi nvcc -V df -h / free -h python3 --version逐条解释一下怎么看输出cat /etc/os-release能看到系统版本号和代号后面有些编译依赖的包名要按这个版本去搜。nvidia-smi不只是看GPU占用主要看驱动版本和顶部显示的CUDA Version。DGX Spark通常自带一套完整驱动和CUDA 12.x运行时这决定了PyTorch要选哪个版本。nvcc -V看的是CUDA编译器版本它和nvidia-smi里显示的不一定完全一致不一致也不代表一定出错但PyTorch建议优先对齐nvidia-smi里的CUDA版本。df -h /ComfyUI本体占用不到1GB但模型工作流文件夹轻松吃掉几十GB。留够磁盘空间再开工。free -h统一内存总量确认128GB版本通常会显示约120GB可用心里有个数。2.2 磁盘和内存预留别等模型下载到一半才后悔我身边有不少朋友第一次装ComfyUI时栽在最简单的问题上——磁盘不够。ComfyUI主体仓库几百MB模型文件每个几GB到十几GBControlNet、LoRA、VAE这些扩展文件更是无底洞。按我的习惯会先给ComfyUI单独划一个目录并且确保所在分区至少有100GB空闲。如果系统盘本来就紧张建议直接把ComfyUI目录放到外置NVMe或大容量数据盘上。DGX Spark的外接存储速度完全可以支撑模型加载不会成为性能瓶颈。2.3 Python环境强烈建议用miniforge而不是直接pip装很多人安装Python环境时有个坏习惯直接往系统自带的Python3里pip install。在普通PC上这通常勉强能用但在DGX Spark这种精简系统上这么干会把系统包搅得一团糟。我强烈建议第一步先装一个ARM原生的conda实现用它建一个隔离环境。操作上推荐miniforge因为它在ARM64平台上的支持非常成熟直接在官方仓库拿对应架构的安装脚本即可wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-aarch64.sh bash Miniforge3-Linux-aarch64.sh安装完成之后新建ComfyUI专用环境conda create -n comfyui python3.11 -y conda activate comfyui用Python 3.11而不是3.12是因为整个ComfyUI生态对3.11的兼容性最稳各种自定义节点的依赖包在3.11下基本都有现成的ARM wheel不容易触发源码编译。3. ComfyUI本体安装从git clone到浏览器打开工作台3.1 拉取官方仓库保持更新别用老办法ComfyUI一直在快速迭代安装时不要去下载打包好的压缩包直接用git拉官方仓库。这样后续想更新只需要git pull而且能随时看到这次更新改了什么。cd ~ git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI如果你的网络条件一般clone过程中卡住或者失败可以多试几次。仓库不算大正常情况下几分钟就能拉完。3.2 安装顺序绝对不能错先PyTorch后requirements.txtComfyUI的依赖有一个很典型的先后顺序问题requirements.txt里的部分依赖会检查PyTorch是否已存在并且根据已有的PyTorch版本决定自己安装哪个变体。如果顺序反了会让pip重新解析出一套错误的包组合后期很难排查。所以在ComfyUI目录下先激活conda环境再安装和DGX Spark CUDA版本匹配的PyTorch。我这边实测有效的是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128这里的关键点是cu128要和nvidia-smi里显示的CUDA版本一致。如果你重装系统或驱动版本不同需要在PyTorch官方历史索引中找到合适的标签。装完之后验证一下python -c import torch; print(torch.__version__, torch.cuda.is_available(), torch.version.cuda)看到True且CUDA版本正确后再装其余依赖pip install -r requirements.txt安装过程中如果卡在某个包编译上不要干等。直接手动安装对应的预编译包或者换一个不需要编译的替代包后面第5章会详细说这类坑。3.3 模型文件放对位置否则工作流全红第一次启动ComfyUI之前必须先把模型放到指定目录。ComfyUI的模型目录结构是这样的models/ ├── checkpoints/ 主模型比如SD1.5、SDXL、SD3的safetensors ├── loras/ LoRA微调模型 ├── vae/ VAE模型 ├── controlnet/ ControlNet模型 ├── embeddings/ 文本反转类嵌入模型 ├── upscale_models/ 放大模型至少需要一个checkpoint模型才能出图。把下载好的基础模型放进models/checkpoints/之后界面里就会自动显示。如果放错文件夹ComfyUI不会报错但下拉菜单里找不到模型新手很容易以为是软件坏了。3.4 首次启动和界面验证在ComfyUI目录下执行python main.py --listen 0.0.0.0 --port 8188几个参数的作用--listen 0.0.0.0允许局域网内其他设备访问工作台。如果只是本机使用可以去掉这个参数默认就会监听127.0.0.1。--port 8188默认端口就是8188手动写出来方便改。--preview-method auto如果不想在生成时读到一串黑屏等待可以显式指定一个预览方法后面优化章节再说。启动时日志会先加载前端资源然后检测CUDA设备最后出现一个Starting server提示。用浏览器打开http://127.0.0.1:8188能看到节点编辑界面就说明本体已经跑起来了。4. ComfyUI-Manager与自定义节点装完本体只算完成一半4.1 第一步先装Manager别急着手动clone各种自定义节点裸装的ComfyUI能跑基本工作流但真正舒服地使用还缺一个关键组件节点管理器。它解决的是两个核心痛点——找节点和装依赖。安装Manager的方式是进到custom_nodes目录直接clonecd ~/ComfyUI/custom_nodes git clone https://github.com/ltdrdata/ComfyUI-Manager.gitclone完成之后重启ComfyUI浏览器界面里会多出一个“Manager”按钮。它内置了节点市场搜索、一键安装、依赖检查等功能。很多新手喜欢手动从Git仓库里一个个clone节点结果装完发现缺依赖、报错一堆Manager在一定程度上能自动处理这些问题。4.2 常用节点的选择策略从需求反推名称别贪多不少教程会推一堆节点包照着装完之后界面塞满几百个节点看着很专业但其实大部分用不上。我更建议从具体需求出发去装想做局部重绘、抠图装和Inpaint、Mask相关的节点。想接入ControlNet装对应的辅助节点和预处理器。想要更丰富的采样器、放大算法装增强采样类节点。想管理工作流里的LoRA和提示词装提示词工具类节点。在Manager里搜索并按关键词筛选比一次性批量安装要稳妥得多。每装完一批重启ComfyUI看有没有红色节点有就当场解决不要积攒到后面。4.3 节点依赖报错的通用解法先看requirements再动手不管是手动clone还是Manager安装自定义节点几乎都会在目录下带一个requirements.txt。如果你启动ComfyUI时看到某个节点导入失败第一步不是去博客搜答案而是进入对应目录cd ~/ComfyUI/custom_nodes/节点名字 cat requirements.txt把里面列的包逐一手动安装装不上的单独处理。大多数“ModuleNotFoundError”其实都能靠这个流程解决。要特别注意某些节点会要求特定版本的PyTorch或特定Python版本所以在ComfyUI专用conda环境里安装就等于提前规避掉了一大部分版本冲突。5. 踩坑实录我在DGX Spark上复现过的4个经典问题5.1 问题一pip安装表面成功实则装了错误架构的包这是ARM平台上最隐蔽的坑。某些包在没有aarch64预编译版本时pip会尝试用源码编译整个过程可能持续很久。如果编译失败pip会抛错但有些包能把源码编译成一个“能用但极慢”的版本表面上说Successfully installed实际运行起来CPU占用率拉满GPU出图反而慢得要命。解决思路是安装时加一个平台验证命令确保拿到的是AArch64原生wheelpython -c import sys; print(any(aarch64 in p for p in sys.path))如果怀疑某个包有问题直接看它被装在哪个目录用pip show 包名查版本和Location再下载对应架构的wheel覆盖安装。5.2 问题二依赖包本地编译卡死特别是opencv和bitsandbytesComfyUI里几个常见依赖在ARM64上最容易出状况opencv-python没有现成aarch64 wheel时会尝试完整编译过程非常漫长bitsandbytes在ARM平台上的兼容更是一言难尽很多节点甚至不依赖它。我的处理办法很直接能用替代包的坚决不用原包。OpenCV就用opencv-python-headless替代功能上完全够用bitsandbytes如果确实需要先查看对应节点是否真的必须它不是就必须就注释掉导入语句。给机器设置编译线程上限也是好习惯export MAX_JOBS4这样即便真的需要编译也不会因为线程过多把内存和CPU资源全部吃满。5.3 问题三启动后浏览器打开白屏或者界面加载不出来白屏问题的根因90%是前端资源没有正确加载。ComfyUI启动时会从本地生成前端文件如果上一次启动被中断或者磁盘有权限问题就会留下残缺目录。优先看启动时终端有没有输出类似Web UI js bundle not found的信息。处理方式是把web目录或临时缓存目录删掉重新生成或者干脆重启ComfyUI让它重建前端资源。另一个常见原因是本地端口被占用。用ss -lntp | grep 8188看端口状态如果已有旧进程占着端口直接kill再重启。5.4 问题四节点全部正常工作但出图时一直卡在加载模型表现是点击“排队提示”之后进度条一直停在一半日志里没有任何报错。这通常是模型文件本身损坏或路径不对。推荐做法是先在models/checkpoints/里放一个社区里口碑稳定的标准模型用默认工作流测一次。如果默认工作流能跑说明问题出在模型或自定义节点上。日志文件在启动终端的输出里搜索Error、Cannot、No such file这些关键字通常就能定位到底是哪个文件。6. 性能实测与优化让DGX Spark的出图速度对得起它的定位6.1 先建立基线再谈优化不要一上来就开一堆优化参数。我建议先记一组默认状态下的出图耗时后续每加一个优化项都对照这个基线才能知道哪些手段真正有效。我手上这台机器的基线数据大致如下仅作参考不同固件、驱动版本会有差异分辨率模型默认参数出图耗时参考值512x512SD1.5约6秒768x768SD1.5约11秒1024x1024SDXL约18秒1024x1024SDXL 高分辨率修复约35秒这个速度对本地桌面设备来说已经不错但距离“丝滑”还有优化空间。6.2 推荐优先尝试的加速手段在DGX Spark上我实测有效的优化按照收益排序是这样的开启FP8混合精度推理。--fp8参数能明显减少显存占用对统一内存设备尤其友好生成大图时的卡顿感会少很多。使用更轻量的预览方式。--preview-method latent2rgb比默认auto更快出预览图虽然预览细节差一点但交互流畅度显著提升。考虑--torch-compile。这个参数会做一层图编译首次跑某个工作流时很慢之后会明显提速。但在ARM平台下编译时间可能长达好几分钟建议只在能接受首次等待的情况下使用。不要把xformers和torch.compile同时开两者的优化路径会打架反而拖慢速度。6.3 统一内存下的显存调优别把任务一次性塞满DGX Spark能加载很大模型但负责任地讲把128GB内存全部塞给一个工作流绝不是好主意。当出图报CUDA Out Of Memory时别第一时间把模型删掉或缩小先看看是不是同时加载了太多模型没有释放。推荐做法是及时清理未使用的模型缓存并且尽量让batch size保持为1。如果某个ControlNet和主模型一起占用了太多内存可以拆分成两个工作流串行执行把中间结果保存为图像再继续下一步。这种方法损失一点自动化程度但换来的是稳定性和可预测性。6.4 日常维护建议git pull是双刃剑ComfyUI更新频率比较高但每次git pull之前一定要先看更新说明确认与自己装的Manager和自定义节点是否兼容。我经历过几次升级后节点全面失效的尴尬情况。一个稳妥的做法是更新前备份整个models/目录不用动但要备份两个东西——custom_nodes/下的自定义节点列表以及自己常用工作流的JSON文件。这样就算升级翻车也能快速回滚到可用的状态。整体来看DGX Spark跑ComfyUI的体验在完成安装调优后非常值回票价。这个小主机安静、小巧放在桌面就能独立完成从文生图到图生图再到局部重绘的整套流程比起依赖云服务或大机箱本地部署要省心太多。最后再分享一个小技巧在ARM64平台下安装ComfyUI如果某个依赖包死活装不上不要死磕源码编译。换个思绪去开源软件镜像站或者conda渠道搜一下有没有对应的aarch64预编译版本很多时候花两分钟换一个来源比在源码编译上耗半小时有意义得多。