Runway 最佳化 57B 即時影片模型：算力需求減半，4 張 H100 跑出 24 幀

做過即時影片互動的人都知道，畫面只要卡頓哪怕半秒，那種面對活人的沉浸感就瞬間碎了一地。

今年 5 月，Runway 拿出了能用單張圖片生成可對話數字人的 Runway Characters，背後頂著一個約 570 億（57B）引數的自迴歸影片擴散 Transformer。

Runway 釋出了最新工程論文，詳細拆解了他們怎麼把這個龐然大物的硬體胃口，從最初的單會話 8 張 H100 直接砍半到 4 張，同時穩穩維持住 24 幀的即時生成。

把反覆嚼的快取「一次搞定」

大模型推理通常靠拼單（batching）來攤薄成本，但即時數字人行不通。每個人都在一對一連線，每個會話都是單獨的私有流，根本沒法和其他人打包計算。

要保證 24 fps 的流暢度，模型必須在 166.7 毫秒內生成一個 4 幀的影片塊。一旦超時，畫面和聲音就會同時卡死。

在 4 張 H100 上，最初的啟動版本跑一步擴散需要 240.9 毫秒，遠遠達不到及格線。

工程師排查發現，整整 29% 的 GPU 時間都花在了重複整理幾乎沒變的快取上。每步擴散有 240 次注意力呼叫，每次都在重新做 RoPE 旋轉位置編碼、重新量化到 FP8、複製挪動滑動視窗。

Runway 的解法簡單粗暴：在新幀寫入快取的瞬間，就把 RoPE 和 FP8 量化一次性做完，並用環形緩衝區來滑動視窗。這一項改動，直接把每步的快取維護時間從 69.7 毫秒削到了 6.2 毫秒。

邊算邊傳，以及那些離譜的線上坑

解決了快取，最大的瓶頸落在了卡間通訊上。每層網路之後都要做一次全歸約（all-reduce），一整步下來要跑 240 次。

Runway 把張量並行的通訊運算元直接融進了 FP8 矩陣乘法裡。顯示卡還在算後面的切片，前面的區域性結果已經在 NVLink 交換機裡開始歸約了，直接把 54% 到 68% 的通訊開銷藏了起來。

加上把耗時 114 毫秒的影片解碼器拆給獨立 GPU 非同步跑，每步擴散時間最終壓到了 147.4 毫秒。

在長達 7 周的實際線上執行中，99.5% 的會話幀率都能維持在 23.5 fps 以上。

論文裡還坦白了幾個啼笑皆非的線上 Bug。比如工程師為了監控 FP8 縮放比例，隨手加了一句 .item() 讀數，結果強行讓 CPU 等待 GPU，單步耗時直接從 168.5 毫秒飆到 278 毫秒，瞬間抹平了此前所有的快取最佳化成果。

為什麼重要

對使用者和應用開發者來說，這意味著高質量即時數字人終於邁過了成本死穴。

過去業內做即時互動，要麼用幾億引數的專用小模型湊合，畫面質感一眼假；要麼用龐大的擴散模型，但單人獨佔 8 張頂級計算卡的高昂賬單根本沒法商業化。4 張 H100 跑通 57B 模型，等於直接把單路影片互動的算力成本砍了一半。

對行業而言，影片生成的競爭重心正在悄悄轉移。過去大家比的是誰能離線生成一段幾秒鐘的驚豔大片，而 Runway 這篇論文給出的，是一整套 batch size 等於 1 的極限吞吐工程範本，會倒逼做即時互動的對手全面轉向細粒度運算元融合與非同步管線。

不過現實依然有短板。Runway 測算的真實對話端到端延遲中位數是 2.13 秒，其中影片管線只佔 0.49 秒，前端的語音模型反而吃掉了 1.42 秒。人類對話的自然停頓平均只有 208 毫秒，我們認為，即時影片生成的算力門檻雖然降下來了，但要把整體互動推進到毫無破綻的真人節奏，瓶頸現在踢回給了語音代理。