在 AMD 平台上本地运行 AI 图像生成：ComfyUI + Z-Image Turbo

更新于 2026 年 9 月 16 日：我不再在自己的电脑上运行这套 ComfyUI 配置了——现在我日常的图像生成任务都是通过远程 GPU 服务器来完成的。不过下面的操作指南仍然有效，如果你想在自己的 AMD 机器上运行的话也可以照着做。

我的 AMD 电脑能在大约 27 秒内将一段文本提示转化为分辨率为 1024×1024 的完整图像：无需云账户、无需为每张图片付费，也无需排队等待其他人的请求。而使用的正是一款大多数人以为根本无法完成此类任务的 AMD 芯片呢。

最终效果如何

配置相关的内容可以稍后再说。平时，我只需打开一个浏览器标签页或从终端启动它即可。无论哪种方式：

指标	数值
分辨率	1024×1024
迭代步数 / CFG值	8步，CFG值为1.0
预热生成时间	约27秒（实际范围：26.5–30.4秒）
冷启动时间（开机后生成第一张图片）	约43.5秒，此时约有20GB的权重数据正在加载中

在这台机器上，真正的用途并非单纯为了创作艺术作品。实际上有个脚本负责为一个自建的聊天应用批量生成各种头像变体：输出文件夹里目前已有222张PNG图片，数量还在不断增加。这种稳定可靠的基础设施，正是你从那些原本只是出于兴趣而搭建、后来却不得不依赖的工具中所期望得到的。

硬件配置

这是一台配备128GB统一内存的电脑：搭载了AMD Ryzen AI Max+ 395（“Strix Halo”）处理器，其封装内还集成了Radeon 8060S集成显卡。这台机器就是我在家庭实验室相关文章中提到的ASUS ROG Flow Z13，后来因电源故障而无法继续使用。整台机器没有任何独立显卡。

接下来是关键部分：固件从128GB内存中划出64 GB作为集成显卡的专用“显存”——ComfyUI启动日志显示 Total VRAM 65536 MB, total RAM 63920 MB。这个显存量甚至超过了市面上任何一款消费级NVIDIA显卡所提供的显存容量；不过这些显存并非通过昂贵的GDDR芯片实现，而只是固件分配给GPU的系统内存而已。此外，在需要的情况下还有约31GB的GTT空间可供GPU调用。

组件	规格
CPU	AMD Ryzen AI Max+ 395，16核/32线程
集成显卡	Radeon 8060S，基于ROCm架构的gfx1151
内存	128GB统一LPDDR5X内存——其中64GB被用作显存，约62GB留给Linux系统使用
操作系统	Bazzite（基于Fedora Silverblue的不可变版系统）
独立显卡	无

这套配置所需的模型权重总大小约为20.7GB。对于64GB显存来说绰绰有余；但若是使用常见的8–16GB显存的消费级显卡，则几乎无法运行——除非将部分计算层转移到系统内存中，不过那样会牺牲性能。

软件栈

目前安装后能够正常运行的版本如下：

组件	版本
ComfyUI	v0.27.0（基于Git检出）
Python	3.12.13，使用uv创建的虚拟环境
PyTorch	2.12.1+rocm7.2
torchvision	0.27.1+rocm7.2
torchaudio	2.11.0+rocm7.2
pytorch-triton-rocm	3.5.1
ROCm	7.2，原生支持gfx1151架构

有趣的一点是：ROCm版的PyTorch会伪装成CUDA。启动日志中甚至明确显示 Device: cuda:0 AMD Radeon 8060S : native。为NVIDIA显卡编写的Python代码也能正常运行，因为它以为自己正在与NVIDIA显卡通信。此外，ComfyUI也会在此类硬件上自动禁用cuDNN，转而使用纯PyTorch实现的注意力机制（无需xformers或flash-attn），而这样运行也完全没问题。

让 ROCm 正常工作

配置上的麻烦主要出在启动脚本中的几个环境变量上：

HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0

• HSA_OVERRIDE_GFX_VERSION 用于告知 ROCm 所使用的 GPU 型号为 gfx1151。在 ROCm 7.2 版本中这个设置其实已无必要（日志里已经显示“原生支持”），但我仍保留它作为预防措施；因为在旧版 ROCm 中，这类集成显卡必须依靠此设置才能正常运行。
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True 可防止统一内存机制下的显存分配出现碎片化现象。若未设置此参数，即便系统中仍有大量空闲显存，也仍可能出现显存不足的错误。
• HIP_VISIBLE_DEVICES=0 用于指定仅使用第 0 号 GPU。虽然没什么特别之处，但万一以后添加了更多硬件的话也能派上用场。

还有一点：启动脚本中将服务器的监听地址强制设为 127.0.0.1——这并非可配置的选项，而是硬编码的值。代码中的注释称其为“整个安全机制的核心”，确实如此。若想让其他设备也能访问该服务？那就需要你自己搭建反向代理或 VPN 了；我们特意没有提供相应的配置开关。

提示词如何转化为图片

很多人觉得这个过程很神秘，其实并非如此。这只是一个简短且固定的处理流程，ComfyUI正是依据其官方模板来构建这一流程的：

Z-Image Turbo 设置说明

Z-Image Turbo 是阿里巴巴旗下 Z-Image 模型的精简版与高速版（据我所知它出自通义实验室，参数规模约为60亿，采用 Apache-2.0 许可）。所谓“精简版”在此处有具体含义：仅需8个采样步骤且 CFG 值设为1.0即可生成完整图像，而旧版模型则需要20至30步甚至更多。以下是我保存的工作流设置，它们其实就是官方提供的默认模板而已；无需费心去寻找什么“神奇组合”。

设置项	数值
采样步骤数	8
CFG 值	1.0
采样器类型	res_multistep
调度器类型	simple
ModelSamplingAuraFlow shift 参数	3
图像分辨率	1024×1024
CLIPLoader 类型	lumina2
负向提示词	已清零（使用 ConditioningZeroOut 节点）

最后一项设置值得详细说明：在 CFG 值为1.0的情况下，负向提示词其实并无作用，因此工作流中使用了 ConditioningZeroOut 节点将其值清零，而非执行毫无意义的文本编码操作。如果你觉得输入负向提示词能带来更多掌控感的话也可以自行填写；不过这并不会影响最终生成的图像效果。

真正承担核心计算任务的三个文件如下：

文件名	大小	功能说明
z_image_turbo_bf16.safetensors	12.3GB	基于 bf16 格式的扩散变换模型
qwen_3_4b.safetensors	8.0GB	文本编码器
ae.safetensors	0.34GB	VAE 模型

实测性能

这些数值并非来自发布公告中的数据，而是来自这台机器上的运行日志。连续执行20次任务后，记录到的时间范围在26.62秒至30.41秒之间；因此“约27秒”只是一个稳定且可重复的平均值，并非经过挑选后的最佳结果。算上文本编码与VAE解码所需的时间后，平均每个采样步骤大约需要2.5至3秒。

服务刚启动时生成的第一张图片耗时43.54秒，因为此时需要从磁盘加载约20GB的权重数据。此后生成的图片就快多了。如果你发现当天第一张图片的生成速度较慢，原因就在于此，并非出现了什么问题。

将其作为服务运行

每次需要生成图片时，我可不想一直守在终端前盯着那个 Python 进程。因此我将其配置为一个 systemd 用户级服务，在登录时自动启动：

ExecStart=%h/comfy/start-comfyui.sh
WorkingDirectory=%h/comfy/ComfyUI
EnvironmentFile=-%h/comfy/comfy.env
Restart=on-failure
RestartSec=5
TimeoutStartSec=120

环境变量文件则用于存放端口号及其他启动参数，方便编辑。此外还有一个小型封装程序 comfyctl，因此日常使用时只需执行该命令即可：

comfyctl start      # starts the service, waits for it to answer, opens the workflow
comfyctl status     # server health + unit state + newest output file
comfyctl generate "a foggy harbor at dawn, cinematic"
comfyctl stop
comfyctl logs

如果进程意外崩溃，Restart=on-failure 会在 5 秒后尝试重新启动它；每分钟最多重试 5 次，之后 systemd 便会放弃（这样就能避免真正的死循环）。还有一个每周定时任务，它会执行 git pull --ff-only 来获取更新，随后重启服务并检查 /system_stats 以确保一切正常。这个程序的桌面图标也是由模型自动生成的——虽然有点不合常理，但我还挺喜欢的。

无界面模式运行

网页用户界面适合偶尔使用，但日常操作则通过脚本来完成。一个仅依赖标准库的 Python 脚本负责将流程图构建为 JSON 格式、发送请求、轮询获取处理结果，最后输出生成的 PNG 图片路径：

python3 ~/comfy/comfy-generate.py "a foggy harbor at dawn, cinematic" \
  --steps 8 --width 1024 --height 1024 --out ~/Pictures/harbor.png

关于 HTTP API、控制脚本以及从其他设备安全远程访问的方法，均有详细的说明：无界面模式下的 ComfyUI：将其作为服务运行并随时随地使用。

注意事项

• 日志中出现“cuda:0”属于正常现象。 ROCm版PyTorch会将AMD显卡识别为CUDA设备。这并非配置错误，也并非在暗中使用NVIDIA显卡。
• 重启后生成的第一张图片会较慢。 权重加载阶段大约需要43秒，之后速度会稳定在约27秒左右。切勿在会话进行中重启，否则可能会误以为出了问题。
• 在此场景下负向提示词无效。 CFG值设为1.0时，负向提示词的作用会被彻底忽略。如果你发现生成的图像质量不佳，问题并不出在负向提示词上。
• 无法直接通过手机访问此服务。 监听地址被刻意硬编码为127.0.0.1。如需远程访问，需自行设置反向代理或VPN，而非修改配置文件即可实现。
• 该程序每周会自动更新一次。 这一机制在初期确实很方便；不过“仅向前推送更新”的机制虽能避免静默合并操作，但上游代码若有破坏性变更，你仍可能毫无察觉。
• 64GB内存看似充裕，实则不然。 此工作流本身仅需约20.7GB的内存来加载权重。但若同时加载多个大型模型，或运行其他对GPU资源需求较高的程序，可用内存便会迅速耗尽。

相关文章：无界面版ComfyUI：将其作为服务运行并随时随地使用 · 华硕ROG Flow Z13：我的便携式家庭实验室，可惜再也无法便携了 · DisPatch：一款用于本地AI代理的自托管聊天应用 · StudioForge：取代LM Studio的纯GPU驱动的LLM服务器