AMD显卡本地部署Stable Diffusion WebUI：DirectML与ROCm实战指南

1. 为什么要在 AMD 显卡上折腾 Stable Diffusion WebUI先把结论摆在前面AMD 显卡跑 Stable Diffusion WebUI 这件事在 2024 年之后已经不再是“玄学”而是有明确路径的工程问题。我前后在 RX 6000 系、RX 7000 系以及部分核显平台上都部署过踩过的坑足够写一本小册子。这篇内容就是把我自己反复验证过的流程、参数、避坑点完整摊开给同样用 AMD 平台、又想本地跑 AI 绘图的同学一个可直接抄作业的参考。先说清楚这个项目到底是什么。Stable Diffusion WebUI社区里通常简称 SD WebUI是一个基于 Gradio 的浏览器图形界面把 Stable Diffusion 这套扩散模型的推理能力包装成了“填提示词、点生成”的可视化工具。它本身不是模型而是模型的操作台。你可以在里面切换底模、加载 LoRA、用 ControlNet 控制构图、跑图生图、做局部重绘。对创作者来说它解决的是“我不想写代码但我想用 AI 出图”这个核心诉求。那为什么标题里要专门强调 AMD因为这套工具链的默认假设是 NVIDIA 的 CUDA 生态。PyTorch 官方长期把 CUDA 作为一等公民AMD 的 ROCm 虽然一直在追但在 Windows 上的支持一直是个老大难。很多教程默认你有 N 卡一句pip install torch就完事AMD 用户照着做要么报错要么跑起来慢得离谱要么干脆调用不到显卡、退回 CPU 推理——一张 512x512 的图跑十几分钟体验直接劝退。所以这篇内容适合谁看三类人第一类手里是 AMD 独显或 APU 笔记本想本地跑图但被环境劝退的第二类已经装过但速度异常、想排查到底有没有真正用上 GPU 的第三类纯粹想搞清楚“AMD 到底能不能跑、怎么跑才稳”的技术好奇者。我会从方案选型讲起再到环境准备、依赖安装、启动参数、性能调优、问题排查尽量把每一步的“为什么”也讲明白而不是甩一堆命令让你复制。需要提前说明的是AMD 跑 SD 目前主流有两条路一条是 Windows 原生 DirectML通过torch-directml另一条是 Linux ROCm。两条路各有取舍我会重点讲 Windows 原生这条因为它对绝大多数人门槛最低同时也会对比说明 ROCm 方案的适用场景。下面进入正题。2. 方案选型DirectML、ROCm 还是 ZLUDA到底选哪个2.1 三条技术路线的本质区别在动手之前必须先把路线选对否则后面全是白费功夫。AMD 显卡跑 PyTorch 推理底层要解决的是“如何把张量运算映射到 AMD 的 GPU 上”。NVIDIA 用的是 CUDAAMD 对应的官方答案是 ROCm但 ROCm 在 Windows 上的消费级显卡支持非常有限官方主要面向 Linux 和数据中心卡。于是就衍生出几种绕行方案。DirectML 路线微软主导的 DirectML 是一套基于 DirectX 12 的机器学习推理 API它不挑显卡厂商AMD、Intel、NVIDIA 都能用。PyTorch 通过torch-directml这个插件把算子映射到 DirectML 上。优点是 Windows 原生、安装简单、兼容性广缺点是性能不如原生 CUDA部分算子支持不全显存管理偏保守。ROCm 路线AMD 官方的异构计算平台性能最接近“原生”在 Linux 上体验最好。Windows 上通过 HIP SDK 也能跑但对显卡型号有硬性要求且配置繁琐。适合愿意折腾 Linux、追求极致性能的用户。ZLUDA 路线一个把 CUDA 调用翻译成 ROCm/HIP 的兼容层理论上能让 AMD 卡直接跑 CUDA 程序。这个方案在社区里热度很高但稳定性和版本匹配非常敏感属于“能跑但别指望省心”的类型。我把三者的关键差异整理成一张表方便你按自己的情况对号入座。对比维度DirectMLROCm (Linux)ZLUDA操作系统Windows 原生主要 LinuxWindows/Linux安装难度低中高高性能表现中等高中高但不稳定显卡兼容性广几乎通吃限定型号限定型号稳定性较好好一般适合人群新手、Windows 用户进阶、Linux 用户折腾党2.2 我的选型建议与理由如果你只是想“尽快跑起来出图”我强烈建议先走DirectML。原因很直接它不需要你重装系统、不需要编译内核模块、不需要担心驱动版本地狱。装完 Python 环境、拉好 WebUI、把 torch 换成 directml 版本基本就能跑。性能上确实比 CUDA 慢一截但“能跑”永远比“跑得快但装不上”有价值。如果你追求性能、又愿意投入时间那Linux ROCm是更优解。ROCm 在 Linux 下对 PyTorch 的支持已经相当成熟很多 AMD 用户在 Ubuntu 上能跑到接近同档 N 卡七八成的水平。代价是要处理内核、驱动、用户组权限这些系统层面的东西。至于 ZLUDA我的态度是可以玩但别当主力。它的版本耦合太强PyTorch 一升级就可能崩适合有明确折腾目标、且能接受反复调试的人。新手直接跳过。提示无论选哪条路先确认你的显卡型号在对应方案的官方支持列表里。DirectML 基本不挑ROCm 和 ZLUDA 则要查清楚否则装到一半发现不支持时间全打水漂。2.3 显存容量的现实预期选型之外还有一个绕不开的硬指标显存。Stable Diffusion 1.5 的底模在 FP16 下大约需要 4GB 显存才能比较舒服地跑 512x512SDXL 则建议 8GB 起步最好 12GB 以上。AMD 卡在 DirectML 下的显存占用通常比 CUDA 略高因为它的内存管理没那么激进。我实测过 8GB 显存的 RX 6600跑 SD1.5 的 512x512 完全没问题开 ControlNet 后需要把分辨率压到 512 以内、batch size 设为 1。4GB 的入门卡也能跑但基本告别 SDXL 和高分辨率。所以在你投入时间之前先看一眼自己的显存心里有个底。3. 环境准备Python、Git 与驱动的前置工作3.1 Python 版本的选择与安装Python 是整套工具链的地基版本选错后面全是坑。我的建议是Python 3.10.x这是目前 SD WebUI 生态兼容性最好的版本。3.11 也能用但个别依赖包可能没有预编译 wheel会触发本地编译在 Windows 上编译环境没配好的话直接报错。3.12 及以上暂时别碰很多包还没跟上。安装时有两个关键点必须注意。第一务必勾选 “Add Python to PATH”否则命令行里敲python会提示找不到命令。第二安装路径不要带中文和空格比如C:\Users\张三\...这种路径在某些依赖处理时会出问题建议直接装到C:\Python310这种干净路径。装完后验证一下python --version pip --version两条命令都能正常输出版本号说明基础环境 OK。如果pip版本太老顺手升级一下python -m pip install --upgrade pip3.2 Git 的安装与配置WebUI 的源码是通过 Git 仓库分发的所以 Git 是必需品。去官网下载 Windows 版安装包一路默认下一步即可。安装完成后同样要验证git --version如果提示找不到命令说明安装时没把 Git 加入 PATH重新运行安装程序勾选对应选项或者手动把 Git 的cmd目录加到系统环境变量里。Git 装好后建议配置一下基础信息虽然对拉取公开仓库不是必须但养成习惯没坏处git config --global user.name 你的名字 git config --global user.email 你的邮箱3.3 AMD 显卡驱动的准备这一步是 AMD 用户和 N 卡用户最大的分水岭。N 卡装个驱动就完事AMD 用户需要额外关注驱动版本。DirectML 依赖较新的显卡驱动建议去 AMD 官网下载Adrenalin 系列的最新推荐版驱动不要用 Windows 自动更新的老版本。安装驱动时选择“出厂重置”选项可以清掉旧驱动的残留配置避免版本冲突。装完后在 AMD 软件里确认显卡型号和驱动版本记下版本号后面排查问题时用得上。注意如果你之前装过多个版本的驱动或者系统里同时有核显和独显建议先用 AMD 官方的清理工具把旧驱动彻底卸载再装新驱动。残留驱动是很多“明明装了却调用不到 GPU”问题的根源。3.4 目录规划与磁盘空间在拉取 WebUI 之前先规划好目录。我习惯在非系统盘建一个专门的工作目录比如D:\AI\然后在里面放 WebUI 本体和模型。这样做的好处是模型文件动辄几个 GB放系统盘容易把 C 盘撑爆而且重装系统时模型不用重新下载。磁盘空间方面WebUI 本体加依赖大约 5-8GB一个 SD1.5 底模约 2-4GBSDXL 底模 6-7GB再加上 LoRA、ControlNet 模型轻松突破 50GB。所以至少预留100GB的可用空间比较稳妥。4. 部署 Stable Diffusion WebUI 的完整实操4.1 拉取 WebUI 源码打开命令行切到你规划好的目录执行克隆命令cd D:\AI git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git这个仓库就是社区里最主流的 AUTOMATIC1111 版本功能最全、插件生态最丰富。克隆完成后进入目录cd stable-diffusion-webui你会看到几个关键文件webui-user.bat是 Windows 下的启动脚本launch.py是主启动逻辑requirements_versions.txt锁定了依赖版本。先别急着启动因为默认脚本会去装 CUDA 版的 torchAMD 用户直接跑会失败或者退回 CPU。4.2 替换为 DirectML 版 PyTorch这是 AMD 路线的核心步骤。默认的 PyTorch 是 CUDA 版我们要把它换成 DirectML 版。先创建一个独立的虚拟环境避免污染全局 Pythonpython -m venv venv venv\Scripts\activate激活后命令行前面会出现(venv)标识。接着安装 DirectML 版的 torch 和 torchvisionpip install torch-directmltorch-directml会自动带上匹配的 torch 版本。装完后验证一下能否识别到设备python -c import torch; import torch_directml; print(torch_directml.device_count()); print(torch_directml.device_name(0))如果输出了设备数量通常是 1和设备名称你的 AMD 显卡型号说明 DirectML 已经能正确调用显卡了。这一步是整个流程里最关键的验证点如果这里失败后面不用继续。4.3 修改启动脚本适配 AMDWebUI 默认的启动逻辑会检测 CUDA检测不到就可能报错或退回 CPU。我们需要修改webui-user.bat让它跳过 CUDA 检测、使用我们装好的 DirectML 环境。用文本编辑器打开这个文件把内容改成类似下面这样echo off set PYTHONvenv\Scripts\python.exe set GIT set VENV_DIRvenv set COMMANDLINE_ARGS--skip-torch-cuda-test --precision full --no-half --use-cpu interrogate call webui.bat这里几个参数值得解释一下。--skip-torch-cuda-test是告诉启动脚本别再找 CUDA 了否则它会一直报错。--precision full --no-half是因为 DirectML 对 FP16 半精度的支持不完善强制用 FP32 全精度能避免一堆数值错误和黑图问题代价是显存占用和速度会受影响但稳定性优先。--use-cpu interrogate是把 CLIP 反推提示词这类功能放到 CPU 上跑避免和 GPU 推理抢资源。提示如果你显存比较充裕12GB 以上可以尝试去掉--no-half看看能不能跑 FP16速度会快不少。但一旦出现全黑图、NaN 报错就老老实实加回来。4.4 首次启动与依赖安装改好脚本后双击webui-user.bat启动。第一次启动会自动下载并安装一堆依赖包括 gradio、transformers、open_clip 等这个过程可能持续十几分钟取决于网络。期间命令行会刷大量日志只要没有红色报错耐心等就行。启动成功的标志是最后出现一行类似Running on local URL: http://127.0.0.1:7860的提示。这时打开浏览器访问这个地址就能看到 WebUI 界面了。如果卡在某个依赖安装上不动多半是网络问题。可以配置国内镜像源加速pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple4.5 放置模型文件WebUI 启动后界面是空的因为还没有模型。把下载好的底模通常是.safetensors或.ckpt文件放到models\Stable-diffusion\目录下然后在界面左上角的下拉框里刷新并选择模型。模型文件从社区模型站获取注意选择合规来源。放好模型后输入一段提示词点生成观察命令行日志。如果看到类似Device: privateuseone:0的字样说明推理确实跑在 DirectML 设备上也就是你的 AMD 显卡上。如果显示的是 CPU那就要回去检查前面的步骤。5. 性能调优与参数取舍5.1 分辨率、步数与采样器的平衡AMD 卡在 DirectML 下的性能本来就比 CUDA 弱所以参数设置要更克制。我的经验是SD1.5 底模跑 512x512、20-25 步、DPM 2M Karras 采样器是比较均衡的组合。分辨率每翻一倍显存占用和耗时大约翻四倍所以别一上来就冲 1024。如果你确实需要高分辨率正确做法是先用 512 出图再用图生图的放大功能Hires. fix分步放大而不是直接拉高初始分辨率。这样显存压力小出图质量也更可控。5.2 显存优化的几个开关WebUI 提供了一些显存优化选项在设置里可以找到。对 AMD 用户来说比较有用的有Low VRAM 模式把部分模型权重换出到内存降低显存峰值代价是速度变慢。MedVRAM / 自动显存管理让 WebUI 根据当前显存动态调整。Attention 优化选择适合 DirectML 的注意力实现能省一些显存。我实测下来8GB 显存跑 SD1.5 不开优化也够用但开 ControlNet 后建议打开 Low VRAM。12GB 以上基本可以全开。5.3 批量生成的策略批量出图batch size 和 batch count是显存杀手。batch size 是同时处理几张直接吃显存batch count 是分几批处理显存占用不变但总耗时线性增加。AMD 用户的正确姿势是batch size 保持 1需要多张就调大 batch count。这样虽然慢但不会爆显存。5.4 实测性能参考为了给你一个直观预期我整理了自己在几台 AMD 机器上的实测数据SD1.5512x51220 步显卡型号显存单张耗时备注RX 66008GB约 25-35 秒DirectMLFP32RX 6700 XT12GB约 18-25 秒DirectMLFP32RX 7900 XTX24GB约 8-12 秒DirectML可尝试 FP16核显 780M共享约 3-5 分钟仅应急这些数字会随驱动版本、采样器、提示词复杂度波动但量级上可以作为参考。对比同档 N 卡AMD 在 DirectML 下大约慢 30%-50%这是当前生态的现实接受它再谈优化。6. 常见问题与排查技巧实录6.1 启动报错与依赖问题速查AMD 部署过程中最容易卡在启动阶段我把高频问题整理成表方便对照排查。现象可能原因解决方向提示找不到 CUDA未加 skip 参数在启动脚本加--skip-torch-cuda-test生成全黑图FP16 数值问题加--no-half --precision full调用不到 GPUDirectML 未装好重装 torch-directml 并验证设备依赖安装卡住网络问题配置国内 pip 镜像源显存不足报错分辨率/批量过高降分辨率、batch size 设 1启动后界面空白模型未放置检查模型目录并刷新6.2 生成速度异常缓慢的排查思路如果你发现出图慢得离谱先别急着怪显卡按这个顺序排查。第一看命令行日志里设备是不是privateuseone:0如果是cpu说明根本没用到显卡回去检查 DirectML 安装。第二确认有没有误开 Low VRAM 模式这个模式会显著降速。第三检查是不是在跑 SDXL 或高分辨率这些本身就慢。第四看后台有没有其他程序占用 GPU比如浏览器硬件加速、视频播放。6.3 驱动相关的疑难杂症AMD 驱动是很多玄学问题的源头。我遇到过几次“昨天还能跑今天突然报错”最后发现是 Windows 自动更新偷偷换了驱动版本。解决办法是关掉驱动的自动更新锁定一个稳定版本。另外如果你同时用核显接显示器、独显跑推理有时会出现设备选择混乱建议在 BIOS 里确认独显是主输出或者在 AMD 软件里明确指定。注意每次更新显卡驱动后建议重新验证一次 DirectML 设备识别因为驱动更新有可能改变设备枚举顺序导致 WebUI 找不到原来的设备。6.4 插件与扩展的兼容性坑WebUI 的插件生态很丰富但 AMD 用户要谨慎。部分插件默认调用 CUDA 专属算子装上后会导致启动失败或生成报错。我的建议是先保证裸 WebUI 能稳定出图再一个一个加插件每加一个就重启验证。ControlNet、ADetailer 这些主流插件在 DirectML 下基本可用但一些冷门插件可能直接崩。遇到插件导致的报错先禁用该插件确认问题消失后再决定是否放弃它。7. 关于 ROCm 与进阶路线的补充说明如果你在 Windows 下折腾够了想追求更好的性能可以考虑 Linux ROCm 路线。核心思路是装一个 Ubuntu 系统安装 AMD 官方 ROCm 驱动然后用 ROCm 版的 PyTorch。这条路的性能提升是实打实的很多模型能跑到 DirectML 的两倍左右。但代价也要说清楚你需要熟悉 Linux 命令行、会处理用户组权限把当前用户加入render和video组、会配置环境变量。而且 ROCm 对显卡型号有硬性要求不是所有 AMD 卡都支持。装之前务必查官方支持列表别装到一半发现自己的卡不在列。对于大多数只想出图的用户我的建议还是留在 Windows DirectML。它足够稳定、足够简单性能虽然保守但完全可用。等技术熟练了、确实遇到性能瓶颈了再考虑迁移到 Linux。工具是为人服务的别为了追求那点性能把自己折腾到放弃。最后分享一个我自己的小习惯每次成功部署后把当时的 Python 版本、torch-directml 版本、驱动版本、启动参数记在一个文本文件里。AMD 生态变化快哪天环境崩了这份记录能帮你快速回到可用状态比重新摸索省太多时间。这套流程我在好几台机器上复现过只要按部就班AMD 跑 SD WebUI 真的没那么难。