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 fps 轉 25 fps 轉換的五倍。enhance_frame_rate 的計費基準是每秒輸入。5× 影格倍增與 1.05× 影格倍增的成本完全相同。如果你要交付的是同一段素材的多種影格率版本，定價表中的那一行就會顛覆一般的算術。

這個時間點也頗具針對性。Runway 獨立的 Frame Interpolation 工具已被列在公司官方的已棄用工具清單上，並指名 Animate Keyframes 應用程式作為其替代方案。Enhance Frame Rate 並非那個網頁工具的復活——它是將影格插補重新打造為 API 模型，目標鎖定在管線流程，而非讓人在時間軸上點來點去。

Enhance Frame Rate 實際上有什麼作用

這是一種重定時模型，不是生成式模型。它不需要提示詞、圖像或參考片段。你只要把一段已經存在的影片交給它——無論是來自攝影機、剪輯成品，還是另一個 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

• 存取 — 在 Runway Dev 上，以 POST /v1/video_upscale 搭配 model: "enhance_frame_rate"

• Runway 的既有先例 —— 在 2024-11-06 API 版本下曾存在 frame_interpolation_v1 任務類型；獨立的網頁版 Frame Interpolation 工具已棄用

• 獨立評估——尚未發表

影格率階梯，以及為何 23.98 才是真正的頭條

每一款消費級插補工具都提供整數影格率。這裡有趣的一欄是分數影格率，因為交付規格實際上寫的就是分數影格率：

• 23.98（23.976）——NTSC 電影速率。幾乎每一份戲院與串流母帶，以及 DVD 與 Blu-ray 製作時所依據的速率。

• 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 交付鏈，就會產生音訊同步漂移與影格節奏錯誤，讓廣播品質管控判定不合格——這正是後期製作公司長久以來會另外執行一道重新取樣影格率的套合步驟，或直接拒絕這類工作的原因。若能直接輸出該非整數影格率的工具，就能從那條流程中省去一個環節。這個說法比「120 fps」狹隘得多、也無聊得多，但對任何要交付給廣播業者的人來說，這正是必須在意的原因。

實務上，48 和 120 這兩個目標才是該存疑的。將 24 fps 素材插補到 120 fps，等於每一個真實影格都要憑空創造出四個影格；而遇到快速動作、遮擋或嚴重動態模糊時，各種插補器都會產生殘影與扭曲。Runway 並未公布任何偽影分析、沒有與其他任何插補器比較，也沒有逐鏡頭的品質指引——所以誠實的立場是：規格支援 120，但 120 在你的素材上看起來如何，仍未經測試。

費用幾何，逐一拆解

這套計算格外簡潔，因為單位是輸入秒數。以每 2 秒 1 credit，以及在 Runway 開發者 API 上每 credit $0.01 計算（預付，最低 $10 可購 1,000 credits）：

• 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 秒。對單一鏡頭來說這相當充裕，但對一支 reel 而言卻很短，因此任何更長的內容都必須分段——而如何分段，比上限本身更重要。

在場景邊界處剪輯，而不是按固定時鐘。插值器會推斷相鄰影格之間的動作；在硬切時，鏡頭 A 的最後一格與鏡頭 B 的第一格完全沒有動作關聯，而未能偵測到剪接的模型會樂於在她們之間捏造出一個變形過渡。Runway 的更新日誌並未記載此模型的自動場景偵測功能，因此安全的假設是：並沒有這樣的功能。在剪接點分塊，逐塊插值，再以新的影格率在時間軸上重新組裝。

那個建議並非 Runway 特有——這是所有 AI 重計時（retiming）的標準但書。2025 年一篇關於 AI 輔助後製的 SMPTE 論文，描述了一套以 TensorRT 優化的插補流程，用於 23.976 → 25、29.97 → 23.976 之類的轉換，也提出同樣的觀點：經影格轉換的內容在場景切換處需要有影格斷點，之後還要進行品質檢測，否則模型會在接點處產生幻覺。預期第一輪處理在棘手的轉場附近會需要手動替換影格。

它與其他選項相比如何

影格插補已經算是個大致解決的問題有好一段時間了，它有兩種形式，而這兩種形式看起來都和這一種不同。

• 桌上型套裝軟體——Topaz Video AI 的 Apollo 與 Chronos 模型是注重品質的重定時基準。永久授權、用你自己的 GPU、沒有按秒計費的計量，還有一輪能獎勵懂得看門道者的調校流程。

• 開源插補器——RIFE 及類似模型，自行託管，一旦擁有硬體，邊際成本幾乎為零，也是大多數後製公司自行打造的自訂流程之基礎。

• Runway Enhance Frame Rate — 無需本地運算，只要一次 API 呼叫，依輸入秒數計費，還有那另外兩者長久以來都留給你手動對齊的分數式 NTSC 影格率。

這筆取捨顯而易見。對於在你已擁有的工作站上進行的一次性鏡頭，本機插補器會更便宜，還能給你 Runway 未開放的控制選項。至於透過自動化流程進來的素材，或是一份交付規格矩陣——同一段素材在某個地區必須以 23.98 輸出、在另一個地區則以 25 輸出——能直接回傳分數影格率的 API 就省去了一道 conform 步驟，而按輸入秒數計價意味著多速率輸出不會產生額外成本。

其周圍的路由層

重新計時是流程中的一個環節，而這條流程附近某處有個語言模型步驟。鏡頭清單與套對備註、必須依新影格率重新計時的字幕與輔助字幕作業、各區域的交付中繼資料、品管紀錄——這些都是文字工作，而這正是影片流程中沒有人會編列預算的部分。

這一層的運作方式是用一把金鑰橫跨 OrcaRouter 目錄中的 200 個模型，供應商定價以 0% 加成原樣傳遞，並在供應商之間自動容錯移轉，因此可以在實際流量上試用更新或更便宜的模型，而不必拿正式環境路徑去賭一把。精確說明適用範圍：Runway Enhance Frame Rate 是 Runway Dev API 的模型，透過 Runway 自家的端點呼叫，OrcaRouter 並不供應它。我們涵蓋的是它周遭的一切。

還有什麼是尚未知道的？

幾乎沒有提到品質方面的資訊。撰寫本文時，這個模型大約才問世一天，而上述關於其行為的一切，都來自 Runway 自家的更新日誌與公告。具體而言，尚未驗證的是：

• 快速動作、遮擋、動態模糊與低位元率來源下的偽影表現 — 目前沒有任何公開測試

• 它是否會自動偵測場景剪接，或是在各剪接點之間進行混合

• 當影格率變更時，音訊是直接傳遞、重新取樣，還是遭捨棄

• 它在品質上與 RIFE、Apollo 或 Chronos 相比如何——目前沒有直接比較

• 隨著目標速率提高，每輸入秒價格是否維持不變，還是之後會被重新分級

在你用自己的素材實際跑過之前，請把 120 fps 和 48 fps 這些目標值當成宣稱；另外，在你送出的第一段片段上檢查剪接處理。

現在誰應該行動？

現在就行動，如果你要交付符合廣播或多地區規格的內容，而且目前得為 conform 步驟付費；如果你的素材已經流經自動化流程，而該流程還能再吸收一次 API 呼叫；或者如果你想從從未拍過高速畫面的攝影機取得慢動作，而且寧可不跑 GPU。

如果單一工作需要超過五分鐘，又無法在剪接點分段；如果你還需要提高解析度——那要用放大工具，而且是逐幀計價——或者你已經有桌面版補幀工具，而這只是一次性鏡頭，那就先等等。而如果決定因素是品質而非便利性，也先等等：Runway 以外沒有人公布過數字，而第一個獨立比較才是值得等待的事。

值得觀察的模式是，Runway 是否會持續以一個又一個模型來擴充這個端點。它已經搭載了一款創意放大器，現在又加入了一個重定時器，兩者都位於 POST /v1/video_upscale，且都以完全不同的單位計價。對任何在建置交付管線的人來說，這個單位——輸入秒數，而非輸出影格——才是值得圍繞設計的部分。