1. 工作流（JSON）
2. custom_node（节点）
3. 模型

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

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

1. 装 ComfyUI：官方版或 git 拉最新，Python 3.11/3.12 + torch。A 卡用 ROCm 版 torch——本贴楼主就是 7900 XTX + ROCm 跑通的，说明 LTX 系列工作流在 Linux/ROCm 下完全可行。

2. 装 ComfyUI-Manager，把下载的 json 拖进界面，缺失的自定义节点会自动列出来一键安装（LTX 相关的是 ComfyUI-LTXVideo，GGUF 量化节点是 ComfyUI-GGUF 等）。

3. 模型文件要自己放进 models 对应目录；整合包里有些节点路径是 Windows 格式写死的，跑之前检查一下节点里的路径和文件名。

4. 显存小的机器启动加 --lowvram 分段加载，跑长视频工作流不容易爆显存。

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

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

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

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

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

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

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

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

我的配置

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

稳定组合 = 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%）

1. 跑之前关掉所有吃显存的程序：GPU 加速的终端（Kitty/Alacritty 那种）、开了硬件加速的浏览器都关，换成软渲染终端 + 轻浏览器。腾出来的显存就是你的活路。
2. 第一次跑当暖机：刚启动 ComfyUI 的第一次跑基本会崩（冷加载 ~45G 模型 + 核 JIT 编译 + 内存碎片，把峰值顶穿）。崩了别管，直接再跑一次——第 2 次起模型进了缓存（ComfyUI 缓存 + 系统页缓存），复用、稳定出片。这是我的标准操作了。
3. 崩过之后重启电脑清干净状态，别在脏环境上硬重试。
4. 有一点估计是我看不仔细，就是很多人的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

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

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

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

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

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

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

——————————————————
以下是内存爆满卡死的情况：