Real-time world model or video API? A 24 fps session vs a job

Use a real-time world model such as HelixWorld when a person must steer the camera and see the result as it happens. Use a video API such as Sume's when you need a finished clip you can store, caption and publish. Sume has no live session: every video request is an async job with a job id, and the answer arrives by polling or by webhook.

The two delivery models

HelixWorld's README reports real-time inference with a real-time factor of 0.77 on an NVIDIA H800, so a second of output takes under a second to compute. That is a figure for its own hardware. It also recommends a GPU with 80 GB of VRAM (a reviewed BF16 run uses about 70 GB), Linux, Python 3.11 and CUDA 12.x. Sume's jobs run on the provider's side, and Sume's docs say video usually takes from half a minute to several minutes, depending on the model and settings.

Designing around the wait

If you build a product on top of a video API, plan for the wait: show a queued state, poll with backoff, and prefer a callback_url for long jobs. The webhook is signed with x-sume-webhook-signature, so verify it before you trust the payload. Sync mode waits at most 30 seconds, and a job that has not finished by then must be polled, not resubmitted.

A middle path

A middle path is to pre-render a few branches. Make clips for the camera moves you expect, store them, and switch between them in the player. That is not a world model, but it gives a user a choice at a predictable price.