ComfyUI 工作流从本地搬到云端 GPU：RunPod 部署与模型同步检查清单

本地机器上跑得好好的 ComfyUI 工作流，换了台云端 GPU 却一导入就满屏红框——这大概是迁移时最常见的失败方式。问题往往在于你搬过去的只是那个 .json 文件，而真正让它跑起来的东西还留在本地：一套特定版本的 Python 和 PyTorch、十几个 git clone 来的自定义节点、几十 GB 的模型文件，以及一堆只有在你电脑上才成立的绝对路径。所以与其照着部署教程从头点一遍，不如把迁移拆成“环境、依赖、模型、路径”四类，逐项核对。下文就按这个顺序来，每一项都给出判断标准和典型报错。

先明确：要迁移的其实是四样东西

很多人以为迁移就是“把工作流 JSON 传上去”。实际上一个能跑通的工作流依赖四层，缺任何一层都会表现为“节点变红”或“跑一半报错”：

层	本地有什么	云端缺了会怎样
环境	Python / PyTorch / CUDA 版本组合	ComfyUI 起不来，或节点导入即崩
依赖	自定义节点仓库及其 requirements	节点显示红色 “Missing Node Type”
模型	checkpoints、LoRA、VAE、ControlNet 等	采样器报 “No checkpoint found” 或输出全黑
路径	节点里写死的绝对路径	保存/读取失败，或读到旧文件

把这四层分开核对，出问题时你能立刻定位到是哪一层，而不是在整条链路上瞎试。

准备条件与实例选择

开始之前，先确认三件事：一是你的工作流确实需要更大显存（比如高分辨率出图、视频模型、多模型串联），否则本地能跑就没必要折腾；二是你手上有 Runpod 账号，并且清楚按秒计费的 Pod 一旦开着就在烧钱；三是本地模型目录的总大小，这决定了你同步模型要花多久。

顺带说明一个命名细节：Runpod 官方文档自 2025 年 6 月起统一把产品名写作 “Runpod”，此前的 “RunPod” 写法已弃用。搜索资料时两种写法都会出现，指的都是同一家。

实例选择上，Runpod 提供预装 ComfyUI 的官方 Pod 模板，适合“只想跑通现有工作流”的场景，能省掉装 ComfyUI 和依赖的时间。如果你需要特定版本的 ComfyUI 或自定义启动参数，也可以选一个干净的 PyTorch 模板自己装。还有一条容易被忽略的建议：优先配一个网络卷（Network Volume）挂载到 /workspace。没有持久卷，Pod 一停，你装的节点和下载的模型就全没了，下次还得重来一遍——这是迁移体验里差别最大的一步。

环境层：先确认 ComfyUI 能独立启动

不管用模板还是手动装，第一件事都是验证 ComfyUI 自身能在云端起来。ComfyUI 默认以 HTTP 服务形式监听 http://127.0.0.1:8188，Runpod 的 Pod 页面里把 8188 端口暴露出来，就能在浏览器打开界面。

如果走手动安装，把 ComfyUI 放在持久卷目录下，这样重开 Pod 不用重装：

cd /workspace
git clone https://github.com/Comfy-Org/ComfyUI.git
cd ComfyUI
pip install -r requirements.txt

环境层最容易踩的坑是版本错配。自定义节点里带编译扩展的（比如某些 attention 加速、自定义采样器），往往对 PyTorch 和 CUDA 版本有硬要求。排查方法是先看节点仓库 README 里声明的版本，再和云端 python -c "import torch; print(torch.__version__, torch.version.cuda)" 的输出对比。对不上就换模板或降级，不要指望“先装上再说”。

依赖层：自定义节点要连依赖一起搬

节点变红是迁移后最刺眼的信号，它对应的含义很明确：这个节点的代码不在云端。两种处理方式——用 ComfyUI-Manager 从界面里安装，或者手动 clone 到 custom_nodes：

cd /workspace/ComfyUI/custom_nodes
git clone https://github.com/<作者>/<节点仓库>.git
cd <节点仓库>
pip install -r requirements.txt

关键在于不要只 clone 不装依赖。很多节点的 requirements.txt 里带了特定版本的库，跳过这一步，节点能加载但一执行就抛 ModuleNotFoundError。装完后重启 ComfyUI，再看节点是否恢复正常。

还有一种更隐蔽的情况：节点装上、依赖也装了，但导入时报 Cannot import .../nodes.py。这通常不是缺包，而是节点与当前 ComfyUI 版本不兼容——ComfyUI 本体更新较快，部分节点会滞后。处理顺序是先把 ComfyUI 切到节点 README 标注的兼容版本，而不是反过来去改节点代码。

模型层：文件、目录、校验三步走

模型是体积最大、也最容易“以为传了其实没传”的一层。ComfyUI 按模型类型分目录存放，云端要保持同样结构：

模型类型	本地常见位置	云端对应位置
主模型 checkpoint	`models/checkpoints/`	同路径
LoRA	`models/loras/`	同路径
VAE	`models/vae/`	同路径
ControlNet	`models/controlnet/`	同路径

同步有两条路。文件在本地、体积不算夸张，用 rsync 推到持久卷最省心：

rsync -avh --progress ./models/checkpoints/ user@<pod地址>:/workspace/ComfyUI/models/checkpoints/

模型本来就在云端仓库（比如 Hugging Face），直接在 Pod 上下载更划算，避免先下到本地再传一遍。Runpod 也提供了 runpodctl 用于在本地和 Pod 之间传文件，大文件场景比网页上传稳。

传完之后做一次校验，别跳过：比对文件大小或哈希，确认没有传一半中断。工作流里引用的每一个模型文件名都要能在对应目录里找到，大小写完全一致——这一点在后面路径层还会再提。

路径层：本地能跑、云端报错的头号原因

这一层最容易被忽略，因为它不会在导入时立刻报错，而是等到执行到某个节点才突然失败。典型表现有三类：

绝对路径写死。 某些节点（尤其是保存图片、加载本地文件、批量处理类节点）会把路径存成 D:AIoutput 或 /Users/xxx/ComfyUI/output。这个路径在云端不存在，节点就会报找不到目录。解决办法是把路径改成相对路径，或在云端建出同名目录。

模型路径不走默认目录。 如果你的本地配置用了 extra_model_paths.yaml 把模型指向别的盘，云端也要有对应配置，否则 ComfyUI 在默认目录里找不到文件，节点会显示模型名但加载失败。

大小写与分隔符。 Linux 文件系统区分大小写，SDXL_Base.safetensors 和 sdxl_base.safetensors 是两个文件；Windows 上不区分，所以你本地一直没发现问题。同理，和 / 混用也会在 Linux 上出问题。

一条实用经验：迁移前在本地把工作流里所有涉及文件的节点过一遍，把能改成相对路径的都改掉，剩下的记下来，到云端逐条对。

端到端验证：用一次完整出图收尾

四层都核对完，别急着跑你那个最复杂的工作流。按下面的顺序做一次完整验证，能在最小成本下暴露问题：

空跑导入：在新 Pod 里导入工作流 JSON，不执行，只看有没有红色节点。有就回到依赖层。
单节点加载：依次点开 checkpoint 加载器、LoRA 加载器、VAE 加载器，确认下拉框里能选到你同步过去的文件名。选不到就回到模型层和路径层。
小图试跑：把分辨率降到 512×512、步数降到 10 左右跑一张，验证整条链路能走通，同时避免一上来就 OOM。
原参数重跑：小图通过后，恢复原始分辨率和步数，跑一张完整图，对比本地输出。风格或细节有明显偏差，多半是模型版本或 VAE 不一致。
持久化验证：停掉 Pod 再重新启动，确认节点和模型还在。这一步能验证你是否真的把东西放在了持久卷上。

最后给一个报错对照表，方便你在验证时快速定位：

现象	大概率原因	对应层
节点显示红色 / Missing Node Type	自定义节点未安装	依赖
`ModuleNotFoundError`	节点 requirements 未装	依赖
`Cannot import nodes.py`	节点与 ComfyUI 版本不兼容	环境 / 依赖
加载器里选不到模型	模型未上传或目录不对	模型 / 路径
执行到某节点报“找不到目录”	绝对路径写死	路径
`CUDA out of memory`	显存不足或分辨率过高	环境

按这四层走一遍，绝大多数“本地能跑、云端报错”的问题都能在一次迁移内解决。真正需要留意的不是部署步骤本身，而是那些你在本地从来没意识到存在的隐式配置——它们才是迁移失败的真正原因。文中涉及 Runpod 模板、端口与持久卷的具体行为，以 Runpod 与 ComfyUI 官方文档的最新说明为准，官方文档分别位于 docs.runpod.io 和 docs.comfy.org。