AMD Ryzen AI Max+ 395 无头服务器部署 ComfyUI 实战指南

把一台 AMD Ryzen AI Max+ 395 主机装成 Ubuntu Server 24.04，再在纯命令行环境里把 ComfyUI 跑起来，这个过程比我想象中曲折，但跑通之后，生图速度完全对得起这套硬件。这篇文章就从 BIOS 设置讲到第一个工作流出图，重点放在那些文档里不会写清楚的坑。适合想用 A 卡 APU 做本地 AI 生图、又不想依赖 Windows 整合包的人，也适合准备把手头迷你主机/一体机改造成无头生图服务器的人参考。

先说结论：这套组合的甜点在于“大内存 + 高带宽核显 + 低功耗静默运行”，但坑也集中在驱动识别和显存分配上。只要把 gfx1151 的兼容变量、PyTorch ROCm 版本、内核固件这三件事搞定，ComfyUI 就能稳定出图。

1. 为什么我会选这套“服务器+ComfyUI”组合

1.1 Ryzen AI Max+ 395 这颗 APU 的真实定位

Ryzen AI Max+ 395 不是普通锐龙处理器，它的核心亮点是把 16 个 Zen 5 CPU 核心、40 组 RDNA 3.5 核显单元和 XDNA 2 NPU 塞进同一颗芯片里。配合最高 128GB 的 LPDDR5X 统一内存，CPU 和 GPU 共享同一片内存池，不需要像独显那样通过 PCIe 拷贝显存数据。

这颗芯片在跑生图模型时特别占便宜。Stable Diffusion 这类任务本质上是大矩阵乘法加反复读写中间特征图，显存带宽和容量比单纯算力更重要。256bit 位宽的 LPDDR5X-8000 理论带宽在 256GB/s 左右，虽然比不上独立显卡的 GDDR6/X 显存带宽，但胜在容量巨大。我用它跑 SDXL 1024x1024 的图，采样过程基本不会因为显存不足切到磁盘交换，这在传统核显机器上是不敢想的。

另一个容易被忽略的点是 NPU。ComfyUI 目前主要还是吃 GPU 算力，NPU 暂时帮不上忙，但如果你后面想把 Stable Diffusion 的某些前置节点（比如图像预处理、人脸检测）搬到 NPU 上跑，这颗芯片的 50 TOPS 算力是实打实的冗余资源。

1.2 为什么不用现成的 Windows 整合包，偏要上 Ubuntu Server

国内社区流行的秋叶整合包确实方便，解压就能用。但那是给 Windows 桌面环境设计的，自带 Python 运行时、模型管理和一键更新，后台占用很高。我这边场景是长期无人值守跑图，Windows 的自动更新、驱动版本冲突、Explorer 内存泄漏都让人头疼。

Ubuntu Server 24.04 是 LTS 版本，内核 6.8 起对 AMD 开源驱动支持已经比较完整，而且不带图形界面，系统本身只占几百 MB 内存。装好 OpenSSH Server 之后，我用笔记本 SSH 进去就能管理，ComfyUI 的 Web 界面通过浏览器直接访问，不需要在主机上接显示器。配合 systemd 把 ComfyUI 做成开机自启服务，这台机器就像一个小型生图 API 服务器，非常干净。

如果你只是想在 Windows 上点鼠标跑图，那确实不需要折腾 Linux。但如果你有批量出图、模型训练前数据清洗、或者把 ComfyUI 嵌入自动化脚本的需求，Ubuntu Server 这种无头模式才是长期稳定运行的形态。

1.3 这套方案的适用与不适用

用这套配置做本地生图，最舒服的场景是：SD1.5 批量生成立绘素材、SDXL 做 1024 分辨率的概念图、FLUX.1 做高质量渲染。因为统一内存够大，我经常一次性排 8~10 个任务队列，让它夜里慢慢跑，早上起来收图。

不太适合的场景是实时交互式绘画，比如一边拖拽控制网络一边预览效果。核显的绝对算力毕竟有限，SDXL 每秒出图速度在 3~4 it/s 的水平，手绘笔刷延迟会比较明显。这类场景更适合带独立显卡的工作站。

2. 装机前必须搞定的三件事

2.1 BIOS 里的显存分配：UMA Frame Buffer 一定要手动改

这是最容易踩的坑，而且 Windows 下不明显，Linux 下会直接导致 PyTorch 报显存不足。

Strix Halo 这类 APU 的核显通常默认只分配到 512MB 或 1GB 作为专用显存（UMA Frame Buffer），其余内存通过 GTT 动态共享。ComfyUI 加载 SDXL 模型时，如果专用显存不足，会触发 GTT 慢路径，出图速度断崖式下降，甚至直接报HIP out of memory。

进 BIOS 后找UMA Frame Buffer Size或GPU Memory Allocation选项，不同主板叫法不一样。建议直接设为最大值，一般有 16GB、32GB 或 Auto。我设的是 16GB，因为 ComfyUI 加载 FP16 的 SDXL 大约需要 7~8GB 显存，16GB 足够覆盖模型权重加中间激活值。如果你的内存是 96GB 或 128GB，设 32GB 也不会影响日常使用。

注意：这里设的是“专用显存”上限，不是锁死。Linux 下 amdgpu 驱动仍然会把剩余内存用作 GTT 动态分配，所以不用担心系统内存不够用。

2.2 安装 Ubuntu Server 24.04 的几个细节

用 balenaEtcher 或 Rufus 把 Ubuntu Server 24.04 ISO 写进 U 盘，UEFI 模式启动。安装过程其实没什么特别的，但有三个细节需要留意。

第一，网络配置建议用 DHCP，装完再改成静态 IP，避免安装程序在网卡识别上卡住。Strix Halo 的 RZ616 无线网卡在 Linux 下需要额外固件，如果你用有线网卡就没这个问题。

第二，分区时我单独划了一个 512GB 的/data分区放模型文件。ComfyUI 模型动辄 5~7GB，Flux 系列甚至十几 GB，系统盘和模型盘分开，后续重装系统不影响模型。

第三，安装时在软件选择界面勾选 OpenSSH server。这一步很重要，装完系统直接拔掉显示器键盘，后面全程 SSH 操作。如果忘了勾选，装完再补装也简单：

sudo apt update sudo apt install openssh-server sudo systemctl enable --now ssh

2.3 更新内核与固件

Ubuntu Server 24.04 默认内核是 6.8，对 RDNA 3.5 的 gc1151 支持已经具备，但早期固件可能存在 microcode 和 GPU 固件版本过旧的问题。我的做法是直接升级到 HWE 内核 6.11 或更高版本：

sudo apt install --install-recommends linux-generic-hwe-24.04 sudo apt install linux-firmware sudo reboot

重启后检查：

uname -r

看到6.11.x或更新版本就对了。新版内核里 amdgpu 驱动的gc_11_5_0固件支持更完整，后面 ROCm 踩坑会少很多。

3. 驱动与运行时栈：AMDGPU、ROCm、PyTorch 的版本搭配

3.1 确认 amdgpu 内核驱动正常工作

Ubuntu 24.04 默认已经加载 amdgpu 内核模块。SSH 登录后先确认 GPU 设备是否被识别：

lspci -nn | grep -i display

正常会看到类似VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Strix [gfx1151]的输出。如果 lspci 里看不到，说明内核太老或者 firmware 缺失，先回到 2.3 更新内核。

然后检查 KFD（Kernel Fusion Driver）节点是否存在：

ls /dev/kfd

ROCm 和 PyTorch 依赖/dev/kfd来访问 GPU。如果没有，手动加载模块：

sudo modprobe amdgpu

再把 amdgpu 写进/etc/modules-load.d/amdgpu.conf，确保开机自动加载。

3.2 安装 ROCm：没必要装全家桶

AMD 官方推荐用amdgpu-install脚本一键装完整 ROCm，但在 Ubuntu Server 上我建议只装运行时需要的部分，省时省空间。原因很简单：ComfyUI 只用到了 HIP 运行时和 rocBLAS 库，完全不涉及 ROCm 的编译器、调试工具、MIOpen 这些开发组件。

先用官方仓库安装基础的 runtime 库：

wget https://repo.radeon.com/amdgpu-install/6.3.2/ubuntu/noble/amdgpu-install_6.3.2-1_all.deb sudo apt install ./amdgpu-install_6.3.2-1_all.deb sudo amdgpu-install --usecase=rocm

如果你不想走官方脚本，也可以手动装rocm-hip-libraries包。但从经验看，官方脚本能自动处理内核模块依赖，省很多事。

注意：Strix Halo 在 ROCm 6.2 之前的版本支持很差，建议至少用 ROCm 6.3 或 6.4。我在 6.3.2 上跑得很稳，PyTorch 对应的 wheel 是rocm6.2系列的，两者互相兼容。

3.3 gfx1151 识别问题：HSA_OVERRIDE_GFX_VERSION 必设

这一步是整篇文章最关键的地方。Strix Halo 的 GPU 架构代号是 gfx1151，而 ROCm 6.3 默认支持列表里可能还没有它。如果不做任何处理，PyTorch 初始化时会报：

RuntimeError: HIP error: system has no valid HIP device

或者 ComfyUI 启动时直接卡在model_management.py的显存检测阶段。

解决办法是设置环境变量，让 HIP 运行时把 gfx1151 模拟成同代已支持的 gfx1100（RDNA 3）：

export HSA_OVERRIDE_GFX_VERSION=11.0.0

gfx1100 和 gfx1151 同属 RDNA 3 家族，指令集基本一致，只是显存控制器和 CU 数量配置不同，用这个参数强制覆盖是完全安全的。为了永久生效，我把它写进了/etc/environment：

echo "HSA_OVERRIDE_GFX_VERSION=11.0.0" | sudo tee -a /etc/environment

也可以写到 systemd service 文件里，后面 7.3 会讲到。

4. Python 环境与 PyTorch ROCm 安装

4.1 为什么我用 venv 而不是 Conda

网上很多 ComfyUI 教程推荐装 Miniconda，因为在 Windows 上 conda 可以避免 Python 版本冲突。但 Ubuntu Server 本身 Python 是 3.12，ComfyUI 目前对 Python 版本要求很宽松，用系统自带的 venv 模块就够了。

Conda 的问题在于安装后默认激活 base 环境，容易干扰系统 Python 路径，而且占用额外磁盘空间。在无头服务器上，越简单的环境越容易排错。

sudo apt install python3-venv python3-pip mkdir -p /opt/comfyui cd /opt/comfyui python3 -m venv venv source venv/bin/activate

4.2 安装 PyTorch ROCm 版的版本匹配

PyTorch 官方为 ROCm 提供了预编译 wheel，安装命令里最重要的是--index-url指向 ROCm 版本对应的仓库。

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.2.4

这里有几个坑：

一是 PyTorch 的 ROCm 版本和系统 ROCm 版本不需要完全一致，只要 kernel driver 能访问 GPU，HIP runtime 版本相互兼容即可。我在系统装 ROCm 6.3.2，PyTorch 用 rocm6.2.4，跑起来没有任何问题。

二是不要用pip install torch默认的 CUDA 版本，那会从 PyPI 拉取 CUDA wheel，在 AMD 机器上直接报错。必须显式指定 index-url。

三是在安装前先把 pip 升级到最新：

pip install --upgrade pip

4.3 验证 PyTorch 是否真的识别到了 GPU

装完先跑一段最小验证脚本，确认 PyTorch 能调用 GPU 再进行下一步：

python -c " import torch print('PyTorch version:', torch.__version__) print('ROCm version:', torch.version.hip) print('GPU available:', torch.cuda.is_available()) if torch.cuda.is_available(): print('GPU name:', torch.cuda.get_device_name(0)) "

这里有个容易误判的点：在 ROCm 环境下，torch.cuda.is_available()返回 True 是正常的，因为 PyTorch 的 CUDA 抽象层把 HIP 也映射成了.cuda接口。不要看到cuda字眼就以为装错。真正的区别要看torch.version.hip，能打印出版本号说明 HIP runtime 加载成功。

再跑一个简单的矩阵乘法测试：

python -c " import torch a = torch.randn(1024, 1024, device='cuda') b = torch.randn(1024, 1024, device='cuda') c = a @ b print('matmul OK:', c.sum().item()) "

能输出matmul OK就说明 GPU 计算链路完整。

5. ComfyUI 部署：从仓库到第一张图

5.1 系统依赖与源码安装

ComfyUI 依赖一些系统图形库，不在纯净 Server 环境里默认安装。可以先补上：

sudo apt install git wget libgl1 libglib2.0-0 libsm6 libxext6 libxrender-dev

然后克隆官方仓库：

cd /opt/comfyui git clone https://github.com/comfyanonymous/ComfyUI.git app cd app pip install -r requirements.txt

如果你打算用 ComfyUI-Manager 管理插件，建议现在就装：

git clone https://github.com/ltdrdata/ComfyUI-Manager.git custom_nodes/ComfyUI-Manager pip install -r custom_nodes/ComfyUI-Manager/requirements.txt

ComfyUI 的代码更新很快，后续升级就两步：

cd /opt/comfyui/app git pull pip install -r requirements.txt

5.2 首次启动会遇到的两个小问题

第一次启动python main.py通常会遇到两个问题。

第一个是缺少libgomp.so.1，报错信息类似：

ImportError: libgomp.so.1: cannot open shared object file

解决方式：

sudo apt install libgomp1

第二个是首次运行会自动创建models等目录，但如果权限不对会报权限错误。我在/opt/comfyui下用的当前用户操作，如果报权限错误就查一下目录属主：

sudo chown -R $USER:$USER /opt/comfyui

5.3 无头模式的启动参数

ComfyUI 在服务器上没有显示器的环境里也能正常运行，它会启动一个本地 Web 服务，通过浏览器访问http://主机IP:8188即可操作。

常用启动命令：

cd /opt/comfyui/app python main.py --listen 0.0.0.0 --port 8188

参数说明：

• --listen 0.0.0.0：允许局域网内其他设备访问，如果只有本机访问可以用127.0.0.1更安全。
• --port 8188：默认端口，可改。
• --lowvram：如果你的专用显存低于 8GB，建议加这个参数，强制走内存共享路径。我这个 16GB 的配置不需要。
• --auto-launch：仅在桌面环境有意义，Server 下不要加。

第一次启动看到类似下面的日志就说明成功：

Starting server To see the GUI go to: http://0.0.0.0:8188

5.4 跑通第一个工作流

浏览器进入 Web UI 后，默认是空工作流。最简单的测试是从官方示例下载 SD1.5 的 workflow 文件，或者直接在页面上右键选“Load Default”。更直接的方式是把 ComfyUI 官方示例的 JSON 手动拖进页面。

如果你一个模型都没下载，可以先跑个最简单的“加载 checkpoint -> 空 Latent -> KSampler -> VAE Decode -> 保存图像”链路。从models/checkpoints目录放一个 SD1.5 模型，比如 DreamShaper 或 realisticVision，然后点 Queue Prompt。能看到进度条滚动，最后在输出目录拿到 PNG，就说明整条链路通了。

6. 模型选择与统一内存下的性能实测

6.1 模型目录的规范

ComfyUI 的模型目录结构是固定的，不同模型要放到对应位置：

我习惯把大模型放在/data/models下，然后通过软链接到 ComfyUI 目录，这样重装系统时模型不会丢：

mkdir -p /data/models/checkpoints ln -s /data/models/checkpoints /opt/comfyui/app/models/checkpoints

6.2 SD1.5 / SDXL / FLUX 的实测体感

以下是我在这台机器（Ryzen AI Max+ 395，96GB 统一内存，16GB UMA，Ubuntu Server 24.04 + ROCm 6.3）上的实测数据，仅供参考。不同批次步数、采样器、分辨率和模型变体都会有差异。

用 SDXL 出一张 20 步的图大概 6~8 秒，整体在可接受范围。FLUX 因为模型参数量大，加上 FP8 量化，出图速度明显偏慢，但考虑到这是纯集显在跑，已经超出我预期了。

速度数据比同功耗的独立显卡（比如 RTX 4060 Laptop）略慢，但优势是显存容量。传统 16GB 显存独显跑 FLUX 经常会撞墙，而统一内存模式下，只要系统物理内存够大，ComfyUI 几乎不会被 OOM 打断。

6.3 统一内存的甜点与陷阱

统一内存最大的甜点是“显存不够，内存来凑”。当你加载一个 12GB 的 FLUX 模型时，ComfyUI 会认为可用的 GPU 显存 = 专用显存 + 可共享内存，从而自动分配。

但有个隐藏陷阱：系统其他进程如果吃掉了大量物理内存，GPU 能用的共享内存就会相应减少。比如你同时开着数据库、浏览器、文件服务，16GB 专用显存加剩余 80GB 内存本来是富余的，结果可用内存降到 30GB，ComfyUI 在加载大模型时反而可能 OOM。

我的对策是给 ComfyUI 限制 CPU 内存占用，或者干脆单独用一台机器跑 ComfyUI。如果你是 All-in-One 服务器，建议至少留 32GB 以上内存给系统其他服务，剩余全给 GPU 跑模型。

7. 常见错误与排查：从“节点执行错误”到 HIP OOM

7.1 “节点在执行过程中发生错误”的定位方法

ComfyUI 的报错界面很简洁，红色节点提示“节点在执行过程中发生错误”，但这个提示本身不告诉你原因。真正有价值的信息在运行 ComfyUI 的终端日志里。

日志里通常会有一段 Python traceback，比如：

Error occurred when executing KSampler: The size of tensor a (128) must match the size of tensor b (64) at non-singleton dimension 0

这类问题大多是模型结构和采样器步数/降噪强度不匹配造成的。我的排查套路：

1. 先看是哪个节点报错。KSampler 报错一般是模型或 latent 尺寸问题；VAE Decode 报错一般是 VAE 缺失或版本不匹配。
2. 检查模型路径。确认 checkpoint 文件名存在，且没有中文路径。
3. 检查内存。日志里有Cannot allocate memory字样就走 7.2 的流程。

7.2 HIP OOM 与虚拟内存设置

在统一内存架构下，“HIP out of memory”通常不是真的显存不够，而是GTT可用内存不够，或者系统整体内存被占满。

先加一段 swap 作为系统兜底，防止内存尖峰导致 OOM Killer 把 ComfyUI 进程杀掉：

sudo fallocate -l 32G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

如果报错仍然存在，可以给 amdgpu 驱动限定 GTT 大小。编辑/etc/default/grub：

GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.gttsize=32768"

然后：

sudo update-grub sudo reboot

gttsize单位是 MB，32768 即 32GB。这个参数可以控制 GPU 能从系统内存中共享多少容量。如果设得太小，大模型加载失败；设得太大，CPU 可用内存紧张。建议根据你的物理内存总量设置为 1/3 到 1/2。

7.3 用 systemd 守护 ComfyUI 进程

手动在 SSH 窗口里跑python main.py只能在前台运行，SSH 断开进程就没了。我建议写一个 systemd service，开机自启，崩溃自动重启：

sudo nano /etc/systemd/system/comfyui.service

内容：

[Unit] Description=ComfyUI Service After=network.target [Service] User=yourname WorkingDirectory=/opt/comfyui/app Environment="HSA_OVERRIDE_GFX_VERSION=11.0.0" ExecStart=/opt/comfyui/venv/bin/python main.py --listen 0.0.0.0 --port 8188 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

注意Environment=和ExecStart=里的路径要写绝对路径。保存后：

sudo systemctl daemon-reload sudo systemctl enable comfyui sudo systemctl start comfyui

之后查看日志用：

sudo journalctl -u comfyui -f

这个日志里能看到完整的自定义节点加载信息和报错 traceback，排查问题比浏览器界面直观得多。

7.4 插件/自定义节点导致的启动失败

如果你装了 ComfyUI-Manager 或第三方插件后，ComfyUI 启动直接退出了，可以先禁用自定义节点：

cd /opt/comfyui/app mv custom_nodes custom_nodes.bak python main.py --listen 0.0.0.0

能正常启动就说明问题出在某个插件上。逐个把custom_nodes.bak里的目录移回custom_nodes，每移一个重启一次，就能定位冲突节点。

遇到过的一个典型问题：某个 ControlNet 相关插件要求torch>=2.3.0，但 PyTorch ROCm 版本只有 2.4.x，版本不匹配直接 import error。这种插件要么换依赖版本，要么等作者更新，没有捷径。

最后分享一个我后来才发现的细节：ComfyUI 的日志里会输出每次生成的峰值显存占用，比如Peak VRAM usage: 11.2 GB。这个数值非常有用。每次换新模型后扫一眼日志，就能判断当前 UMA Frame Buffer 分配是否合理。如果峰值一直在专用显存上限附近徘徊，建议回 BIOS 把 UMA 调大一级，出图速度会有肉眼可见的提升。我这台机器就是先把 UMA 从 8G 调到 16G 后，FLUX 出图从每步 2.4 秒降到了 1.8 秒。