租GPU服务器跑Stable Diffusion听起来就是下单、开机、装环境、启动WebUI四步走但真操作起来不少人在第二步就开始怀疑人生驱动装好了但是WebUI识别不到显卡公网开了又被扫描器盯上模型下载到一半磁盘满了出图倒是能出一放大分辨率就OOM。这篇文章我把完整链路重新走了一遍从选服务器、基础环境、WebUI部署、公网访问到上线后的调优和故障排查一次性说清楚。适合刚租了GPU服务器、想在Stable Diffusion WebUI上出图或者把这套服务分享给朋友使用的读者顺便帮大家避开那些看起来是小问题、实际上能卡你半天的坑。1. 选GPU服务器时最容易忽视的变量显存之外还有计费和带宽1.1 显存选多大才不白花钱按模型档位和出图尺寸倒推很多人一看GPU服务器就奔着显存去非24GB不要。这个思路在训练大模型时没错但Stable Diffusion的推理场景并不需要盲目堆显存关键看你要跑什么模型、出多大图。如果只跑SD 1.5出512×512的图4GB显存也能勉强跑但体验极差。我最早在一台4GB显存的机器上跑过必须开--lowvram参数出图过程中反复把权重从显存换到内存一张图等上两三分钟是常事中途切个模型还可能直接OOM。这个档位只适合验证流程能不能走通。真正体验不错的入门底线是8GB显存。RTX 3060 8G、4060 Ti 8G这类卡跑SD 1.5很从容512×512分辨率下开xformers一张图几秒到十几秒跑SDXL的话8GB也能跑但需要--medvram1024×1024大约十几秒一张。如果预算允许12GB到24GB是当前性价比最舒服的区间。RTX 3060 12GB是租用平台上最常见的卡型跑SD 1.5各种模型加ControlNet基本无压力SDXL也能流畅出图RTX 3090或4090有24GB显存不但能跑SDXL还能同时挂多个ControlNet模块甚至可以做LoRA训练。我个人的选择逻辑很简单按用途倒推用下面这张表用途最低显存推荐显存常见租用卡型SD 1.5 512×512尝鲜4GB8GBRTX 3050、RTX 3060SD 1.5 ControlNet / LoRA8GB12GBRTX 3060 12GSDXL 1024×10248GB16GBRTX 4070 Ti SuperSDXL 多ControlNet LoRA训练16GB24GBRTX 3090、RTX 4090还有一个容易被忽略的点是显存带宽。3060 12GB和4060 Ti 16GB这类卡显存容量够大但带宽相对有限在大分辨率出图时会成为瓶颈。同样是24GB显存专业卡像A100、H100的带宽确实高得吓人但用来跑SD纯属大材小用而且价格可能是消费级卡的好几倍。Stable Diffusion推理不吃FP64、NVLink这些特性消费级卡的Tensor性能已经完全够用别为了专业两个字多花冤枉钱。1.2 计费模式中的隐性扣费关机费、流量费、存储费我见过不少人在选服务器时只盯着每小时多少钱结果月账单出来吓一跳。算力租赁平台的计费远不只是单价乘以小时数这么简单至少要问清楚三件事第一是关机是否收费。有些平台按量计费模式下关机后GPU不再计费但存储空间、IP地址可能仍然按小时或按天计费。第二是流量怎么算。GPU服务器通常有公网下行和上行流量下载Stable Diffusion模型、安装依赖、以及远程访问WebUI时传输图片都会消耗流量部分平台的流量费甚至比算力费还贵。第三是竞价实例的回收策略。有些平台提供竞价/抢占式实例价格很低但实例可能随时被回收。你跑个批量生图任务跑到一半实例没了图全白跑。我的建议是如果是长时间跑图或者跑后台服务选包月、包周更省心如果只是短期测试按量计费配合自动关机策略即可。另一个省心的办法是看平台有没有已经预装WebUI的GPU镜像有的平台甚至提供SD一键部署镜像能省掉后面大半天的安装依赖时间虽然版本可能不是最新的但先跑通流程后面再手动升级完全来得及。1.3 机房网络和预装镜像能省掉大半天的部署时间GPU服务器选机房时除了价格还要考虑网络链路。国内云厂商的国内机房访问GitHub、HuggingFace这类站点经常不稳定而Stable Diffusion的依赖包和模型偏偏都在这类站点上。虽然可以通过各种镜像源解决但如果直接选择网络链路更友好的机房或者选择某些已经配置好基础环境的镜像能显著减少各种超时重试。我自己的经验是开局先看平台有没有含Stable Diffusion WebUI的镜像哪怕需要付费也比手动折腾一天划算。如果没有预装镜像就确认为你分配到的磁盘是不是高性能SSD、系统盘空间是多少、是否支持挂载数据盘。模型下载和解压对磁盘IO有一定要求机械盘不是不能跑但首次下载和加载模型时会明显慢。2. 拿到服务器后的前30分钟驱动核对、Python隔离与磁盘规划2.1 第一件事是确认nvidia-smi输出而不是急着装CUDA登录GPU服务器后很多新手做的第一件事是去装CUDA结果越装越乱。正确做法是先运行nvidia-smi看驱动是否已经装好、驱动版本对应的CUDA版本是多少。这里有个常见的误区nvidia-smi显示的CUDA版本并不是系统真的装了CUDA toolkit它只是表示当前驱动支持的最高CUDA版本。Stable Diffusion WebUI运行时所依赖的PyTorch自带CUDA runtime并不需要单独安装完整的CUDA toolkit。只要驱动版本号大于等于PyTorch官方要求的CUDA版本就能正常运行。如果nvidia-smi报错或者看不到显卡说明驱动有问题。Ubuntu系统下最稳妥的方式是apt update apt install -y ubuntu-drivers-common ubuntu-drivers autoinstall reboot自动安装会选择合适的驱动版本。装完后重启再跑nvidia-smi应该就能看到显卡信息了。这里还要提醒一句很多云平台默认给的是root账号操作是方便但安全上我不建议长期用root跑WebUI后面可以建一个普通用户来运行服务。2.2 Python版本与虚拟环境WebUI官方脚本对Python版本很挑剔Stable Diffusion WebUI的启动脚本会自动创建虚拟环境并安装依赖但它对Python版本有明确要求。目前官方支持较好的是Python 3.10和3.11其中3.10最稳。如果你租的服务器自带系统是Ubuntu 20.04默认Python通常是3.8直接跑WebUI会遇到各种兼容性问题最常见的是某些依赖库要求更高版本的Python。这种情况下不要试图改系统的默认Python版本容易把系统搞坏而是额外安装Python 3.10apt install -y software-properties-common add-apt-repository ppa:deadsnakes/ppa apt update apt install -y python3.10 python3.10-venv python3.10-dev装完可以用update-alternatives切换默认版本但更省事的方式是安装完直接记住Python 3.10的路径启动WebUI时用./webui.sh --skip-torch-cuda-test等参数时它会自动找合适的Python。还有个细节是pip源。国内服务器直接装依赖非常慢尤其是torch这种几个GB的包建议先把pip源换成国内镜像pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple或者用阿里云源、腾讯源都行这步能省下大量等待时间。WebUI的venv虚拟环境也会读取这个pip配置所以在系统级配置一次后续WebUI创建venv时也能继承。2.3 磁盘空间按模型库规划200GB数据盘是舒适起点磁盘100GB肯定够了吧是我见过最天真的假设。Stable Diffusion的胃口比你想象中大得多WebUI本体和依赖大约占2到3GB一个SD 1.5主模型4GB左右SDXL主模型7GB左右常见的二次元模型Anything、Counterfeit等也都在4GB到7GB之间每个LoRA几十到几百MBVAE文件300MB以上ControlNet的每个模型从700MB到2.5GB不等。把这些网络安全风险控制好即使你只装两三个主模型加几个LoRA和ControlNet50GB很容易就出去了。如果再加上CAD、embeddings、一堆下载缓存文件100GB真的不够看。我建议系统盘至少50GB另外挂一块至少200GB的数据盘用来放WebUI和模型目录。如果用平台提供了数据盘先把WebUI安装到数据盘上比如mkdir -p /data mount /dev/vdb1 /data cd /data git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git这样就不用担心以后换镜像或者扩展装多了磁盘不够。查看目录占用可以用du -sh /data/stable-diffusion-webui心里有数。3. WebUI装机的三种路线官方仓库、整合包与Docker怎么选3.1 官方仓库部署的完整命令链和国内加速配置市面上Stable Diffusion WebUI的整合包很多但服务器环境我仍然推荐从官方仓库部署原因很简单整合包通常是针对Windows桌面环境做的服务器上有一堆不必要的依赖而且升级扩展时要自己处理各种路径问题官方仓库则相对干净遇到问题去GitHub Issues搜索时大家的报错环境也和你更接近。先安装基础系统包apt update apt install -y wget git python3.10-venv然后克隆官方仓库。考虑到国内网络访问GitHub的不稳定性可以用镜像地址cd /data git clone https://gitclone.com/github.com/AUTOMATIC1111/stable-diffusion-webui.git如果gitclone不好用也可以直接从原仓库克隆只是可能要多试几次git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui启动前先设置HuggingFace的镜像环境变量否则首次启动会卡在下载模型和部分依赖上export HF_ENDPOINThttps://hf-mirror.com然后直接启动./webui.sh --listen --port 7860 --xformers首次启动会创建venv并下载torch等依赖这个阶段会持续很久如果SSH断连就前功尽弃。我习惯用tmux挂后台apt install -y tmux tmux new -s sd ./webui.sh --listen --port 7860 --xformers按CtrlB再按D退出tmux会话WebUI继续在后台跑。再次进入用tmux attach -t sd。这个习惯能救很多次命。3.2 启动参数组合--listen、--xformers、--medvram的真实作用WebUI的启动参数有很多但不能无脑全开得理解每个参数实际在干什么。--listen是必备的不加这个参数服务只监听127.0.0.1外部无法访问。--port指定端口默认7860冲突时改7861之类的。--xformers是我最常用的。它能降低显存占用并提升采样速度尤其在N卡上效果明显。但注意它依赖xformers库和当前环境的编译版本部分显卡驱动组合下会有兼容性问题启动直接报错。如果加了--xformers启动失败先去掉再启动等WebUI能正常运行时再尝试装xformers。--medvram和--lowvram是显存不足时的兜底方案。--medvram把部分权重放在显存和内存之间做交换6GB到8GB显存跑SDXL时会用到--lowvram则是更激进的换入换出策略适合4GB左右显存。8GB以上显存跑SD 1.5不需要开开了反而因为反复交换权重而变慢。还有两个参数我偶尔用--precision full --no-half当某些模型在fp16精度下出图出现黑图或异常色块时加上这个参数可以解决但它会显著增加显存占用和降低速度非必要不开。--api则是开启REST API后面接入自己的脚本时再详细说。一个典型的组合是这样./webui.sh --listen --port 7860 --xformers --medvram --api先小成本验证启动是否正常再逐个调整参数别一上来把所有优化参数全加上出了问题都不知道是哪个造成的。3.3 模型放置目录与首次出图先跑通512×512再谈扩展WebUI启动后浏览器访问http://服务器IP:7860迎接你的应该是很简洁的生图界面。但这时候点击Generate大概率会报错因为还没有模型。主模型要放到models/Stable-diffusion/目录。用wget下载一个SD 1.5的官方权重文件cd /data/stable-diffusion-webui/models/Stable-diffusion wget https://hf-mirror.com/stable-diffusion-v1-5/stable-diffusion-v1-5/resolve/main/v1-5-pruned-emaonly.safetensors这个文件大约4GB同样建议在tmux里下载。下载完后回到WebUI界面点右上角的刷新按钮模型下拉框里就能看到它了。除了主模型常用的还有VAE放在models/VAE/、LoRA放在models/Lora/、ControlNet模型放在models/ControlNet/。扩展插件则装在extensions/目录下可以通过界面的Extensions菜单在线搜索安装也可以直接git clone到该目录然后重启WebUI。首次出图时建议先在512×512分辨率下测试确认基本流程通了再去挑战1024或者SDXL。我见过太多人一上来就开1024×1024结果OOM后误以为是机器不行。先小后大先官方模型后自定义模型排查会容易很多。4. 公网访问的四条路线对比直连端口、frp、Cloudflare Tunnel与安全底线4.1 直接暴露7860端口的操作和为什么我不推荐如果你租的GPU服务器有公网IP最简单的方案就是WebUI加--listen然后到云平台的安全组或防火墙放行7860端口之后任何人访问http://IP:7860就能用。听起来很爽但这是四套方案里风险最高的一种。AI绘画服务对扫描器来说是个肥肉。IP一暴露很快就会有大量扫描流量试图访问WebUI的未授权接口或者探测是否存在其他漏洞。Stable Diffusion WebUI默认不带登录认证任何人都能消耗你的显存批量生图轻则卡顿重则显存被占满导致服务崩溃。我在一次测试中只把7860端口暴露了不到两小时日志里就出现了几十条来自不同IP的访问记录。所以如果一定要直连至少要给WebUI加上登录认证。在启动参数里加--gradio-auth admin:你的密码但这只是基础防护。Gradio自带的认证机制比较简陋无法防范CSRF和暴力破解。我的结论是直连只适合临时测试也最好配上防火墙限制来源IP比如只允许你当前办公网络的IP段访问。4.2 frp穿透适合GPU服务器在内网环境的通用方案很多算力租赁平台分配给用户的GPU服务器并没有独立的公网IP而是在一个VPC内网里需要自己配置公网访问。这种情况下frp是我最常用的方案。它的原理很简单GPU服务器通过内网连接一台有公网IP的中转服务器把本地WebUI端口转发到中转服务器的某个公网端口上。中转服务器不需要多高的配置1核1G的轻量云就够用但公网带宽要留意。下载和上传图片都会经过中转服务器带宽太小体验会很难受。先在中转服务器上下载frp并启动服务端。frp的安装包里包含frps服务端和frpc客户端下载对应架构的版本解压即可。服务端配置frps.tomlbindPort 7000 auth.method token auth.token 你的强密码启动服务端./frps -c frps.toml在GPU服务器上配置客户端frpc.tomlserverAddr 中转服务器公网IP serverPort 7000 auth.token 你的强密码 [[proxies]] name sd-webui type tcp localIP 127.0.0.1 localPort 7860 remotePort 7860启动客户端./frpc -c frpc.toml这样公网访问http://中转服务器IP:7860就能连到GPU服务器上的WebUI了。frp的auth.token一定要设置否则任何能碰到7000端口的人都可以在中转服务器上开代理等于给攻击者提供了跳板。frp方案适合不需要固定域名的场景但要注意中转服务器的流量费用。高频生图时图片来回传输产生的流量可能比GPU服务器本身的费用还高。4.3 Cloudflare Tunnel有域名就能免公网IP暴露如果GPU服务器没有公网IP又不想额外买中转服务器Cloudflare Tunnel是另一个很顺滑的选项。它通过Cloudflare的全球网络建立一条隧道把本地服务暴露到一个自定义域名上而且自带TLS加密访问地址是HTTPS比frp裸端口安全得多。前提是你有一个域名且DNS托管在Cloudflare。免费版就够用。在GPU服务器上安装cloudflaredwget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 chmod x cloudflared mv cloudflared /usr/local/bin/登录和创建隧道cloudflared tunnel login cloudflared tunnel create sd-tunnel然后配置~/.cloudflared/config.ymltunnel: sd-tunnel credentials-file: /root/.cloudflared/隧道ID.json ingress: - hostname: sd.example.com service: http://localhost:7860 - service: http_status:404再配置DNS路由cloudflared tunnel route dns sd-tunnel sd.example.com启动隧道cloudflared tunnel run sd-tunnel之后访问https://sd.example.com就直达WebUI。国内访问Cloudflare网络的速度时好时坏但对个人使用来说完全够用。这个方案的额外好处是可以在Cloudflare面板里配Access策略对访问者做邮件验证码或Google登录验证进一步保护WebUI。4.4 公网访问前必须完成的安全加固清单无论选哪条公网路线我都建议在放行之前把下面这几件事做一遍顺序也很重要WebUI不要监听0.0.0.0的场景限制在127.0.0.1公网访问交给frp或Cloudflare Tunnel处理。只有当你明确使用直连方案时才加--listen。给WebUI加上登录认证。即使走frp或Tunnel--gradio-auth也能挡掉一批随便撞进来的人。如果使用直连方案在云平台安全组配置IP白名单尽量只允许自己的办公网或家宽IP访问。用nginx等反向代理加一层TLS和Basic Auth。把WebUI本身藏在内部外部看到的是nginx的443端口优雅很多。注意日志。WebUI启动时如果刷出一堆异常访问说明已经有人盯上端口了及时关闭公网访问并检查有没有被上传异常文件。安全这块没有一次配置终身无忧的说法尤其是公网暴露的服务定期看一眼日志和模型目录是值得养成的习惯。5. 上线后的性能调优与故障处置实测数据与排查顺序5.1 出图速度到底由什么决定显存带宽、半精度、采样器步数服务跑通只是开始出图速度才是大家真正关心的。实测下来出图速度的核心影响因素依次是显卡型号显存带宽和算力、是否开启半精度、是否使用xformers、采样器类型和步数。我拿常见卡型做过几组量级参考不同驱动和模型下会有些差异但大致范围如下卡型显存SD 1.5 512×512 20步SDXL 1024×1024 20步RTX 3060 12G12GB约1.5~2.5 it/s约0.5~1 it/sRTX 3090 24G24GB约3~4 it/s约1.5~2.5 it/sRTX 4090 24G24GB约5~8 it/s约3~5 it/s怎么让速度尽可能接近上限有几个实操技巧保持开启--xformers多数情况下能提升20%到40%的速度并降低显存占用。半精度fp16默认是开启的别轻易关--no-half只用于解决黑图问题。采样器步数不是越多越好Euler a / DPM 2M这类采样器20步已经足够堆到50步只会线性增加耗时画质提升有限。批量出图时batch_size设1就好在显存不足时强行加大batch只会OOM速度并不会成倍提升。一些扩展比如部分放大算法、动画插件后台会持续占用显存不用时最好禁用。5.2 几个高频故障的定位顺序OOM、白图、端口冲突、启动卡住我把自己在实际使用中遇到最多的四类问题按排查顺序列出来遇到时照着这个顺序能省不少时间。OOM显存不足界面直接报CUDA out of memory。先别急着怀疑机器配置按这个顺序处理关闭不需要的扩展每个扩展都可能占用几百MB显存→ 降低输出分辨率 → 打开--medvram→ 用nvidia-smi看是否有僵尸进程占着显存。特别是长期跑着WebUI不重启某些扩展有显存泄漏重启WebUI往往立刻解决。输出全黑图或异常色块通常是模型精度问题。可以加--precision full --no-half重启试一下。如果加了就好了说明某个模型在fp16下确实有兼容问题。另一种情况是VAE缺失或匹配错误去下载正确的VAE放在models/VAE/目录并手动指定。端口冲突启动日志会提示Address already in use。换端口就行--port 7861。不推荐杀掉占用端口的进程因为你可能正在跑另一个生图任务。启动卡住启动过程卡在某个下载步骤大概率是网络问题。原因通常是下载模型或某依赖超时。把启动日志看完确认是在下载什么东西再设置对应镜像然后重启。用tmux挂后台、反复重启时不设限让它慢慢下载这样最省心。模型文件损坏用wget下载大文件时中断再续传后文件损坏加载时报Error loading model。用wget -c断点续传或者下载完成后检查文件大小是否和源文件一致。5.3 API模式把WebUI当作生图后端接入自己的脚本WebUI不只是个网页开--api之后它还提供了一组REST API方便你把它当作一个生图服务接入自己的脚本。我倾向于先用网页调好参数再通过API做批量生图这样既保留了调试的直观性又能自动化。API的关键端点是/sdapi/v1/txt2img用curl测试curl -X POST http://127.0.0.1:7860/sdapi/v1/txt2img \ -H Content-Type: application/json \ -d { prompt: a cute cat, masterpiece, steps: 20, width: 512, height: 512, batch_size: 1 } -o result.json返回的JSON里images字段是base64编码的图片用Python存成文件很方便import json import base64 with open(result.json, r) as f: data json.load(f) img_data base64.b64decode(data[images][0]) with open(output.png, wb) as f: f.write(img_data)API模式下尤其要注意并发控制。WebUI本质上是单GPU资源多个并发请求同时打到API上显存会被瞬间打满。我的做法是在脚本里加一个简单的任务队列或者用nginx限制/sdapi/路径的QPS避免并发尖峰打崩服务。这些经验是我实际部署过一轮之后沉淀下来的。最后再分享两个小习惯一是关键路径的安装、启动命令都写成一个脚本放到/root/下下次重置实例后照着跑一遍就行不用再回忆二是定期把模型目录和配置文件做一次快照避免平台回收实例后好不容易下载的模型全部归零。GPU服务器这套东西真正让人头疼的从来不是显卡本身而是显卡之后每个环节的细节。把这几个环节理顺了Stable Diffusion WebUI跑起来也就是一杯咖啡的功夫。