速度是 AI 数字人营销中最常被声称、也最少被精确定义的指标。每个平台都会宣传低延迟，但很少有平台说明延迟来自哪里，更少有数字能在真实网络条件下成立。
下面是一种更有用的比较方式：在实时 AI 数字人语境中，“速度”到底意味着什么，架构决定了什么，以及评估平台时真正应该测量什么。
The Two Architectures and Their Speed Profiles
Cloud Streaming Platforms
HeyGen LiveAvatar、Tavus、Anam.ai 这类平台在云端服务器上渲染数字人，并把结果作为实时视频流发送给客户端。完整管线，包括 ASR、LLM、TTS、数字人动画、帧渲染、视频编码，都在服务端运行。客户端只解码并显示视频流。
延迟特征： 传统云端渲染数字人管线的端到端延迟通常大于 3 秒。这是音频上传、语音识别、语言模型推理、文本转语音、数字人动画、帧渲染、视频编码、流传输和客户端解码的累积成本。这些步骤大多串行发生，每一步都增加往返时间。
带宽要求： 标准质量视频流每路会话需要持续 1–2 MB/s。这是 30fps 数字人视频流在可用质量下的视频编码物理约束，不是软目标。低于这个带宽阈值，会话会出现可见质量下降或卡顿。
网络压力下： 当可用带宽低于视频流下限，编码器会降低画质以保持帧率，或丢帧以保持画质。两种结果用户都能立刻看到。WebRTC 有拥塞控制，但没有真正优雅的降级模式。一旦带宽低于最低可用值，体验就会破坏。
Spatius: On-Device Rendering
Spatius 将渲染从云端推理步骤中拆出来。云端 GPU 只运行轻量 driving model：接收 TTS 音频并输出 FLAME 表情参数，也就是描述数字人面部如何运动的紧凑数据。这些参数以 10–20 KB/s 传给客户端 AvatarKit。AvatarKit 在本地渲染 3DGS 数字人，并与音频同步。
延迟特征： 在 Spatius 侧，从音频输入到数字人交互增加的延迟低于 300ms。包括客户自建 ASR + LLM + TTS 栈在内，总端到端延迟低于 1.5 秒。优化过的端到端语音 AI 栈可以进一步达到亚秒级。相比传统云端渲染 3 秒以上的延迟，这是一种由架构产生的结构性优势，而不是单纯基础设施调优。
带宽要求： 每路会话需要 10–20 KB/s 的 FLAME 表情驱动数据，约比云端推流低 99%。官方文档将高端情况描述为约 100 kbps。
网络压力下： 10–20 KB/s 的要求可以在退化 4G、共享 WiFi 和波动移动连接上工作。短暂连接中断会延迟下一批 FLAME 参数，用户可能注意到数字人响应短暂停顿，但渲染本身继续进行，因为它运行在本地。如果 WebSocket 连接失败 15 秒，AvatarKit 会自动切换到 audio-only mode，TTS 音频继续，动画暂停。
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 秒和 1.5 秒在对话界面中是巨大的感知差距。人类自然对话响应延迟大约是 200–500ms。3 秒会让每次交流都像是在等待；低于 1.5 秒，尤其是在优化语音栈后达到亚秒级，交互会自然很多。
差异不在于服务器距离或基础设施优化，而在于架构本身需要什么。云端推流无法消除编码、传输和解码步骤。端侧渲染则把这些步骤从延迟路径中移除了。
What “Speed” Claims Miss
大多数公开“低延迟”数字都在最佳条件下测量：附近服务器区域、专用高速连接、低并发负载。真实部署很少完全符合这些条件。
速度最重要的时候，往往是条件最差的时候：
零售场所 中，几十台顾客设备共享 WiFi。10 路云端推流数字人会话需要 10–20 MB/s 带宽；10 路 Spatius 会话只需要约 100–200 KB/s。
运行在 4G 上的现场设备 中，信号波动。云端推流在约 1 MB/s 以下会崩坏；Spatius 在 20 KB/s 仍可用。
会议或活动部署 中，酒店或场馆 WiFi 通常共享且不可预测。视频流会卡顿和出现伪影，FLAME 参数流基本不受影响。
新兴市场用户 使用中端设备和移动数据。1–2 MB/s 视频推流会快速消耗流量，10–20 KB/s 则几乎可以忽略。
在这些条件下，架构差异不是边际优化，而是“产品能用”和“只在 demo 里能用”的区别。
How to Actually Compare Speed When Evaluating Platforms
在目标硬件上测试，而不是在你的工作站上测试。 如果要部署到 Android 平板或 kiosk 硬件，就在这些硬件上测试。
模拟真实网络条件。 使用浏览器 DevTools 网络限速。测试 Fast 3G（1.5 Mbps、40ms RTT）和波动 Slow 4G。云端推流数字人在这些级别会出现退化，端侧渲染不受影响。
用秒表测端到端延迟。 停止说话时开始计时，数字人声音开始时停止。平均 10 次。方差说明一致性，均值说明延迟下限。
观察 Network 面板。 对 Spatius 来说，你不应看到视频流，只会看到合计 10–20 KB/s 的小数据包。对云端推流平台，你会看到持续 1–2 MB/s 的 WebRTC 视频流。这是一个不需要基准测试工具就能识别的架构指纹。
Try It
Spatius playground 在浏览器中运行。与数字人对话，然后打开 DevTools → Network。观察带宽：10–20 KB/s 的参数数据，而不是 1–2 MB/s 的视频流。在 DevTools 中限速测试，数字人仍会继续运行。
如果要比较平台，在任何云端推流平台的 demo 上运行同样的 DevTools 网络检查。带宽数字会立刻可比。
Related Reading
架构解释 → On-Device AI Avatar vs Cloud Streaming: Architecture, Bandwidth, and Cost
硬件要求 → AI Avatar on Entry-Level Chipsets: How On-Device Rendering Works on Budget Hardware
提交平台前测试 → Avatar SDK Demo: How to Test a Real-Time AI Avatar Before You Commit to a Platform
完整平台格局 → Interactive Avatar: The Complete Guide to Real-Time AI Avatars in 2026