部署前先判断服务器是否合适
Automatic1111 是常用的 Stable Diffusion WebUI 项目，适合需要在浏览器中生成、管理和测试AI绘画模型的个人创作者、设计团队与开发者。把它部署到 Linux 服务器上，优势是算力集中、可远程访问、任务不中断，也便于多人在同一套环境中协作。但它对显卡、显存、驱动和依赖版本比较敏感，部署前应先确认服务器条件。
推荐使用 Ubuntu 20.04、22.04 或 Debian 系发行版，显卡优先选择 NVIDIA，显存建议 8GB 起步，生成大图或使用 ControlNet、高清修复等功能时建议 12GB 以上。CPU 模式也能运行，但速度较慢，更适合功能验证。磁盘空间至少预留 50GB，模型文件通常较大，后续还会产生缓存、输出图和插件数据。
开始前需要准备服务器登录权限、可用的 Python 环境、Git、基础编译工具，以及与显卡匹配的驱动。不要在生产业务服务器上直接试装，建议使用独立实例或容器化环境，避免依赖冲突影响其他服务。
基础环境安装与检查
登录服务器后，先更新系统软件索引并安装基础工具：apt update && apt install -y git wget curl python3 python3-venv python3-pip build-essential。不同发行版命令略有差异，但核心是确保 git、python3、venv、pip 都可用。
检查 Python 版本可执行 python3 --version。Automatic1111 通常对 Python 版本有要求，常见稳定选择是 Python 3.10。如果系统默认版本过高或过低，建议通过系统软件源或 pyenv 单独安装，不要随意替换系统 Python，以免影响系统组件。
如果使用 NVIDIA 显卡，应先确认驱动状态。执行 nvidia-smi，能看到显卡型号、驱动版本和显存占用，说明驱动基本正常。如果命令不存在或报错，需要先安装显卡驱动并重启服务器。CUDA 工具包并非所有场景都必须手动安装，因为 PyTorch 通常会安装对应运行组件，但驱动版本必须满足要求。
下载 Automatic1111 并建立运行目录
建议把项目放在固定目录，例如 /opt/ai 或用户 home 目录。执行 mkdir -p /opt/ai && cd /opt/ai，然后获取项目：git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git。完成后进入目录：cd stable-diffusion-webui。
项目自带启动脚本 webui.sh，首次运行会自动创建虚拟环境并下载依赖。为了减少权限问题，推荐使用普通用户运行，而不是长期使用 root。若目录属于 root，可通过 chown -R 用户名:用户名 /opt/ai/stable-diffusion-webui 调整权限。
模型文件通常放在 models/Stable-diffusion 目录下，扩展名常见为 .safetensors 或 .ckpt。建议优先使用来源清晰、格式安全的模型文件，并保留文件名中的版本信息，方便后续排查效果差异。VAE、Lora、ControlNet 等资源也应放入对应目录，不要混在一起。
首次启动与关键参数配置
在项目目录中执行 ./webui.sh 即可开始初始化。首次启动时间较长，脚本会创建 venv 虚拟环境、安装 PyTorch、下载前端组件并生成配置。看到 Running on local URL: https://127.0.0.1:7860 之类提示，表示本机服务已经启动。
如果需要通过服务器地址访问，需要修改启动参数。推荐编辑 webui-user.sh，在 COMMANDLINE_ARGS 中加入 --listen --port 7860。--listen 表示监听外部连接，--port 用于指定端口。若显存较小，可加入 --medvram 或 --lowvram；若希望减少半精度兼容问题，可根据报错选择 --no-half，但这可能增加显存占用。
常见配置示例为：COMMANDLINE_ARGS="--listen --port 7860 --xformers"。其中 xformers 可提升部分显卡上的推理效率，但安装失败时不要强行叠加参数，应先保证基础功能可用。参数每次调整后都需要重启服务。
远程访问与端口安全
服务器部署后，不能只关注能否打开页面，还要关注访问边界。若使用云主机，需要在实例规则中放行 7860 端口，同时系统防火墙也要允许访问，例如 ufw allow 7860/tcp。若只给自己使用，更建议限制来源 IP，避免服务暴露给无关访问者。
Automatic1111 默认没有强安全防护能力，不适合直接裸露在公网。可在启动参数中加入 --gradio-auth 用户名:强密码，为页面增加基础登录校验。更稳妥的做法是放在内网环境，或通过反向袋里增加访问控制、HTTPS 和日志审计。
如果只是临时测试，也可以不使用 --listen，而是在服务器上做安全的端口转发访问本地 7860。无论采用哪种方式，都不要把弱密码、固定口令和管理端口长期公开。
让服务在后台稳定运行
测试阶段可以使用 tmux 或 screen。安装 tmux 后执行 tmux new -s webui，进入项目目录运行 ./webui.sh，确认启动成功后按 Ctrl+b 再按 d 退出会话，服务会继续运行。需要查看时执行 tmux attach -t webui。这种方式简单，适合调试和短期使用。
若希望长期稳定运行，建议使用 systemd 管理。可创建服务文件 /etc/systemd/system/sd-webui.service，核心配置包括 WorkingDirectory=/opt/ai/stable-diffusion-webui，ExecStart=/opt/ai/stable-diffusion-webui/webui.sh，User=实际用户名，Restart=always。保存后执行 systemctl daemon-reload，再执行 systemctl enable sd-webui 和 systemctl start sd-webui。
查看运行状态可执行 systemctl status sd-webui，查看实时日志可用 journalctl -u sd-webui -f。使用 systemd 的好处是进程异常退出后可自动拉起，服务器重启后也能自动启动，适合团队或长期任务环境。
常见问题与处理思路
第一类问题是 Python 版本不匹配。表现为依赖安装失败、模块编译报错或启动中断。处理方式是确认 python3 --version，必要时安装 Python 3.10，并删除 venv 目录后重新运行脚本，让项目重建虚拟环境。
第二类问题是显卡不可用。若 nvidia-smi 无法显示信息，应先修复驱动；若 PyTorch 提示无法使用 CUDA，可能是驱动版本、PyTorch 版本或安装缓存异常。可删除 venv 后重装依赖，或按照项目提示指定合适的 PyTorch 安装源。
第三类问题是显存不足。生成时报 CUDA out of memory，可降低分辨率、批量数量和采样步数，关闭不必要插件，或启用 --medvram。高分辨率修复、多个插件同时运行会明显增加显存压力，排查时应先用基础文生图功能验证。
第四类问题是端口无法访问。先在服务器本机执行 curl https://127.0.0.1:7860 判断服务是否正常，再检查是否添加 --listen，随后检查系统防火墙和云主机规则。若端口被占用，可改用 --port 7861。
插件、模型与升级建议
Automatic1111 的生态丰富，插件安装通常在 extensions 目录中完成，也可以在页面的 Extensions 功能里添加。建议一次只安装少量插件，安装后重启并确认无报错。插件越多，依赖冲突和启动变慢的概率越高，生产环境应保持克制。
升级前不要直接覆盖运行中的环境。建议先停止服务，备份 webui-user.sh、models、outputs、extensions、config.json 等目录和文件，再执行 git pull。升级后首次启动如出现依赖问题，可根据日志处理，必要时重建 venv。团队环境最好先在测试服务器验证，再同步到正式环境。
如果升级后功能异常，可以通过 git log 查看最近提交，再使用 git checkout 回到旧版本。回退前同样要停止服务并备份配置。模型文件一般不需要跟随项目回退，但插件版本可能与主程序存在兼容关系，应一并检查。
合规使用与运维注意事项
AI绘画工具部署完成后，应明确使用边界。不要生成违法违规内容，不要上传未获授权的敏感素材，不要把他人作品或受保护形象用于不当用途。团队使用时建议制定素材来源、模型来源和输出审核规则，避免后续产生版权与合规风险。
运维层面要定期清理 outputs 目录和缓存，避免磁盘被生成结果占满。可用 df -h 查看磁盘空间，用 du -sh outputs/* 判断占用。日志也应定期检查，发现频繁重启、显存耗尽、异常访问等情况要及时处理。
总体来看，Automatic1111 在 Linux 服务器上的部署并不复杂，关键是按“系统依赖、显卡驱动、项目安装、模型放置、启动参数、后台守护、访问控制”的顺序推进。先让基础功能稳定，再逐步增加插件和高级参数，能显著降低排错成本，也更适合长期使用。
