ElatoAI：把实时语音对话塞进一块不带 PSRAM 的 ESP32
Realtime Voice AI with 100+ Models on Arduino ESP32 with Secure Websockets and Edge Functions for AI Companions, and Devices
秒懂
- 它是什么？
- ElatoAI 用 TypeScript 写服务端、用 Arduino 框架写固件，让 ESP32 通过加密 WebSocket 接入 OpenAI Realtime、Gemini Live、Grok、ElevenLabs 等语音模型。它解决的是硬件玩具的联网对话链路，而不是通用语音中间件。
- 适合谁用？
- 如果你在做带麦克风和喇叭的 ESP32 实体玩具，并且需要把 OpenAI、Gemini、Grok、ElevenLabs 这类实时语音 API 接进来，ElatoAI 提供的固件加边缘函数组合值得先跑通一遍。如果你的产品是纯软件客户端，或者你需要的是可自托管的开源语音模型推理，这个仓库的默认路径并不合适，因为它的服务端依赖 Supabase 与 Deno Deploy 这类托管服务。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 14 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它填的是硬件到实时语音 API 之间那段空白
ESP32 能连 Wi-Fi，也能推流音频，但把麦克风采集的 PCM 送到 OpenAI Realtime API 并实时播回，中间缺的东西很多：TLS 握手、WebSocket 帧管理、音频编解码、断线重连、设备身份认证。ElatoAI 把这些打包成一个 Arduino 固件加一组服务端函数。README 把目标写得很直白，面向的是 AI 玩具和陪伴设备，配套还有 NextJS webapp 用来管理角色、设备和音量。它的用户画像不是做语音中间件的团队，而是手里已经有硬件原型、想尽快听到 AI 声音的人。仓库同时提供 PCB 设计图和 App 截图，说明作者是按完整产品链路来组织的，不是纯库。
三条服务端路径，选哪条决定了你的运维负担
仓库的 server 目录下并列了三种服务端形态。Deno Edge 目录按模型分文件，openai、gemini、grok、elevenlabs、hume 各一个入口，另有 boson.ts。这些走的是各家的实时语音到语音接口，服务端主要做协议转发和鉴权。Cloudflare Workers 路径则是另一套逻辑：STT、LLM、TTS 三段拼成流水线，README 说明 Deepgram 的 STT 与 TTS 由 Workers AI 原生提供，你只需要自备 LLM 的 API Key。FastAPI 路径面向 Pipecat，README 的说法是可以组合出 100 多种 STT、LLM、TTS 管线。三者的取舍很清楚：Deno 路径代码量最小但把延迟和可用性交给模型厂商；Workers 路径可控性更强，代价是你要自己调三段之间的衔接；FastAPI 路径最灵活，也最需要你自己维护进程。
音频走 Opus，轮次判定放在服务端
固件端不做语音活动检测，README 把 Server VAD Turn Detection 列为特性之一，意思是判断用户说完没有这件事由服务端完成。这个选择对 ESP32 是合理的，因为片上算力要留给 Opus 编解码。README 同时把 Opus Audio Compression 单列出来，说明带宽是设计时的重要约束。值得注意的是 No PSRAM Required 这一条：项目声称不需要外挂 PSRAM 就能跑语音到语音，这通常意味着音频缓冲被压得很小，或者采用了边收边播的策略。文档没有给出缓冲深度或丢帧处理的具体参数，如果你的网络抖动比作者测试环境更差，这里是最先出问题的地方。
配网、OTA 与按钮触控：固件侧的日常接口
README 列出的固件能力包括 captive portal 配网、OTA 更新、恢复出厂设置、按钮或触摸传感器控制。配网走热点门户是嵌入式项目的常见做法，用户用手机连上设备热点填 Wi-Fi 密码，省掉在设备上做屏幕的成本。OTA 的存在意味着固件可以远程迭代，但仓库没有说明签名校验或回滚机制，README 的 feature list 里只是把 Over the Air Updates 列为一条。恢复出厂设置由 NextJS webapp 触发，这条链路要经过 Supabase 和设备认证，如果设备已经离线，这个按钮实际不会生效。
会话记录落在 Supabase，认证也绑在上面
实时转录文本存进 Supabase 数据库，用户认证和 OAuth 也由 Supabase 承担。这个设计让 webapp 端省掉大量后端代码，代价是数据层和身份层被绑定在一个托管服务上。对做玩具的团队来说，这不是问题，甚至省事。对需要在自有基础设施内保存对话数据的场景，这就成了硬约束，因为 README 没有提供替换 Supabase 的抽象层说明。设备注册与管理同样依赖这套体系，换句话说，脱离 Supabase 之后，设备认证和会话历史这两块功能都需要重写。
什么时候它不是你该用的东西
如果目标设备是手机或浏览器，ElatoAI 的固件层完全是多余的，你只需要看它的 webapp 部分，而 README 对 web 端 WebRTC 的描述只有一句话。如果项目要求语音模型跑在本地、数据不出内网，这个仓库的默认服务端路径会直接违反要求，因为 Deno Edge 和 Cloudflare Workers 都是托管平台。仓库的 News 里提到过一个独立的 local-ai-toys 项目做本地模型，但那是另一个仓库，不在本文讨论范围内。还有一种情况：如果你的硬件不是 ESP32 而是树莓派或 Linux 板卡，Arduino 框架的这套固件无法复用，你只能参考服务端的协议设计。
替代方案与真正的差异
Pipecat 是这个领域里更接近框架定位的选择，ElatoAI 的 FastAPI 服务端本身就是围绕它搭建的。差别在于 Pipecat 从服务端语音管线出发，硬件端要你自己接；ElatoAI 从 ESP32 固件出发，服务端是配套。如果你已经有一套自研的语音管线，引入 ElatoAI 只会增加一层你不需要的抽象。反过来，如果你手上是裸的 ESP32 加麦克风，从 Pipecat 起步意味着你要先解决 TLS、Opus 和配网，这些正是 ElatoAI 已经写好的部分。选哪个取决于你缺的是服务端编排还是设备端连接。
许可与维护成本：动手前必须自己确认的部分
仓库的 License 字段显示为 NOASSERTION，这意味着 GitHub 无法自动识别出一个标准许可证。README 正文里没有出现许可证名称，也没有在显著位置说明商用条款。这不是可以靠推测填补的信息，需要直接打开仓库根目录的 LICENSE 文件阅读原文，必要时咨询法律意见，本文不提供法律判断。维护成本方面，项目最后推送时间在 2026 年 9 月，News 段落记录了 2026 年 3 月到 4 月的多次功能更新，说明仍在活跃开发。但这种活跃也意味着接口可能变动：服务端按模型分文件的结构，在新增模型时容易调整目录。升级前建议对照 docs 里的部署文档，确认 Deno 函数与固件版本的对应关系，固件和服务端不同步是这类项目最常见的故障来源。
编辑结论
如果你在做带麦克风和喇叭的 ESP32 实体玩具，并且需要把 OpenAI、Gemini、Grok、ElevenLabs 这类实时语音 API 接进来，ElatoAI 提供的固件加边缘函数组合值得先跑通一遍。如果你的产品是纯软件客户端，或者你需要的是可自托管的开源语音模型推理，这个仓库的默认路径并不合适，因为它的服务端依赖 Supabase 与 Deno Deploy 这类托管服务。动手之前先确认三件事：仓库的 LICENSE 文件里到底写了什么条款，Supabase 表结构与 Deno 函数的部署步骤在 docs 里是否完整，以及你的硬件是否与 assets/pcb-design.png 中的电路一致。
社区笔记