【交作业】7900 XTX + ROCm + ComfyUI 调优小结

Fery Chen

️ 7900 XTX + ROCm + ComfyUI 调优小结

CachyOS (Arch) · 2026-07-27 · 从系统死机到跑通视频工作流

0. 序言

序言还是得自己写。其他都是Hermes帮我总结的。现在太懒了……
自从油管看老特的推荐，琢磨好久，还是选择了7900XTX。无他，比较适合自己。
买来后，重装了系统，用PikaOS（Debian Based），发现还是不习惯，用习惯CachyOS了，AUR太香了……又重装来折腾，毕竟坚信，都是Linux，来来去去都那样，翻不了天……
然后开始就翻车了，用机智罗的工作流，处理好节点后（刚开始就叫Hermes直接帮我看工作流JSON来解决，后面自己还是花了点时间看看），跑图片没问题，但是跑一次视频就OOM一次。最后发现，核心点是机智罗的小白工具箱分块加载能力没生效，OOM了。具体的说明在后面。

1. 本机配置

项目	值
OS	CachyOS (Arch Linux), kernel 7.1.4
GPU	AMD Radeon RX 7900 XTX (24GB VRAM, gfx1100, RDNA3)
CPU	Intel i5-13490F (31GB RAM)
ROCm	7.14.0
PyTorch	2.11.0+rocm7.14.0
ComfyUI	v0.28.0
Storage	NVMe 系统盘 + 数据盘 / NTFS 仓储盘
Shell	Fish 4.8 + Tide prompt / kitty + TokyoNight

2. Swap 的坑是如何解决的

问题：zram 死循环导致系统死机

最初只有 31GB zram（压缩内存 swap），配合 XB_ToolBox 的 Block Swap 把大模型块搬到系统内存后：

Block Swap 把 20+ GB 模型块从 GPU → CPU RAM
CPU RAM 压力大 → 内核把块换到 zram
zram 的压缩池本身也住在 RAM 里 → RAM 更少了
内核更激进地 swap → 死循环 → 系统卡死

关键认知： zram 不释放 RAM，它本身就是 RAM 的消费者，不适合大块 offload 场景。

解决：NVMe swapfile 作为主力溢出

组件	大小	优先级	作用
`/swapfile`	64 GB	`10`	主力溢出走 NVMe，零 RAM 竞争
`zram`	31 GB	`5`	轻量缓存，备胎

总 swap 可用 95 GB，Block Swap 的溢出全部走 NVMe，不再触发 zram 压缩池争抢 RAM。

# zram 配置：/etc/systemd/zram-generator.conf
[zram0]
compression-algorithm = zstd
zram-size = ram          # 恢复 1:1
swap-priority = 5        # 降优先级
fs-type = swap

3. 启动脚本优化

#!/bin/bash
cd "$HOME/ai-workspace/ComfyUI" || exit 1

# 文件描述符上限（防 Too many open files）
ulimit -n 65536 2>/dev/null

# ROCm 显存分配策略（防碎片化）
export PYTORCH_ALLOC_CONF="expandable_segments:True,\
garbage_collection_threshold:0.75,max_split_size_mb:512"

# ROCm MIOpen 修复（防 VAE Decode 黑屏 / 超时）
export MIOPEN_FIND_MODE=2

exec "$HOME/ai-workspace/venv/bin/python" main.py \
  --listen 127.0.0.1 --port 8188 --gpu-only \
  --cache-none \
  --disable-dynamic-vram

参数	作用
`PYTORCH_ALLOC_CONF`	可扩展显存段 + GC 阈值，减少碎片化导致的 OOM
`MIOPEN_FIND_MODE=2`	ROCm 下 VAE Decode 黑屏/超时的关键修复
`--cache-none`	禁用中间缓存，配合 Block Swap 防止残留张量占 VRAM
`--disable-dynamic-vram`	固定 HIGH_VRAM 模式，避免动态管理干扰 Block Swap

依赖修复

问题	解决
`huggingface_hub` 新版删了 `cached_download`	`diffusers` 0.27.2 → 0.39.0
`comfyui-workflow-templates` 缺失	`pip install -r requirements.txt`
CUDA tensor → numpy 报错（VideoHelperSuite）	audio_data 两处加 `.cpu()`
音频 NaN/Inf 导致 ffmpeg 崩溃	加 `np.nan_to_num()` 过滤
SageAttention 上游版 WMMA bug	切到 `guinmoon/SageAttention-Rocm7`

4. 工作流现状

我使用的是 B站机智罗大神的工作流跑通，刘悦大神工作流暂时未跑通。出图基本没问题，跑视频目前还在继续摸索。

工作流	作者	状态
LTX 图生视频	机智罗（B站）	跑通
LTX 工作流	刘悦（B站）	暂未跑通

下一步方向：调优分辨率/步数/CFG 参数提升视频质量，以及适配刘悦大神的工作流。

5. 附带一些截图

7900 XTX + ROCm + ComfyUI 调优记 · 2026-07-27

terry

非常好的分享，其实任何教程到真正部署到时候都会有意外发生，因为大家的环境各不相同，就是要一个明确信号，它能跑起来，大多数人就能坚持下去。你的很多问题我从为遇到过，但是我部署N卡的时候，有些问题其他人也没遇到过。分享出来，有类似问题的人的就能找着抄作业。

Fery Chen

RX 7900 XTX + ROCm 跑 LTX-2.3 视频折腾全记录（附能跑通的配置）

折腾了差不多一周，从花屏、黑图、卡死、OOM 杀桌面一路趟过来，终于让 LTX-2.3 在 A 卡上稳定出片了。把踩的坑和最终配方写下来，希望帮同样在 ROCm 上挣扎的朋友少走点弯路。

我的配置

项	配置
GPU	AMD Radeon RX 7900 XTX（24GB，gfx1100/RDNA3）
驱动/计算栈	ROCm 7.2.4
PyTorch	2.11.0+rocm7.2（关键，下面说）
系统	CachyOS（Arch 系），btrfs
CPU/内存	i5-13490F / 32GB 内存
ComfyUI	v0.29.0 + 几个本地补丁
工作流	LTX-2.3 22B AV（首尾帧视频、图生视频，GGUF Q4_K_M）

一、先说结论（太长不看版）

稳定组合 = LTS 内核 + PyTorch 2.11 + 下面那套启动参数。 记住这三样，剩下的都是细节。

内核：用 LTS（别用最新的 7.x）。
PyTorch：用 2.11（别用 2.12）。
TunableOp：关掉（花屏元凶，暂时我这里是……）。
注意力：用 --use-pytorch-cross-attention，别开 flash。
第一次跑会崩，当暖机，再跑一次就稳。

二、内核选择：一定要 LTS

这是最先踩的坑。最新的 7.x 内核（CachyOS 滚的）在重 ROCm 负载下，amdgpu 驱动会触发：

Memory access fault by GPU node-1 ... Reason: Page not present or supervisor privilege.
Fatal Python error: Aborted

直接 SIGABRT 退出。看内核日志就是一堆 [gfxhub] page fault。切到 LTS 内核（cachyos-lts）这个崩法就消失了。 所以开机 GRUB 永远选 LTS，别手贱升最新。

怎么判断是不是这个坑：崩之前日志里如果有 Memory access fault ... Page not present，基本就是新内核 amdgpu 的锅，换 LTS。

三、ComfyUI 升级 + 打补丁

直接 git pull 升到 v0.29.0 就行。但有几个坑上游还没修，得自己打本地补丁（补丁我存在仓库的 scripts/ 下，提交进了 git，pull 后重新 git apply 即可）。

补丁 1：pin_memory 预算修复（对应 GitHub #14525 / issue #13730）

症状：加载大模型时卡死在 Requested to load LTXAV，一动不动。
原因：AMD 上 pinned memory（锁页内存）会被无限注册直到把主机内存撑爆。上游 #14525 加了预算检查但至今没合并，#13730 那个 issue 还开着。
修法：本地把 comfy/model_management.py 的 pin_memory() 改成先检查预算：

# 改之前(裸调用,会卡死):
ensure_pin_registerable(size)
# 改之后(检查预算,失败就回退到普通内存):
if not ensure_pin_budget(size) or not ensure_pin_registerable(size):
    return False

补丁 2：SaveVideo 音频 NaN 修复（对应 #13192 / #14617）

症状：视频采样完了，最后存盘时报 avcodec_send_frame() returned 22（EINVAL），视频存不出来。
原因：音频波形里有 NaN/±Inf，ffmpeg 的 AAC 编码器直接拒绝。
修法：在 video_types.py 存盘前 np.nan_to_num 清洗 + try/except 兜底（音频实在编不了就存无声视频）。

这两个补丁上游都还没合，所以每次 git pull 升级 ComfyUI 都要重新打一遍，否则老问题又回来。

四、启动参数调优（最核心的一段）

这部分我反复调了好几天，直接给结论。下面这套是我实测能跑通的：

# 环境变量
export TORCH_BLAS_PREFER_HIPBLASLT=1
export COMFYUI_ENABLE_MIOPEN=1
export MIOPEN_FIND_MODE=FAST
export PYTORCH_CUDA_ALLOC_CONF="expandable_segments:True,garbage_collection_threshold:0.7,max_split_size_mb:512"
export HSA_ENABLE_SDMA=0
# ⚠️ 切勿开启 PYTORCH_TUNABLEOP_ENABLED,会花屏!

python main.py \
  --use-pytorch-cross-attention \
  --disable-async-offload \
  --disable-dynamic-vram \
  --cache-none \
  --reserve-vram 4.0 \
  --enable-cors-header --preview-method auto --port 8188

每个 flag 为什么这么选

参数	为什么
`--use-pytorch-cross-attention`	ROCm 原生 SDPA，稳定。flash 和 quad 都试过，不稳（见第五节）。
`--disable-dynamic-vram`	必须留！关掉它才走 lowvram 逐层流式，22B 模型才塞得进 24G 显存。去掉会卡死。
`--disable-async-offload`	显存策略配套，留着。
`--reserve-vram 4.0`	单卡带显示，给桌面留点显存，不然 VRAM 峰值一来直接杀桌面。(其实实测，只要RAM内存太小，还是会杀桌面，峰值来了，不稳定)
`--cache-none`	排查期最干净，每次重算。
不开 `--disable-smart-memory`	让 smart memory 开着，文本编码器(Gemma)用完会自动释放，腾内存给后面的大模型加载。（0.29更新后，似乎有用了）
不开 `--disable-pinned-memory`	让 pinning 开着，CPUGPU 搬运快（配合上面的 #14525 补丁已经安全）。

️ PYTORCH_TUNABLEOP_ENABLED 千万别开！它会自动挑"最快"的核但不校验正确性，在 gfx1100 上挑到错核 → 全局花屏/黑图（连最简单的 SD1.5 文生图都崩）。这是花屏的真正元凶，我追了半天。

五、Flash Attention vs PyTorch Attention

这俩我都测试过，但是效果没多大感觉和区别：

Flash Attention（--use-flash-attention）：我编译装了 flash_attn 2.8.4（ROCm/Triton 后端），这个稳定性存疑，要多测试。
PyTorch Cross Attention（--use-pytorch-cross-attention）：ROCm 原生 SDPA，稳，画质无损。就用这个。
SageAttention：这个版本太低了，不活跃，不如用原生的。

一句话：A 卡上老老实实用 --use-pytorch-cross-attention，速度够，稳定性最好。

六、显存内存峰值：24G，内存32G，卡的天花板（这是最无奈的部分）

我用监控实测过，LTX-2.3 的 AV（音视频）工作流在"采样后合成"那一瞬间，显存峰值能冲到 23.82G / 24G——只剩 ~180MB 余量。这就是一切不稳定的总根源：

单卡同时干显示 + 计算，桌面合成器、鼠标、浏览器都要吃显存；
那 180MB 够不够显示用 → 全凭运气：有时候够（出片成功），有时候差一点（OOM 杀桌面 / GPU fault / 花屏）。
--reserve-vram 4.0 在这个峰值点也没完全守住，ComfyUI 照样冲到 23.82G。

** 最佳还是用64GB内存，32GB内存要生成视频，一定要控制视频的块以及视频的分辨率，长度，不然卡在内存里面，就跟死了没两样 **

怎么把成功率拉到最高（但拉不到 100%）

跑之前关掉所有吃显存的程序：GPU 加速的终端（Kitty/Alacritty 那种）、开了硬件加速的浏览器都关，换成软渲染终端 + 轻浏览器。腾出来的显存就是你的活路。
第一次跑当暖机：刚启动 ComfyUI 的第一次跑基本会崩（冷加载 ~45G 模型 + 核 JIT 编译 + 内存碎片，把峰值顶穿）。崩了别管，直接再跑一次——第 2 次起模型进了缓存（ComfyUI 缓存 + 系统页缓存），复用、稳定出片。这是我的标准操作了。
崩过之后重启电脑清干净状态，别在脏环境上硬重试。
有一点估计是我看不仔细，就是很多人的7900XTX, 不跑桌面任务，单纯用来跑视频的。所以也就是很多人用SSH到另一台机器跑的缘故，可以节约1GB的显存 ————》机智罗的工作环境，他本地内存64GB, 而且他是Windows内，用核显跑桌面，显卡是专用跑AI的！

老实讲：一个峰值 23.82G 的工作流在 24G 单卡（还带显示）上，天生就是走钢丝。想 100% 稳，要么降峰值（分辨率/帧数/AI 模型），要么换更大显存的卡。在我这套硬件上，能跑通，但不是每次都通——这是物理上限，不是参数没调好。

七、关于 swap / zram（顺手提一下）

32G 内存跑 ~45G 模型，必然要 swap。我把 swap 调成了：

zram 16G（优先级 100）：压缩内存，速度快，优先用；
磁盘 swap 32G（优先级 10）：兜底。

注意 zram 别开太大（我一开始开 31G 反而吃光内存），16G（约内存的一半）是甜点。btrfs 上的 swap 文件要用 btrfs filesystem mkswapfile 建（普通 fallocate 会被 swapon 拒绝，EINVAL）。

我推翻了我原来认为ZRAM的问题。因为说到底，是我没设置好。而且机器内存真的不够。

还有就是：ComfyUI对Linux的Swap真的不会去调用的。Windows内可以开虚拟显存，在Linux内我还在找办法。

八、PyTorch 版本：为什么是 2.11

我测了 2.11 / 2.12 / 2.13 三个版本：

版本	表现
2.11	稳，能完整跑通（就这个）
2.12	卡在 LTXAV 加载，过不去
2.13	没充分验证，不敢用

所以锁定 2.11。我的三个 venv 是 venv(2.13) / pt-2.12 / pt-2.11，启动器里永远选 pt-2.11。

九、几个"吓人但不是坏事"的现象

首次启动第一张图黑：ROCm 内核 JIT 冷启动，第二张就正常。无害。
跑完任务后屏幕花屏闪烁：基本是崩过之后 amdgpu 的脏状态残留，重启就好。判别：重启后消失 = 没事；BIOS 界面也花 = 才需要担心硬件。我查过内核日志，那些 fault 都是 ComfyUI 进程的权限错误（软件问题），GPU reset 次数为 0，硬件没坏。
换工作流报 VideoVAE has no attribute ...：大概率是 VAE 模型选错了（我就犯过），检查一下加载的 VAE 文件对不对。

十、为什么 N 卡 8G 能跑，我这 24G A 卡这么费劲？

不是 8G > 24G。是 ComfyUI 那套"显存不够就从内存流式喂"的机制，在 CUDA 上又快又顺，在 ROCm 上又慢又糙。N 卡的锁页内存和 CPUGPU 传输很快，GPU 一直被喂饱；A 卡这条传输路径慢一截，GPU 经常饿着（利用率掉到 3%、卡住）。再加上 ROCm 生态对 ComfyUI 这种动态搬权重的场景成熟度不如 CUDA，坑就多。

但结局不差：24G 显存比 8G 大，配对了之后能常驻的权重更多，理论上比 8G N 卡还快——只是路更颠。A 卡性价比是实打实的，没买错。

附：我的完整启动脚本片段

#!/bin/bash
# ROCm 环境变量
export TORCH_BLAS_PREFER_HIPBLASLT=1
export COMFYUI_ENABLE_MIOPEN=1
export MIOPEN_FIND_MODE=FAST
export MIOPEN_USER_DB_PATH="$HOME/.cache/miopen"
export PYTORCH_CUDA_ALLOC_CONF="expandable_segments:True,garbage_collection_threshold:0.7,max_split_size_mb:512"
export HSA_ENABLE_SDMA=0
# PYTORCH_TUNABLEOP_ENABLED 不设(=关)

python main.py \
  --use-pytorch-cross-attention \
  --disable-async-offload \
  --disable-dynamic-vram \
  --cache-none \
  --reserve-vram 4.0 \
  --disable-api-nodes \
  --enable-cors-header \
  --preview-method auto \
  --port 8188

TL;DR

LTS 内核 + PyTorch 2.11 是稳定基线，别用最新的。
#14525 和 SaveVideo 两个补丁自己打，上游没合。
TunableOp 关掉，用 pytorch-cross-attention，否则花屏。
--disable-dynamic-vram 必须留（lowvram 流式），smart memory 留开（自动释放）。
峰值 23.82G 是天花板，第一次跑当暖机，关掉别的吃显存程序，崩了重启再来。
A 卡跑 ComfyUI 路是颠，但能跑通，性价比还是香的。
A 卡出一个大视频，低内存就别想了，还是老老实实做脚本，一段一段来吧。

最后，未来在继续尝试折腾看看。过阵子看看内存，上64G试试咸淡……

有问题欢迎在帖子里交流，我能帮的都答。祝大家的 7900 XTX 都能稳定出片

附带B站黑鹤001的工作流，我用这个测试的：

LTX23-首尾帧视频(双图).json

——————————————————————————
以下是机智罗的Wan2.1工作流测试图生视频。但是不知道为啥一次比一次慢
机智罗wan工作流冷.png
机智罗wan-越来越慢.png

——————————————————
以下是内存爆满卡死的情况：
内存爆满崩坏.png

exe127

妥妥的乾貨. 必須留個名. 感謝你的分享呀! 我也是7900xtx+32GB內存. 今個星期實戰一下

terry

妥妥的干货分享，精品，非常适合A卡用户入门

Fery Chen

@exe127 我找到了一条8g的ddr4..怼上去多了一丝丝的余量……其实还是最少48G比较好

Fery Chen

minimax-h3文生图.png

A卡可以玩一下Minimax H3 的文生视频, 但是因为ROCm的动态内存调度不理想，所以很慢……

minimax-h3-参考生图-失败.png

我测试图生视频（参考生视频），因为我内存不够，ROCm的内存交换太渣，卡了好久，不想等下去了……

希望有好的配置的人试试。

感觉这玩意的效果还是挺好的。

terry

H3发布了吗？？？xtx都能玩？

Fery Chen

@terry 老特你有64G内存吧？你试试跑跑看。升级ComfyUI到最新版本，有官方的实例工作流。支持int8模型，可以跑试试。就是慢。我文生图跑通了，速度还可以。

但是图生视频，我的内存不够，A卡调度老是出问题，容易爆。B站很多人都出视频介绍了。我关注萝卜的，他的工作流也挺有意思。

terry

今天没空，得明后天才有时间，效果如何？值得玩玩就去弄下。

Fery Chen

@terry 惊艳，可以看看下面的对比：

另外，我发现B站刘悦也有更新这个工作流了。都赶着来了

Miraco

谢谢分享！机智罗的工作流可以直接搬到Linux吗？能否具体分享一下过程。谢谢。

linkdesu

干货，我也是听老特的入了 7900XTX 来做视频，因为是放身边的游戏主机先尝尝咸淡，所以最后还是吧安静放在了第二位，第一位当然是能跑，结果就是今天收到显卡后发现真的好安静。而且 H3 今天也很顺利跑起来了，我因为是兼顾玩游戏用的 windows 系统，所以直接上机智罗老师的整合包非常方便，也是要感谢老特的分享

Xiaote

@Miraco 补充下：工作流 json 文件本身是跨平台的，直接搬没问题，但机智罗整合包是 Windows 一键包（bat 启动 + 内置 Python 环境），Linux 上要自己重建环境。大致步骤：

装 ComfyUI：官方版或 git 拉最新，Python 3.11/3.12 + torch。A 卡用 ROCm 版 torch——本贴楼主就是 7900 XTX + ROCm 跑通的，说明 LTX 系列工作流在 Linux/ROCm 下完全可行。
装 ComfyUI-Manager，把下载的 json 拖进界面，缺失的自定义节点会自动列出来一键安装（LTX 相关的是 ComfyUI-LTXVideo，GGUF 量化节点是 ComfyUI-GGUF 等）。
模型文件要自己放进 models 对应目录；整合包里有些节点路径是 Windows 格式写死的，跑之前检查一下节点里的路径和文件名。
显存小的机器启动加 --lowvram 分段加载，跑长视频工作流不容易爆显存。

其实整合包的核心就是"ComfyUI + 常用节点 + 模型 + 工作流 json"，Linux 上最费时间的反而是把模型和自定义节点找齐，json 本身半小时内就能跑起来。

Fery Chen

@Miraco 在Windows或者虚拟机内，用机智罗的起动器，解压他的整合包。具体解压哪个你自己去看他的视频。解压后，有用的就几样内容：

工作流（JSON）
custom_node（节点）
模型

拷贝到Linux内，你让 Hermes等Agent, 帮你把节点迁移进去，模型放进去，它自己会搞。你让它迁移工作流的时候，跟它说，让它把windows的字符格式转linux的，例如Windows路径用""， Linux用"/"，它自己会搞。

搞完你叫它跑一个测试流程就知道了。不难

imbiplaza ASUS

所以当初我选择32gb vram + 96gb 是对的。。。。宁可多，也不要承担oom的风险，总括来说，我还没开跑comfyui之前，vram已经被占用chrome 1g, 其他py 2g, 还有premier pro, photoshop ,

exe127

@Fery-Chen 後續不知會不會有H3對7900xtx的優化, 可以跑快一點呢

Fery Chen

@exe127 有人在做int4模型，用这种应该可以好一些。现在也有不少人在开始做有损加速，但是还是再等等吧……我在等有64G内存的人测试一下……

exe127

@Fery-Chen 以我認知, 7900xtx 只支持FP16, FP8, INT8. INT4就已經不支持了, 如果出INT4的版本, 7900xtx 應該跑不了嗎? 會很慢

terry

@exe127 7900xtx支持INT4，另外INT4是模型权重，不是推理指令，推理还是FP8，BF16，FP32。

抡锤者