Speed is the metric most frequently claimed and least precisely defined in AI avatar marketing. Every platform advertises low latency. Few publish a breakdown of where that latency comes from, and almost none of the numbers hold under real-world network conditions.
This is an attempt at a more useful comparison: what “speed” actually means in a real-time AI avatar context, what the architecture determines, and what you should actually measure when evaluating platforms.
The Two Architectures and Their Speed Profiles
Cloud Streaming Platforms
Platforms like HeyGen LiveAvatar, Tavus, and Anam.ai render the avatar on a cloud server and deliver it to the client as a real-time video stream. The entire pipeline — ASR, LLM, TTS, avatar animation, frame rendering, video encoding — runs server-side. The client decodes and displays the stream.
Latency profile: Traditional cloud-rendered avatar pipelines deliver end-to-end latency greater than 3 seconds. This is the cumulative cost of audio upload, speech recognition, language model inference, text-to-speech synthesis, avatar animation, frame rendering, video encoding, stream delivery, and client decode — all sequential, all adding round-trip time.
Bandwidth requirement: A video stream at standard quality requires 1–2 MB/s sustained, per session. This is set by video codec physics at usable quality for a 30fps avatar stream. It’s not a soft target — sessions below this bandwidth threshold see visible quality degradation or stalling.
Under network stress: When available bandwidth drops below the video stream floor, the codec degrades quality to maintain frame rate, or drops frames to maintain quality. Either outcome is immediately visible. WebRTC has congestion control, but there’s no graceful degraded mode — once bandwidth falls below the minimum viable rate, the experience breaks.
Spatius: On-Device Rendering
Spatius separates the rendering from the cloud inference step. The cloud GPU runs only a lightweight driving model: it takes TTS audio as input and outputs FLAME expression parameters — compact data describing how the avatar’s face should move. These parameters stream to AvatarKit on the client at 10–20 KB/s. AvatarKit renders the 3DGS avatar locally in sync with the audio.
Latency profile: The audio input to avatar interaction adds less than 300ms on Spatius’s side. Total end-to-end latency — including the customer-built ASR + LLM + TTS stack — is under 1.5 seconds. With an optimized end-to-end voice AI stack, this can reach sub-second. Compared to traditional cloud rendering’s 3+ seconds, this is a structural latency advantage rooted in architecture, not infrastructure tuning.
Bandwidth requirement: 10–20 KB/s of FLAME expression driving data per session. This is approximately 99% less than cloud streaming. The official documentation describes the stream as “~100 kbps” at the high end.
Under network stress: The 10–20 KB/s requirement is viable on degraded 4G, shared WiFi, and variable mobile connections. A momentary connectivity disruption delays the next batch of FLAME parameters — the user may notice a brief pause in the avatar’s responsiveness — but the rendering itself continues uninterrupted because it runs locally. If the WebSocket connection fails for 15 seconds, AvatarKit falls back to audio-only mode automatically; the TTS audio continues while animation pauses.
Speed Comparison Table
| Metric | Cloud Streaming Platforms | Spatius (On-Device) |
|---|---|---|
| End-to-end latency | >3 seconds | <1.5 seconds |
| Avatar→audio additional latency | High (encode+stream+decode adds up) | <300ms |
| Bandwidth per session | 1–2 MB/s | 10–20 KB/s (~99% less) |
| Minimum viable bandwidth | ~1 MB/s (below = artifacts/stall) | ~20 KB/s (works on degraded 4G) |
| Performance on shared WiFi | Degrades as network load increases | Unaffected |
| Performance under congestion | Visible artifacts / stall | Brief pause in avatar response only |
| Connectivity fallback | Stream stops | Audio-only mode (automatic, 15s) |
| Cost per hour | ~$9/hr (at industry avg $0.15/min) | $0.42/hr (Scale plan) |
What the Latency Numbers Mean in Practice
3 seconds versus 1.5 seconds is a large perceptual gap in a conversational interface. Human conversation has natural response latency of roughly 200–500ms. At 3 seconds, every exchange feels like a noticeable wait. At under 1.5 seconds, and especially at sub-second with an optimized voice stack, the interaction feels substantially more natural.
The difference isn’t about server proximity or infrastructure optimization — it’s about what each architecture fundamentally requires. Cloud streaming cannot eliminate the encoding, transmission, and decoding steps. On-device rendering removes those steps entirely from the latency path.
What “Speed” Claims Miss
Most published “low latency” figures are measured under optimal conditions: nearby server region, dedicated fast connection, low concurrent load. Real deployments rarely match this.
Speed matters most when conditions are worst:
Retail locations with dozens of customer devices sharing WiFi. Ten simultaneous cloud-streaming avatar sessions need 10–20 MB/s of bandwidth. Ten Spatius sessions need roughly 100–200 KB/s.
Field devices on 4G with variable signal. Cloud streaming breaks at ~1 MB/s. Spatius is viable at 20 KB/s.
Conference or event deployments on shared hotel or venue WiFi. Video streams stall and artifact. FLAME parameter streams are unaffected.
Emerging market users on mid-range devices and mobile data. 1–2 MB/s of video streaming burns data plans. 10–20 KB/s is negligible.
Under these conditions, the gap between architectures isn’t marginal. It’s the difference between a working product and one that only works in demos.
How to Actually Compare Speed When Evaluating Platforms
Test on your target hardware, not your workstation. If you’re deploying to Android tablets or kiosk hardware, test on that hardware.
Simulate realistic network conditions. Use browser DevTools network throttling. Test at “Fast 3G” (1.5 Mbps, 40ms RTT) and “Slow 4G” (variable). Cloud-streaming avatars show degradation at these levels. On-device rendering is unaffected.
Measure end-to-end latency with a stopwatch. Stop speaking, start timing, stop when the avatar’s voice begins. Average 10 trials. The variance across trials tells you about consistency; the mean tells you about floor latency.
Watch the network tab. For Spatius, you should see no video stream — only small data packets totaling 10–20 KB/s. For cloud-streaming platforms, you’ll see a sustained WebRTC video flow at 1–2 MB/s. This is an immediate architectural fingerprint that doesn’t require any benchmarking tools.
Try It
Spatius’s playground runs in your browser. Talk to the avatar, then open DevTools → Network. Observe the bandwidth: 10–20 KB/s of parameter data, not a 1–2 MB/s video stream. Test under throttled network conditions in DevTools — the avatar keeps running.
For platform comparison, run the same DevTools network check against any cloud-streaming platform’s demo. The bandwidth numbers are immediately comparable.
Related Reading
Architecture explained → On-Device AI Avatar vs Cloud Streaming: Architecture, Bandwidth, and Cost
Hardware requirements → AI Avatar on Entry-Level Chipsets: How On-Device Rendering Works on Budget Hardware
Test before committing → 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