AWS 發布 Kokoro TTS 串流方案，解決 AI 語音代理延遲問題

背景

Kokoro-82M 是一個文字轉語音（TTS, Text-to-Speech）模型，參數量為 82 million parameters，可運行在單一中型 GPU 實例上以控制成本與延遲。來源指出，文字轉語音整合會產生延遲落差：一句話的回應可能只需 600 毫秒生成，但完整回應需要五秒，且整合方式會等待所有內容生成完畢後才開始合成。此方案旨在透過串流技術縮短這段等待時間。 AWS ML Blog

發生什麼事

AWS 於 2026 年 10 月 22 日發布技術文章，展示如何在 Amazon SageMaker AI 上部署 Kokoro-82M 模型，並結合 Amazon Bedrock AgentCore 運行 AI 代理。該方案使用雙向串流機制，讓代理每生成一句話就立即發送給 TTS 模型進行合成，而非等待完整回應。 AWS ML Blog

重點內容

部署環境使用 ml.g5.xlarge GPU 實例，容器提供兩個路由：POST /invocations 用於單次請求，WS /invocations-bidirectional-stream 用於維持雙向連線。測試顯示，三句輸入的語音合成時間分別為 1.525 秒、2.250 秒和 2.050 秒，對應音訊大小為 73,200、108,000 和 98,400 位元組。此方式並非並行合成，而是嚴格依序處理：接收訊息、合成音訊、發送音訊、發送完成訊號，再接收下一則訊息。 AWS ML Blog

開發者需注意 WebSocket 框架的處理方式，SageMaker AI 傳送的是二進位 WebSocket 幀，若使用 Starlette 的 receive_text() 會因缺少 text 欄位而失敗。正確做法是明確接受二進位幀並解碼為 UTF-8。此外，應保持會話開啟以連續處理多句訊息，僅在客戶端發送 {"type": "close"} 時關閉連線，避免每句都重新建立連線造成延遲。 AWS ML Blog

對使用者的意義

此方案主要面向開發者，用於建構低延遲的語音代理應用。開發者需具備 AWS 帳號權限、Python 3.12 或更高版本、uv、Docker 以及 AWS CDK v2 環境。透過 GitHub 倉庫提供的 speech-infra CLI 工具部署端點，並使用 tts-client 套件從 Python 呼叫已部署的 TTS 端點。 AWS ML Blog 官方原文・github.com

限制與未定事項

官方明確指出此解決方案為價值證明（proof-of-value），並非生產就緒的實現。容器固定使用 torch==2.6.0，該版本存在 PYSEC-2026-2286 記憶體損毀漏洞，雖在 torch 2.10.0 中修復，但此倉庫尚未採用。若使用者分叉倉庫並指向不同模型，需自行評估升級 torch 或採取其他緩解措施。 官方原文・github.com AWS ML Blog