在Windows上的ComfyUI中安装LTX-2：CUDA设置与首次运行指南

我是Dora。那天，我只是想为一个草图做一个快速的文字转视频处理，我在ComfyUI的讨论线程中不断看到LTX‑2被提及。到上午中期，我盯着一个空白的图表和一个名为”ltx”的文件夹，想知道我是否又陷入了驱动程序赌博中。

我在Windows 11上设置时做了笔记。如果你正在搜索”ltx‑2 comfyui windows”，因为你正在安装过程中，我也经历过。这是有帮助的方法。

安装前检查清单（GPU / CUDA / 驱动程序版本）

开始前的快速检查可以让你节省后来追逐DLL错误的一小时：

GPU： 一块至少有12GB VRAM的NVIDIA显卡让LTX‑2在中等设置下（512–768宽度，短视频）对我来说是可用的。8GB可以在非常保守的设置下工作，但这很紧张，经常令人沮丧。
驱动程序： 更新到最近的Game Ready或Studio驱动程序（我使用了552.xx）。
CUDA： 你不需要为ComfyUI便携版安装完整的CUDA工具包。你只需要PyTorch附带的运行时DLL。这就是为什么匹配PyTorch+CUDA build很重要（cu121或cu122等）。
Python： ComfyUI便携版内置了自己的Python。如果你运行自定义venv，请保持与你选择的PyTorch wheel一致。
VC++ 可再发行版： 安装/修复最新的Microsoft Visual C++ 可再发行版。这是修复”procedure entry point”式DLL错误的一个安静的方法。

我在任何重型模型前进行两个完整性检查：

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

这些都不能保证一帆风顺，但它缩小了失败的方式。

更新ComfyUI到LTX-2-Ready版本

我做的事情：

首先更新ComfyUI。如果你在GitHub的便携版上，获取最新版本或git pull并运行更新脚本。
打开ComfyUI Manager（如果你使用它）并更新核心依赖项。当提示时，我让Manager重建venv。
从其官方repo安装LTX‑2节点包。名称各不相同（我看到过”ComfyUI-LTXVideo”/“LTX‑Video”风格的repos）：我使用了从模型官方页面链接的那个。如果repo描述说它支持LTX‑Video v2/LTX‑2，那就是你想要的。

为什么这在实际中很重要：

LTX‑2依靠PyTorch 2.3+功能和CUDA 12.x构建。混合旧的torch（cu118）与新节点是快速遇到隐晦导入错误的方式。
一些包以不同的方式公开FP8/BF16切换。匹配节点包和ComfyUI版本可以避免不匹配的输入和死路图。

我一开始抗拒全新安装，感觉不必要。然后我比较了：新版本第一次尝试就启动了；旧版本一直要求缺失的操作。我没有错过猜测工作。

模型文件放置（逐步）

这是我通常花时间的地方。不同的节点期望不同的文件夹。这是我使用安装的LTX‑2节点包的方法，即使你的文件夹名称不同，通用模式也适用。

查找节点的预期路径。 在ComfyUI中，打开LTX加载器节点并悬停任何文件输入。大多数包显示它们扫描的相对路径（例如，models/ltx、models/checkpoints或自定义子文件夹如models/ltx_video）。如有疑问，检查repo README。他们通常列出确切的目录。
从官方来源下载LTX‑2权重（通常是Hugging Face，从模型的页面链接）。你通常会获得一个主.safetensors或.pth文件加配置。有些repos分别分割文本编码器/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 load failed while importing …” 或缺失 nvrtc64_X.dll

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

解压时的长路径问题

原因：Windows路径长度限制加上深层ComfyUI子文件夹。
修复：在Windows中启用长路径（本地组策略或注册表）或在C:\附近解压。

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

症状：ComfyUI在编码期间挂起或卡顿。
修复：为ComfyUI文件夹或只是输出临时路径添加排除项。

“Could not find model” 即使文件夹正确

修复：重启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，降低分辨率或帧数。
首帧的时间。我第一次清晰的运行是在4070上512×288处的8步16帧~25–40秒。任何异常长的运行通常指向CPU编码或I/O瓶颈。

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

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

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

性能调优（批处理 / 精度）

我没有追求基准荣誉。我只是想要阻止我照看内存的设置。

推动指针的内容：

帧数在宽度之前。保持12–16帧并将宽度提升到640比跳到24+帧对VRAM来说更容易。更长的剪辑迅速上升内存。
精度：FP16在我的4070上效果最好。BF16也有效但使用了更多内存。在这些大小下，我从BF16没有获得可见的质量提升。
注意力后端：如果你的包为scaled_dot_product_attention（PyTorch本机）vs xFormers公开一个切换，先在最近的PyTorch上尝试本机。它在Windows上对我更稳定。
批处理大小：保持视频为1。小批处理主要惩罚VRAM，而不是在我的设置上节省壁钟时间。
Torch编译：值得测试，但我只看到更长运行的小收益。对于短的8–16帧测试，编译时间可能会吃掉节省。
混合I/O：写入快速本地SSD比我预期的更重要。慢网络文件夹使编码阶段看起来像模型问题，实际上不是。

一个对我不爆炸VRAM的简单阶梯：