UVR5 / audio-separator トラブルシューティング完全ガイド（GPU未使用・CUDA・OOM・インストール）

この記事の使い方

UVR5 / MDX-Net や audio-separator は、動く環境では一瞬、動かない環境では延々ハマるツールです。そして詰まりどころは、ほぼ決まっています——GPUが使われない・CUDA out of memory・cuDNNエラー・ffmpegが無い・モデルが毎回ダウンロードされる。

本稿は 症状から逆引きできるトラブルシューティング集です。各症状について「まず何を実行して診断するか → 原因 → 具体的な修正」を、ONNX Runtime / PyTorch / audio-separator の公式情報に基づいて示します。

筆者について（信頼性の開示）：私は音源分離を第1段に持つ AI動画ローカライズ基盤を単独で設計・実装し、本番運用しています。本稿の修正手順は、ローカル・Colab・コンテナ・本番 GPU の各環境で実際に踏み抜いて直してきた記録です。本番でのスケール設計はGPUワーカー基盤の記事に、ツール全体像はUVR5ガイドにまとめています。

症状の早見表（30秒で当たりをつける）

まず診断：環境を機械的に確認する

勘で直す前に、事実を取得します。最初に投げるべきコマンドはこれです。

# audio-separator公式の環境診断（最優先）。CUDA/ffmpegの可否を一発で出す
audio-separator --env_info
# 期待する出力例:
#   "ONNXruntime has CUDAExecutionProvider available, enabling acceleration"
#   "FFmpeg installed"

# GPUドライバ自体が見えているか
nvidia-smi

さらに Python から ONNX Runtime と PyTorch の両方を確認します。audio-separator は ONNX Runtime（MDX-Net等の .onnx）と PyTorch（Demucs等の .ckpt）の2系統で動くため、両方を見る必要があります。

# diagnose.py — GPUが本当に効いているかを機械的に確認する
import onnxruntime as ort

print("ORT version :", ort.__version__)
print("ORT device  :", ort.get_device())                 # 'GPU' なら可、'CPU' なら未使用
print("ORT providers:", ort.get_available_providers())   # 'CUDAExecutionProvider' が含まれるか

try:
    import torch
    print("torch       :", torch.__version__)
    print("torch.cuda  :", torch.cuda.is_available())     # Demucs等のPyTorch側
    if torch.cuda.is_available():
        print("device name :", torch.cuda.get_device_name(0))
except ImportError:
    print("torch not installed (MDX-Net/.onnx のみ使うなら不要)")

• ort.get_available_providers() に 'CUDAExecutionProvider' が無ければ、GPU は使われていません（CPU実行＝激遅）。
• ort.get_device() が 'CPU' なら同上。

この2つが「使えていない」を指していたら、原因はほぼ症状①です。

【最頻出】GPUが使われず、CPUで激遅

これが最も多く、最も気づきにくい問題です。エラーは一切出ず、ただ数十倍遅いだけ。

なぜ無言で CPU に落ちるのか

ONNX Runtime は Execution Provider の優先順リストで動きます。公式の説明どおり——

['CUDAExecutionProvider', 'CPUExecutionProvider'] means execute a node using CUDAExecutionProvider if capable, otherwise execute using CPUExecutionProvider.

つまり CUDA が使えなければ、黙って CPU で実行します。これが「動くのに遅い」の正体です。

原因A：onnxruntime と onnxruntime-gpu の同居（最有力）

CPU 版 onnxruntime と GPU 版 onnxruntime-gpu を両方インストールすると、同じディレクトリに展開されて後勝ちで上書きされ、CUDAExecutionProvider がサイレントに消えることがあります。

🔎 これは ONNX Runtime の公式ドキュメントに明文で警告がある話ではなく、microsoft/onnxruntime のissue などコミュニティで広く知られた gotchaです。挙動（CPUフォールバック）は providers の仕様から説明できます。

修正：CPU 版を消してから GPU 版を入れ直す。

pip uninstall -y onnxruntime          # CPU版を必ず先に消す
pip install --force-reinstall onnxruntime-gpu

原因B：CUDA / cuDNN のバージョン不整合

onnxruntime-gpu のビルドが要求する CUDA/cuDNN と、環境のそれが噛み合わないと CUDA EP がロードできず CPU に落ちます。→ ③ バージョン不整合へ。

audio-separator 公式の再インストール手順

audio-separator の README は、GPU が効かないときのクリーン再インストール手順を示しています（verbatim）。

pip uninstall torch onnxruntime
pip cache purge
pip install --force-reinstall torch torchvision torchaudio
pip install --force-reinstall onnxruntime-gpu

これで audio-separator --env_info が CUDAExecutionProvider available を出せば解決です。

CUDA out of memory（落ちる）

長尺・高解像度設定で RuntimeError: CUDA out of memory が出るケース。

修正の優先順位

1. segment_size を下げる（最も効く）。GPU に載せるチャンクが小さくなり VRAM を節約。
2. batch_size を 1 に。スループットは落ちるが VRAM を確実に削減。
3. より小さい/軽いモデルに替える（RoFormer → MDX-Net など。モデル選定ガイド参照）。
4. VRAM の大きい GPU に上げる（g4dn 16GB → g5/g6 24GB）。

# OOM対策：チャンクを小さくしてVRAMを抑える
from audio_separator.separator import Separator

sep = Separator(mdx_params={
    "segment_size": 128,   # 既定256から下げる（OOMの一番効く対策）
    "overlap": 0.25,
    "batch_size": 1,       # まとめ処理をやめてVRAMを節約
    "hop_length": 1024,
    "enable_denoise": False,
})
sep.load_model(model_filename="UVR-MDX-NET-Inst_HQ_3.onnx")

empty_cache() の誤解に注意

PyTorch 系（Demucs等）で OOM が出ると torch.cuda.empty_cache() を呼びたくなりますが、過信は禁物です。PyTorch 公式いわく——

Calling empty_cache() releases all unused cached memory from PyTorch ... However, the occupied GPU memory by tensors will not be freed so it can not increase the amount of GPU memory available for PyTorch.

つまり 解放されるのは「未使用のキャッシュ」だけで、テンソルが握っている VRAM は戻りません。OOM の本質的な解は「そもそも使用量を減らす」＝チャンク/バッチを小さくすることです。断片化が疑わしいときは環境変数 PYTORCH_CUDA_ALLOC_CONF の調整も選択肢です。

CUDA/cuDNN のバージョンエラー

LoadLibrary failed、libcudnn.so.X not found、CUDA EP がロードできない等。

ONNX Runtime のバージョン要件（公式表）

ONNX Runtime の CUDA EP は ORT バージョンごとに要求 CUDA/cuDNN が決まっています（公式表）。要点：

そして最大の落とし穴がこれ（公式 verbatim）。

ONNX Runtime built with cuDNN 8.x is not compatible with cuDNN 9.x, and vice versa.

cuDNN 8系と9系は互換性がありません。新しい ORT（1.19+）は cuDNN 9 を要求するので、環境に cuDNN 8 しか無いと CUDA EP がロードできず CPU に落ちます。

環境別の対処

• Colab（CUDA 12 が既定だが ORT が CUDA 11 ライブラリを要求する場合、README verbatim）：

apt update && apt install -y nvidia-cuda-toolkit   # 不足するCUDAライブラリを補う

• CUDA 12 環境向けの ONNX Runtime（README が案内する nightly）：

python -m pip install ort-nightly-gpu \
  --index-url=https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ort-cuda-12-nightly/pypi/simple/

• 基本方針：onnxruntime-gpu のバージョンを、環境の CUDA/cuDNN に表で合わせる。合わせられないなら、対応する CUDA/cuDNN を入れるか、ORT 側を入れ替える。audio-separator のサポート CUDA は 11.8 と 12.2 です。

ffmpeg が見つからない（音声I/O失敗）

ffmpeg not found、音声の読み込み/書き出しで落ちる。audio-separator は音声 I/O に ffmpeg を必要とします。

# Debian / Ubuntu
apt-get update && apt-get install -y ffmpeg
# macOS
brew install ffmpeg

audio-separator --env_info で FFmpeg installed が出れば OK。コンテナでは イメージに ffmpeg を必ず同梱してください（実行時 apt は遅く・不安定）。

モデルが毎回ダウンロードされる / 遅い

「起動のたびに数百MBの DL が走る」——コンテナ/サーバーレスで頻発します。

原因

モデルは初回利用時に自動ダウンロードされ、既定の保存先は /tmp/audio-separator-models/（README verbatim）。/tmp は揮発するため、コールドスタートのたびに再ダウンロードされます。

修正

• 保存先を永続化：model_file_dir を永続ボリュームに向ける。
• イメージに焼き込む：ビルド時に1回だけ DL してレイヤに含める（本番で最も速く確実）。

from audio_separator.separator import Separator

sep = Separator(model_file_dir="/models")   # 永続ボリューム or イメージ同梱パス
sep.load_model(model_filename="UVR-MDX-NET-Inst_HQ_3.onnx")

# Dockerfile（抜粋）：ビルド時にモデルを焼き込み、起動時の再DLをゼロに
ENV MODEL_DIR=/models
RUN python -c "from audio_separator.separator import Separator; \
  s=Separator(model_file_dir='${MODEL_DIR}'); \
  s.load_model(model_filename='UVR-MDX-NET-Inst_HQ_3.onnx')"

この「モデル常駐＋イメージ焼き込み」は、本番のコールドスタートとegress課金を同時に削ります。スケール設計はGPUワーカー基盤の記事で詳説。

Apple Silicon（Mac）で動かない / 遅い

Apple Silicon（M1以降）は NVIDIA CUDA 非対応です。UVR5 本体は MPS（GPU）アクセラレーションに対応していますが、audio-separator ライブラリでは CPU 実行（[cpu] extra）が基本になります。

pip install "audio-separator[cpu]"   # Apple SiliconはCPU版

• Mac で「GPU が使われない」と悩むのは正常です（CUDA が無いため）。CPU でも動きますが遅いので、大量処理は NVIDIA GPU の Linux 環境（クラウド含む）を使うのが現実解です。
• 軽いモデル（MDX-Net）を選び、segment_size を環境に合わせるとCPUでも実用に近づきます。

本番で「沈黙の劣化」を防ぐ：起動時ガード

最後に、最頻出の①を二度と踏まないための予防策です。本番では起動時に GPU を検証して、CPU に落ちていたら fail-fast にします。気づかないまま遅い本番を回すのが、最も高くつくからです。

# guard.py — 起動時にCUDAが効いているか検証。本番ではCPUフォールバックで起動を止める
import os
import onnxruntime as ort

def assert_gpu(require: bool = True) -> None:
    providers = ort.get_available_providers()
    ok = "CUDAExecutionProvider" in providers and ort.get_device() == "GPU"
    if not ok:
        msg = (f"GPUが有効化されていません（providers={providers}, "
               f"device={ort.get_device()}）。onnxruntime-gpuとCUDA/cuDNNを確認。")
        if require:
            raise RuntimeError(msg)     # CIや本番起動で確実に気づく
        print(f"[WARN] {msg}")

if __name__ == "__main__":
    assert_gpu(require=os.environ.get("REQUIRE_GPU", "true").lower() == "true")

これを Docker の HEALTHCHECK やサービス起動時に挟むだけで、「いつの間にか CPU で激遅」という最悪の事故を構造的に防げます。

よくある質問（FAQ）

Q. GPU があるのに --env_info が CUDAExecutionProvider を出しません。 A. まず pip uninstall -y onnxruntime でCPU版を消し、onnxruntime-gpu を入れ直してください（同居が最有力）。直らなければ ORT と CUDA/cuDNN のバージョン表を確認し、cuDNN 8/9 の取り違えを疑います。

Q. ローカルでは GPU が効くのに、コンテナだと CPU になります。 A. コンテナに CUDA/cuDNN ランタイムが正しく入っているか、onnxruntime（CPU版）が紛れていないかを確認。nvidia-smi がコンテナ内で動くか（--gpus all / GPU ランタイム）も要チェックです。

Q. CUDA out of memory を empty_cache で直せますか？ A. 基本的に直りません。empty_cache() は未使用キャッシュしか解放しないためです。segment_size/batch_size を下げるのが本筋。VRAM が足りなければ GPU を上げます。

Q. ffmpeg はなぜ必要？ A. 音声の読み書き（デコード/エンコード）に使われます。未インストールだと音声 I/O で落ちます。apt-get install -y ffmpeg 等で入れてください。

Q. Mac で GPU を使いたいです。 A. Apple Silicon は CUDA 非対応です。UVR5 本体は MPS に対応しますが、ライブラリ運用は CPU が基本。大量処理は NVIDIA GPU の Linux/クラウドを使ってください。

まとめ：症状 → 診断 → 修正の型を持つ

UVR5 / audio-separator のトラブルは、当てずっぽうで直すと泥沼ですが、診断コマンドで事実を取れば、原因はほぼ一意に決まります。

1. まず audio-separator --env_info と diagnose.py で GPU/ffmpeg の事実を取る。
2. 最頻出は CPU フォールバック——onnxruntime 同居を消し、CUDA/cuDNN を表に合わせる。
3. OOM はチャンク/バッチを下げる（empty_cache は本質解ではない）。
4. 本番は起動時 GPU ガードで「沈黙の劣化」を構造的に防ぐ。

こうした「環境の沼」を設計で踏み抜かないのが、外注で差がつくところです。音源分離を含む音声・動画 AI を本番品質で組みたい方は、実績とともにご相談ください。一人 × 生成AIで、環境構築から本番運用まで一気通貫で支援します。

出典・公式リソース

• ONNX Runtime CUDA EP（要件表・cuDNN互換性）：CUDA Execution Provider
• ONNX Runtime Python API：API summary（get_available_providers / get_device） ／ Install
• PyTorch CUDA メモリ管理：CUDA semantics（empty_cache / PYTORCH_CUDA_ALLOC_CONF）
• audio-separator：README（--env_info / 再インストール手順 / CUDA 11.8・12.2 / モデルDL先）
• 「onnxruntime 同居」問題：microsoft/onnxruntime issue #7748

※ ライブラリのバージョン要件は更新されます。実装前に必ず一次情報を確認してください。「onnxruntime と onnxruntime-gpu の同居」問題は公式の明文ではなく、Issue で広く知られた挙動に基づく説明です。