AI 語音代理嘅「等落」問題
用家問 AI 語音代理一個問題，代理已經有答案，但用户要等五秒先聽到嘢。一句簡單嘅回覆可能 600 毫秒就生成晒，但完整回應要五秒，傳統做法要等全部文字都寫完先開始語音合成，呢個「空窗」就係用户感受最差嘅位。
點解決：逐句 streaming
AWS Machine Learning Blog 2026 年 10 月 22 日刊文，講點樣將呢個空窗縮短：用家一問，代理每生成完一句，即時將嗰句 stream 去 hosted Kokoro-82M TTS（text-to-speech，文字轉語音）模型，合成由第一句開始，唔使等完整回覆寫完。音頻再傳返 browser 又有另外嘅方法，文內涵蓋兩種 transport 同實際成本。
Kokoro-82M 只有 8200 萬參數，細到可以在單個 mid-tier GPU 實例上運行，延遲同推理成本都壓住。模型部署喺 SageMaker AI real-time endpoint，GPU 型號係 ml.g5.xlarge。
技術細節
容器暴露兩個 route：
POST /invocations：對一個完整輸入 stream 回應WS /invocations-bidirectional-stream：喺同一條連接上雙向、跨多條訊息保持開著
部署條件同安全提醒
文內列出部署需要嘅 IAM 權限、ECR repository、AWS CDK v2、Python 3.12+ 等。值得留意：範例容器固定咗舊版 PyTorch，有已知安全通告（PYSEC-2026-2286，torch 2.10.0 已修復），文內提醒用家喺正式使用之前要更新。
文內亦有 GitHub 代碼庫連結同完整 walkthrough，包括 endpoint 同 agent runtime 嘅部署。
阿調搞兩下
呢個做法核心唔複雜：唔好等全部分生成完先動，逐句就逐句處理。但值得留意，Kokoro-82M 82M 參數嘅小型 TTS 模型，喺語音品質方面未必趕得上更大嘅商業模型。做語音代理嘅產品團隊要掂埋質量同延遲嘅 trade-off，唔好只盯住快就夠。
阿調｜深度調教
