Runway Enhance Frame Rate 登陆 Dev API：24 至 120 fps，支持 NTSC

Runway 于 2026 年 9 月 17 日在其开发者 API 上推出了一款新的帧插值模型，而真正要紧的细节并不在最高档位——而在那些小数帧率上。Runway Enhance Frame Rate 可将你已有的素材重新定时到 24、25、30、48、50、60 或 120 fps 的目标帧率，同时也支持广播电视与电影真正实际交付的那三种帧率：23.98、29.97 和 59.94。Runway 自家的开发者更新日志将该模型记为 enhance_frame_rate，通过该公司已用于其创意放大器的同一个 POST /v1/video_upscale 端点调用，每个任务的输入上限为 300 秒，并按每 2 秒 1 个信用点计费。

那条计费项目是第二个意外。帧插值通常按输出计价——Runway 自家的 Magnific Video Upscaler 在同一个端点上，720p/1K 下每输出帧收取 0.7 积分——这意味着 24 fps 到 120 fps 的转换，成本是 24 到 25 转换的五倍。enhance_frame_rate 按输入秒数计费。5 倍帧倍增和 1.05 倍帧倍增的成本完全相同。如果你的工作是交付同一段素材的多个帧率版本，定价表里的这一行就颠覆了通常的算法。

这个时间点也颇具意味。Runway 独立的 Frame Interpolation 工具已被列入公司官方的弃用工具清单，而 Animate Keyframes 应用被指定为其替代品。Enhance Frame Rate 并非那款网页工具的复活——它是把帧插值重建为 API 模型，面向的是流水线，而非某个人在时间轴上逐帧点击操作。

增强帧率究竟是做什么的

这是一个重定时模型，而不是生成式模型。没有提示词，没有图像，也没有参考片段。你输入一段已经存在的视频——来自摄像机、剪辑，或另一个 Runway 模型的任何内容——它会合成达到目标帧率所需的中间帧。Runway 在其自己的 X 账号上发布的公告也是同样的说法：“将任何素材转换为你所需的规格。”

从机制上讲，它是视频放大端点上的一个异步任务。你 POST 一个视频 URI，设置 model: "enhance_frame_rate"，拿回一个任务 id，然后轮询获取结果。由于它与 Runway 的放大器共用同一个端点，已经对接 /v1/video_upscale 的流水线只需改一个参数，而不必做一次新的集成。

Runway 的更新日志将以下内容列为当前由厂商提供的规格说明。其中没有任何一项经过独立验证——目前没有针对该模型的第三方基准测试，而且在撰写本文时，它才刚发布一天。

• 目标帧率 — 24、25、30、48、50、60 和 120 fps，以及 23.98、29.97 和 59.94 fps（在 API 中写作 23_98、29_97 和 59_94）

• 输入限制 — 每个作业 300 秒

• 价格 — 每 2 秒输入 1 积分；Runway API 积分每个 $0.01

• 访问 — POST /v1/video_upscale，使用模型："enhance_frame_rate"，在 Runway Dev 上

• Runway 的现有技术——在 2024-11-06 API 版本下存在一个 frame_interpolation_v1 任务类型；独立的 Web 版 Frame Interpolation 工具已弃用

• 独立评估——未发布任何结果

帧率阶梯，以及为什么 23.98 才是真正的重点

每个消费级插值工具都提供整数帧率。这里值得关注的那一列是分数帧率，因为交付规格实际规定的正是分数帧率：

• 23.98 (23.976)——NTSC 胶片帧率。几乎所有影院和流媒体母版所采用的帧率，也是 DVD 和蓝光制作时所依据的帧率。

• 24 — 真实电影帧率，至今仍用于 DCP 和许多电影节的交付格式。

• 25 — PAL 和 EBU 地区：英国、欧洲大部分地区、澳大利亚、亚洲和非洲的大部分地区。

• 29.97 — NTSC 广播，30 的分数同胞。

• 30 — 用于屏幕捕获、网页和游戏画面的整数帧率。

• 48 — 高帧率电影（《霍比特人》系列电影的拍摄和放映帧率）。

• 50 — PAL 高帧率，正好是 25 的 2 倍。

• 59.94 — NTSC 高帧率，美国和日本的 60 Hz 广播传输速率。

• 60 — 整数 60 Hz，流畅网页播放的常用目标。

• 120 — 慢动作，以及高刷新率输出。

24 与 23.976 之间的差距看似微不足道，实则不然。在一小时的播放时长内，两者会漂移开大约 3.6 秒。把 24.000 母版送入 23.98 交付链路，就会出现音频同步漂移和帧节奏错误，导致广播 QC 判定失败——这就是为什么后期制作公司历来会单独运行一个套底步骤来重采样帧率，或者干脆拒绝这项工作。一个能直接输出分数帧率的工具，会从这条链路中去掉一个环节。与“120 fps”相比，这是一个窄得多、也无聊得多的说法；但对任何要向广播机构交付的人来说，这正是值得在意的原因。

实践中真正需要持怀疑态度的是 48 和 120 这两个目标。把 24 fps 素材插值到 120 fps，意味着每有一个真实帧，就要凭空造出四个帧；而在快速运动、遮挡或严重运动模糊的情况下，各种插值器都会产生重影和扭曲。Runway 没有发布任何伪影分析，没有与其他任何插值器进行对比，也没有提供逐镜头的质量指导——因此，诚实的立场是：规格支持 120，而 120 在你的素材上看起来如何，尚未经过测试。

成本是多少，详细算一遍

这个算术异常简洁，因为单位是输入秒数。按照每 2 秒 1 个积分，且在 Runway 的开发者 API 上每个积分为 $0.01（预付费，1,000 个积分最低 $10）：

• 10 秒片段，任意目标速率 — 5 积分，约 $0.05

• 30 秒片段——15 积分，约 0.15 美元

• 一段 60 秒的片段 — 30 积分，约 $0.30

• 一段 5 分钟剪辑，上限 300 秒 —— 150 积分，约 1.50 美元

• 一段 90 秒的剪辑，24 → 25 fps — 45 积分，约 0.45 美元

• 同一个90秒片段，24 → 120 fps — 45积分，约0.45美元

最后两行就是整个定价论证。在按输出帧计费的模型下，第二个任务会变成5倍的帧数，因此大约会是5倍的账单。而在这里，它是免费的。

与同一端点上的相邻方案进行对比，就能把这一点说明得很具体。Magnific Video Upscaler 按输出帧计费——720p/1K 为 0.7 积分，2K 为 0.9，4K 为 1.2，且每次生成最低收费 1 积分。一段 10 秒、30 fps 的剪辑是 300 输出帧，因此按 720p/1K 费率计算为 210 积分，约合 2.10 美元。同一段剪辑通过 enhance_frame_rate 处理则是 5 积分，约 0.05 美元。如果你想要更高的帧率而不是更大的画面，选择 upscaler 的成本大约高出四十倍。另请注意，启用 upscaler 的可选 fps 提升会改变输出帧数，从而进一步推高这笔费用——Runway 的定价文档明确说明了这一点。

有一个成本方面的注意事项值得指出：这里应以 Runway 的开发者定价页面为准，而非本文；并且据报道，自 2026 年 8 月起，积分价格一直在接受审查，可能转向定制定价。在为大批量做预算之前，请先查看门户。

300 秒上限，以及如何绕过它

每项任务的输入都限制在 300 秒以内。对于一个镜头来说，这个时长很宽裕；对于一整段成片而言，却又太短。因此，凡是超过限制的内容都必须分段——而如何分段，比上限本身更为重要。

按场景边界切分，而不是按固定时钟切分。插帧器会推断相邻帧之间的运动；在硬切处，镜头 A 的最后一帧与镜头 B 的第一帧之间根本不存在运动关系，而无法检测到切点的模型会乐于在二者之间凭空生成变形过渡。Runway 的更新日志并未记载此模型具备自动场景检测，因此稳妥的假设是：它没有。在切点处分块，对每个分块进行插帧，再以新的帧率在时间线上重新组装。

那条建议并非 Runway 专属——它是所有 AI 重定时场景下的通用警示。2025 年一篇关于 AI 辅助后期制作的 SMPTE 论文，描述了一个针对 23.976 → 25 和 29.97 → 23.976 等转换的 TensorRT 优化插值流水线，也提出了同样的观点：经过帧率转换的内容需要在场景切换处设置帧断裂（frame breaks），并在之后进行 QC，否则模型会在拼接处产生幻觉。预计第一遍处理在困难转场附近需要手动替换帧。

与替代方案相比所处的位置

帧插值有段时间以来已经算是个差不多被解决的问题了，只是以两种形式存在，而这两种形式看起来都与这一种不同。

• 桌面套件——Topaz Video AI 的 Apollo 和 Chronos 模型是注重质量的重新定时的标杆。永久许可证，用你自己的 GPU，没有按秒计费，还有一个能让懂行之人获益的调优过程。

• 开源插帧器——RIFE 及类似模型，可自托管，一旦拥有硬件，边际成本几乎为零，也是大多数后期制作公司自建定制流水线的基础。

• Runway Enhance Frame Rate — 无需本地计算，仅需一次 API 调用，按输入秒数计费，还有另外两者历来只能靠你手动适配的分数 NTSC 帧率。

这笔权衡很清楚。对于在你已经拥有的工作站上处理的一次性镜头，本地插帧工具会更便宜，还能提供 Runway 未开放的调节项。对于进入自动化流水线的素材，或者对于交付矩阵——同一段剪辑必须在一个地区以 23.98 输出、在另一个地区以 25 输出——直接返回分数帧率的 API 能省去一道帧率匹配步骤，而按输入秒计费意味着多帧率输出不会带来额外成本。

它周围的路由层

重新定时是流程中的一个阶段，而这条流程附近某处还有一个语言模型步骤。镜头清单和套底备注，需要按新帧率重新定时的字幕与说明文字处理，按地区交付的元数据，质检日志——这些都是文本工作，而这是视频流程中没人会为之做预算的部分。

那一层的运转依托OrcaRouter 目录中 200 个模型共用的一枚密钥，供应商目录价格以 0% 加价原样透传，并在各供应商之间自动故障转移，因此可以在实时流量上试用更新或更便宜的模型，而不必拿生产路径去赌。关于范围，需要说明的是：Runway Enhance Frame Rate 是一个 Runway Dev API 模型，在 Runway 自己的端点上调用，OrcaRouter 并不提供该模型。我们覆盖的是它周边的一切。

尚未知晓的是什么

几乎没有任何关于质量的内容。撰写本文时，这个模型大约才发布一天，而上面关于其行为的一切都来自 Runway 自己的更新日志和公告。具体未经证实的有：

• 快速运动、遮挡、运动模糊和低比特率源下的伪影表现——无人发布过任何测试

• 它是自动检测场景切换，还是在场景切换之间进行混合

• 当帧率发生变化时，音频是直接传递、重采样，还是被丢弃

• 在质量上与 RIFE、Apollo 或 Chronos 相比如何——目前尚无正面比较

• 随着目标速率上升，按输入秒计的价格是会保持不变，还是会在之后被重新分级

在你用自己的素材实际跑过 120 fps 和 48 fps 这两档目标之前，先把它们当作宣传说法看待，并且检查你发送的第一个片段上的剪切处理情况。

现在谁应该行动？

如果你需要交付符合广播或多地区规范的成品，并且目前要为套底环节付费；如果你的素材已经流经一条自动化流程，且还能多承受一次 API 调用；或者如果你想从一台从未拍摄过高帧率画面的摄影机获得慢动作，而且宁愿不运行 GPU——那就现在就行动。

如果单次任务需要超过五分钟，且无法在剪辑点分段；如果你还需要提升分辨率——那就要用放大器，按每帧计价——或者你已经拥有桌面端插帧工具，而这只是一次性镜头，那就再等等。如果决定因素是质量而非便利，也要再等等：Runway 之外还没有人公布过数字，而首个独立对比才是值得等待的。

值得关注的模式是，Runway 是否会继续逐个模型地扩展这个端点。它已经承载了一个创意超分器，如今又加入了一个重定时器，两者都挂在 POST /v1/video_upscale 上，且都按完全不同的计量单位定价。对于任何构建交付流水线的人来说，这个计量单位——输入秒数，而非输出帧数——才是值得围绕其进行设计的部分。