ControlNet云端部署实战：从环境配置到性能优化全指南

先聊几句实在话：ControlNet这名字听起来高大上，但它本质上就是Stable Diffusion的一个方向盘，让你能通过姿态、边缘、深度这些线索精确控制生成图的结构。而“云端部署”这四个字，对很多本地显卡吃紧、或者想把能力开放给团队的人来说，不是锦上添花，是刚需。我自己在云端反复搭过好几轮，从裸环境到插件满天飞，中间踩了不少坑，也总结出一套稳定到能直接对外服务的流程。这篇指南就把云端部署ControlNet从配置到优化的完整路径讲透，适合正在做电商图、角色设计、室内效果图，或者想把生成能力工具化的朋友。

我先把结论放在前面：云端部署ControlNet这件事，真正的难点不在ControlNet本身，而在底层的Stable Diffusion WebUI与运行环境，再加上模型与参数的适配。只要把这几件事理顺，剩下就只是时间问题。

1. 先想清楚：ControlNet云端部署到底在解决什么问题

1.1 一句话看懂ControlNet在生成流程里的角色

ControlNet是2023年初由张吕敏等人提出的神经网络结构，它做的事情非常巧妙：在不改动Stable Diffusion原始权重的前提下，通过引入可训练的副本分支，把图片的结构条件注入到生成过程中。换句话说，你不需要重训大模型，只需要挂一个小的控制网络，就能让生成结果乖乖听话。

用生活化类比来说：Stable Diffusion像一位自由发挥的画家，你给一句提示词，他画什么全凭感觉。ControlNet则像在画布上叠了一张描图纸，描图纸上已经画好了人体的骨架、物体的轮廓、场景的深度，画家必须沿着这些线条画，发挥空间被圈定，但出图的可控性大幅提升。

这个“挂一个小网络”的设计非常优雅，因为它保留了底层大模型的全部知识，同时叠加了结构约束。部署时你只需要在WebUI里装一个插件，加上独立的ControlNet模型文件，就能在文生图、图生图、局部重绘等流程里随时调用。这也是为什么它能在短时间内成为AI绘画工作流里使用率最高的辅助模块之一。

1.2 为什么非得上云：本地部署的痛点与云端优势

本地跑ControlNet，最大的门槛是显存。SD 1.5基础模型在512x512分辨率下推理大约需要4GB到6GB显存，挂上ControlNet之后，单次推理要多占2GB左右，如果再叠加高分辨率修复、多个ControlNet同时参与，16GB显存都未必从容。SDXL生态普及后，显存需求进一步上探，很多人的游戏显卡只能望图兴叹。

云端方案的优势不仅在于显存规格可以按需选择，更在于环境的一致性。我在本地装过太多次依赖，Python版本冲突、PyTorch与CUDA版本不匹配、Git LFS拉不动大模型，这些问题在云端可以用镜像和初始化脚本一次性解决。还有一点很实际：云端GPU是7x24小时在线的，你可以把批量生成任务丢上去排队跑，跑完自动关机，成本反而比专门配一台本地工作站更可控。

另外，云端天然具备服务化能力。你可以在同一台服务器上开WebUI界面给自己用，同时开启API接口给内部系统调用。团队设计、电商运营、内容生产可以共享同一套生成服务，而不是每个人都去本地折腾一个半成品环境。

1.3 部署方案的选型：云服务器、在线平台与自建服务的取舍

先给一个自查框架。如果你的需求是“偶发试验、验证想法”，云厂商提供的在线GPU笔记本完全够用，省去环境维护。如果你的需求是“长期生产、批量出图、API接入业务系统”，那么自建云端服务是更合适的方向。两者的分界线在任务量和稳定性要求上：在线平台大多有会话时长限制，闲置过久会被回收，重开环境之后还得重新装依赖，这在批量生产场景里非常痛苦。

自建云端服务也分两条路：一是裸机手动搭建WebUI，适合希望完全掌控每层配置的人，也是我下面要详细展开的路径；二是使用Docker镜像一键部署，例如社区常见的stable-diffusion-webui容器镜像，适合追求快速上手的人。我自己的经验是：至少手动完整搭一遍，理解启动流程与关键目录结构后再用Docker，这样出问题时不至于两眼一抹黑。

1.4 影响范围的拆解：从个人创作到团队协作

部署ControlNet带来的影响面比很多人想象得大。对个人创作者来说，它意味着姿势、构图、视角不再靠运气抽卡；对电商团队来说，它意味着商品图可以批量保持品牌风格，模特姿态可控，换背景不破坏主体；对设计团队来说，它意味着前期的灵感草图可以快速被重绘成高完成度素材。

更进一步，当ControlNet服务被封装成API并接入业务系统后，你的图片生产能力就不只是个人工具，而是一条内部流水线。批量任务、参数模板、生成记录管理、图片向量检索，这些东西会逐步浮出水面。后面我会专门讲如何把这套Playground升级成小型生产环境，包括向量数据库与任务队列的集成思路。

2. 云端部署环境准备：从零到能跑SD的服务端

2.1 GPU云服务器选型：显存、算力与成本的平衡

选云服务器第一个看显存，第二个看算力，第三个看带宽与存储。以ControlNet常用玩法来看，我建议直接把目标锁定在16GB到24GB显存区间。16GB可以流畅跑SD 1.5加单ControlNet并开启高分辨率修复；24GB能进一步兼顾SDXL和双ControlNet叠加场景。

市面上主流选择包括NVIDIA L4、A10G、A100、RTX系列云主机，价格相差很大，但本质差别只在算力和显存带宽上。对个人或小团队，L4级别性价比最高，功耗低，AI推理能力足够；对高频批量生产，A100的吞吐量优势才值得多花钱。如果没有强实时性要求，优先考虑竞价实例或按量计费的“省心模式”，跑完便释放。

还有一个容易被忽略的点：数据盘大小。ControlNet模型单文件普遍在1.4GB到2.5GB之间，SD模型动辄4GB到7GB，七八个模型一放就是几十GB。另外WebUI在生成过程中还会产生大量临时文件与输出图片，所以建议系统盘至少80GB，数据盘至少100GB起步，并单独挂载到工作目录。

2.2 系统初始化与基础工具链：Ubuntu、Git、Python、CUDA

云服务器拿到手后，第一件事不是急着装SD，而是把操作系统和工具链打理好。我一直用Ubuntu 22.04 LTS作为基底，原因很简单：社区支持最全，NVIDIA驱动和CUDA适配几乎没有坑。下面是在干净系统上的初始化流程，每一步都有它的目的。

sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential net-tools htop git curl wget

安装Git是必须的，因为WebUI和ControlNet插件都通过Git拉取，后续更新也依赖它。这里我建议顺手配一下Git的全局用户信息，否则某些脚本在提交或检查版本时可能出现异常。

接下来是NVIDIA驱动与CUDA。Cloud厂商一般提供GPU镜像，但有时候镜像版本陈旧。手动装驱动推荐直接用apt安装对应版本：

sudo apt install -y nvidia-driver-535 sudo reboot

重启后执行nvidia-smi验证驱动。要注意的是PyTorch自带CUDA运行时，不需要单独安装整个CUDA Toolkit，只要驱动支持即可。这一点很多新手搞反了，误以为要装完整的CUDA开发套件，结果白白浪费几十分钟。

然后安装Miniconda。用Conda管理Python环境，最大的好处是环境隔离。SD WebUI对依赖版本敏感，尤其PyTorch版本、CUDA版本一旦不匹配，会出一堆玄学错误。Conda环境可以让你随时推倒重来，不影响系统Python。

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b source ~/.bashrc conda create -n sdwebui python=3.10.12 -y conda activate sdwebui

选择Python 3.10是经过验证的稳定组合，3.11和3.12虽然也能跑，但个别依赖包在Linux上的编译兼容性不如3.10顺畅。在这个环境里，WebUI会自动安装PyTorch和全部依赖。

2.3 安装Stable Diffusion WebUI及ControlNet插件

Activate环境后，进入工作目录（比如/workspace/sd），拉取WebUI主仓库和ControlNet插件仓库。这一步要注意顺序：先装主程序，再装扩展插件，最后启动一次主程序生成目录结构，再放入模型文件。

mkdir -p /workspace/sd && cd /workspace/sd git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui git clone https://github.com/Mikubill/sd-webui-controlnet.git extensions/sd-webui-controlnet

为什么不直接用一键脚本自动装插件？因为云环境下网络不稳定，插件拉取失败会直接影响WebUI启动。手动clone的好处是能确认代码完整落盘，之后git pull更新也更省心。

启动前先配置环境变量和启动参数。我个人的固定用法是创建一个webui_user.sh脚本写入启动命令：

export CUDA_VISIBLE_DEVICES=0 export COMMANDLINE_ARGS="--xformers --api --listen --enable-insecure-extension-access"

讲解一下这几个参数：

• --xformers：开启优化的注意力实现，显存占用更低，出图速度明显更快。
• --api：开放API端口，后续可以用脚本批量调用。
• --listen：监听所有网络接口，这样可以从外部访问WebUI，但配合安全配置使用，别裸奔上公网。
• --enable-insecure-extension-access：允许通过网页安装扩展，对远程使用是刚需，但同样要搭配访问控制。

首次启动会安装PyTorch、diffusers、transformers等一堆依赖，耗时较长。建议在screen或tmux会话里执行，避免SSH断开导致进程被杀。启动成功后会看到Running on local URL: http://0.0.0.0:7860，这时浏览器访问http://服务器IP:7860就能看到WebUI界面了。

2.4 准备模型文件：基础模型与ControlNet模型放到正确位置

WebUI启动成功只代表空壳跑了，还得把模型放进去。基础模型是Stable Diffusion的核心权重，通常以.safetensors结尾，放在models/Stable-diffusion/目录下；ControlNet模型则放在extensions/sd-webui-controlnet/models/目录下。

这里要特别提醒一个容易搞错的点：ControlNet的模型是针对基础模型版本训练的。SD 1.5生态的ControlNet模型，就需要搭配SD 1.5的checkpoint使用；如果你用的是SDXL基础模型，那必须找专门为SDXL训练的ControlNet模型。混用最典型的结果是——生成出来的图片完全不生效，或者干脆报错。

模型下载推荐使用Hugging Face官方仓库，可以通过git lfs或者wget直接下载。下载后用sha256sum做一次校验，确保文件完整。我曾经因为网络中断导致模型文件损坏，ControlNet加载时总报“模型哈希不匹配”，排查很久才发现文件少了几个字节。

3. ControlNet核心配置与参数全解析

3.1 模型选择：按任务类型匹配ControlNet版本

ControlNet不是一个单一模型，而是一族按任务训练的模型。官方发布的v11版本里有canny（边缘检测）、depth（深度图）、openpose（姿态）、seg（语义分割）、scribble（草图）等多个类别。类别选错了，控制效果自然不对。

我用表格整理一下最常用的几个模型和适用场景：

下载时注意匹配自己基础模型的版本。SD 1.5选带sd15的模型文件，SDXL则选xl版本。模型文件体积普遍在1.4GB左右，下载时间视网络而定。把所有模型放在同一个目录后，WebUI下拉框会自动识别，无需额外配置。

3.2 关键参数逐项说明：权重、起止时机与预处理

在ControlNet面板里，最核心的四个控制项是：启用的ControlNet模块、对应的模型、控制权重、引导起始与结束时机。前两者决定了“用什么控制”，后两者决定了“控制到什么程度”。

Control Weight的值默认是1.0，表示完全遵循控制信号；调到0.5以下，模型可以适度偏离；调到0.2以下，几乎等于没开。我踩过最典型的坑是：权重设置太低，生成结果与ControlNet信号完全无关，还以为是模型坏了。实际操作中，姿态类控制建议0.8到1.0，边缘类控制0.6到0.9，深度类控制可以稍微低一些，因为深度信号相对宽松。

Guidance Start/End是很多人忽略的参数。默认0.0到1.0的意思是，从生成第一步到最后一步全程施加控制。你可以把它改成0.2到0.8，让生成前半段自由发挥，后半段才对齐结构，这样往往能得到更自然的结果。用户普遍反映，这个参数在创意类生成里提升明显，在生产类流程里则保持全程控制更稳妥。

还有一个细节：预处理分辨率与输入图的尺寸匹配问题。ControlNet预处理阶段会把参考图缩放到目标分辨率，如果参考图的比例和生成图比例差太多，人物会被拉变形。最佳实践是，生成图的宽高比尽量接近参考图的宽高比，必要时先裁剪再上传。

3.3 OpenPose与多角度骨骼：最实用的一类工作流

在ControlNet的众多能力里，OpenPose一直是我用得最多的。它的控制信号是人体骨骼关键点，包含头部、肩膀、手臂、腿部等位置信息。简单说，你给它一张姿态参考图，它就能告诉Stable Diffusion“人的手应该抬到这里，腿应该站在这里”，但具体这个人长什么样、穿什么衣服，完全由提示词决定。

多角度骨骼是电商和角色设计里的高频操作。你想要同一个角色生成正面、侧面、背面三个角度的展示图，传统做法是反复抽卡，角度还不一定准。用ControlNet多角度骨骼工作流，可以先用三维人台或骨骼工具生成一组标准姿态，再分别喂给OpenPose，配合固定描述角色的提示词和LoRA，就能高效生成风格统一、姿态标准的多视图素材。

操作上有一个细节值得留意：OpenPose预处理本身是自动检测上传图片中的人体骨架，但检测效果不是万能的。如果参考图里人物动作复杂，骨架检测可能出错，这时需要开启“OpenPose Editor”或手动画关键点来修正。启动WebUI后，在OpenPose编辑器里调整关节位置，保存后作为控制信号，精度高很多。

3.4 深度图、Canny与语义分割：电商图优化的组合打法

电商图片优化是我身边被问到最多的场景之一。ControlNet在电商图里的价值主要体现在三个方面：保持主体轮廓不变、控制空间透视关系、自由替换背景。

具体组合打法是这样的：用Canny提取商品的外形轮廓，作为最硬的约束；再用Depth获取整体场景的深度关系，保证主体与背景的前后层次不错乱；最后用Seg把主体和背景区分开。三项叠加后，你可以在提示词里随意描述“换个更精致的背景”、“换个更高级的打光效果”，生成结果里商品本体的形状和透视都不会跑偏。

这套方案的实际效率我测过：一张白底商品图，依次经过Canny、Depth、Seg三个模块后重绘，大约比普通图生图多花40%的推理时间，但可控性提升是质的飞跃。团队里几个运营试用后都说，终于不用一张张用PS抠图了。这也侧面反映，ControlNet并不是“一个人的玩具”，它能直接嵌入到商业制作流程里降本增效。

4. 把我踩过的坑写成速查表：常见问题与排查

4.1 模型加载失败：哈希不匹配、路径错误与文件损坏

ControlNet加载失败是部署第一天最容易遇到的事。表现是界面报错、模型下拉框看不到文件、或者生成时忽略ControlNet信号。排查顺序我建议按下面三条走：

第一，检查模型是否放在正确目录。ControlNet模型必须放在extensions/sd-webui-controlnet/models/下，而不是WebUI的models目录。这个目录搞错的话，WebUI不会识别模型文件。

第二，检查文件完整性。下载中断、磁盘空间满都会导致模型文件损坏。用sha256sum对比官方Hash，不一致就直接重新下载，不要心疼流量。

第三，检查WebUI的版本与插件版本。ControlNet插件更新频繁，老版本WebUI与新版插件偶尔不兼容。最简单的方法是进入extensions/sd-webui-controlnet目录执行git pull，然后重启WebUI。

4.2 生成速度慢、显存不足：优先检查这些配置

速度慢是性能问题，显存不足则是资源问题。先说显存不足，最容易出现的场景是：高分辨率开启了高分辨率修复，再加一个ControlNet，16GB显存会被直接塞满。解决办法是用--medvram启动参数，它会动态调度显存分配，牺牲一点速度换稳定性。如果还是爆，就降生成分辨率，或者减少同一时间加载的ControlNet模型数量。

速度慢的原因则复杂一些。最直接的加速手段是开启--xformers，对注意力层做优化，推理速度普遍能提升20%到30%。采样步数和CFG值也会显著影响耗时，生产环境里建议把采样步数控制在20到30之间，CFG控制在6到8之间，肉眼效果几乎没有差别，单张图时间能减少近四成。

还有一个经常被忽视的点：首次推理有CUDA初始化开销，会感觉特别慢。生产服务上线前，最好先跑一张小图“预热”，让模型加载到显存里，后续请求会明显提速。

4.3 ControlNet不生效：权重太低与参数没走对

“我明明开了ControlNet，为什么生成结果完全不受控制？”这个问题我被问了不下十次。大多数情况，问题不在ControlNet本身，而在配置细节。

• Control Weight设得太低（小于0.3），控制信号基本被模型忽略。
• 选错了ControlNet模块与模型。比如上传了姿态图，却选了Canny的模型，当然不会按姿态走。
• 基础模型与ControlNet模型版本不匹配。SD 1.5的ControlNet配SDXL，是无效组合。
• 检查“启用”复选框有没有勾上，以及预处理结果是否正确显示。如果预处理预览全是黑色或一团乱线，说明参考图没有被正确解析。

遇到不生效的情况，最直接的排查方法是：先把Control Weight拉到1.0，固定用Canny模型加一张明显边缘图测试，如果这样能生效，再逐步调整参数组合。

4.4 任务管理：从手工点单到脚本化批量调用

当生成需求多起来之后，在WebUI里一张张手工点击就不现实了。开启--api后，可以用脚本直接调用/sdapi/v1/txt2img接口，实现批量生成。下面这段脚本是我在服务器上跑批量时装模特图的简化版本：

import json import base64 import requests url = "http://127.0.0.1:7860/sdapi/v1/txt2img" payload = { "prompt": "full body fashion model, studio lighting, white background, best quality", "negative_prompt": "lowres, bad anatomy, extra fingers, blurry", "width": 768, "height": 1024, "steps": 25, "cfg_scale": 7, "batch_size": 1, "override_settings": { "sd_model_checkpoint": "你的基础模型.safetensors" } } response = requests.post(url, json=payload).json() with open("output.png", "wb") as f: f.write(base64.b64decode(response["images"][0]))

注意两点：一是override_settings里指定基础模型，避免WebUI里手动切换模型不一致；二是批量任务做好失败重试与结果记录，不建议直接堆几百个请求并发，单卡下并行请求反而会互相抢显存，导致OOM。

5. 性能与成本优化：从“能跑”到“跑得又快又稳”

5.1 加速三板斧：xFormers、半精度与批处理策略

云端GPU是按时计费的，每快一分钟，意味着省下真金白银。性能优化里最值得先做的三件事，分别是xFormers、半精度推理和合理的批处理。

xFormers的优化效果在前面提过，这里补充一点：它不只是省显存，更重要的是把注意力计算从平方复杂度做了算法级优化，同样的batch下能跑更大的分辨率。半精度推理则是把模型权重从FP32压缩到FP16，显存占用减半，速度也会有可感知的提升。WebUI默认在多数据加载时使用半精度，但某些插件可能会强制切回全精度，确认启动日志里显示torch.float16即可。

批处理策略大家容易走极端。有人为了省时间把batch_size从1调到4，结果显存直接爆掉。实际上，批处理减少的是重复的模型加载和调度开销，但显存占用会随batch_size线性增长。比较稳的做法是保持batch_size为1，在流程层面做并发队列管理，而不是在单次推理内硬塞多张图。

5.2 预热、队列与横向扩容：让生成服务像正经后端一样工作

把WebUI当成生产服务来用之后，只开一个进程裸奔就不够专业了。一是冷启动时首次推理慢，影响接口响应速度；二是任务堆积时没有排队机制，并发请求会互相拖垮。

预热最简单的方式，是服务启动后立刻执行一次最小的推理请求。我一般用一张64x64的低分辨率图，耗时极短，但能把CUDA上下文和模型体重都加载进显存，后续请求的平均耗时能下降一半以上。

队列管理可以用系统级的简单方案，比如写一个定时轮询脚本，读数据库里待处理的任务表，依次调API生成。进阶一点的做法是把请求打到消息队列里，消费者进程逐一处理。这个阶段，很多人会自然想到引入关系型数据库来做任务记录，MySQL稍加配置就能扛住这类低频写入，这也是为什么相关话题里MySQL安装配置会被反复提及——它其实就是任务流水线的一部分。

团队规模再大一点，单卡吞吐会成为瓶颈。此时横向扩容更划算：多台实例各自挂载WebUI与模型，前面用一个负载均衡器分发任务，模型文件通过共享存储或初始化脚本同步。相比之下，在一张卡上盲目堆并发只会让速度和稳定性同时崩掉。

5.3 成本控制：按量计费、竞价实例与冷启动停机

云GPU的成本是最容易被忽视的隐形压力。我见过不止一个人，跑完测试忘了关实例，账单出来吓一跳。控制成本有几个实用策略，按优先级排列：

• 生产任务集中到夜间批量跑，配合按量计费的闲时优惠，单价能降不少。不同平台规则不同，用前先看清楚计费模式。
• 无任务时释放GPU实例，只保留便宜的CPU机用来存模型和代码。用的时候跑一段初始化脚本，挂载数据盘并启动WebUI，冷启动时间大约在3到5分钟，完全可接受。
• 使用竞价实例。价格明显低于按量计费，但存在被回收的风险。稳妥的做法是把生成结果实时写回对象存储，实例回收不丢数据。

整套流程搭建完成后，你会发现真正决定成本的不只是GPU单价，还有你的工程化程度。任务编排顺了，一晚上能批量处理之前分散一周的工作量，单位成本自然降下来。

5.4 生成资产的存储与检索：向量数据库集成优化

批量生成之后，图片文件会迅速堆积，靠文件夹管理很快会乱。这里我引入一个进阶优化方向：向量数据库集成。这是一个在AI绘画工具链里越来越常出现的词，它解决的核心问题是“如何在海量生成素材里快速找到相近的图”。

思路不复杂：每生成一张图片，提取其视觉特征向量（用CLIP或类似模型），连同提示词、参数、生成时间一并写入向量数据库。之后你想要“和这张图风格类似的三张图”，或者在几十万个素材里找“某个品类、某个色调的图”，直接做相似度检索即可，秒出结果。

常见的开源向量数据库包括Milvus、Qdrant等，部署和维护都不复杂。我自己的实践是：先用Milvus搭建一个Collection，写入时把图片编码成512维向量，查询时用同样的编码器对参考图编码，检索TopK。这套方案的折腾成本集中在数据写入管道上，一旦跑顺，素材管理效率提升非常明显。

顺带说一句，存储和检索是配套的。建议所有生成图统一输出到对象存储或挂载的数据盘中，数据库里只保存索引和元数据，这样即使实例销毁，素材资产也不会丢。

6. 安全加固与生产级发布

6.1 SSH密钥登录与防火墙UFW基础防护

把服务跑在公网上之前，先花十分钟做安全加固。第一件事是禁用密码登录，只允许SSH密钥登录。方法是在服务器上生成密钥对，把公钥写入~/.ssh/authorized_keys，然后修改/etc/ssh/sshd_config里的PasswordAuthentication no，重启SSH服务。

第二件事是配置UFW防火墙。默认只放行SSH端口和WebUI端口，其余全部拒绝。以下是我常用的最小规则：

sudo ufw allow OpenSSH sudo ufw allow 7860/tcp sudo ufw enable

这里有一个容易被忽视的点：如果WebUI要暴露给不只你一个人访问，强烈建议加一层基础认证。WebUI本身支持--gradio-auth参数，设置用户名和密码后，任何人访问都需要登录。或者用Nginx反代加HTTP Basic Auth，更灵活。别裸奔，这类AI生成服务一旦被滥用，轻则算力被白嫖，重则账号被平台封禁。

6.2 用Nginx反代把SD变成稳定服务

裸的WebUI服务不适合直接面向外部用户。一是端口既丑又不安全，二是WebUI进程长期运行偶尔会僵住。我习惯在WebUI前面加一层Nginx反向代理，同时挂载SSL证书，这样对外只暴露标准的443端口，路径还更干净。

server { listen 443 ssl; server_name your.domain.com; ssl_certificate /etc/letsencrypt/live/your.domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your.domain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:7860; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

证书可以用Certbot自动申请和续期。配置好后，systemctl托管WebUI进程加--restart=always，WebUI进程意外退出后自动拉起，稳定性会好很多。我建议顺带配一个简单的健康检查脚本，定时请求API，连续失败就重启服务。

6.3 系统盘快照与灾难恢复的准备工作

云端环境最大的风险是配置丢失。重装系统后要重新装环境、拉模型、配插件，折腾大半天不说，中途还容易漏步骤。最简单可靠的手段是系统盘定期快照。

模型数据建议放在独立的数据盘，因为快照是针对系统盘的，模型动辄几十GB，频繁快照既不划算也没必要。对系统盘做快照，主要保的是你的配置、安装脚本、Python环境和WebUI代码；数据盘里的模型文件做好文件列表清单，需要时用脚本一键重新下载。

我自己会在/root/init.sh里写一份完整的初始化脚本，从系统更新到WebUI启动，所有步骤都固化下来。这样即使整台机器报废，开一台新实例执行一次脚本，半小时内就能复原环境。这个习惯在多次迁移服务器时帮我省了大量时间，强烈建议你也做一份。

结尾：我最终把这套流程稳定下来的体会

把云端ControlNet从“能跑”打磨到“跑得稳”之后，我个人最大的感受是：技术难点其实没那么高，真正拉开差距的是工程习惯。模型放哪里、依赖怎么隔离、任务怎么排队、服务怎么起停、出问题怎么快速复位，这些细节决定一套方案是只能自己玩，还是能交给团队用。

最后分享一个小技巧：把常用的工作流参数固化成JSON模板。同一类任务（比如电商白底图、时装模特图、室内方案图）各自存一套参数组合，包括基础模型、ControlNet模型、权重、采样步数、CFG值、正负提示词模板。批量调度时全部走模板，既减少了手工调参的随机性，也方便新人快速上手。ControlNet的乐趣就在于，你能让它越来越“听话”，而这一步，往往是从一份整齐的配置开始的。