本文要点
- 从一次性 prompt 出片，变成语音连续控制未来帧。
- 从固定时长短片，变成论文声称的无限长度流式生成。
- 从离线画质指标，加入 FPS、延迟、会话成本等系统约束。
阅读辅助
先看数字、证据和来源，再读正文。
Vidu S1 公开了语音控制数字角色的实时视频生成论文和入口。
2026-07-03 · Vidu S1 论文以 arXiv:2607.03118 v1 提交到 cs.CV 与 cs.LG。
Vidu S1 值得放进今日深度，原因在于它把视频生成的产品问题从“等模型离线出片”推向“用户在会话中实时控制未来画面”。论文、README、GitHub 更新和 Vidu API 页面共同给出一个清晰方向：数字角色正在从预生成短片，变成可听语音、可持续输出、可进入 API 计费和服务系统的 live session。
已经确定的事实是：arXiv 页面显示论文 2026 年 7 月 3 日提交，标题为 Vidu S1: A Real-Time Interactive Video Generation Model。摘要称模型支持对数字角色进行实时语音控制，用户可以在任意时刻用语音指令控制生成内容；论文还称它支持无限长度实时视频生成，不出现快速模糊、漂移或视觉失真。性能口径上，论文和 README 都写到 540p 最高 42 FPS，论文表 1 进一步标注为 960x540，并说明实时评测使用 3-step 配置，在 RTX 5090 GPU 上测得平均 42 FPS。
不确定部分也必须前置。本文按低置信处理，原因是少源且未复现。42 FPS、Vidu-StreamBench 上的人类偏好结果、HDTF 表 1 中的 CSIM 0.9192、Sync-D 7.8470 和 DOVER 0.5660，都来自论文作者自测。Vidu-StreamBench 是团队内部基准，包含 500 个样本，但截至本稿写作没有看到完整样本和第三方复现。Vidu Stream demo URL 存在，但用最小 HTTP 抓取时返回脚本挑战；README 链接的 Notion 用户指南也只返回 Notion 应用壳，因此本文不把这些页面当成功能细节证据。
对读者的影响在于，实时视频生成的竞争变量发生了变化。离线视频模型主要比画质、时长、镜头稳定性和 prompt 遵循；实时交互模型还要比首帧延迟、持续会话稳定性、语音听懂率、身份保持、动作可控性、GPU 成本、并发调度和审核边界。开发者看到的是一个新 API 入口，内容平台看到的是直播和虚拟角色工具，企业买方则要先问清楚授权、日志、成本和失败恢复。
发生了什么
Vidu S1 的论文把问题定义为 speech-guided future video generation。这个表述比“音频驱动头像”更具体：用户不是只上传一段语音让头像对口型，而是在生成过程中持续发出语音指令，让角色接下来挥手、比心、竖大拇指、抬腿或坐下。论文图 1 把这种能力拆成三块：语音引导未来视频、无限高效推理与服务、支持多种自定义角色。
README 给出的产品话术与论文一致。它把三项突破写成实时语音控制、无限长度实时交互生成、自定义角色图片和声音语调。README 还链接到 Vidu Stream、arXiv 论文、英文和中文用户指南、API 文档和 API quickstart，并在 2026 年 7 月更新说明里写到 Vidu S1 已作为可试玩平台开放。GitHub commits API 显示 7 月 10 日仍有演示 GIF 相关提交，说明项目页在 HF Papers 当日收录后仍在整理展示资源。
论文的方法部分给出的是一套模型与系统组合，而不是单个生成网络。数据侧，团队描述了从原始直播、talking-head 和影视素材中筛出单人、单镜头、高质量、音画同步的训练片段，并通过说话人分离、active speaker detection 和结构化 caption 建立视频、音频和文本条件。训练侧，论文写到三阶段流程：先训练双向 video-audio teacher，再转向因果自回归生成，最后用 Distribution Matching Distillation 和 Phased Consistency Models 正则化做少步生成。服务侧，论文把 TurboDiffusion 和 TurboServe 放在同一套推理栈里，强调 attention acceleration、多 GPU 并行和流式调度。
这些细节说明，Vidu S1 不是只在模型输出层做一段头像动画，而是在把“可交互视频”当成系统工程。实时性不是模型最后一层的指标，而是数据、训练、蒸馏、推理 kernel、服务调度和 API 计费共同决定的结果。
| 维度 | 论文口径 | 产品页口径 | 早报解读 |
|---|---|---|---|
| 输出分辨率 | 540p，表 1 写 960x540 | 540P streaming output | 论文和产品页都强调 540p，但指标口径不同 |
| 帧率 | 最高 42 FPS，RTX 5090 上平均口径 | 25 FPS streaming output | 论文吞吐不等于产品默认流式输出 |
| 生成方式 | 3-step 少步配置，面向实时推理 | Live call 和 text prompt steering | 交互接口已经产品化，但能力边界需实测 |
| 基准 | Vidu-StreamBench 500 样本，HDTF 指标 | landing 页面未披露基准 | 论文基准是研究证据，产品页是商业入口 |
| 成本 | 论文强调 low-cost GPU，但未给价格 | 3 credits per 2s | API 成本会成为开发者真正的约束 |
| 延迟 | 论文强调 real-time inference | 首帧延迟 as low as 200ms | landing 页口径需在真实网络下复核 |
技术上真正变了什么
视频生成过去两年的主流范式，是用户输入 prompt，然后等待模型一次性生成完整片段。Sora、Veo、Wan、Seedance 等模型让画质和复杂镜头能力快速提升，但产品体验仍然接近“提交任务，等待结果”。Vidu S1 论文在引言里直接批评这种 one-shot offline paradigm：用户在等待期间不能主动互动，模型也不能在生成过程中接收新的自然语言或语音控制。
Vidu S1 的增量在于把控制信号放进时间轴。用户的语音不只是音频驱动嘴型，而是显式控制未来内容。论文称模型可以在任意时刻接收指令，并把“未来帧应该发生什么”作为生成条件。这会改变产品设计：一个虚拟主播不再只播一段脚本，而可以根据观众指令改变动作；一个陪伴角色不再只回应语音文本，而要让表情、手势和身体动作跟上对话；一个游戏 NPC 不再只播放预设动画，而需要在会话中连续生成可控动作。
第二个变化是长时间生成。论文称 Vidu S1 支持 infinite-length real-time generation，并把 drift、instability 和 visual collapse 作为核心问题处理。这一点需要谨慎解读：论文提出了稳定流式生成的目标和自测结果，但没有公开第三方长时间压力测试。真正的产品问题是，角色是否能在 10 分钟、30 分钟、90 分钟会话中保持身份、背景、服装、口型和动作意图稳定；一旦出现漂移，系统能否重置、纠正或提示用户。
第三个变化是服务指标进入论文。表 1 不只列 CSIM、Sync-D、DOVER，还把 real-time、resolution、FPS 或 throughput 写进比较表。论文结果显示，Vidu S1 支持 instruction following 和 real-time，标注 540p 与 42 FPS；HeyGen 表中为 25 FPS，Kling Avatar 2.0 支持 instruction following 但表中没有 real-time 标记。这个比较的方向很明确：数字人模型的评价不再只看脸像不像、嘴型对不对，还要看是否能在实时会话里接受动作指令。
证据链和边界
这篇文章的信源强度是“中等”。高置信部分包括论文存在、arXiv 提交日期、HF Papers 7 月 10 日收录、GitHub README 内容、仓库 7 月 10 日提交记录、Vidu Stream 和 Vidu API landing URL 存在。中置信部分包括 42 FPS、内部基准领先、无限长度稳定生成和产品页首帧延迟，因为它们来自团队自述或 landing 页面，没有第三方复现。
arXiv 页面是核心论文来源，但日期是 7 月 3 日，因此在今日早报里只作为背景和论文内容来源；当天的新鲜锚点来自 Hugging Face Papers 的 7 月 10 日更新和 GitHub 同日提交。这个区分很重要：不能把 7 月 3 日论文伪装成 7 月 11 日首发，也不能只用聚合页凑新鲜度。今天的新闻价值在于 HF Papers 收录、项目页维护、API 入口和实时视频生成方向被社区重新看见。
产品页还暴露出一个值得注意的口径差异。论文强调 42 FPS，Vidu API landing 写的是 540P、25FPS streaming output，同时写到 first-frame latency as low as 200ms 和 3 credits per 2 seconds。这不是简单矛盾，而是研究吞吐与产品默认输出之间的常见差异。论文中的 FPS 更像模型与系统在特定硬件和配置下的吞吐能力；产品页中的 FPS、延迟和 credits 更接近开发者实际使用时会遇到的商业配置。
为什么重要
Vidu S1 之所以值得关注，是因为它把视频生成推向了“生成式界面”。如果视频模型只能离线出片，它主要服务广告、影视预演、社交短视频和创意素材；如果视频模型能实时响应语音，它就会进入直播、客服、陪伴、教育、游戏 NPC、虚拟偶像和交互媒体。前者是内容生产工具，后者更接近实时应用平台。
这会给平台带来新的安全和治理问题。README 明确写到用户可以上传真人、动漫角色、宠物等自定义图片，也可以选择不同 voice tones。只要真实头像和声音进入实时会话，授权、肖像权、声音克隆、未成年人保护、内容审核和日志保存都会变成产品必答题。离线视频生成至少可以在出片前做审核；实时视频生成需要边生成边管控，审核延迟本身也会影响体验。
开发者侧的约束也会变。过去接入视频生成 API，主要估算每条视频的生成成本和等待时间；接入 Live API，则要估算每秒或每两秒 credits、并发会话、断线重连、首帧延迟、输入音频质量、用户打断、敏感动作拒绝和长会话状态管理。Vidu API landing 的 3 credits per 2 seconds 说明，它的成本结构更像实时服务，而不是一次性素材生成。
研究者侧则需要新的基准。Vidu-StreamBench 的方向是对的：动作指令、参考首帧、音频片段、人类偏好、subject controllability、motion、synchronization 都比传统视频质量指标更贴近 live avatar。但它仍是内部基准。这个领域需要公开、可复现、跨厂商的实时交互评测，尤其要测用户中途变更指令、连续错误恢复、长时间身份保持和多语言语音控制。
早报判断是，Vidu S1 的核心增量在于把视频生成的竞争从“谁能生成更漂亮的一段视频”推向“谁能维持一个可交互的视频会话”。这个变化会让模型能力、推理系统和产品治理绑在一起。画质只是入场券，实时控制、长时间稳定、低延迟、并发成本和安全审核才是上线门槛。
这条路线对数字人和虚拟角色公司尤其直接。过去很多数字人产品本质上是语音驱动口型和表情，动作自由度有限；Vidu S1 论文把语音指令变成未来动作控制，并把 subject controllability 放进偏好评估。若这种能力被第三方复现，直播、陪伴、教育和游戏角色会从“会说话的头像”走向“可被语音导演的角色”。
但当前不能把厂商自测当成行业结论。42 FPS、500 样本内部基准、HDTF 指标和 200ms landing 页面口径，都需要真实网络、真实 GPU、真实用户输入和长会话压力测试。更稳妥的结论是：Vidu S1 给出了实时交互视频生成的清晰样本，证明厂商正在把视频模型从离线创作工具推向 live API；它是否成为平台级能力，还要看复现、成本和治理。
接下来看什么
第一，等第三方复现 42 FPS。论文提到 RTX 5090 与 3-step 配置，但开发者更关心不同 GPU、不同并发、不同角色复杂度、不同网络条件下的吞吐和延迟。若只能在团队环境里成立，产品价值会打折；若在常见消费级 GPU 或云 GPU 上稳定复现，实时视频生成会更快进入工具链。
第二，看长时间会话稳定性。论文提出无限长度生成，但真正的测试应覆盖 10 分钟以上、多轮打断、多次动作切换和噪声语音输入。需要观察身份是否漂移，背景是否渐变，服装和宠物特征是否保持，错误动作能否纠正，以及系统是否能在不重启会话的情况下恢复。
第三，看 API 文档和价格细则。Vidu API landing 已有 Live 入口、25 FPS 产品输出口径和 3 credits per 2 seconds，但开发者还需要区域可用性、并发上限、模型选择、输入格式、超时策略、审核返回码、日志保存、企业 SLA 和退款规则。实时服务的商业可用性，往往不是论文指标决定的。
第四，看安全审核与授权。自定义真人头像和 voice tones 是高价值功能，也是高风险入口。平台需要说明上传照片和声音是否需要授权证明，是否支持 watermark 或身份标识，是否记录会话输入输出，是否允许公众人物或未成年人形象，如何处理诱导角色说出敏感内容或做出不当动作。
第五，看 Vidu-StreamBench 是否开放。公开样本、评分脚本、人类偏好流程和失败案例，比继续发布单张对比图更有价值。实时交互视频生成需要行业共同评测，否则每家厂商都会用自己的会话设置、自己的偏好样本和自己的展示 GIF 证明领先。