ローカルLLM（Gemma4）× AIVIS Speech で音声チャットの応答を「1秒未満」にした話

> Source: Qiita_Trend

// Problem

音声対話において、LLMの推論とTTSの音声合成を直列に処理すると、特にTTSのデコーダー推論がボトルネックとなり、応答が1秒を超えてしまう。これにより、人間同士の自然な会話リズム（200〜500ms）から乖離し、ユーザーの没入感が損なわれるという課題がある。

// Approach

ネットワークホップを最小化するためフロントエンドから各APIへ直接リクエストを送信。Gemma4のシンキングモードをOFFにして推論速度を優先し、句読点検知による早期チャンク分割と、TTSの非同期並行生成（Fire-and-Forget）を実装。さらに、ローカルCPUでのTTS生成を避け、クラウドAPIのストリーミングモードを採用することで、TTFBを劇的に短縮した。

// Result

初回音声再生までの時間を694msまで短縮することに成功。内訳はOllama応答に209ms、トークン蓄積に193ms、TTS生成に291ms。LLMのストリーミングとTTSの並行処理により、2チャンク目以降も途切れのないシームレスな音声再生を実現している。

Senior Engineer Insight

> 本構成の肝は「精度を捨てて速度を取る」というトレードオフの明確化と、ネットワークホップを徹底的に排除したアーキテクチャにある。中継サーバーを置かないフロントエンド直結構成は、極限の低レイテンシを求める場合には合理的だが、セキュリティや認証管理の観点では課題が残る。実戦投入においては、APIキーの隠蔽や、エッジ側での推論負荷の動的制御が鍵となるだろう。また、TTSをクラウドに逃がす判断は、計算リソースの最適化として極めて現実的かつ賢明な判断である。