リアルタイム音声対話、パーツ別に直接測定した遅延：音声認識 0.2秒、LLMファーストトークン 0.07秒、音声合成は長さの半分

ステータス：ドラフト（2026-10-06）、実測記事です。 以下の数値は筆者が直接測定した値です。1ターンの最初の音声までの時間は、パーツ別の実測からの 計算された推測値であり、最初から最後まで通して測定したわけではありません。大半の測定は合成音声と1種類の対話プロンプトで行ったため、実際のユーザー環境とは異なる場合があります。4-3節は、人間が読み上げた音声（公開音声コーパス）で音声認識を再度測定した値であり、非ネイティブの英語も含みます。 作成ルール：実測データを基本とし、測定できなかったものは「未測定」と表記します。

目次

• 1. 何をなぜ測定したのか
• 2. 環境と方法
• 3. 音声合成（TTS）結果
  • 3-1. VoxCPM2
  • 3-2. Magpie TTS Multilingual 357M
• 4. 音声認識（ASR）結果
  • 4-1. Qwen3-ASR-1.7B
  • 4-2. Nemotron 3.5 ASR Streaming 0.6B
  • 4-3. 人間の音声で再度測定した値：ネイティブの朗読と非ネイティブの英語
• 5. 対話LLM結果：Gemma 4 12B 4bit
• 6. 測定で判明した問題
  • 6-1. 日本語：音声は合っているのに表記が異なりスコアが下がる
  • 6-2. デプロイされたサーバーが最新コードより古い場合がある
  • 6-3. GPUサーバーごとにドライバーバージョンが異なるとイメージが起動しない
  • 6-4. 測定ツールで直面した罠
• 7. 1ターンの遅延はどれくらいか
  • 発話終了の判定時間はどれくらいであるべきか（朗読音声の実測）
• 8. 面接で聞かれそうな質問
• 確認できなかったこと
• 参考文献
• 確認したバージョンと日付

1. 何をなぜ測定したのか

第19回でオープンソースの候補を調査しましたが、値はすべてドキュメント基準でした。外国語のスピーキング練習に「音声でのやり取り」機能を組み込むには、次の3つのパーツの遅延を直接把握する必要があります。

1. 音声認識（ASR）： 学習者の発話をテキストに変換します。
2. 対話LLM： 書き起こされた言葉に対する返答を生成します。
3. 音声合成（TTS）： 返答を音声として読み上げます。

3つのパーツすべてを韓国語、日本語、中国語、英語で測定し、オープンモデルの2ペア（Qwen3-ASRとNemotron 3.5 ASR、VoxCPM2とMagpie TTS）を同一の入力で比較しました。

2. 環境と方法

2つのモデルペアを 異なるGPU で測定しているため、速度の直接比較には慎重を期す必要があります（メモリ使用量と精度はGPUに関係なく比較可能です）。音声合成は、サーバーが通知する合成時間と音声の長さから リアルタイム係数（合成時間 ÷ 音声の長さ） を算出し、1未満であれば再生よりも速く生成できることを意味します。

3. 音声合成（TTS）結果

3-1. VoxCPM2

ウォームアップ状態（モデルがロードされ、声質がすでに設定された状態）での3回の測定の中央値です。

• 言語に関わらず、合成時間は音声の長さの約半分です。 12の組み合わせ全体でのリアルタイム係数は0.494〜0.582（中央値0.521）であり、同一の組み合わせの3回のばらつきは0.02以内でした。
• 短い文ほど係数がやや大きくなります。 言語ごとに3つの点に直線を当てはめると、合成時間は 音声の長さ × 約0.47 + 約0.23秒（12点全体を基準にすると 0.475 × 長さ + 0.23秒）となり、4言語でほぼ同じ数式になります。文ごとに約0.23秒の固定コストがかかり、それが短い文で割合を大きくしていると解釈できますが、そのコストの正体は何であるかは確認できませんでした。
• サーバーが文全体を合成した後に一度に返す方式です。 最初の音声までの時間がそのまま文の合成時間となり、2〜4秒程度の短い文であれば1.2〜2.1秒です。対話においては、この値が最初の音声を遅らせる最大の要因となります。
• 声色を新しく作成する呼び出しにはさらに3〜3.5秒かかります。 サーバーは声色を一度設計して保存し、以降は複製するため、これは最初の一回のみ発生します。
• GPUメモリを約6,600〜6,900MiB使用します。 モデルのロードには初回起動時のウェイトのダウンロードを含めて385秒かかりました。

3-2. Magpie TTS Multilingual 357M

同じ文で測定しました（8GBクラスのノートPC用GPU、3回の中央値）。

• GPUメモリを追加でわずか約750MiBしか使用しません。 2つのモデルをロードした後の使用量5,832MiBから、音声認識モデルのみをロードした5,078MiBを引いた値です。VoxCPM2のおよそ9分の1です。
• 正常に動作する3言語のリアルタイム係数は中央値0.466（0.447〜0.541）です。 VoxCPM2と同程度かやや低い値ですが、異なるGPUで測定しています。
• 韓国語はこの構成ではそのままでは使用できませんでした（原因と回避策は後述）。 20〜67文字の文が0.4〜4.3秒の音声で終了し（正常であれば4〜13秒）、音声認識に入力すると空の結果が出力されました。モデルカードには韓国語をサポートしていると記載されており、同じ呼び出し方式が英語、日本語、中国語では正常に動作していました。チェックポイントのバージョンが原因ではありませんでした。モデルカードで韓国語が追加されたと記載されているv2607を含め、main、v2607、v2602の3つのチェックポイントを同一環境でテストしたところ、韓国語の3つの文すべてが0.4〜2.1秒（v2602は0.7〜1.3秒）の音声で終了し、書き戻して文字起こしすると文字エラー率は1.00であり、テキスト正規化を有効にしても同様でした。同じ呼び出しで英語は3つのバージョンすべてで正常でした（文字エラー率0.00〜0.07）。正規化を初めて有効にした場合の呼び出しには4.5〜4.7秒かかりました。 原因は、言語コードからトークナイザーを選択するコードにありました。 v2607のチェックポイントは korean_chartokenizer を含めて15個のトークナイザーを所持していますが（韓国語の文をこれでトークナイズすると40トークン）、NeMo 3.0.0の get_tokenizer_for_language は言語コードを内部の表（LANGUAGE_TOKENIZER_MAP）から探し、見つからない場合は english_phoneme にフォールバックしますが、この表に韓国語がないため、 ko, ko-KR, korean がすべて英語の音素トークナイザーにルーティングされてしまいました。韓国語の文が英語の音素トークナイザーを通ると5トークンしか残らず（大部分が不明な文字）、モデルが0.4〜0.8秒で終了してしまったのです（英語、日本語、中国語はそれぞれのトークナイザーにマッピングされて正常）。韓国語に korean_chartokenizer を使用するようにこの関数のみを変更したところ（回避策）、3つの文が3.5、5.8、3.8秒の音声として出力され、音声認識で書き戻した文字エラー率は0.00、0.00、0.05でした。合成時間は1.6、2.7、1.7秒（リアルタイム係数約0.46〜0.47）と他の言語と同等の水準でした。つまり、 モデルとチェックポイントは韓国語をサポートしており、このNeMoのコードバージョンが韓国語を紐付けしていなかったことが原因です。より新しいNeMoでこのマッピングが追加されたかどうかは確認できていません（未確認）。このテストは3つの文を用いたものであり、音声の品質については評価していません。
• 書き戻しエラー率は、合成音声を別の音声認識モデル（Nemotron 3.5 ASR）に入力して原文と比較した値であり、合成品質の大まかな指標に過ぎません。

4. 音声認識（ASR）結果

上記の合成で作成された12個の音声（2〜13秒）を、言語を指定して書き起こさせました。

4-1. Qwen3-ASR-1.7B

• 書き起こしにかかる時間は0.15〜0.6秒、リアルタイム係数は0.04〜0.08です。合成（約0.5）よりも 約10倍高速であり 、ボトルネックにはなりません。
• 言語を指定せず自動検出で実行した場合でも、12個すべて正しく認識されました。
• GPUメモリはモデルのロードによって約5,756MiB増加しました。初回のリクエストには174秒（ウェイトのダウンロードとロードを含む）かかり、推論のみでは6秒でした。

4-2. Nemotron 3.5 ASR Streaming 0.6B

同じ12個の音声（8GBクラスのノートPC用GPU、言語をロケールとして指定、ファイル全体を一度に書き起こす方式）です。

• 書き起こしエラーの例は How was を How is, 三明治 を 三名制, 집 근처에 を 집근처에 として書き起こしたものです。この12個においてはQwen3-ASRの方がより正確であり、Nemotronはより小型でストリーミング向けに作成されたモデルです。
• チャンクサイズ別の精度。 モデルは一度に処理するチャンクを80、160、320、560、1,120msから選択できます。同じ12個で平均エラー率を測定すると、80msで4.3%、160msで4.0%、320msで3.9%、560msで3.9%とほぼ同等で、 1,120msでのみ11.3% へと跳ね上がりました。1つの音声が空の結果になったことが原因ですが（2回測定しても同様）、人間の音声で再測定したところ、韓国語ではチャンクサイズに関わらず空の結果は0件でした（4-3節）。この12個の合成サンプルにおいてのみ現れた現象とみられます。この値はファイル全体に該当の設定を適用した近似値であり、 実際のストリーミング遅延は測定していません。

4-3. 人間の音声で再度測定した値：ネイティブの朗読と非ネイティブの英語

上記の12個は合成音声であり、人間の発音やイントネーションは含まれていません。公開音声コーパスを用いて Nemotron 3.5 ASR を再度測定しました。FLEURS（人間が読み上げた文）から言語ごとに30文、speechocean762（中国語話者が読んだ英語に発音評価スコアが付与されたコーパス）から100文であり、ファイル全体を一度に文字起こしする方式、デフォルトのチャンク1,120ms、8GB級ノートPC用GPUです。

非ネイティブ英語を発音評価の総得点（0〜10）で分けると、エラー率に大きな差が出ました。

• 韓国語の文字エラー率5.8%は、モデルカードのFLEURSの値（7.12%、1.12秒チャンク）と同水準です。サンプルが30文と少ないですが、カードの値と矛盾しませんでした。上記の合成音声12個の平均3.9%（4言語の平均）は、人間の音声の値（韓国語5.8%、日本語14.7%、中国語18.2%）よりも低く、楽観的であったことが確認されます。
• **非ネイティブ英語では、エラー率がネイティブの読み上げ（10.0%）の約4倍（38.8%）**になり、発音スコアが低いほど急激に悪化しました。総得点6未満では中央値が100%、つまりほとんど文字起こしできませんでした。語学学習アプリにおいて初級学習者の発話は最も認識が難しく、それだけフィードバックが必要な発話であるという意味です。人間による評価スコアはコーパスが提供したものです。
• チャンクが小さいほど精度が落ちますが、韓国語ではほぼ同等でした。

英語と非ネイティブ英語は、1,120msから80msに短縮するとエラー率が3〜6%p増加しました。韓国語は5.6〜6.2%とほとんど差がなく、モデルカードの韓国語の値（7.12〜7.70%）もフラットです。空の結果は1,120msでのみ発生せず（非ネイティブ英語はむしろ1,120msで12個と最多）、上記の合成サンプルの1,120ms以上の現象は再現されませんでした。

• 制限事項。 韓国語、日本語、中国語、英語それぞれ30文と、非ネイティブ英語100文の読み上げ音声です。会話体や雑音、韓国人学習者の英語とは異なる母語話者による韓国語は測定していません（未測定）。ファイル全体にチャンク設定を適用した近似値であり、実際のストリーミングでの確定遅延ではありません。

5. 対話 LLM の結果：Gemma 4 12B 4-bit

学習者のレベル（CEFR A2）に合わせて「1〜2文で答え、簡単な質問を1つで終えよ」という指示と、「昨日のカフェで本を読んだ」というユーザーの発話を4つの言語で送信し、言語ごとに5回ストリーミングで受信しました。 最初のトークンはリクエスト送信後最初の文字が返るまで、 最初の文は最初の句読点が出力されるまで（音声合成を開始できる時点）です。

• 最初のトークンは約0.07秒前後、生成は約 85 tok/s です。 サーバー自体の計測結果とも一致しました（入力67トークンの処理95.7ms、すなわち 700 tok/s、生成トークンあたり11.6ms）。
• 最初の文が終了するまでは0.1〜0.2秒です。 英語に最も時間がかかった理由は、最初の文が長いためです。
• 指示に従いました。 20回すべて1〜2文で答え、末尾に質問を付加しました。韓国語の例： 와, 정말 좋았겠네요! 카페에서 책 읽는 건 정말 행복한 일이에요. 어떤 책을 읽었어요? 品質（校正、レベルへの適合）は人間が評価する必要があり、この測定で客観的なのは速度のみです。
• 同時リクエストが増えると最初のトークンが遅くなります。 日本語のプロンプトを同時に送信した場合、2個の場合は0.206秒、4個の場合は中央値0.352秒、最大0.552秒でした（サーバーが同時に2個のみ処理するように制限しているため、残りは待機）。
• GPU メモリは約 8,450MiB を使用しました。 モデルのロードは、ウエイトのダウンロードを含めて145秒でした。

思考モードにより応答が完全に空になりました。 最初の測定では20回すべて回答が空でした。元の応答を確認すると、 content は空文字列であり、 reasoning_content に Role: Friendly conversation partner for a Japanese learner... Constraint 1: ... のような英語の分析が蓄積され、80トークンの予算が思考だけで使い果たされていました。このモデルが llama.cpp のチャットテンプレートでデフォルトで思考から開始するためであり、サーバーオプション（--reasoning-budget 0）とリクエストオプション（chat_template_kwargs: {enable_thinking: false}）で無効にすることで正常になりました。 音声対話では思考モードを必ず無効にする必要があります。 有効にしたままにすると最初の音声が何秒も遅れ、予算が短い場合は回答が全く出力されません。

6. 測定で判明した問題

6-1. 日本語：音声は正しいが表記の違いで減点される

日本語の中間文でエラー率15%が出ましたが、音声が間違っていたわけではありません。

たいてい 対 大抵, 七 対 7、句読点の有無は同じ言葉の異なる表記です。発音練習サービスが認識結果を目標の文と 文字列類似度で比較する場合、学習者が完璧に話してもこのような表記の違いで減点される可能性があります。中国語の数字（七 対 7）でも同様の問題が予想されます。修正方法としては、比較前に数字や表記を正規化するか、文字ではなく発音（読み上げ）基準で比較することです。

6-2. デプロイされたサーバーが最新コードより古い場合がある

ある環境で中国語の合成が 404 Not Found で失敗しました。サーバーコードの中国語の音声プリセットは新しいコードには存在しますが、デプロイされたイメージには存在しなかったためです。新しい機能が動作しない場合は、 コードではなくデプロイされたイメージのバージョンを先ず確認する必要があります。

6-3. GPU サーバーごとにドライバーのバージョンが異なるとイメージが起動しない

CUDA 13 向けにビルドされた vLLM イメージが、ドライバー 570 系統（CUDA 12.8 まで）で Error 804: forward compatibility was attempted on non supported HW により起動できませんでした。同じイメージがドライバー 595 系統では動作します。CUDA 13.x はドライバー 580 以上を要求します。複数のサーバーを併用する場合は、 ドライバーのバージョンをサーバーごとに確認し、イメージの CUDA バージョンと合わせる必要が あります。本記事の LLM 測定は CUDA 12 用イメージ（llama.cpp）で構成しました。

6-4. 測定ツールで直面した罠

ここでの最大の教訓はバックエコーエラー率の事例です。 測定コードのバグがモデルの欠陥のように見えることがあります。 エラー率が1を超える値が出た場合は、モデルではなく入力（サンプリングレート、長さ、言語指定）をまず疑うべきです。

7. 1ターンの遅延はどのくらいか

ユーザーの発話終了時点から最初の音声が出るまでの合計は以下の通りです。

(말 끝 판단) + ASR + LLM 첫 문장 + TTS 첫 문장 + 전송

パーツごとの実測値を文の長さで繋ぎ合わせた 計算上の推定値です（最初から最後まで通して測定したわけではありません）。LLM の最初の文は上記の測定で実際に生成された文であり、TTS の時間は3-1の式（合成 ≈ 0.475 × オーディオ長 + 0.23秒）にその文の読み上げ長さを代入しました。

この表には発話終了判定（VAD）とネットワーク転送が含まれていません。発話終了を0.3〜0.5秒と仮定すると、その分が加算されます。この仮定値が発話途中の途切れというコストにどれだけ影響するかは、すぐ下で人間が読み上げた文を用いて測定しました。公開されている値の範囲は、NVIDIA ブループリント推奨の200〜500ms、Pipecatデフォルトの0.2秒、LiveKitの0.5秒（ストリーミングターン検出器0.3秒）、OpenAIの例の500msであるため、仮定はこの範囲内に収まっています。同一ドキュメントの目標遅延（発話終了から応答開始まで）は600〜1,500msであり、大型 GPU とストリーミング TTS を使用したブループリントのサーバー終端遅延は0.86〜0.93秒（ベンダー数値）です。本記事の韓国語の合計に発話終了判定を加算した約1.9〜2.3秒が大きい理由は、本記事の TTS がストリーミングではないためと読み取れます（公開事例における TTS の最初の音声までは0.07〜0.37秒）。学習者は言い淀みが多く、短い判定では発話が途中で切れてしまう可能性がありますが、これを扱った研究は閲覧可能な資料から見つかりませんでした（未確認）。

発話終了判定時間はどれくらいであるべきか（読み上げ音声の実測）

発話終了判定は、ユーザーが一定時間静寂状態であれば発話が終了したとみなす仕組みであり、その時間が文中の自然なポーズよりも短いと発話の途中で切れ、長いと応答がその分遅れます。人間が読み上げた FLEURS の文（言語ごとに60個、平均10〜14秒）から Silero VAD（6.2.3、閾値0.5、CPU 1スレッド）で音声区間を検出し、1文中の隣接する音声区間の間隔を「文中のポーズ」としてカウントしました。スクリプトと元データは docs/experiments/2026-10-07-vad-turn-gaps/ にあり、GPU を使わず CPU 1スレッドで実行しました。

• 発話終了を0.3秒と設定すると、読み上げ文の40〜52%が発話途中で終了したと判定されます。 上記の仮定の下限（0.3秒）はこのデータでは短すぎます。0.5秒であれば13〜28%、0.7秒であれば7〜10%、1秒であれば0〜1.7%に減少します。

• 計算すると、 上の1ターンの合計に発話終了の判定を追加する場合、0.5秒をかけると韓国語は約2.1〜2.3秒、0.7秒をかけると約2.3〜2.5秒になります（上の表の合計に加算した計算であり、最初から最後まで測ったわけではありません）。途切れを減らすために判定時間を長くすると、その値が応答遅延にそのまま上乗せされるというトレードオフになります。

• VAD自体のコストは小さかったです。 CPUの1スレッドでオーディオ1秒を処理するのに中央値3.2ms（最大55.1ms）、32msのフレーム1つあたり0.10msでした。発話終了判定の遅延は計算ではなく、待機時間のレイアウト設定がほぼ全てです。

• 制限。 朗読音声であり、文が会話のひと言よりも長いため（長いほど間が空く場所が増えます）、会話音声での値は異なる可能性があり、言い淀みや考え込むための無音のポーズは含まれていません。VAD1つ（Silero 6.2.3）としきい値1つのみを使用しており、意味を読み取って発話終了を判定するターン検出モデルは測定していません。文ごとにポーズがあるかどうかをカウントしたものであり、各ポーズが実際に発話の終了地点であるかどうかは判断していません。

• ボトルネックは音声合成です。 1ターンの時間のうち約60〜85%がTTSであり、ASR（0.2秒）とLLM（0.1〜0.2秒）は合わせても0.5秒前後です。

• 最初の文を短く区切ると、最初の音声の出力が早くなります。 日本語と中国語の返答が短い相槌から始まると、合計が1秒前後まで下がります。英語は最初の文が長いため最も遅かったです。会話のプロンプトで「短い相槌から始めよ」と指定すれば同様の効果が得られると考えられますが、検証はしていません。

• ChatGPTの水準（発話終了後1秒前後）に近づきます。 日本語と中国語はすでにその範囲にあり、英語と韓国語は最初の文をさらに分割するか、ストリーミング合成（このサーバーでは使用していません）を使用することで短縮できます。これは推測であり、検証はしていません。

8. 面接で出そうな質問

• リアルタイム音声会話の遅延はどのように分解するか？ 発話終了判定、ASR、LLMの最初の文、TTSの最初の音声、転送に分けて段階ごとに測定する。ここではASRが0.2秒、LLMの最初の文が0.1〜0.2秒、TTSが0.7〜1.8秒であり、TTSがボトルネックになっていた。
• リアルタイム係数が0.5であれば十分か？ 再生よりも速いという意味なので、長い返答をつなぎ合わせる際には十分だが、最初の音声までの時間は別問題である。非ストリーミングサーバーは文をすべて合成しなければ最初の音声が出力されない。
• 音声認識の結果で学習者を採点する際の注意点は？ 音声が合っていても表記が異なって出力される（たいてい 対 大抵）。比較する前に正規化するか、読み方基準で比較する。
• GPUを1つでモデル2つが共有する場合、何を確認するか？ VRAMの余裕（TTSは約6,900MiB、ASRは約5,800MiBをそれぞれ追加）とホストRAM、サーバーのドライバーバージョン（コンテナイメージのCUDAバージョンと一致しているか）。
• 測定値が常識から外れている場合（エラー率 > 1）、どのように対処するか？ モデルよりも測定コードを先に疑う。入力変換（サンプリングレート）のエラーがよくある原因である。

確認できなかった事項

• 会話の品質。 速度は測定しましたが、学習者のレベルへの適応、エラー訂正、自然さなどの品質は人間が評価する必要があり、今回は評価していません。プロンプトも1種類（昨日はカフェで本を読んだ）のみしか検証していません。
• 韓国人学習者の英語や、他の母語話者の韓国語音声、騒音環境下における認識精度。 非ネイティブの英語は、中国語話者が読み上げた英語コーパスでのみ測定しました（第4-3節）。
• 部品をつなぎ合わせた実際のエンドツーエンド遅延。 第7節は計算による推測です。
• 異なるGPUで測定した値の直接比較。 2つのモデルの組み合わせを異なるGPUで測定しました。
• Magpie TTSの韓国語音声の品質（原因はNeMoコードのトナイザーマッピングの欠落と判明、第4節。回避策を講じれば文3つのエコー文字エラー率は0〜5%）。Nemotron ASRの1.12秒のチャンク空結果は、人間の音声では再現されませんでした。
• 同時会話数（TTS、ASR）。 一度に1つずつ測定しました（LLMは同時に2〜4個を測定しました）。TTSサーバーはリクエストを1つずつ処理するロックを保持しているため、同時に2つの会話を受け付けると行列に並ぶように見えますが、測定はしていません。このTTSサーバーは実際にサービス中のものであるため負荷テストは行わず、公開されている数値で方向性のみを確認しました。NVIDIAのブログ（ベンダーの数値、NIMサービング）のMagpie TTSの値には、同時ストリームを1から64に増やすと、最初の音声までの時間がB200では32から239ms、H100では47から275ms、A100では79から395ms、小型システム（DGX Spark）では53から962msに増加したと記載されています（それぞれ約7.5倍、5.9倍、5.0倍、18倍）。同じ負荷がかかった場合、ハードウェアが小さいほど同時実行性が遅延をより大きく拡大させるという傾向の根拠であり、本記事の環境にそのまま置き換えることのできる数値ではありません。
• ストリーミング合成の最初の音声遅延と、ストリーミング音声認識の実際の確定遅延。 今回の測定ではストリーミング経路を使用していません。
• 割り込み（応答の途中でユーザーが発話を遮る状況）と、会話音声の発話終了判定。 朗読音声の文中のポーズは上記で測定しましたが、割り込みと会話音声は測定しておらず、第7節の公開範囲のみを確認しました。

参考資料

• 第19章（オープンソース調査）、第21章（原理）、第17章（DCGM指標、ドライバーバージョン）

確認したバージョンと日付

2026-10-06時点。voxcpm 2.0.3、Qwen3-ASR-1.7B、Qwen3-ForcedAligner-0.6B、Nemotron 3.5 ASR Streaming 0.6B、Magpie TTS Multilingual 357M、NeMo 3.0.0、Gemma 4 12B QAT q4_0、llama.cpp b11429。