いちばん遅い工程を丸ごと差し替えた

まず Cerebras が何者かをはっきりさせます。そうしないと「35 倍」という数字の真偽を判断できません。

AI チップの会社ですが、NVIDIA とはやり方が違います。他社はウェハー 1 枚を数百個のチップに切り出してつなげて使う。この会社は切らず、ウェハー 1 枚をそのまま巨大な 1 個のチップにします。利点は、データをチップ間で行き来させずに済むこと。モデルの重みをオンチップメモリに直接置けるので、読み出しが格段に速くなります。学習には向きませんが、推論——つまり学習済みモデルに文字を吐かせる用途では非常に高速です。ここ数年の商売も、その速度を売ることが中心です。

音声 AI は、あなたの声を聞いてから返事を発するまでに 4 つの工程を通ります。いちばん遅いのは真ん中、答えを考える工程です。前後の 3 つがどれだけ速くても、ここに足を引っ張られます。

Hugging Face と Cerebras は、この工程を Cerebras の推論ハードに任せました。モデルは Google DeepMind がオープンウェイトで公開した Gemma 4 31B です。

35 倍になれば、たまに起きる大きな引っかかりも消えます。これが P95 レイテンシ改善の直接の理由です。答えを考える工程の所要時間が極小になれば、パイプライン全体のばらつきも自然に小さくなります。

ついでにモデルの「思考」もオフにしています。接続コマンドに --responses_api_reasoning_effort none が入っているのがそれです。同じモデルでもコードを書くときは思考を入れたほうが賢い。会話では、切らないと話す速さに追いつけません。

Gemma 4 31B は当サイトで 2 度取り上げました。今回は別の顔で登場します——オープンソースのパイプラインから、いつでも外して差し替えられる「脳」として。

あちらのモデルは持ち出せない、こちらは持ち出せる

この技術の価値を理解するには、まず Doubao や GPT-Live とは土俵がまったく違うと知る必要があります。あちらが競うのは「どれだけ人らしく話せるか」。こちらが競うのは「そのモノが誰のものか」です。

まずあちら側。リアルタイム全二重の音声はもう珍しくありません。Doubao の音声モデルは 2.0、3.0 の頃からリアルタイム双方向対話に対応し、今年 4 月にはネイティブ全二重の Seeduplex をアプリ全体に展開。OpenAI は 7 月に GPT-Live を発表し、こちらが話している最中から応答します。Gemini の Live API はもっと直接的で、音声が入って音声が出る。認識・大規模モデル・合成という 3 工程が途中に存在しません。

この種のモデルには、生まれつき会話のリズムがあります。聞きながら相槌を打てるし、相手が言葉を探して黙っただけで、まだ割り込むべきでないことも判断できます。Gemini 側には Proactive Audio というスイッチがあり、オンにするとモデル自身が話すべきかを決め、ずっと黙って聞き役に回ることもできます。ByteDance が Seeduplex を公開したときの数字では、誤った割り込みが半減、会話のかぶりが 40% 減となっています。

Hugging Face のこちらは従来型です。4 工程のリレーで、認識・思考・合成がそれぞれ 1 区間を担当します。半二重なので、同じ瞬間に聞くか話すかのどちらかしかできません。こちらが割り込めば黙りますが、話している最中に「うん」と相槌を打つことはできません。

ですから「人らしく話す」点では Doubao や GPT-Live に敵いません。しかもこの差はアーキテクチャが決めているので、埋めきれません。

ただし勘定にはもう半分あります。あちら 3 社がどれだけ上手に話せても、あなたは借りているだけです。モデルは相手のサーバーにあり、あなたが叩くのは API。ネットが切れれば終わりですし、値上げや規約変更、機能の停止があっても従うしかありません。こちらは逆で、モノがあなたのものになります。

では強みはどこか

「モノがあなたのもの」を具体化すると、1 枚のライセンスに行き着きます。このパイプラインの 4 工程は、真ん中の脳である Gemma 4 31B も含めてすべて Apache 2.0。商用利用も、改変も、再配布も、誰の許可も要らないという意味です。

実際に何が手に入るのか、4 つあります。

同じクライアントコードのまま、接続先を自前サーバーに変えるだけで会話は続く。出典は huggingface/speech-to-speech リポジトリのドキュメント

以降のセクションは、その「届かない箇所」をどう埋めるかの話です。

フライングでテンポ差を埋める

半二重の一問一答は、聞きながら話せる方式に構造上かないません。このパイプラインの対策はフライングです。話し終わるのを待たずに考え始め、この先が大きくは変わらないほうに賭けます。以下の 3 つは一続きの仕組みです。

話し終わるのを待たずに考え始める

ハードで「答えを考える」工程を圧縮すると、残った遅延の大半が意外な場所に移ります。話し終わったかどうかの判定そのものに、時間がかかるのです。

機械は無音の長さを数えて発話の終わりを判断します。あなたが止まると数え始め、規定に達してようやく動き出す。この待ち時間には何の仕事も入っておらず、純粋な確認作業です。かといって短くしすぎると、息継ぎのたびに割り込まれます。

下のタブを切り替えて、時間がどこに使われているか見てください。

確認の時間を削ったのではありません。作業の時間を待ち時間の中に隠したのです。

超高速なハードが要る理由もここにあります。答えはこの 1 秒以内に出し切らねばならず、そうでなければ結局待つことになる。思考をオンにすると即座に予算を超えるので、切るわけです。

一言足すと、全部やり直す

フライングで怖いのは、外したまま押し通すことです。この実装は丸ごと破棄します。

その 1 秒の間にまた話し出せば、この版は無効。続きだけを推測して繋ぐことはせず、前半の録音を残したまま新しい発話と 1 つの文につなぎ、最初から転写し直し、生成し直します。だから答えの品質は落ちません。モデルが見るのは常に完全な一文です。

代償は、言い直すたびに全部やり直すこと。途切れ途切れに 4 回止まれば、裏では 4 周が無駄になります。ハードが安くて速いことが、ここでとりわけ効いてきます。

言い足しのための細かい配慮もあります。新しい発話を始めるには 384 ミリ秒の音声検知が必要で、咳払いでの誤作動を防ぐため。一方、前の発話の続きなら 192 ミリ秒で済み、しきい値は半分です。あなたの沈黙を「まだ話している」側に倒す設計になっています。

話し出したら、そのターンは確定

言い直せるかどうかは、時間の長さではなく 1 つの動作で決まります。合成モジュールが音を出し始めた瞬間にそのターンは確定し、以降の発話はすべて新しいターン扱い。確定前なら最長 7 秒の間、何度でもやり直せます。言葉を探す、息を継ぐ、途中で止めて言い足す——それには十分です。

話している最中に割り込めば、即座に黙る

前節はまだ話し出す前の言い直しでした。ここは、話している最中に直接割り込むケースです。

難しいのは、割り込んだ瞬間、4 つのスレッドのあちこちに作りかけが散らばっていることです。モデルはまだ文字を吐き、合成は音声ブロックを切り出し、送信ループは耳へ押し出し続けている。1 つずつ追いかけて止めるのは遅いうえ、取りこぼしも起きます。

割り込みはオフにもできます。オフでも発話は転写されますが、AI は止まらず、手元の一段を話し切ります。電話サポートの定型アナウンス、ロボットの安全案内の読み上げなど、こうした場面で使えます。

導入すると、こんなことができる

導入はコマンド 3 つ

まずサーバーを起動し、別のターミナルから接続して話します。

pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech

ここで OpenAI の key が要るのは、引数を渡さない場合、真ん中の工程が標準で OpenAI の gpt-5.4-mini に繋がるからです。今回の主役に替えるには、モデル名と接続先を指定するだけです。

speech-to-speech \
    --mode realtime \
    --stt parakeet-tdt \
    --llm_backend chat-completions \
    --tts qwen3 \
    --model_name "google/gemma-4-31B-it:cerebras" \
    --responses_api_base_url "https://router.huggingface.co/v1" \
    --responses_api_api_key "$HF_TOKEN" \
    --responses_api_reasoning_effort none \
    --responses_api_stream

python scripts/listen_and_play_realtime.py --host 127.0.0.1 --port 8765

発話を外に出したくない場合は、真ん中の工程もローカルに置けます。片方のターミナルで llama.cpp が小型 Gemma 4 をホストし、もう片方でパイプラインをそちらに向けます。

# ターミナル 1：llama.cpp で Gemma 4 をホスト
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536 -fa on --swa-full

# ターミナル 2：音声パイプラインをこのローカルサーバーへ
speech-to-speech \
    --mode realtime \
    --stt parakeet-tdt \
    --llm_backend responses-api \
    --tts qwen3 \
    --model_name "ggml-org/gemma-4-E4B-it-GGUF" \
    --responses_api_base_url "http://127.0.0.1:8080/v1" \
    --responses_api_api_key "" \
    --responses_api_stream \
    --enable_live_transcription

先に知っておきたい制約

リポジトリ自身が制約を列挙しています。導入前に目を通しておくとよいでしょう。

いちばん直接効くのは、標準の音声認識がヨーロッパ系 25 言語しか扱えないこと。日本語も中国語も入っていないので、Whisper か Paraformer に差し替える必要があります。下のコマンドは Apple Silicon の Mac 専用で、ついでに真ん中の工程もローカルの小型モデルに置き換えています。他の OS では speech-to-speech[faster-whisper] か [paraformer] を入れ、対応する引数を指定してください。

speech-to-speech \
    --stt whisper-mlx \
    --stt_model_name large-v3 \
    --language zh \
    --llm_backend mlx-lm \
    --model_name mlx-community/Qwen3-4B-Instruct-2507-bf16

インストール時につまずく箇所も 2 つあります。オプションの音声強調モジュールは numpy 1.x、Pocket TTS は numpy 2.x を要求し、両立しません。Linux では標準の音声合成パッケージが CUDA 12.8 を前提としており、合わない場合は対応版を先に入れる必要があります。リポジトリは CUDA 13、12.4、CPU のみの 3 種類の入手先を用意しています。

インストールせずに試したい場合は、オンライン版を開けばすぐ話せます。無料枠は協定世界時で毎日リセット。未ログインで 5 分、ログイン済みの一般ユーザーで 10 分、PRO 会員と指定組織のメンバーは無制限。ローカル実行は計測対象外です。

4 工程のうち最も遅いのは真ん中、答えを考える工程です。前後の 3 つが速くてもここに引きずられる。今回の変更は、この工程を Cerebras の推論ハードに任せたこと。あの会社はウェハーを小さなチップに切らず、1 枚をそのまま巨大チップにするので、モデルの重みをオンチップに置けて出力が格段に速い。同時にモデルの「思考」をオフにします。コードを書くときは思考ありのほうが賢いのですが、会話では話す速さに追いつけません。

変えたのは引数 2 つだけ。このパイプラインはどの工程もこの調子で差し替えられます。認識を Whisper に、合成を Kokoro に、答えを考える工程をローカルの llama.cpp に、といった具合です。ただしハードで圧縮した後、残った遅延の大半が意外な場所に移ります。話し終わったかの判定そのものに、時間がかかるのです。

機械は無音を数えて発話の終わりを判断します。止まると数え始め、規定に達してようやく動く。この間は何の仕事もしていません。短すぎれば息継ぎで割り込まれる。このパイプラインの答えは「確認」と「作業」を重ねること。無音 64 ミリ秒で発話終了とみなし、認識と思考をすぐ走らせ、出た答えは 1 秒伏せて言い直しの余地を残します。

「35 倍速い」ではピンと来ません。同じ作業に換算します。60 字の返答を考えるのに、両者は何秒かかるか。

導入は pip install speech-to-speech の一行。ウェブ版はマイクを許可すればすぐ話せて、未ログインで毎日 5 分、ログインで 10 分が無料。制約を 2 つ先に。標準の認識はヨーロッパ系 25 言語のみで、日本語や中国語は Whisper か Paraformer に差し替えが必要。標準では同時 1 人しか使えず、チームで使うならパイプライン数を自分で増やす必要があり、1 本ごとにモデル分のメモリを食います。