AWS博客：两个实测值替代TTS自动扩缩容的猜测

流量高峰到来，语音合成请求开始排队，延迟突破服务等级目标——而自动扩缩容策略本该阻止这一切。问题在于，策略所依据的阈值往往是凭经验猜出来的。猜得太保守，GPU实例大量闲置，成本体现在每张账单上却不会触发任何告警；猜得太激进，每台实例承载的并发请求超出其延迟承诺，控制台上一切正常，直到真正的流量高峰把排队时间推过SLO，才在最多人收听的时刻暴露出来。

为什么语音合成不能沿用大语言模型的扩缩容指标？多数公开指南针对的是短同步请求或LLM推理，自然指标是每秒生成的token数。但Kokoro-82M这类非自回归模型一次前向传播就产出完整语音，没有逐token生成循环可以挂载指标。决定一台TTS实例是否过载的因素更简单：此刻有多少请求在排队和执行。因此，该方案选用SageMaker AI原生发布的ConcurrentRequestsPerModel指标，而非自定义的吞吐量度量。

核心方法被称为四数模型：操作者选定两个参数——延迟SLO（本文取3000毫秒p95首音频字节时间）和溢出比率（1.25倍，即允许流量在一个扩容周期内增长25%而不破SLO）——然后对实际端点做两次测量。第一次是Q_max：用闭环负载阶梯逐档提升并发数，直到p95延迟突破SLO，取最后一个满足SLO的并发值。本文的Kokoro-82M在ml.g5.xlarge上测得Q_max=50。第二次是T_total：强制触发一次扩容，逐阶段计时，从请求容量到恢复健康流量的端到端耗时。本文测得纯供给耗时260.2秒，加上策略检测延迟的上界60秒，计划使用的T_total为320.2秒。

有了Q_max和T_total，扩缩容阈值和冷却时间全部由算术推导：扩容阈值C_scale_max = (1−h) × Q_max = 0.75 × 50 = 37.5；缩容阈值C_scale_min = (1−2h) × Q_max = 0.50 × 50 = 25。扩容冷却取短（30秒），因为多开一台实例的代价小；缩容冷却取长（约3倍T_total，即960秒），因为缩掉一台实例后若流量回升，重新扩容需要整整320秒。容器自身的准入控制将队列深度硬限在Q_max=50，超出即返回503拒绝，而非让请求排队到必然超时。

这套方法的关键洞察不限于TTS。博客指出，SageMaker AI上延迟敏感、并发受限的实时推理端点——例如一个在GPU前向传播期间保持连接打开的图像嵌入端点——其瓶颈都是并发在途请求数，而非从其他工作负载形状借来的吞吐量指标。四数模型的推导逻辑和五步工具链（drift、qmax、ttotal、plan、validate）可原样迁移。但具体数值会因模型和实例类型而不同：Q_max=50和T_total=320秒只对Kokoro-82M在ml.g5.xlarge上成立，换模型或换机型必须重新测量。