問題の概要：CUDAバージョン競合によるエラー
AI開発、特に深層学習のモデルトレーニングや推論を行う際、異なるフレームワークやプロジェクトが要求するCUDAバージョンが異なることがよくあります。例えば、PyTorchのあるバージョンはCUDA 11.3を、TensorFlowの別のバージョンはCUDA 11.8を必要とする場合です。このような状況で、単一のCUDAバージョンしかシステムにインストールされていないと、以下のような典型的なエラーに遭遇します。
ImportError: libcudart.so.11.3: cannot open shared object file: No such file or directory
あるいは、nvcc --versionで確認されるコンパイラバージョンと、プログラムが実行時に参照するランタイムライブラリのバージョンが一致せず、動作が不安定になることもあります。システムのデフォルトCUDAを頻繁に書き換えるのはリスクが高く、プロジェクトごとに環境を切り替える必要が出てきます。
原因の解説：シンボリックリンクとパスの管理
これらのエラーの根本原因は、CUDAツールキットのインストールが、/usr/local/cuda というシンボリックリンクを介して管理されていることにあります。通常、CUDAをインストールすると、/usr/local/cuda-11.3、/usr/local/cuda-11.8 のようなバージョン付きの実ディレクトリが作成され、/usr/local/cuda はそのいずれかを指すシンボリックリンクとして設定されます。
問題は、このシンボリックリンクを手動で変更したり、異なるインストーラーが上書きしたりすることで、システム全体で使用されるCUDAバージョンが意図せず切り替わってしまう点にあります。また、LD_LIBRARY_PATHなどの環境変数が適切に設定されていないと、実行時に正しいバージョンの共有ライブラリ（libcudart.soなど）を見つけられず、前述のエラーが発生します。
解決方法：update-alternativesによる体系的管理
Debian/Ubuntu系のLinuxディストリビューションに標準搭載されている update-alternatives ユーティリティを使用すると、複数インストールされたCUDAバージョンを体系的に管理し、ユーザー権限で安全に切り替えることができます。このツールは、/usr/local/cuda のような汎用パスを、登録された複数の候補（各CUDAバージョン）のいずれかに向ける「シンボリックリンクの管理システム」です。
ステップ1: 既存のCUDAバージョンをupdate-alternativesに登録する
まず、システムにインストール済みのCUDAバージョンを update-alternatives の管理下に置きます。ここではCUDA 11.3と11.8がインストールされている例で説明します。
# CUDA 11.3を登録
sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-11.3 100
# CUDA 11.8を登録
sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-11.8 80
コマンドの構成は --install [リンクパス] [グループ名] [候補のパス] [優先度] です。
/usr/local/cuda: 管理対象の汎用シンボリックリンク。cuda: このリンクを管理するグループ名。/usr/local/cuda-11.3: 登録する実際のCUDAインストールパス。100: 優先度。数字が大きいほどデフォルトとして選ばれやすくなります。
ステップ2: 使用するCUDAバージョンを切り替える
登録が完了したら、以下のコマンドでインタラクティブにバージョンを選択できます。
sudo update-alternatives --config cuda
実行すると、以下のような選択メニューが表示されます。
There are 2 choices for the alternative cuda (providing /usr/local/cuda).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/local/cuda-11.3 100 auto mode
1 /usr/local/cuda-11.3 100 manual mode
2 /usr/local/cuda-11.8 80 manual mode
Press <enter> to keep the current choice[*], or type selection number:
切り替えたいバージョンの番号（この例では2）を入力し、Enterを押します。これで、/usr/local/cuda が指定したバージョンを指すように切り替わります。
ステップ3: 環境変数の設定を確認・更新する
update-alternativesでシンボリックリンクを切り替えても、シェルの環境変数が古いパスをキャッシュしている場合があります。設定を反映させるために、~/.bashrc または ~/.zshrc に以下のような設定を追加し、シェルを再起動するか source コマンドを実行します。
# ~/.bashrc または ~/.zshrc に追加
export CUDA_HOME=/usr/local/cuda
export PATH=${CUDA_HOME}/bin:${PATH}
export LD_LIBRARY_PATH=${CUDA_HOME}/lib64:${LD_LIBRARY_PATH}
設定を反映させます。
source ~/.bashrc # または source ~/.zshrc
ステップ4: 切り替えの確認
バージョン切り替えが正しく行われたか、以下のコマンドで確認します。
# nvccコンパイラのバージョン確認
nvcc --version
# CUDAランタイムのバージョン確認 (Python環境例)
python -c "import torch; print(torch.version.cuda)" # PyTorchの場合
# または
nvidia-smi # ドライバーがサポートする最高バージョンと、現在プロセスで使われているランタイムバージョンを確認可能
コード例・コマンド例
登録済みのCUDA候補を一覧表示する
sudo update-alternatives --list cuda
現在の選択状態を詳細に表示する
sudo update-alternatives --display cuda
自動モードに戻す（優先度が最も高いバージョンを自動選択）
sudo update-alternatives --auto cuda
登録を解除する（CUDA 11.3を削除する例）
注意: 実際のCUDAインストールディレクトリは削除されず、管理リストから外れるだけです。
sudo update-alternatives --remove cuda /usr/local/cuda-11.3
まとめ・補足情報
update-alternativesを活用したCUDAバージョン管理は、システムの基幹部分を直接いじることなく、安全かつ柔軟に開発環境を切り替えるための強力な手法です。これにより、プロジェクトごとに異なるCUDAバージョン要件に対応する労力を大幅に削減できます。
重要な補足点:
- NVIDIAドライバーとの互換性: CUDA Toolkitのバージョンは、インストールされているNVIDIAドライバーのバージョンによってサポートされる範囲が決まります。
nvidia-smiで確認できる「CUDA Version」はドライバーがサポートする最高バージョンです。それ以下のCUDA Toolkitは通常問題なく動作します。 - 仮想環境との併用: PyTorchやTensorFlowなどのフレームワークは、pipやcondaでインストールする際に特定のCUDAバージョンにバインドされたパッケージを選択します。システムのCUDAを切り替えても、仮想環境内に既にインストールされたパッケージのCUDAバージョンは変わりません。新しい仮想環境を作成し、システムCUDAに合わせたパッケージをインストールし直す必要があります。
- より高度な管理: プロジェクトごとに環境を完全に分離したい場合は、Dockerコンテナを使用する方法がさらに確実です。コンテナ内に必要なCUDAバージョンを含めた完全に独立した環境を構築できます。
以上、update-alternativesを使った複数CUDAバージョンの管理方法を詳しく解説しました。この手法をマスターすることで、AI開発における環境構築のストレスを減らし、本質的なモデル開発や実験に集中できるようになるでしょう。