その処理、GPUじゃなくて勝手にCPUで実行されてるかも ~ONNX RuntimeのcuDNN 警告と対策~

その処理、GPUじゃなくて勝手にCPUで実行されてるかも  ~ONNX RuntimeのcuDNN 警告と対策~

こんにちは!

本日は、ONNX RuntimeでGPU推論時の「libcudnn.so.9: cannot open shared object file」エラーの解決方法についての内容となります。

ONNX Runtimeを使用してGPU推論を行う際、CUDAプロバイダの初期化エラーに遭遇することがありますので、このエラーの原因と解決方法を解説いたします。

エラーメッセージの詳細

[E:onnxruntime:Default, provider_bridge_ort.cc:2195 TryGetProviderInfo_CUDA] 
/onnxruntime_src/onnxruntime/core/session/provider_bridge_ort.cc:1778 
onnxruntime::Provider& onnxruntime::ProviderLibrary::Get() [ONNXRuntimeError] : 1 : FAIL : 
Failed to load library libonnxruntime_providers_cuda.so with error: 
libcudnn.so.9: cannot open shared object file: No such file or directory

エラーの原因

このエラーは以下の状況で発生します

  1. cuDNN 9が未インストール: ONNX RuntimeがCUDA 12系で動作する際に必要なcuDNN 9(libcudnn.so.9)がシステムに存在しない
  2. ライブラリパスの問題: cuDNNはインストールされているが、ONNX Runtimeから見つけられない

これはたいていWarningとしてログに出ますがほっとくとGPU推論が実行できず、CPUフォールバックまたは処理の失敗が発生します。

よくあるのがログを無視してると処理がCPUフォールバックしてることにもきづかづ異様に処理が遅くなってしまいます

「あれ~、何かこの処理遅いぞ」

とおもったら、勝手にCPUで実行されていた、っていうことがよくあります

問題の診断方法

1. システムレベルでのcuDNN確認

まずシステムレベルで cuDNNの確認をしてみましょう

# 共有ライブラリとして登録されているか確認
ldconfig -p | grep libcudnn

# 物理ファイルの存在確認
ls -l /usr/lib/x86_64-linux-gnu/libcudnn.so* 2>/dev/null

この出力が何もない場合、cuDNNがシステムに存在しないか、パスが通っていない、ということになります

2. パッケージマネージャーでの確認

次は、パッケージマネージャで確認してみましょう

APT(Ubuntu/Debian)の場合

dpkg -l | grep libcudnn

Conda環境の場合

conda activate your_environment
conda list cudnn

こちらも、何も出ない場合、cuDNNが存在しないことになります。

解決手順

方法1: Conda環境での解決(推奨)

さて、Conda環境を使用している場合、
環境内にcuDNNをインストールすることで解決できます。

# 1. Conda環境をアクティベート
conda activate your_environment

# 2. cuDNN 9.10.1.4をインストール
conda install -c conda-forge cudnn=9.10.1.4 -y

インストールされる主要パッケージ

  • cuda-nvrtc-12.9.86
  • cudnn-9.10.1.4
  • libcublas-12.9.1.4
  • libcudnn-9.10.1.4
  • libcudnn-dev-9.10.1.4

方法2: システムレベルでの解決

一方で、システム全体で使用するようにすることも可能です(Linux環境やWSL環境)

# Ubuntu/Debianの場合
sudo apt update
sudo apt install libcudnn9 libcudnn9-dev

# ライブラリパスの更新
sudo ldconfig

重要: ONNX Runtimeの再インストール

方法1か方法2でcuDNNをインストールできたら、再度onnxruntime-gpuをインストールしましょう。

cuDNNインストール後、ONNX Runtimeが新しい環境を正しく認識するよう、再インストールを行います

# 既存のパッケージをアンインストール
pip uninstall onnxruntime onnxruntime-gpu -y

# GPU版を再インストール
pip install onnxruntime-gpu

この再インストールにより、ONNX Runtimeが新しくインストールされたcuDNNライブラリを正しく検出し、リンクすることができます。

動作確認

以下のPythonスクリプトで、問題が解決したか確認できます

import onnxruntime as ort

# 利用可能なプロバイダを表示
providers = ort.get_available_providers()
print("Available providers:", providers)

# CUDAプロバイダの確認
if 'CUDAExecutionProvider' in providers:
    print("GPU推論が利用可能です")
    
    # テスト用の簡単なモデルでセッション作成を確認
    import numpy as np
    from onnxruntime import InferenceSession
    
    try:
        # セッション作成(実際のモデルパスに置き換えてください)
        session_options = ort.SessionOptions()
        providers_list = ['CUDAExecutionProvider', 'CPUExecutionProvider']
        print("CUDAExecutionProviderが正常に初期化されました")
    except Exception as e:
        print(f"初期化エラー: {e}")
else:
    print("CUDAプロバイダが利用できません")

トラブルシューティング

それでも解決しない場合

たいてい上記で解決しますが、それでも解決しないときは、以下を試します

  1. バージョン互換性の確認
    CUDAとcuDNNは以下の用な関係になっています。まずバージョン互換性を確認しましょう
    • CUDA 12.x → cuDNN 9.x
    • CUDA 11.x → cuDNN 8.x
    • ONNX Runtime GPUのバージョンがCUDAバージョンと互換性があるか確認

詳細なデバッグ情報の取得

import onnxruntime as ort
ort.set_default_logger_severity(0)  # 詳細ログを有効化

環境変数の設定
環境変数を設定すると解決することがあります

export LD_LIBRARY_PATH=$CONDA_PREFIX/lib:$LD_LIBRARY_PATH

CUDAバージョンの確認

nvidia-smi
nvcc --version

まとめ

ONNX RuntimeのCUDAプロバイダエラーは、主にcuDNNライブラリの不在が原因です。

Conda環境を使用している場合は、環境内にcuDNNをインストールします、
さらに、その後念には念を入れONNX Runtimeを再インストールしましょう。

これでたいていは解決するとおもいます

Qualiteg 技術コンサルティング

GPU推論環境のトラブル、その先の最適化まで。

GPU・推論まわりは、動かすまでも、その先の運用も悩みどころが尽きません。

私たちは自社で GPU クラスターを運用し、LLM プロダクトを開発しています。GPU 選定・推論最適化(量子化・vLLM)・分散構成まで、運用経験に基づいて実践的にアドバイスします。

LLMインフラ・基盤技術の支援を見る →

Read more

Claudeのリセット権(上限のリセット)とは?Fableリセット・週次リセットで戻るものとChatGPTとの違い

Claudeのリセット権(上限のリセット)とは?Fableリセット・週次リセットで戻るものとChatGPTとの違い

Claude Fable 5.2 のリリース記念で配られたリセット権(上限のリセット)をご紹介します。使った利用枠を定期リセットを待たずに戻せる権利で、Fable リセットで戻るのは Fable で使った分です。週次リセットとの違い、もらえる件数、プランごとの期限、注意点、ChatGPT のリセットとの違いを、公式ヘルプと実際の画面をもとに整理します。

By Qualiteg プロダクト開発部
ゼロから作るコーディングエージェント【第6回】評価をどう作るか。動くものを作らせて自動採点し、採点器そのものを疑う

ゼロから作るコーディングエージェント【第6回】評価をどう作るか。動くものを作らせて自動採点し、採点器そのものを疑う

採点器の「テスト」10点が3日間ずっと0/0でした。点数の表を見ているだけでは気づけません。仕様書を渡してWebシステムを作らせ、起動して叩いて採点する評価装置の作り方、5種類×3本の合否基準、対照実験を先にやる理由、自作でない課題で「テストだけが決めている契約」を先に洗う話を、測った数字で書きます。

By Qualiteg プロダクト開発部
大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第7回 セキュリティとベストプラクティス - 本番環境での考慮事項

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第7回 セキュリティとベストプラクティス - 本番環境での考慮事項

こんにちは、今回はシリーズ第7回セキュリティとベストプラクティス - 本番環境での考慮事項 について解説いたします! 連載の構成 * 第1章:基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎 * 第2章:ドメイン環境の構築 - 検証環境の構築手順 * 第3章:クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順 * 第4章:プロキシサーバーと統合Windows認証 * 第5章:ブラウザ設定と認証 - 各ブラウザでの設定方法 * 第6章:トラブルシューティング - よくある問題と解決方法 * 【★今回です★】第7章:セキュリティとベストプラクティス - 本番環境での考慮事項 * 第8章:実践的な構成例 - AIセキュリティツールとの統合事例 第7章:セキュリティとベストプラクティス 第 7 回は、ここまでの回で作った認証基盤を「本番で運用できる状態」にするための話です。 前半の 7.1

By Qualiteg コンサルティング