新闻 · AWS Machine Learning Blog
别再猜测Amazon SageMaker AI上TTS的自动扩缩容目标
在Amazon SageMaker AI上部署自定义文本转语音模型的团队常常靠猜测设定自动扩缩容阈值，猜错要么浪费GPU开销，要么违反延迟SLO。本文以自定义容器部署Kokoro-82M，并基于两个实时端点测量值Q_max和T_total推导出经过实测的自动扩缩容策略，而非凭猜测。
en
英文原标题：Stop guessing auto scaling targets for TTS on Amazon SageMaker AI
本文为英文原文的机器翻译摘要，原文见：AWS Machine Learning Blog ↗
- 文章指出，为TTS端点设置自动扩缩目标时，常见做法是凭猜测设定阈值，这会导致两种隐性失败：过于保守则GPU实例闲置浪费成本，过于激进则实例并发过高，在流量高峰时延迟超出SLO。
- 作者将Kokoro-82M（8200万参数TTS模型）以自定义容器部署在Amazon SageMaker AI实时端点上，使用AWS CDK栈管理部署，并用两个实测值替代猜测：Q_max（单实例在SLO内可承受的最高并发）和T_total（一次完整扩容所需时间）。
- TTS请求与短同步调用或LLM服务不同，单次请求会保持连接数秒，且Kokoro-82M是非自回归模型，没有逐token生成循环可供埋点，因此默认的token/秒等指标不适用。
- 方案选择基于SageMaker AI原生发布的ConcurrentRequestsPerModel指标进行扩缩，避免自定义指标配置看似正确但实际无数据发布的故障；该指标发布10秒窗口的最大值，工具会测量其与客户端实测均值的比率并换算阈值。
- 部署通过三个CDK栈按序完成：SpeechFoundationStack创建IAM角色和S3桶，SpeechModelCacheStack同步Hugging Face权重，SpeechEndpointStack构建容器镜像并创建模型、端点配置和端点；第三个栈在合成时检查是否存在真实可行的测量计划，防止未测量的扩缩配置进入生产。
关键数据
- Kokoro-82M为8200万参数TTS模型，基于StyleTTS2衍生，使用ISTFTNet解码器，非自回归。
- ConcurrentRequestsPerModel发布10秒窗口的Maximum统计值。
- 在本文Kokoro-82M运行中，客户端实测与CloudWatch报告阈值的比率在各并发级别均为1.0。
- 示例容器固定了较早的PyTorch版本，存在已知安全公告PYSEC-2026-2286，已在torch 2.10.0修复。
- 需要ml.g5.xlarge服务配额，且基线之上至少有一个空闲槽位用于扩容测量。
引语
- “T_total is how long a scale-out takes end to end”
为什么值得看：文章提供了一套基于实测Q_max和T_total推导TTS自动扩缩阈值的可复现方法，并用CDK门禁防止未经验证的扩缩配置进入生产，对部署实时语音服务的团队有直接参考价值。