# NVIDIA Nemotron 3.5 Transcribe：40言語・話者分離・ローカル構築

> 40言語の文字起こしや発話が重なる話者分離に対応するNVIDIA Nemotron 3.5 Transcribe(30B-A4B)の実力、WhisperやParakeetとの違い、必要なVRAM容量を解説します。

- URL: https://freelivecaption.com/ja/posts/nemotron-3-5-transcribe
- Author: 佐藤 美咲 (https://freelivecaption.com/ja/about)
- Topic: 音声入力 (https://freelivecaption.com/ja/topics/dictation)

## 要点

- NVIDIA Nemotron 3.5 Transcribe(30B-A4B)は、40言語の文字起こしや重なる発話の話者分離、単語単位のタイムスタンプに対応します。
- トークンあたりの稼働は4Bパラメータですが、全30Bの重みをメモリに保持する必要があり、BF16で67.5GB、NVFP4で21.6GBを消費します。
- Parakeet TDT v3(~1GB VRAM)やWhisper large-v3と比べ、単一話者の単純な音声では動作が重く処理も低速です。
- SGLang-OmniやNeMo-Speech.cppでローカルサーバーを立て、標準の/v1/audio/transcriptionsから会議録音を処理できます。

---

NVIDIAが[NVIDIA-Nemotron-3.5-Transcribe-30B-A4B](https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B)のオープンウェイトを公開した際、その特徴にはすぐに目を引かれました。3つの別々のツールを連結することなく、単一のモデルで40言語の音声文字起こしを処理し、複数人が同時に話して声が重なっても話者を識別してラベル付けし、単語単位のタイムスタンプを生成し、さらに音声翻訳までこなせるという点です。内部的には、トークンあたり約4Bのパラメータをアクティブ化するハイブリッドMixture-of-Experts（MoE）アーキテクチャ上に構築された、30Bパラメータの音声言語モデル（SALM：Speech-Audio Language Model）となっています。

20〜68GBのモデルウェイトをダウンロードし始める前に、あらかじめ把握しておくべき重要な制限が1つあります。Nemotron 3.5 Transcribeが処理できるのは録音済みの音声ファイル（保存された会議の録音、インタビュー、最長1時間までの通話エクスポートなど）のみであり、マイクからのリアルタイムストリーミングには対応していません。

NVIDIAはコンシューマ向けノートPC上の低遅延な音声入力ツール向けに、`nemotron-3.5-asr-streaming-0.6b`という全く別の軽量モデルも提供しているため、この2つは混同されがちです。室内や通話中で誰かが話している最中に画面へリアルタイムで字幕を表示したい場合、この30Bモデルはそのようなワークフロー向けには作られていないため、専用の[Mac向けライブキャプションアプリ](/en/posts/live-caption-apps-mac)やストリーミング対応の0.6Bモデルを使用するほうが適しています。一方、手元にあるのが録音済みのファイルで、発言の遮り合いや文の途中での言語切り替え、専門用語が含まれる場合には、Nemotron 3.5 Transcribeを使えば1回のパスでそのファイルを処理できるように設計されています。

## 30B-A4Bモデルの対応範囲：40言語、コードスイッチング、発話の重なり

ここ数年、話者ラベル付きで翻訳された会議の文字起こしをローカル環境で作成するには、壊れやすいパイプラインを構築する必要がありました。WhisperやParakeetのような音響モデルを実行して生のテキストを取得し、`pyannote`のような2つ目のモデルを実行してタイムスタンプごとに声をクラスタリングし、2つの出力を整合させるスクリプトを書き、さらにそのテキストをローカルまたはクラウドのLLMに渡して翻訳するという手順です。白熱した会議で2人が同時に話すたびにタイムスタンプの整合性がずれ、文の半分が別の人の発言として割り当てられてしまうという問題が起きていました。

Nemotron 3.5 Transcribeは、Conformerベースのオーディオエンコーダと30B-A4B言語デコーダ、そして専用のConnectionist Temporal Classification（CTC）タイムスタンプヘッド（`ctc_timestamp.*`、チェックポイント内の`word_timestamp_config`で設定）を組み合わせることで、これらすべての段階を1つのモデルに統合しています。話者の交代を文字起こし後に後付けする音響クラスタリングの問題として扱うのではなく、最長60分までの録音にわたり、話者タグ、句読点、単語のタイミングをテキストと直接並べて出力します。

言語サポートは標準で40言語をカバーしており、ヨーロッパ、アジア、中東の主要言語に加え、双方向の翻訳機能も内蔵しています。標準的な音響モデルと比べて30Bの言語バックボーンが顕著な違いを発揮するのは、言語間のコードスイッチングです。これは、ヒンディー語と英語、あるいはスペイン語と英語のビジネス通話のように、バイリンガルの話者が同じ文の中で自然に2つの言語を混ぜて話す録音を指します。一般的な音声認識エンジンでは通常、セグメントごとに単一の言語タグに固定せざるを得ないか、話者がヒンディー語の文法から英語の専門名詞に切り替えた瞬間に意味不明な文字列を出力してしまいます。Nemotron 3.5 Transcribeはオーディオトークンを30Bの多言語モデルに通すため、文の途中で言語が切り替わっても単語誤り率（WER）を低く保ち、複雑な医療用語や工学用語も発音通りの当て字にすることなく正確に処理します。

ただし、この大規模な言語バックボーンも、コンシューマ向けハードウェアに収まるようウェイトを量子化するとトレードオフが生じます。4ビット量子化ウェイト（`Q4`および`IQ4_NL`）を用いたテストでは、複数話者の会話や専門用語はうまく処理できたものの、4ビットでの1パス内蔵翻訳は、きれいに文字起こししたテキストを専用のLLMに渡す場合と比べて表現が硬く、言い回しの誤りも起きやすい結果となりました。また、音声に音楽が混ざっている場合にもつまずくことがあります。アニメ1話分を丸ごと4ビットのチェックポイントに通したところ、元の音声トラックでもボーカル抽出後のトラックでも3回連続で失敗しました。オープニングテーマ曲の英語の歌詞によって、その後に続くセリフに対するデコーダの言語状態が狂ってしまったためです。

## Nemotron 3.5 Transcribeと標準的なローカルモデルおよびParakeetの比較

コマンドラインスクリプトや[MacWhisper](/en/posts/macwhisper-guide)のようなアプリを通じてすでにローカルの文字起こしツールを使用している場合、最大の疑問は、標準的なローカルモデルやNVIDIA自身のParakeetファミリーと比べて、メモリ消費量を大幅に増やしてまで30Bモデルを使う価値があるのかという点でしょう。

| 機能/仕様 | Nemotron 3.5 Transcribe (30B-A4B) | NVIDIA Parakeet TDT v3 | Whisper large-v3 / large-v3-turbo |
| :--- | :--- | :--- | :--- |
| **総パラメータ数** | 30B（トークンあたり約4Bが稼働） | 0.6B〜1.1B | 1.55B (large-v3) / 0.8B (turbo) |
| **標準的なメモリ使用量（VRAM/ユニファイドメモリ）** | 20GB〜32GB（量子化時）/68GB（BF16） | 約1GB〜2GB | 約1.5GB〜4GB |
| **対応言語** | 40言語＋コードスイッチング | ヨーロッパ25言語（v3）/英語 | 99言語 |
| **ネイティブ話者分離** | 対応（発話の重なり・クロストークを含む） | 非対応（外部の話者分離が必要） | 非対応（pyannote / WhisperXが必要） |
| **単語単位のタイムスタンプ** | 対応（内蔵の`ctc_timestamp`ヘッド経由） | 対応（Token-and-Duration Transducer） | クロスアテンションによる近似 |
| **内蔵翻訳機能** | 1パスでの多言語翻訳 | 非対応 | 英語への翻訳のみ |
| **最適な用途** | 複数話者の会議、クロストーク、医療・専門用語、コードスイッチング | 日常的な高速文字起こし、CPUや低VRAM環境、字幕エディタ | 8GB〜16GB RAMのノートPCでの幅広い99言語対応 |

単一話者によるシンプルな英語やヨーロッパ言語の音声であれば、4ビット量子化したNemotron 3.5 Transcribeを実行するよりも、依然としてParakeet TDT v3のほうが高速かつ軽量で、精度面でも上回ることが少なくありません。Parakeetは約1GBのメモリで動作し、CPU上でも高速に処理でき、他のアプリと同時に起動してもメモリ不足に陥ることがありません。デコーダだけで15〜20GBのメモリを消費する30Bモデルを統合する代わりに、Subtitle Editのような軽量なデスクトップ向けキャプション・字幕作成ツールが引き続きParakeetを推奨している理由は、まさにこのメモリ消費量の差にあります。

Mac上で最適化されたWhisper large-v3環境と比較しても、クリアなポッドキャストやボイスメモを文字起こしする程度であれば、Nemotron 3.5 Transcribeは明らかに低速で動作も重くなります。Nemotron 3.5 Transcribeを選ぶべきなのは、WhisperやParakeetでは破綻してしまうようなケースです。具体的には、会議室で3人が同時に話す録音、頻繁にコードスイッチングが発生するバイリンガルインタビュー、あるいは1Bクラスの音響モデルでは30秒ごとに同音異義語を誤変換してしまうような専門性の高い録音（医療ディクテーションやアーキテクチャレビューなど）が該当します。

## ハードウェアとVRAMの要件：30B MoEモデルのメモリに関する落とし穴

「30Bパラメータのうち稼働は4B」と聞くと、標準的な4Bモデルのように8GBや12GBのグラフィックスカードで動作すると思いがちです。MoEアーキテクチャにおいて、稼働パラメータ数の4Bという数値はトークンあたりの計算量を決定するため、一度メモリに読み込まれれば推論速度は実用的な水準に保たれます。しかし、ルーターはトークンごとに異なるエキスパートを選択する可能性があるため、30Bすべてのパラメータを同時にVRAMまたはユニファイドメモリ上に保持しておかなければなりません。ウェイトがSSDへスワップしてしまうと、トークン生成は極端に遅くなります。

各フォーマットが実際に必要とするディスク容量とメモリ容量は以下の通りです。

まず、フル精度の**BF16チェックポイント（`nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B`）**は約67.5〜68GBあります。マルチGPUサーバーノードでモデルのファインチューニングを行うのでない限り、日常的な文字起こしのためにBF16ウェイトをダウンロードする理由はありません。NVIDIA DGX Spark（GB10）のような128GBワークステーションであっても、文字起こしモデルだけで68GBを占有してしまうと、ローカルLLMや音声エージェントを同時に読み込んでおくための余裕がほとんどなくなってしまいます。

次に、公式の量子化版である**NVFP4（`NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-NVFP4`）およびFP8チェックポイント**は、NVIDIAが最新GPUでのローカル運用向けに想定しているものです。発表直後にHugging Faceを確認した際、BF16と投機的デコーディング用ドラフタの`DFlash2`しか公開されておらず、NVFP4やFP8のリンクが404エラーになっていたかもしれませんが、現在はそれらのリポジトリも公開されています。NVFP4チェックポイントではモデルサイズが21.6GBまで縮小されるため、短い音声クリップであれば24GBの単一GPU（RTX 3090、RTX 4090、RTX 5090など）に収まります。ただし、フルコンテキストを伴う1時間クラスの録音では、総VRAM使用量が優に24GB〜32GBの範囲に達します。

3つ目に、Appleシリコン搭載Macや**GGUF（`IQ4_NL`＋`F16`）**を使用するローカルC++環境では、モデルは4ビット量子化言語デコーダ（`NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-AD-IQ4_NL.gguf`）と16ビットオーディオエンコーダ（`Encoder-F16.gguf`）の2つのファイルに分割されています。これら2つのファイルの合計ディスク容量は約21.35GBです。Appleシリコン搭載Mac（36GBや64GBのユニファイドメモリを備えたMシリーズMaxチップ搭載モデルなど）で読み込んだ場合、実行時のメモリ使用量は約20GBになります。

RTX 3060やRTX 4070のような12GB GPUを使用していて、`llama.cpp`のように非稼働のMoEエキスパートをシステムRAMへオフロードしようと考えている場合は、`NeMo-Speech.cpp`の現在の制限に注意が必要です。`nemo-speech serve`に対して`--asr.salm.n_cpu_moe 40`のようなフラグを渡すと、`nemo-speech serve: unknown option: --asr.salm.n_cpu_moe`というエラーが出て即座に失敗します。アップストリームでMoEのCPUオフロード用フラグが追加されるか、2枚の16GBカードにGGUFをきれいに分割できるようになるまでは、カスタムパッチを当てない限り、12GBや16GB VRAMのカードでデコーダとF16エンコーダの両方をGPUメモリに収めることはできません。

## `/v1/audio/transcriptions`経由でNemotron 3.5 Transcribeをローカル実行する方法

少なくとも24GB〜32GBのVRAM（Linux＋NVIDIA GPU環境の場合）または32GB以上のユニファイドメモリを備えたマシンを用意できたら、ローカルでの推論環境を構築できます。

NVIDIA GPU向けには、[SGLang-Omni](https://sgl-project.github.io/sglang-omni/cookbook/nemotron_transcribe.html)がリリース初日から高スループットでのモデル配信をサポートしています。Macやデスクトップワークステーション上の量子化GGUFウェイト向けには、`NeMo-Speech.cpp`が`nemo-speech serve`を通じてローカルサーバーを提供します。ローカルエンドポイントを立ち上げて複数話者の録音を文字起こしする手順は以下の通りです。

1. **BF16ではなく量子化ウェイトをダウンロードします。**24GB以上のNVIDIA GPUでSGLang-Omniを実行する場合は、Hugging Faceから`nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-NVFP4`（または`-FP8`版）を取得します。32GB以上のユニファイドメモリを搭載したMacで`NeMo-Speech.cpp`を使用する場合は、デコーダファイルの`NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-AD-IQ4_NL.gguf`とオーディオエンコーダファイルの`Encoder-F16.gguf`の両方をダウンロードします。
2. **会議の音声ファイルを準備します。**保存したZoomやTeams、ボイスレコーダーのファイルを、標準的な16kHzモノラルの`.wav`または`.mp3`ファイルに変換します（`ffmpeg -i meeting.m4a -ar 16000 -ac 1 meeting.wav`）。個々のファイルを60分以内に収めることで、モデルが学習したコンテキストウィンドウの範囲内に保ち、KVキャッシュの急激なメモリ増加を防ぐことができます。
3. **ローカルの文字起こしサーバーを起動します。**Python環境にSGLang-Omniをインストールした状態で、チェックポイントを指定してポート`8000`でサーバーを起動します（起動引数は[SGLang-Omni Nemotron Transcribeクックブック](https://sgl-project.github.io/sglang-omni/cookbook/nemotron_transcribe.html)に従います）。代わりにGGUFファイルと`NeMo-Speech.cpp`を使用する場合は、F16エンコーダのパスとともに`nemo-speech serve --asr-model NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-AD-IQ4_NL.gguf`を実行し、約20GBのモデルがメモリにマッピングされるまで待機します。
4. **音声ファイルを`/v1/audio/transcriptions`に送信します。**サーバーがローカルで待機状態になったら、`curl`または標準的なPython HTTPクライアントを使用して`POST`リクエストを送信し、話者ラベル付きの文字起こしを生成します。

```bash
curl http://localhost:8000/v1/audio/transcriptions \
  -H "Content-Type: multipart/form-data" \
  -F file="@meeting.wav" \
  -F model="nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-NVFP4" \
  -F response_format="verbose_json" \
  -F timestamp_granularities[]="word" \
  -F timestamp_granularities[]="segment"
```

多言語やコードスイッチングが含まれる録音を同じパス内で別のターゲット言語へ翻訳したい場合は、使用している配信バックエンドがサポートするリクエストボディまたはプロンプト設定でターゲット言語パラメータを渡し、返されたJSON出力をディスクに保存します。

## AMD ROCmおよびAppleシリコン環境で注意すべき2つのローカルバグ

標準的なCUDA環境やMac上の`NeMo-Speech.cpp`環境から外れる場合、原因を知らないとハードウェア障害のように見えるプラットフォーム固有の既知の問題が2つあります。

1つ目は、AMD GPU（ROCm 7.x上のRadeon AI PRO R9700やRX 7900 XTXなど）向けに`NeMo-Speech.cpp`をHIP/ROCmでコンパイルした場合です。30秒や60秒の短い音声クリップは問題なく文字起こしできますが、約120〜160秒を超える音声ファイルを処理しようとすると無期限にハングアップします。この現象が起きると、GPU使用率が0%に落ち込む一方で、単一のCPUスレッドが`hipStreamSynchronize`内で100%に張り付き、`nemo-speech serve`が後続のリクエストを受け付けなくなります。これは、HIPの`ARGSORT`修正がアップストリームにマージされる前の古い`llama.cpp`サブモジュールのコミットに`NeMo-Speech.cpp`が固定されているためです。CUBなしのROCmビルドにおいて、音声の長さによってソート行列が1,024列を超えると実行が停止してしまいます。ベースとなっている`ggml`/`llama.cpp`サブモジュールを更新またはパッチ適用してアップストリームのHIP `ARGSORT`修正を取り込めば、2分を超えるファイルでのハングアップは解消されます。

2つ目は、Mac上で`NeMo-Speech.cpp`ではなく`mlx-audio`経由でモデルを実行しようとする場合です。現時点では`.srt`や`.vtt`の字幕エクスポートは機能しない点に注意してください。公開されているHugging Faceのウェイトには単語単位のタイミングを出力する`ctc_timestamp.*`ヘッドが含まれていますが、現在の`mlx-audio`はモデル読み込み時に`ctc_timestamp.*`のウェイトを破棄してしまいます。これらのタイムスタンプ用ウェイトが読み込み時に除外されるため、`mlx-audio`が出力できるのはプレーンな`.txt`または基本的な`.json`の文字起こしのみに限られます。タイムスタンプと話者ラベルが付いた[SRTまたはVTT](/en/posts/srt-vs-vtt)の字幕ファイルを生成することが最終目標であれば、CTCタイムスタンプヘッドがそのまま維持されるSGLang-Omniまたは`NeMo-Speech.cpp`を使用してください。

## 出典と確認

<a id="source-huggingface-co-1"></a>

- [NVIDIA-Nemotron-3.5-Transcribe-30B-A4B](<https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B>) — 確認日 2026-11-01

<a id="source-sgl-project-github-io-2"></a>

- [SGLang-Omni](<https://sgl-project.github.io/sglang-omni/cookbook/nemotron_transcribe.html>) — 確認日 2026-11-01