On-device rendering
The cloud produces motion or control data. A client SDK loads avatar assets and renders the result locally. Spatius uses this division through Motion Server and AvatarKit.
Architecture comparison
On-device vs cloud-streamed AI avatars
On-device rendering is usually the better fit when a product can run an avatar renderer on the client and wants to move lightweight motion data instead of video. Cloud streaming is often easier when the client should only decode media and the vendor or backend will operate the rendering infrastructure.
Verified Aug 3, 2026Decision-ready guidePrimary sources
Decision matrix
Compare the complete path.
Do not compare isolated numbers unless the definitions, inputs, environment, and included services match.
| Decision area | On-device rendering | Cloud-streamed rendering |
|---|---|---|
| Network payload | Motion or control data | Rendered video stream |
| Client responsibility | Load assets and render the avatar | Decode and display media |
| Cloud responsibility | Driving inference and session services | Inference, rendering, encoding, and delivery |
| Published Spatius framing | 10–20 KB/s / around 100 kbps | Cloud avatar services commonly require a larger media stream |
| Cost driver | Motion service plus client compute | Cloud GPU, encoding, and media delivery |
| Recovery focus | Asset state, motion buffering, client lifecycle | RTC state, video decoder, server session |
| Best fit | Owned application with supported client runtime | Thin clients and centrally managed rendering |
How it works
Two different operating models.
Architecture decides which team owns rendering, transport, recovery, and the surrounding AI product.
Cloud-streamed rendering
The server renders final frames and sends a video stream to the client. Client work is simpler, while GPU compute, media delivery, and connection quality become server-side concerns.
Best fit
Choose for the system you can operate.
The best option is the one whose responsibilities match your product, client, network, and team.
Choose On-device rendering when…
- Bandwidth-sensitive sessions
- High session volume
- Products that own the client experience
- Need a composable AI stack
Choose Cloud-streamed rendering when…
- Clients cannot render the avatar
- Central visual consistency is essential
- Managed media pipeline is preferred
- Server-side GPU cost is acceptable
Limitations and unknowns
Neither architecture is universally faster or more reliable. The result depends on model inference, voice pipeline, encoder settings, client hardware, network quality, buffering, and recovery policy.
Build a controlled evaluation.
Use one workload and record both user experience and operational responsibility.
1. Evaluation stepMeasure full-session network traffic, not a single packet.
2. Evaluation stepRecord client CPU/GPU and memory alongside cloud compute.
3. Evaluation stepIntroduce packet loss and reconnect events.
4. Evaluation stepUse the same speech audio and visual-quality rubric.
- Define the user job and acceptable fallback.
- Use the same input, session duration, and client.
- Record latency, traffic, compute, errors, and recovery.
- Compare total operating cost, not only list price.
Evidence
Sources and freshness.
Last verified Aug 3, 2026. Recheck implementation details when SDKs or plan terms change.
Related decisions