本地 ComfyUI 跑 Z-Image Turbo 出竖版图，以及 ffmpeg 抽帧的一个坑

开头：把出图搬到本地，是因为量大了不划算

做短视频内容经常需要批量出图。除了用云端 AI 出图，也可以把出图搬到本地 ComfyUI 跑开源模型——更可控，也更适合标准化批量生产。

下面把两个踩过的坑写下来，都是能直接用的经验。

一、为什么选 Z-Image Turbo，实测是什么样

本机显卡是 RTX 5060（8G 显存）。一开始以为 8G 跑不了像样的模型，试下来 Z-Image Turbo 完全够用：

• 能出 1024×1536 的竖版（短视频标准尺寸）
• 实测一张约 50 秒
• 无乱码、无水印
• 协议是 Apache 2.0，可商用 最后这条很关键。很多本地模型出图效果不错，但协议写着"非商用"，拿去做内容是踩雷的。出图之前先看一眼协议，别等账号做起来才发现图不能商用。 具体怎么跑 起一个本地服务，然后用脚本调，注意宽高要竖着设： python zimage_gen.py --prompt "明亮的浅色科技风插画，手机竖屏构图，主体清晰，柔和自然光" -W 1024 -H 1536 --steps 8 参数说明（都是踩过的坑）：
• -W 1024 -H 1536：竖屏必须竖着设。很多人默认出 1024×1024 方图，做短视频还得裁，一裁就把主体切掉了。
• --steps 8：我一开始用默认的 20 步，一张要跑将近 5 分钟。降到 8 步，画质肉眼几乎没差，速度快了 57%。Turbo 类模型本来就是为低步数设计的，用 20 步纯属浪费。 二、ffmpeg 抽帧，一定要直接出 PNG 这是另一个让我卡了半天的坑，值得单独说。 做画面比对的时候，我要从一批视频里抽关键帧。很自然的写法： ffmpeg -ss 3.5 -i input.mp4 -frames:v 1 frame.jpg 跑完一看，60 张图有一大半是空白的。 一开始以为是时间戳取错了，改了半天没用。后来把完整报错打出来才看见： mjpeg Non full-range YUV is non-standard Error while opening encoder Nothing was written into output file 根因 ffmpeg 会根据你给的 .jpg 后缀，自动推断用 mjpeg 编码器。而我这批源视频是 full-range YUV，mjpeg 编码器不接受这个色彩范围，直接报错。 最坑的地方在于：它报错了，但进程还是退出了，文件也生成了——只不过是个空白文件。如果你不看 stderr，只会以为"抽帧成功了，这几帧本来就是黑的"。 解法：别让它推断，直接出 PNG ffmpeg -y -ss 3.5 -i input.mp4 -frames:v 1 -pix_fmt rgb24 frame.png 三个改动：
• 后缀从 .jpg 改成 .png（绕开 mjpeg 编码器）
• 显式指定 -pix_fmt rgb24
• 加 -y（覆盖已存在的那个空白文件，不然你以为改好了，其实一直看的是旧图） 改完全部 60 帧一次成功。 教训：ffmpeg 报错了先别猜，把完整 stderr 打出来看。它经常"报错但假装成功"，这种情况光看输出文件是发现不了的。 三、想清楚什么该留在平台上 写到这，可能有人会觉得"那我把所有东西都搬本地好了"。 我的结论正好相反：只搬"量大、标准化、不依赖推理能力"的活。
• 批量出图：放本地。量大、尺寸固定、风格固定，适合批量生产。
• 抽帧 / 转码 / 拼接：放本地。ffmpeg 本就是本地工具，没必要走云端。
• 复杂推理、长文策划、多步骤拆解：留在平台。本地小模型扛不住，看似省事但返工更贵。
• 偶尔一两张概念图：留在平台。为了两张图不值得开本地服务。 结尾 工具搬不搬本地，核心是先想清楚：哪些活是"量大、标准化、不靠脑子"的。把这些识别出来，效率和成本立刻就不一样了。 如果你也在本地跑图生图或者 ffmpeg 处理，欢迎交流避坑经验。 附：本文涉及的两条命令（可直接复制）本地出图（1024×1536 竖版，8 步，约 50 秒）python zimage_gen.py --prompt "你的提示词" -W 1024 -H 1536 --steps 8

抽帧（务必出 PNG，不要 .jpg）

ffmpeg -y -ss 3.5 -i input.mp4 -frames:v 1 -pix_fmt rgb24 frame.png