WhisperでGPUが使われない原因と対処法｜CUDA・cuDNNの合わせ方

WhisperでGPUが使われない・認識しないときは、「PyTorchがCPU版で入っている」「CUDA・cuDNNとCTranslate2のバージョンが噛み合っていない」「VRAM不足でCPUに退避している」の3つを順に確認すると、原因はほとんど特定できます。エラーが出ずに静かにCPUで動き続けるケースが多いため、まず「本当にGPUを使えていないのか」を切り分けることが出発点です。この記事では、openai-whisperとfaster-whisperのそれぞれで詰まりやすいポイントを、確認コマンドとバージョン対応表つきで整理します。

なお、Whisperの導入手順そのものやモデル選び・日本語精度の上げ方は、Whisperで文字起こしする使い方（ローカル導入と日本語精度）で解説しています。本記事は「導入は済んだのにGPUが効かない」状態に絞って扱います。

WhisperでGPUが使われないときに最初に確認する3点

Whisperは、GPUが使えない環境だと例外を投げずにCPUへフォールバックする作りになっています。「動いてはいるが異常に遅い」という状態が典型で、1時間の音声に数時間かかる場合はまずGPU未使用を疑ってください。

1. 実行時のデバイスがcudaになっているか

もっとも確実なのは、Python側から実際に何のデバイスが選ばれているかを見ることです。次の3行を実行してください。

• import torch
• print(torch.__version__) … バージョン文字列の末尾を確認する
• print(torch.cuda.is_available()) … FalseならGPUは使われていない

ここでtorch.cuda.is_available()がFalseを返すなら、Whisper側の設定ではなくPyTorchの導入方法に原因があります。Trueなのに遅い場合は、後述のVRAM不足かfaster-whisper側のライブラリ不足を疑います。

2. torchのバージョン末尾が「+cpu」になっていないか

見落としが多いのがこれです。torch.__version__の出力が2.8.0+cpuのように+cpuで終わっている場合、CPU専用ビルドのPyTorchが入っています。この状態ではドライバやCUDA Toolkitを何度入れ直してもGPUは有効になりません。2.8.0+cu128のようにCUDAバージョンが付いているのが正しい状態です。

3. nvidia-smiでGPUとドライバが見えているか

ターミナルでnvidia-smiを実行し、GPU名とドライバのバージョンが表示されるかを確認します。ここで「コマンドが見つからない」「GPUが表示されない」となる場合は、Python環境以前にNVIDIAドライバの導入かハードウェア認識の問題です。なお、この表示に出るCUDAバージョンは「このドライバが対応できる上限」であり、実際にインストールされているCUDA Toolkitのバージョンとは別物である点に注意してください。

原因1：PyTorchがCPU版で入っている（openai-whisper系）

openai-whisperはPyTorchの上で動くため、PyTorchがGPUを掴めていなければWhisperもGPUを使えません。もっとも頻度が高い原因です。

なぜCPU版が入ってしまうのか

pip install torchとだけ実行すると、環境によってはCPU専用ビルドが入ります。また、以前CPU版を入れた環境に後からGPU版を重ねてインストールしても、既存のtorchが「インストール済み」と判定されて置き換わらないことがあります。「前は動いていたのに急にCPUになった」というケースは、別パッケージの依存解決でtorchがCPU版に差し替えられている場合が少なくありません。

入れ直しの手順

確実なのは、いったん削除してから公式が案内するインデックスURLを明示して入れ直す方法です。

• まずpip uninstall torch torchvision torchaudioで既存を削除する
• PyTorch公式のGet Startedページで自分の環境に合うコマンドを生成する
• 生成された--index-url付きのコマンドをそのまま実行する
• 再度torch.__version__を確認し、末尾が+cu126や+cu128になっていることを確かめる

PyTorchはCUDA 12.6（cu126）・12.8（cu128）など複数のビルドを配布しており、どれを選ぶかはドライバの対応状況で決まります。過去バージョンを固定したい場合はPyTorch公式の旧バージョン一覧から対応するコマンドを探すのが確実です。

仮想環境を使っている場合、有効化し忘れたまま入れ直して「システム側のPythonに入っていた」というミスも起こりがちです。インストール後は必ず、Whisperを実行するのと同じ環境でtorch.cuda.is_available()を確認してください。

原因2：CUDA・cuDNNとCTranslate2が噛み合っていない（faster-whisper系）

faster-whisperはPyTorchではなくCTranslate2という推論エンジンの上で動きます。そのため、PyTorchがGPUを認識していてもfaster-whisper側だけGPUが使えない、という状態が発生します。ここがopenai-whisperとの最大の違いです。

CTranslate2のバージョン別・必要なCUDAとcuDNN【対応表】

CTranslate2は、バージョンによって要求するcuDNNの世代が変わります。この対応がずれていることが、faster-whisperでGPUが使えない原因の大半です。

出典：CTranslate2 公式インストールドキュメント / faster-whisper 公式リポジトリ

ポイントは、CTranslate2 4.5.0以降がcuDNN 9を要求するようになったことです。手元の環境がcuDNN 8のままだと、ライブラリの読み込みに失敗してGPUが使えません。環境側を上げられない事情があるなら、pip install ctranslate2==4.4.0のようにCTranslate2の側をバージョン固定するほうが早く解決します。

「cudnn_ops64_9.dllが見つかりません」エラーの直し方

Windowsでもっとも見かけるのが、Could not locate cudnn_ops64_9.dllという趣旨のエラーです。これは「CTranslate2はcuDNN 9を探しているが、パスの通った場所に見つからない」という意味で、次のいずれかで解決します。

• cuDNN 9を導入してPATHを通す：NVIDIA公式のcuDNN配布ページから対応版を入れ、binフォルダをPATHに追加する（設定後はターミナルを開き直す）
• CTranslate2を4.4.0へ固定する：cuDNN 8のまま動かしたい場合はこちら。既存環境を壊さずに済む
• DLLをCTranslate2のフォルダに置く：pip show ctranslate2で表示される場所にcuDNNのDLLを配置する。応急処置としては有効だが、環境を再構築すると再発するため恒久策には向かない

なお、末尾の数字が_8（cudnn_ops_infer64_8.dll）になっている場合は逆に「cuDNN 8を要求しているのに無い」状態です。要求されている番号が8なのか9なのかを読み取ると、どちら側を合わせるべきかがすぐ判断できます。

torchのバージョンが古すぎないか

最新のCTranslate2を使う場合、faster-whisper側がtorch 2.4.0以上を前提とすることがあります。faster-whisperだけを最新化してtorchを据え置くと、依存関係の食い違いで起動時に落ちるケースがあるため、両者はセットで更新するのが安全です。

原因3：VRAM不足でCPUに退避している

torch.cuda.is_available()がTrueで、ライブラリも揃っているのに遅い場合は、モデルがVRAMに載り切っていない可能性があります。largeクラスのモデルを積んだ結果メモリ不足で落ち、CPUで処理し直しているパターンです。

モデル別のVRAM目安

数値はあくまで目安で、同時に動かしている他のアプリやcompute_typeの設定によって上下します。GPUのVRAMはnvidia-smiの使用量表示で実測できるため、処理中に見ておくと判断が早くなります。

compute_typeで消費を抑える

faster-whisperではcompute_typeをfloat16やint8_float16に指定することでVRAM消費を抑えられます。VRAMが8GB前後の環境では、largeをfloat32で動かそうとせず、large-v3-turboをfloat16で動かすほうが速度と品質のバランスが取れます。無理にモデルを大きくするより、載る構成で確実にGPUを使うほうが結果的に速く終わります。

症状別の切り分け早見表

ここまでの内容を、実際に出ている症状から逆引きできる形に整理します。上から順に確認すれば、多くのケースは数十分で解決できます。

ありがちな失敗と、編集的な判断

環境構築でつまずくとき、技術的な難しさより「手順の順番」でロスしているケースが目立ちます。実際に起こりやすい失敗を挙げておきます。

• CUDA Toolkitから入れ直してしまう：もっとも時間を溶かすパターンです。PyTorchのGPU版ホイールには必要なCUDAランタイムが同梱されるため、openai-whisperを使うだけならCUDA Toolkitのフル導入は不要なことが多く、まずtorchの入れ直しから試すほうが短時間で終わります。
• nvidia-smiのCUDAバージョンに合わせようとする：あの数字はドライバの対応上限であって、導入すべきToolkitのバージョンではありません。ここを取り違えると不要な入れ直しを繰り返すことになります。
• 仮想環境を有効化せずにインストールする：入れたはずのGPU版が別の環境に入っており、実行側は古いままという状態です。確認は必ず実行環境と同じシェルで行ってください。
• エラーメッセージのDLL番号を読まない：8と9のどちらを要求されているかで対処が正反対になります。番号を確認するだけで判断が一段速くなります。

編集的な判断として付け加えると、GPUを使えるようにすること自体が目的化していないかは一度立ち止まる価値があります。文字起こしの頻度が月に数回で、1回あたり1時間程度の音声なら、環境構築に半日かけるよりクラウドのAPIやサービスに任せたほうが総コストは低くなります。GPU環境の整備が効いてくるのは、機密性の高い音声を外部に出せない場合や、毎週まとまった量を処理する場合です。用途別の選択肢はAI文字起こしツールの精度比較で整理しているので、あわせて検討すると判断しやすくなります。会議音声が中心なら無料のAI議事録ツール比較も選択肢に入ります。

まとめ｜番号を読み、バージョンを揃えれば解決する

WhisperでGPUが使われない原因は、PyTorchのCPU版・CUDAとcuDNNとCTranslate2のバージョン不一致・VRAM不足の3つにほぼ集約されます。最初にtorch.__version__とtorch.cuda.is_available()を確認し、faster-whisperを使っているならCTranslate2のバージョンとcuDNNの世代が対応表どおりかを見る、という順番で切り分けてください。

エラーメッセージに出るDLLの番号（8か9か）は、どちら側を合わせるべきかを示す手がかりになります。環境側を上げられない場合は、CTranslate2のバージョンを固定するという逆方向の解決も選べます。導入手順やモデル選びから見直したい場合は、Whisperで文字起こしする使い方もあわせて参照してください。