Linux服务器部署ComfyUI完全指南：从驱动到systemd服务

如果你想在一台不带显示器的Linux服务器上长期跑ComfyUI，比如用几块大显存显卡做图像生成、批量出图、给团队提供生图服务，那这篇文章大概能帮你少走不少弯路。这篇内容不是照着官方README念一遍，而是把我自己从裸机环境开始，装驱动、配Python、拉仓库、搞模型目录、做成systemd服务、然后处理各种稀奇古怪报错的完整过程记下来。

先说结论：ComfyUI在Linux服务器上部署，本质上就是一个Python项目部署，只要把显卡驱动、Python虚拟环境、依赖版本这三样理顺，后面基本就是水磨功夫。但恰恰是这三样，新手最容易卡住。很多人拿到一台服务器，先装CUDA，又装cuDNN，再装Anaconda，结果环境一团乱，最后连 import torch 都过不去。这篇文章我会告诉你一套相对干净的路径：装好NVIDIA驱动，创建一个Python虚拟环境，直接用PyTorch官方源装带CUDA的torch，然后跑ComfyUI的requirements，完事。

适合看这篇内容的人，主要是这几类：一是有Linux服务器但之前只在Windows上用秋叶整合包，想转到服务器上部署的人；二是公司或实验室有一台GPU服务器，但环境比较空，需要从零开始部署ComfyUI的人；三是玩ComfyUI已经有点基础，想在服务器上做长期服务化、自动化出图的进阶玩家。如果你是纯新手，连Linux基本命令都还不太熟，建议先把 cd、ls、vim 这几个命令练熟了再来看。

1. 部署前的方案选择，以及硬件和系统检查清单

很多人在部署前根本没想清楚一个问题：我要在服务器上怎么用ComfyUI？是自己远程开着浏览器一点点搓工作流，还是把ComfyUI当后端服务，让别人通过API来调？这两种用法对部署方式的影响很大。如果是自己搓工作流，那其实部署完，能把网页开出来就成功了大半。如果是做服务，还得考虑开机自启、端口管理、访问鉴权、模型加载策略这些事儿。

服务器上部署ComfyUI，绝大多数情况选原生方式就够用。Docker方案也有，但对显卡直通和镜像版本的要求比较麻烦，除非你对Docker已经很熟，否则不建议一上来就上容器。裸机部署的排查链路简单，环境变量、CUDA版本、共享库路径都清清楚楚，出了问题也好定位。这篇文章后面讲的原生部署方式。

硬件这块，先泼一盆冷水：ComfyUI对NVIDIA显卡支持最好，AMD卡和Intel卡在Linux上虽然也能用，但要么需要ROCm，要么性能打折扣，折腾成本高出一大截。如果服务器上插的是NVIDIA卡，那先跑一下 nvidia-smi 看看驱动和显存。如果连 nvidia-smi 都没有，先装驱动。

一个常见误解是部署ComfyUI必须要很大的显存，其实要看你想跑什么模型。跑SD1.5，8G显存足够；跑SDXL，建议12G以上；想本地跑SD3.5或者FLUX这种大模型，建议直接上24G。但显存之外，内存也别忽略。服务器如果内存只有8G，启动FLUX或者加载一堆LORA的时候很容易被操作系统杀掉进程，别把锅甩给ComfyUI，先看看是不是内存不够。我实际测试下来，跑SDXL工作流，16G内存都比较紧张，32G算宽裕。磁盘空间也一样，一个基础模型从几GB到十几GB不等，加上一堆LORA、VAE、ControlNet模型，几百G空间说没就没，部署前一定先 df -h 看一眼。

操作系统选型上，Ubuntu 20.04或22.04 LTS是大多数人的选择，因为这俩版本的glibc、Python版本和NVIDIA驱动兼容性都比较好。CentOS也不是不行，但Python环境比较老，缺依赖的时候要自己编译，费劲。我建议用Ubuntu 22.04，Python 3.10内置可用的版本，ComfyUI官方对Python版本的要求是3.9到3.12，3.10刚好落在舒适区。

给一个我自己会用来做初步检查的命令清单：

bash复制# 检查操作系统版本
cat /etc/os-release
# 检查CPU和内存
lscpu | grep -E "Model name|Socket|Core|Thread"
free -h
# 检查磁盘空间
df -h / /home /opt 2>/dev/null
# 检查GPU以及驱动状态
nvidia-smi
# 如果上面命令没有任何输出或提示不存在，先安装显卡驱动

2. 显卡驱动、CUDA运行时与Python环境的底层配合关系

很多人在Linux上部署深度学习项目时有一个很大的误区：以为要先装一套CUDA Toolkit才能用。其实在跑PyTorch系列项目时，装好NVIDIA驱动就够了，因为PyTorch的pip包内部已经自带了CUDA runtime。你不需要手动安装完整的CUDA Toolkit，装了反而容易把系统库路径弄乱，导致版本冲突。

这个逻辑要说清楚。NVIDIA驱动是负责跟硬件打交道的内核级东西，它提供一个底层的运行时；而CUDA Toolkit里的大部分开发工具、编译器只在你自己要编译CUDA源码时才需要。PyTorch预编译包和ComfyUI的依赖，基本都直接用PyTorch自带的CUDA库，所以你只需要保证驱动的版本足够新，能支持PyTorch对应版本要求的CUDA版本就行。

举个例子。如果PyTorch是cu121版本（意思是CUDA 12.1），那你的NVIDIA驱动版本至少要能支持CUDA 12.1，查一下 nvidia-smi 右上角显示的CUDA Version是多少。这里显示的CUDA Version实际上是驱动最高支持的CUDA版本，比如显示12.2，那跑cu121的torch就没问题。我见过有人在驱动只支持CUDA 11.4的机器上强行装cu121的torch，结果导入torch直接报 libcudart.so: cannot open shared object file。遇到这种问题，先降torch版本，或者老老实实升级驱动。

Python环境这块，强烈建议用虚拟环境，不要用系统的全局Python。原因很简单：服务器上可能同时有其他项目依赖不同版本的torch、numpy、opencv，全局装的话冲突是迟早的事。用Python自带的venv就够，不需要装Anaconda。ComfyUI官方文档也推荐用venv，流程简单直接。

先给系统装上必要的软件包：

bash复制sudo apt update
sudo apt install -y git python3 python3-venv python3-pip

国内服务器如果pip速度慢，可以考虑给pip换个国内镜像源，但注意PyTorch的CUDA版本包需要从PyTorch官方源或指定源装，不要用普通镜像。普通的pip包比如requirements.txt里的依赖则可以放心用镜像。

到这儿，一个干净的服务器基础环境就准备好了。有几点值得注意：安装的Python版本不要太新。有些服务器默认Python已经是3.12了，PyTorch虽然现在支持3.12，但ComfyUI的部分自定义节点可能还比较滞后。如果你遇到装某个custom_node编译不过，首先检查Python版本。

给一个通用的显卡驱动装法参考，这里以Ubuntu为例：

bash复制# 查看推荐驱动版本
ubuntu-drivers devices
# 安装推荐驱动（通常版本号最大、标注recommended的那一个）
sudo apt install -y nvidia-driver-535
# 重启使驱动生效，或者不重启时手动加载模块
sudo reboot

重启之后再跑 nvidia-smi，能正常显示显卡型号和驱动版本，底层这块就稳了。

3. 核心安装流程：克隆仓库、构建虚拟环境、安装依赖

这一步就是实际操作了。我的习惯是把项目统一放在 /opt 或 /data/ai 这类目录下，而不是放root家目录。原因很简单：服务通常是独立的用户跑的，目录权限要跟运行用户配合好，放共享目录更清晰。

以我推荐的/opt/ComfyUI为例：

bash复制sudo mkdir -p /opt
sudo chown $USER:$USER /opt
cd /opt
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
python3 -m venv venv
source venv/bin/activate

进入虚拟环境后，先装PyTorch。装哪个版本取决于你的显卡驱动支持多新的CUDA。对现在大多数人的驱动来说，直接装cu121或cu124的版本基本没问题：

bash复制# 以cu121为例，如果你需要别的CUDA版本，去PyTorch官网找对应的index-url
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

装完先做个快速验证，确认torch能识别到GPU：

python复制python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

如果这步输出True和其他显卡型号，那整个环境基本通了。如果输出False，先去查驱动和PyTorch版本的匹配，别急着往下走。

紧接着装ComfyUI的requirements：

bash复制pip install -r requirements.txt

这一步会把ComfyUI主程序需要的所有Python依赖都装好。目前ComfyUI的requirements里核心依赖就那么几个，重点包括torch、transformers、safetensors、aiohttp、pillow、numpy这些，底层还会拉一些诸如triton这类的东西，如果你机器上有NVIDIA的卡而且torch装的是CUDA版本，triton会被正常带上。

注意：这些依赖经常会跟系统已经装的别的东西冲突，比如opencv、numpy版本被偷改之类。如果你机器上已经跑着其他Python项目，建议用虚拟环境隔离，而不是一股脑装到全局。用venv之后，万一依赖坏了，把venv目录直接删掉重建就行，代价很低。

到这里，理论上可以尝试启动ComfyUI了，不过先别急着向前台跑。启动前最好先检查一下所有依赖是否装全。一个比较高效的验证方式是直接跑一次启动命令，看前十几行日志是否报缺库：

bash复制cd /opt/ComfyUI
source venv/bin/activate
python main.py

如果依赖齐全，日志会提示它正在加载模型目录、启动服务。通常启动不带--listen参数时，只监听127.0.0.1:8188，你没法从别的机器访问，但本机能开网页就说明核心没问题。确认没问题后按Ctrl+C停下来，接着下一步做服务化配置。

4. 模型目录规划与模型下载，用软链接省掉一半磁盘焦虑

ComfyUI跟其他AI绘图工具的很大一个区别是模型的存放非常灵活。默认情况下，ComfyUI项目的models目录下分了很多子目录，比如checkpoints放主模型，loras放LoRA，vae放VAE，还有controlnet、upscale_models、embeddings等。如果你用HuggingFace上的一些新架构模型，可能还会出现unet、clip、text_encoders这些目录。记得这些目录的作用，下载模型时不要一股脑全塞进checkpoints。

部署在服务器上，磁盘规划尤其重要。服务器不像个人电脑，通常数据盘是单独挂载的。很多人会犯一个错误：把模型全下到系统盘，结果跑了几百张图后发现根目录磁盘满了，ComfyUI保存图片时报No space left on device，检查半天还以为是显卡出了问题。

我的推荐做法是：把模型文件放在一个独立的数据盘目录里，然后在ComfyUI的models目录下做软链接。

如果你有单独的数据盘，比如挂载在/data，可以先定义模型目录：

bash复制sudo mkdir -p /data/ai-models
sudo chown -R $USER:$USER /data/ai-models
# 在里面先把ComfyUI的模型子目录结构创建好
mkdir -p /data/ai-models/checkpoints
mkdir -p /data/ai-models/loras
mkdir -p /data/ai-models/vae
mkdir -p /data/ai-models/controlnet
mkdir -p /data/ai-models/embeddings
mkdir -p /data/ai-models/upscale_models

然后把ComfyUI默认的models目录里各个子目录删掉或移走，替换成软链接：

bash复制cd /opt/ComfyUI/models
# 把自带的空目录清理掉（注意确认里面没有已经下载的文件）
rm -rf checkpoints loras vae controlnet embeddings upscale_models
ln -s /data/ai-models/checkpoints checkpoints
ln -s /data/ai-models/loras loras
ln -s /data/ai-models/vae vae
ln -s /data/ai-models/controlnet controlnet
ln -s /data/ai-models/embeddings embeddings
ln -s /data/ai-models/upscale_models upscale_models

这样ComfyUI在读取模型时走的是软链接，实际写入的是数据盘，系统盘就不会因为模型越攒越多而爆炸。

模型下载是另一个主题。在服务器上下大文件，强烈建议用aria2c这类支持多线程下载的工具，速度比浏览器和wget快很多，尤其是下那种好几个G的模型文件时，差距是几十分钟和几分钟的差别。

bash复制sudo apt install -y aria2
# 以下载一个SDXL模型为例
cd /data/ai-models/checkpoints
aria2c -x 16 -s 16 -k 1M "模型的直链URL" -o 模型文件名.safetensors

下载模型要注意文件格式，.safetensors比.ckpt更安全且加载速度更快，现在主流模型也都以safetensors为主。另外有些模型文件下载时需要带token或referer，如果aria2c下载出来的文件几百KB，多半是下到了错误提示页，先拿浏览器访问直链确认。

模型文件名不要乱改，很多模型对外观有依赖。文件名会以模型名_版本.safetensors的形式出现在ComfyUI的下拉列表中，所以名字起得清楚一点，以后方便。

还有一个很多人不知道的地方，ComfyUI在启动时会扫描模型目录，模型文件越多，第一次扫描和加载越慢。如果你目录里有上百个模型，每次启动可能要多等一段时间。这个不是故障，耐心等就行。想要启动快点，可以把不常用的模型放到一个别的目录，等需要的时候再移回来或单独做软链接。

5. 把前端跑成正式服务：监听设置、systemd托管、访问控制

当你部署一个给团队或远程用的ComfyUI时，就不应该只是开个终端跑python main.py了。终端一关，服务就断了，重启服务器后还得手动启动，这很业余。正确做法是用systemd把ComfyUI做成一个后台服务，让它开机自启、崩溃自动重启、日志统一管理。

做systemd服务之前，要先把ComfyUI的启动参数搞明白。核心的启动参数有这几个：

我的习惯是，创建systemd服务前先在终端手动执行一遍完整命令确认能正常启动，而不是直接把systemd文件写死。比如：

bash复制cd /opt/ComfyUI
source venv/bin/activate
python main.py --listen 0.0.0.0 --port 8188 --disable-auto-launch

这个命令如果跑通了，你就能在同一局域网内通过http://服务器IP:8188打开ComfyUI界面。跑不通就先调，调通了再写服务文件。

接下来创建systemd服务文件：

bash复制sudo vim /etc/systemd/system/comfyui.service

内容参考如下：

ini复制[Unit]
Description=ComfyUI Server
After=network.target

[Service]
Type=simple
User=你的用户名
Group=你的用户组
WorkingDirectory=/opt/ComfyUI
ExecStart=/opt/ComfyUI/venv/bin/python main.py --listen 0.0.0.0 --port 8188 --disable-auto-launch
Restart=on-failure
RestartSec=5
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

这里有个细节，ExecStart里不要写python main.py，要写虚拟环境里的Python的完整路径/opt/ComfyUI/venv/bin/python。这样systemd启动时不需要激活虚拟环境，直接就能跑在正确的环境里。Restart=on-failure表示非正常退出时自动重启，对服务器上的长驻服务来说很有用，显卡驱动偶尔抽风把ComfyUI带崩的时候，它自己就会恢复过来。

写好后执行：

bash复制sudo systemctl daemon-reload
sudo systemctl enable comfyui
sudo systemctl start comfyui
sudo systemctl status comfyui

查看运行日志用：

bash复制sudo journalctl -u comfyui -f

服务起来之后，外网访问是个必须考虑的安全问题。ComfyUI默认没有用户密码机制，也就是说只要有人能访问到你的8188端口，谁都能上传工作流、执行代码、读取输出图片，这在公网环境下等于裸奔。如果只是内网用，问题还不大；如果服务器有公网IP或者做了端口转发，建议用Nginx反向代理加一层简单的HTTP Basic认证，或者仅通过防火墙限制访问来源IP。

一个基础的Nginx反向代理加访问认证配置大概长这样：

nginx复制server {
    listen 80;
    server_name your.hostname.com;

    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:8188;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

如果不需要公网访问，用防火墙只允许内网IP访问8188端口就行了：

bash复制sudo ufw allow from 192.168.0.0/16 to any port 8188
sudo ufw deny 8188

这一步别跳过。很多人的服务器被入侵，就是因为跑了个不带认证的AI服务，又没做防火墙，然后被人拿来当免费算力挖矿。

如果你是给多人团队提供生图服务，ComfyUI本身只管执行工作流，不做用户管理。可以考虑用ComfyUI自带的多用户或API模式做二次封装，但这话题展开就长了，后续有机会单独写一篇。

6. 实际部署中排查过的几个坑，以及解决办法

装完之后，踩坑才是真正的开始。我把自己在服务器部署ComfyUI过程中遇到的问题按频率排个序，挑几个最有代表性的展开说说。

第一个坑是服务起来了但外部访问不了。这种情况十有八九是防火墙拦了端口。Ubuntu上如果你开了ufw，默认除了22端口其他全拦，先检查一下：

bash复制sudo ufw status

如果是云服务器，还要检查安全组有没有放行8188端口。云厂商的控制台安全组和服务器内部防火墙是两层，任何一个没放行都访问不了，这个坑在腾讯云、阿里云上特别常见。顺便说一句，有些厂商默认有一层防火墙，你在机器上把端口改了，但安全组还守着旧端口，两边对不上，折腾半天才发现。

第二个坑是启动正常，但执行工作流时GPU显存不够，直接OOM。如果你跑的是SDXL或FLUX大模型，且显存只有8G或12G，那确实很容易炸。可以先试试在启动参数里加--lowvram：

bash复制python main.py --listen 0.0.0.0 --lowvram

--lowvram模式会把模型阶段性加载到显存，不再常驻，速度和显存之间做个交换。如果加了还是OOM，建议换个小模型，或者用模型分块加载策略。很多人会遇到的一个奇怪现象是，两次生成之间显存没有释放，第二次跑直接OOM。这种情况先去任务管理器里看是不是有多个python main.py进程在抢显存。ComfyUI本身有一套显存管理逻辑，但如果你用了一个不兼容的自定义节点，可能把显存占住不放，重启服务是最快的解法。

第三个坑是模型加载到一半报错：Error(s) in loading state_dict。这个报错信息会给出很多行描述不匹配的信息，大概意思就是检查点文件里的张量与当前模型结构对不上。如果你用的是别人分享的工作流，他那边基础模型选的是SD1.5，你加载的是SDXL模型，这种错就很典型。解决办法不是改代码，而是回到前端工作流中，把加载模型那个节点换成正确的模型文件。

第四个坑是当我部署完ComfyUI-Manager之后，更新自定义节点时把环境搞坏了。自定义节点是在custom_nodes目录下，很多节点都依赖额外的Python包，如果用Manager自动更新，更新的节点可能依赖新版本torch，可能与主程序冲突。这是一个很恶心的场景，我踩过一次之后得出的经验是：更新前先备份一下custom_nodes目录，或者干脆把关键节点的更新关掉。

第五个坑，看起来有点蠢但真实存在：服务器内存不够导致进程被杀。当你跑FLUX这类大模型时，只盯着显存看是没用的，模型文件加载时需要先读进内存再传到显存，内存至少要有模型的1.5到2倍空间。比如一个12G的FLUX模型，你内存只有16G，系统很容易在加载过程中触发OOM Killer，把ComfyUI进程干脆利落地杀掉，journalctl里能看到Killed process的记录。解决办法是加物理内存或者用交换分区顶上。

第六个坑是如果你想跑需要登录HuggingFace下载的模型，服务器上需要在终端里先huggingface-cli login获取token，否则ComfyUI尝试在线下载模型会卡在认证那一步。很多人会在前端一直等模型加载，却不知道后端日志里早就报403了。

第七个坑是关于启动速度和首次请求慢的问题。ComfyUI本身启动不算慢，真正慢的是第一次执行工作流时需要加载模型、编译可能用到的部分模块。如果你在服务器繁忙时段用，第一次请求等个一两分钟都是正常的，别以为卡死了。另外，预热模型之后再批量跑图，效率会高很多。

第八个坑，如果你是在服务器上通过SSH远程跑ComfyUI，想下载别人分享的工作流JSON文件然后加载。这里有个隐藏的坑：工作流文件里可能包含自定义节点的引用，如果服务器上没装对应的节点，前端会提示缺节点。工作流会显示一堆红色节点，需要你手动补齐这些自定义节点，一般是Git clone到custom_nodes目录，再重启服务。具体哪些节点缺了，ComfyUI前端界面会有提示，照着名字去GitHub上搜就好。

第九个坑是模型在线下载功能。很多工作流里会用到"从HuggingFace下载模型"的节点，这种节点会往~/.cache/huggingface目录里下模型，而且默认不清理。服务器跑久了，这个缓存目录可能吃光你的系统盘。解决方法是定期清理无用缓存，或者修改环境变量HF_HOME，把HuggingFace缓存也指到数据盘去。

bash复制# 在systemd服务文件里的Environment行加一个
Environment=HF_HOME=/data/ai-models/huggingface-cache

7. 推荐的自定义节点与启动参数调优参考

ComfyUI的默认安装只有最基本的能力，如果要跑出比较好的效果，有几个自定义节点几乎成了标配。

第一个是ComfyUI-Manager。装好之后可以在ComfyUI界面里直接搜索和安装其他自定义节点，也可以一键更新全部节点，管理缺失节点非常方便。安装方式：

bash复制cd /opt/ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Manager.git
cd ComfyUI-Manager
source /opt/ComfyUI/venv/bin/activate
pip install -r requirements.txt

装完重启ComfyUI，界面右侧会多出一个Manager按钮。

第二个是ComfyUI-AnimateDiff-Evolved，做视频生成必备；第三个是ComfyUI-VideoHelperSuite，做视频解码、抽帧回补用的。如果你主要做静态图，前两个装不装无所谓，但Manager建议是必装的。

自定义节点的安装逻辑要记住：绝大多数节点就是Git clone进custom_nodes目录，然后去节点目录里看有没有requirements.txt，有就装一下，最后重启ComfyUI。90%的节点都逃不出这个三步流程。剩下的10%可能要编译，那种就要看节点自己的README了，卡住了就去GitHub Issues找找有没有人遇到过相同问题，一般都有答案。

启动参数方面，除了前面提到的--listen和--lowvram之外，还有几个参数可以对不同场景做精细化调整。

调参这个事，别一次开一堆，每加一个参数就测一遍速度和显存占用，这样才知道哪个参数在你的组合下真正起了作用。显卡的资源情况可以用 watch -n 1 nvidia-smi 动态观察，设置完参数跑一个固定的测试工作流，对比前后差异。

还要特别提一下--disable-metadata这个参数，它可以在保存图片时不写入生成信息。如果你要做批量出图后还要用别的软件读取图片信息，加上这个参数，图片大小会小一些。

另一个容易被忽略的参数是--output-directory，可以指定出图保存目录到数据盘。默认图片存在/opt/ComfyUI/output里，一旦跑大量出图任务，这个目录占用也很快。指定到数据盘可以省心。

bash复制python main.py --listen 0.0.0.0 --port 8188 --output-directory /data/comfyui-output

8. 日常运维中值得养成的小习惯

部署完成、服务跑起来，这不算完。服务器上跑服务跟本地开个窗口完全是两回事，长期运维有自己的一套习惯。聊聊几个我在使用中逐渐总结出来的小习惯。

第一，养成看日志的习惯。ComfyUI的systemd日志就是journalctl -u comfyui，出任何问题，先看日志最后几十行，八成能直接看到报错原因。不要一问题就去群里发截图问，日志往往比任何人的猜测都更接近真相。

第二，模型文件要做登记。自己写一个models/README.txt，每次下载模型进去，就把来源、用途、分辨率、触发词记下来。这个动作很不起眼，但当你攒了几十个模型，别人问你"这个风格是哪个模型出的"时，你才不会翻遍整个目录找。对服务器这种多人共用的环境，这个习惯尤其重要。

第三，控制台的端口监控和进程监控。简单的做法是用crontab写一个定时脚本，每隔几分钟检测一下8188端口是否正常。不正常的就尝试重启systemd服务。长期跑服务的服务器，这种简单自愈机制很有必要。

bash复制# 检测脚本例子：check_comfyui.sh
#!/bin/bash
if ! ss -tlnp | grep -q 8188; then
    systemctl restart comfyui
    echo "$(date) ComfyUI服务已重启" >> /var/log/comfyui_restart.log
fi

给脚本加执行权限后，放到crontab里就行：

bash复制crontab -e
*/5 * * * * /path/to/check_comfyui.sh

机器重启之后服务能自动恢复，系统崩溃后也能自愈，这才算是合格的服务器部署。

第四，定期备份。备份的关注点不是ComfyUI本体，而是三个目录：custom_nodes（自定义节点列表）、user/default/workflows（工作流JSON）、以及一个你自己整理过的模型清单。前两个目录加起来通常很小，用rsync同步到备份目录或者直接做Git仓库都行。模型文件太大，不推荐全量备份，但模型清单一定要留着，这样就算数据盘坏了，也知道该去哪里重新下载什么。

第五，GPU服务器的温度监控。如果你在机房或办公室机柜里放了GPU服务器，注意看显卡温度。长期满载跑图，GPU温度超过85度就要注意散热了。可以用nvidia-smi --query-gpu=temperature.gpu --format=csv定时读取温度，配合报警机制能做到及时提醒。

我在实际部署中最深的体会是：ComfyUI在Linux服务器上部署，难的不是安装本身，而是装完之后能长期稳定运行。很多人在本地上跑得好好的，一到服务器就各种出问题，本质上还是没有把Linux的服务化思维建立起来——环境隔离要严格、启动方式要可控、日志要可查、权限要分明。这几条做扎实了，ComfyUI服务器也就是个普通的Python Web服务而已。