ElatoAI：把語音對話塞進 ESP32 的三種後端路線

ESP32 想做語音對話，卡住的是協定而不是模型

ESP32 的資源限制讓它無法在本機跑語音模型，所以做法一定是把音訊往外送。問題在於送出去之後要接什麼。多數語音 API 提供的是 HTTP 端點或瀏覽器用的 WebRTC，兩者對 MCU 都不友善：HTTP 需要反覆建立連線，WebRTC 的實作對記憶體與堆疊要求偏高。ElatoAI 的切入點是把這件事收斂成一條 WebSocket，讓裝置端只需要處理 Opus 壓縮音訊的收送。README 的 feature list 明白寫著裝置端走 WebSocket，而 NextJS webapp 走 WebRTC，兩條路徑共用同一套後端模型。目標讀者是做硬體產品或玩具的人：README 連到一個 Kickstarter 專案，首頁的敘述就是讓玩具用 AI 聲音說話。這也解釋了為什麼 feature list 裡會出現音量控制、出廠重置、captive portal 這類跟語音模型無關，但跟實體產品有關的項目。

三條後端路線，差別在誰幫你管模型與連線

專案沒有單一伺服器，而是三套並行的實作，各自對應不同的取捨。Deno Edge 路線直接串接供應商的 speech-to-speech API，README 列出六個已實作的模型目錄：openai、gemini、grok、elevenlabs、hume，以及單一檔案的 boson.ts。這條路線的延遲取決於供應商，你拿到的就是該供應商原始的行為。Cloudflare Workers 路線則反過來，把 STT、LLM、TTS 拆成三段，由 Workers AI 提供 Deepgram 的 STT 與 TTS，你只需要自備 LLM 的 API key。這是 pipeline 而非 speech-to-speech，中間多了一層文字轉換，換來的是可以自由替換其中一段。FastAPI 路線走的是 Pipecat，README 的 2026 年 4 月 15 日公告說可以啟動超過 100 種 STT、LLM、TTS 的組合。三條路線的差異不在功能多寡，而在故障時你要去哪裡找問題：Deno 路線出錯要找供應商，Cloudflare 路線出錯要判斷是 STT、LLM 還是 TTS 這一段，FastAPI 路線則是自己維護整條鏈。

音訊怎麼走：從 I2S 到 WebSocket 到模型再回來

README 沒有提供完整的時序圖，但從 feature list 可以拼出資料流。裝置端用 Opus 壓縮音訊，透過加密 WebSocket 送到伺服器；伺服器把音訊交給選定的模型，模型回傳語音與逐字稿。伺服器端的 VAD 負責判斷使用者是否講完，文件稱之為 server VAD turn detection，意思是輪次切換的判斷不在裝置上，而在伺服器。這一點對硬體設計有實際影響：裝置不需要跑語音活動偵測，運算負擔因此下降，README 也明確寫著不需要 PSRAM。代價是每一輪對話都得等伺服器判斷，網路品質直接反映在對話節奏上。逐字稿與對話歷史寫入 Supabase，webapp 再從那裡讀取。裝置管理與使用者驗證同樣走 Supabase，webapp 端另外支援 OAuth。架構上，Supabase 是狀態的集中點，WebSocket 伺服器是無狀態的轉接層，這個切分讓多裝置部署變得可行，README 也有一篇專門講多裝置部署的文件。

動手部署：PlatformIO、Arduino IDE 與 Deno 伺服器

硬體端的建置有兩條官方路徑，README 分別連到 PlatformIO 與 Arduino IDE 的文件頁，兩者都指向同一個 ESP32 Arduino Framework 實作。專案同時提供 OTA 更新與 captive portal 的 WiFi 設定，代表裝置出貨後不需要拆機就能換韌體與換網路。伺服器端以 Deno 為主，模型目錄位於 server/deno/models/ 之下，每個供應商一個子目錄。實際的環境變數名稱與部署指令，README 本身沒有列出，只連到 elatoai.com/docs 的 quickstart 與 deploying-globally 兩頁，所以任何具體的 key 名稱都必須回到官方文件確認，不能從 repository 首頁推測。Cloudflare Workers 路線的關鍵在於自備 LLM API key，STT 與 TTS 由 Workers AI 內建提供，這降低了要申請的帳號數量。FastAPI 路線的入口在 server/fastapi，README 建議直接看該目錄的說明。三條路線的共同前置條件是 Supabase，因為逐字稿、裝置註冊與使用者驗證都依賴它。

授權狀態未定與其他必須先確認的事

最需要留意的是授權。GitHub 把這個專案的授權標示為 NOASSERTION，意思是無法從既有資料判定它適用哪一種條款。repository 根目錄的 LICENSE 檔案內容必須自己打開確認，這在打算商業出貨硬體時不是小事：條款會決定你能不能修改、能不能閉源、要不要揭露衍生作品。其次是語言支援範圍。README 的模型清單以供應商為主，沒有提到中文語音或中文辨識的實測結果，而不同供應商對中文的支援落差很大，這部分只能自己用目標語言試。第三是專案沒有檢索到任何 release，最新推送時間為 2026 年 9 月 2 日，代表它是以 main 分支持續推進的狀態，沒有版本標籤可以鎖定。想要可重現的建置，就得自己記錄 commit。最後，README 提到超過 20 分鐘不中斷的對話，但沒有說明連線中斷後的重連行為與音訊緩衝策略，這在實際產品中是使用者最先感受到的問題。

跟 Pipecat 直接拿來用差在哪裡

FastAPI 路線本身就是建在 Pipecat 之上，所以真正的替代方案不是另一個框架，而是直接用 Pipecat 加上自己的 ESP32 韌體。差別在於 ElatoAI 已經幫你決定了幾件事：裝置端用 WebSocket 而非 WebRTC、音訊用 Opus、輪次判斷放在伺服器、狀態存 Supabase、裝置認證與 OTA 都做進去了。自己組的話，這些每一個都是獨立的決策點，彈性更大但工作量也更大。反過來說，如果你要接的模型不在 ElatoAI 已實作的清單裡，Deno 路線就得自己新增一個目錄，而 FastAPI 路線因為走 Pipecat，反而比較容易換模型。另一個方向是 Cloudflare 的 Voice Agents 與 Durable Objects，README 的 2026 年 4 月 17 日公告提到可以用它建立跨裝置的網路，這條路線的價值在於連線狀態由 Durable Objects 管理，適合需要多台裝置互相協調的場景，而不只是單機對話。

誰該用，誰該等

如果你手上已經有 ESP32 的硬體原型，目標是做一個能講話的裝置，而且團隊裡有人能處理 Deno 或 FastAPI 的部署，ElatoAI 省下的是裝置端與伺服器端之間那層協定的設計工作，這部分自己刻通常會踩到音訊格式與輪次判斷的坑。如果你需要的是純軟體的語音代理，不需要實體裝置，這個專案多出來的硬體整合對你沒有價值，直接用供應商的 API 或 Pipecat 更直接。如果你要的是託管服務，這個專案不是，Supabase、Deno 與模型供應商的帳號都得自己申請與付費，README 也沒有提到任何代管方案。最後一個判斷點是中文：在確認所選供應商的語音辨識與合成對中文的實際表現之前，不要把它排進產品時程。

編輯結論

ElatoAI 適合已經有 ESP32 硬體、想把語音對話接上雲端模型，且願意自己處理 Supabase 與 Deno 部署的人；不適合想要現成託管服務、或不打算碰伺服器端程式碼的團隊。動手前先確認三件事：repository 根目錄的 LICENSE 條款（GitHub 標示為 NOASSERTION，無法從既有資料判定授權範圍）、Deno 伺服器實際需要的環境變數清單，以及你選定的模型供應商是否支援你要的語言。這三項都會直接決定你能不能把裝置交到別人手上。

官方來源

1. akdeb/ElatoAI on GitHub
2. Issues
3. Project website
4. README