AWSはKokoro-82Mの同時処理上限と拡張所要時間を測り、SageMaker AIの自動拡張設定へ反映する手順を紹介しました。 要求数の平均だけでは音声合成の混雑を捉えにくい場合があります。遅延目標と急増時の余力を実際の負荷で確かめることが焦点です。 音声合成の容量設定を推測から実測へ AWSは10月22日、SageMaker AI上の音声合成を対象に、自動拡張の設定値を測定から決める手順を公開しました。Kokoro-82Mをカスタムコンテナーで動かし、1台が遅延目標を守れる最大同時処理数と、実際に台数を増やすまでの時間を調べます。設定が控えめすぎると計算資源が余り、厳しすぎると要求が積み上がって待ち時間が増えます。どちらも平常時の画面だけでは問題を見つけにくいと説明しています。新機能の提供ではなく、運用中の指標と設定を対応させる実装方法を示す記事です。音声合成に合う負荷の見方を整理しています。負荷が増えてから新しい処理能力が使えるまでの間を、設定へ反映する点が重要です。測定としきい値の関係を残すことで、運用上の根拠を説明しやすくなります。 接続が続く処理を同時要求数で捉える Kokoro-82Mは音声を生成する間、接続を保持します。一般的な短い要求や、トークンの生成速度を測るLLMとは異なるため、単純に同じ拡張基準を使えません。紹介した方式はSageMaker AIが公開するConcurrentRequestsPerModelを利用します。負荷試験の平均同時処理数と、指標に現れる値は同じ量ではないため、両者を同じ負荷で測って対応を求めます。影響を受けるのは自前のTTSエンドポイントを運用する基盤担当者です。最大同時処理数と拡張時間を基に、拡張・縮小のしきい値や待機時間を計算します。指標を独自に送信する構成と比べ、送信されていない指標へ設定を結び付ける失敗を避ける狙いがあります。ただし、標準指標であっても単位や集計方法の確認は必要です。数値を他の構成からコピーしない点が要点になります。 遅延目標と急増条件を先に決める 実務では、守る遅延目標と想定する要求の増え方を決めた上で測定することが論点です。音声の長さや同時接続の傾向が変われば、同じ台数でも必要な余力が変わる可能性があります。記事の測定値を自社の容量として使うのではなく、同じ測定方法を実際の環境へ適用する進め方が考えられます。拡張時間にはモデルやコンテナーの起動も関わるため、台数が増え始める時点と要求を処理できる時点を区別する必要があります。縮小を早めすぎた場合の再拡張や、待ち行列の長さも確認する材料です。費用と遅延の折り合いを説明できるよう、設定の根拠となる測定結果を残す運用が重要と見られます。モデルや実行基盤を更新した際に同じ試験を行い、しきい値がまだ有効かを見直すことが次の判断点です。