背景痛点：视频大模型推理的三座大山
做视频生成/修复的朋友都懂，把 30s 的 1080P 片段塞进大模型，就像把大象塞进冰箱——门都关不上。显存爆炸、计算冗余、前后处理拖后腿，三条“大山”把机器卡得明明白白：
- 显存爆炸：按 8bit 估算，单帧 1920×1080×3 约 6 MB，一秒 30 帧就 180 MB；模型本身 8-10 GB 起步，再留 PyTorch 的缓存，24 GB 卡直接报警。
- 计算冗余：相邻帧差异极小，却逐帧完整推理，90% 算力花在“复制粘贴”。
- 前后处理耗时：解码、对齐、色彩空间转换、编码回写，CPU 单线程跑，GPU 空转等数据，A100 也只能干瞪眼。
一句话：不拆流水线，就别想实时玩视频大模型。
技术对比：为什么选 ComfyUI 而不是 Gradio/Streamlit
| 维度 | ComfyUI | Gradio/Streamlit |
|---|---|---|
| 工作流描述 | 节点图 JSON，可热重载 | Python 脚本写死，一改全重启 |
| 动态调度 | 节点级并行，支持条件分支 | 整页级阻塞，只能线性跑 |
| 显存复用 | 内置缓存池，引用计数 | 无，用户自己 malloc/free |
| 多 GPU | 节点绑定 device，拓扑可配置 | 需手写 multiprocessing |
| 生态 | 视频/扩散模型现成节点 200+ | 基本靠社区 gradio-apps，视频节点稀少 |
结论：Gradio 适合“秀 demo”，ComfyUI 才像“产线 PLC”，节点随时插拔，才能把视频大模型拼成流水线。
核心实现：30 行代码搭一条“分帧-推理-后处理”产线
1. 目录约定
comfyui_custom_nodes/ └── video_llm_nodes/ ├── __init__.py ├── nodes.py # 自定义节点 └── utils.py # 显存池、批处理辅助2. 自定义节点骨架（nodes.py）
from typing import Tuple import torch import comfy.model_management as MM from comfy.nodes import CLIP, VAE, Conditioning class VideoFrameSplitter: """ 把视频按指定间隔拆成 tensor list，支持跳帧。 返回 List[torch.Tensor] 供下游 batch 推理。 """ def __init__(self): self.cache = {} # 显存复用池 @classmethod def INPUT_TYPES(cls): return {"required": {"video": ("VIDEO", ), "skip_frames": ("INT", {"default": 2, "min": 1})}} RETURN_TYPES = ("IMAGE_LIST",) FUNCTION = "split" CATEGORY = "video_llm" def split(self, video: torch.Tensor, skip_frames: int): key = f"{video.data_ptr()}_{skip_frames}" if key in self.cache: return (self.cache[key],) # 简易跳帧采样 indices = torch.arange(0, video.shape[0], skip_frames) frames = video[indices].to(MM.get_torch_device()) self.cache[key] = frames return (frames,)class BatchInference: """ 把 IMAGE_LIST 打包成 batch，调用扩散模型，支持动态 batch_size。 内部用 torch.cuda.empty_cache() 做显存保护。 """ def __init__(self): self.max_bs = 8 # 默认安全值，后面会跑 benchmark 调优 @classmethod def INPUT_TYPES(cls): return {"required": {"model": ("MODEL",), "image_list": ("IMAGE_LIST",), "batch_size": ("INT", {"default": 4, "min": 1, "max": 16})}} RETURN_TYPES = ("IMAGE_LIST",) FUNCTION = "infer" CATEGORY = "video_llm" def infer(self, model, image_list: torch.Tensor, batch_size: int): device = MM.get_torch_device() results = [] for i in range(0, len(image_list), batch_size): batch = image_list[i:i+batch_size] with torch.no_grad(): out = model(batch) results.append(out.cpu()) # 立即搬回 CPU，释放显存 if MM.is_nvidia(): torch.cuda.empty_cache() return (torch.cat(results),)把上面两个节点拖进 ComfyUI，连线顺序：
VideoFrameSplitter → BatchInference → VAEEncode → ... → SaveVideo
就能跑通 1080P 视频，节点图如下：
性能优化：batch_size 与 TorchScript 的双线提效
1. VRAM-Throughput 权衡曲线
在 RTX 4090 24 GB 上实测，模型 7.8 GB，输入 1920×1080，不同 batch_size 结果：
| batch | 峰值显存 | 推理 FPS | 备注 |
|---|---|---|---|
| 1 | 9.1 GB | 2.3 | 安全但慢 |
| 4 | 13.4 GB | 7.8 | 日常推荐 |
| 8 | 21.9 GB | 9.6 | 接近打满 |
| 16 | OOM | — | 爆显存 |
结论：把 batch_size 设成“最大安全值 -1”即可，ComfyUI 的 BatchInference 节点留 1 GB 余量，基本不会炸。
2. TorchScript 边缘部署
模型训练完先转 Script，再塞进 ComfyUI：
# trace_example.py from torch import jit import torch dummy = torch.randn(4, 3, 1080, 1920).to("cuda") model = load_my_video_model() scripted = jit.trace(model, dummy) scripted.save("video_model_ts.pt")在节点里把torch.jit.load当普通nn.Module用即可，推理延迟再降 18%，CPU 回退时也能跑。
避坑指南：多 GPU 与帧对齐的血泪史
- 多 GPU 序列化陷阱
ComfyUI 默认用cuda:0，若手动把某些节点绑到cuda:1，中间数据会走 CPU 复制，速度反而腰斩。解决：提前在节点__init__里把 tensor 转成pin_memory，并启用non_blocking，节点图里尽量让上下游在同卡。 - 帧对齐 & 内存泄漏
视频抽帧后用 list 缓存，如果忘记del self.cache[key]，跑长视频会吃光 RAM。建议：- 在节点
__del__里显式清空； - 或者在 ComfyUI 的
ExecutionBlock结束信号里回调清理。
另外，解码器（pyav/torchvision）一定加seek_keyframe，否则音画不同步，后期对齐能把人逼疯。
- 在节点
代码规范小结
- 所有 Python 文件严格 PEP8，80 列宽，黑盒函数必须写 docstring + 类型标注；
- 显存敏感函数用
torch.cuda.synchronize()前后打时间戳，方便后续 benchmark； - 节点返回值统一用 Tuple，即使单输出也写成
(image,)，防止 ComfyUI 解析器误判。
留个思考题：节点级弹性扩缩容怎么做？
目前 batch_size 是手工调，如果节点能根据队列长度、显存占用自动把max_bs涨上去，再缩回来，整条流水线就真正“无人值守”了。你有啥好思路？欢迎评论区一起头脑风暴！
