Why choose uRun
Real-time GPU Sessions for interactive AI with zero infrastructure configuration
Most GPU platforms are built around inference endpoints with a request/response pattern where you POST inputs, wait while the platform allocates a worker and runs your function, then get outputs back. While per-request routing across a shared fleet is the right shape for batch jobs and async generation, that model is a poor fit for anything interactive where every prompt change, utterance, and frame pays the cost of a fresh round-trip, and state can drift as the model reloads or re-queues between calls.
uRun's Session primitive is different and provides a stateful loop. A Session is a single low-latency connection to a GPU that stays warm for the life of the connection, carries bidirectional media over QUIC/WebTransport (with WebRTC fallback), and is steered live through a CRDT-synced control document. This architecture enables interactive AI that feels alive instead of feeling like a loading spinner.
How uRun works
Here is how data flows when you start a uRun Session from the browser:
A frontend built with the TypeScript SDK references an App. This can be a templated App created as part of serving a model from the catalog or a custom App built with the Python SDK. The frontend invokes a function that opens a Session. The Session continuously exchanges media streams and a control document between a warm GPU and the browser. There is no polling or re-queuing.
GPU platform comparison
Here's a comparison of the typical request/response inference endpoints available on most GPU platforms versus uRun's Session primitive:
| Typical inference endpoint | uRun Session | |
|---|---|---|
| Steering mid-run | Not possible — you call again | Live, via a CRDT-synced control document |
| Connection | One round-trip per call | One persistent connection (QUIC/WebTransport, WebRTC fallback) |
| Model state | Re-loaded / re-queued per request (unless you pin) | Stays warm and resident for the whole Session |
| Data flow | Sequential: input in, then output out | Continuous bidirectional media streams |
Edge/SSR platform comparison
Edge and SSR platforms like Netlify or Vercel are built to serve web frontends close to the user. They don't provide GPUs for AI inference.
These platforms are complementary to uRun. After creating a templated or custom App on uRun, you can develop a frontend with uRun's TypeScript SDK that references your App and host the frontend on any edge/SSR platform. Then, when someone visits your site, their interactions can open a uRun Session from the browser for real-time AI workloads. uRun hosts the GPU Session while your edge/SSR platform hosts the webpage.
When to use which platform
Most batch jobs and async generation can be sufficiently handled through inference endpoints with a request/response cycle. But that architecture won't suffice for interactive or real-time workloads.
Choose uRun Sessions for workloads like the following:
- A person watches and steers video output while it's being generated.
- You need media in and media out on the same connection, such as a webcam or mic.
- You're rendering something continuously such as a live canvas, an avatar, or an interactive world.
The scale-to-zero economics of Sessions mean uRun is also well suited to use cases where the model is time-consuming to load, and you want it to stay warm across many interactions.
You can host a frontend for your uRun App on any edge or SSR platform.