AWS 發布工具：用實測數據設定 SageMaker TTS 自動縮放

背景

Amazon SageMaker AI 是 AWS 提供的機器學習平台，允許開發者部署模型並透過端點（Endpoint）提供服務。在部署文字轉語音（TTS, Text-to-Speech）模型時，自動縮放（Auto Scaling）機制會根據負載調整 GPU 實例數量。然而，TTS 請求通常持續數秒且非自回歸生成，傳統基於 Token 生成速率的指標不適用，若目標值設定過於保守，GPU 實例將大部分時間閒置；若設定過於激進，則可能在真實流量高峰時導致排隊時間超過 SLO。 AWS ML Blog

發生什麼事

AWS 於 2026 年 10 月 22 日發布部落格文章，並提供名為 sample-kokoro-tts-for-ai-agents 的 GitHub 儲存庫。該專案部署 Kokoro-82M（一個 82-million-parameter TTS 模型）至 Amazon SageMaker AI 即時端點，並提供一套基準測試工具，透過測量實際端點的行為來推導自動縮放配置。 AWS ML Blog 官方原文・github.com

重點內容

該工具鏈包含 tts-bench 套件，用於測量兩個關鍵指標：Q_max（單一實例在違反 SLO 前能持續維持的最高並發數）與 T_total（一次擴容從開始到結束所需的時間）。系統利用這兩個數值，透過算術推導出擴容閾值、縮容閾值及冷卻時間。部署流程使用 AWS CDK（AWS Cloud Development Kit，用於定義基礎設施的程式碼框架）建立三個堆疊：SpeechFoundationStack 建立 IAM 角色與 S3 儲存桶，SpeechModelCacheStack 同步模型權重，SpeechEndpointStack 建置容器並部署端點。 AWS ML Blog 官方原文・github.com

自動縮放策略採用 Amazon SageMaker AI 原生發布的 ConcurrentRequestsPerModel 指標，而非自訂指標。該指標在 10 秒窗口內發布最大值統計數據。工具會測量客戶端測得的並發數與 CloudWatch 報告值的比率，並據此轉換閾值。在 Kokoro-82M 的測試中，該比率在所有層級均為 1.0，因此客戶端測得值可直接用於配置。容器支援兩種傳輸方式：InvokeEndpointWithResponseStream（串流回應，邊合成邊播放）與 InvokeEndpointWithBidirectionalStream（雙向串流，維持長連接處理多條訊息）。 AWS ML Blog

對使用者的意義

開發者可使用此工具鏈為部署在 Amazon SageMaker AI 上的 TTS 模型設定基於實測數據的自動縮放策略。這有助於避免因猜測錯誤導致的 GPU 閒置成本或延遲超標風險。使用者需具備 AWS 帳號權限、AWS CDK v2、Python 3.11 以上版本、uv、Docker，以及 ml.g5.xlarge 服務配額。透過執行提供的 CLI 指令，可自動完成部署與測量流程，生成可部署的縮放配置。 AWS ML Blog 官方原文・github.com

限制與未定事項

此解決方案被標記為「價值證明」（proof-of-value），並非生產就緒的實現。使用者需自行評估 AWS 共同責任模型並實施必要的安全控制。樣本容器固定使用 torch==2.6.0，該版本存在 PYSEC-2026-2286 記憶體損毀漏洞（torch 2.10.0 已修復），若分叉此儲存庫並指向不同模型，需評估升級 torch 或採取其他緩解措施。 官方原文・github.com AWS ML Blog