生成式AI初创公司正快速从静态片段生成转向构建互动实时世界。Visko是一家构建交互式世界模型的AI初创公司，其旗舰模型Orbis能够从单个文本或图像提示流式生成实时视频，观众在播放中输入steering prompts动态改变场景。例如测试中，直播流开始于一只猫在噼啪作响的壁炉旁打盹；当观众输入加一碗食物的指令，碗会无缝出现，猫伸懒腰、站起来并喵喵叫。Orbis自2026年9月1日公开demo，应用场景涵盖互动娱乐、实时商务、AI伙伴、沉浸式教育和机器人仿真。

实时世界模型的生产挑战不在平均吞吐量，而在必须打败实时时钟。与离线生成器不同，用户提交提示后排队等待即可；实时世界模型连续流式输出，每个新视频块和同步音频必须在观众看完前一个块之前完成渲染，否则世界就冻结。具体来说，每个视频块都要去噪、从潜空间解码、超分到1664×936分辨率（18fps），并与生成的音频同步，且整个会话期间必须快于实时播放速度。两个结构约束让事情更难：batch size为1，每个流是独立观众会话，无法用批量隐藏延迟；严格顺序依赖，每个块依赖前一个块，因为模型维护滚动记忆以保持动作连贯，不能乱序预渲染或跨未来时间戳并行。文章提醒，LLM服务工程师应把实时世界模型当作每一步的延迟SLO，而不是每秒token吞吐量。

Visko与Google Cloud TPU工程师合作，将视频扩散、超分辨率上采样、音频生成三个生成模型链式串联，部署到单个Cloud TPU slice上，以BF16精度运行。软件栈基于三个开源支柱：JAX（由XLA编译器编译为优化机器码）、torchax（让PyTorch模型通过JAX运行在TPU上的互操作层）和Pallas（JAX中的TPU自定义内核语言，类似GPU上的Triton/CUDA）。项目从启动到生产移交仅30天，最终实现1.07倍播放速度的实时渲染。通过剖析与优化每阶段，每chunk总延迟低于目标，并保留约7%的余量应对直播抖动。视频去噪占总计算预算近三分之二，因此成为内核与并行优化重点。

三个关键优化推动了实时能力。首先是Ulysses上下文并行：batch size为1时，不切分模型权重，而是将token序列切分到不同TPU芯片；在注意力层之前，通过高速all-to-all互联交换张量，使每块芯片持有完整视频序列、但只计算四分之一注意力头；计算完注意力后，再一次all-to-all交换恢复序列切分布局供前馈层使用。在单流视频场景，这一方法比张量并行和ring attention更快。第二个优化是来自MaxDiffusion的Pallas splash attention内核：它把FlashAttention风格的分块计算带入TPU，不把完整二次方注意力矩阵写入HBM，而是在片上VMEM中计算紧凑分块。该内核可通过custom_splash_attention.py直接放入现有管线。第三，音频模型从torchax迁移到原生JAX，获得5.8x加速。视频和超分模型留在torchax即满足延迟，只有音频是瓶颈需要重写。团队建议：torchax的价值在于快速把PyTorch模型跑上TPU，先获得端到端遥测，再只重写真正主导延迟的组件。

针对连续流工作负载，团队还给出几条实用经验：原生BF16比FP8更适合连续流，因为FP8量化误差会在块间累积；原生BF16在延迟预算内保持视觉质量完整。XLA编译缓存很关键，首次启动编译图需几分钟，缓存编译产物后worker重启不到一分钟。文章最后给出了开发者可直接使用的资源：MaxDiffusion中的splash attention内核、Pallas文档、torchax、Cloud TPU Profiler、TPU Flex-start VMs，以及Google for Startups Cloud Program。对于追求超低延迟生成式AI的团队，这套路径可以借鉴：先用torchax快速移植，再用Profiler定位瓶颈，最后用Pallas或原生JAX重写热点。