Runway 的数字角色能以 24 fps 播放，开口回答要等多久？

客户问完问题后，动画角色只有一小段时间来回应。即使开始播放后画面流畅，第一声回答之前的停顿也可能让人以为通话断了。Runway 的一篇新论文给出了详细计时数据，可以看出这个间隔来自哪里。

Runway 于 2026 年 3 月 9 日推出 Characters。11 月 3 日的预印本介绍了会一边说话一边生成视频的对话头像，以及它背后的系统。这是对已推出产品的技术说明。Runway 的作者报告了自家系统的结果，包括如何在四块 NVIDIA H100 GPU 上运行视频。数字可以帮助团队明确试点要问哪些问题。换一种设备、连接或应用，就要在对应环境下测量。

用于测试 H100 硬件的服务器，GPU 类型与 Runway 论文所用相同。参考画面来自极客湾Geekerwan，已调整大小，CC BY 3.0。图片来源 · 许可证。

每组四帧只有约 167 毫秒的准备时间

实时视频生成。Telli.sh 原创示意图。

每秒 24 帧意味着，每隔约 167 毫秒就要准备好一组四帧。如果视频组到达得比播放器消耗得慢，为保持连续运动，系统就得增加缓冲、调整画质或采取其他措施。即使视频播起来流畅，一组帧也可能几乎用完整个 167 毫秒。

Runway 作者介绍的系统约有 570 亿参数，生成分辨率为 704×1,088 的帧。扩散步骤的用时中位数在参考配置中为 240.9 毫秒，在一种优化配置中为 159.3 毫秒，进一步融合算子后为 147.4 毫秒。一个完成去噪的潜在表征对应四帧，解码器另行并发运行。这些步骤计时的范围，与用户感受到的响应时间不同。

还有一个区别：首组画面开始后，视频生成可以维持足够速度。论文报告在其测量条件下，视频链路耗时为 0.49 秒，完整一轮的中位数约为 2.1 秒。语音处理、对话生成、语音合成、传输和首次有用的播放都影响对话。各环节可能重叠，从总用时减去视频用时，算不出任何单独环节的成本。

动起来的角色在哪些地方有实际用处

一个可行的试点是博物馆或展厅里的产品教学终端。访客问某个控制件有什么用途，应用从批准材料里选出简短答案，由角色回答，屏幕上的示意图仍保持可见。来访者可能从清楚的表情、视线和轮流说话的信号中受益。如果连接不稳定，系统可以转到文字说明。

另一个场景是员工角色扮演。受训者练习怎样回复一位不满的客户，再从培训应用获得反馈。这对时序的要求比念一段欢迎词更高。角色要能在半句话时停下、处理打断，并在听错一句话后恢复。除了常规延迟，试验还应记录参与者是否重复表达，或者是否和角色同时说话。

头像使用真人图像或声音时，还涉及同意与肖像使用。组织可以事先规定谁能创建角色、肖像能在哪里出现、怎样撤下。做实验时，使用明确的虚构人物，或取得出演人员的书面授权，能更容易把界面研究的发现和后续许可问题分开。

实际运行数据也留有空白

衡量完整对话轮次。Telli.sh 原创示意图。

作者报告，持续至少一秒的会话中，99.5% 的平均帧率超过每秒 23.5 帧。统计分母和取平均的区间很重要。一场会话通过平均帧率门槛，仍可能有明显的卡顿。回应也可能很快开始，随后却播得不流畅。论文没有给出每个买家在自己预期并发量下的首次响应时间分布。

小试点应包含普通办公网络、受限的移动网络，以及访客实际使用的设备类型。先用语音和文字记录建立基线，再对角色提出同样的问题。比较完成率、中途退出率和打断率。保持预设回答和对话策略不变，以便把差异归因于界面。既记录成功案例，也记录较慢的回应。

论文里的硬件配置不能告诉买家一次对话花多少钱。有用的单位可以是一次完整的训练对话，或一个被正确回答的访客问题。生成了多少分钟，要等团队弄清其中多少分钟有用才有意义。视频演示可以展示外观和动作。做了计量的真实对话可以说明应用是否准备好面向目标受众。

逐帧观察一场对话

论文报告了两组更具体的延迟分布。在 43 个标记轮次中，从用户说完到客户端播放头像语音的中位数为 2.13 秒，第 10 和第 90 百分位分别为 1.45 秒和 3.00 秒。从第一段代理音频到 LiveKit 捕捉到第一帧说话画面的中位数是 493 毫秒，第 10 和第 90 百分位是 421 和 562 毫秒。第一组描述测试条件下听到回答前的停顿，第二组涉及开始播放说话画面的时间。访客能感知这两种时序。

帧率来自另一次数据收集。作者说，他们记录了七周的工作进程遥测数据，也定义了哪些会话计入指标。在繁忙场馆试点时，可以观察刚被打断或多位访客同时到达时的播放缺口，作为论文结果的补充。记录实际客户端的音频和视频，让测量包括网络和播放表现。

公平测量对话时，标出人说完、代理开始回答和第一帧可见说话画面的时点。重复提出已知正确答案的问题。这样，测试者能区分来得慢但准确的答复，以及来得快却答偏的回应。加上几次在两套界面中时机相同的打断。

用已完成的会话来比较费用

Runway 帮助中心说明，启动时收取 2 点额度，活跃会话每 6 秒再收 2 点。按公布的税前每点 0.01 美元计，一次活跃 60 秒的会话为 22 点，即 0.22 美元。这只是依据公开计费模式的示例。实际支出取决于账号、活跃时间、现价和应用中可能单独收费的部分。

团队拿它和纯语音基线比较时，可以跟踪每次完整交流的成本。有人会在头像说完前离开，也有人因网络问题或答案不清楚而需要第二次交流。即使访客没有完成原来的任务，会话也消耗资源。计算完成率时保留中途放弃的会话，费用也要算进支出。

内容审核与管理成本也可能变化。公司可能要确认生成的讲话符合政策、合成人物可以在目标地区出镜，以及系统答不上来时访客能否转接给员工。像测试渲染系统一样认真测试这些路径。备选方式做得好，低速网络给访客带来的影响就能小一些。

让两种方式在同样条件下接受计量

1. 选择一种已经批准的互动，正确答案和成功结果都明确。
2. 在文字或语音基线以及头像版本中，使用相同的回答来源和对话策略。
3. 在访客实际使用的设备和连接上重复每条提示。加入一段长答复、一次主动打断和一次短暂断网。
4. 记录开始回答、出现说话画面、播放中断、打断是否成功，以及访客有没有完成任务。
5. 结合播放记录复盘失败。判断问题来自语音识别、答案生成、时间安排、网络，还是界面本身。
6. 扩大到更长时间或更大流量的用途前，对比两个版本的完成会话数与总成本。

这项试验可以说明，额外增加的视频渠道在哪里真有帮助。角色可以让一些人更容易知道什么时候该说话，也可能让另一些人多等一段时间。试点结果对应的是产生结果的互动、网络和设备。

看清计时数字背后的算力变化

作者描述了单个实时会话从使用八块 H100 减到四块的过程。他们报告，在尚未使用后续融合优化的四卡配置上，系统就达到了每秒 24.5 帧。结果说明特定软硬件配置在报告的负载下达到目标。它不保证另一种负载能有同样的并发能力，也没有说明客户账号会分配到什么硬件。

买家可以问供应商，哪部分服务先启动、容量不足时会怎样，以及会话怎么恢复。在展厅里，只要语音还在继续、问题能得到答复，视频短暂中断可能可以接受。同步要求更高的培训应用可能得先暂停，明确显示正在恢复，再从已知位置继续。中断后重复同一个动作，观察应用能不能知道用户已经听到了哪里。

用户在一句话中途打断时，也会遇到取舍。系统可以积累一些已生成的音频或视频，保证播放平滑。缓冲太大，用户开始说话时角色可能还在继续讲。缓冲较小，又可能更容易受到网络波动影响。分别测实际停声的时间和下一声回应出现的时间。

测试用户能理解的恢复方式

在小规模访客试验中，可以让回答播放到一半时，把连接从正常配置切换到慢速配置。记录声音是否停下、画面是否冻结，以及界面告诉用户什么。恢复正常连接后，检查角色是继续同一段回答、请用户重问，还是转到另一种渠道。对站在终端前的人来说，这三种结果差别很大。

如果系统无法恢复，且应用具备相应能力，可以提供文字记录、容易使用的书面说明或转接人工。短任务可能在视频失败后仍可完成。长训练可能需要回到检查点。恰当的行为取决于对话已经进行到哪里。

常规负载测试可以从三种到达模式开始。比较一个长会话、多个互相独立的短会话，以及一群访客同时到达。分别查看首个响应与较慢的尾部。播放开始后一直能维持目标速度，并不等于高峰时的体验好，因为访客可能要更久才等到第一声回答。

来源

• Runway Characters 用量和额度价格

• Runway 技术预印本，2026 年 11 月 3 日

• Runway Characters 发布，2026 年 3 月 9 日

• Characters 官方演示

---

如果想把工作背后的对话和决定留成可搜索的记录，可以创建 Telli.sh 账号。