ローカルLLM常駐中にWhisperで文字起こしを回すと何が詰まるか｜VRAMは足りてもGPU計算の取り合いで遅くなる

音声をその場で文字に起こしながら、同じパソコンでローカルLLMにも答えさせたい、という使い方が増えている。会議を録りながら要点をまとめる、取材音源を書き起こして質問を投げる、音声アシスタントのように話しかけて処理させる。どれも「文字起こし」と「LLM」を一台のGPUで同時に回す構図になる。このとき最初に気になるのが「VRAMは足りるのか」だが、実際に引っかかるのはそこではないことが多い。

ここで扱う数値のうち、Whisperの必要VRAMと速度、各LLMの単体VRAMと生成速度は、いずれもRTX 5080での実測値である（Whisperの詳細はWhisperをローカルで動かす必要スペックを参照）。一方で、LLMを常駐させたままWhisperを同時に走らせたときにどれだけ遅くなるかは、機構として説明するにとどめ、同時実行そのものの実測はしていない。低下の量は組み合わせるモデルと処理の重なり方で変わるため、単体の数値と同じ強さでは語らない。

まず、VRAMには意外と収まる

結論を先に言うと、LLMとWhisperを同じGPUに載せること自体は、16GB級のGPUでも多くの構成で成立する。理由は単純で、Whisperが思いのほか軽いからだ。faster-whisper（CTranslate2）で動かした場合、推論中のピークVRAMは large-v3・turbo（large-v3のデコーダを軽くした高速版。詳しくは後述）とも約4.7GB、int8まで落とせば約3.7〜3.8GBに収まる。音声認識モデルは、大規模言語モデルほどメモリを食わない。

ただし、この軽さは動かし方に依存する点は押さえておきたい。同じWhisperでも、本家のPyTorch実装では large で約10GB、turbo で約6GBが目安とされ、faster-whisper（CTranslate2）実測の約4.7GBは、largeに対しては半分前後、turboに対しても1GB以上少ない。限られたVRAMを分け合う同居では、どの実装で動かすかが「収まるかどうか」を左右する。以下の数値は、推論効率に定評のあるfaster-whisperで動かした前提のものだ。

一方のLLMは、モデルの規模で必要VRAMが大きく変わる。RTX 5080単体での実測を、常駐に向く小〜中規模を中心に並べる。

（表の値はRTX 5080での単体ロード時の実測概算。Whisperはfaster-whisper／CTranslate2、LLMはOllama既定設定での計測で、Ollamaのバージョン・設定コンテキスト長・並列数・KVキャッシュ形式によって必要VRAMは変わる。再現時は測定条件を揃える必要がある。）

単純に足すと、8B級のLLM（約7.8GB）とWhisper（約4.7GB）で12.5GB前後。16GBのGPUなら余白を残して両方載る。12B級で14.4GBとやや詰まり、14B級では単純合計が約16.3GB相当となって、16GB級では表示単位や作業領域を含めると余裕がなくなる。つまり「小〜中規模のLLM＋Whisper」は容量的に収まりやすく、大きめのLLMにすると初めてVRAMが効いてくる、という順番になる。ここまでは、画像生成を同居させたときに真っ先にVRAMが破綻する話（ローカルLLM常駐時のVRAM配分で扱った）とは事情が違う。Whisperは画像生成ほど大きなメモリの山を作らない。

収まるのに遅くなる理由：同じGPUの実行資源を競合する

VRAMに両方載るなら快適に回るかというと、そうはならない。ここが本稿の中心で、詰まる場所は容量ではなくGPUの計算そのものの取り合いにある。

VRAMに両方載っても、同じGPU上でLLMとWhisperが同時に計算を要求すれば、両者の処理時間やスループットは影響を受ける。Ollamaとfaster-whisperは通常、別々のCUDAプロセス（コンテキスト）として動く。MPSを使わない一般的な構成では、別プロセスの処理はコンテキスト単位の時分割が中心になるため、一方がGPUを使っている間はもう一方の実行が待たされる場面が生じる。どちらもVRAMには載っているのに、実行の順番待ちで時間を削り合うという状態だ。

ただし、GPUが必ず一つのカーネルしか実行できないという意味ではない。同一プロセスの複数ストリームや、後述するMPSを使った構成では、別々の計算が重なって走ることもある。重なった場合に競合するのは一つの資源ではなく、GPUの演算器（SM）・メモリ帯域・キャッシュ・カーネルのスケジューリング枠・電力やクロックの上限といった共有資源で、どこが主なボトルネックになるかは構成によって変わる。MPSを使わない別プロセス構成では時分割の影響（一方が使う間もう一方が待つ、切り替えのオーバーヘッドも乗る）が中心になりやすい。いずれにせよ、「VRAMに載る」ことと「同時に速く動く」ことは別問題だ。

複数プロセスのカーネルを同時にスケジューリングしやすくするNVIDIAのMPSという仕組みもあるが、対応OSはLinuxとQNXで、Windowsでは利用できない。さらにMPSは、単独プロセスでは使い切れていないGPU資源を別プロセスで埋める用途に向く仕組みで、物理的な演算量や帯域を増やすものではない。LLMとWhisperの両方が単独でもGPUを高い割合で使う構成では、有効にしても改善が限定的な可能性がある。個人のWindows環境では選択肢に入りにくく、次に挙げる「GPUを占有する時間を減らす」対策のほうが実際的だ。

速度の数字で見ると、たとえば llama3.1:8b は単体で約134 tok/s 出るが、これは「GPUをそのモデルが占有できたとき」の値だ。同じGPUでWhisperが並行して計算を要求すれば、LLMに割ける時間が減るぶん、生成速度は単体値より落ちる。Whisper側も、LLMの生成中は文字起こしが引き延ばされる。落ち幅は、二つの処理がどれだけ時間的に重なるか（＝Whisperが連続で回り続けるのか、時々短く走るだけなのか）で変わる。

この「時間の重なり」がポイントになる。3分程度の音声をturboで一度書き起こすだけなら、Whisperが計算を要求するのは短い時間で、LLMへの影響も一過性で済む。逆に、話しながらリアルタイムに書き起こし続ける使い方（ストリーミング文字起こし）では、Whisperの処理が繰り返し発生するため、バッチ処理よりLLMと計算時間が重なりやすい。ただしWhisperが常にGPUを占有し続けるとは限らず、実際の占有率は、音声に対する処理速度・チャンク長・VAD・区間の再処理・使うストリーミング実装によって変わる。turboが音声の流入より十分速ければ、短い計算を間欠的に行うだけで済むこともある。「VRAMが足りるか」ではなく「二つの処理の時間がどれだけ重なるか」で快適さが決まる。

具体的な場面で考えると分かりやすい。8B級のLLMを常駐させて質問応答に使いながら、会議の音声をturboでリアルタイムに書き起こす構図を想定する。VRAMは8B（約7.8GB）＋turbo（約4.7GB）で12.5GB前後、16GBには収まる。だが実行中は、Whisperが音声チャンクを処理するたびにGPUへ計算を投げ、その合間にLLMが回答を生成する。両者が重なる区間では、LLMの体感速度は単体の約134 tok/sより落ち、書き起こしの確定も待たされる。VRAMのメーターには余裕が見えているのに、どちらの応答も少しずつ遅い——これが計算の取り合いの典型的な現れ方だ。

画像生成との「詰まり方」の違い

同じ「LLM常駐中に別の処理を同居させる」でも、相手が画像生成かWhisperかで、先に効くボトルネックが入れ替わる。

画像生成は、生成の瞬間に数GB〜十数GBのVRAMをまとめて確保しようとするため、常駐LLMと足すと容量が先に破綻しやすい。システムRAMへ退避が始まれば速度は桁で落ちる（LLMと画像生成のメモリ消費はローカルAIにシステムRAMは何GB必要かで扱った）。対してWhisperは軽く、容量では詰まりにくい。そのぶん、残った制約が「計算資源をどう分けるか」に移る、という関係になる。画像生成も同居中はGPU計算を激しく奪うが、その手前で容量のほうが先に破綻する。Whisperは容量に余裕が残るぶん、残る制約が計算の取り合いに移る——先に効く場所が違う、と押さえると整理しやすい。

常駐LLMのコンテキスト設定が、同居の余白を先に消費する

同居の余白を大きく左右するのがKVキャッシュだ。KVキャッシュは、LLMが処理済みトークンの中間状態を保持しておく作業メモリで、必要量は設定したコンテキスト長と並列数に応じて増える。ここで注意したいのは、Ollama（llama.cpp系）ではこの領域が会話の進行につれて少しずつ増えるのではなく、モデルのロード時に設定値ぶんまとめて確保される点だ。つまり、実際には短いやり取りしかしていなくても、大きなコンテキストを設定していればそのぶんVRAMの余白は最初から小さい。

別記事の実測では、qwen3:14bをFP16のKVキャッシュで動かすと、16GBのGPUに載せられた設定はコンテキスト32Kまでで、40Kでは収まらなかった（ローカルLLMで長文を扱うとVRAMはどれだけ増えるか）。これはWhisperを同居させない単体の話で、同居させるならモデルのロード時点でWhisper用の余白も残す必要がある。判断は「8B＋Whisperで12.5GB」という単純合計だけでなく、Ollamaに設定したコンテキスト長・並列数・KVキャッシュ形式まで含めて行うことになる。

ロード順序によって現れ方も変わる。LLMを先にロードしてVRAMの大半を使っていれば、後から起動したWhisper側のGPUメモリ確保が失敗する可能性がある。逆にWhisperが先にVRAMを使っている状態でLLMをロードすれば、LLMがGPUだけに収まらず、構成によってはCPUとの分割配置になる。会話の途中でKVキャッシュが膨らんで突然CPUへ移るというより、ロード時の設定・空きVRAM・配置で決まると捉えるのが正確だ。

対策は二つ。一つはコンテキスト長を用途に見合う範囲へ抑えること、もう一つはKVキャッシュ量子化でキャッシュ自体を小さくすることだ。OllamaではFlash Attentionを有効にしたうえで OLLAMA_KV_CACHE_TYPE を q8_0 または q4_0 にすると、KVキャッシュのVRAM消費を減らせる（量子化でどこまでコンテキストを伸ばせるかはVRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるかで扱った）。同居前提では、常駐LLMのコンテキストを欲張らないことが、そのままWhisperぶんの余白を守ることにつながる。

同居前提でのWhisper構成：軽く・速く・逃がす

計算の取り合いが本質だとすると、Whisper側でできる対策は「GPUを占有する時間を短くする」方向になる。

第一に、turboを選ぶ。large-v3-turbo はデコーダの層数を32から4へ削った派生版で、精度の頂点である large-v3 に対して約2.5倍速い（実測）。文字起こしにかかる時間が短ければ、LLMの計算を邪魔する時間もそれだけ短くなる。VRAMはどちらも約4.7GBでほぼ同じなので、同居用途では速いturboが素直な選択になりやすい。

第二に、VRAMを詰めたいならint8。int8量子化でピークVRAMは約1GB下がる（large-v3で約4.7→3.8GB、turboで約4.7→3.7GB）。ただしint8の主目的はメモリ削減で、速度が必ず上がるとも下がるとも限らない（faster-whisper公式READMEのlarge-v2の例ではint8がFP16よりわずかに速いが、差は小さく、GPUやモデル、バッチ設定によって変わる）。容量に余裕があるなら、メモリ目的だけでint8を選ぶ必然性は薄い、という程度に捉えておけばよい。常駐LLMを一段大きくしたくてWhisper側を削りたい、といった事情があるときの選択肢になる。

第三に、Whisperを別のデバイスに逃がす。Whisperは軽いので、CPUや、GPUを2枚積んでいるなら空いている側で動かせば、LLMがいるGPUの計算を奪わずに済む。faster-whisperはCPU実行にも対応するため、リアルタイム性がそこまで要らない用途では、Whisperだけを別GPUに固定するのが、計算の取り合いを根本から避ける最も確実な方法になる。GPUの役割分担そのものの考え方はローカルLLM常駐時のVRAM配分と地続きだ。

GPUが1枚しかなく別デバイスに逃がせない場合は、WhisperをCPUで動かす選択もある。faster-whisperやwhisper.cppはCPU実行に対応しており、CPUに余裕があれば、GPUの計算はLLMに専念させられる。数分程度の音源をバッチ処理する用途なら、CPU性能と選ぶモデルによってはCPU実行も選択肢になる。リアルタイム性を満たせるかは手元で確認したい。ただしリアルタイムに近い応答が要る用途では、CPUの文字起こしが間に合わないことがあるため、そこはGPUを分ける方向に戻る。

リアルタイム文字起こしを重視する場合は、Whisper側のチャンク（一度に処理する音声の長さ）の取り方も効いてくる。チャンクを短くすると応答は速く感じられるが、呼び出し頻度やオーバーヘッドが増えやすい。逆に長くすると確定までの遅延が増える。最適値は実装と用途によるが、常駐LLMの応答性を優先するなら、リアルタイム性が許す範囲でチャンクをやや長めに取るのが一つの折り合いになる。

現実的な回し方

用途に応じて、詰まりの避け方は次のように整理できる。

LLM側の選び方も、単体のときとは基準が変わる。単独運用なら「16GBに載る最大」を狙って12〜14B級を選ぶ判断もあるが、Whisperと同居させるなら、載るぎりぎりを攻めると計算の取り合いに加え、大きなコンテキスト設定でKVキャッシュ領域を確保すると余白がなくなる。同居前提では、単体で1〜2段小さいモデル（8B級まで）を選び、VRAMにも計算にも余白を残すほうが体感の安定につながりやすい。生成速度の実測でも、8B級は単体で100 tok/s以上出る一方、12〜14B級は70 tok/s台まで落ちる。もともと遅いモデルを取り合いでさらに削ると、応答の待ち時間が目立ちやすい。

Ollama側の常駐設定（keep_aliveや並列数）は、LLMをどれだけ待機させ続けるか・同時に何本さばくかを決める部分で、Whisperとの同居とは別軸だが合わせて効いてくる（設定値の詳細はOllamaを常駐・並列運用する実運用設定を参照）。並列数を上げればLLM側のVRAMと計算の要求も増えるため、Whisperと同居させるなら、常駐LLMの並列数はほどほどに抑えておくほうが安定しやすい。

自分の環境で確かめる

同居時の実際の落ち幅は環境で変わるため、最終的には手元で測るのが早い。手順はそれほど難しくない。

まず、LLM単体の生成速度を控えておく（Ollamaなら --verbose で tok/s が出る）。次に、Whisperで文字起こしを走らせながら同じ質問をLLMに投げ、生成速度がどれだけ落ちるかを比べる。並行して nvidia-smi でGPU使用率とVRAM、ollama ps でモデルが載ったままか（オフロードされていないか）を見る。VRAMに余裕があるのに速度だけ落ちていれば、それが計算の取り合いのサインだ。逆に ollama ps でモデルがCPUへあふれていれば、それは容量側の問題で、対処はLLMを小さくするかコンテキストを削る方向になる。

数値の読み方も決めておくとよい。たとえば（あくまで仮の数値だが）単体で134 tok/s のモデルが、Whisper併走時に90 tok/s程度に収まるなら、生成は体感で遅くなっても実用は保てる、といった線引きができる。逆に半分以下まで落ちる、あるいは書き起こしが音声の流入に追いつかなくなるなら、GPUを分けるか用途を割り切る判断に入る。nvidia-smi ではGPU全体の使用率・VRAM・クロック・電力を確認できる（Linuxで対応していれば nvidia-smi pmon でプロセス別の平均SM使用率も見える）。ただし、二つのプロセスのカーネルがどの順で実行されたかを nvidia-smi だけで判定するのは難しく、実行の重なりや待ち時間まで見るなら Nsight Systems などのCUDAトレースが要る。簡易な確認なら、LLM単体とWhisper併走時で tok/s・文字起こし時間・VRAMを比べるだけでも実用上の影響は判断できる。数回まわして平均を取れば、自分の常用構成での落ち幅がつかめる。

まとめ

ローカルLLMを常駐させたままWhisperで文字起こしを回すとき、最初に疑われがちなVRAM容量は、実は多くの構成で足りる。faster-whisperのWhisperは約4.7GBと軽く、8B級のLLMと足しても12.5GB前後で16GBに収まる（いずれもRTX 5080での単体実測にもとづく概算）。詰まるのはむしろその先で、二つの処理が同じGPUの計算を時分割で奪い合うため、VRAMが足りていても両方が遅くなる。これは、容量が先に破綻する画像生成との同居とは逆の詰まり方になる。

対策は「GPUを占有する時間を減らす」方向に集約される。Whisperはturboで短く済ませ、必要ならint8で軽くし、GPUが2枚あるなら別GPUへ逃がす。リアルタイムに書き起こし続ける用途ほど計算の取り合いは顕著になるので、時間をずらすかGPUを分けるのが効く。VRAMに載るかどうかと、載ったうえで快適に回るかどうかは別の問いだ、という点を押さえておくと、構成の判断を誤りにくい。なお、同居時の具体的な速度低下量は環境依存のため、最後は手元での実測で確かめてほしい。

よくある質問

16GBのGPU1枚で、LLMとWhisperの同時運用は現実的か。 容量の面では、8B級までのLLMなら現実的だ（8B約7.8GB＋Whisper約4.7GBで12.5GB前後）。ただし、大きなコンテキスト設定によるKVキャッシュ領域の消費と計算の取り合いがあるため、長い文脈を常駐で抱えつつリアルタイム文字起こしも回す、という重い使い方では1枚だと窮屈になる。バッチ書き起こし中心なら1枚でも回しやすい。

VRAMは空いているのにLLMが遅い。なぜか。 Whisperなど別の処理が同じGPUで計算を要求していると、GPUが処理を時分割するため、VRAMに余裕があっても生成速度は落ちる。nvidia-smi でGPU使用率が高く、ollama ps でモデルはGPUに載ったまま（CPUへあふれていない）なら、容量ではなく計算の取り合いが原因の可能性が高い。

Whisperは large-v3 と turbo のどちらを同居用に選ぶべきか。 同居用途ではturboが素直だ。VRAMはどちらも約4.7GBでほぼ同じだが、turboは約2.5倍速く、GPUを占有する時間が短いぶんLLMへの影響を抑えられる。精度が最優先で速度を犠牲にできる場面だけ large-v3 を検討する。

GPUを2枚にすれば同居の問題は解決するか。 計算の取り合いという観点では、Whisperを別GPUに固定できるので大きく改善する。Whisperを2枚目に固定し、LLMを1枚目だけに収めれば、両者のGPU計算の競合はほぼ分離できる（それぞれを別GPUに完結させる構成では、モデル分割のような継続的なGPU間のテンソル転送が基本的に発生しないため、GPU間の帯域は問題になりにくい）。ただしLLM自体を2枚へ分割する場合は、別途GPU間転送の影響を考える必要がある。

音声アシスタントのように使いたい。1枚のGPUで足りるか。 常駐LLMを8B級までに抑え、Whisperをturboにすれば、1枚（16GB）でも成立はする。ただし「話す→即書き起こし→即LLM応答」の一連をすべて低遅延で回すと、計算の取り合いで各段が少しずつ待たされる。反応の速さを最優先するなら、Whisperを別GPUかCPUへ分けて、LLMのGPUを空けておくほうが安定する。

参考資料

• OpenAI Whisper（公式リポジトリ）
• faster-whisper（CTranslate2実装・公式リポジトリ）
• Ollama FAQ（keep_alive・並列・GPU設定の公式ドキュメント）