Visko Orbis 世界模型在 Google Cloud TPU 上实现实时运行，但时钟永不停歇

Visko 在 30 天内将其 Orbis 管线迁移至 Google Cloud TPU，使 Visko Orbis 世界模型达到据称为播放速度 1.07 倍的性能。这个数字代表了一次微小却意义重大的跨越：系统能够在观众看完前一段内容前生成下一段内容，并留出约 7% 的余量。

这并非又一项更快的视频生成基准。Orbis 必须生成视频、进行超分辨率处理、生成同步音频，并在开放式会话中保持连续性。即使系统的平均吞吐量颇具竞争力，只要有一个片段过慢，体验就可能中断。

这让 Visko 走上了一条不同于离线视频生成器的工程路线。它也与 Odyssey、Decart 等公司并列，这些公司同样在严苛的延迟约束下构建交互式世界。竞争正从“谁能渲染出最惊艳的片段”，转向“谁能让一个生成世界持续运转”。

Visko Orbis 世界模型跨越播放时限

核心变化很简单：据称 Orbis 已足够快，能够在当前视频片段结束前生成下一个片段。

Visko 于 2026 年 9 月 1 日推出了公开的 Orbis 演示。根据双方于 10 月 15 日发布的联合 TPU 生产实践报告，该公司在 8 月期间已开始与 Google Cloud TPU 工程师合作。

在 30 天内，团队将完整的多模态管线从此前环境迁移至一个 Cloud TPU slice。slice 是一组互联 TPU 芯片，作为一个计算单元统一分配。

据称，最终系统以播放速度 1.07 倍进行渲染。实际而言，管线会在每秒观看时间内生成略多于一秒的成品媒体内容。这意味着在播放追上生成器前，约有 7% 的延迟余量。

这一余量很关键，因为 Orbis 并不是在加载页面背后生成一段完整视频。它从文本或图像提示开始，然后在观众观看时持续生成。用户可以提交新的提示来引导不断展开的场景，而无需重新开始另一段视频。

Google Cloud 描述了一项测试：Orbis 以一只在壁炉旁睡觉的猫开始。后续提示引入食物，使一个碗出现，同时猫起身并发出喵叫。这个例子结合了离线生成可以避开的多项要求。

视觉状态必须在片段之间延续。新物体必须进入已有场景。动物必须做出合理反应。生成的声音必须与动作保持同步。

Orbis 通过包含三个生成模型的管线处理这些任务。核心扩散模型生成视频；超分辨率模型将输出提升至每秒 18 帧、1664 × 936 像素；另一个独立模型生成同步音频。

三个模型共用一个 TPU slice，并为每个片段依次执行。它们并非运行在拥有独立硬件池、彼此无关的服务中。这种设计减少了基础设施的分散程度，但也带来了共享的时限。

每个片段都必须在播放缓冲区耗尽之前，完成去噪、潜变量解码、超分辨率处理和音频生成。潜变量是压缩后的数值表示，使模型无需直接处理每个输出像素，也能处理视觉信息。

因此，Visko 和 Google Cloud 表示，1.07 这一数字衡量的是端到端管线，而不只是某项有利模型操作的速度。这一区别使该结果与生产系统更相关。

不过，这一数字来自构建和部署系统的公司。两家公司均未发布第三方基准测试，覆盖长时间会话、多样化提示、并发用户或更大生产规模下的延迟表现。

因此，这项成果应被视为有据可查的部署结果，而非普适性能保证。它的重要性在于证明完整的实时管线可以在一个加速器 slice 上跨越播放时限。

这一时限构成了本文的核心张力。离线生成器优化吞吐量和等待时间；实时世界则必须优化每一个连续步骤，因为昨天的平均表现无法挽救此刻迟到的帧。

实时视频让延迟成为硬性失效条件

实时世界模型无法通过数分钟后生成更快的片段，来弥补一个迟到的片段。

传统视频生成赋予后端相当大的调度自由。请求可以在队列中等待、共享大批次，或在可用加速器之间迁移。用户只会在获得最终成品前经历一次等待。

连续生成消除了其中大部分灵活性。每位用户都占用独立且持续演化的状态。下一个片段取决于系统已生成的内容，以及用户提供的任何新动作。

这使批次大小变为一。批处理通常让加速器能够同时处理相似请求，从而提高利用率和总体吞吐量。当每个世界都携带自身历史和引导指令时，Orbis 无法自由合并无关会话。

第二项约束是顺序依赖。Orbis 会保留近期视频潜变量的滚动记忆，以便下一个片段延续当前场景。片段 N+1 直接依赖片段 N。

系统无法提前渲染遥远未来的片段。观众可能更改提示、调整预期动作，或改变场景方向。一旦新输入到达，推测性输出就会失去意义。

这使实时世界模型的延迟更接近交互式服务等级目标，而非媒体导出基准。管线的每个阶段都消耗同一个时限的一部分。波动性的重要程度几乎与平均值相当。

7% 的余量或许可以吸收小幅调度波动，但它并不是很大的安全缓冲。编译暂停、网络延迟、内存压力，或异常困难的片段都可能将其耗尽。因此，生产可靠性取决于延迟分布中最差的部分。

这种区别也改变了团队解读加速器利用率的方式。当排队操作可能错过播放时限时，让每枚芯片始终满负荷运行并不一定可取。即使在吞吐量图表中看似低效，预留容量也可能是必要的。

Visko 的工作负载说明，为语言模型服务设计的实践无法直接迁移。LLM 服务通常会在管理首个 token 延迟和 token 间延迟的同时，报告跨用户的每秒 token 数。它可以对形状兼容的请求进行批处理和调度。

实时视频世界在每一步都承载更多数据。它必须协调空间与时间 token，将其解码为帧，放大这些帧，并同步声音。该工作负载还要在没有预定终点的序列中维持视觉状态。

技术文献也指出了同样更广泛的难题。一项 2026 年的世界模型综述将该领域的瓶颈归纳为可控性、长期记忆和响应能力。更快渲染只直接解决了第三类问题。

这些类别彼此交织。更强的记忆能力可能需要更多上下文，从而增加计算量。更高响应性可能促使采用更短片段，进而带来更频繁的协调开销。更精确的控制则可能引入额外的条件处理工作。

因此，一个系统可能通过速度测试，却仍会在长时间运行中丢失物体、改变布局或忽略指令。它也可能通过抗拒用户要求的改动来保持视觉连贯性。最困难的产品问题，是如何同时平衡这些属性。

这正是 Visko 的成果对加速器厂商之外的参与者也施加压力的原因。模型架构师必须为增量生成而设计；基础设施工程师必须瞄准尾部延迟；产品团队则必须决定，在不中断的体验中用户能够接受多少不一致性。

离线视频公司同样面临战略选择：继续优化精致且有边界的短片，还是围绕持续状态和输入重构系统。后一路线需要的不只是降低现有模型的渲染时间。

一个 TPU Slice 迫使三个模型共享时钟

Visko 通过将管线作为一个受约束的整体进行优化来实现实时播放，而不是替换每个 PyTorch 组件。

最终架构采用 BF16 精度，这是一种适用于机器学习计算的 16 位数值格式。BF16 在保留较宽数值范围的同时，降低了内存和算术需求。

据其工程实践报告，Visko 和 Google Cloud 曾考虑采用更低精度的 FP8 计算。他们发现，小型量化误差会在连续片段中累积，并影响视觉质量。BF16 则在延迟预算内运行，且没有出现同样的报告性退化。

这一选择揭示了有边界请求与开放式流之间的关键差异：单张孤立图像中的微小误差会随该图像结束；循环性误差则可能成为用于生成后续所有内容的状态的一部分。

团队围绕 JAX、torchax 和 Pallas 构建软件栈。JAX 提供由 XLA 为加速器编译的数组操作。Torchax 让 PyTorch 程序能够通过 JAX 和 XLA 在 TPU 上运行。

这种组合形成了一条迁移路径，无需立即全面重写。视频扩散和超分辨率模型通过 torchax 保留在 PyTorch 中；只有音频阶段完全迁移至原生 JAX。

据称，这种选择性移植使音频生成速度提升了 5.8 倍，也让完整管线进入时限之内。与“重写一切”的笼统建议相比，这一结果提供了更有用的经验。

兼容层可以加速迁移，但可能在特定执行路径中留下开销。性能分析能够确认这种开销是否重要；原生代码则应部署在能改变端到端结果的环节。

Visko 的视频去噪阶段消耗了近三分之二的总体计算预算。去噪是扩散模型将初始带噪潜变量表示反复转换为结构化视频内容的过程。

团队采用 Ulysses 上下文并行来优化这一阶段。Ulysses 并非将模型权重拆分到各芯片，而是拆分长视频 token 序列。

在注意力计算之前，芯片会交换数据，使每个芯片处理完整序列中一部分注意力头。随后，另一次交换会恢复用于前馈操作的序列拆分布局。

这一策略适合一种棘手的工作负载。系统无法扩大批次大小，但单个视频片段仍包含跨空间和时间的大型序列。拆分该序列可以让多个芯片在单个观众的会话中承担有效工作。

这种方法依赖快速的芯片间通信。当互连无法足够快地传输张量时，全互连交换可能变得昂贵。Google 的 TPU 架构使这一通信模式能够在一个 slice 内实际运行。

团队还使用了来自 MaxDiffusion 的自定义 Pallas splash-attention 内核。Pallas kernels 让开发者能够在 JAX 生态系统内编写专用加速器操作。

Splash attention 将与 FlashAttention 相关的分块执行思路适配到了 TPU。它避免在高带宽内存中实例化完整的二次方注意力矩阵，而是使用更快的片上内存处理紧凑的数据块。

这项优化很重要，因为注意力成本会随序列长度迅速增长。视频 Transformer 覆盖的时空位置远多于许多文本请求。减少内存流量的重要性，可能不亚于减少算术计算。

Google Cloud 表示，针对这一单流工作负载，Ulysses 的表现优于张量并行和环形注意力。由于性能取决于架构、形状、硬件和通信模式，这一发现不应被泛化到所有模型。

该部署还会缓存已编译的 XLA 工件。未缓存的首次启动可能需要花费数分钟编译计算图。报道称，复用这些工件可将工作节点重启时间缩短至一分钟以内。

对于活跃会话而言，不到一分钟的重启时间依然过长。编译缓存主要改善服务恢复和容量管理。用户层面的连续性仍需要路由、缓冲或其他恢复机制，而两家公司并未详述这些机制。

更大的机制是一系列有针对性的权衡。torchax 能赶上期限的部分，Visko 保留了 PyTorch；兼容层无法满足需求的部分，则采用原生 JAX。为保护连续输出，它选择了 BF16 而非更快的格式。

这正是 Visko 实现实时世界流式传输的方式：不把加速器视作神奇的速度升级工具。硬件、编译器行为、内核、模型划分和输出质量都共同占用同一份延迟预算。

真正的竞争是连续状态，而不是帧率

Visko 已跨过一道性能门槛，但竞争对手表明，实时世界模型正因交互模式和目标市场而出现分化。

Odyssey 在 2025 年推出了一款可玩的世界模型，据称最高可实现每秒 30 帧的流式输出。其系统在美国和欧洲使用 Nvidia H100 GPU 集群运行。

该公司表示，操作最快可在 40 毫秒内影响视频。其可玩的世界模型会根据当前状态、近期历史和传入的用户操作预测新帧。

这种设计不同于传统的片段生成器，后者会在播放前确定一个有边界的序列。它也为 Orbis 提供了重要的比较对象。两个系统都将生成视频视为交互循环，而非已完成的文件。

公开规格无法直接比较。Odyssey 报告的是 GPU 集群上的单帧响应速度和最高帧率。Visko 报告的是单个 TPU slice 上每秒 18 帧的端到端分块生成速度。

分辨率、模型规模、视觉质量、会话时长、输入方式和硬件分配也各不相同。没有共享评测，更高的帧率并不能证明世界模型更好。

Odyssey 自身也将早期体验描述为不稳定且功能有限。这种坦率揭示了基础速度指标掩盖的弱点。一个世界可以快速响应，却同时出现空间漂移、物体身份变化或因果结构丢失。

Decart 则通过 Oasis 走上了另一条路线。其当前的物理 AI 模型面向机器人工作流，采用动作条件化的多摄像头模拟。Decart 表示，该系统的端到端延迟低于 200 毫秒。

这一目标要求的不仅是具娱乐性的视觉连续性。多个摄像头视角必须对同一环境保持一致。机器人策略必须获得对闭环训练和评估仍然有用的响应。

Visko 将娱乐、商业、陪伴、教育和机器人模拟列为 Orbis 的应用场景。这些市场有不同的标准。令人意外的物体变化或许会逗乐娱乐用户，却可能破坏机器人实验。

因此，这一领域需要的不止一种“实时”标签。有价值的比较应披露首帧时间、控制响应延迟、持续帧率、输出分辨率、会话时长、硬件分配和故障率。

它们还应衡量指令遵循能力和长时间跨度的一致性。一个模型若能立即响应操作却忘记房间状态，并未解决交互式模拟问题。一个模型若能保留房间却忽略操作，也并未解决控制问题。

共享基准仍不成熟，因为开放式世界难以简单评分。人工判断可以评估视觉质量，但成本高且不一致。自动化指标往往无法判断生成环境是否仍具有因果上的实用性。

Visko 的 Orbis 世界模型为这一格局增加了另一种基础设施选项。它表明，GPU 集群并非实现实时生成视频的唯一途径。但它并未证明一个 TPU slice 在成本或质量上优于竞争部署。

Visko 和 Google Cloud 均未披露确切 TPU 版本、芯片数量、模型参数量、分块时长、利用率或运营成本。这些遗漏限制了架构比较和商业结论。

并发性也是另一个未解问题。一个流以 batch size one 运行，但生产服务需要许多独立流。运营者必须确定每个会话是否获得专用容量，还是调度可以安全地交错不同工作负载。

需求不太可能均匀到来。直播娱乐活动、课堂和商业会话都可能造成突发高峰。延迟余量很小的系统，需要足够的预热容量来吸收这些高峰，而不延误活跃世界。

此外还有平台问题。在 Google Cloud 工程师直接协助下完成的迁移，可能并不代表普通的自助迁移。此次协作展示了技术上的可行性，但并未说明另一家初创公司需要投入多少专业工作。

Google 已发布相关组件，包括 JAX、torchax、Pallas 和 MaxDiffusion。开源代码能够减少重复劳动，但不能消除模型特定的性能分析、调试、数据移动或质量评估需求。

两家公司所称的 30 天时间线，作为项目记录是可信的；但读者不应将其视为标准迁移周期。Visko 已拥有可运行的模型，并直接与 TPU 专家合作。初始条件决定了大多数基础设施项目的时间线。

这种不确定性并不抹杀这一成果，而是界定了它的边界。Visko 和 Google Cloud 展示了一条跨越狭窄延迟门槛的连贯技术路径。剩余的竞争关乎耐久性、经济性和可重复性。

7% 的余量并非生产环境的定论

报告中的余量证明了公开配置下的可行性，但几乎没有为无法解释的波动或产品增长留下空间。

实时生成系统必须比受控演示坚持得更久。会话可能遇到异常提示、视觉密集场景、复杂运动或反复控制变化。这些条件中的任何一种都可能改变执行行为。

Google Cloud 的报告称，总延迟低于播放目标，余量约为 7%。但它没有公布百分位分布。读者无法看到中位性能与最慢成功分块之间的差距。

缺失的分布数据很重要。一个系统即使中位数安全、却频繁错过截止时间，仍会出现明显卡顿。生产团队通常会关注高百分位延迟，因为罕见延迟会在长会话和大规模用户群中变得常见。

报告也没有量化丢帧、音频同步错误、控制延迟或会话故障。这些都与原始生成速度不同。流水线可以按时完成一个分块，却输出质量不佳或时机失准的响应。

长时间跨度的稳定性也是另一项悬而未决的问题。Orbis 会维护近期 latent 的滚动记忆，这有助于让一个分块延续前一个分块。滚动窗口并不会自动保留已从近期视野中消失的事实。

窗口之外的物体可能以不同形状或位置重新出现。角色可能改变外观。房间可能失去其几何结构。随着会话超出开发期间使用的演示范围，这一问题会愈发突出。

选择 BF16 表明，Visko 遇到了一种累积误差。FP8 减轻了带宽压力，但量化变化据称会跨分块累积。这为更广泛的连续生成系统敲响了警钟。

优化不能只根据短输出样本来评判。它们必须经受反复应用。一次迭代中的微小损失，可能在数十或数百次迭代后变得可见。

安全与审核还会带来额外的延迟工作。开放式世界可以随时接收新的提示。筛查输入、监控生成视频以及应对不安全输出，都会消耗时间或需要并行系统。

公开架构聚焦于生成本身，并未解释审核如何嵌入实时循环。对于工程案例研究而言，这一遗漏可以理解，但对娱乐、教育和陪伴类产品而言至关重要。

商业可行性同样仍不明确。在一个 slice 上运行全部三个模型，可能减少协调和基础设施复杂度。但没有公开数据表明每用户小时成本、可接受利用率或可支持的并发会话数量。

一项服务可以在技术上实现实时，却在经济上不可行。用户会话时长存在差异时，专用加速器容量尤其难以管理。供应商必须为闲置余量付费，或冒着接入超过系统承载能力会话的风险。

产品设计者可以通过缓冲掩盖部分波动。更大的播放缓冲区会给生成器更多时间从慢分块中恢复，但也会延迟控制指令带来的可见响应。

这是实实在在的权衡。更多缓冲可提升连续性，却削弱交互性。更少缓冲会让操作感觉即时，却让观众直接感受到计算波动。

Visko 尚未披露 Orbis 位于这条曲线的哪个位置。1.07 这一数字描述的是相对于播放的生成速度，但并未揭示端到端控制响应。用户可能更在意控制延迟，而非名义渲染速度。

最后的不确定性涉及验证。工程细节足够具体，具有参考价值，而且若干组件已公开提供。不过，核心性能测量数据来自 Visko 和 Google Cloud。

独立测试将增强这一主张的可信度。一项有价值的评估应在长会话中运行多样化提示，报告延迟百分位，披露硬件分配，并评估反复控制事件后的连续性。

在此之前，这一结果应被理解为一项严肃的生产案例研究，但其公开基准测试仍有限。它通过揭示具体约束、优化措施和失败的替代方案，推动了讨论向前发展。

它并未判定哪种硬件平台、模型架构或商业设计将在实时世界生成领域占据主导。这些问题需要持续的运营证据。

Visko TPU 交接后值得关注的事项

下一项考验是，Visko 能否将狭窄的实时余量转化为可供众多并发用户使用的稳定、可衡量服务。

第一个信号将是持续的生产数据。Visko 应披露不同工作负载下的高百分位分块延迟、截止时间错失率、会话时长和控制响应。

如果这些数据在更长的会话中保持稳定，当前结果就不仅仅像一次成功迁移。如果延迟会随场景复杂度或会话时长急剧上升，那么 7% 的缓冲余量将显得过于狭窄。

第二个信号是并发经济性。关注每个切片可支持的会话数、加速器利用率、冷启动情况和区域容量等细节。这些指标决定了 Orbis 能否在无需过度预留硬件的情况下支撑面向公众的产品。

具备成本效益的多会话调度证据，将强化单切片架构的合理性。若高度依赖专用切片，可行应用将局限于能够承担高额算力成本的市场。

第三个信号是与 Odyssey、Decart 及其他交互系统进行统一标准下的评测。仅看帧率并不足够。比较需要采用等效分辨率、披露硬件配置、包含会话时长、引导测试和连续性指标。

可信的基准测试将揭示 Orbis 是以牺牲视觉保真度换取速度，还是能在其预算范围内兼顾两者。它还将说明文本引导能否为该公司提出的应用场景提供足够的控制能力。

对开发者而言，眼下的启示更具体，也更务实。实时世界模型需要围绕完整的用户可见闭环进行优化。平均吞吐量无法替代在截止时间前交付的内容片段。

探索这一类别的团队，应在模型实验之外同步记录内核性能分析、质量回归、编译行为和延迟分布。可检索的工程知识库能够让这些决策始终与其证据关联。

Visko Orbis 世界模型已在 Google Cloud TPUs 上跨越了一个重要门槛。如今，Visko 必须证明：当提示词、用户和运行条件不再像基准测试那样规整时，这个世界仍能持续运转。