AI 短视频流水线如何拆分生成与渲染

HypeFox 把短视频制作拆成两类工作：脚本、核查和配音调用 API，真正吃机器的是 Remotion 渲染。作者选择让容器按需启动，空闲 2 分钟就关闭，用 Postgres 队列处理唤醒、并发和中断重试。

这套方案从首次提交到写作还不到两周，却给出了具体成本和踩坑记录。它值得看的地方，是如何让一个需要 Node、Chrome 和 ffmpeg 的任务，接受冷启动，也接受机器随时被停掉。

先约束 AI 的输出，再交给渲染器执行

HypeFox 没让模型直接写视频代码。小模型先写脚本，再按所选风格的 schema 填写 JSON，只能选择规则允许的布局、图标、文案和时间。校验失败，就把错误交回模型重试。

这把生成内容和执行程序之间的边界收紧了：模型负责选素材、填结构，Remotion 负责把结构变成画面。

随后，系统最多选取 4 条可核查的陈述上网搜索，只重写未通过的句子。语音 API 返回逐词时间戳，用来确定场景时长并驱动字幕。最终以 1080×1920、30 fps 渲染，封面图并行生成，不阻塞视频。

模型输出能否被校验，比让它自由生成更多内容更重要。

不过，原文没交代核查来源如何筛选，也没给核查准确率。这里能确认的是流程设计，不能据此认定成片事实可靠。

容器可以关闭，任务必须找得回来

第一天，worker 跑在 Mac 上，关机就停止服务。当晚，作者把同一份 worker 迁入 Cloudflare Containers，镜像包含 Node 22、供 Remotion 使用的 Chrome 和 ffmpeg。

唤醒走两条路径。视频表插入记录后，Postgres trigger 通过 pg_net 请求 worker 的唤醒端点；请求在事务提交后发出，失败不会拖垮插入。另有每分钟运行的 cron，补捞丢失的唤醒和重新入队的任务。

两条路径调用同一个数据库函数，查询待处理视频、处理中视频和未完成封面。Worker 保持忙碌容器运行，按等待任务启动空闲容器，最多并发 4 个。

实测从插入记录到冷容器领取任务需要 7 至 10 秒。其中，唤醒请求抵达 Worker 用时 0.2 至 0.3 秒，容器启动用时 2 至 4 秒。这两段没有覆盖全部等待，原文未进一步拆解。只靠 cron，等待可能达到 1 分钟。

sleepAfter 从首日的 4 分钟缩短为 2 分钟，关闭前再查一次队列。平台发来 SIGTERM 时，未完成视频重新入队；每个容器在数据库里有独立的 worker 名称，启动时只回收自己上次遗留的任务，避免共用名称导致互相抢活。

唤醒密钥放在 Supabase Vault，Worker 仅保存其 SHA-256；额外 worker 的密钥通过 HMAC-SHA256 从首个密钥派生，Worker 因而仍只需持有一个密钥。

这里的关键不是容器能否一直活着，而是任务状态是否独立于容器。机器消失后，数据库仍知道哪些活没做完。

省钱的关键，是空闲时间和交付速度怎么换

作者在 10 月 18 日，用网页实际调用的函数测试了一段 36 秒视频，容器从冷启动开始：

• 单独生成一条，容器成本约 1.1 美分，其中内存 0.61、CPU 0.47、磁盘 0.03 美分。
• 使用原先 4 分钟休眠设置时，约为 1.5 美分。
• 连续生成时，每条约 0.8 美分，因为最后 2 分钟的空闲费用由多条视频分摊。

他们保留了 standard-4。减少 vCPU 后，每秒视频的渲染耗时从约 1.5 秒升至 2.1 至 2.6 秒，交付晚 30% 至 40%，每条却只省 0.1 至 0.3 美分。

内存存在明显闲置：支付 12 GiB，实际最多用到 3 GiB。但自定义实例要求每个 vCPU 至少搭配 3 GiB，因此无法选择 4 vCPU、6 GiB。Workers Paid 包含的月度额度约能覆盖 36 条单独生成的视频，最先耗尽的是内存额度。

这些都只是容器账。脚本、场景和事实核查的模型调用，按风格不同每条另加约 0.5 至 2.5 美分，语音费用还要另算。

部署也会增加重复计算。一次 rollout 让已完成 98% 的测试视频从头开始，他们随后改为确认没有进行中任务再部署。镜像则从临时目录中的 git archive HEAD 构建，避免把工作区未提交文件带进去。

所有容器休眠时，rollout 曾无法启动，使用 wrangler deploy --containers-rollout=immediate 才解决。依赖方面，zod 固定到 Remotion 预期版本，并用 npx remotion versions 检查，使云端与本地渲染保持一致。

我的判断

这套设计适合任务间有空档、能接受数秒启动等待的按需渲染。数据库保存状态，容器承担计算，职责清楚。对早期产品而言，也容易追踪问题。

但它还不足以证明优于常驻实例。作者没有提供相同负载下的月账单对照，也没给出高并发、失败率和尾部延迟数据；缩短 sleepAfter 的收益不能直接推广成所有业务的最优设置。

「没有进行中任务再部署」也是早期操作办法。业务持续有任务后，很难一直等到队列清空，届时需要考虑暂停领新任务、等待现有任务结束等机制。原文没有实现这些，不能替它补成绩。

能拿来做什么

• 用 Node 和 Remotion 做按需视频时，先把任务状态放进持久队列，明确中断后如何重新入队，再决定容器何时休眠。
• 做 AI 场景生成时，先定义可校验的 JSON schema，让模型在已有组件范围内选择，并把校验错误用于重试。
• 估算单条成本时，分别计算渲染、模型和语音费用，同时测量单条冷启动与连续处理，避免漏掉空闲尾账。
• 部署渲染 worker 前检查进行中任务；构建使用已提交文件，并核对 Remotion 依赖版本，减少重复渲染和环境差异。