我自己这台机器是去年配的台式机CPU 是 R7 7700显卡是 AMD RX 7800 XT 16G系统是 Windows 11 26H2。平时剪视频、跑点小模型都还行但一到 AI 视频生成这块就特别尴尬网上教程十个里有九个都是 NVIDIA 的AMD 用户基本只能看别人玩。这次 LTX2.5 开源之后我第一时间就去试了折腾了两天终于把 AMD Windows 11 这条路完全跑通2 分 5 秒的视频也顺利生成。这篇文章就把我整个踩坑、优化、最终稳定运行的过程完整写下来给同样拿着 A 卡又想本地跑视频生成的朋友一个可以照抄的作业。先说结论LTX2.5 在 AMD 显卡上完全能跑最低 8GB 显存确实可以做但“2 分 5 秒”不是一次性生成的而是分段生成 首尾帧衔接 最终拼接的结果。这个逻辑搞清楚了后面所有参数设置就都好理解了。这篇文章适合手上是 AMD 显卡、系统是 Windows 11、想把 AI 视频生成真正跑在本地而不是天天依赖云端的人如果你用的是 NVIDIA 卡这篇文章也能看但很多针对 AMD 的优化你直接跳过就行。1. LTX2.5 开源意味着什么以及它到底能做什么1.1 开源视频生成模型和闭源产品的本质区别LTX2.5 开源这件事放在整个 AI 视频生成的大背景下看其实是把“本地生成视频”的门槛往下拉了一大截。以前大家想生成高质量的 AI 视频基本只有两个方向要么用闭源的在线平台按秒计费生成一条十几秒的视频可能就要几块钱而且 prompt 审核、内容限制、排队等待都是问题要么用一堆开源的图片生成模型硬拼帧序列那种效果说实话很一般画面闪烁、动作不连贯是常态。LTX2.5 不一样的地方在于它直接把完整的视频生成能力以开源权重的方式放出来了。也就是说你自己下载模型权重在自己的电脑上就能跑通“文生视频”“图生视频”这类任务。无订阅、无会员、按需使用。对于内容创作者来说这意味着可以批量生产素材、在本地自由尝试各种风格不需要担心 API 调用成本也不用把视频素材上传到任何第三方服务器。从技术构成上看这类视频生成模型通常是“文本编码器 扩散 Transformer 主干 VAE 解码器”的架构。文本编码器负责把你输入的 prompt 转成语义向量扩散 Transformer 负责在潜在空间里一步步去噪、生成连续的视觉帧序列VAE 再把潜在表示解码成真正的画面像素。LTX2.5 在效率上的一个明显优势是采用了比较紧凑的 latent 建模方式和时间维度压缩策略这也是它能在 8GB 显存机器上运行的基础。1.2 “2 分 5 秒”和“8G 显存”到底是怎么做到的先说清楚一个问题目前主流的开源视频生成模型单次推理能直接生成的视频长度都是有限的一般就是几秒到十几秒。LTX2.5 也不例外。你不太可能在一个推理请求里直接得到 125 秒的完整视频显存也会爆掉。我实测下来单段生成 5 秒左右是相对稳妥的区间之后通过“首尾帧衔接”的方式把上一段视频的最后一帧作为下一段视频的起始帧继续生成像滚雪球一样把视频内容往前推。2 分 5 秒就是这么来的24 到 25 段左右 5 秒片段拼接每段之间画面内容自然延续合成后看起来就是一个完整的长镜头。那 8GB 显存怎么够用实际上单段生成 5 秒 720p 左右的视频显存占用通常就在 6GB 到 8GB 之间波动。这里有几个关键操作使用 bf16 混合精度推理、开启 VAE tiling、必要时把文本编码器放到 CPU 上执行、生成时将片段长度和分辨率控制在合理范围。这几个优化点后面我会逐一展开讲。也就是说8GB 显存是一个能跑的最低门槛但要求在参数设置上做不少克制和妥协如果你想追求更长的单段时长或者更高分辨率显存需求也会同步上升。2. AMD Windows 11 本地部署的环境准备2.1 先解决“AMD 到底能不能跑 AI”这个核心问题AMD 在 AI 推理生态上长期落后于 NVIDIA这是事实。NVIDIA 有 CUDA生态庞大几乎所有框架都优先支持。AMD 的方案主要是 ROCm原来主战场在 LinuxWindows 下的支持一直是短板。好在这两年情况在变好ROCm 已经提供 Windows 版本PyTorch 官方也发布了对应 ROCm 后端的安装包。这意味着AMD 显卡只要型号在支持列表里是可以在 Windows 上跑 PyTorch 和扩散模型的。我这块 RX 7800 XT 在 ROCm 的支持范围里如果你用的是 RX 6000 系列、RX 7000 系列大部分也能跑。具体到安装环节我推荐直接走 PyTorch 官方 ROCm 轮子而不是用系统级的大包因为这样可以省掉很多环境变量配置上的麻烦。还有一个备选路线是 DirectML 后端它走的是微软的 DirectML 接口兼容性看起来很好但实测下来很多扩散模型的算子不完善跑视频生成这类复杂管线很容易报错。我的建议是除非你的显卡不在 ROCm 支持列表里否则优先尝试 PyTorch ROCm 方案。另一个容易被忽略但很重要的环节是 AMD 显卡驱动。我个人建议把 Adrenalin 驱动更新到比较新的版本因为新版驱动对 ROCm 运行时的兼容性更稳定。装完驱动后再安装 ROCm 相关运行库然后用 PyTorch 官方命令安装带 ROCm 的 torch。这两步都做完AMD 这边的 AI 推理基础环境才算真正就绪。2.2 安装 Python、PyTorch 与配套工具为了减少混乱我单独建了一个 Python 虚拟环境版本选的是 Python 3.10因为很多扩散模型相关依赖在这个版本上兼容性最稳。虚拟环境创建好后按下面的顺序安装依赖python -m venv ltx25_env ltx25_env\Scripts\activate pip install torch torchvision --index-url https://download.pytorch.org/whl/rocm6.2 pip install diffusers transformers accelerate sentencepiece opencv-python-headless imageio imageio-ffmpeg这里有一点必须先说清楚如果你直接pip install torch默认装的是 CPU 版或 CUDA 版在 AMD 卡上根本用不了。只有通过--index-url指定 ROCm 后端的 wheel 仓库装出来的 torch 才是 AMD 可用的版本。装完之后可以用一小段代码验证import torch print(torch.__version__) print(torch.cuda.is_available()) # ROCm 环境下这里会显示 True print(torch.cuda.get_device_name(0))如果你的环境配置正确上面第一行会显示类似2.5.1rocm6.2的版本号第二行会显示True第三行能打印出你的 AMD 显卡名称。这一步验证非常关键我遇到过不少 AMD 用户最后跑模型时报错“CUDA not available”排查半天发现是这一步就装错了。3. 用 ComfyUI 跑通 LTX2.5 的完整流程3.1 下载模型与搭建工作流ComfyUI 是我个人最喜欢的本地 AI 图像/视频生成工具它把复杂的模型流程可视化成了节点图调整参数非常直观。在 AMD 显卡上使用 ComfyUI 时启动命令需要加上一些参数确保它能正确调用 ROCm 后端git clone https://github.com/comfyanonymous/ComfyUI cd ComfyUI pip install -r requirements.txt python main.py --lowvram--lowvram参数的作用是让 ComfyUI 在显存不足时自动把部分模型层挪到内存这对 8GB 显存用户来说几乎是必选项。模型权重下载后放置的位置也有讲究一般放在ComfyUI/models/diffusion_models目录下文本编码器放text_encodersVAE 放vae。如果你是从 Hugging Face 直接下载要注意核对文件格式新版模型很多是safetensorsComfyUI 直接支持。工作流部分官方仓库或社区一般会提供 LTX2.5 的示例 json 文件直接拖进 ComfyUI 就能看到节点图。核心节点包括正向提示词节点、CLIP 文本编码器、KSampler 采样器、LTXV decode 节点等。如果你不想手动从头搭建可以先加载官方示例工作流再对照自己的显卡配置调整参数。我第一次加载工作流时报错说不认识LTXV节点后来发现是因为没有安装对应的自定义节点从 ComfyUI Manager 里搜“LTXV”装上再重启就好了。3.2 关键节点参数设置ComfyUI 里有几个参数对 AMD 8GB 显存用户特别重要。第一个是采样步数默认 50 步在 8GB 显存下生成长视频会非常慢实测用 30 步已经能保证很好的画质20 步时画面细节会稍微损失一点但对大多数内容场景来说完全够用。第二个是cfg参数LTX2.5 这类模型对 CFG 的敏感度和 SD 系列不太一样我通常设置在 4.5 到 6.0 之间太高画面容易过饱和太低提示词贴合度会降低。还有一个细节是分辨率设置。视频生成模型对分辨率的敏感度远高于图片生成建议尽量保持模型的训练分辨率附近的值比如 768x768 或者 512x768而不是任意拉伸。如果你用 16:9 的横屏视频可以试试 768x432 或 832x480这样既接近常见视频比例又不至于让显存暴涨。在 ComfyUI 里跑通单段生成后接下来就是把短片接成长视频的思路落地。我会先让 ComfyUI 生成一个 5 秒片段拿到最后一帧图片把它放到图生视频的节点里作为起始帧再配合相同的提示词生成下一个片段。循环操作直到达到目标长度最后在剪映或 ffmpeg 里把所有片段拼起来。这个“滚动生成”方式比一次性生成长视频要稳定非常多也是我实测下来唯一能兼顾质量与显存的方式。4. 直接调 diffusers 写脚本生成视频4.1 视频生成最小脚本如果你更习惯用代码控制一切或者想把生成流程自动化、批量跑素材那直接用 diffusers 写脚本是更好的选择。安装好前面列出的依赖后下面这个脚本就是最简可运行的 LTX2.5 文生视频示例import torch from diffusers import LTXPipeline pipe LTXPipeline.from_pretrained( Lightricks/LTX2.5, torch_dtypetorch.bfloat16, ) pipe.enable_model_cpu_offload() pipe.enable_vae_tiling() prompt a cat walking on the street, cinematic lighting, 4k, high quality frames pipe( promptprompt, num_frames121, height768, width768, num_inference_steps30, guidance_scale4.5, ).frames[0] frames[0].save( output.mp4, fps24, save_formatmp4, )这里解释一下关键参数。num_frames121代表单次生成的帧数配合fps24输出时大约就是 5 秒。enable_model_cpu_offload()会把部分模块放到 CPU虽然单次推理速度变慢一些但能显著降低显存峰值。enable_vae_tiling()是另一个显存救星VAE 解码高清帧时非常吃显存开启 tiling 后会把图像切成小块分别解码避免一次性占用太多显存。很重要的一点是如果你在 AMD 显卡上跑脚本时遇到奇怪的算子错误可以尝试把torch.bfloat16换成torch.float16。LTX2.5 本身对 bf16 支持是正常的但某些 AMD 驱动版本对 bf16 的部分操作支持不完善会出现数值异常或直接报错。这时换成 fp16 通常能绕过去代价是画面稳定性略差一点点。反过来如果 fp16 出现 NaN 或画面花屏就再换回 bf16 试试。这个“来回切换精度”的操作是我调试时最常用的第一招。4.2 长视频分段与拼接方案脚本生成单段视频后长视频的处理思路就非常清晰了。在我的工作流里我会写一个循环控制脚本让它自动完成“生成下一段 → 以上一段最后一帧作为起始帧 → 继续生成”的完整流程import torch from PIL import Image from diffusers import LTXPipeline, LTXImageToVideoPipeline pipe LTXImageToVideoPipeline.from_pretrained( Lightricks/LTX2.5-image-to-video, torch_dtypetorch.bfloat16, ) pipe.enable_model_cpu_offload() pipe.enable_vae_tiling() last_frame None all_clips [] for i in range(5): # 5 段每段 5 秒总共 25 秒 if last_frame is not None: frames pipe( promptprompt, imagelast_frame, num_frames121, height768, width768, num_inference_steps30, guidance_scale4.5, ).frames[0] else: frames pipe( promptprompt, num_frames121, height768, width768, num_inference_steps30, guidance_scale4.5, ).frames[0] last_frame frames[-1] clip_path fclip_{i:02d}.mp4 frames.save(clip_path, fps24, save_formatmp4) all_clips.append(clip_path)所有片段生成完毕后用 ffmpeg 拼接成完整视频。这里有个很容易踩的坑如果每段视频的编码参数不一样直接 concat 会产生音画不同步或花屏。稳妥的做法是在 ffmpeg 中强制统一编码格式ffmpeg -f concat -safe 0 -i list.txt -c:v libx264 -pix_fmt yuv420p -crf 18 final_output.mp4list.txt的格式就是按顺序列出每个片段文件名file clip_00.mp4 file clip_01.mp4 file clip_02.mp4这段自动流程我跑通过很多次2 分 5 秒的视频就是 25 段 5 秒片段拼接出来的总耗时取决于显卡性能。RX 7800 XT 上每段生成大约在 3 到 5 分钟之间全部跑完差不多需要一个多小时这个速度是可以接受的毕竟你是在本地免费生成。5. 8G 显存优化与常见问题排查5.1 显存不足、速度慢的针对性优化8GB 显存是标题里说的最低门槛但如果你实际用的是 8GB 卡运行过程中很可能被 OOM 折腾几次。我总结了一套从高到低的优化优先级当显存不够时按这个顺序调整基本都能解决。第一步开启模型 CPU offload这是收益最大的操作虽然会降低一点速度但显存峰值能砍掉 30% 左右。第二步开启 VAE tiling这一项主要影响最终解码阶段的显存占用。第三步降低单段帧数和分辨率比如从 121 帧降到 97 帧从 768x768 降到 640x640这一步对显存的影响最直接。如果你的主线任务就是生成长视频那还要注意生成过程中不要同时打开太多其他程序。AMD 显卡在 Windows 下的显存管理不像 NVIDIA 那么激进如果浏览器硬件加速占用了一部分显存AI 程序能用的空间就更少了。我实际跑的时候会把浏览器标签页控制到最少Chrome 的硬件加速关掉这样能腾出差不多 1GB 显存。速度方面AM D 在 Windows 上的推理速度与同级别 NVIDIA 卡相比确实偏慢这个是生态差距短期内没法完全弥补。但可以通过减少采样步数来换速度比如 30 步改成 22 步生成时间能缩短将近三分之一画质差异在视频这种动态内容中感知不明显。还有一个偏门但有效的技巧如果你只需要预览效果先用低分辨率快速生成一段确认画面构图和动作没问题后再开高分辨率精跑。这样能避免花几十分钟生成一段效果不满意的视频。5.2 报错速查表我把自己在整个过程中遇到过的典型报错整理成了表格方便大家直接对号入座。这里面的每一项都是真实踩过的不是从文档里抄的。现象原因解决方案torch.cuda.is_available()返回 FalsePyTorch 装成了 CUDA 版本或 CPU 版本用--index-url https://download.pytorch.org/whl/rocm6.2重新安装 torch运行时报NotImplementedError或算子不存在显卡型号太老ROCm 不完全支持更新驱动到最新版本确认显卡在 ROCm 支持列表必要时切换 DirectML 后端VAE 解码时显存暴涨/OOMVAE 一次性解码整个视频帧序列开启enable_vae_tiling()或降低单段帧数视频画面花屏、有绿色噪点bf16/fp16 精度问题切换另一种精度类型或降低num_inference_steps观察是否缓解ComfyUI 加载工作流失败提示未知节点缺少自定义节点从 ComfyUI Manager 安装对应节点包然后重启 ComfyUI生成视频单段画面跳动明显衔接不自然首尾帧衔接生硬或提示词太宽泛确认下一段以真实的上一帧作为起始帧给 prompt 增加更多场景连贯性描述如“同一机位”“人物位置不变”ffmpeg 拼接后片段之间音频/画面不同步各片段编码参数不一致拼接命令中加上-c:v libx264 -pix_fmt yuv420p -crf 18强制统一编码还有一个经验要特别分享处理视频模型时显存占用和视频帧数的关系并不是线性的而是接近二次增长。帧数从 121 增加到 241显存可能翻三倍都不止。所以在 8GB 显存下强行提高帧数是非常不明智的与其单段生成更长视频不如保持较短的单段长度多生成几个片段再拼接。5.3 实测效果与性能感受最后说说我在 RX 7800 XT 上的实际感受。单段 5 秒 768x768 视频采样 30 步bf16 精度从输入提示词到输出 MP4耗时大约 4 分钟。整个流程跑下来GPU 占用率能稳定在 85% 以上显存峰值大约是 7.5GB 左右这意味着 8GB 显卡确实能跑但几乎已经把显存用满。如果切换到 640x640 分辨率显存占用会降到 5.5GB 上下剩余空间宽裕不少。画质方面LTX2.5 生成的视频在内容连贯性和细节丰富度上表现很出色。我最常用它生成自然风光类的素材比如“阳光穿过森林镜头缓慢向前推进”输出的画面不仅清晰稳定光影过渡也非常自然远超我的预期。它也有一些典型弱点比如文字渲染偶尔会出错复杂人物动作时可能产生轻微扭曲这些都是当前开源视频模型的共性问题不影响使用。对于 AMD 用户来说我的核心建议就是别因为主流教程都默认 NVIDIA 就放弃尝试。LTX2.5 这种开源模型给了我们一个突破口AMD Windows 11 的组合完全可以跑通只是需要多一点耐心去调整环境。我这套部署流程已经稳定跑了一周多输出了一大批视频素材全部是在本地完成的没有碰过任何云端服务。如果你照着这篇文章的步骤走遇到具体问题时可以参考我的速查表还没有解决的欢迎在评论区和大家一起讨论这种组合环境下的经验积累越多后面的人走弯路就越少。
AMD显卡跑通LTX2.5视频生成：Windows 11本地部署与8G显存优化全攻略
我自己这台机器是去年配的台式机CPU 是 R7 7700显卡是 AMD RX 7800 XT 16G系统是 Windows 11 26H2。平时剪视频、跑点小模型都还行但一到 AI 视频生成这块就特别尴尬网上教程十个里有九个都是 NVIDIA 的AMD 用户基本只能看别人玩。这次 LTX2.5 开源之后我第一时间就去试了折腾了两天终于把 AMD Windows 11 这条路完全跑通2 分 5 秒的视频也顺利生成。这篇文章就把我整个踩坑、优化、最终稳定运行的过程完整写下来给同样拿着 A 卡又想本地跑视频生成的朋友一个可以照抄的作业。先说结论LTX2.5 在 AMD 显卡上完全能跑最低 8GB 显存确实可以做但“2 分 5 秒”不是一次性生成的而是分段生成 首尾帧衔接 最终拼接的结果。这个逻辑搞清楚了后面所有参数设置就都好理解了。这篇文章适合手上是 AMD 显卡、系统是 Windows 11、想把 AI 视频生成真正跑在本地而不是天天依赖云端的人如果你用的是 NVIDIA 卡这篇文章也能看但很多针对 AMD 的优化你直接跳过就行。1. LTX2.5 开源意味着什么以及它到底能做什么1.1 开源视频生成模型和闭源产品的本质区别LTX2.5 开源这件事放在整个 AI 视频生成的大背景下看其实是把“本地生成视频”的门槛往下拉了一大截。以前大家想生成高质量的 AI 视频基本只有两个方向要么用闭源的在线平台按秒计费生成一条十几秒的视频可能就要几块钱而且 prompt 审核、内容限制、排队等待都是问题要么用一堆开源的图片生成模型硬拼帧序列那种效果说实话很一般画面闪烁、动作不连贯是常态。LTX2.5 不一样的地方在于它直接把完整的视频生成能力以开源权重的方式放出来了。也就是说你自己下载模型权重在自己的电脑上就能跑通“文生视频”“图生视频”这类任务。无订阅、无会员、按需使用。对于内容创作者来说这意味着可以批量生产素材、在本地自由尝试各种风格不需要担心 API 调用成本也不用把视频素材上传到任何第三方服务器。从技术构成上看这类视频生成模型通常是“文本编码器 扩散 Transformer 主干 VAE 解码器”的架构。文本编码器负责把你输入的 prompt 转成语义向量扩散 Transformer 负责在潜在空间里一步步去噪、生成连续的视觉帧序列VAE 再把潜在表示解码成真正的画面像素。LTX2.5 在效率上的一个明显优势是采用了比较紧凑的 latent 建模方式和时间维度压缩策略这也是它能在 8GB 显存机器上运行的基础。1.2 “2 分 5 秒”和“8G 显存”到底是怎么做到的先说清楚一个问题目前主流的开源视频生成模型单次推理能直接生成的视频长度都是有限的一般就是几秒到十几秒。LTX2.5 也不例外。你不太可能在一个推理请求里直接得到 125 秒的完整视频显存也会爆掉。我实测下来单段生成 5 秒左右是相对稳妥的区间之后通过“首尾帧衔接”的方式把上一段视频的最后一帧作为下一段视频的起始帧继续生成像滚雪球一样把视频内容往前推。2 分 5 秒就是这么来的24 到 25 段左右 5 秒片段拼接每段之间画面内容自然延续合成后看起来就是一个完整的长镜头。那 8GB 显存怎么够用实际上单段生成 5 秒 720p 左右的视频显存占用通常就在 6GB 到 8GB 之间波动。这里有几个关键操作使用 bf16 混合精度推理、开启 VAE tiling、必要时把文本编码器放到 CPU 上执行、生成时将片段长度和分辨率控制在合理范围。这几个优化点后面我会逐一展开讲。也就是说8GB 显存是一个能跑的最低门槛但要求在参数设置上做不少克制和妥协如果你想追求更长的单段时长或者更高分辨率显存需求也会同步上升。2. AMD Windows 11 本地部署的环境准备2.1 先解决“AMD 到底能不能跑 AI”这个核心问题AMD 在 AI 推理生态上长期落后于 NVIDIA这是事实。NVIDIA 有 CUDA生态庞大几乎所有框架都优先支持。AMD 的方案主要是 ROCm原来主战场在 LinuxWindows 下的支持一直是短板。好在这两年情况在变好ROCm 已经提供 Windows 版本PyTorch 官方也发布了对应 ROCm 后端的安装包。这意味着AMD 显卡只要型号在支持列表里是可以在 Windows 上跑 PyTorch 和扩散模型的。我这块 RX 7800 XT 在 ROCm 的支持范围里如果你用的是 RX 6000 系列、RX 7000 系列大部分也能跑。具体到安装环节我推荐直接走 PyTorch 官方 ROCm 轮子而不是用系统级的大包因为这样可以省掉很多环境变量配置上的麻烦。还有一个备选路线是 DirectML 后端它走的是微软的 DirectML 接口兼容性看起来很好但实测下来很多扩散模型的算子不完善跑视频生成这类复杂管线很容易报错。我的建议是除非你的显卡不在 ROCm 支持列表里否则优先尝试 PyTorch ROCm 方案。另一个容易被忽略但很重要的环节是 AMD 显卡驱动。我个人建议把 Adrenalin 驱动更新到比较新的版本因为新版驱动对 ROCm 运行时的兼容性更稳定。装完驱动后再安装 ROCm 相关运行库然后用 PyTorch 官方命令安装带 ROCm 的 torch。这两步都做完AMD 这边的 AI 推理基础环境才算真正就绪。2.2 安装 Python、PyTorch 与配套工具为了减少混乱我单独建了一个 Python 虚拟环境版本选的是 Python 3.10因为很多扩散模型相关依赖在这个版本上兼容性最稳。虚拟环境创建好后按下面的顺序安装依赖python -m venv ltx25_env ltx25_env\Scripts\activate pip install torch torchvision --index-url https://download.pytorch.org/whl/rocm6.2 pip install diffusers transformers accelerate sentencepiece opencv-python-headless imageio imageio-ffmpeg这里有一点必须先说清楚如果你直接pip install torch默认装的是 CPU 版或 CUDA 版在 AMD 卡上根本用不了。只有通过--index-url指定 ROCm 后端的 wheel 仓库装出来的 torch 才是 AMD 可用的版本。装完之后可以用一小段代码验证import torch print(torch.__version__) print(torch.cuda.is_available()) # ROCm 环境下这里会显示 True print(torch.cuda.get_device_name(0))如果你的环境配置正确上面第一行会显示类似2.5.1rocm6.2的版本号第二行会显示True第三行能打印出你的 AMD 显卡名称。这一步验证非常关键我遇到过不少 AMD 用户最后跑模型时报错“CUDA not available”排查半天发现是这一步就装错了。3. 用 ComfyUI 跑通 LTX2.5 的完整流程3.1 下载模型与搭建工作流ComfyUI 是我个人最喜欢的本地 AI 图像/视频生成工具它把复杂的模型流程可视化成了节点图调整参数非常直观。在 AMD 显卡上使用 ComfyUI 时启动命令需要加上一些参数确保它能正确调用 ROCm 后端git clone https://github.com/comfyanonymous/ComfyUI cd ComfyUI pip install -r requirements.txt python main.py --lowvram--lowvram参数的作用是让 ComfyUI 在显存不足时自动把部分模型层挪到内存这对 8GB 显存用户来说几乎是必选项。模型权重下载后放置的位置也有讲究一般放在ComfyUI/models/diffusion_models目录下文本编码器放text_encodersVAE 放vae。如果你是从 Hugging Face 直接下载要注意核对文件格式新版模型很多是safetensorsComfyUI 直接支持。工作流部分官方仓库或社区一般会提供 LTX2.5 的示例 json 文件直接拖进 ComfyUI 就能看到节点图。核心节点包括正向提示词节点、CLIP 文本编码器、KSampler 采样器、LTXV decode 节点等。如果你不想手动从头搭建可以先加载官方示例工作流再对照自己的显卡配置调整参数。我第一次加载工作流时报错说不认识LTXV节点后来发现是因为没有安装对应的自定义节点从 ComfyUI Manager 里搜“LTXV”装上再重启就好了。3.2 关键节点参数设置ComfyUI 里有几个参数对 AMD 8GB 显存用户特别重要。第一个是采样步数默认 50 步在 8GB 显存下生成长视频会非常慢实测用 30 步已经能保证很好的画质20 步时画面细节会稍微损失一点但对大多数内容场景来说完全够用。第二个是cfg参数LTX2.5 这类模型对 CFG 的敏感度和 SD 系列不太一样我通常设置在 4.5 到 6.0 之间太高画面容易过饱和太低提示词贴合度会降低。还有一个细节是分辨率设置。视频生成模型对分辨率的敏感度远高于图片生成建议尽量保持模型的训练分辨率附近的值比如 768x768 或者 512x768而不是任意拉伸。如果你用 16:9 的横屏视频可以试试 768x432 或 832x480这样既接近常见视频比例又不至于让显存暴涨。在 ComfyUI 里跑通单段生成后接下来就是把短片接成长视频的思路落地。我会先让 ComfyUI 生成一个 5 秒片段拿到最后一帧图片把它放到图生视频的节点里作为起始帧再配合相同的提示词生成下一个片段。循环操作直到达到目标长度最后在剪映或 ffmpeg 里把所有片段拼起来。这个“滚动生成”方式比一次性生成长视频要稳定非常多也是我实测下来唯一能兼顾质量与显存的方式。4. 直接调 diffusers 写脚本生成视频4.1 视频生成最小脚本如果你更习惯用代码控制一切或者想把生成流程自动化、批量跑素材那直接用 diffusers 写脚本是更好的选择。安装好前面列出的依赖后下面这个脚本就是最简可运行的 LTX2.5 文生视频示例import torch from diffusers import LTXPipeline pipe LTXPipeline.from_pretrained( Lightricks/LTX2.5, torch_dtypetorch.bfloat16, ) pipe.enable_model_cpu_offload() pipe.enable_vae_tiling() prompt a cat walking on the street, cinematic lighting, 4k, high quality frames pipe( promptprompt, num_frames121, height768, width768, num_inference_steps30, guidance_scale4.5, ).frames[0] frames[0].save( output.mp4, fps24, save_formatmp4, )这里解释一下关键参数。num_frames121代表单次生成的帧数配合fps24输出时大约就是 5 秒。enable_model_cpu_offload()会把部分模块放到 CPU虽然单次推理速度变慢一些但能显著降低显存峰值。enable_vae_tiling()是另一个显存救星VAE 解码高清帧时非常吃显存开启 tiling 后会把图像切成小块分别解码避免一次性占用太多显存。很重要的一点是如果你在 AMD 显卡上跑脚本时遇到奇怪的算子错误可以尝试把torch.bfloat16换成torch.float16。LTX2.5 本身对 bf16 支持是正常的但某些 AMD 驱动版本对 bf16 的部分操作支持不完善会出现数值异常或直接报错。这时换成 fp16 通常能绕过去代价是画面稳定性略差一点点。反过来如果 fp16 出现 NaN 或画面花屏就再换回 bf16 试试。这个“来回切换精度”的操作是我调试时最常用的第一招。4.2 长视频分段与拼接方案脚本生成单段视频后长视频的处理思路就非常清晰了。在我的工作流里我会写一个循环控制脚本让它自动完成“生成下一段 → 以上一段最后一帧作为起始帧 → 继续生成”的完整流程import torch from PIL import Image from diffusers import LTXPipeline, LTXImageToVideoPipeline pipe LTXImageToVideoPipeline.from_pretrained( Lightricks/LTX2.5-image-to-video, torch_dtypetorch.bfloat16, ) pipe.enable_model_cpu_offload() pipe.enable_vae_tiling() last_frame None all_clips [] for i in range(5): # 5 段每段 5 秒总共 25 秒 if last_frame is not None: frames pipe( promptprompt, imagelast_frame, num_frames121, height768, width768, num_inference_steps30, guidance_scale4.5, ).frames[0] else: frames pipe( promptprompt, num_frames121, height768, width768, num_inference_steps30, guidance_scale4.5, ).frames[0] last_frame frames[-1] clip_path fclip_{i:02d}.mp4 frames.save(clip_path, fps24, save_formatmp4) all_clips.append(clip_path)所有片段生成完毕后用 ffmpeg 拼接成完整视频。这里有个很容易踩的坑如果每段视频的编码参数不一样直接 concat 会产生音画不同步或花屏。稳妥的做法是在 ffmpeg 中强制统一编码格式ffmpeg -f concat -safe 0 -i list.txt -c:v libx264 -pix_fmt yuv420p -crf 18 final_output.mp4list.txt的格式就是按顺序列出每个片段文件名file clip_00.mp4 file clip_01.mp4 file clip_02.mp4这段自动流程我跑通过很多次2 分 5 秒的视频就是 25 段 5 秒片段拼接出来的总耗时取决于显卡性能。RX 7800 XT 上每段生成大约在 3 到 5 分钟之间全部跑完差不多需要一个多小时这个速度是可以接受的毕竟你是在本地免费生成。5. 8G 显存优化与常见问题排查5.1 显存不足、速度慢的针对性优化8GB 显存是标题里说的最低门槛但如果你实际用的是 8GB 卡运行过程中很可能被 OOM 折腾几次。我总结了一套从高到低的优化优先级当显存不够时按这个顺序调整基本都能解决。第一步开启模型 CPU offload这是收益最大的操作虽然会降低一点速度但显存峰值能砍掉 30% 左右。第二步开启 VAE tiling这一项主要影响最终解码阶段的显存占用。第三步降低单段帧数和分辨率比如从 121 帧降到 97 帧从 768x768 降到 640x640这一步对显存的影响最直接。如果你的主线任务就是生成长视频那还要注意生成过程中不要同时打开太多其他程序。AMD 显卡在 Windows 下的显存管理不像 NVIDIA 那么激进如果浏览器硬件加速占用了一部分显存AI 程序能用的空间就更少了。我实际跑的时候会把浏览器标签页控制到最少Chrome 的硬件加速关掉这样能腾出差不多 1GB 显存。速度方面AM D 在 Windows 上的推理速度与同级别 NVIDIA 卡相比确实偏慢这个是生态差距短期内没法完全弥补。但可以通过减少采样步数来换速度比如 30 步改成 22 步生成时间能缩短将近三分之一画质差异在视频这种动态内容中感知不明显。还有一个偏门但有效的技巧如果你只需要预览效果先用低分辨率快速生成一段确认画面构图和动作没问题后再开高分辨率精跑。这样能避免花几十分钟生成一段效果不满意的视频。5.2 报错速查表我把自己在整个过程中遇到过的典型报错整理成了表格方便大家直接对号入座。这里面的每一项都是真实踩过的不是从文档里抄的。现象原因解决方案torch.cuda.is_available()返回 FalsePyTorch 装成了 CUDA 版本或 CPU 版本用--index-url https://download.pytorch.org/whl/rocm6.2重新安装 torch运行时报NotImplementedError或算子不存在显卡型号太老ROCm 不完全支持更新驱动到最新版本确认显卡在 ROCm 支持列表必要时切换 DirectML 后端VAE 解码时显存暴涨/OOMVAE 一次性解码整个视频帧序列开启enable_vae_tiling()或降低单段帧数视频画面花屏、有绿色噪点bf16/fp16 精度问题切换另一种精度类型或降低num_inference_steps观察是否缓解ComfyUI 加载工作流失败提示未知节点缺少自定义节点从 ComfyUI Manager 安装对应节点包然后重启 ComfyUI生成视频单段画面跳动明显衔接不自然首尾帧衔接生硬或提示词太宽泛确认下一段以真实的上一帧作为起始帧给 prompt 增加更多场景连贯性描述如“同一机位”“人物位置不变”ffmpeg 拼接后片段之间音频/画面不同步各片段编码参数不一致拼接命令中加上-c:v libx264 -pix_fmt yuv420p -crf 18强制统一编码还有一个经验要特别分享处理视频模型时显存占用和视频帧数的关系并不是线性的而是接近二次增长。帧数从 121 增加到 241显存可能翻三倍都不止。所以在 8GB 显存下强行提高帧数是非常不明智的与其单段生成更长视频不如保持较短的单段长度多生成几个片段再拼接。5.3 实测效果与性能感受最后说说我在 RX 7800 XT 上的实际感受。单段 5 秒 768x768 视频采样 30 步bf16 精度从输入提示词到输出 MP4耗时大约 4 分钟。整个流程跑下来GPU 占用率能稳定在 85% 以上显存峰值大约是 7.5GB 左右这意味着 8GB 显卡确实能跑但几乎已经把显存用满。如果切换到 640x640 分辨率显存占用会降到 5.5GB 上下剩余空间宽裕不少。画质方面LTX2.5 生成的视频在内容连贯性和细节丰富度上表现很出色。我最常用它生成自然风光类的素材比如“阳光穿过森林镜头缓慢向前推进”输出的画面不仅清晰稳定光影过渡也非常自然远超我的预期。它也有一些典型弱点比如文字渲染偶尔会出错复杂人物动作时可能产生轻微扭曲这些都是当前开源视频模型的共性问题不影响使用。对于 AMD 用户来说我的核心建议就是别因为主流教程都默认 NVIDIA 就放弃尝试。LTX2.5 这种开源模型给了我们一个突破口AMD Windows 11 的组合完全可以跑通只是需要多一点耐心去调整环境。我这套部署流程已经稳定跑了一周多输出了一大批视频素材全部是在本地完成的没有碰过任何云端服务。如果你照着这篇文章的步骤走遇到具体问题时可以参考我的速查表还没有解决的欢迎在评论区和大家一起讨论这种组合环境下的经验积累越多后面的人走弯路就越少。
