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 毫秒，我们认为，实时视频生成的算力门槛虽然降下来了，但要把整体交互推进到毫无破绽的真人节奏，瓶颈现在踢回给了语音代理。