AWSはSageMaker AI上のKokoro-82Mへ生成中の文を順次送る実装を紹介しました。応答全文を待たずに音声合成を始める構成です。 最初の音が届く時間と通信形式の負担を一緒に評価できます。サンプルの依存関係には更新が必要と原文が明記しています。 回答の完成前に音声合成を始める AWSは10月22日、AIエージェントの応答を低遅延で音声化する実装を公開しました。SageMaker AIのリアルタイムエンドポイント上でKokoro-82Mを動かし、エージェントが文を作るたびに合成へ送ります。長い応答の全体が完成するまで待つ構成では、テキストができ始めても利用者には無音の時間が続きます。今回の方式は文章生成と音声生成を並行させ、その待ち時間を減らすものです。新しい音声モデルの発表ではなく、既存モデルと双方向ストリーミングを組み合わせる技術解説です。ブラウザーへ音声を返す通信方法についても比較しています。モデルが話す内容を決める部分と、文章を音へ変える部分の接続が対象です。利用者へ届くまでの待ち時間を、処理の境界で分けて測る内容になっています。 双方向接続とブラウザーへの配信を分けて設計 Kokoro-82Mはカスタムコンテナーで配備し、単発の入力と双方向の接続を扱います。原文の構成はml.g5.xlargeを利用し、AgentCoreなどと組み合わせます。ブラウザーへ返す経路では、SSEへbase64で音声を載せる方式と、バイナリー音声とJSON制御情報を同じ接続で扱う方式を説明しています。前者ではデータ量が約3分の1増え、MP3のフレーム境界を扱うための処理も必要です。対象は音声エージェントや会話システムを実装する開発者です。AWSは紹介した実験で最初の音声までの時間が短くなったと報告していますが、実際の値は文章やネットワーク、配備環境で変わります。モデル単体の生成時間と、利用者が聞き始めるまでの時間を分けて測ることが論点です。接続の維持や切断時の扱いも体験に関わります。 サンプルの依存関係と遅延全体を確認する 原文はサンプルが既知の問題を持つ古いPyTorchに固定されていると明記し、試験用途を超える前に更新を求めています。導入側ではコードをそのまま本番へ移さず、依存関係とコンテナーの設定を確認する必要があります。文ごとに処理する場合は、区切りの検出が早すぎて不自然な読み上げにならないかも評価対象です。通信形式の変更は転送量だけでなく、クライアントの実装や再接続の処理に影響する可能性があります。実務では、最初の音声、全文の終了、途中での停止などを同じ条件で測る進め方が考えられます。利用者の割り込みをどう受け付けるかも、応答を早める価値と合わせて検討する論点です。試験の改善率を自社へ当てはめる前に、想定する長さの発話と同時接続数で確認することが、費用と品質を判断する材料になります。