SageMaker TTS Kokoro-82M Q_max T_total 自动扩展策略

SageMaker TTS Kokoro-82M Q_max T_total 自动扩展策略

Teams deploying custom text-to-speech models on Amazon SageMaker AI often guess at autoscaling thresholds, and a wrong guess either wastes GPU spend or breaches a latency SLO. This guide presents a data-driven approach using measured values of Q_max (maximum concurrency per instance before SLO breach) and T_total (full scale-out time) to derive reliable policy settings for Kokoro-82M TTS on SageMaker. It is suitable for teams running production endpoints with variable load, custom containers, and strict latency targets. Decision is straightforward: measure your own endpoint first, then apply the formulas below.

The method is engine-verifiable and eliminates silent over- or under-provisioning. It directly addresses the limitations of default SageMaker autoscaling for non-autoregressive TTS workloads like Kokoro-82M, where traditional token-per-second metrics do not apply.

为什么 TTS 自动扩展不同于 LLM

SageMaker 的默认指标和常见建议多针对同步请求或大型语言模型（LLM），其中自然指标是 tokens generated per second。Kokoro-82M 是非自回归模型（StyleTTS2 变体），一次推理生成整个音频片段，没有生成循环可嵌入指标。

TTS 超载的判断条件非常简单：实例上排队和正在执行的请求数量。Kokoro-82M 使用 ConcurrentRequestsPerModel 这一 SageMaker 原生指标，避免自定义指标失效。

SageMaker TTS Kokoro-82M Q_max T_total 自动扩展策略概述

该策略在 SageMaker 实时端点上部署 Kokoro-82M 自定义容器，然后用两个现场测量值替换猜测的阈值：

• Q_max：单实例在 SLO 内能维持的最高并发（排队 + 执行中的请求）。
• T_total：从请求更多容量到容量服务健康流量所需的全流程时间。

请求路径经过四层：客户端、SageMaker 端点、自定义容器和容器内的 Kokoro-82M 模型。

核心公式（直接从官方部署测量推导）： `` scale_out_threshold = Q_max + 1 scale_in_threshold = Q_max - 1 scale_out_cooldown = T_total scale_in_cooldown = T_total * 2 `` 这些值由实际部署的 aws-samples 仓库生成，任何生产配置必须经过此过程。

现场测量与配置

在部署阶段，AWS CDK 堆栈会检查是否已有真实可行的测量计划（plan）才生成自动扩展资源。无测量计划则无法进入生产环境。

#### 测量 Q_max（并发上限） 使用负载阶梯测试（闭环方式，避免协调省略）。固定并发 N，逐步增加直到 p95 首音频字节时间超过 3000 ms SLO。

Q_max = 50，这是一真实上限（60 已超标）。无队列服务时间均值 61.3 ms，可作为额外监控基线。

#### 测量 T_total（规模扩展时间） 强制执行规模扩展，记录八个阶段时间（从请求到健康流量）。使用 Q_max 作为输入，避免跨传输协议的不兼容。

部署与监控

1. 部署三个 CDK 堆栈（IAM、模型缓存、端点）。
2. 运行 drift 检查部署状态。
3. 执行 qmax 测量，生成计划。
4. 执行 ttotal，生成最终策略。
5. 应用到生产端点，CloudWatch 仪表板会显示延迟、并发和扩展警报。

风险与边界

如果测量不准确（例如服务迁移或硬件变更），策略可能失效——过度保守导致 GPU 闲置浪费，过度激进导致 SLO breach。建议定期重新测量，并将官方/挂牌页当日数据作为基准。这不是法律意见，仅供参考。

延伸阅读

• API 中转：结合 Grok API 与中转倍率优化整体语音合成成本
• 模型天梯：探索 Kokoro-82M 在本地部署与云端性能对比
• 工具：查看本地部署与算力账工具页
• api-lab：本地部署实验室资源
• open-models：开放模型列表与部署指南

English summary

Teams deploying custom text-to-speech models on Amazon SageMaker AI often guess at autoscaling thresholds, and a wrong guess either wastes GPU spend or breaches a latency SLO. This guide presents a data-driven approach using measured values of Q_max (maximum concurrency per instance before SLO breach) and T_total (full scale-out time) to derive reliable policy settings for Kokoro-82M TTS on SageMaker. It is suitable for teams running production endpoints with variable load, custom containers, and strict latency targets. Decision is straightforward: measure your own endpoint first, then apply the formulas below. The method is engine-verifiable and eliminates silent over- or under-provisioning. It directly addresses the limitations of default SageMaker autoscaling for non-autoregressive TTS workloads like Kokoro-82M, where traditional token-per-second metrics do not apply. Official deployment measurements provide the exact numbers for scale-out threshold = Q_max + 1, scale-in threshold = Q_max - 1, scale-out cooldown = T_total, and scale-in cooldown = T_total * 2. Teams can replicate the closed-loop concurrency ladder and forced scale-out test to obtain their own verified values. This approach replaces guesswork with arithmetic based on live endpoint data.