03 · 本地视频生成与内存墙

系列:mac mini ComfyUI 实战(03/07)· 教程型 · 阅读时长约 15 分钟 读者定位:已按 01/02 篇装好环境、跑通文生图的读者;想在 Mac 上把静图做成视频的创作者。需命令行基础。 实测环境:Mac mini M5 Pro / 64GB 统一内存 / macOS 27.0 · ComfyUI v0.36.0(01 篇锁定表配方)

导读:02 篇拿到系列第一个产出物——图;本篇拿第二个——视频,也是三个模态里最重的瓶颈。兑现前三篇的六个承诺:静图变镜头(02)、61GB/64GB 内存墙实测(02)、降档策略(02)、能力边界视频侧完整展开(02/01)、坑 9 内容层展开(01)、劣化系数推导与逐段拆解(00)——清单见开篇。先给结论:打样 544 档、生产 768 档、1088 不可批量——采样 2:20:24 中断于解码段,未产出成品。

实测声明:文中全部数字来自 Mac mini M5 Pro / 64GB 真机实测,锚点 2026-09-24~26;「总表/实验日志」指本系列实测数据底稿。本文由 AI 辅助创作,经人工审核编辑后发布(完整声明见文末)。

开篇:第二个产出物——视频

02 篇说过队列的那句纪律:先提交图任务,再提交视频任务。这一篇讲的就是那个「视频任务」——系列的第二个产出物,也是三个模态里最重的瓶颈:一段 5 秒视频(768 档)要 33 分钟,生成耗时是成品时长的 396 倍(总表 §2.4;对照:40 秒 BGM 只要 10.9 秒)。

本篇兑现前三篇留下的六个承诺:

1. 把静图变成动起来的镜头(02 篇结语)→ 第一章
2. 61GB/64GB 内存墙实测(02 篇结语)→ 第二、三章
3. 视频生成的降档策略(02 篇结语)→ 第四章
4. 能力边界视频侧完整展开(02 篇第三章)→ 第五章
5. 坑 9 视频内容层展开(01 篇)→ 第五章
6. 劣化系数推导、逐段拆解、机制解释与验证计划(00 篇四处「见 03 篇」)→ 第二、三章

先给结论,三句话:打样验证用 544 档,303 秒出结果;批量生产定 768 档,33 分钟一段;1088 全尺寸不可批量——采样 2:20:24 后中断于解码段,未产出成品。本篇的全部数据,就是支撑这三句话。

一、H3 图生视频工作流:怎么接

图生视频(i2v)的输入是一张首帧图加一段运动提示词。首帧怎么来,02 篇已经解决:四段式提示词出候选,每镜 3-4 张,人工挑一张定稿。本篇从首帧之后讲起:这张静图怎么变成 5 秒的镜头。

接线配方(实测投产配方,节点名与参数逐字来自实验日志,分四组读):

① 加载组:UNETLoader 加载扩散模型 minimax_h3_fl2va_pruned_int8_convrot(H3 int8 量化版,20GB 级),输出 MODEL;CLIPLoader 加载文本编码器 qwen3vl_32b_nvfp4(type 选 minimax),输出 CLIP;VAELoader 加载视频 VAE minimax_h3_video_vae_fp16,输出 VAE;LoadImage 读入首帧。

② 打包节点(本工作流的核心):MiniMaxH3ImageToVideo——输入为 CLIP + VAE + prompt(运动提示词)+ W×H(32 倍数)+ length(帧数)+ first_frame(首帧),输出 COND + LATENT。

③ 采样链:RandomNoise(seed)→ KSamplerSelect(euler)→ BasicScheduler(simple,4 步)→ BasicGuider(接加载组的 MODEL 与打包节点的 COND)——四路加上 ② 输出的 LATENT,一起进 SamplerCustomAdvanced。

④ 输出链:SamplerCustomAdvanced → VAEDecode(用加载组的 VAE)→ SaveWEBM(vp9,25fps)。

和 02 篇的 Z-Image 三件套对比,有两个结构差异值得注意。

差异一:采样器拆开了。 Z-Image 用一个 KSampler 一站式搞定;H3 把噪声、采样器选择、调度、引导拆成四件(上面第 ③ 组),拼进 SamplerCustomAdvanced 自由采样链。4 步质量实测达标。

差异二:条件是打包的——这就是「无负面词入口」的结构原因。 Z-Image 那边是 CLIPTextEncode 正负两条接线;H3 这边,提示词和首帧一起进 MiniMaxH3ImageToVideo 节点,输出 COND+LATENT 打包进 BasicGuider——界面根本没有负面词接线(总表 §三:conditioning 打包,蒸馏模型)。02 篇说过这是两种实现,本篇给视频侧的实操含义:约束只能正向表述。不想让画面出现什么,没有第二个输入框可写,只能靠首帧锁定和正向描述。

由此得到本篇的提示词范式——两段式:静态身份由首帧锁定,运动提示词只写「动什么」。

下面是本系列 31 秒宣传片镜 3 的运动提示词(执行包实测定稿版,照抄;对应首帧为该镜定稿图):

盒顶光柱中的微光粒子缓缓上升,光柱辉光一次比一次更亮地脉动扩张;太阳辉光同步增强,暖光渐渐扩散照亮整间暗室;轨道上的微小光点加速运行。镜头从盒顶低角度缓缓上摇,跟随光柱一路升至太阳,气势上扬、迸发振奋。

注意这段词里没有一句在描述「盒子长什么样、太阳长什么样」——静态外观全在首帧图里。运动词只写三类内容:哪些东西在动(粒子、辉光、光点)、怎么动(上升、脉动、加速)、镜头怎么走(低角度上摇)。这是本系列实测沉淀的写法。

参数逐个说:steps=4(蒸馏模型,质量实测达标);length=125 ≈ 5 秒(25fps;打样档 61 帧 ≈ 2.4 秒);seed 沿用 02 篇三条纪律——固定可复现、候选递增、同 seed 重跑记 pid 查 history。

分辨率是硬性限制:宽高必须是 32 的倍数。 01 篇坑 5 给过现象与根因,这里给工作流里的落位。根因:H3 的 VAE 做 16× 下采样,patch 再做 2×2 切分,宽高像素必须被 16×2=32 整除。1080÷32=33.75,不整除——patchify 的 reshape 直接崩(报错原文:shape '[1, 24, 1, 1, 60, 2, 33, 2]' is invalid for input of size 192960——shape 乘积与输入元素数不符,reshape 无法完成);1920=60×32 合规,所以只有宽炸。

落位成三条操作:①三档分辨率 544×960、768×1344、1088×1920,宽高全是 32 的倍数,照抄即可;②分辨率选择器节点的「倍数」参数必须设 32——设 60 会得到 1080×1920,复现此崩;③要 1080 宽的成片,生成用 1088(=34×32),后期裁掉 8px。另注意:文生图 Z-Image 没有这条硬限制,它的是 latent 8 像素对齐、静默取整(02 篇)——一个是硬崩,一个是静默改尺寸,两套规则别混。

最后是命令行入口:

python3 comfy_api.py i2v --prompt-file 运动.txt --image 首帧.png --seed 31003

脚本默认就是 768×1344、125 帧、4 步(生产档参数);打样档显式传 --w 544 --h 960 --length 61。脚本与 02 篇配套文件为同一份(内置 i2v 子命令;早期版本未必含,请获取最新版),获取方式详见「阅读原文」。队列提醒沿用 02 篇:i2v 是大任务,一段 33 分钟起步,提交前确认队列里没有排它前面的图任务。

二、速度实测:两档完成,1088 中断记录

同一模型、同一采样配置(H3 i2v,4 步,euler/simple),只改分辨率与帧数——两档跑完、1088 中断,实测记录如下(总表 §2.2):

分辨率 × 帧	每步耗时	整段耗时(含解码)	内存水位	判定
544×960 × 61 帧	46.07s	303s	健康	快速打样档
768×1344 × 125 帧	416.82s	≈33 分钟	健康	生产定档
1088×1920 × 125 帧	2010.68s(平均;首步 1892.84s)	采样 2:20:24,中断于解码段,未产出成品	61.29/64GB(95%)	不可批量

表头口径先说清:544 打样档是 61 帧(约 2.4 秒),768/1088 是 125 帧(约 5 秒)——总表标题里的「5 秒/段」是统称,精确到档位是这两个帧数。素材归属补充一句:544 打样样片与 1088 全尺寸出自同一镜头(镜 3,分别作测速与质量基准);768 档速度出自 9-25 晚的六镜批量生产,实验日志未把该计时归属到具体镜次。

两条表注,都是读数纪律。

注一:整段耗时含解码,不等于每步耗时×4。 544 档 46.07×4=184s,整段 303s;768 档 416.82×4≈1667s,整段约 33 分钟。解码与开销占了不少比例,拿每步耗时乘步数估总时长会偏低。

注二:1088 档的「每步耗时」与「采样总长」不严格相乘——00 篇留下的「逐段拆解」欠账,在此兑现。 逐段看:首步 1892.84s,4 步平均 2010.68s,平均较首步劣化约 6%(日志原文简写作「逐步再劣化 ~6%」);采样总长 2:20:24,另含其他开销——平均每步×4 不等于总长。

1088 这次任务本身的口径也要立清楚:它跑的是质量基准样片,采样 2:20:24 后中断于解码段,未产出成品。本系列对 1088 档只记录中断事实——不推荐、不验证可完成性、不推测中断原因。判定就三个字:不可批量。

档位的用法分工是操作结论:544 打样,768 出正片。一段 768 档 33 分钟,如果运动提示词写错、镜头走向不对,试错成本就是 33 分钟;先在 544 档花 303 秒验证运动效果,对了再上 768——把试错成本压到 5 分钟。

批量生产的总账:31 秒宣传片的视频产线 10 段(768 档,含两次改版重 roll),机器时间约 6 小时(总表 §2.5),按挂机规划。另一笔账单独记:9-25 晚当批六镜 7 段约 3.5 小时、全部成功零失败(实验日志 §2.2,当批口径:均时约 30 分钟/段,与 768 档 33 分钟量级一致;7×33≈3.85 小时与 3.5 小时的差值属当批实测波动,以日志凭证为准)——与全程 10 段约 6 小时是两笔账,不要混。

收束到跨模态:音乐 1:0.27 实时,图像分钟级,视频 1:396 实时(总表 §2.4)——视频是当前 Apple 芯片本地 AIGC 的绝对瓶颈。瓶颈的机理,下一章拆。

三、内存墙:超线性劣化实测与机制分层

内存墙,本系列口径指:内存占用逼近物理上限后,耗时出现远超计算量比例的劣化。先把事实摆出来,再谈劣化,最后分层谈机制。

常驻:H3 全家同时驻留内存约 40.5GB——扩散模型 19.99GB + 文本编码器 14.96GB(常驻 CPU)+ 视频 VAE 4.97GB + 音频 VAE 577MB(约 0.58GB)(00 篇 5.1 体量账,控制台实测凭证;音频 VAE 是 04 篇 AV 双路的组件,这里只作内存分项出现,不展开)。

峰值:1088 档采样中,活动监视器显示物理内存已用 61.29/64GB(95%),内存压力仍是绿色,进程未崩(2026-09-25 凭证)。这就是内存墙的实测层:满水位不会让进程崩溃,但足以让批量生产失去可行性。

劣化有多超线性?两个系数,各注基准。(兑现 00 篇「推导见 03 篇」)

以 768 档为基准(像素口径,两档同为 125 帧):1088 档像素量是 768 档的 2.02 倍(2088960÷1032192),每步耗时却是 4.82 倍(2010.68÷416.82)——劣化系数 4.82÷2.02 ≈ 2.4。

以 544 打样档为基准(计算量口径):计算量 = 面积 4 倍 × 帧数 2.05 倍(125÷61)≈ 8.2 倍;每步耗时 = 1892.84÷46.07 ≈ 41.1 倍(1088 首步口径)。劣化 = 41.1÷8.2 ≈ 5.0;总表与 00 篇写「约 5.1」,按计算量 8 倍的整数口径取整(41.1÷8≈5.1)——5.0 与 5.1 两种取法,同为「约 5 倍」。

两个系数口径不同、都真:引用任何一个,必须注明基准,禁止混用(系列既定裁定)。基准不同的两个系数,互相不可换算,也不可拿来互相对照。

变慢的机制,分两层说。(00 篇承诺的「机制解释与验证计划」)

实测层,就是上面这些:61.29/64GB 占用、内存压力绿、进程未崩、耗时超线性。机制层——「大张量在内存层级间反复搬运,而非计算变慢」——这是推断:它是对「占用满 + 超线性劣化」的合理解释,但本系列未做 Instruments 级验证,推断不升格为实测。

验证计划随之明确:Instruments 级的内存带宽与时间剖面分析,列为待验证项(00 篇说「03 篇继续验证」,进展到此)。现有的旁证是降档实验本身——768 档内存回落到健康水位,每步耗时超线性回落。旁证支持「内存主导」这个假设,但旁证不等于机制证实。

这一章的结论,承接 00 篇的表述并精确化:内存占用比算力更早决定批量产出的可行性。64GB 门槛线的含义是:能承受全尺寸采样阶段的内存占用、但未完成全流程;能稳定排产的是 768 档。

四、降档策略:768 生成与上采样

参数路线走不通:面对内存墙,先试了官方参数 --use-split-cross-attention,结果一步就请求 210.34GB 缓冲区,直接崩(坑 8,01 篇已详述)。实测范围内,该参数对 H3 视频已排除;降档是落地的解。

数据先看:768 档的像素量是全尺寸(1088×1920)的 49.4%,耗时只有其 20.7%(每步耗时口径,416.82÷2010.68)——降档的收益比线性更划算,同一段视频快 4.8 倍。

生产路线:768×1344 生成,放大到 1080×1920 交付。本系列 31 秒宣传片竖版全片走的就是这条路,合成滤镜逐字(执行包 assemble.sh,ffmpeg -vf 参数):

crop=756:1344:6:0,scale=1080:1920

拆开读:768 宽先左右各裁 6px 得 756(756:1344 恰为 9:16,与 1080×1920 同比例),再放大到 1080×1920。画质结论本文不做——768 原生与放大后的样张对照属待补项,这里只给路线与命令,不下「损失大小」的判断。

实操节奏四步:

1. 544 档打样:验证运动效果,303 秒一段;
2. 768 档出正片:33 分钟一段,队列串行,按挂机规划;
3. 挂机防睡眠:长任务前在 Mac 上跑 caffeinate -ims(机器曾在连跑数小时后自动睡眠,细节 05 篇批量产线展开);
4. 上采样交付:crop+scale 到 1080×1920,进剪辑。

07 篇做本地 vs 云端成本对比时,这条降档策略会再出现一次(00 篇 5.4 伏笔)。

五、能力边界:视频模型能做什么、不能做什么

02 篇第三章在图侧画了能力边界(主体稳、细节偶失准),并预告「03 篇给视频侧的完整展开」;01 篇坑 9 留下「视频内容层的展开见 03 篇」。本篇兑现,证据逐条来自总表 §三的实测。

先说能做的,四项,全部实测通过:

• 形态转化类高难动作一次成型:「火焰凝聚成太阳」「开盖→入盒→盖合→透光」,一次 roll 即成型(4 步、768 档)——推翻了「形态转化必崩」的预期。
• 运镜听从描述:低角度上摇、极缓推近、缓慢拉远,均有执行。
• i2v 首帧身份保持:盒、日、轨道三重锚全程稳定,10 段无一崩坏。
• 末帧接力:取上一段末帧作下一段首帧,衔接自然——多镜头连续叙事的衔接基础。

再说不能做的:大片留白区自生成无语义字纹。(01 篇坑 9 的完整展开)

镜 6 是「悬日 + 下部大片留白」的构图。生成的素材里,视频模型在画面 52-56% 高度、横向 40-65% 的位置,自发生成了一行无语义字纹,中度可辨——观感上与尾帧卡的固定文字重叠冲突。

根因:H3 对大片纯净留白,倾向用文字状纹理填充。图侧有同源现象:Z-Image 提示词去掉轨道后,当批候选里约三分之一仍惯性画环(02 篇图侧证据)。

两层解法:

修复层(零重 roll):利用分镜里「下部 55% 深邃留白」的设定,用 ffmpeg 给这一镜叠加自 45% 高度渐入的暗部渐变——字纹埋进暗部不可辨,上部悬日不受影响。一次重 roll 都没花。修复即设计(实验日志原话)。

构图层(预防):分镜阶段就给留白安排用途(压暗区、叠字区),或避免无功能的大留白。「留白不是免费的,构图时给它安排任务」——01 篇坑 9 的一句话记住,原话引用。

两边合起来,就是 00 篇说的能力边界在视频侧的完整形状:能力分布不均匀。高难的形态转化一次通过,推不出「简单留白不生字纹」——不能从一个维度的通过,外推另一个维度。图侧(02 篇)与视频侧(本篇)两组证据,指向同一个结论。

最后重申多候选纪律的视频侧版本:一段 33 分钟,试错成本高。首帧多候选(02 篇流程)+ 544 打样(本篇第二章),是提交正片前的两道低成本验证——都以分钟计,远低于 33 分钟一段的重 roll 成本。

结语

视频这一环跑通,系列的第二个产出物就位。回头盘点:档位怎么选(544 打样、768 生产;1088 全尺寸未产出成品,批量生产不考虑)、内存墙在哪(61.29/64GB,机制推断与验证计划分层在案)、能力边界画在哪(形态转化稳、留白会生字纹)——本地视频生成从「不敢碰」变成「可排产」。

下一篇,画面动起来了,声音从哪来:04 篇《音视频联合生成与本地配乐》——H3 的 LATENT 是音视频联合 latent,接两个 VAE 解码,能额外得到一条音轨。

参考资料

• 本系列实测数据底座:测评数据总表与实验日志 03(作者实验留存;关键数字已在正文逐条引用)
• ComfyUI 官方仓库 comfyanonymous/ComfyUI(v0.36.0 tag,可搜索)
• 00 篇《mac mini 本地 AIGC 实测:图、视频、音乐的真实水位》(已发布)
• 01 篇《ComfyUI 源码版安装与 9 坑实录》(已发布)
• 02 篇《文生图工作流与配图批量实战》(已发布)

免责声明

本文内容仅供学习交流,所述方法需结合实际场景灵活运用。模型与软件栈版本演进很快,本文实测于 2026-09-24~26(MiniMax H3 int8 量化版 / ComfyUI v0.36.0 / Mac mini M5 Pro / 64GB),读者以此日期为参照核对版本;1088 档相关数据仅为中断事实记录,不构成对该档位可完成性的判断;生成视频发布时按平台要求标注「AI 生成内容」。

本文由 AI 辅助创作,经人工审核编辑后发布。