詳しい解説 · 読了目安 7 分
AWSの技術ガイド：エージェントの返答完了前にKokoroで発話を始める
SageMakerで文ごとに音声を合成する方法を、待ち時間、転送コスト、実験の限界に分けて読む。
- 当サイトの公開日
- 原典の公開日
- 出典確認日
AWSのJoseph Cottinghamが10月22日に公開した技術ガイドは、言語モデルが続きを生成している間に、完成した文をKokoro-82Mへ送る構成を説明する。統合方法と限定的な比較であり、新しい音声モデルの提供開始や一定の遅延を保証する発表ではない。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- 例ではml.g5.xlarge上の独自ASGIコンテナでKokoro-82Mを動かし、複数の文に同じ双方向セッションを使う。
- AWSによる単独TTS試験は各方式5回で平均329.3→156.7 ms。別のエージェント比較では最初の音声が2.4倍、3.5倍速いと報告する。
- モデル側はバイナリ音声でBase64を避けるが、AgentCoreから呼び出し元への経路にはSSEとBase64が残る。
新モデルではなく、待つ位置を変える
避けられる遅延は、テキスト生成と音声合成の間にある。一括方式では最初の文が完成していても返答全文が揃うまでTTSを呼ばない。AWSの方式は文が完成するたびに送る。例では8200万パラメータのKokoroを独自Starlette ASGIコンテナに入れ、SageMaker AIのリアルタイムml.g5.xlargeエンドポイントで動かす。利用者が配置する基盤であり、自動的に有効になる音声機能ではない。
コンテナはヘルスチェック、全文入力のHTTP、接続を維持する双方向WebSocketの経路を持つ。後者にはSageMakerの双方向ストリーミング対応ラベルが必要だ。適切なIAM権限、CDK v2、Docker、Python 3.12以降、対応するBoto3クライアントも前提となる。ブラウザーの再生設定だけではなく、アプリとクラウド構成を変更する作業である。
接続を共有しても合成は文の順番通り
フレーム形式の不一致は、正常に見えるエンドポイントを使えなくする。ガイドによると、SageMakerはクライアントのメッセージをバイナリWebSocketフレームとして渡す。テキスト欄だけを読む処理は、状態がInServiceのままでもKeyErrorを起こし得る。そのため例の受信処理はテキストとUTF-8に復号したバイト列の両方を扱う。接続状態と音声生成成功は別々に確かめる必要がある。形式の整ったエラー応答は合成成功の証拠にならない。
各文の音声とsynthesis_complete制御メッセージを送った後、サーバーは同じセッションで次の入力を待ち、クライアントの明示的な終了指示で閉じる。分割器は完成文を取り出し、最後に句読点のない残りもflushする。ただし会話内の合成は逐次的で、第一文を転送中に第二文を合成しない。重なるのは、言語モデルによる後続テキスト生成と、先行テキストのTTS処理である。
三つの通信経路を混同しない
全体例はBedrockAgentCoreApp内のStrandsエージェントを使う。呼び出し元とエージェント、Amazon Bedrockからのテキスト受信、エージェントとKokoroという三つの経路がある。モデル側では同じセッションにバイナリ音声とJSON制御を流す。先頭バイトだけでは正当なPCM音声を誤判定し得るため、チャンク全体をJSONオブジェクトとして解析できる場合だけ制御と判断する。
呼び出し元に返す経路には、SSE形式のJSONとBase64音声が残る。管理された入口がJSON化できる辞書の出力を要求するためで、比較した両方式とも同じ負担を持つ。したがってBase64による約33%のサイズ増加がシステム全体から消えたわけではない。既存SSE経路では、転送チャンクが完全なイベントや音声フレームと一致しないため、バッファリングと再構成も必要だ。バイナリ方式の対象はモデル側であり、すべてのブラウザー経路ではない。
遅延と符号化の実験は分母が異なる
単独TTS試験では267文字・4文の文章を使い、全文と第一文だけを送る方式を各5回比較した。最初の音声バイトまでの平均は329.3から156.7 msへ下がり、相対減少は52.4%だった。別の実言語モデル試験ではプロンプト、モデル、エンドポイントを揃え、ローカルコンテナで最初の音声が2.4倍、配置済みAgentCoreで3.5倍速いと報告した。図では各一括基準の0.42倍、0.29倍に相当する。
この比率からエンドツーエンドの絶対ミリ秒や本番p95は分からない。別の24クリップ試験では、48k表記のMP3が実測49.5 kbps、32k表記のfMP4 AACが41.6 kbpsだった。Base64でMP3は308,304から411,072バイト、AACは258,039から344,084バイトへ増えた。名目ビットレートの保証ではなく、この測定のペイロードである。著者のTranscribe確認は、聴感の忠実度が同等だと証明する主観聴取実験ではない。
依存関係と残る料金も判断材料にする
AISubHubの分析では、後続文を待つ時間が体感遅延の大きな部分を占める場合に、この構成が有効になる。音声エンジンを並列化したり、容量、同時処理、地域での提供、普遍的な節約率を実証したりはしない。原文自体は固定された古いPyTorchを警告し、PYSEC-2026-2286と修正版torch 2.10.0を挙げる。これは原文の注意として紹介するもので、その助言やリンク先リポジトリを当サイトが独立監査したわけではない。
AgentCoreランタイムとSageMakerのモデル、エンドポイント設定、エンドポイントを削除しても、重みを置くS3バケットやECRイメージリポジトリは消えない。共有ストレージは不要になった際に別途削除するまで料金が続き得る。導入判断では自分の最初の音声までの経路を測り、残存資源も計上する必要がある。当サイトは例を実行せず、音質も測定しておらず、本番サービス水準を保証していない。
注目する理由
逐次的な待ち時間の削減と音声転送の変更を分ける点が実用的だ。通信経路、遅延の比較基準、残す資源を明示すれば導入実験の参考になる。
制約と提供状況
数値はAWSの例に属する。各5回の平均、相対比、認識確認から本番の裾遅延、主観音質、一般的な価格は結論できない。コードや外部助言は当サイトで実行・独立監査していない。
出典と根拠
原典の公開日: · 出典確認日:
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。