The assumption baked into most AI avatar platforms is that you have a reliable, fast connection and a cloud billing account to absorb the cost. The server renders the avatar as a video stream, you receive it, the user sees it. Clean in theory, fragile in practice.
The problem starts the moment you leave the ideal scenario: shared WiFi at a retail location, cellular signal in a warehouse, a kiosk device that costs $80 wholesale. Traditional cloud-rendered avatar video requires 1–2 MB/s of sustained bandwidth per session. On constrained networks and budget hardware, that’s where the experience breaks down.
Spatius takes a different approach. Rather than rendering video on the cloud and streaming it, Spatius Motion Server generates Motion data. Motion data streams to the client at just 10–15 KB/s. The client device renders the 3DGS avatar locally using its own GPU. No video stream. No heavy decoding pipeline.
This architecture shift — from streaming rendered video to streaming Motion data — is what makes Spatius run stably on entry-level chipsets.
Why Entry-Level Hardware Can Handle This
The GPU workload of rendering a real-time AI avatar in Spatius is fundamentally different from what people assume. There’s no heavy ML inference happening on-device. Spatius Motion Server runs in the cloud and generates Motion data. The client SDK — called AvatarKit — receives Motion data and uses it to animate a 3DGS (3D Gaussian Splatting) avatar model that lives on the device.
Rendering a 3DGS avatar is the GPU task. Asset size, frame rate, and required GPU capability depend on the generated Avatar and target device; benchmark representative hardware rather than assuming a universal profile.
Spatius can be evaluated on entry-level chipsets without a dedicated GPU, but the published docs do not define a universal frame-rate guarantee or a fixed chipset matrix. Benchmark the G88, S565, 8189, RK3576, or other target hardware with the avatar and graphics path you plan to ship.
What “Entry-Level” Means in This Context
The reference hardware Spatius targets includes:
Embedded / kiosk SoCs — Chips like the RK3576 are common in commercial Android kiosk hardware and can be useful test targets. Validate AvatarKit’s rendering pipeline, frame rate, memory, and thermal behavior under sustained sessions.
Budget Android and IoT devices — Chipsets like the G88 and S565 represent the class of hardware found in the $100–$200 Android device range globally. These run AvatarKit across Web, iOS, and Android SDKs.
Web deployments on aging hardware — Because the Web SDK uses WebGL / WebGPU (available in all modern browsers), even older desktop and laptop hardware running Chrome or Safari can render the avatar locally without a dedicated GPU.
The key enabler across all of these: zero on-device inference. AvatarKit only does rendering and audio alignment. The cloud side generates lightweight Motion data, not video.
The Bandwidth Equation
Traditional cloud-rendered avatar platforms stream video. A session at standard quality needs 1–2 MB/s, continuously. Across 20 simultaneous kiosks, that’s 20–40 MB/s of committed bandwidth for avatar video alone.
Spatius streams Motion data: 10–15 KB/s per session. Twenty kiosks need roughly 200–400 KB/s total. That’s negligible on any business internet connection, stable on 4G cellular, and viable even on degraded network conditions.
This isn’t a configuration trade-off — it’s an architectural property. The compression ratio comes from streaming compact Motion data instead of encoded video frames.
How the Architecture Fits Together
Spatius follows a three-layer separation:
-
AI Agent (customer-built) — You build and own the full voice AI stack: ASR (speech-to-text), LLM (language model), and TTS (text-to-speech). Spatius does not provide these components.
-
Avatar (Spatius) — The 3DGS digital human model, built from a single photo; generation time and asset size depend on the avatar and workflow.
-
AvatarKit SDK (Spatius core product) — The rendering engine that lives on the client device, receives Motion data from Spatius Motion Server, and renders the avatar in sync with the audio.
The data flow:
[Your TTS audio] → Spatius Motion Server → Motion data (10–15 KB/s)
↓
AvatarKit (client SDK)
renders 3DGS avatar locally
The cloud side in this pipeline generates lightweight Motion data — not video encoding. The rendering cost is dramatically reduced compared to full cloud rendering, though not eliminated entirely. The client does the visual rendering at zero inference cost.
SDK Integration
AvatarKit ships for three platforms:
| Platform | Distribution | Rendering Engine |
|---|---|---|
| Web | npm: @spatius/avatarkit | WebGL / WebGPU |
| iOS | AvatarKit.xcframework | Metal |
| Android | Gradle: ai.spatius:avatarkit | Vulkan |
Three integration modes are available depending on your latency and infrastructure requirements:
- Direct Mode — Lowest development effort, suitable for Web/iOS/Android, moderate latency
- LiveKit Plugin — Ultra-low latency, Web only, for teams already using LiveKit Agents
- Backend Mode — Ultra-low latency, full transport control, Web/iOS/Android
Note: iOS testing requires a physical device — the iOS simulator does not support Metal rendering.
Full code samples for Web, iOS, Android, and Flutter are available in the Voice Agent Demo repository.
Fallback Behavior
If the WebSocket connection to Spatius Motion Server fails within 15 seconds, AvatarKit automatically switches to audio-only fallback mode. The TTS audio continues uninterrupted; only the avatar animation pauses. This ensures the user experience degrades gracefully on flaky networks rather than breaking entirely.
Getting Started
The Spatius playground runs AvatarKit in your browser. The avatar rendering happens on your device using WebGL/WebGPU — no video stream. You can verify this in your browser’s network tab: you’ll see Motion data, not a video stream at 1–2 MB/s.
For device-specific testing, the demo repositories include iOS, Android, and Flutter clients ready to run on physical hardware.
From the Spatius team:
“replacing heavy cloud rendering with a lightweight stream and rendering on edge”
Related Reading
Go deeper on architecture → On-Device AI Avatar vs Cloud Streaming: Architecture, Bandwidth, and Cost
See it in a real deployment context → AI Avatars for Edge Deployments: Kiosks, Retail, and Low-Bandwidth Environments
Test before you commit → Avatar SDK Demo: How to Test a Real-Time AI Avatar Before You Commit to a Platform
The full landscape → Interactive Avatar: The Complete Guide to Real-Time AI Avatars in 2026