レイテンシ最適化

このドキュメントは英語の原文から自動翻訳されています。表現に不自然な箇所がある場合があります。正確な内容は英語の原文もあわせてご確認ください。

ボイスエージェントやチャットボットなどのリアルタイム体験では、総スループットよりも**最初の音声が返ってくるまでの時間（time-to-first-audio）**が重要です。本ガイドを活用してその数値を低く保ちましょう。

レイテンシスタック

合計レイテンシはおおよそ次のとおりです。

input → LLM token stream → text buffer → TTS request → first audio chunk → playback

各レイヤーがレイテンシを追加します。最も寄与の大きいレイヤーから最適化してください。

1. 品質基準に合う最速のモデルを選ぶ

通常、モデル選択は最も大きなレバーになります。

Model	When to use it
`sona_speech_2`	品質を優先し、レイテンシに余裕がある場合。最高品質のモデルです。
`sona_speech_2_flash`	速度と品質のバランスを取りたい場合。`sona_speech_2`より低いレイテンシで、同等の品質を実現。voice settingsと`normalized_text`に対応。
`supertonic_api_3`	速度が最優先の場合。最小のオーバーヘッドでの推論と最良のtime-to-first-audioを実現し、`supertonic_api_1`に比べて発話安定性が大幅に向上しました。voice settingsは`speed`のみに制限されます。
`supertonic_api_1`	レガシーのsupertonicモデル。これに固定された既存連携でのみ使用してください。新規プロジェクトは`supertonic_api_3`を優先してください。voice settingsは`speed`のみに制限されます。
`sona_speech_1`	`stream_speech`によるチャンク出力、またはvoice settingsの全機能（`similarity`、`text_guidance`、`subharmonic_amplitude_control`）が特に必要な場合。

多くのインタラクティブなエージェントやチャットボットでは、各呼び出しが全体として高速に返るため、sona_speech_2_flashやsupertonic_api_3がsona_speech_1のストリーミングを上回ります。機能比較の全体はモデルを参照してください。

2. トークンを文単位にバッチする

LLMをTTSにパイプする場合、1リクエストあたり1トークンを送信しないでください。トークンを文サイズのチャンクにまとめ、1文ごとに1回のTTSリクエストを発行してください。実行可能な例についてはLLMレスポンスからのTTSストリーミングを参照してください。合理的なバッチ戦略：

文末の句読点（.、!、?、。、！、？）でフラッシュ。
カンマの後、バッファが約60文字を超えたらフラッシュ（最初の音声のレイテンシをタイトに保つため）。
ストリーム終了時にフラッシュ。

3. ストリーミングは本当に効果がある時のみ使う

stream_speech（sona_speech_1で利用可能）は音声をチャンクごとに返します。次の場合に有用です。

入力が1つで十分に長く、クリップ全体を待つと体感できるほど時間がかかる場合、かつ
クリップ全体の準備が整う前に再生を開始したい場合。

短い文サイズの入力については、各呼び出しがより速く完了するため、速いモデルでの非ストリーミング呼び出しの方が、遅いモデルでのストリーミングよりもエンドツーエンドで通常は高速です。

# Often the fastest option for an interactive agent:
response = client.text_to_speech.create_speech(
    voice_id=VOICE_ID,
    text=sentence,
    language="en",
    model="supertonic_api_3",
)

4. コネクションを再利用する

両方のSDKは、単一のクライアントとコンテキストマネージャを使用する場合、複数の呼び出しにわたって1つのHTTPSコネクションを再利用します。呼び出しごとに新しいクライアントを構築しないでください — TLSセットアップは100〜500 msを追加します。

Python
TypeScript

# Good: one client, reused across requests
with Supertone(api_key=API_KEY) as client:
    for sentence in sentences:
        client.text_to_speech.create_speech(...)

# Bad: constructs a new client (and TCP/TLS handshake) per call
for sentence in sentences:
    with Supertone(api_key=API_KEY) as client:
        client.text_to_speech.create_speech(...)

// Good: one client, reused across requests
const client = new Supertone({ apiKey: API_KEY });
for (const sentence of sentences) {
  await client.textToSpeech.createSpeech({ /* ... */ });
}

5. リトライをレイテンシ予算に合わせて調整する

遅い接続での攻撃的なリトライは、体感レイテンシを悪化させます。maxElapsedTimeはSLOに比例して保ってください — 2秒以内に応答すべきエージェントには、60秒のリトライ予算を割り当ててはいけません。チューニングについてはリトライとバックオフを参照してください。

6. 起動時にウォームアップする

サービスのデプロイ直後にトラフィックのバーストがある場合、起動時に1回のTTS呼び出しを行ってDNS、TLS、コネクションプールをウォームアップしてください。後続の呼び出しはより高速になります。

7. APIの近くに配置する

Supertone APIはsupertoneapi.comでホストされています。サービスが遠隔リージョンで動作している場合、ネットワークのラウンドトリップ自体が短いクリップのレイテンシを支配する可能性があります。必要に応じてサービスを同一地域に配置するか、エッジプロキシを追加してください。

time-to-first-audioの計測

時間がどこで消費されているかを正確に計測するために、呼び出しをラップしてください。

import time

start = time.perf_counter()
response = client.text_to_speech.create_speech(
    voice_id=VOICE_ID,
    text="Hello!",
    language="en",
    model="supertonic_api_3",
)
audio = response.result.read()
end = time.perf_counter()

print(f"Total time: {end - start:.3f}s   audio bytes: {len(audio)}")

このメトリクスを本番でトラッキングしてください。劣化した場合、原因は通常、モデル変更、ネットワーク変更、リトライのチューニング、または自社サービスのキューイングのいずれかです。

モデル

モデルのトレードオフを詳しく解説。

LLMストリーミングTTS

低レイテンシのボイスエージェント向けエンドツーエンドレシピ。

Announcement

レイテンシスタック

1. 品質基準に合う最速のモデルを選ぶ

2. トークンを文単位にバッチする

3. ストリーミングは本当に効果がある時のみ使う

4. コネクションを再利用する

5. リトライをレイテンシ予算に合わせて調整する

6. 起動時にウォームアップする

7. APIの近くに配置する

time-to-first-audioの計測

関連項目

モデル

LLMストリーミングTTS

​レイテンシスタック

​1. 品質基準に合う最速のモデルを選ぶ

​2. トークンを文単位にバッチする

​3. ストリーミングは本当に効果がある時のみ使う

​4. コネクションを再利用する

​5. リトライをレイテンシ予算に合わせて調整する

​6. 起動時にウォームアップする

​7. APIの近くに配置する

​time-to-first-audioの計測

​関連項目

モデル

LLMストリーミングTTS

レイテンシスタック

1. 品質基準に合う最速のモデルを選ぶ

2. トークンを文単位にバッチする

3. ストリーミングは本当に効果がある時のみ使う

4. コネクションを再利用する

5. リトライをレイテンシ予算に合わせて調整する

6. 起動時にウォームアップする

7. APIの近くに配置する

time-to-first-audioの計測

関連項目