爆速400ms！スクラッチで開発した超低遅延音声エージェントの舞台裏：STT・LLM・TTSを極限まで削ぎ落とす手法

ゼロから音声エージェントを構築し、エンドツーエンド（ユーザーの発話終了から応答の最初の一音まで）で平均約400msという驚異的なレイテンシを実現しました。STT → LLM → TTSのフルループを回し、自然な割り込み（barge-in）にも対応。事前生成された回答は一切使っていません。\n\nパフォーマンス向上の鍵となったポイント：\n\n1. 音声対話は「ターン制」の制御がすべて： VAD（音声区間検出）だけでは不十分です。意味論に基づいた「発話終了検知」が必要になります。\n\n2. ループの単純化： システムは「話す」か「聞く」かの1つのループに集約されます。「割り込み時に即座にキャンセルする」「発話終了時に即座に返答する」という2つの遷移が、ユーザー体験の質を決定づけます。\n\n3. ストリーミングの徹底： STT → LLM → TTSは必ずストリーミングで繋ぐ必要があります。一つずつ処理を待つシーケンシャルなパイプラインでは、自然な会話は到底不可能です。\n\n4. TTFT（最初の1トークン）が命： 音声において、最初のトークンを出すまでの時間がクリティカルパスとなります。Groqによる約80msのTTFT（Time to First Token）が最大の勝因でした。\n\n5. プロンプトよりも地理的配置： サーバーの地理的な近さが、プロンプトの工夫よりも重要です。すべてのコンポーネントを同じ場所に配置しなければ、開始する前から負けているも同然です。\n\nGitHubリポジトリ:\nhttps://github.com/NickTikhonov/shuo\n\n最新の開発状況はこちら:\nhttps://x.com/nick_tikhonov

かなり刺激的なブレイクスルーだね。これ、ゲームエンジンのネットコードが進化してた初期の頃を思い出すよ。レイテンシは（モデルの問題じゃなくて）オーケストレーションの問題だから、アグレッシブに同じ場所に配置してパイプライン化すれば、汎用フレームワークにも勝てる。カーマックの2013年の「Latency Mitigation Strategies」って論文[0]でもVRについて同じことが言われてた。数ミリ秒の遅延がパイプラインの各ステージに隠れてて、自分でフルパスをトレースして初めて見つかるんだ。TTSのWebSocketプールをウォーム状態で保持して300ms削ったのはナイス発見だし、まさにその好例だね。

もしくは、Soniox Real-time（60言語対応）を使う手もあるよ。ネイティブでエンドポイント検出をサポートしてて、ユーザーの発話が終わったタイミングを判断するようにモデルが訓練されてるんだ。これはVAD（音声区間検出）よりもずっと精度が良い。SonioxはPipecatを作ってるDailyが行った独立ベンチマークでも勝ってるし、ホームページでデモも試せる。免責事項：以前Sonioxで働いてた。追記：コメントするのが早すぎた。VADっていう文字を見て、去年リアルタイムのエンドポイント検出を一番に実装したSonioxのことを即座に思い出しちゃったんだ。

良いまとめだね、シェアしてくれてありがとう。君が自作したPythonプログラムは、pipecatやlivekit agentsみたいなフレームワークと比べてどう？あっちも同じPythonで書かれてるけど。

「音声はオーケストレーションの問題だ」っていうのは基本的には正しいね。個人的に気になったのは2点。1. 単一の言語に絞ればもっと最適化できるんじゃないか？ 2. 干渉の問題をどう解決するか。人間は複数の会話やテレビ、音楽が流れてる中でも聞き分けるのが得意だけど、ノイズの多い環境での音声認識はまだあんまり上手くいった試しがないんだ。

個人的にはSTT -> LLM -> TTSっていう構成は行き止まりだと思う。未来はエンドツーエンド（E2E）にある。2年前にこれをいじって、ゲーミングGPUにローカルでインストールできるデモまで作ったけど、実用的なものにするにはE2Eモデルの訓練が必要だって結論になった。すごく面白い課題だし取り組みたいけど、個人のサイドプロジェクトの予算じゃ足りないな。

やあ、みんな！このHandyってアプリをチェックしてみて。完全にオフラインで動く、フリーでオープンソースな拡張性の高い音声文字起こし（STT）アプリなんだ。毎日Claudeを動かすのに使ってるけど、すごく調子いいよ（macOSの音声入力モードよりずっとマシ）。

素晴らしい解説だね、ありがとう！LLMのレイテンシに関しては、OpenAIが最近ResponsesクライアントでWebSocketを導入したから、少し速くなってるはず。別の方法としては、デバイス上で極小のLLMを動かす手もある。自分でも完全にローカルなパイプラインを組んでみたけど、ストリーミングも最適化もなしでRTT（往復時間）は1秒を切ったよ。

このボイスエージェント（STT -> LLM -> TTS）みたいに、完全にオフラインで動くオープンソースのプロジェクトを誰か知らないかな？

これについては21日前にもかなり詳しく議論されてたよ。

「音声は発話交代（ターンテイキング）の問題だ」：音声に関しては、まだ誰も活用してない「すぐ手の届く成果（low hanging fruit）」がある気がする。それはフィラー（相槌）とペース配分。LLMが沈黙を察知したら、本物の回答を生成してる間に文脈に合った相槌を入れるんだ。単に「ふむふむ」とか「なるほど」とかね。それだけでやり取りがずっと会話っぽくなるし、もし話し手がまだ話し終わってなくても「ユーザーの話に被せてしまうダメな挙動」にならずに済む（相槌を打ってから、そのまま聞き続ければいいからね）。