ローカルLLMは音声対話に向かないのか──「1〜2秒」の壁をハードウェアごとに検証する

音声で対話するAIアシスタントを、クラウドを一切経由せず、自分のPC・Macだけで完結させる。この構成は「音声認識（STT）→ローカルLLM→音声合成（TTS）」という3層のパイプラインで実現できる。問題は、この3層を経由する間にどれだけ「間」が空いてしまうかだ。技術ブログPromptQuorumが2026年6月19日に更新した詳細な構築ガイドから、ハードウェアごとのレイテンシの実態を確認する。

3行まとめ

1. PromptQuorumの実測によると、STT→LLM→TTSのオフライン音声対話パイプラインのエンドツーエンドレイテンシは、デスクトップGPU（RTX 3060）やMac Mini M5で1〜2秒、Raspberry Pi 5では5〜8秒とハードウェアで大きく変わる
2. ボトルネックはLLMの初回トークン生成（0.5〜1.5秒）で、文単位でTTSをストリーミング開始する最適化により体感レイテンシを0.3〜0.7秒縮められるという
3. ただしPromptQuorumが推奨する「Llama 3.3 8B」について、Ollama公式のモデルカードを確認すると実在するのは70B版のみで、公式が明記する対応言語8つの中に日本語・中国語は含まれていない──ブログの記述と一次資料の間に食い違いがあった

3層構成という前提

記事はまず、完全オフラインの音声アシスタントを構成する3つの独立したレイヤーを説明する。

• レイヤー1（音声認識）：whisper.cpp または faster-whisper。マイク音声をテキストに変換する
• レイヤー2（推論）：Ollamaで動かすLlama 3.3 8B、Phi-4、Mistral Smallなど。文字起こしされたテキスト・会話履歴・システムプロンプトを受け取り、応答を生成する
• レイヤー3（音声合成）：Piper または Coqui TTS。LLMの応答テキストを音声に変換しスピーカーで再生する

これら3つをつなぐのが、マイクからの音声取得→STT→LLM→TTS→再生という流れを実装するPythonのオーケストレータだ。

ハードウェア別のレイテンシ実測

記事が示す最大のポイントは、ハードウェアのグレードによってエンドツーエンドのレイテンシがどれだけ変わるかという実測データだ。

記事はこの数字をこう位置づけている。

"End-to-end latency on a desktop GPU (RTX 3060 12 GB): 1–2 seconds. This is comparable to Alexa and Google Assistant — the latency threshold for 'feels natural' in voice interaction."

デスクトップGPU構成の1〜2秒というレイテンシは、AlexaやGoogle Assistantに匹敵し、これが音声対話で「自然に感じられる」しきい値だという。一方でRaspberry Pi 5については「usable for hands-free queries where the user accepts a longer pause, not for conversational interaction（ユーザーが長めの間を許容できるハンズフリークエリには使えるが、会話的なやり取りには向かない）」と明確に線引きしている。

記事はMac Mini M5を「質と静音性の両立という点でのスイートスポット」と評しており、アイドル時は無音・ファンレスでありながら、Metal経由でLlama 3.3 8Bを毎秒約50トークン、Whisper large-v3をリアルタイムの10倍速で処理できるとしている。

レイテンシの内訳：どこで時間が食われるか

記事は、1〜2秒という合計時間がどの層にどれだけ配分されるかも分解している。

"STT adds 0.2–0.5 sec, LLM first-token latency adds 0.5–1.5 sec, TTS adds 0.1–0.3 sec — total 1–2 seconds on a desktop GPU."

STTが0.2〜0.5秒、LLMの最初のトークンが出るまでが0.5〜1.5秒、TTSが0.1〜0.3秒。ボトルネックは明確にLLMの初動時間だ。

体感速度を上げる最大の一手：LLMとTTSの並行実行

記事が最も効果的な最適化として挙げるのが、LLMの出力を待ちきってからTTSを開始するのではなく、文単位でストリーミング処理する手法だ。

"Stream the LLM output token-by-token. Start TTS on each completed sentence (end of sentence detected by period/question mark). This reduces perceived latency by 0.3–0.7 seconds — the user hears the start of the answer while the LLM is still generating the end."

LLMの出力をトークンごとにストリーミングし、文の区切り（句点・疑問符）を検出するたびにTTSを開始する。これにより体感レイテンシが0.3〜0.7秒短縮される。ユーザーは、LLMがまだ文の後半を生成している間に、応答の冒頭を聞き始められる。

モデル選定の指針

記事が推奨するLLMは、Llama 3.3 8B（推奨）、Phi-4（より軽量で16GB RAM機に向く）、Mistral Small（Llama 3.3 8Bに匹敵する品質）。量子化はQ4_K_Mが速度と品質のバランスとして推奨されている。音声対話向けのシステムプロンプトについては、「応答は1〜3文までに抑える」「箇条書き・Markdown・装飾は一切使わない」「会話のように自然に話す」という指示が例示されている。応答の長さを--num-predict 100〜150で制限することも、TTSにかかる時間を減らし不自然さを避けるために推奨されている。

一次資料で確認すると、「Llama 3.3 8B」の対応言語の記述に食い違いがあった

PromptQuorumの記事は推奨LLMとして繰り返し「Llama 3.3 8B」を挙げているが、Ollama公式のモデルカード（ollama.com/library/llama3.3）を直接確認すると、そこに記載されているのは次の内容だ。

"The Llama 3.3 instruction tuned text only model is optimized for multilingual dialogue use cases [...] Supported languages: English, German, French, Italian, Portuguese, Hindi, Spanish, and Thai."

（訳）「Llama 3.3の指示チューニング済みテキスト専用モデルは、多言語対話ユースケース向けに最適化されている。〔中略〕対応言語：英語、ドイツ語、フランス語、イタリア語、ポルトガル語、ヒンディー語、スペイン語、タイ語」

モデルの説明文にも「70B（text in/text out）」という記載があり、ページ全体を確認した範囲では8Bサイズへの言及は見当たらなかった。つまりOllama公式のモデルカード上では、Llama 3.3は70Bという1サイズのみで公開されており、公式が明記する対応言語8つの中に日本語・中国語は含まれていない。PromptQuorumの記事にあった「Llama 3.3 8Bは英語・フランス語・ドイツ語・スペイン語・イタリア語・ポルトガル語、および一部の日本語・中国語に対応する」という記述とは、モデルサイズ・対応言語の両方で食い違いがある。この食い違いの原因（記事側の誤記なのか、別の派生モデルを指しているのか）までは本記事では特定できていない。日本語での音声対話パイプラインを組む場合、LLM層のモデル選びはこの記事の推奨をそのまま採用せず、使うモデルの公式ページで対応言語を確認し直すことを勧める。

Whisperの日本語精度は「WER」でなく「CER」で公式評価されている

STT層に使われるWhisperについても、OpenAI公式のGitHubリポジトリを確認した。README内の説明はこうだ。

"Whisper's performance varies widely depending on the language. The figure below shows a performance breakdown of large-v3 and large-v2 models by language, using WERs (word error rates) or CER (character error rates, shown in Italic) evaluated on the Common Voice 15 and Fleurs datasets."

（訳）「Whisperの性能は言語によって大きく異なる。以下の図は、Common Voice 15とFleursデータセットで評価した、large-v3・large-v2モデルの言語別の性能内訳を、WER（単語誤り率）またはCER（文字誤り率、斜体で表示）で示したものだ」

つまりOpenAI自身が、日本語のような単語の区切りが明確でない言語については、単語単位の誤り率（WER）ではなく文字単位の誤り率（CER）で評価する、という使い分けをしていることが公式READMEから確認できる。具体的な数値は図（画像）として掲載されており、本記事では画像内の日本語の数値までは読み取れていない。なおREADMEのコマンド例にはwhisper japanese.wav --language Japaneseという日本語音声を明示的に指定する使用例が掲載されており、日本語が公式にサポート対象言語として扱われていること自体は確認できる。

TTS層のPiperについても、GitHub公式リポジトリ（OHF-Voice/piper1-gpl、★5,316）のREADMEを確認したが、対応言語の一覧や日本語音声モデルへの言及は、本記事が確認した範囲のREADME本文には見当たらなかった。PromptQuorumの記事がPiperを前提にしている一方、日本語の音声合成には別エンジンが必要になりそうだという状況が、Piper側の一次資料からも間接的にうかがえる。

日本語話者にとっての意味：VOICEVOXという選択肢

この記事はPiper（英語圏で主流の軽量TTS）を前提にしているが、日本語の音声対話パイプラインを組む場合、TTS層にVOICEVOXを充てる構成が広く使われている。VOICEVOXはCPUモードとGPUモードを切り替えられるため、GPUリソースをLLMやWhisperに集中させたい場合はCPUモードで動かす、という設計判断も可能だ（VOICEVOXの技術的な仕組みについてはVOICEVOXの音声合成の仕組みを参照）。3層構成の基本的な考え方（STT→LLM→TTSのパイプライン、ストリーミングによる体感速度の改善）は、TTSエンジンをPiperからVOICEVOXに置き換えても変わらないはずだが、この点についての日本語環境での実測データは、本記事のソースには含まれていない。

結論：「向かない」のではなく「ハードウェア次第」

「ローカルLLMは音声対話に向かないのか」という問いへの答えは、この記事のデータを見る限り「向かない」ではなく「ハードウェア構成次第」というのが正確だ。約$600〜800クラスのMac Mini M5・デスクトップGPU構成であれば、商用アシスタントに匹敵する1〜2秒台のレイテンシが実現できる一方、$100クラスのRaspberry Pi構成では5〜8秒かかり、会話的な用途には厳しい。ローカルLLM全般の基礎知識はローカルLLMとは何か、音声認識の精度・仕組みについてはWhisper文字起こしガイドも参照してほしい。

根拠は商用ブログ1本、宣伝色のある記事

• 本記事はPromptQuorumという1つの技術ブログの記事を一次資料としている。著者Hans Kuepper氏はPromptQuorum（複数モデルを扱うAIディスパッチツール）の創業者であり、記事自体は同社の他コンテンツへの誘導も含む商業的な文脈のブログ記事である点に留意してほしい。
• 記事で示されたレイテンシ数値は、あくまで記事執筆者が構築・計測した特定の構成（Whisper + Ollama + Piper、特定のモデルバージョン）にもとづくものであり、独立した第三者による再現実験や査読を経たベンチマークではない。
• 本記事のタイトルにある「VOICEVOX的」という切り口について、記事自体はPiperを前提にしており、VOICEVOXを実際に組み込んだ場合のレイテンシ・品質の実測データは、本記事のソースには含まれていない。日本語のSTT精度（Whisperの日本語書き起こし精度）についても、この記事は英語圏を前提にしており、日本語特有の数値は確認できていない。
• 「Llama 3.3 8Bは英語・フランス語・ドイツ語・スペイン語・イタリア語・ポルトガル語、および一部の日本語・中国語に対応する」というPromptQuorum側の記述は、Ollama公式モデルカードの記載（70Bのみ・対応言語8つに日本語中国語含まず）と食い違うことを確認した。この食い違いが生じた経緯（記事の誤記か、コミュニティ版など別モデルを指しているか）は特定できておらず、いずれにせよ日本語での実用性は、この記事の記述だけでは判断できない。