简介：这份资源面向希望用首尾帧快速生成视频的创作者与ComfyUI使用者，核心是一套LTX2.3首尾帧生成视频的工作流配置，解决从静态起止画面自动补全中间过渡、输出连贯视频的问题，适合具备基础ComfyUI操作经验、想省去手动逐帧制作的用户。压缩包内共1个文件，为json格式的工作流配置，体积约3KB，导入ComfyUI后即可加载节点结构，其中包含首尾帧输入、帧插值、过渡与图像处理、帧率与分辨率调整、色彩校正及视频格式输出等模块，并支持批处理与步骤回改。目前已有645人学习下载。借助该工作流，读者可直接复用现成的节点编排，理解首尾帧驱动视频生成的完整链路，并在此基础上调整参数、替换素材，快速产出平滑自然的视频结果。
1. 首尾帧生成视频：为什么 LTX2.3 工作流值得单独拆一遍
如果你用过图生视频，大概率遇到过同一个尴尬：给一张图，模型自由发挥，镜头往哪走、主体怎么动、结尾停在哪，全靠抽卡。做短片、做广告分镜、做产品演示，最怕的就是"开头对了，结尾飞了"。LTX2.3 的首尾帧工作流解决的正是这件事——你给第一帧和最后一帧，中间的运动由模型补全，视频的起点和终点都被你锁死。
这套 ComfyUI 工作流的核心价值在于可控性。传统图生视频是"单锚点"，首尾帧是"双锚点"，后者对镜头运动、主体位移、光影过渡的约束强得多。适合谁？做 AI 视频生成的内容创作者、需要批量产出分镜的从业者、以及想把视频生成接进自动化流水线的人。它不挑显卡到离谱的程度，但显存和内存的边界得心里有数，后面会专门讲爆内存怎么排查。
2. LTX2.3 首尾帧工作流的节点结构与参数逻辑
2.1 工作流骨架：从两个 LoadImage 到视频输出
先把整条链路捋清楚，不然节点一多就容易懵。首尾帧工作流的骨架大致是这样：
LoadImage(首帧) ─┐ ├─→ LTXVConditioning ─→ 采样器(KSampler) ─→ VAEDecode ─→ 视频合成 LoadImage(尾帧) ─┘ ↑ LTX2.3 模型加载关键节点分工：
- 两个 LoadImage：分别喂首帧和尾帧，尺寸必须一致，不一致会在拼接阶段报错或产生拉伸。
- LTXVConditioning：这是 LTX 系列做首尾帧控制的核心节点，它把两帧信息编码进条件，告诉采样器"从这走到那"。
- 模型加载节点：加载 LTX2.3 的主模型和对应的 VAE、文本编码器。
- 采样器：负责在潜空间里补全中间帧，步数和 CFG 直接决定质量和耗时。
- VAEDecode + 视频合成：把潜空间结果解码成帧序列，再按帧率封装成视频。
我一般会先把这条链路在脑子里过一遍再动手连线，因为 LTX 的节点命名和 SD 系不太一样，照搬 SD 的经验容易连错。
2.2 关键参数怎么设：帧数、步数、CFG 的取舍
参数是这套工作流最容易翻车的地方。下面这张表是我实测下来比较稳的起点，具体还得按你的素材调：
| 参数 | 建议起点 | 作用 | 调大/调小的后果 |
|---|---|---|---|
| 总帧数 | 49 / 97 | 决定视频长度 | 越大越吃显存，且运动幅度可能失控 |
| 采样步数 | 20～30 | 去噪迭代次数 | 步数低画面糊，步数高收益递减还慢 |
| CFG | 3～5 | 文本引导强度 | 太高画面过饱和、运动僵硬 |
| 帧率 | 24 / 25 | 播放速度 | 帧率低显卡顿，高则需更多帧 |
| 分辨率 | 768×512 起 | 画面尺寸 | 直接线性影响显存占用 |
帧数这块有个经验：LTX 对总帧数比较敏感，49 帧（约 2 秒 @24fps）是显存和效果的平衡点。想更长就往上加，但显存占用不是线性涨的，是阶梯式跳的，97 帧可能直接把你 12G 卡干趴。
# 采样参数配置示例（伪代码，对应节点里的输入） total_frames = 49 # 总帧数，必须是 8n+1 这类模型友好的数值 steps = 25 # 采样步数 cfg = 4.0 # 引导强度 fps = 24 # 输出帧率 width, height = 768, 512 # 分辨率，首尾帧必须与此一致逻辑说明：total_frames之所以强调 8n+1，是因为 LTX 的时序 VAE 对帧数有整除要求，49 = 8×6+1，97 = 8×12+1，用这两个值最稳。steps和cfg是一对，步数低的时候 CFG 别拉太高，否则噪点会被放大。分辨率先别贪大，跑通了再往上加。
2.3 首尾帧的匹配要求：尺寸、构图与内容连续性
很多人第一次用首尾帧，直接拿两张风格完全不同的图去喂，结果中间过渡像鬼畜。首尾帧不是随便两张图，它要求：
- 尺寸严格一致：宽高必须相同，否则 LTXVConditioning 阶段就会出问题。
- 构图有连续性：首帧主体在左，尾帧主体突然跑到右，模型补出来的中间帧会很拧巴。合理的做法是让两帧的构图差异控制在"一个合理运动能到达"的范围内。
- 光照和色调接近：一帧白天一帧黑夜，模型会试图在中间做渐变，但往往变成闪烁。
常见做法是：先用同一张图做轻微位移或缩放，生成尾帧，再拿这对图去跑，过渡会顺很多。这也是做"推拉摇移"类镜头最省事的办法。
3. 从零跑通：ComfyUI 环境准备与工作流导入
3.1 环境准备：整合包还是手动装
如果你不想在依赖上耗时间，秋叶 ComfyUI 整合包是很多人的起点，模型、插件、常用节点都打包好了，解压即用。手动装也不是不行，但要自己处理 Python 版本、torch 和 CUDA 的匹配，新手容易在这一步卡住。
不管哪种方式，跑 LTX2.3 之前确认三件事：
- ComfyUI 本体能正常启动，浏览器能打开界面。
- 显存至少 8G，内存建议 32G 起（16G 也能跑，但爆内存概率高）。
- 磁盘留出模型空间，LTX2.3 主模型加 VAE 加文本编码器，几个 G 是跑不掉的。
# 手动安装时的依赖检查（在 ComfyUI 根目录） python -c "import torch; print(torch.__version__, torch.cuda.is_available())" # 期望输出类似：2.x.x True # 如果 cuda_available 是 False，说明 torch 和显卡驱动没对上逻辑说明：这行命令是排查环境的第一道关。torch.cuda.is_available()返回 False，后面所有 GPU 加速都是空谈，先解决驱动和 torch 版本，别急着导入工作流。
3.2 模型与插件放置：目录别放错
ComfyUI 的模型目录结构是固定的，放错位置节点就找不到模型。LTX2.3 相关的文件一般这么放：
ComfyUI/ ├── models/ │ ├── checkpoints/ # 主模型放这里 │ ├── vae/ # VAE 放这里 │ ├── text_encoders/ # 文本编码器 │ └── clip/ # 部分版本放这里 └── custom_nodes/ # 首尾帧相关自定义节点提示：LTX 的节点如果没出现在右键菜单里，八成是 custom_nodes 里的插件没装或没重启。装完插件一定要重启 ComfyUI，热加载不一定生效。
3.3 导入工作流并首次运行
拿到工作流 JSON 后，直接拖进 ComfyUI 界面，或者用菜单里的 Load 加载。加载后先别急着点生成，按顺序检查：
- 所有红色节点说明模型没加载，点节点里的模型名重新选一遍。
- 两个 LoadImage 分别上传首帧和尾帧，确认尺寸一致。
- 检查采样器的帧数、步数、CFG 是否是你想要的。
- 输出节点确认帧率和保存路径。
首次运行建议： - 分辨率降到 512×320 - 帧数设 25 - 步数设 15 先跑通流程，确认能出视频，再逐步加参数。逻辑说明：第一次跑用最小参数，目的是验证链路通不通，而不是出好片。很多人一上来就拉满参数，结果爆显存，还以为是工作流有问题，其实是参数太激进。
4. 避坑与排查：爆内存、黑帧、首尾帧不生效
4.1 生成时爆内存（OOM）
现象：点生成后进度条走到一半，控制台报 CUDA out of memory，或者整个界面卡死。
原因：帧数或分辨率超出显存承载，或者同时开了其他吃显存的程序。
解决：先把帧数砍到 25、分辨率降到 512 级别跑通；关掉浏览器里其他占显存的标签页；在启动参数里加--lowvram或--medvram。如果还不行，就是模型本身太大，考虑换更小的版本。
4.2 输出视频全黑或只有首帧
现象：视频出来了，但要么全黑，要么从头到尾就第一帧不动。
原因：VAE 没配对，或者 LTXVConditioning 的尾帧没接上，模型只拿到了首帧条件。
解决：检查 VAE 节点是否加载了 LTX 对应的 VAE，别用 SD 的 VAE 顶替；检查尾帧的 LoadImage 输出有没有连到 Conditioning 节点，连线断了不会报错，但结果就是单帧。
4.3 首尾帧过渡鬼畜、闪烁
现象：中间帧画面扭曲、闪烁，或者主体突然变形。
原因：首尾帧构图差异太大，或者 CFG 太高导致模型过度"用力"。
解决：把 CFG 降到 3 左右；换一对构图更接近的首尾帧；适当增加采样步数让过渡更平滑。这个坑我踩过不止一次，后来养成习惯：首尾帧先肉眼比对一下，差异太大就重新做尾帧。
4.4 帧数不是 8n+1 导致报错
现象：采样阶段直接报错，提示帧数不合法。
原因：LTX 的时序结构要求帧数满足特定整除关系。
解决：把总帧数改成 25、49、97 这类 8n+1 的值。别用 30、50 这种整数，看着舒服但模型不认。
4.5 插件冲突导致节点消失
现象：昨天还能用的节点，今天打开 ComfyUI 找不到了。
原因：新装的插件和现有插件冲突，或者插件更新后接口变了。
解决：看启动时的控制台日志，哪个插件报错就临时移出 custom_nodes；确认 LTX 相关插件版本和工作流匹配，工作流是老版本的话，节点名可能已经变了。
5. 进阶技巧：用首尾帧做镜头运动与批量验证
跑通基础流程后，真正拉开差距的是怎么用首尾帧控制镜头语言。我的做法是把首尾帧当成"关键帧"来用：想要推镜，就让尾帧比首帧主体更大；想要横移，就让主体在画面里平移；想要旋转，就让尾帧带一点角度变化。这样模型补出来的中间帧，运动方向是可预期的，而不是随机漂移。
批量验证这块，与其一张张手动跑，不如把参数做成变量。下面这个思路可以套用到任何批量场景：
# 批量生成不同镜头运动的参数组合（伪代码） moves = { "push_in": {"scale_end": 1.15}, # 尾帧放大，推镜 "pull_out": {"scale_end": 0.85}, # 尾帧缩小，拉镜 "pan_left": {"shift_x": -0.1}, # 尾帧左移，横移 } for name, params in moves.items(): # 用 params 生成对应的尾帧，再喂给工作流 # 每个组合跑一遍，对比运动效果 run_workflow(first_frame, make_end_frame(params))逻辑说明：把"镜头运动"翻译成尾帧的几何变换参数，是这套工作流最实用的进阶玩法。scale_end控制推拉，shift_x控制横移，跑完一轮你就有了一套可复用的镜头模板。参数别一次调太多，每次只动一个维度，不然出了问题不知道是哪个变量导致的。
验证生成质量，我一般看三个点：首帧到第二帧的过渡是否自然、中间段有没有闪烁、尾帧是否精确落在你给的那张图上。第三点尤其重要，如果尾帧对不上，说明条件没生效，回去查 LTXVConditioning 的连线。
还有个习惯：每次改完参数，先跑 25 帧的低分辨率版本验证方向，确认没问题再上 49 帧全分辨率。这个"先小后大"的流程帮我省了无数次等待。从那以后我每次调新工作流，都强制先跑一遍最小参数，确认链路通了再谈效果。希望帮到你。
本文还有配套的精品资源，点击获取
