Visko runs its Orbis live world model in real time on Google Cloud TPUs

A world model that never stops streaming

Visko is building what it calls Live Models: video world models that generate continuously and respond on the fly. Its flagship model, Orbis, streams live video from a single text or image prompt. While the stream plays, viewers can type new steering prompts that change the scene without restarting it or breaking continuity.

Google Cloud describes one test session in which a livestream opens on a cat napping beside a crackling fireplace. When the viewer steers the scene to add a bowl of food, the bowl appears and the cat stretches, stands up and meows. According to the post, Orbis has been available as a public demo since September 1, 2026, and targets uses such as interactive entertainment, live commerce, AI companions, immersive education and robotics simulation.

Visko began working with Google Cloud TPU engineers in August 2026 to port the live pipeline to Google's Tensor Processing Unit. Within 30 days, the full multimodal pipeline was running in real time on TPUs, the companies say.

Why live video is a hard-deadline problem

The post stresses that the challenge is not average throughput but a strict clock. In a live stream, each chunk of video and synchronized audio must finish rendering before the viewer finishes watching the previous one, or the world freezes. Each chunk has to be denoised, decoded from latents, upscaled to 1664x936 at 18 fps and paired with generated audio faster than real time, for as long as the session lasts.

Two constraints make this harder than ordinary batch inference:

• Batch size of one: each stream is one viewer's interactive session, so latency cannot be hidden by grouping many requests into a large batch.
• Strict sequential dependency: the video model keeps a rolling memory of recent video latents so that chunk N+1 continues from chunk N. Chunks cannot be rendered out of order or in parallel across future timestamps.

For engineers used to LLM serving, the authors suggest thinking of this as an unforgiving per-step latency SLO rather than a tokens-per-second benchmark.

Three models on one TPU slice

To keep infrastructure lean as Visko scales, the team chained three generative models on a single Cloud TPU slice running in BF16 precision: the core video diffusion model, the super-resolution upscaler and the audio generator. They share the same chips and take turns on the hardware for each chunk.

The software stack rests on three open-source pieces. JAX is Google's Python array library for accelerators, compiled by the XLA compiler. torchax is an interoperability layer that runs PyTorch models on Cloud TPUs via JAX, so teams can bring existing PyTorch components over without a ground-up rewrite. Pallas is the custom kernel language for TPUs in JAX, comparable to writing Triton or CUDA kernels on GPUs.

After profiling and optimizing each stage, the team brought per-chunk latency under the real-time target while keeping roughly 7% headroom to absorb variance during live streaming. Video denoising accounts for nearly two-thirds of the compute budget, so it was the main focus of the kernel and parallelism work.

The optimizations that made the difference

The first was Ulysses context parallelism. At batch size 1, a video chunk becomes a very long sequence of spatiotemporal tokens inside the transformer. Instead of splitting model weights, Ulysses splits that token sequence across chips. Just before attention, an all-to-all exchange over the high-speed interconnect regroups the tensors so each chip holds the whole sequence but only one-quarter of the attention heads. A second all-to-all restores the sequence-split layout for the feed-forward layers.

The second was a custom Pallas splash attention kernel from MaxDiffusion, Google Cloud's open-source reference library for diffusion models on Cloud TPU. It brings FlashAttention-style tiling to TPUs: rather than building the full quadratic attention matrix in High Bandwidth Memory, it computes attention in compact tiles held in on-chip VMEM. The post says other startups can reuse the exact kernel through custom_splash_attention.py.

The third concerned audio. The team first moved all three Orbis models to TPU with torchax. For the video and upscaling models, torchax combined with Pallas attention kernels met the latency target. For audio, the post's section title points to a 5.8x speedup from moving from torchax to pure JAX, and the pipeline diagram shows pure-JAX audio generation. The excerpt of the post provided ends before the details of that step.

What it means for startups building real-time AI

Dave Elliott, Head of Developer Advocacy for AI at Google Cloud, said the co-engineering effort showed "how quickly a lean startup team can go from PyTorch prototype to render at 1.07x playback speed on Google Cloud's AI Hypercomputer."

For other teams, the example suggests a practical route: keep PyTorch components running through torchax, then replace only the bottleneck stages with custom Pallas kernels or pure JAX. It also shows that real-time, batch-size-one workloads can run on a single TPU slice when the work is split carefully across chips. These are the companies' own results, and the source does not give pricing or broader availability details.