Managed platform, rented GPU or self-hosting: how to run a realtime video model
Compare managed APIs, rented GPUs and self-hosting for realtime video models. Understand session costs, infrastructure work and when each approach fits.
There are three ways to run a realtime video or world model in production: a managed platform that hosts it and bills per second, a rented GPU you operate yourself, or hardware you own. Choose a managed platform when you want to ship a product on realtime models without building the serving layer, rent GPUs when you need control and have steady heavy load, and own hardware when cost at scale or data control outweighs everything else.
Most teams start managed and move a stable, high-volume workload to dedicated capacity later. This page lays out why, and where the line sits.
What running a realtime model actually involves
A model that generates video as you steer it is more than a checkpoint on a GPU. Production needs:
- A runtime image with pinned code and dependencies, restorable weights and a health check.
- A streaming transport that gets frames to a browser or app (WebRTC, WebSocket) and handles loss and reconnects.
- Session state: one user, one held GPU, a lifecycle from queued to ready to released.
- A control channel that takes prompts, images, movement or camera input while the model runs.
- Placement: finding a GPU, bringing capacity up when it is needed, and replacing a worker that fails.
- Metering and limits: knowing who used what, and capping the worst case.
- Observability from the client, because server logs show frames sent, not frames seen.
The model is one box in that list. The other boxes are where most of the engineering goes.
The three approaches compared
| Managed platform | Rented GPU | Hardware you own | |
|---|---|---|---|
| Time to a first session | As soon as access is granted | Days to weeks to build the serving layer | Weeks to months, including procurement |
| What you build | Your product | Runtime, transport, sessions, scheduling, metering | Everything in the rented case, plus the hardware lifecycle |
| Cost shape | Per ready second; zero when nobody is using it | Per hour per GPU, whether or not it is used | Capital cost plus power, space and staff |
| Spiky or unpredictable traffic | Handled by the platform's capacity | You provision for peak or accept queueing | You provision for peak |
| Control of model and runtime | The platform's runtime, within the model's controls | Full | Full |
| Data and compliance | Sessions run on the platform's workers | Your cloud account | Your premises |
| Operational burden | Low | High | Highest |
| Best fit | Products in early or growth stages, demos, variable load | Teams with infrastructure staff and steady load | Large stable workloads, air-gapped or regulated use |
Where the break-even sits
The comparison that matters is cost per useful hour.
- A managed platform costs rate × seconds used. On Windflow that is $6.12 for an hour of Helios or $8.64 for an hour of LingBot-World 2.0, only while the session is ready.
- A rented GPU costs hourly price × GPUs needed ÷ utilisation. Utilisation is the share of the hour the GPU is actually serving a session. A model that needs several GPUs and is used for a few hours a day pays for the idle hours.
Per-second billing wins while utilisation is low or unpredictable. Dedicated capacity can win once one model is busy around the clock, which is why Windflow scopes steady, high-volume use separately as reserved scale. Add the cost of the people who run the serving layer before concluding that renting is cheaper.
Decision guide
- You are validating a product or demo: managed. You pay only for sessions you run and learn what users do before committing to infrastructure.
- Traffic is spiky, seasonal or tied to events: managed. Idle time is free.
- One model runs flat-out all day, and you have infrastructure engineers: rented GPUs, or reserved capacity from a platform.
- You must keep video and prompts inside your own network: your own hardware or a private deployment.
- You have your own model: consider bringing it to a platform so it gets the serving layer without you building one.
A hybrid is normal
The common path is managed first and dedicated later: prove demand per second, then move the stable core of the load to capacity you control, keeping the managed route for spikes and experiments. Because Windflow gives every model the same session protocol, moving between models or capacity types changes the controls you send, not how you integrate.
FAQ
What is the cheapest way to run realtime AI video models without managing GPUs?
A managed platform that bills per ready second, because you pay nothing while a session is queued or starting, and nothing for GPUs you are not using. On Windflow the lowest rate is $0.0017 per second. For round-the-clock load on one model, compare it against dedicated capacity.
Is renting a GPU cheaper than a managed platform?
Only when the GPU is kept busy and you count the engineering time to build and run the serving layer. Rented GPUs bill every hour; managed sessions bill ready seconds.
How much engineering does self-hosting a realtime model take?
Enough to build and operate a runtime, a streaming transport, session handling, scheduling, metering and client-side measurement. Teams typically find the serving layer takes longer than getting the model to run.
Can I move from a managed platform to my own infrastructure later?
Yes. Keep your integration at the session level, and the controls you send stay the same whichever capacity serves the model.
Where does Windflow fit?
Windflow is the managed option: a catalog of ten hosted realtime video and world models on NVIDIA and AMD GPUs, one session API, per-second billing, and a route for model authors to bring a model. See pricing and the model catalog.