ComfyUI 在视频生成后卡死：恢复指南

AI 概览

为什么 ComfyUI 在视频生成后会卡死？

采样器（sampler）可能已结束，但解码、编码、预览传输、自定义节点或浏览器仍处于阻塞状态。在重启任何组件前，请先将缓慢的最终阶段与已崩溃的后端区分开来。

如何判断 ComfyUI 是否仍在运行？

需综合查看终端日志、GPU 利用率、队列状态及输出文件夹。若日志持续更新、GPU 处于活跃状态，或输出文件大小正在增长，则表明仍在工作；若堆栈日志停滞不变、GPU 设备空闲，则很可能已卡死。

ComfyUI 卡死时是否应清空 VRAM？

仅在保存证据并安全取消任务之后执行。释放模型可能使健康进程恢复，但无法修复已损坏的 CUDA 上下文、不兼容的自定义节点或失败的编码器。

最快且安全的修复方法是什么？

保存当前工作流与日志，停止当前运行中的提示（prompt），重启 ComfyUI，并运行一个已知可稳定工作的极简视频图（tiny known-good video graph）。随后分组逐步还原原始节点，直至卡死现象再次出现。

确定实际卡死的位置

“ComfyUI 在视频生成后卡死”这一描述可能对应四种不同故障：画布（canvas）停止更新但后端仍在运行；采样器已完成，但 VAE 解码或视频编码仍在进行；Python 进程仍存活，却在等待某个自定义节点返回；或 GPU 驱动程序已无响应。这些情况在浏览器中表现相似，但需采用不同的修复策略。

首先记录最后可见的节点名称及终端中最后一行日志。切勿立即关闭所有窗口。一次有效诊断需包含以下信息：工作流 JSON、ComfyUI 与前端版本、各第三方节点版本、Python / PyTorch 版本、CUDA 版本、GPU 驱动版本、GPU 型号、启动参数、分辨率、帧数、编码格式，以及最近 30–50 行日志。

是前端卡死还是后端卡死？

打开输出文件夹，检查是否有文件正在被创建，或其大小是否正在变化。在不提交新提示的前提下，观察 GPU 利用率与显存占用。若终端日志仍在持续输出进度，而浏览器界面看似冻结，则只需在保存工作流后刷新前端即可。若终端日志静止、GPU 利用率为零、且队列始终无法推进，则应视为后端卡死。

使用小尺寸、视觉清晰的基准场景，有助于在恢复复杂图之前快速判断管线是否能完整执行。

采样完成 ≠ 输出交付完成

视频图常在扩散过程结束后执行大量高开销操作：解码潜在帧（latent frames）、合并批次、跨设备移动张量（tensor）、插值、写入音频、封装容器（encode the container）。因此，进度条显示 “100%” 仅表示采样阶段完成，并不意味着 MP4 文件已生成完毕。请务必确认最后一个执行完成的节点，而非简单假设 “100%” 就等于卡死。

重启前务必保留证据

重启是一种恢复手段，而非诊断行为。在执行重启前，请先导出工作流并复制终端全部文本。注意记录：是整个操作系统卡死？仅浏览器无响应？还是仅某一项队列任务停滞？全系统级锁死更可能指向驱动程序、CUDA 后端、不稳定超频、供电不足或内存压力问题，而非单个标签页无响应。

请创建一份精简的事件记录：

ComfyUI / 前端版本：
Python / PyTorch / CUDA / 驱动版本：
GPU 型号与系统内存：
启动参数：
工作流与模型：
宽 × 高，帧数，批大小：
最后完成的节点：
终端最后一行日志：
浏览器状态 / 后端状态 / 操作系统状态：
首次运行即失败，还是重复运行后失败：

在不信任结果的前提下保存部分输出

若 MP4 文件已存在，请在视作完成前先检查其时长与音视频流。截断的容器（truncated container）可能可以打开，但提前终止；图像序列（image sequence）可能帧数少于请求值。请将该不完整产物以故障专属名称保存，避免下一次运行覆盖关键证据。

ComfyUI 视频裁剪与音频同步指南 解释了为何视频与音频路径应保持显式分离。这种分离同样有助于定位卡死发生于复用（muxing）之前，还是发生在最终编码环节内部。

降低内存与编码压力

视频生成会因分辨率、帧数、批大小、潜在通道数、VAE 解码、插值及编码等多维度叠加而显著加剧内存压力。降低其中任一维度，往往比随机开关各类内存标志更具诊断价值。建议优先将帧数减半。若图仍卡死，再降低分辨率；随后禁用插值、上采样及可选预览，同时保持基础模型与采样器不变。

使用分阶段内存测试

按顺序执行以下测试，并记录每项是否成功完成：

1. 以工作流支持的最小分辨率生成一段极短视频。
2. 使用相同片段，启用目标 VAE 与解码器。
3. 使用相同片段，启用目标编码器但禁用插值。
4. 在短时长下运行完整的后处理链（post-processing chain）。
5. 仅当上述所有阶段均通过后，才尝试目标时长。

切勿在同一测试中同时提高分辨率与帧数。若短片段可成功，而长片段反复卡死于解码阶段，则说明图本身可行，但内存分配或解码策略存在问题。若连最小图都无法运行，则应在调优画质前优先排查兼容性问题。

使用细节丰富但时长较短的素材测试解码稳定性；时长与分辨率应分别独立提升。

避免掩盖驱动故障的“伪修复”清除模型内存、卸载预览图，或重启前端，有助于健康的后端释放资源。但这些操作无法重置每一个失败的 GPU 上下文。如果整个桌面锁死、终端无 Python 异常即停止响应，或显卡驱动重置，请先使用最小化的官方工作流（minimal official workflow）和保守的硬件设置复现问题，再归因于提示词（prompt）。

对于模型文件与解码器（decoder）不匹配的问题，请参考 VAE 加载检查清单。一个被重命名或放错位置的文件，并不会仅仅因为加载器能“看到”它，就自动转换为兼容的 VAE。

隔离自定义节点与前端状态

自定义节点会引入 Python 包、编译扩展、UI 代码、编码器（encoders）以及设备管理行为。一次性更新全部内容，将破坏可用于定位根本原因的对比基础。请先保存当前可正常运行的环境，然后禁用所有第三方节点，并运行针对相同媒体类型、最小化的核心工作流（core workflow）。

若核心图（core graph）成功执行，则按功能分组依次重新启用自定义节点：模型加载器 → 条件控制工具 → 视频工具 → 插帧 → 超分 → 编码器。当故障重现时，对该组再次细分。请记录节点仓库地址及具体 commit 哈希值，而不仅依赖其显示名称。

单独测试浏览器

前端可能停止显示进度，而后端仍在后台完成任务。请尝试在全新浏览器标签页中重新连接，并在终止 Python 进程前检查队列（queue）或历史记录（history）。一次测试中可禁用浏览器扩展；避免同时打开多个承载重型工作流的标签页；并比对前端版本与后端版本是否一致。若画布刷新后状态恢复，这表明是显示状态（display-state）问题，而非 GPU 冻结的证据。

完整流水线执行完毕后，交付帧应仍保有可信的皮肤质感、蒸汽效果、食物纹理及细微的手部细节。

运行已知可用的恢复工作流

安全重启后，切勿立即提交完整的生产级图（production graph）。请先使用此前已在本机成功运行过的极简工作流：仅含一个模型、一段短片、无任何可选自定义节点、无插帧、无超分、且采用标准编码器。该步骤旨在回答最关键的问题——当前安装的视频技术栈（video stack）是否整体可用。

src=https://r2.seedance.tv/blog/comfyui-freezes-after-video-generation/known-good-motion-baseline-v1.mp4
poster=https://r2.seedance.tv/blog/comfyui-freezes-after-video-generation/known-good-motion-baseline-poster-v1.jpg
label=ComfyUI 恢复测试用短时已知可用运动基线

五秒的动态输出已足以验证生成、解码、编码及播放环节是否正常，之后再重建高开销图（expensive graph）。

按检查点逐步恢复图结构

为每个检查点保存一份 JSON 文件：01-core、02-loader、03-conditioning、04-post 和 05-final。诊断期间每次仅提交一项任务。当某检查点失败时，将其终端输出与上一个成功检查点的输出进行比对，并移除新加入节点中的一半。这种二分搜索法（binary-search approach）比无假设地反复修改参数更快。

若队列（queue）本身即为问题根源，可参考 ComfyUI 批处理指南，其中提供了更安全的独立任务模式：明确指定输出文件名、支持断点续跑的批处理机制。单个任务失败不应迫使您重复运行所有已批准的片段。

选择本地恢复或托管工作流

本地 ComfyUI 的价值在于：需精确控制所用节点、自定义模型、可复现的环境配置，以及对机器的直接访问权限。但这也意味着您须自行负责显卡驱动兼容性、Python 依赖管理、自定义节点的 commit 版本、内存规划、日志记录与重启操作。正确选择取决于：这些控制能力是构成创意优势的核心要素，还是仅属生产过程中的额外负担。

本地 vs. 云端 AI 视频生成指南 提供了一套实用决策框架。当工作流图本身即为可复用资产，且有人专职维护时，请坚持本地部署；当团队主要需求是获得已批准镜头、保持参考一致性、确保可预测的重跑结果，以及聚焦交付而非持续修复环境时，则应选用托管方案。

Seedance Agent 的定位

Seedance Agent 可将参考素材、镜头计划、审批记录与重跑请求绑定至具体生产任务，无需编辑人员维护庞大的本地依赖图。它不能修复损坏的本地 ComfyUI 安装；而是在诊断显卡驱动、节点或编码器所耗成本高于“通过托管工作流重跑受影响镜头”时，提供一条替代性的生产路径。

有效的交接应是选择性的：保留已批准的提示词（prompt）、源图像、宽高比、时长、运动要求，以及失败镜头的证据。仅重新生成被拒单元，再依据同一验收清单（acceptance checklist）比对，最终将通过审核的镜头返回剪辑流程。

结论

当 ComfyUI 在视频生成后冻结时，请首先判断是浏览器、后端、后处理节点、编码器、GPU 驱动，还是整个操作系统停止响应。保存工作流与日志，测试极简的已知可用片段，优先降低帧数再调高分辨率，按功能组隔离自定义节点，并通过命名检查点（named checkpoints）逐步恢复图结构。若本地维护已不再带来有效控制力，请将下一个已批准镜头迁移至受管的 Seedance 工作流 →[/]