在Windows上的ComfyUI中安裝LTX-2：CUDA設定和首次執行指南

我是Dora。那天，我只想快速为一个草图做文本生成视频，结果一直在ComfyUI帖子里看到LTX-2被提及。到了上午中旬，我盯着空白的节点图和一个叫”ltx”的文件夹，想知道自己是不是又陷入了驱动程序赌局。

我在Windows 11上设置时做了笔记。如果你因为正在安装而搜索”ltx-2 comfyui windows”，我也经历过。以下是有帮助的内容。

安装前检查清单 (GPU / CUDA / 驱动版本)

在开始前快速检查一下，可以省去你之后追踪DLL错误花费的一小时：

GPU: 至少12 GB VRAM的NVIDIA显卡让我能在适中的设置下(512–768宽度，短视频)使用LTX-2。8 GB也可以用，但需要非常保守的设置，往往令人沮丧。
驱动: 更新到最近的Game Ready或Studio驱动(我用的是552.xx)。
CUDA: 你不需要为ComfyUI便携版安装完整的CUDA工具包。你只需要PyTorch附带的运行时DLL。这是为什么匹配PyTorch+CUDA构建(cu121或cu122等)很重要。
Python: ComfyUI便携版附带它自己的Python。如果你运行自定义venv，让它与你选择的PyTorch wheel保持一致。
VC++ Redistributable: 安装/修复最新的Microsoft Visual C++ Redistributable。这是解决”程序入口点”风格DLL错误的安静修复。

任何重型模型前我做的两个理智检查：

nvidia-smi在终端中运行并清晰地显示驱动程序。
python -c "import torch: print(torch.version, torch.cuda.is_available())"在ComfyUI将使用的任何环境中为CUDA返回True。

这些都不能保证一帆风顺，但会缩小故障模式。

更新ComfyUI到LTX-2就绪版本

我做的：

首先更新ComfyUI。如果你用的是GitHub上的便携版，获取最新发布版或git pull并运行更新脚本。
打开ComfyUI Manager(如果你用的话)并更新核心依赖。我让Manager在提示时重建venv。
从其官方仓库安装LTX-2节点包。名称多样(我见过”ComfyUI-LTXVideo”/“LTX-Video”风格的仓库)：我用的是从模型官方页面链接的那个。如果仓库描述说它支持LTX-Video v2/LTX-2，那就是你要的那个。

这在实际中为什么重要：

LTX-2依靠PyTorch 2.3+特性和CUDA 12.x构建。混合旧torch(cu118)和新节点是快速命中神秘导入错误的方式。
有些包暴露FP8/BF16开关的方式不同。匹配节点包和ComfyUI版本避免了不匹配的输入和死胡同图。

我一开始抗拒全新安装，感觉没必要。然后我比较了：新构建首次尝试就启动了；旧的一直要求缺少的ops。我没有错过猜测工作。

模型文件放置 (逐步)

这是我通常浪费时间的地方。不同的节点期望不同的文件夹。以下是我用安装的LTX-2节点包有效的方法，即使你的文件夹名称不同，一般模式也成立。

找到节点的预期路径。
在ComfyUI中，打开LTX加载器节点并悬停任何文件输入。大多数包显示他们正在扫描的相对路径(如models/ltx、models/checkpoints或自定义子文件夹如models/ltx_video)。
如有疑问，检查仓库README。他们通常列出确切的目录。
从官方来源下载LTX-2权重(通常来自Hugging Face，从模型页面链接)。
你通常会得到一个主.safetensors或.pth文件加上配置。有些仓库将文本编码器/VAE分开；其他的捆绑在一起。
将文件放在节点查找的确切位置。
对于我的包：ComfyUI/models/ltx_video/包含主模型文件。如果你的包说models/checkpoints，就用那个代替。重启或重新扫描后，名称应该出现在节点下拉菜单中。
可选：文本编码器 / VAE。
如果节点暴露编码器或VAE的单独输入，遵循其指导。许多LTX-2节点隐藏这个并在内部捆绑组件。如果暴露了，按README指示将CLIP/Tokenizer文件放在models/clip或models/text_encoders中。
重启ComfyUI。
我知道，这很明显。但热加载并不总是重新扫描这些文件夹，我盯着空下拉菜单的次数比我愿意承认的还多。

小注：如果Windows标记下载的文件为阻止(右键 > 属性 > 解除阻止)，清除那个。我在更严格的设置中见过Python拒绝接触”从互联网下载的”文件。

常见Windows错误 (DLL / 权限)

“DLL加载失败，同时导入…”或缺少nvrtc64_X.dll

原因：PyTorch构建与节点包期望的CUDA运行时不匹配，或环境混合了cu118和cu12x。
修复：在ComfyUI环境中重新安装/确认PyTorch 2.3+与cu121/cu122。如果你运行便携版，让Manager处理它。更新NVIDIA驱动有一次也有帮助。 “访问被拒绝”当写入帧/视频
原因：我把SaveVideo节点指向一个有激进权限的同步文件夹(OneDrive)。
修复：首先写到本地非同步路径(如ComfyUI/output/ltx_test)。稍后移动文件。

解压时的长路径问题

原因：Windows路径长度限制加上深ComfyUI子文件夹。
修复：在Windows中启用长路径(本地组策略或注册表)或解压到靠近C:\的位置。

杀毒软件在渲染中间扫描临时帧

症状：编码时ComfyUI挂起或卡顿。
修复：为ComfyUI文件夹或只是输出临时路径添加例外。

“找不到模型”即使在正确的文件夹

修复：重启ComfyUI。如果仍然没有显示，检查节点的确切预期文件夹。有些LTX-2节点在自定义目录名中查找。完全匹配。

我也遇到过经典的”第一次可以，下一次运行失败”。对我来说，这归结为一个浏览器标签试图在编码节点仍在写入时预览部分MP4。我改为每次运行写到新文件名。不稳定性消失了。

首次推理测试工作流

我让第一个图形很小。没有什么巧妙的，只是足以确认管道。

我构建的：

一个提示节点，带有单个句子(10–20个token)。保持简单。
LTX-2加载器节点指向下载的模型。
LTX-2采样器/调度器节点(无论你的包怎么命名它)，步数较低。
一个视频解码/组装路径，将帧写到SaveVideo节点(MP4，H.264对于烟雾测试很好)。

没有给我麻烦的参数：

分辨率：512×288或640×360
帧数：8–16帧(0.5–1秒)
步数：6–12
指导/CFG：中间地带(5–7)
种子：固定数字(使故障排除噪音更少)
精度：FP16(默认)除非你的节点在Ada上建议BF16：两者对我都有效，FP16用更少VRAM

我在首次运行中观察的：

nvidia-smi中的VRAM峰值。如果你立即钉住99%VRAM，降低分辨率或帧数。
首帧时间。我首次干净运行是512×288、steps=8在4070上16帧约25–40秒。任何非常长通常指向CPU编码或I/O瓶颈。

如果你的渲染完成但视频为空或损坏，尝试：

首先写入PNG帧，然后让单独的节点或外部工具组装视频。
切换到不同的编码器(H.264 vs H.265)或CRF值。

有用的部分不是速度，而是看到一个连贯的剪辑。那时我放松了。然后我小心地扩展。

性能调优 (批次 / 精度)

我没有追求基准荣耀。我只想要让我不用照看内存的设置。

移动指针的：

帧数在宽度之前。在VRAM上保持12–16帧并将宽度提高到640比跳到24+帧容易得多。更长的剪辑内存快速增长。
精度：FP16在我的4070上效果最好。BF16也有效但用更多内存。我在这些大小上从BF16没有获得可见质量。
注意力后端：如果你的包暴露scaled_dot_product_attention(PyTorch原生)vs xFormers的开关，在最近的PyTorch上首先尝试原生。它在Windows上对我更稳定。
批大小：对视频保持在1。小批处理主要在没有节省挂钟时间的情况下惩罚VRAM。
Torch编译：值得测试，但我只在较长运行中看到小收益。对于短8–16帧测试，编译时间可能吃掉节省。
混合IO：写到快速本地SSD比我预期的更重要。缓慢的网络文件夹使编码阶段看起来像模型问题，其实不是。

一个没有炸VRAM的简单梯子对我：