Claude+ComfyUI+LTX2.3实战：本地AI视频生成全流程与显存优化

最近总有人拿一个视频链接来问我这是不是 Claude Opus 5.5 直接生成的我理解大家为什么会这么问——AI 视频的质感已经越来越像“真人拍的了”但只要拆开看流程你就会发现Claude 这种大语言模型从来不是一个“一键出片机”它更像是一个导演兼副驾负责把脑子里模糊的想法翻译成视频模型能听懂的提示词、分镜表和参数方案真正逐帧生成画面的是它背后的 ComfyUI 视频生成模型这套组合拳。这篇文章我就用最近跑通的一条完整链路——Claude 写脚本、LTX2.3 出帧、FramePackWrapper 兜住显存——把“AI 视频是怎么做出来的”这件事讲透彻。适合谁看两类人一类是想在本地部署自动化 AI 视频生成但第一步就被爆内存劝退的另一类是手里有显卡、已经会跑 Stable Diffusion但一直没搞明白视频提示词该怎么写的人。1. 先搞清楚一件事Claude不是视频生成器是工作流大脑很多人在标题里看到“Claude”就默认它能直接吐视频这是个误解。Claude 这类大语言模型的输入输出都是文本它不碰像素。但换个角度想视频生成真正卡人的地方从来不是采样器跑得够不够快而是“你根本说不清自己要什么”。一张图片可以用半句话描述一段视频却需要时间轴上的每一帧变化都要有明确交代这就是 Claude 的价值所在。1.1 Claude在一条视频链路里到底干了哪些活我把一条完整的 AI 视频生成流水线拆开看Claude 干的主要是三件事。第一件事是分镜脚本规划。你给它一句“我要一个黄昏城市上空无人机缓慢推近大厦的镜头”它会帮你拆成若干段镜头运动方式、主体动作、光线变化、环境元素出现的先后顺序。这一步没有它你就要自己在 ComfyUI 里反复试错——试过的人都知道模型出画面很快但你脑子里没脚本跑十次也攒不出一段能用的素材。第二件事是提示词工程。视频模型的提示词和图片模型不是一个量级。图片模型你写“一只猫”就行了视频模型你得交代“猫从左侧入画耳朵抖动然后转头看向镜头背景从模糊变清晰”。这些连续动作的措辞哪个模型能识别、哪个词会被忽略Claude 比人凭感觉猜准确得多。尤其是它知道 LTX2.3 这类模型对动作词的敏感度会主动规避“快速闪烁”“剧烈变化”这类容易触发画面崩坏的表达。第三件事是报错排查。ComfyUI 跑视频生成报错几乎不可避免。Diffusion 模型对环境变量的敏感程度远高于普通程序同样的节点换一张显卡、换一个 PyTorch 版本都可能出问题。我现在的习惯是直接把完整 traceback 贴给 Claude让它判断是显存不足、张量维度不匹配还是节点连接顺序错了。很多次它给出的修复方案比我翻 GitHub issue 半小时还准。这三件事没有一件是生成像素但没有一件不影响最终视频质量。把 Claude 理解成“工作流大脑”而不是“视频生成器”整个技术路线就通顺了。1.2 为什么我坚持本地ComfyUI而不是图省事用在线工具网上有大量“免费生成 AI 视频的网站”我并不是说它们一无是处。在线工具有一个非常大的优势零门槛。注册账号、点几下、等排队视频就出来了。但只要你批量做、做系列化内容在线工具的弊端会集中爆发。首先是限制问题。免费档通常有分辨率上限、时长上限、水印有的还会在提示词层面做过滤。我做过一个系列视频需要同一角色在同一场景里连续出几条片段在线工具根本没法保证角色一致性因为我没有底层模型的任何控制权。其次是成本问题。按秒计费看着便宜一分钟视频按 10 秒一段生成要跑六次积少成多很可观而且排队时间不可控。本地部署之后电费是唯一的硬成本我有一台 8G 显存的卡晚上挂机批量跑早上起来收素材体验完全不一样。更重要的是本地部署让你能上自定义节点。热词里反复出现的 FramePackWrapper就是典型的本地专属方案——在线工具不可能让你改采样器的内存管理策略。整个本地链路里ComfyUI 是壳LTX2.3 是引擎Claude 是驾驶策略三者缺一不可。在线工具再方便你也改不了它的方向盘。2. 视频提示词和图片提示词完全不是一回事如果说图片生成的提示词是写“静态剧本”视频生成的提示词就是写“分镜脚本”。这个区别没转过来之前我吃了不少亏——在 ComfyUI 里写了一段看似很丰富的图片提示词扔给视频模型结果生成出来的画面要么是主体发呆不动要么是场景乱跳。后来我才明白视频模型对文本的理解方式压根不同。2.1 关键帧描述让模型知道第一帧长什么样视频模型不是从空白开始画它需要一个“锚点”。LTX2.3 这类模型最常见的操作模式就是首尾帧生成你给它一张起始帧图片和一张结束帧图片模型负责把中间的过渡动作“脑补”出来。这个过程可以类比传统动画里的原画与中割——首尾帧就是原画决定了画面从哪开始、到哪结束中间的过程交给自动插值。这就引出关键帧描述的必要性。如果只给一张起始图不给任何描述模型会随机补全动作走向给两张图但两张图构图差异太大中间帧就会疯狂扭曲。我在实际操作中会让 Claude 同时输出三样东西首帧的完整描述、尾帧的完整描述、以及中间过渡的动作描述。三者的光线方向、主体位置、镜头焦段必须保持一致否则视频会出现肉眼可见的“抽搐感”。举个我踩过的例子。有一次我生成“雨夜街道一把伞从画面右侧向左移动”的视频首帧描述写的是“伞在右侧雨滴斜落路灯在左上角”尾帧描述写的是“伞在左侧雨滴竖直下落路灯在正上方”结果中间帧的光线和雨滴方向完全对不上画面像两个片段硬拼接。后来改成首尾帧统一描述“路灯在画面左上角雨滴自右上向左下斜落”一次就跑通了。2.2 用Claude批量拆解分镜的提示词模板直接让 Claude 写一条“完整视频提示词”是不够的它会给你一段很长但结构混乱的文字。我测试下来用结构化模板去约束它效果最好。下面这个模板我用了很久你可以直接复制套用请将下面这句话拆成N段连续镜头每段包含以下字段 - 镜头类型固定/推近/拉远/左摇/右摇/跟拍/环绕 - 主角描述外观、衣着、所在位置 - 主角动作必须是连续的、可被视觉呈现的动作禁止抽象描述 - 环境变化光线、天气、物体运动、背景元素 - 首帧描述静态画面50字以内 - 尾帧描述静态画面50字以内 - 过渡动作描述首尾之间发生了什么必须具体 我的原始创意是{在这里粘贴你的创意} 额外要求全片保持同一角色的外貌一致性避免镜头切换过快时长共5秒左右输出为可直接用于视频生成模型的提示词格式。这个模板看起来死板但它解决了一个核心问题人写提示词时会偷懒会省略“理所当然”的动作过程而 Claude 会把每个环节都补齐。实际使用中我发现它产出的提示词长度通常在 300-500 字之间视频模型能完整读取generate 出来的画面动作连贯率明显高于我手写版本。顺带说一个数字供参考有些在线 API 类视频模型对提示词有字数限制比如 5 秒视频建议控制在 100-200 字之间而本地 Deploy 的 LTX2.3 对长提示词容忍度更高。如果你用 Claude 生成的提示词被截断优先让 Claude 精简到核心信息不要强行喂给模型。2.3 首尾帧生成LTX2.3的核心玩法LTX2.3 是我目前本地视频生成的主力模型它最实用的功能就是首尾帧生成。这个功能对硬件要求不算离谱但在实操中有几个细节必须注意。首尾帧图片的尺寸必须完全一致。我一开始犯过错误——首帧用 1024×576尾帧不小心弄成了 576×1024结果模型直接报错。这个错误很蠢但很容易犯尤其是从图库批量拖图片的时候。现在我在流程里加了一步先让 Claude 生成一段 Python 校验脚本批量检查所有首尾帧图片的尺寸和格式不合规的直接标记出来。首尾帧之间的“语义差距”不能太大。模型学习的是物体如何运动不是空间如何重塑。从“人站在门口”到“人站在客厅中央”是可以的从“室内”到“海底”就太难为插值了强行生成会出现大量帧间失真。我的经验是首尾帧最好是同一场景下的位置变化、姿态变化或视角变化尽量避免场景类型的跳变。如果必须跨场景就拆成两段生成中间用转场帧衔接。另一个值得注意的点LTX2.3 不会自动读书面语言里的时间概念。“三秒后”“突然”“逐渐”这些词会消耗提示词额度却带不来实际效果。要让 Claude 把时间信息翻译成空间信息——比如“逐渐靠近”翻译成“镜头从远景匀速推近至中景主体在画面中的占比由 20% 增加到 60%”。这才是模型真正听得懂的语言。3. ComfyUI本地部署实操从装环境到出片前面讲完了思路这一节是纯实操。我把最近一次完整跑通视频的流程原原本本记下来每一步都有据可查。环境不同可能会略有差异但整体路径是通用的。3.1 本地环境准备清单照抄就能跑先说硬件底线。我测试用的是一张 8G 显存的 N 卡跑 512×768 分辨率、24 帧、30 步采样单段视频约 40-70 秒生成完毕。如果你只有 6G 显存也能跑但分辨率需要进一步降到 384×576 左右6G 以下就不建议硬撑了体验会很痛苦。软件清单如下Python 3.10 或 3.11注意不要用 3.12部分算子编译会出问题PyTorch 2.x 版本建议按 ComfyUI 官方推荐的组合安装N 卡用 cu121 或 cu124 的 wheelComfyUI 本体直接 git clone 官方仓库然后 pip install -r requirements.txtLTX2.3 模型权重去 HuggingFace 下载放在 ComfyUI/models/checkpoints 或 diffusion_models 目录对应的 VAE 文件和文本编码器文件自定义节点管理器ComfyUI-Manager装插件全靠它comfyui-framepackwrapper 节点这是后面内存优化章节的主角安装过程中最容易出的问题就是依赖冲突。我的建议是全部依赖装在一个干净的虚拟环境里不要和别的 AI 项目混装。我用 venv 建了一个独立环境装完就没再动过它。另外N 卡用户注意检查驱动版本CUDA 版本和 PyTorch 编译版本对不上会直接报错 “torch not compiled with CUDA enabled”这种情况重装 PyTorch 比改驱动快。3.2 一条完整视频工作流的节点拆解在 ComfyUI 里搭工作流本质是把不同功能的节点串成一条采样管线。视频生成的工作流比图片生成多出几个关键节点下面按顺序列出来第一个节点是 Load Checkpoint加载模型。这里加载的是 LTX2.3 的主模型。第二个是 CLIP Text Encode分正向和负向两个正向输入 Claude 生成的完整提示词负向输入“模糊、扭曲、闪烁、低质量、水印”这类词。第三个是 LTX2.3 专用的采样器节点参数包括帧数、步数、CFG、分辨率。第四个是 VAE Decode把潜空间张量解码成像素图序列。第五个是视频输出节点通常会自动将帧序列拼接成 mp4 文件。如果用了 FramePackWrapper采样器和 VAE 之间会多一个 FramePack 节点它做的事情是把连续的帧序列分包处理而不是一次性全部载入显存这一步是解决爆内存的关键。这里有一个新手常见的误解ComfyUI 里数以百计的节点并不是都要用。视频生成这条链路核心节点不超过八个。你只需要理解采样器、文本编码器、VAE 解码器三者的职责剩下的事情就是调参。3.3 关键参数配置与显存权衡参数配置是视频生成最容易被忽视的部分。我见过有人拿着文生图的参数习惯直接套视频结果要么爆显存要么画面质量惨不忍睹。下面这张表是我目前在 8G 显存环境下的推荐配置参数推荐值说明分辨率512×768 或 576×1024分辨率提高对显存占用是指数级增长谨慎上调帧数16-32 帧对应约 1-2 秒内容帧数越高显存占用越大采样步数20-30 步超过 30 步收益很低低于 15 步画面有明显噪点CFG3-5视频模型 CFG 不宜太高6 以上容易色彩过饱和帧率8-16 FPS输出端帧率视觉上 16 FPS 已接近流畅批大小1视频生成极少用 batch 大于 1因为显存根本扛不住关键要理解“分辨率、帧数、步数”三个参数对显存的占用关系。分辨率影响的是单帧的显存消耗帧数影响的是累积状态的内存消耗而步数影响的是时间消耗。实操中8G 显存的机器如果跑 576×1024 分辨率帧数一旦超过 32OOM 概率极大。正确处理方式不是调低步数而是先降分辨率到 512×768再降帧数到 24这样能保住画面质量的底限。3.4 实测让Claude帮我把报错改到跑通这套流程里最有实用价值的一个环节是把 Claude 当成你的“外挂运维工程师”。跑不通的时候别急着盲改参数把完整报错信息拷给它它能快速定位问题方向。我第一次跑通 LTX2.3 时遇到的报错很典型torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.00 GiB. GPU: 8.00 GiB我当时的做法是把这段报错连同工作流截图一起丢给 Claude它给出的判断是采样器 batch 层把 32 帧一次性加载进显存超出容量。解决方案有两个方向——降低帧数到 16或者用 FramePackWrapper 分包。我试了前者的确跑通了但视频只有 1 秒内容根本不够用。于是我又回头安装了 FramePackWrapper这次 32 帧跑完没有报错只是耗时增加了约 30%。类似的报错还有很多比如 “Shape mismatch” 通常意味着首尾帧尺寸不一致“Unrecognized keyword argument dtype” 多半是版本兼容问题。这些坑单靠搜索引擎效率很低但大模型读过大量类似 issue能直接给出对症方案。我的工作习惯是每碰到一个报错就把报错内容 修复方案存进本地笔记反正 Claude 的记忆窗口足够长下次碰到同类问题直接翻旧账。4. 爆内存是常态FramePackWrapper是怎么兜住显存的视频生成比图片生成更吃显存这是物理规律不是软件 bug。但理解爆内存的根本原因才能知道 FramePackWrapper 这类方案到底在解决什么问题。4.1 视频生成时为什么会爆内存图片生成时模型处理的是单张图的潜空间张量。视频生成时模型要同时处理多帧的序列张量维度从二维变成三维数据量成倍增加。更关键的是注意力机制的计算复杂度是序列长度的平方级——帧数翻倍注意力计算的显存占用不是翻倍而是翻四倍。打个比方图片生成是打一发子弹视频生成是打一整梭子弹而你持枪的手臂没有变粗。8G 显存跑文生图绰绰有余跑视频一到 32 帧就顶不住就是这个原因。另外视频模型在 VAE 解码阶段也会出现临时显存高峰。整个序列同时解码中间张量全部驻留在显存里直到写出文件才会释放。这就是为什么有些工作流采样器能跑完但 VAE 解码时报 OOM——瓶颈转移到了最后一公里。4.2 FramePackWrapper的核心思路FramePackWrapper 解决这个问题的思路很朴素不能一次性处理完整序列那就分包处理。它把长序列切成若干个帧包每个包只占一小块显存按顺序推理完毕后把必要信息传递到下一个包同时释放前一个包的中间状态。这个思路相当于把“10 个盘子一次端”改成“一次端 2 个跑五趟”牺牲一点时间换回不爆显存的空间。但分包不能只做“切片”这个简单操作因为相邻帧之间有运动连续性纯切片会把运动切断。FramePackWrapper 的做法是在包与包之间保留重叠帧和条件状态让下一个包知道前面已经发生了什么从而保持动作的连贯性。这才是一个能实际落地的方案。我实测下来用 FramePackWrapper 后显存占用明显平缓——采样器阶段 8G 显存能支持到 48 帧左右VAE 解码阶段也不再是瓶颈了。缺点是生成时间变长48 帧比 24 帧慢了不止一倍但换来的是完整的视频时长这是值得的。4.3 我给FramePackWrapper的推荐配置这个自定义节点装好之后默认参数不一定适配你的显卡需要手动调。结合我在 8G 显存卡上的经验核心参数如下frame_pack_size建议设为 8意思是每 8 帧为一个包。显存小的设为 4显存大的可以试试 12。overlap_frames建议设为 2重叠帧太少会导致包与包之间动作断裂太多则冗余计算增加。cache_mode选“activation”只保留前向传播所需激活值其他中间结果及时释放。precision建议 fp16半精度显存占用减半画面质量损失在可接受范围内。vae_offload打开把 VAE 解码阶段的负载转移到 CPU虽然慢一点但几乎不占显存。配置好之后跑同一段视频显存占用从之前的接近打满降到 70% 左右这个效果在 Windows 任务管理器里看得很直观。如果你用的是一张 8G 显存卡这套参数可以直接抄如果是 16G 以上可以适当提高 frame_pack_size 换取更快速度。4.4 除了FramePackWrapper还有这几个坑要避靠 FramePackWrapper 兜底不代表可以无视其他优化手段。以下三个技巧是我在反复调试中沉淀下来的每一条都实际救过场。第一不要在一个工作流里加载多个大模型。很多人习惯把文生图、视频生成、超分模型同时加载进来ComfyUI 默认会把所有模型驻留在显存。做一个视频只加载一个模型其他模型全部卸载这是最直接的降显存手段。第二VAE 解码要单独跑。实测下来采样完成之后把 VAE 解码从采样流程里拆出来单独执行避开了采样和加载解码同时占显存的高峰期。ComfyUI 的流程可以打断先跑采样再跑解码不会影响结果。第三尽量避开直接播放超长视频。本地部署的视频生成模型每一次推理都有帧数天花板超过上限不是变慢的问题是直接无法执行。想要更长的视频正确思路是分段生成然后后期拼接。我一般让 Claude 生成一个多段分镜表每段独立生成视频最后用剪辑软件拼接配合转场效果体感上就是一条完整的长视频。5. 常见问题速查从衔接抖动到无限生成这部分我按真实碰到的频率整理了一张排查表其他人在评论区问得最多的几个问题也一并收录了。5.1 高频问题排查表现象可能原因解决方法视频中间帧画面突变首尾帧描述不一致或提示词里存在冲突动作用 Claude 统一首尾帧的光线、位置、构图描述CUDA out of memory帧数或分辨率超过显存上限调低分辨率启用 FramePackWrapper关掉多余模型生成的人物五官漂移提示词对角色的外貌描述不够具体在提示词中固定脸型、发色、衣着重复出现同一角色的外貌描述画面像 PPT 切换帧间动作描述缺失模型只能输出静态画面提示词中补上“推近、转身、眨眼”等连续动作词报错 “Shape mismatch”首尾帧图片尺寸不一致批量脚本检查所有首尾帧尺寸统一为同一分辨率生成速度极慢采样步数过高或 FramePack 分包过小步数降到 20-30frame_pack_size 适当调大文字始终是花的LTX2.3 对文字生成能力较弱视频中不要出现较长的文本内容或后期用剪辑工具叠加字幕这些坑基本覆盖了视频生成的 70% 日常问题。剩下 30% 的稀缺问题大概率是模型权重损坏或 ComfyUI 版本不一致引起这时候从头检查依赖版本是唯一出路。5.2 关于“无限生成视频”的一个实践提醒热词里有一条“comfyui 无限生成视频”不少人把它理解成“一次跑出几分钟的完整视频”这不是本地部署的正确打开方式。真正的无限生成是指通过自动化脚本或工作流串联让机器持续不断地批量产出短视频片段而不是让单次推理的时间无限拉长。我在实践中会这样设计流水线Claude 生成一批分镜脚本 → 脚本转成批量提示词文件 → ComfyUI 配合 API 模式依次读取 → 每一段生成独立视频文件 → 完成后自动进入下一段。整个过程中人和机器是解耦的晚上睡觉前启动第二天早上收几十条素材。要达成这个效果关键是将“人工调参”变成“程序编排”而 Claude 在其中扮演的就是批量脚本生成器的角色。综合这几章的内容你会发现 AI 视频生成的可控性比想象中高得多。它不是一个全自动的黑箱而是一套需要你理解原理、配置参数、排查错误的系统工程。Claude 在其中承担的是规划与修复的智力劳动LTX2.3 承担的是生成画面的计算劳动真正拿主意的人还是你自己。我个人在实际操作中的体会是不要迷信“一键出片”把时间和精力花在提示词设计和参数理解上产出质量的提升是立竿见影的。最后再分享一个小技巧——出批量视频时把每一条提示词和它对应的输出视频放在同名的 txt 和 mp4 文件里归档之后回看特别方便。希望这套流程能帮你在本地稳定跑起来少走几步我曾经绕过的弯路。