その処理、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を再インストールしましょう。

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

Read more

AIエージェントを"事業に載せる"ために【第1回】

AIエージェントを"事業に載せる"ために【第1回】

AI導入事故は何を示しているのか — AI導入を"事業に載せる"ために、いま設計すべきこと(全3回) こんにちは!Qualitegコンサルティングチームです! AIエージェントを導入する企業が増える一方で、 「試してみる」段階から「事業に載せる」段階へ進める難しさ が、はっきり見え始めています。 本シリーズでは、AIエージェント導入を技術論だけでなく、責任分解・監査可能性・契約・運用統制を含む業務設計の問題として整理します。 全3回を通じて、「AIが賢いかどうか」ではなく、「AIを業務に載せるために何を設計するか」を考えていきます。 第1回となる本記事では、2025年に起きた2つの事例を出発点に、なぜいま「責任設計」が問題になっているのかを見ていきます。 上図は、本シリーズ全体で扱う論点の全体像です。 AIエージェントの導入は、技術的なモデル選定だけでは完結せず、権限設計、契約、監査、品質監視、保険、異常時対応まで含めた設計が必要になります。 第1回ではまず、なぜこうした設計が求められるようになったのかを、実際の事例から見ていきたいとおもいます なお、本シリー

By Qualiteg コンサルティング
PII検出の混同行列では見えないもの ― 認識器間衝突と統合テスト

PII検出の混同行列では見えないもの ― 認識器間衝突と統合テスト

こんにちは!Qualiteg研究部です! 個人情報(PII: Personally Identifiable Information)の自動検出は、テキスト中から特定の表現を抽出し、それがどの種類のPIIに当たるかを判定する問題として捉えることができます。 電話番号、人名、口座番号、金額表現など、検出対象のPIIタイプが増えるにつれて、単一の手法ではカバーしきれなくなり、性質の異なる複数の認識器(Recognizer)を組み合わせるマルチレイヤー構成が採用されるのが一般的です。 本稿で想定しているのは、ユーザーが海外製LLMにチャットを送信する直前に、その内容に個人情報や機密情報が含まれていないかをリアルタイムに検査するユースケースです。 この場面では、検出精度だけでなく、送信体験を損ねない速度が不可欠です。 高精度なLLMやBERT系モデル、NERベースの手法は有力ですが、送信前チェックの第一層として常時適用するには、レイテンシやコストの面で不利になることがあります。 そのため、本システムでは、正規表現、辞書、軽量なルールベース認識器を組み合わせた超高速な第一層を設け、そ

By Qualiteg 研究部, Qualiteg AIセキュリティチーム
日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(3月6日版)

日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(3月6日版)

はじめに 本レポートは、Nejumi Leaderboard 4のベンチマークデータ(2026/3/6版)に基づいて、日本語対応LLMの性能を総合的に分析したものです。 前回は 2025/12/18 版の分析レポート を公開しましたが、約3か月でまたもや大きな変動がありました! (定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です) Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。 本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。 オープンソースモデルについて Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、モデルによっては「オープンソース」と呼ぶには不十分な場合があるため本稿では、「オープンソースモデル」ではなく「オープンモデル」と表現しています。 ベンチマーク分析について 本レポートは

By Qualiteg コンサルティング, Qualiteg プロダクト開発部
日経トレンディ 2026年4月号に Bestllam の広告を掲載しました

日経トレンディ 2026年4月号に Bestllam の広告を掲載しました

こんにちは! このたび、日経トレンディ 2026年4月号(2026年3月4日発売、雑誌)に、当社のエンタープライズ向け統合型AIプラットフォーム「Bestllam」を掲載しました。 日経トレンディ(雑誌)は全国の書店・コンビニエンスストアにてお買い求めいただけますので、お手に取った際はぜひご覧くださいませ。 Bestllam とは? Bestllam は、「チャットで指示するだけ。仕事が終わっている。」をコンセプトに開発した、エンタープライズ向けの統合型AIプラットフォームです。 主な特長 20種類以上のLLMを、契約一本で OpenAI GPT、Anthropic Claude、Google Gemini をはじめ、DeepSeek、Qwen、Llama など商用・オープンソース合わせて20種類以上のLLMを1つの契約で利用できます。各プロバイダと個別に契約を結ぶ手間が不要になります。 6つのLLMに同時質問して、最適な答えを選択 同じ質問を複数のLLMに一括投げかけ、回答を比較・検討できます。各モデルの得意・不得意を活かすことで、重要な意思決定や精度が求められる業

By Qualiteg ビジネス開発本部 | マーケティング部