Gemma 4 × Cerebras でリアルタイム音声AIを触ってみた

Hugging Face のブログに Gemma 4 と Cerebras を組み合わせたリアルタイム音声AIのデモ記事が上がっていた。読んですぐ手元で動かしてみたのでメモを残しておく。

アーキテクチャはこういう構成になっている。

音声入力 → NVIDIA の Parakeet で ASR
Gemma 4 31B (Cerebras 推論) で LLM 処理
Alibaba の Qwen3TTS でテキスト→音声

それぞれのコンポーネントが差し替え可能な cascaded パイプラインになっている点がえぐい。自分のユースケースに合わせて ASR だけ swap したり、TTS を別モデルにしたりできる設計だ。

レイテンシの話が刺さった

記事の中でいちばん気になったのは P95 レイテンシの話だ。今の production システムでも median はそこそこ出るけど、P95 で数秒の遅延が残るケースがあると書かれていた。これはリアルにわかる。自分が最近触っている音声系の個人開発でも、median が 800ms くらいでも tail が 3〜4 秒に跳ねることがあって、そのたびに「会話が死ぬ」感覚になる。

Cerebras を使う動機がコスト削減ではなくレイテンシの安定化だと明言しているのも正直な記述で好感が持てた。普通こういうの「コスパ最高」みたいな書き方をしがちだけど、ちゃんと「predictable performance が目的」と書いている。

もうひとつ印象的だったのが Reachy Mini の話だ。この speech-to-speech パイプラインはすでに 9,000 台超のロボットに載っているらしい。デモ用のハリボテじゃなくて本番で使われているということで、実装の信頼度がグッと上がった。

自分のコードへの影響を考えた

今の個人開発では OpenAI の Whisper API + GPT-4o + 別途 TTS という構成で動かしていた。毎月 API コストが地味にかかっていて、しかも GPT-4o 経由だと tool call が入ったターンで tail レイテンシが跳ねる問題をずっと放置していた。

huggingface/speech-to-speech リポジトリを clone してざっと見たところ、環境構築は Python の依存を入れるだけでそんなに複雑ではなかった。

git clone https://github.com/huggingface/speech-to-speech
cd speech-to-speech
pip install -r requirements.txt
python s2s_pipeline.py --recv_host 0.0.0.0 --send_host 0.0.0.0

Cerebras の inference endpoint は Hugging Face の Inference Providers 経由でアクセスできるようになっていて、API キーを差すだけで Gemma 4 31B を叩ける。自前でモデルを立てなくていいのはありがたい。Gemma 4 は VLM なので将来的に画像や映像を流し込む拡張もやりやすい構成だ。

彼女とよく「なんでスマートスピーカーってあんなに会話がぎこちないの」という話をするんだけど、今回のデモ動画を見せたら「これなら普通に話せそう」と言っていた。レイテンシが体験に与える影響をエンジニア以外の人間が感覚的に理解できるくらい差が出ているということだ。

現状の自分の構成だと ASR に Whisper large-v3 を使っていて、ここが遅延の割合として結構でかい。Parakeet に切り替えたらどこまで変わるか検証してみたい。モデル自体は NVIDIA が公開しているもので、HuggingFace Hub にも上がっているのでそのまま使える。

次にやること

とりあえず今週末に自分の音声パイプラインを huggingface/speech-to-speech ベースに移行してみる。ASR を Parakeet、LLM を Cerebras 上の Gemma 4、TTS を Qwen3TTS に統一して、現状構成と P50・P95 のレイテンシを比較するつもりだ。Cerebras の料金体系も確認して、今の OpenAI コストと比べてどっちが安いかも見る。

モジュール構成が綺麗に分離されているので、自分のプロジェクトに組み込む際に LLM 部分だけ差し替えるのも難しくなさそうだ。まずは手を動かして数字を出す。それが一番早い。