本地做视频，15秒之后才是开始
杂货铺 · 第055篇
欢迎来到我的小铺，今天聊聊视频。
作为我的第三块积木，起源于画了那么久的静态图，看着屏幕里那些被千问一帧帧渲染出来的场景和角色，心里难免会冒出念头：要是他们能动起来就好了。一首歌的 MV，一个小故事的视觉 PV，或者带着某种情绪的短片，这些想法其实在备忘录里躺了挺久。
之前一直没怎么动，主要还是门槛太高。早期的开源视频模型不是动作抽搐，就是显存和算力要求高得吓人，跑一段要等到地老天荒。
直到 MiniMax H3 出来，经开源社区一步步把它优化到 INT8 量化，在本地跑视频的总算落到了一个“时间上等得起、真正能拿来用”的区间。
既然工具接得上茬了，我就借着手头刚跑完的两个小样——一个 15 秒的单镜头尝试，一个 90 秒（一分半钟）的完整小短片，来聊聊现在用本地算力做视频，到底是个什么样的实际体感。
15 秒的单镜头：把一个想法一口气说完整
做视频的第一步，我选了一个尽量不涉及复杂因果、但情绪很足的小片子，叫《风把秋天翻出来》。
画面很简单：一张老旧的书桌上摊着一本旧书，页脚落着一片枯黄的叶子。风吹过来，书页微微颤动，叶子打着旋儿从纸面上滚过去；滚过的痕迹变成细密的铅笔线条，线条在纸上分叉、蔓延，最后晕染成一片秋天的水彩树林。叶子在树下落定，风停，书页重新平复。
这段跑的是本地部署的 MiniMax H3 Base（FL2VA 的 INT8 量化版），走纯文生视频，采样设为 20 步。
我特意想测的是它的“声画一体”。输出规格定在 960×544、24 帧，一共 362 帧，折算下来是 15.08 秒。在单台 DGX Spark 上，从任务开始加载模型、采样到最后编码保存，一共用了 31 分 38 秒。
用半个小时出 15 秒的镜头，随点随出肯定谈不上，但对我这种把提示词写好、扔给机器慢慢跑的用法来说，完全是可以接受的。
这 30 多分钟换来的体感相当好。由于没有镜头切换，也不用在不同场景之间记忆逻辑，模型在 15 秒的单一时空里把动作表现得很自然：纸张的翻动声、风声、随着线条蔓延出来的轻音乐，和画面是同步长出来的。
这个小样让我大致摸到了底：只要把空间和概念收敛在一个单镜头内，本地模型已经完全有能力把一段微小的情绪，一口气表达得很完整。
90 秒的尝试：把镜头、动效和音乐拼起来
有了这 15 秒的底气，下一步自然就是把时间拉长。但做长片从来就不是单镜头能解决的，它从一开始就是一项拼图工程：分镜怎么切、动效怎么衔接、两头怎么借力关键帧、音乐怎么通盘铺设，都要一起考虑。
第二段片子叫《失物招领处，收留了一场雨》。故事设定偏童话感：一把被遗失在角落的雨伞，伞尖上的雨水滴进地上的铁盆；有人走过去把它拿起来、撑开，画面顺势溶入一段雨天的回忆，最后回到现实，伞被重新收好、挂在墙上。
为了把它做出来，本地几个模型做了明确分工：
- 画关键帧：千问 Qwen-Image-2.1（UC Q8 版本，40 步采样，出 1280×736 的底图，一张大概跑一分钟左右）；
- 跑动效：换成了更轻量的 FastH3（8 步 INT8 版本，单段 9 秒左右的镜头，耗时压缩到了 7 到 8 分钟）；
- 做配乐：让 YuE2 单独生成一段完整的器乐；
- 剪辑组装：全拿回 Mac 上，用 FFmpeg 做画幅裁切、节奏对齐和转场。
两台 DGX 成了后台车间，分头出图、出视频。然而当所有片段被拉进时间线时，多镜头拼接的麻烦就集中暴露出来了，主要就卡在三类问题上：
一是空间前后不一致。单张看都挺好看，但镜头一换，桌上的物件位置就对不上了；
二是动作交代有断层。伞上一秒还在桌上，下一秒就直接撑开在手里，中间拿起来、打开的动态被模型直接省掉了；
三是首尾状态的扭曲与镜头接缝生硬。
解决这些问题并没有什么捷径，主要是通过流程上的约束把它扳顺：
- 用首尾帧定边界：光说一句“把伞打开”，模型很容易自由发挥。先用千问把动作“开始”和“结束”的两张底图画死，逼着视频模型只在两张图之间做过渡，动作就规整多了；
- 拆细动作与景别取舍：把大动作拆成拿起、开伞、收伞几个分段镜头；遇到模型局部生成不自然的地方，直接用 FFmpeg 裁成近景特写，避开破绽；
- 顺着音乐找剪点：让 YuE2 的音乐铺满整条轨道，画面动作顺着节拍去切，在需要过渡的地方加上半秒轻微的溶接，让转场不那么突兀。
最后导出的这版 90 秒成片，一共拼了 11 个镜头。它依然还有进步的空间，但至少，整部小片子的视听逻辑和动作起伏，终于能完整顺畅地走下来了。
规格、成本，以及本地算力给的体感
聊完制作过程，再聊聊画质规格和实际的运行体感。
这次跑出来的视频，我定在 960×544，差不多在 540P 左右。我没有去选最低档的 320P，因为那种分辨率下水彩和纸张的质感基本糊成了马赛克；但我现在也没强求 1080P 甚至 4K。
从实际体感来看，在目前的算力下，不到 720P 的这个规格是一个非常舒服的平衡点。画面细节和氛围感已经完全能够立得住。至于更高的清晰度，后面可以通过超分辨率模型来做增强，但这个事情不能颠倒——动效逻辑和镜头接缝没搞好，就算直接跑出 4K，也只是一堆高清的破绽。先把内容跑顺，再去琢磨超分的事。
另外一个更深层次的体感，是关于成本。
现在去线上用商业 API 跑视频，价格着实太高了。商业平台通常是按秒、按次计费。像做这个 90 秒短片，为了把一个开伞动作调顺、把空间位置纠正过来，中间免不了要推翻重来。如果这一切都在公有云上按次扣费，那做片子的时候整个人会极其紧绷，哪怕看到瑕疵，可能也会下意识地妥协：“算了，凑合用吧，再刷一次又是几十块钱。”
而在本地跑，最大的体感优势就是“重来的自由”。
确实，本地并不意味着“随点随出”。改一个 9 秒的镜头要等七八分钟，要试出一套满意的分镜，一天时间就在后台一次次的排队里耗过去了。但机器就在自己手边，电费是恒定的，我不需要为每一次的试错去心疼钱包。
音乐做好了，整条音轨安稳地趴在 Mac 上不用动；画面哪个镜头出了毛病，我就让 Agent 去调指令、重跑关键帧，单点爆破那一个镜头。
这种感觉跟上一篇我聊做图是一脉相承的。环境配置、脚本执行、FFmpeg 剪辑命令行，依然是 Agent 在后台默默做；我负责当那个挑剔的导演兼场记，一遍遍看，挑出哪里不对，再告诉它继续调整。
从最初看着静态图心痒，到如今能把一首歌的配乐和一段一分半钟的动画拼到一起，本地视频这条路算是在我这里走通了第一步。
以后肯定还要继续往前试，做更复杂的 MV，或者人物更多一点的故事短剧。但在那之前，还是先把眼前的事情磨扎实：
先让这把伞好好地打开，再好好地收起来。
感谢阅读。