音声で話しかけて返事が返るまでの数百ミリ秒。この「間(ま)」がほんの少し伸びるだけで、対話AIは途端に機械と喋っている感触になる。逆にここが詰まると、会話は不思議と生き物めいてくる。Hugging FaceとCerebrasが7月1日に公開した speech-to-speech は、その間を実用域まで縮めた音声エージェントを、全段が入れ替え可能なオープンソース部品で組めるようにしたものだ。派手な新モデルではない。だが「話して答える体験」を自分の手で組み立て、中を全部見られる、という点がこれまでになかった。しかも同じスタックは既に9,000台を超えるロボットで動いている。
出典はHugging Faceの公式ブログとリポジトリ、そしてローカル版の解説記事の3本を突き合わせた。
🎙️ 体感を決めているのは、真ん中のLLM
音声対話は一枚岩に見えて、中身はいくつかの処理を数珠つなぎにした「カスケード(cascade)」で動いている。マイク入力から順に、こういう流れだ。
| 段 | 役割 | 既定のモデル |
|---|---|---|
| VAD | 発話区間検出(いつ話し始め・話し終えたかの判定) | Silero VAD v5 |
| STT | 音声認識(音声→テキスト) | Parakeet-TDT 0.6B v3(NVIDIA) |
| LLM | 応答文の生成 | Gemma 4(Google DeepMind) |
| TTS | 音声合成(テキスト→音声) | Qwen3-TTS(Alibaba) |
このうち体感遅延を支配するのはほぼLLMだ。VADやSTTは軽くCPUでも回るし、TTSはストリーミングで先頭から喋り出せる。ところがLLMは、返答を1トークンずつ生成し終えるまで文が確定しない。生成が遅ければ、その分だけ相手を待たせる。カスケード設計で厄介なのは、各段の遅延が足し算で積み上がることで、真ん中が詰まると全体が破綻する。公式ブログもそこを率直に「音声AIにとってレイテンシは決定的なパラメータだ」と言い切っている。
面白いのは、この4段のどれもがベンダーの違う独立したオープンモデルで構成されている点だ。認識はNVIDIA、生成はGoogle、合成はAlibaba。垂直統合の逆を行っていて、各段でその時点の最良を選べる。
🧩 コマンド1つで動き、フラグ1つで入れ替わる
導入はPythonパッケージ1つで済む。既定構成ならこれで対話ループが立ち上がる。
pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech
肝は、4段それぞれをCLIフラグで差し替えられることだ。認識をFaster Whisperに、合成をKokoroに変える、といった操作が設定ファイルを触らず一行で通る。
speech-to-speech --stt faster-whisper --tts kokoro
--stt には parakeet-tdt(既定)や whisper、paraformer、--tts には qwen3(既定)や kokoro、chattts などが並ぶ。LLMは --llm_backend でOpenAI互換API・ローカルのTransformers・MLXを切り替える設計になっている。
クラウドを一切使わず手元で完結させることもできる。llama.cppでGemma 4を立て、そこに向けて喋りかける構成がREADMEに載っている。
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536 -fa on --swa-full
speech-to-speech \
--model_name "ggml-org/gemma-4-E4B-it-GGUF" \
--responses_api_base_url "http://127.0.0.1:8080/v1" \
--responses_api_api_key ""
Apple Silicon向けには --local_mac_optimal_settings という一発設定も用意されていて、M系チップならQwen3-4Bクラスが「即応」で動くとされる。ローカル版の解説記事は利点を3つに整理している。音声がネットワークの外に出ない(プライバシー)、従量課金がない(コスト)、そしてVAD/STT/LLM/TTSのどれでも差し替えられる(柔軟性)、だ。
⚡ なぜLLMの段だけCerebrasなのか
Hugging Faceが公開したデモ構成では、LLMの段にCerebrasの推論基盤でGemma 4を載せている。前述のとおりカスケードの遅延はLLMが握る。Cerebrasはウェハースケール(1枚のシリコン全体を1つのチップにする方式)の推論で高いトークン毎秒を出すことで知られ、まさにその一段の詰まりを抜くための選択だ。ブログはこう書いている。
ロボットや音声アシスタント、身体を持つAIにとって、応答性は見た目の改善ではない。それこそが対話を「生きている」と感じさせるものだ。
ここでの設計判断は示唆的だ。全段をローカルの小型モデルで固めれば安くて閉じているが、生成品質と速度は頭打ちになる。逆にLLMだけを高速なクラウド推論に外出しすれば、認識・合成は手元に置いたまま、応答の切れだけを買える。カスケードが部品ごとに独立しているからこそ、こういう「一段だけ課金する」使い分けが素直に書ける。
カスケードに賭けたことの意味
音声対話には、もう一つの潮流がある。音声を途中でテキストに落とさず、音のまま入出力する「ネイティブ音声(end-to-end)」型のモデルだ。理屈の上ではこちらが速く、声の抑揚や割り込みといった言葉にならない情報も保てる。ではなぜHugging Faceは、あえて古典的なカスケードを選んだのか。
答えは中身が見えることにある、と私は読む。カスケードなら各段の入出力がテキストや区間として観測でき、どこで認識を誤ったか、どの段が遅いかを切り分けてデバッグできる。段ごとに最良のモデルを差せるし、多言語対応もSTT/TTSを言語別に選ぶだけで済む。ネイティブ音声モデルの滑らかさと引き換えに、実務で効く「観測性」と「交換可能性」を取った格好だ。プロダクトを運用する側からすると、ブラックボックスの一枚岩より、壊れた段だけ取り替えられる構成のほうが圧倒的に扱いやすい。
その主張の裏付けが、9,000台超で稼働するHugging Faceのオープンソース卓上ロボット Reachy Mini だ。デモでCerebras版として見せた同じパイプラインが、ロボット上ではローカル完結版として動く。クラウドで速さを買う構成と、手元で閉じる構成が、フラグの違いだけで地続きになっている。ここが今回いちばん重要な点だと思う。「話して答える」を、特定ベンダーのAPIに縛られず、要件(速度・コスト・プライバシー)に応じて自分で組み替えられる土台が、pip一発の距離に来た。音声エージェントを検討しているなら、まず既定構成を立ち上げて各段を1つずつ差し替えてみるのが、この設計思想を体で理解する近道になる。