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

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のようなアプリを通じてすでにローカルの文字起こしツールを使用している場合、最大の疑問は、標準的なローカルモデルやNVIDIA自身のParakeetファミリーと比べて、メモリ消費量を大幅に増やしてまで30Bモデルを使う価値があるのかという点でしょう。

単一話者によるシンプルな英語やヨーロッパ言語の音声であれば、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がリリース初日から高スループットでのモデル配信をサポートしています。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クックブックに従います）。代わりに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リクエストを送信し、話者ラベル付きの文字起こしを生成します。

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の字幕ファイルを生成することが最終目標であれば、CTCタイムスタンプヘッドがそのまま維持されるSGLang-OmniまたはNeMo-Speech.cppを使用してください。