將自研 TTS 模型部署喺 Amazon SageMaker AI 嘅 realtime endpoint 上面，最頭痛嘅問題往往唔係模型本身，而係後面嗰套 auto scaling policy：目標數值估錯，貴嘅時侯係 GPU 長期空轉、帳單照開但無警報；激嘅時侯係每個 instance 扛住超出 latency 承諾嘅並發量，平時冇事，一有流量峯值立即撞穿 SLO，而嗰陣正係最多人喺度聽緊嘅時候。呢種故障喺 console 上面完全無風聲無息。
2026 年 10 月 22 日，AWS Machine Learning Blog 發表一篇教學文，示範點樣用兩個「量得出」嘅數，取代「估得出」嘅數，將整套擴縮閾值算落去。
點解舊指引唔适用
SageMaker AI 公開嘅 auto scaling 指引，大部分係針對短同步 request/response，或者 LLM 推論——自然指標係 tokens 每秒。TTS 兩者都唔係：單一請求會開住 connection 數秒，冇 token generation loop 可以掛 metric。文內用嘅 Kokoro-82M 係 8200 萬參數、非自回歸嘅 StyleTTS2 衍生模型，配備 ISTFTNet decoder，以對抗訓練取代自回歸 next-token 預測；一次 duration-aligned 過就出完整句子，根本冇生成循環可以掛 per-token metric。
兩數：Q_max 同 T_total
部署嘅係一個 custom container 落喺 SageMaker AI realtime endpoint，AWS CDK 處理 infrastructure as code。文中明確：
- Q_max：單一 instance 唔會破 SLO 嘅最高並發量
- T_total：scale-out 全程所需時間
scale-out threshold、scale-in threshold、兩邊 cooldown，全部由呢兩數做算式推導。
用原生指標，唔好自己發 metric
文內 policy 落喺 ConcurrentRequestsPerModel，呢個係 SageMaker AI 本身發出嘅指標，唔係自寫 container code 要額外發。呢一步直接斬走一類故障：自訂 metric 配置喺紙面睇好似正確，但實際上冇人向佢發數。
另有一層要處理：ConcurrentRequestsPerModel 發出嘅係 10 秒窗口嘅 Maximum statistic，同 benchmark client 直接量嘅平均 in-flight 數唔同。文中 tooling 喺 concurrency ladder 每一級同時量兩個量、記低比率，再用該比率將 client 量出嘅 threshold 換算入 CloudWatch 單位，先寫入可部署配置。文尾指所有數字來自一個 aws-samples repository 嘅實際部署同測量 run。
阿調搞兩下
呢篇文嘅意思唔係「SageMaker 好弱要人自訂」，而係：TTS 與 LLM 唔係同一物理系統，用同一套 metric 邏輯係錯誤預設。估數嘅代價唔會即刻響警報，但會喺真實流量嘅時候一次過爆。對打工仔嚟講，呢類「console 睇冇事」嘅失敗係最難寫 postmortem 嘅一種——因為根本冇 incident 被記錄。兩數實測、算式推導，係將故障由「等爆」轉成「寫低」嘅最小可行方法。
阿調｜深度調教
