部署前先确认适用场景
SD.Next 是基于 Stable Diffusion 生态的 AI绘画工具，适合希望在 Linux 服务器上长期运行图像生成服务的个人创作者、设计团队和内部工具平台。与桌面端临时启动不同，服务器部署更强调环境稳定、显卡资源管理、远程访问安全和后台持续运行。常见场景包括：在云主机或本地工作站上提供 Web 界面、多用户共享一台显卡机器、通过局域网访问生成服务，或把它作为后续自动化工作流的一部分。
部署前需要明确一点：SD.Next 对硬件资源比较敏感，尤其依赖显卡显存。一般建议 NVIDIA 显卡显存不低于 8GB，生成高分辨率图片或使用较大模型时建议 12GB 以上。CPU 也能运行，但速度较慢，不适合作为主要生产环境。系统方面推荐 Ubuntu 22.04 LTS、Debian 12 或其他主流 Linux 发行版，本文以 Ubuntu 系列命令为例，其他系统可替换对应包管理命令。
环境准备：系统、驱动与基础组件
首先更新系统软件包，建议使用具备管理权限的普通用户登录，不要长期使用 root 直接运行服务。可执行：sudo apt update && sudo apt upgrade -y。随后安装常用依赖：sudo apt install -y git wget curl python3 python3-venv python3-pip build-essential libgl1 libglib2.0-0。部分图像处理组件会依赖 OpenGL 与系统库，缺少时容易出现界面启动正常但生成失败的问题。
如果使用 NVIDIA 显卡，需要确认驱动和 CUDA 运行环境可用。执行 nvidia-smi，能看到显卡型号、驱动版本和显存占用，说明基础驱动正常。服务器如果刚安装系统，建议优先使用发行版推荐的稳定驱动，不要盲目追新。驱动安装或升级后通常需要重启。若 nvidia-smi 无法识别设备，应先处理驱动问题，再继续部署 SD.Next，否则后续 Python 依赖安装成功也无法调用 GPU。
磁盘空间也要提前规划。程序本体占用不算大，但模型、LoRA、VAE、输出图片和缓存会快速增长。建议为部署目录预留至少 80GB，长期使用建议 200GB 以上，并将模型目录与系统盘分开管理，便于扩容和备份。
获取源码并创建运行环境
选择一个固定目录存放服务，例如 /opt/ai 或用户家目录下的 apps。可执行：mkdir -p ~/apps && cd ~/apps，然后获取项目源码：git clone https://github.com/vladmandic/automatic.git sdnext。进入目录：cd sdnext。SD.Next 项目会在启动过程中自动处理大量 Python 依赖，但手动创建虚拟环境更利于隔离和维护。
创建虚拟环境：python3 -m venv venv。启用环境：source venv/bin/activate。随后升级基础工具：python -m pip install --upgrade pip wheel setuptools。首次启动可执行：./webui.sh。脚本会检测环境、下载依赖并生成必要配置。第一次安装耗时较长，取决于服务器性能和网络质量，看到本地访问地址或监听端口后，说明基础服务已经启动。
如果服务器没有图形界面，这是正常情况，SD.Next 通过浏览器访问 Web UI。默认常见端口为 7860，实际以启动日志为准。若只在服务器本机测试，可使用 curl https://127.0.0.1:7860 查看是否有响应；若从其他设备访问，需要在启动参数中允许监听外部地址。
模型与目录配置
部署完成后，还需要准备基础模型文件。常见模型目录一般位于项目下的 models/Stable-diffusion，也可以在设置中指定外部模型路径。为了便于维护，建议建立独立目录，例如 /data/sd-models/checkpoints、/data/sd-models/lora、/data/sd-models/vae，再通过软链接或配置项映射到 SD.Next。这样升级程序时不容易误删模型，也方便多套服务共用模型资源。
模型文件来源要注意授权范围，尤其是团队或商用场景，需要确认模型许可、素材来源和输出用途。不要把未知来源文件直接放入生产服务，建议先在隔离环境中测试。模型文件体积较大，上传时可使用 scp、rsync 或对象存储同步工具，传输完成后检查文件大小和校验值，避免因文件损坏导致加载报错。
远程访问与启动参数
如果需要从局域网访问，可在启动命令中加入监听参数，例如：./webui.sh --listen --port 7860。--listen 表示允许外部地址访问，--port 用于指定端口。生产环境不建议直接把服务暴露到公网，因为 Web UI 可能包含模型管理、文件读取、插件安装等敏感能力。更稳妥的方式是只允许可信网络访问，或放在反向袋里之后，并增加登录校验、访问白名单和 HTTPS。
如果只是个人远程使用，可优先选择 SSH 端口转发方式访问，本地执行：ssh -L 7860:127.0.0.1:7860 user@server_ip，然后浏览器打开 https://127.0.0.1:7860。这样 SD.Next 仍只监听服务器本地地址，风险更低。若必须开放端口，需要同时配置系统防护策略，只允许固定来源地址访问，并定期查看访问日志。
后台运行：tmux、nohup 与 systemd
临时使用时，tmux 是最简单可靠的方式。安装：sudo apt install -y tmux。创建会话：tmux new -s sdnext，进入项目目录并启动：cd ~/apps/sdnext && source venv/bin/activate && ./webui.sh --listen --port 7860。按 Ctrl+B 后再按 D 可退出会话，服务继续运行。恢复会话使用：tmux attach -t sdnext。tmux 适合调试阶段，因为可以直接查看日志。
nohup 适合简单后台运行，例如：nohup ./webui.sh --listen --port 7860 > sdnext.log 2>&1 &。但它不具备自动拉起能力，进程异常退出后需要手动处理。正式部署更推荐 systemd。可创建服务文件 /etc/systemd/system/sdnext.service，内容包括运行用户、工作目录、启动命令和重启策略。核心项可设置为：User=你的用户名，WorkingDirectory=/home/你的用户名/apps/sdnext，ExecStart=/home/你的用户名/apps/sdnext/webui.sh --listen --port 7860，Restart=always，RestartSec=10。
保存后执行：sudo systemctl daemon-reload，sudo systemctl enable sdnext，sudo systemctl start sdnext。查看状态：sudo systemctl status sdnext。查看实时日志：journalctl -u sdnext -f。使用 systemd 的好处是机器重启后自动恢复，服务异常退出后可自动重启，也方便统一管理。
更新、回滚与插件管理
更新前先停止服务：sudo systemctl stop sdnext，进入项目目录执行 git status，确认本地没有重要修改。建议先记录当前版本：git rev-parse --short HEAD。更新可执行 git pull，然后重新启动服务。若更新后出现异常，可使用 git checkout 旧版本号回到之前状态，再重启。对于生产环境，最好先在测试目录验证更新，不要在高峰使用时直接升级。
插件会显著影响稳定性。安装插件前应确认适配版本，避免一次性安装过多扩展。出现启动缓慢、界面报错或显存异常时，可先禁用最近新增的插件，再逐步排查。模型、插件和程序分开备份，是降低维护成本的关键。
常见问题与处理思路
问题一：启动提示找不到 Python 或版本不兼容。处理方式是安装 python3-venv，并确认 python3 --version。若系统 Python 过旧，可使用 pyenv 或发行版提供的新版本，但不要随意替换系统默认 Python。
问题二：nvidia-smi 正常，但程序仍使用 CPU。通常与 PyTorch 安装版本有关，可查看启动日志中的 torch 与 cuda 信息。必要时清理虚拟环境后重新安装，避免多个 Python 环境混用。
问题三：生成时报显存不足。可降低分辨率、批量数量和采样步数，关闭高占用插件，或使用低显存模式。多人共用时应限制并发，避免多个任务同时占满显存。
问题四：浏览器打不开页面。先在服务器本机检查端口是否监听：ss -lntp | grep 7860；再检查启动参数是否包含 --listen；最后确认云平台安全组或系统防护规则是否放行对应端口。若采用 SSH 转发，则无需开放外部端口。
问题五：服务运行一段时间后变慢。可检查输出目录是否过大、缓存是否堆积、插件是否存在异常日志，并定期重启服务。长期运行建议监控显存、磁盘占用和进程状态。
安全边界与实用建议
AI绘画服务部署到服务器后，不应只关注“能不能启动”，还要关注“谁能访问、能做什么、数据放在哪里”。不要给 Web UI 过高系统权限，不要把项目目录设置为所有人可写，不要在服务中保存敏感密钥。对外提供服务时，应增加访问控制，并限制上传、插件安装和文件浏览能力。
实用维护建议包括：固定部署目录，模型目录独立存放；升级前记录版本并备份配置；使用 tmux 调试，稳定后切换 systemd；定期清理输出图片和缓存；重要模型单独备份；遇到问题优先查看启动日志而不是反复重装。按照这样的流程部署，SD.Next 在 Linux 服务器上可以形成较稳定的后台运行环境，既方便日常创作，也便于后续扩展为团队级 AI 图像工作流。
