日々の開発Tips

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

Qualiteg プロダクト開発部

Qualiteg プロダクト開発部

— 3 min read
その処理、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の再インストール

方法１か方法２で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

企業セキュリティはなぜ複雑になったのか？ 〜AD+Proxyの時代から現代のクラウド対応まで〜

企業セキュリティはなぜ複雑になったのか？ 〜AD+Proxyの時代から現代のクラウド対応まで〜

こんにちは！ ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、 「AIに機密情報を送ってしまうリスク」 が新たなセキュリティ課題として浮上しています。 この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。 すると、ある疑問が浮かんできます。 「なんでこんなに複雑になってるんだっけ？」 企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。 アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。 当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。 本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。 第1章：観測点を集約できた時代 ― オンプレAD + Proxy（〜2010年代前半） 統制しやすかったモデル かつ

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
【IT温故知新】WS-* の栄光と黄昏：エンタープライズITはいかにして「実装」に敗北したか

【IT温故知新】WS-* の栄光と黄昏：エンタープライズITはいかにして「実装」に敗北したか

こんにちは。 —— 2003年のSOAから、2026年のAIへ —— この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。 歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。 そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。 だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。 はじめに：20年前の熱狂を覚えていますか 2000年代初頭。 私はSOA（サービス指向アーキテクチャ）に本気で取り組んでいました。 当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。 カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。 SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。 あれから

By Qualiteg コンサルティング
DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

こんにちは！Qualitegプロダクト開発部です！ 本日は Docker環境でPythonをソースからビルドした際に発生した、GCCの内部コンパイラエラー（Segmentation fault） について共有します。 一見すると「リソース不足」や「Docker特有の問題」に見えますが、実際には PGO（Profile Guided Optimization）とLTO（Link Time Optimization）を同時に有効にした場合に、GCC自身がクラッシュするケースでした。 ただ、今回はDockerによって問題が隠れやすいという点もきづいたので、あえてDockerを織り交ぜた構成でのPythonソースビルドとＧＣＣクラッシュについて実際に発生した題材をもとに共有させていただこうとおもいます 同様の構成でビルドしている方の参考になれば幸いです TL;DR * Docker内でPythonを --enable-optimizations --with-lto 付きでソースビルドすると GCCが internal compiler error（Segmentati

By Qualiteg プロダクト開発部
サブスクビジネス完全攻略 第2回～「解約率5%」が1年後に半分の顧客を消す恐怖と、それを防ぐ科学

サブスクビジネス完全攻略 第2回～「解約率5%」が1年後に半分の顧客を消す恐怖と、それを防ぐ科学

こんにちは！ Qualitegコンサルティングです！ 前回の第1回では、サブスクリプションビジネスの基本構造と、LTV・ユニットエコノミクスという革命的な考え方を解説しました。「LTV > 3 × CAC」という黄金律、覚えていますか？ サブスクビジネス完全攻略 第1回～『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイドなぜサブスクリプションモデルが世界を変えているのか、でもAI台頭でSaaSは終わってしまうの？ こんにちは！ Qualitegコンサルティングです！ 新規事業戦略コンサルタントとして日々クライアントと向き合う中で、ここ最近特に増えているのがSaaSビジネスに関する相談です。興味深いのは、その背景にある動機の多様性です。純粋に収益モデルを改善したい企業もあれば、 「SaaS化を通じて、うちもデジタルネイティブ企業として見られたい」 という願望を持つ伝統的な大企業も少なくありません。 SaaSという言葉が日本のビジネスシーンに本格的に浸透し始めたのは2010年代前半。それから約15年が経ち、今やSaaSは「先進的な企業の証」のように扱われています。

By Qualiteg コンサルティング