ローカル音声対話、応答開始2.37秒

この構成はカスケード型のSpeech-to-Speechパイプラインで、音声活動検出、ターン検出、音声認識、言語モデル、音声合成をそれぞれ別モデルとして1基のGPU上で動かす。Windows PCはマイクとスピーカーだけを担い、SSHトンネル経由で接続する。speech-to-speech自体はOpenAI Realtime互換のWebSocketサーバーとして待ち受け、会話履歴、ターン処理、割り込みを管理する。

2.37秒を分解すると、VADが約0.10秒、Smart TurnとSTTが合わせて約0.81秒、LLMが1.36秒、TTSの初回音声出力までが約0.10秒だった。テスト担当者によると、ログではTTSが始まる前に回答全体が生成されており、パイプラインが完全な応答を待ってブロックしている可能性がある。これは生のモデル速度ではなく受け渡しの問題だ。TTS自体はボトルネックではないようで、単体テストではリアルタイムの約8倍の速さで音声を生成した。Smart Turnも重要で、文中の間を未完了の発話と正しく判断してターンを維持し、AIが返答を始めた後にユーザーが話し続けた場合は進行中の処理をキャンセルした。履歴がより長い別セッションでは、入力が500トークンを超えるとLLMの処理時間が1.59〜2.18秒に伸びたが、サンプルが少なく比例的な遅延と断言するのは早いとテスト担当者は注意を促している。

鍵を握るのは、LLMの出力を文単位でTTSにストリーミングすることでテスト担当者が期待する遅延削減が実現するかどうかだろう。実現すれば、手頃な単一GPU環境のローカル音声アシスタントはプライバシー重視の導入先でより現実的になる。実現しなければ、残る差はこうした用途をより大規模な計算資源へ押し戻すかもしれない。テスト担当者は、外部通信を一切行わない完全オフライン動作は未検証だと指摘している。音声を外部に送れない環境では、これが最も重要な評価項目になりそうだ。