如果你正在 Mac 上折腾本地 AI 图生视频，纠结日常工作流该优先投入 MLX（8-bit + Turbo） 还是 h3.c（官方 BF16 权重、M5 默认 int8），先把我这轮跑完 11 条本机测试、核对完运行日志与抽帧特写后的选型结论放在最前面：作为我自己的本地图生视频主力路线，我整体更推荐 MLX。
给出这个推荐，靠的不是播放器缩略图的粗看印象，而是本机实打实跑出来的两份证据：一方面，在画面细节上，MLX 的 768×1344 主片在所抽帧里更清楚地保住了帽面水珠的亮边高光与帽檐挂滴的饱满体积，而本轮 8 条不同规格的 h3.c 样本在抽帧复核中均发现了手部与叶片遮挡变化时的半透明绿色残像；另一方面，MLX 的本机日志把生成耗时与内存代价交了底——跑通一条 768×1344 的 5.167 秒成片耗时 11.1 分钟、内存峰值 29.6 GiB，而在同画布下尝试 8 秒（192 帧）时则在第 1 步因内存交换（SWAPPING）超限中断。
把这轮实测的日志数值、局部放大画面和控制组排查全部摊开，你在 Mac 上选哪条路、要准备多少时间和内存预算，一眼就能看明白。
原始首帧 · 1086×1448 · 本机提供
一张首帧、11条样本：先把两路方案的本机测试条件亮清楚
为了看清细节底线，这轮测试统一拿同一张《雨中采茶的坚毅身影》（1086×1448，3:4 画幅）作为输入首帧：画面里采茶人戴着黄帽，帽面上散落着细亮边与点状高光彼此分开的水珠，帽檐右侧垂着一颗有体积感的泪滴，右手捏着茶梢，最前景则是几片自然离焦的大茶叶散景。
MLX 768×1344 主力样本
8-bit + Turbo · 768×1344 · 124 帧 · 5.167 秒 · 6 步。下文展示本机实测数据与抽帧对照。
这组数据对应本轮跑出的 MLX 768×1344 主力成片。在看具体数据和抽帧之前，先把两边上桌的测试范围对齐——两套方案均使用同一首帧与种子 42，但画布尺寸、权重与量化路线不同，也没有核对完全相同的提示词文本，因此这是一次服务本机实战选型的对照，不作跨框架的同条件跑分排名：
MLX 路线（8-bit + Turbo，种子 42）：本机跑通 3 条 124 帧（输出片长 5.167 秒）成片，包括两条 544×960 画幅（6 步、8 步）和一条 768×1344 高画布主片（6 步），每条均抽取第 0、62、123 帧复核；另做了一次 768×1344 画幅、192 帧（8 秒目标）、6 步的尝试。
h3.c 路线（官方 BF16 权重、M5 默认 int8，种子 42、50 层、reuse 1）：共跑了 8 条样本，包含 4 条 768×1024 画幅的 22 帧短片（输出片长约 0.92 秒：分别为 4 步、6 步、8 步，以及强制把 MLP/QKV/注意力输出设为 BF16 的 6 步版，每条抽第 0、11、21 帧），外加 4 条 6 步中长片——768×1024 画幅的 107 帧（输出片长 4.46 秒）、243 帧（输出片长 10.13 秒）、362 帧（输出片长 15.08 秒），以及 768×1344 高画布的 107 帧（输出片长 4.46 秒），除了抽头、中、尾帧，长片还按每 10 到 33 帧做了加密抽帧。
拆解MLX本机日志：从4.2分钟到11.1分钟，生成耗时与内存峰值全记录
把 MLX 作为优先路线，在本机跑一条片子到底要等多久、吃多少内存？我们直接调出 2026-10-14 的本机运行日志，把 3 次成功生成的实测数值和 1 次 8 秒尝试的日志记录整理成了下面这张图表：
2026-10-14 本机 MLX 日志 · 峰值取日志 peak 字段。
对照日志里的实测记录，你可以直接看清这四次运行的资源账单：
544×960 画布的 6 步与 8 步耗时对比：跑 544×960、124 帧（输出 5.167 秒）、6 步时，本机生成用时为 4.2 分钟，每步监测的内存峰值为 28.1 GiB（日志开头系统已有 3485 MiB 交换空间占用，不属于该任务新增）。在同画布、同帧数下把采样拉到 8 步后，内存峰值同样是 28.1 GiB，生成用时来到 5.4 分钟——在 MLX 这两条同画布、同帧数与同种子的日志记录里，6 步升到 8 步多花了 1.2 分钟（用时增加约 29%），而仅凭这组样本还没有充分的画面证据表明 8 步带来了画质提升。
768×1344 高画布 5 秒主片的本机代价：把画布设为 768×1344（124 帧、6 步、输出 5.167 秒），这次成功生成的用时为 11.1 分钟，内存峰值记录为 29.6 GiB（此处画布尺寸改变，与 544×960 的用时差异同时混有像素量变化等因素）。
768×1344 画布尝试 8 秒（192 帧）的失败记录：同一份日志的第 18–60 行记录了 768×1344、192 帧（8 秒目标）、6 步的运行结果——任务在第 1 步出现 BudgetExceeded: SWAPPING，交换空间占用从 3204.9 MiB 升至 4944.5 MiB，随后以退出码 1 中断，没有生成成片（因此图表中不将其列为成功耗时条）。这两次运行直接展示了当前本机配置在 768×1344 画布下跑通 124 帧与尝试 192 帧时的实际内存表现。
画面硬证据一：帽面水珠与帽檐挂滴，第62帧对第53帧的细节大考
为什么我愿意花 11.1 分钟去等上面那条 MLX 768×1344 主片？把首帧原图、MLX 主片抽帧与 h3.c 抽帧的局部放大摆在一起，水珠细节的差别非常直观（以下 h3.c 展示的是先前审片时抽出的原始静帧；其生成耗时日志当前不可读，文中提及的 h3.c 秒数均为输出成片时长）。
局部 01 / 帽面水珠
原始首帧
MLX · 第 62 帧
h3.c · 第 53 帧
裁切自同一审片拼图，未重绘或插值。
先看黄帽表面的水珠群：原图里每颗水珠都有彼此分开的细亮边和点状高光。在 MLX 768×1344 主片所抽的第 0、62、123 帧里——尤其是正中间的第 62 帧——帽面水滴的细亮边和点状高光依然区分得比较清楚；而在 h3.c（768×1024）所抽的第 0、53、106 帧里，到了中段的第 53 帧，帽面水珠明显变软，原本分开的细亮边更容易糊成一团团亮斑。
局部 02 / 帽檐挂滴
原始首帧
MLX · 第 62 帧
h3.c · 第 53 帧
看挂檐处的亮边、体积与拖痕。
再看帽檐右侧那颗垂挂的泪滴：结合原片观感与所抽的第 0、62、123 帧特写，MLX 768×1344 主片在第 62 帧里，帽檐右侧挂着的水滴仍有饱满体积，滴落感更像水珠，也未见明显的双重水珠重影；反观 h3.c 的第 53 帧及第 106 帧抽帧，这颗挂檐水滴在中后段渐渐撑不住形状，往细线、淡痕与拖影方向变化。原本湿漉漉的雨景镜头，一旦帽檐水珠化成淡线拖痕，画面的真实感就会明显打折。
画面硬证据二：h3.c这批短长片抽帧均发现“手前绿影”，控制组排查了哪些因素？
除了头顶的水珠，采茶人右手与黄色衣袖前方的茶叶区域，是促使我在这轮选型中倾向 MLX 的另一项关键观察。
看图前要先区分清楚：首帧原图最前景本来就有几片自然离焦的大茶叶，那是镜头自带的焦外散景，并非生成伪影；而我们在 h3.c 这批样本抽帧里观察到的问题，是在手部与茶枝叶片发生遮挡变化时，右手和黄色衣服前方短暂出现的半透明绿色残像。
局部 03 / 4.46 秒片中段
h3.c · 107 帧片 · 第 53 帧
注意黄衣服与手前方的浅绿色残留；最前景的模糊大叶子本就在原图。
局部 04 / 不到 1 秒的短片
4 步 · 第 21 帧
6 步 · 第 21 帧
8 步 · 第 21 帧
局部 BF16 · 第 21 帧
4、6、8 步及局部 BF16 的 22 帧短片，末段均见轻度残留。
这抹半透明绿影到底在哪些规格里出现、跟时长或参数有什么关系？我们把 8 条 h3.c 样本的人工抽帧观察结果汇总成了下面这张矩阵（注：图中的“轻”与“明显”仅代表人工审阅抽帧时的视觉分类标签，不折算为百分比、评分或全片发生率）：
同一首帧输出的人工抽帧分类；秒数为输出片长。
顺着矩阵里的 8 组抽帧记录，我们可以对四项常见疑问做出具体界定：
不只是长片才会出现残像：在 6 步中长片里，107 帧（输出片长 4.46 秒）的第 39–58 帧、362 帧（输出片长 15.08 秒）的第 33–66 帧抽帧中，手前绿色残像表现为“明显”；243 帧（输出片长 10.13 秒）的第 44、110 帧以及 768×1344 高画布的 107 帧（输出片长 4.46 秒）抽帧中表现为“轻”。更关键的是，4 条只有 22 帧（输出片长约 0.92 秒）的短片，在第 21 帧附近也全部观察到了“轻”度绿色残像。短片末段同样出现，说明“只有视频拉长了才会有残影”的说法在这批样本里不成立。
画幅拉伸不是唯一原因：首帧原图是 3:4（1086×1448），h3.c 的 768×1024 恰好保持了 3:4 的原图比例（而 MLX 的 768×1344 更窄更长），但保持原比例的 768×1024 样本照样在抽帧中出现了手前绿影，说明不能把原因单纯归结为画布比例拉伸。
4/6/8 步与局部 BF16 均未消除该残像，但不能据此完全排除 int8：在 22 帧短片组里，把采样步数从 4 步调到 6 步、8 步，或者在 6 步下把 MLP、QKV 和注意力输出强制设为 BF16 运行，第 21 帧附近依然可见“轻”度残像。这说明在本轮测试的参数范围内，单靠增加步数或将上述局部模块切回 BF16 并未消除残影；同时也要注意，仅靠部分模块强制 BF16 的结果，还不能直接推出“该现象与 int8 完全无关”。
VAE 分块日志仅作排查线索，不能直接定因：h3.c 的 10 秒运行日志里虽然记有一条 video VAE tiles 3×4 at 304 pixels，但这只能作为后续排查的线索，仅凭当前日志和抽帧不能断言 VAE 分块就是主因。停留在画面层最贴近观察的描述是：这批 h3.c 片段在手部移动、与叶片发生遮挡变化时，叶片位置的画面重建出现了短暂不稳。
实测选型落点：按你最在乎的指标，决定先用哪一路
把本机日志记录的耗时、内存峰值和两边的抽帧特写合在一起，你在 Mac 上挑选本地图生视频路线时，可以直接按自己的实际需求做取舍：
如果你优先想要像本次 768×1344 主片那样保住水滴亮边、高光与挂滴体积的可用成片，并且机器能够承担对应的耗时与内存开销：我更推荐选 MLX。 按本机实测记录，跑通一条 544×960 的 5.167 秒视频需要 4.2 分钟（6 步）至 5.4 分钟（8 步）、峰值内存 28.1 GiB；跑通那条水珠细节清楚的 768×1344 5.167 秒主片需要 11.1 分钟、峰值内存 29.6 GiB（同时留意在本机当前配置下，768×1344 尝试 192 帧/8 秒时会在第 1 步触发 SWAPPING 退出）。
如果你现阶段主要想在本机尝试更长的输出片长或测试不同参数组合：可以参考 h3.c 的输出时长范围，但需留意画面残像。 从输出文件来看，h3.c 在本机产出了最长 10.13 秒（243 帧）和 15.08 秒（362 帧）的成片（注：此处为输出片长，不代表生成速度，本篇亦不做跨框架速度比较），不过在本轮全部 8 条短长片的抽帧复核中，手部遮挡变化处均观察到了不同程度的茶叶残影。
自己在本机验片时，建议也顺手做两件事：一看日志里的耗时和内存峰值有没有触发交换空间（SWAPPING），二抽开头、中段、结尾三帧（长片在中段加密抽帧），放大帽檐水珠这类高反差细节和手部遮挡边缘做个比对。就这轮本机实测跑出的画面表现与运行记录而言，我自己的本地图生视频工作流，这一票明确投给 MLX！
