AWS用两次实测替代猜测来设定SageMaker上TTS的自动扩缩目标
AWS机器学习博客给出一个工具链：在SageMaker AI实时端点上部署Kokoro-82M后，实测单实例并发上限Q_max与一次扩容总耗时T_total，再用算术推导扩容/缩容阈值和两个冷却时间，并由CDK校验阻止未经测量的配置进入生产。
AI解读：这是AWS官方博客作者Joseph Cottingham给出的一套方法，而非新产品发布：在SageMaker AI上以自定义容器部署 82M参数的TTS模型Kokoro-82M，用两次针对在线端点的测量替代凭猜测设定的自动扩缩目标，文中数字来自一次真实部署与测量。
需要弄清的问题是“哪些TTS部署适合这样做”。作者称，公开的SageMaker扩缩目标指南主要面向短同步调用或LLM服务（后者看每秒生成token数），而TTS单个请求要占用连接数秒，Kokoro-82M又是非自回归模型、没有token生成循环可挂指标，因此改为按SageMaker自身发布的ConcurrentRequestsPerModel指标扩缩。
这套方法有明确的适用条件与限制。SLO需自行指定（本例为p95首字节 3,000 毫秒），扩容耗时依赖实例类型和容器镜像，文中 260.2 秒加 60 秒策略检测余量的结果只对应本次ml.g5.xlarge运行；作者还提示示例容器锁定了存在已知安全公告的旧版PyTorch，非概念验证用途需先升级。
工具链的边界：qmax全程压低扩缩、只留一台实例，ttotal故意绕开策略检测逻辑直接强制扩容，plan是唯一不访问AWS的命令；validate与drift只读比对，不修改任何资源。artifact文件名带实例类型和镜像摘要指纹，ttotal与plan默认拒绝配对指纹不一致的产物（可用 --allow-config-mismatch降为警告）。
AWS机器学习博客发布一篇实操文章，作者Joseph Cottingham提出用两次针对在线端点的实测替代猜测来设定文本转语音（TTS）服务的自动扩缩目标。文章以 82M参数的Kokoro-82M为样本，在SageMaker AI实时端点的自定义容器中部署，先测单实例在SLO内可承受的最高并发Q_max，再测一次扩容从请求容量到流量恢复的总耗时T_total，然后用算术推导扩缩阈值与冷却时间。
为什么不用默认指标：作者给出的理由
文章称，公开的SageMaker AI扩缩目标指南主要针对短同步请求/响应调用，或针对以每秒生成token数为指标的LLM服务，而TTS两类都不符合：单个合成请求要占用连接数秒，Kokoro-82M是非自回归的StyleTTS2衍生模型（ISTFTNet解码器），一次前向就产出整句话，没有可供逐token打点的生成循环。
作者因此选用SageMaker AI自身发布的ConcurrentRequestsPerModel指标，认为这能避免“自定义指标配置看起来正确、实际没人上报”的一类故障。该指标按 10 秒窗口发布Maximum统计量，与压测客户端直接测量的平均在飞请求数不是同一个量；工具会在并发阶梯的每一级同时测两者并记录比值，再换算成CloudWatch单位。作者称本次Kokoro-82M运行在每一级的比值恰好是 1.0。
两次测量与推导出的配置
第一步qmax以闭环负载阶梯逐级提高并发，测到p95首字节时间突破 3,000 毫秒SLO为止。文中阶梯结果为：并发 50 时p95为 2,805.7 毫秒（Q_max），并发 60 时 3,374.8 毫秒越线，因而 50 是由实际越线点界定的上限。同次运行测得无排队服务时间均值 61.3 毫秒、p95 66.1毫秒。实测运行耗时约 36 分钟，可先用 --dry-run查看排期与预估。
第二步ttotal直接强制扩容并给各阶段打时间戳，实测总时长 260.2 秒，另加 60 秒策略检测余量，按 320.2 秒做规划。占比最大的是EC2实例开通加镜像拉取，180.8 秒，占 56.5%；作者据此认为缩短它的最有效手段是减小镜像或使用预热容量池，而非改应用代码。
- 实测八阶段中的主导项：容量请求到desired_set 30.0秒，desired_set到实例在日志中出现 180.8 秒，实例出现到容器启动 3.7 秒，框架初始化 0.0 秒，权重就绪 6.5 秒，预热完成 1.0 秒，进入服务 20.7 秒，恢复流量 47.4 秒
- 推导结果：扩容阈值C_scale_max = (1−0.25)×50 = 37.5，缩容阈值C_scale_min = (1−0.5)×50 = 25，扩容冷却 30 秒、缩容冷却 960 秒（约为T_total的三倍）
- 容器自身准入控制把队列深度限制在 50（等于Q_max），超出即返回 503 queue_saturated
- 另设FirstChunkLatencyP95告警，阈值 65 毫秒，取自并发 1 时的实测p95服务时间
工具给出的两处warn与配置门槛
作者说明plan命令对本次运行给出两条warn，称它们是工具如实呈现已知且被接受的取舍，并非缺陷。其一surge_survival：扩容触发瞬间单实例利用率已达 97.4%，替换实例要等满一个T_total；1.25 倍的突发比例预留了队列位，但 97.4% 利用率下流量腾挪余量很小，能否扛住突发取决于队列排空速度。其二scale_in_safety：从N台缩到N−1 台会使剩余实例并发乘以N/(N−1)，该比值需低于C_scale_max/C_scale_min（此处 1.5），即至少保持 3 台；本例下限为 1 台时，从 2 缩到 1 会让存活实例正好回到Q_max，长冷却只能抑制而不能消除来回扩缩。作者称把下限提到 3 台可结构性消除该问题，代价是低峰期保留更多常驻容量。
部署侧，三个CDK栈按序创建IAM角色与模型权重缓存桶、同步Hugging Face权重、构建镜像并创建端点。第三个栈在合成时除scaling_enabled标志外，还独立检查是否存在真实可行的plan产物，两者同时成立才生成扩缩与可观测性资源，因此带scaling_enabled=True却没有测量依据的模型不会得到扩缩资源。
- 工具链顺序：drift（只读核对已部署状态与配置是否漂移）→ qmax → ttotal → plan（唯一不访问AWS的命令）→ validate（比对线上策略与plan值）
- 文章提示：示例容器锁定的旧版PyTorch存在已知安全公告PYSEC-2026-2286（torch 2.10.0修复），非概念验证用途需先审查并升级
- 前置条件包括具备创建IAM、S3、ECR、SageMaker AI资源的账号权限，CDK v2已引导，Python 3.11+、uv、Docker，以及ml.g5.xlarge配额至少比基线多一个空位