把一台 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~7GBFlux 系列甚至十几 GB系统盘和模型盘分开后续重装系统不影响模型。第三安装时在软件选择界面勾选 OpenSSH server。这一步很重要装完系统直接拔掉显示器键盘后面全程 SSH 操作。如果忘了勾选装完再补装也简单sudo apt update sudo apt install openssh-server sudo systemctl enable --now ssh2.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 更新内核。然后检查 KFDKernel Fusion Driver节点是否存在ls /dev/kfdROCm 和 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 --usecaserocm如果你不想走官方脚本也可以手动装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 模拟成同代已支持的 gfx1100RDNA 3export HSA_OVERRIDE_GFX_VERSION11.0.0gfx1100 和 gfx1151 同属 RDNA 3 家族指令集基本一致只是显存控制器和 CU 数量配置不同用这个参数强制覆盖是完全安全的。为了永久生效我把它写进了/etc/environmentecho HSA_OVERRIDE_GFX_VERSION11.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.12ComfyUI 目前对 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/activate4.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 能访问 GPUHIP runtime 版本相互兼容即可。我在系统装 ROCm 6.3.2PyTorch 用 rocm6.2.4跑起来没有任何问题。二是不要用pip install torch默认的 CUDA 版本那会从 PyPI 拉取 CUDA wheel在 AMD 机器上直接报错。必须显式指定 index-url。三是在安装前先把 pip 升级到最新pip install --upgrade pip4.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, devicecuda) b torch.randn(1024, 1024, devicecuda) 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.txtComfyUI 的代码更新很快后续升级就两步cd /opt/comfyui/app git pull pip install -r requirements.txt5.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/comfyui5.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:81885.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 的模型目录结构是固定的不同模型要放到对应位置模型类型路径Checkpoint / 大模型models/checkpointsVAEmodels/vaeLoRAmodels/lorasControlNetmodels/controlnetEmbeddingmodels/embeddings我习惯把大模型放在/data/models下然后通过软链接到 ComfyUI 目录这样重装系统时模型不会丢mkdir -p /data/models/checkpoints ln -s /data/models/checkpoints /opt/comfyui/app/models/checkpoints6.2 SD1.5 / SDXL / FLUX 的实测体感以下是我在这台机器Ryzen AI Max 39596GB 统一内存16GB UMAUbuntu Server 24.04 ROCm 6.3上的实测数据仅供参考。不同批次步数、采样器、分辨率和模型变体都会有差异。模型分辨率步数实测速度显存占用SD1.5FP16512x512208~10 it/s3~4 GBSDXLFP161024x1024203~4 it/s7~9 GBFLUX.1FP81024x1024201.5~2.5 it/s10~12 GB用 SDXL 出一张 20 步的图大概 6~8 秒整体在可接受范围。FLUX 因为模型参数量大加上 FP8 量化出图速度明显偏慢但考虑到这是纯集显在跑已经超出我预期了。速度数据比同功耗的独立显卡比如 RTX 4060 Laptop略慢但优势是显存容量。传统 16GB 显存独显跑 FLUX 经常会撞墙而统一内存模式下只要系统物理内存够大ComfyUI 几乎不会被 OOM 打断。6.3 统一内存的甜点与陷阱统一内存最大的甜点是“显存不够内存来凑”。当你加载一个 12GB 的 FLUX 模型时ComfyUI 会认为可用的 GPU 显存 专用显存 可共享内存从而自动分配。但有个隐藏陷阱系统其他进程如果吃掉了大量物理内存GPU 能用的共享内存就会相应减少。比如你同时开着数据库、浏览器、文件服务16GB 专用显存加剩余 80GB 内存本来是富余的结果可用内存降到 30GBComfyUI 在加载大模型时反而可能 OOM。我的对策是给 ComfyUI 限制 CPU 内存占用或者干脆单独用一台机器跑 ComfyUI。如果你是 All-in-One 服务器建议至少留 32GB 以上内存给系统其他服务剩余全给 GPU 跑模型。7. 常见错误与排查从“节点执行错误”到 HIP OOM7.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这类问题大多是模型结构和采样器步数/降噪强度不匹配造成的。我的排查套路先看是哪个节点报错。KSampler 报错一般是模型或 latent 尺寸问题VAE Decode 报错一般是 VAE 缺失或版本不匹配。检查模型路径。确认 checkpoint 文件名存在且没有中文路径。检查内存。日志里有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/grubGRUB_CMDLINE_LINUX_DEFAULTamdgpu.gttsize32768然后sudo update-grub sudo rebootgttsize单位是 MB32768 即 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] DescriptionComfyUI Service Afternetwork.target [Service] Useryourname WorkingDirectory/opt/comfyui/app EnvironmentHSA_OVERRIDE_GFX_VERSION11.0.0 ExecStart/opt/comfyui/venv/bin/python main.py --listen 0.0.0.0 --port 8188 Restartalways RestartSec5 [Install] WantedBymulti-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 相关插件要求torch2.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 秒。
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~7GBFlux 系列甚至十几 GB系统盘和模型盘分开后续重装系统不影响模型。第三安装时在软件选择界面勾选 OpenSSH server。这一步很重要装完系统直接拔掉显示器键盘后面全程 SSH 操作。如果忘了勾选装完再补装也简单sudo apt update sudo apt install openssh-server sudo systemctl enable --now ssh2.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 更新内核。然后检查 KFDKernel Fusion Driver节点是否存在ls /dev/kfdROCm 和 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 --usecaserocm如果你不想走官方脚本也可以手动装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 模拟成同代已支持的 gfx1100RDNA 3export HSA_OVERRIDE_GFX_VERSION11.0.0gfx1100 和 gfx1151 同属 RDNA 3 家族指令集基本一致只是显存控制器和 CU 数量配置不同用这个参数强制覆盖是完全安全的。为了永久生效我把它写进了/etc/environmentecho HSA_OVERRIDE_GFX_VERSION11.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.12ComfyUI 目前对 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/activate4.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 能访问 GPUHIP runtime 版本相互兼容即可。我在系统装 ROCm 6.3.2PyTorch 用 rocm6.2.4跑起来没有任何问题。二是不要用pip install torch默认的 CUDA 版本那会从 PyPI 拉取 CUDA wheel在 AMD 机器上直接报错。必须显式指定 index-url。三是在安装前先把 pip 升级到最新pip install --upgrade pip4.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, devicecuda) b torch.randn(1024, 1024, devicecuda) 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.txtComfyUI 的代码更新很快后续升级就两步cd /opt/comfyui/app git pull pip install -r requirements.txt5.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/comfyui5.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:81885.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 的模型目录结构是固定的不同模型要放到对应位置模型类型路径Checkpoint / 大模型models/checkpointsVAEmodels/vaeLoRAmodels/lorasControlNetmodels/controlnetEmbeddingmodels/embeddings我习惯把大模型放在/data/models下然后通过软链接到 ComfyUI 目录这样重装系统时模型不会丢mkdir -p /data/models/checkpoints ln -s /data/models/checkpoints /opt/comfyui/app/models/checkpoints6.2 SD1.5 / SDXL / FLUX 的实测体感以下是我在这台机器Ryzen AI Max 39596GB 统一内存16GB UMAUbuntu Server 24.04 ROCm 6.3上的实测数据仅供参考。不同批次步数、采样器、分辨率和模型变体都会有差异。模型分辨率步数实测速度显存占用SD1.5FP16512x512208~10 it/s3~4 GBSDXLFP161024x1024203~4 it/s7~9 GBFLUX.1FP81024x1024201.5~2.5 it/s10~12 GB用 SDXL 出一张 20 步的图大概 6~8 秒整体在可接受范围。FLUX 因为模型参数量大加上 FP8 量化出图速度明显偏慢但考虑到这是纯集显在跑已经超出我预期了。速度数据比同功耗的独立显卡比如 RTX 4060 Laptop略慢但优势是显存容量。传统 16GB 显存独显跑 FLUX 经常会撞墙而统一内存模式下只要系统物理内存够大ComfyUI 几乎不会被 OOM 打断。6.3 统一内存的甜点与陷阱统一内存最大的甜点是“显存不够内存来凑”。当你加载一个 12GB 的 FLUX 模型时ComfyUI 会认为可用的 GPU 显存 专用显存 可共享内存从而自动分配。但有个隐藏陷阱系统其他进程如果吃掉了大量物理内存GPU 能用的共享内存就会相应减少。比如你同时开着数据库、浏览器、文件服务16GB 专用显存加剩余 80GB 内存本来是富余的结果可用内存降到 30GBComfyUI 在加载大模型时反而可能 OOM。我的对策是给 ComfyUI 限制 CPU 内存占用或者干脆单独用一台机器跑 ComfyUI。如果你是 All-in-One 服务器建议至少留 32GB 以上内存给系统其他服务剩余全给 GPU 跑模型。7. 常见错误与排查从“节点执行错误”到 HIP OOM7.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这类问题大多是模型结构和采样器步数/降噪强度不匹配造成的。我的排查套路先看是哪个节点报错。KSampler 报错一般是模型或 latent 尺寸问题VAE Decode 报错一般是 VAE 缺失或版本不匹配。检查模型路径。确认 checkpoint 文件名存在且没有中文路径。检查内存。日志里有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/grubGRUB_CMDLINE_LINUX_DEFAULTamdgpu.gttsize32768然后sudo update-grub sudo rebootgttsize单位是 MB32768 即 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] DescriptionComfyUI Service Afternetwork.target [Service] Useryourname WorkingDirectory/opt/comfyui/app EnvironmentHSA_OVERRIDE_GFX_VERSION11.0.0 ExecStart/opt/comfyui/venv/bin/python main.py --listen 0.0.0.0 --port 8188 Restartalways RestartSec5 [Install] WantedBymulti-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 相关插件要求torch2.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 秒。