LLMの応答が速くても、なぜ家庭用音声アシスタントは遅く感じるのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does a Home Voice Assistant Feel Slow Even When the LLM Responds Quickly? - Zima Store Online

ホーム音声アシスタントが遅く感じられるのは、音声のキャプチャ、エンドポイント検出、ツール、音声合成、再生がLLMを直列的な遅延で取り囲んでいるためです。

ローカルモデルが最初のトークンを120ミリ秒で生成しても、キッチンのスピーカーがコマンドの終了から2秒後に応答することがあります。ユーザーが体験するのは、1つのベンチマークではなく、ターン全体です。プロンプトの前に行われる無音検出や、応答後の音声バッファリングだけで、高速な言語モデル推論にかかる時間を上回ることがあります。

LLMが担うのは音声ターンの一部分だけ

発話されたターンは、マイクのバッファリング、音声活動検出、エンドポイント検出、ASR、プロンプトの組み立て、モデル生成、ツール実行、TTS、音声出力を経由します。ほとんどの段階は、直前の段階が終わるのを待ちます。そのため、最初のトークンが生成されるまでの時間が短いからといって、テキストが届いた後の言語処理段階が速いことしか証明できません。

音声スタックのレイテンシ分析では、経路を複数のレイテンシ段階に分解し、1つのコンポーネントを最適化しても高速な会話が保証されない理由を示しています。個々の段階が単独ではそれほど遅く見えなくても、直列的なオーバーヘッドは積み重なります。

エンドポイント検出は、見落とされがちなフロントエンドのコストです。アシスタントは、無音が話し手の発話終了を意味するのか、それとも考えているだけなのかを判断する必要があります。保守的なタイムアウトは割り込みを防ぎますが、ASRの確定前に無音時間が加わるため、その直後にLLMがすぐ起動しても、システムはためらっているように感じられます。

ストリーミングは、すべての処理をなくさずに体感速度を高める

部分的な文字起こしを使えばプロンプトの準備を開始でき、ストリーミングされたトークンを回答の完成前にTTSへ渡すこともできます。こうした重ね合わせによってクリティカルパスは短くなります。ただし、音声出力が始まるタイミングは、チャンクサイズ、安全性チェック、ツールの確認、そして合成を開始する前に必要な安定テキストの量によって決まります。

低レイテンシの音声エージェントに関する研究では、ストリーミングASR、量子化言語モデル、リアルタイム合成を組み合わせています。エンドツーエンドの応答性は、モデル速度だけを報告するのではなく、この3つすべてを連携させることに依存するためです。

最終的な音声の長さよりも、最初の音が出るタイミングのほうが重要な場合もあります。500ミリ秒で自然な応答を始めるシステムは、回答全体を900ミリ秒で無音のまま完成させるシステムより速く感じられることがあります。ストリーミングはフィードバックのタイミングを変えますが、遅いツール呼び出しを消し去るわけではありません。

パイプラインによる説明が当てはまらない場合

アシスタントが意図的に確認を待つ、コマンドをレート制限する、または会話上の間を置く場合、パイプラインの遅延だけでは十分に説明できません。ネットワークジッター、スピーカーの省電力動作、Bluetoothの再接続、オーディオデバイスの起動時間は、AIスタックの外部で発生することがあります。サーバー内部のトレースが高速でも、最終的に遅い部屋のスピーカーへ到達することがあります。

会話のレイテンシに関する指針では、人は短いターン間隔を期待するとされており、体感上の応答タイミングは単一モデルの統計値ではなく、製品レベルの特性だと説明されています。フィードバックが保留されると、合計の計算時間が変わらなくても体感遅延は増加します。

サーバーのタイムスタンプで音声再生がすぐに始まっているのに、ユーザーが遅延を報告する場合、この仕組みだけでは説明できません。その場合は、音響的な距離、デバイス間の同期、またはインターフェースのフィードバックが原因かもしれません。また、最初のコマンドだけ遅く、その後のコマンドが速いケースも説明できません。これはコールドスタートや電源状態の遷移をより強く示唆します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

LLMだけでなく、音声ターン全体を測定する

マイク入力の開始、検出されたエンドポイント、最終文字起こし、プロンプトの送信、LLMの最初のトークン、ツールの完了、TTSの最初のチャンク、再生キュー、可聴出力について、単調増加する時計によるタイムスタンプを1つずつ記録します。コールドスタートとウォームスタートの両方で、短いコマンドを20回、ツールを使用するコマンドを5回実行します。

これらのトレースをローカルAIのコールドスタートと比較します。モデルの読み込みが最初のターンを歪める一方で、後続のターンではエンドポイント検出が支配的になる可能性があるためです。1つにまとめた「応答時間」の値ではなく、生のタイミングを保持してください。

最も目立つモデルではなく、繰り返し発生する最大の区間を最適化します。エンドポイント検出が支配的ならターン検出を調整し、ツールが支配的なら安全なデータだけを先読みし、TTSから最初の音声が出るまでに遅れがあるならバッファリングとスピーカーの起動を調べます。意図的な安全対策は性能上の失敗ではないため、確認による遅延は明示的に扱ってください。