Runway将 57B视频模型推理降至 147.4 毫秒，实时对话所需显卡从八块H100减至四块
Runway公布Characters服务的推理优化细节：通过把缓存维护改为在写入时执行、将张量并行all-reduce融进FP8矩阵乘法、让解码器独占一块GPU，扩散步从 240.9 毫秒降至 159.3 毫秒，融合核再降至 147.4 毫秒。
AI解读：Runway发布研究论文《Runway Characters: Serving a 57B Video Diffusion Transformer for Real-Time Conversation》，说明其约 570 亿参数自回归视频扩散Transformer如何在生产环境中以 24 fps实时驱动可对话的虚拟角色。
在 24 fps下，模型需每 166.7 毫秒生成一个 704x1088的四帧视频块，只服务单一用户，会话持续多久就要跑多久；播放器只缓存少量视频块，任一视频块延迟会同时冻结面部和声音。
Characters上线时每会话需八块H100；在四块H100上，初期软件每步耗时 240.9 毫秒，超过 166.7 毫秒的要求，优化后降至 159.3 毫秒（1.51 倍，稳定 24.5 fps），融合通信核进一步降至 147.4 毫秒（1.63 倍）。
Runway称，第一步中 29% 的GPU时间花在每次 240 次注意力调用里重复处理基本未变的缓存，注意力本身只占 6%；改为在每帧写入时做一次RoPE与FP8量化，缓存维护从每步 69.7 毫秒降至 6.2 毫秒。
七周遥测显示，在至少流式播放一秒的会话中，99.5% 平均高于 23.5 fps；回滚并修复后，融合核下平均 23.5 fps或更低的会话占 0.08%。
Runway称在 51 个计分片段上，各次运行的平均唇形同步差异最大 0.03，与同配置重复运行之间的波动同量级；四段 10 分钟会话结果相同。论文同时指出，这些结果只是给变化划出范围，并非证明等价，SyncNet对风格化角色更弱。
Runway公布其Characters产品的推理系统研究，说明这套可实时对话的虚拟角色背后是一个约 570 亿参数的自回归视频扩散Transformer。在 24 fps下，模型必须每 166.7 毫秒生成一个 704x1088的四帧视频块，一次服务一个用户，并持续整个会话。
Runway称，Characters上线时每会话使用八块H100。在四块H100上，上线版本的软件每个扩散步耗时 240.9 毫秒，超过 166.7 毫秒的要求；经优化降至 159.3 毫秒，达到 1.51 倍加速并稳定在 24.5 fps，使每个会话可在四块H100上实时运行。加入融合通信核后进一步降到 147.4 毫秒（1.63 倍）。这些数字来自Runway自己的论文与遥测。
为什么不能靠批处理省算力
Runway在论文中解释，传统生成视频按模型节奏工作：输入提示、等待、得到成品片段。对话角色不同，它要在对方说话时倾听、回应和反应，没有自然的停止点，也不能事后补上进度。
按Runway的计算，24 fps下每个会话需要 2.24 PFLOP/s的有效算力，超过单块H100的密集FP8峰值。矩阵乘法已接近该峰值的三分之二，把第二个会话加入批处理几乎会让每步耗时翻倍，因此每毫秒只能从单个步骤内部节省。
缓存与通信的改动
Runway称，每个扩散步要对一个潜变量帧做四次去噪，经过一个 60 块Transformer，合计 240 次注意力调用。每次调用读取 5,788 个槽位的缓存，其中只有 757 个是新的。原实现每次都要对整个缓存重做旋转位置编码（RoPE）、重新量化为FP8并靠复制移动窗口，这项维护占 239.2 毫秒一步中的 69.7 毫秒。
改动后，Runway在每帧写入缓存时应用RoPE和FP8量化，并按会话校准一次每头缩放，把缓存存成环状，使窗口推进无需复制。缓存维护降到每步 6.2 毫秒。位置每 42 步重置，重置时对缓存窗口做一次增量旋转，表现为每 42 步中出现一个 263 毫秒的较慢步骤，由播放缓冲吸收。
矩阵乘法之后，每个块还有一次张量并行all-reduce，每步 240 次。Runway将all-reduce融进FP8矩阵乘法，每个输出块的部分结果一落地就在NVLink交换机内归约。Runway称，在生产形状下融合调用 153.8 微秒，对比 208.2 微秒，隐藏了 54% 至 68% 的all-reduce时间。
解码器单独占一块GPU
把潜在表示转成视频帧的解码器每步耗时 114 毫秒。Runway称，如果让它与扩散模型共用GPU，这段时间会加到每一步上，因为张量并行组要等最慢的成员。让解码器独占一块GPU后，它在下一块去噪时解码上一块，步周期只比扩散时间多 1.6 毫秒。
Runway还测试了B200上的替代方案：解码和扩散共用的GPU达到 1,000 瓦功耗上限，使扩散核变慢 18% 至 26%。
质量如何评估
Runway表示，其中三项优化改变了模型数值：FP8缓存、融合的注意力前核和融合all-reduce。在自回归模型中，像素对比在几秒内就失去意义，因为任何数值差异，甚至GPU非确定性，都会让视频走向不同轨迹；约 10 秒后，同一生产配置的两次运行在PSNR上的差异与任意两种配置之间的差异相当。
因此Runway按任务评估：用 50 张合成参考图构建 53 个片段的评测集，覆盖写实、卡通、黏土动画、奇幻和非人类风格，并用生产配置运行四次以测量同一配置下的波动。Runway称，在 51 个可计分片段上，每次运行的平均唇形同步差异最大 0.03，95% 区间均在 ±0.08 内；四次生产运行本身的LSE-D跨度 0.024、LSE-C跨度 0.018；四段 10 分钟会话未出现超出重跑波动的差异。
论文也写明，这些结果给变化划出范围，而非证明等价：SyncNet对风格化角色更弱，区间宽两到五倍，四段长会话也无法排除缓慢趋势。
生产故障与回滚
Runway称，融合核于 2026 年 8 月上线并平稳运行数周。一次PyTorch和NCCL升级后，由于基准测试的输入不够多样，worker开始因内存不足而失败：会话首次前向传播的长度取决于提示，核为见过的每个token数保留缓冲区，而固定提示的基准从未触发这一点。
Runway表示，系统中每项优化都在开关之后保留普通代码路径，回滚到NCCL只需改配置。现在只融合稳态形状，首次前向传播走NCCL。经过 15 小时金丝雀测试，每段被测会话平均达 24.0 fps或以上，于 2026 年 10 月 8 日重新启用该核。此后 15 天，至少一秒的会话中有 0.7% 平均 24 fps或更低，而此前五周各周为 7% 至 23%。
Runway还披露，两个bug通过了所有eager模式测试，只在编译下失败；另一个每步调用一次 .item() 监控FP8缩放的bug，把一步从 168.5 毫秒拖到 278 毫秒。
对话延迟与硬件差异
Runway引用一项跨 10 种语言的研究：一位说话者结束到下一位开始的间隔平均 208 毫秒；单独的商业语音代理在同一指标上平均 1.30 秒。Runway追踪 12 场实时会话中的 51 轮对话，从用户语音结束到角色声音到达客户端的中位耗时为 2.13 秒，其中语音代理占 1.42 秒；Runway自己的管线从代理首段音频到首个说话帧耗时 0.49 秒，传到浏览器约 190 毫秒。
Runway称，生产环境在四块H100上每步 159.3 毫秒实时运行，在三块B200上为 154.3 毫秒。但并非所有H100优化都能迁移：FP8缓存在H100上省 17.0 毫秒，在B200上反而增加 2.4 至 6.7 毫秒，因为其构建没有接受每头缩放的FP8注意力核。增加GPU能加快模型但加快不了解码器：八块H100上扩散降至每步 118.2 毫秒，单块解码GPU跟不上，每步仍需 128.7 毫秒（31 fps）。