Amazon SageMaker AIのTTSモデル向けオートスケーリング最適化手法が公開、実測値から閾値を算出

要点

• AWSは、Amazon SageMaker AI上の音声合成（TTS）向けに、実測値からオートスケーリング目標値を算出する手法を公開した。

• 勘による設定が引き起こす、余剰GPUコストの発生やアクセス急増時のサービスレベル目標（SLO）違反を防止する。

• TTSモデルはLLMと異なりトークン生成ループを持たないため、従来のスケーリング指標が適用できない課題に対処した。

• 最大同時実行数（Q_max）とスケールアウト所要時間（T_total）の実測値から、閾値や待機時間を算術的に導出する。

• アマゾン ウェブ サービス（AWS）は2026年10月22日、Amazon SageMaker AI上で音声合成（TTS: Text-to-Speech）モデルを運用する際のオートスケーリング最適化手法を公式ブログで発表した。推測に基づく設定を排し、実機環境の測定データからスケールイン・アウトの目標値を算出するアプローチを提示している。コスト抑制とアクセス集中時のレイテンシ維持を両立させる狙いだという。

推測による設定が招くコスト増加とサイレントなSLO違反

自前ホストのTTSエンドポイントでは、アクセス急増時にリクエストが滞留し、利用者が集中する時間帯に応答遅延がSLO（サービスレベル目標：システムが満たすべき性能基準）を超過する問題が起こりやすい。AWSによると、オートスケーリング目標値が推測で設定され、実負荷で破綻するまで欠陥が表面化しないことが原因だという。

目標値が保守的すぎると、GPUインスタンスが遊休状態のまま稼働して不要なコストが発生する。逆に攻めすぎると、各インスタンスが許容量以上のリクエストを抱え、急なアクセス集中で遅延を引き起こす。これらは通常のアラームで検知されず、実トラフィックで問題化するまでサイレントに進行すると説明している。

TTSモデルの構造的特性と従来スケーリング指標の不適合

SageMaker AIの従来のスケーリング指針は、短時間の同期型処理や、毎秒生成トークン数を指標とする大規模言語モデル（LLM）を前提としている。しかしTTSは1リクエストの接続が数秒間続き、トークン生成ループを持たないため既存の指針が合致しない。

検証に用いられた8200万パラメータのTTSモデル「Kokoro-82M」は、敵対的学習を用いた「StyleTTS2」派生で、「ISTFTNet」デコーダを備えた非自己回帰型（出力を一括生成する方式）モデルだ。1回のパスで発話全体を出力し反復ループが存在しないため、トークン単位の指標は測定できない。そのため、負荷状況はキューで待機・実行中のリクエスト数で判断する必要があるという。

実測値「Q_max」と「T_total」に基づく算術的導出

この課題に対しAWSは、稼働中のエンドポイントで得た2つの実測値からポリシーを決定する手法を示した。検証環境では「AWS Cloud Development Kit（AWS CDK: インフラをコード定義するツール）」を用い、Kokoro-82Mをリアルタイムエンドポイントにカスタムコンテナとしてデプロイしている。

測定する指標は以下の2点だ。

• Q_max: 単一インスタンスがSLOを満たしたまま維持できる最大の同時実行リクエスト数
• T_total: スケールアウト開始から追加インスタンスが稼働するまでの全所要時間

これら2つの数値から算術計算によって、スケールイン・アウトの閾値や過剰な伸縮を防ぐ待機時間を論理的に導出する。提示された数値はすべて、「aws-samples」リポジトリの実測データに基づいている。

プラットフォーム標準メトリクス「ConcurrentRequestsPerModel」の採用

監視メトリクスには、独自実装のカスタムメトリクスではなくSageMaker AI標準の「ConcurrentRequestsPerModel」を採用した。自作メトリクスの設定ミスによる送信不備を防ぐためだ。

ただし、同指標は10秒間の最大値を集計するため、負荷テストツールが測る処理中リクエストの平均値とは統計的な性質が異なる。そこでツール側で負荷テストの各段階における両者の比率を計測し、実測値をAmazon CloudWatchの単位へ変換して設定に書き出す仕組みを整えた。Kokoro-82Mでの実測ではすべての段階で比率が1.0となり、クライアント実測値とCloudWatchの報告値が完全に一致したという。

補足

本手法のデプロイコードおよび測定ツールは、AWS公式の「aws-samples」リポジトリとして公開されている。