桌面机器人语音交互选型：端侧离线唤醒 vs 云端全双工流式，延迟、成本与打断体验的实测权衡

最近在给桌面小机器人改语音交互链路，反复对比了传统「端侧离线唤醒（KWS）+ 分段请求」和现在的「云端全双工流式（Full-duplex）」方案，发现工程落地上取舍挺撕裂的。

聊聊我这边实测的两个极端：

1. 端侧唤醒词（ESP-SR / sherpa-onnx）+ 分段 ASR/LLM/TTS 硬件要求极低，ESP32-S3 或者几十块钱的 Linux 算力棒就能跑。平时不耗云端资源，也没有隐私顾虑。 缺点是机械感太重，永远是「唤醒 - 哔一声 - 说话 - 傻等 1.5 秒 - 机械播报」，一旦打断就得硬掐音频流，几乎没有「陪伴」该有的松弛感。

2. 云端全双工流式交互（WebRTC / WebSocket + VAD 打断 + 端到端语音模型） 体验确实惊艳，插话打断（Barge-in）、语气词停顿都很自然，特别像真人在桌边跟你唠嗑。 但工程代价很现实：桌宠机器人是要全天待机的，如果全时段挂音频流，按分钟计费的 Token 和带宽直接起飞；小主控跑双向音频流容易受 Wi-Fi 抖动影响，一旦丟包重传，动作舵机和表情同步就容易直接卡死。

我现在折中的方案是：端侧超低功耗 KWS 唤醒 -> 开启一个 30 秒的本地双工 Session（端侧跑轻量 Silero-VAD 做打断检测）-> 超时自动降级回休眠。

想问问在做桌面伴侣、机械宠物的朋友，你们目前量产或 DIY 原型机里用的是哪套架构？长连接推流的成本和随时随地插话的自然感，大家是怎么做权衡的？有没有踩过 AEC（回声消除）没做好导致机器人自己说话把自己打断的坑？