AWS 发布工具链通过实测 Q_max 与 T_total 推导 SageMaker AI 实时端点扩缩容策略
Stop guessing auto scaling targets for TTS on Amazon SageMaker AI
AWS Machine Learning Blog 发布了一套针对 Amazon SageMaker AI 实时端点的自动化测试工具链,旨在解决文本转语音(TTS)等长连接模型在自动扩缩容中因依赖经验猜测而导致的成本浪费或延迟超标问题。该方案以 Kokoro-82M 模型为例,通过五步命令行流程(drift、qmax、ttotal、plan、validate),利用实测数据替代默认配置,确保扩缩容策略精确匹配实际负载特征。
核心方法在于两个关键指标的实测:Q_max 定义为实例在满足 SLO(如首字节延迟 p95 < 3000ms)前提下的最大并发数,实测结果为 50;T_total 为强制扩容所需的总耗时,实测为 260.2 秒,其中 EC2 实例供应及镜像拉取占 181 秒。基于这两个数值,结合预设的流量突增系数(surge ratio 1.25x)和 SLO 目标,工具链通过算术公式计算出具体的扩缩容阈值(scaling_target_value=37.5, scale_in_threshold=25.0)及非对称冷却时间(scale_out_cooldown_s=30, scale_in_cooldown_s=960)。
该方案强调使用原生指标 ConcurrentRequestsPerModel 而非自定义 Token 生成速率,因为 TTS 等非自回归模型缺乏连续的 Token 生成循环。此外,文章指出扩容决策中的主要瓶颈在于基础设施层(EC2 启动与镜像拉取),而非应用代码优化。虽然文中给出的具体数值(Q_max=50, T_total=320s)仅适用于 ml.g5.xlarge 实例上的 Kokoro-82M 模型,但所提出的测量方法论和工具链具有通用性,可推广至其他对延迟敏感且受并发限制的实时推理场景。
提供了一套可复现的测量工具链,将 TTS 模型的扩缩容阈值从经验猜测转化为基于并发上限和扩容时延的算术推导。
来源:AWS Machine Learning Blog · aws.amazon.com