为 Amazon SageMaker AI 上的 TTS 端点实测自动扩缩容目标

自建文本转语音（TTS）端点遇到流量尖峰时，请求开始排队，延迟在最需要服务的时刻越过 SLO。问题往往不在扩缩容策略本身，而在策略所依据的目标值来自猜测：猜保守了，GPU 实例长期空转，成本体现在每张账单上却不触发告警；猜激进了，单实例承载的并发超过它在延迟承诺内能服务的量，直到真实尖峰把排队时间推过 SLO 才暴露。

AWS 在 Amazon SageMaker AI 上给出了一套用实测替代猜测的做法：把 82M 参数的 TTS 模型 Kokoro-82M 以自定义容器部署到实时端点，用 AWS CDK 管理部署，再对活端点做两项测量——Q_max，即单实例在不违反 SLO 前提下能承受的最高并发；T_total，即一次扩容从开始到完成的总耗时。扩容阈值、缩容阈值和两个冷却时间都由这两个数经算术推导得出。

为什么默认指标不适用

公开的 SageMaker AI 扩缩容指引多针对短同步请求/响应调用，或大语言模型推理（自然指标是每秒生成 token 数）。TTS 合成两者都不符合：单个请求会占用连接数秒，且没有 token 生成循环可供挂接指标。Kokoro-82M 是非自回归模型，属于 StyleTTS2 的衍生架构，带 ISTFTNet 解码器，以对抗方式训练，一次时长对齐的前向即可产出整段语音。

判断 TTS 实例是否过载，关键量是当前排队与执行中的请求数。方案因此基于 ConcurrentRequestsPerModel 扩缩容——这是 SageMaker AI 自己发布的原生指标，不需要容器代码自行上报，从而避开“自定义指标配置看起来正确、实际无人写入”这类失效。

该指标发布的是 10 秒窗口内的 Maximum 统计值，与压测客户端直接测得的在途请求均值不是同一量。工具在并发阶梯的每一级同时测量两者并记录比值，再把客户端测得的阈值换算成 CloudWatch 单位后写入部署配置。本次 Kokoro-82M 运行中，各级实测比值均为 1.0，两个口径的阈值直接一致。

请求路径与容器选择

一次合成请求经过四层：客户端、SageMaker AI 端点、端点后 GPU 实例上的自定义容器、容器内的 Kokoro-82M 模型。容器支持两种传输方式：响应流式（InvokeEndpointWithResponseStream），边合成边回传音频，播放可在整段语音完成前开始；双向流式（InvokeEndpointWithBidirectionalStream），保持一个长连接会话处理多条消息。

选择自定义容器而非托管推理工具包，是为了让容器自行执行准入限制，并暴露 SageMaker AI 已发布的并发信号，而不是把借来的指标硬套到不适配的负载上。CDK 栈只有在存在真实测量方案时才挂载扩缩容资源，使猜测出来的配置无法悄悄进入生产。

前置条件与注意事项

跟随该方案需要：具备创建 IAM 角色、S3 存储桶、Amazon ECR 仓库和 SageMaker AI 资源权限的 AWS 账号；已安装并在目标账号与区域完成引导的 AWS CDK v2；Python 3.11 或更高版本、uv 与 Docker 用于构建镜像；以及至少比基线多一个空闲槽位的 ml.g5.xlarge 服务配额，用于运行扩容测量。

AWS 特别提示：示例容器固定了较早版本的 PyTorch，存在已知安全公告 PYSEC-2026-2286，该问题在 torch 2.10.0 中修复，任何非概念验证用途前都应审查并升级该版本锁定。

编辑部观察

这套方法的价值不在具体数字，而在流程：先测单实例的 SLO 并发上限和扩容耗时，再由算术推出阈值与冷却时间，而不是沿用通用默认值。对自建 TTS 或其他长连接推理服务的团队，可核查三点：扩缩容所依赖的指标是否由平台原生发布、压测口径与平台统计口径是否做过比值校准、以及扩缩容资源是否被限制在实测方案之后才启用。示例容器的依赖版本安全状况也应在试点前单独确认。