はい、承知いたしました。DockerとNVIDIA Container Toolkitを連携させてGPUを最大限に活用する方法について、約5000語の詳細な記事を記述します。

Dockerと連携！NVIDIA Container ToolkitでGPUを最大限に活かす

1. はじめに：なぜ今、GPUとコンテナの融合が必要なのか？

現代のテクノロジーにおいて、GPU（Graphics Processing Unit）は単なる画像処理装置の枠を超え、データサイエンス、機械学習、深層学習、高性能計算（HPC）、シミュレーションなど、多岐にわたる分野で不可欠な存在となっています。特にディープラーニングのモデルトレーニングにおいては、その並列計算能力が飛躍的な性能向上をもたらし、イノベーションの原動力となっています。

一方で、ソフトウェア開発やデプロイの現場では、コンテナ技術、とりわけDockerが標準的なツールとして広く普及しています。Dockerは、アプリケーションとその依存関係を一つのパッケージとしてまとめ、どのような環境でも一貫して動作させることを可能にします。これにより、「私の環境では動くのに…」といった環境依存の問題を解消し、開発、テスト、デプロイのプロセスを劇的に効率化します。

しかし、GPUを利用するアプリケーションをDockerコンテナ内で動作させる際には、特有の課題がありました。コンテナはホストシステムから分離されており、GPUハードウェアやそのドライバー、CUDAライブラリといった低レベルのリソースへのアクセスが直接的ではないためです。これらの課題を解決し、Dockerコンテナ内でGPUのパワーを最大限に引き出すための鍵となるのが、「NVIDIA Container Toolkit」（旧称nvidia-docker2）です。

この記事では、NVIDIA Container Toolkitの基本から、その仕組み、インストール方法、具体的な利用例、さらには高度な活用方法やトラブルシューティングに至るまで、網羅的かつ詳細に解説します。これにより、GPUを必要とするアプリケーション開発者やデータサイエンティストが、Dockerの恩恵を受けながら、GPUの性能をフルに活用できる環境を構築できるようになることを目指します。

2. GPUコンピューティングの基礎とDockerの役割

GPUとDockerを組み合わせる意義を深く理解するために、まずはそれぞれの基本的な概念と、それらがなぜ融合されるべきなのかを見ていきましょう。

2.1. GPUとは？そしてCUDAの重要性

2.1.1. CPUとGPUの違い：並列処理の力

CPU（Central Processing Unit）は、複雑なタスクを高速に処理することに特化したプロセッサであり、少数の強力なコアで構成されています。一方、GPUは、大量の単純な計算を同時に実行することに特化しており、数千もの多数のコア（ストリーミングマルチプロセッサ、SMs）を持つことができます。

この設計の違いが、それぞれの得意分野を分けます。CPUは逐次処理や分岐予測に優れ、汎用的なOSやアプリケーションの実行に適しています。対してGPUは、画像レンダリング、科学技術計算、そして今日の主役であるディープラーニングのように、膨大な量の並列計算が必要なタスクにおいて、CPUをはるかに凌駕する性能を発揮します。

2.1.2. CUDA：NVIDIA GPUをプログラミングするためのプラットフォーム

NVIDIAは、自社のGPU上で並列計算を効率的に行うためのソフトウェア開発プラットフォーム「CUDA (Compute Unified Device Architecture)」を提供しています。CUDAは、GPUプログラミングモデル、API、ライブラリ、開発ツールキットの集合体です。

CUDAが登場する以前は、GPUはグラフィック用途に特化しており、汎用的な計算にはアクセスしにくいものでした。しかし、CUDAの登場により、C/C++などの一般的なプログラミング言語を使ってGPUをプログラミングすることが可能になり、GPUコンピューティングの扉が大きく開かれました。ディープラーニングフレームワーク（TensorFlow、PyTorchなど）がGPUを活用できるのも、その根底にCUDAがあるためです。

GPUコンピューティングでは、ホスト（CPU）がメインの処理を制御し、計算量の多い部分をデバイス（GPU）にオフロードするという協調的なモデルで動作します。この際、ホストとデバイス間でデータ転送が発生するため、効率的なデータ管理も重要になります。

2.2. Dockerの基礎と利点

Dockerは、アプリケーションをコンテナという形でパッケージ化し、どの環境でも一貫して実行できるようにするオープンソースプラットフォームです。

2.2.1. コンテナとは何か？仮想マシンとの比較

仮想マシン (VM): ホストOSの上にハイパーバイザーを介してゲストOS（完全なOS）を起動し、その上でアプリケーションを実行します。これにより、完全な分離と異なるOSの実行が可能ですが、VMごとにOSのオーバーヘッドがあるため、リソース消費が大きく、起動に時間がかかります。
コンテナ (Docker): ホストOSのカーネルを共有し、その上にアプリケーションと、そのアプリケーションが動作するために必要な依存関係（ライブラリ、設定ファイルなど）だけをパッケージ化します。OSのオーバーヘッドがないため、軽量で高速に起動し、リソース効率も優れています。分離性はVMほど厳密ではありませんが、十分な隔離を提供します。

2.2.2. Dockerの主要な利点

ポータビリティと再現性: コンテナイメージとしてパッケージ化されたアプリケーションは、Dockerがインストールされていれば、開発環境、テスト環境、本番環境のどこでも同じように動作します。「私の環境では動くのに…」という問題が解消されます。
分離性: 各コンテナは互いに隔離されており、ホストシステムや他のコンテナに影響を与えることなく動作します。これにより、異なるバージョンのライブラリやアプリケーションを同一ホスト上で安全に実行できます。
開発とデプロイの効率化: Dockerfileを使えば、アプリケーションの環境構築手順をコードとして管理でき、CI/CDパイプラインに簡単に組み込むことができます。デプロイも、コンテナイメージをプルして実行するだけと非常にシンプルです。
リソース効率: VMに比べてオーバーヘッドが少ないため、より多くのアプリケーションを同一ホスト上で効率的に実行できます。

2.3. なぜGPUとDockerを組み合わせるのか？

GPUの強力な計算能力とDockerのポータビリティ・再現性を組み合わせることは、AI/MLやHPCのワークフローにおいて計り知れないメリットをもたらします。

環境構築の複雑さの解消:
- GPUアプリケーションは、NVIDIAドライバー、CUDAツールキット、cuDNN、そしてTensorFlowやPyTorchのようなディープラーニングフレームワークなど、多岐にわたる依存関係を持ちます。これらのバージョン管理と互換性の確保は非常に複雑です。
- Dockerは、これらの依存関係をすべてコンテナイメージ内に封じ込めることで、環境構築の手間を劇的に削減します。
依存関係の管理と衝突の回避:
- 複数のプロジェクトで異なるバージョンのCUDAやフレームワークが必要になる場合、ホストシステム上で共存させるのは困難です。
- コンテナを使えば、各プロジェクトが独自の独立したGPU環境を持つことができるため、依存関係の衝突を心配する必要がなくなります。
複数プロジェクトでのGPU共有:
- 限られたGPUリソースを複数のユーザーやプロジェクトで効率的に共有する場合、Dockerコンテナは理想的な分離単位となります。各コンテナは必要なGPUリソースにのみアクセスします。
CI/CDとの連携とデプロイの容易さ:
- GPUを利用するアプリケーションのCI/CDパイプラインにDockerを組み込むことで、ビルド、テスト、デプロイのプロセスを自動化・標準化できます。
- モデルのトレーニング済みイメージをコンテナ化し、推論サービスとしてデプロイする際も、Dockerは非常に強力なツールとなります。
再現可能な実験環境の提供:
- 研究や開発において、特定のGPU環境（CUDA、cuDNN、フレームワークバージョン）で実験を行い、その結果を再現することは非常に重要です。Dockerイメージを使えば、完全に同じ環境をいつでも再現できます。

これらのメリットを享受するためには、DockerコンテナがホストのGPUにどのようにアクセスできるかが鍵となります。そこで登場するのが、NVIDIA Container Toolkitです。

3. NVIDIA Container Toolkit (nvidia-docker2 / libnvidia-container) とは？

Dockerコンテナ内からホストのGPUに直接アクセスすることは、標準のDocker機能だけでは実現できません。なぜなら、Dockerはデフォルトでホストのハードウェアデバイスにアクセスする許可を与えていないからです。ここにNVIDIA Container Toolkitが果たす役割があります。

3.1. 課題の明確化：標準DockerでのGPUアクセスの限界

通常のDockerコンテナは、ホストのファイルシステムから分離されており、/dev ディレクトリ以下のデバイスファイル（例: /dev/nvidia0, /dev/nvidiactl, /dev/nvidia-uvm など）に直接アクセスできません。また、NVIDIA GPUを動かすために必要な低レベルの共有ライブラリ（libcuda.so, libnvidia-ml.so など）も、通常はホストシステムにインストールされており、コンテナ内部には存在しません。

これらの問題を解決するために、以前は「--device オプションでデバイスファイルを個別にマウントする」や「--volume オプションでライブラリをマウントする」といった手動での設定が必要でした。しかし、これらは手間がかかり、異なるGPU構成やドライババージョンに対応するのが困難でした。

3.2. 解決策としてのNVIDIA Container Toolkit

NVIDIA Container Toolkitは、このGPUアクセスに関する課題を解決するためにNVIDIAが提供するツールセットです。これにより、ユーザーは通常のDockerコマンドに --gpus オプションを追加するだけで、コンテナ内でGPUをシームレスに利用できるようになります。

3.2.1. 旧来のnvidia-docker1からnvidia-docker2、そしてlibnvidia-containerへの変遷

NVIDIAのGPU対応コンテナ技術は、歴史的な変遷をたどっています。

nvidia-docker1 (非推奨): 独自の nvidia-docker コマンドラインツールとして提供されていました。Dockerコマンドのラッパーとして機能し、GPUアクセスに必要な設定を自動的に追加していました。しかし、Docker本体との統合が不十分で、複雑なワークフローには対応しきれませんでした。
nvidia-docker2 (旧名称、現在はContainer Toolkitの一部): Dockerのプラグインメカニズムを利用し、docker コマンド自体に daemon.json を通じて設定を注入する方式に変わりました。これにより、従来の docker run コマンドに --runtime=nvidia オプション（後に --gpus オプションが導入される）を追加するだけでGPUが利用できるようになり、Dockerとの統合が大幅に強化されました。
NVIDIA Container Toolkit (現在の名称): nvidia-docker2の進化版であり、より汎用的な「Container Toolkit」という名称で提供されています。中心となるのは低レベルライブラリの libnvidia-container です。これは、特定のコンテナランタイム（Dockerの runc など）がGPUリソースにアクセスできるようにするための共通インターフェースを提供します。これにより、Dockerだけでなく、Kubernetesなどの他のコンテナオーケストレーションシステムでも一貫してGPUを利用できるようになりました。

3.2.2. `--gpus all` オプションの実現メカニズム

現在、NVIDIA Container Toolkitをインストールすると、Docker EngineのOCI (Open Container Initiative) ランタイムが拡張され、--gpus オプションが利用可能になります。例えば、docker run --gpus all ... と実行すると、Container Toolkitが以下の処理を自動的に行います。

デバイスファイルのマウント: ホストの /dev/nvidia* デバイスファイル（GPU本体、制御デバイス、メモリ管理ユニットなど）をコンテナ内に自動的にマウントします。
GPU関連ライブラリのパススルー: ホストにインストールされているNVIDIAドライバーの共有ライブラリ（libcuda.so, libnvidia-ml.so など）をコンテナ内に自動的に「パススルー」またはマウントします。これにより、コンテナ内のCUDAアプリケーションがこれらのライブラリを見つけ、ホストのGPUと通信できるようになります。
CUDAランタイムの提供: コンテナ内にCUDAランタイム（libcuda.so など）がない場合でも、ホストのランタイムを適切に利用できるようにします。これにより、コンテナイメージを軽量化し、ホストのドライバーバージョンとの互換性を保つことができます。

これらの処理は、NVIDIA Container Toolkitが提供する nvidia-container-runtime という特別なOCIランタイムフックによって実現されます。Dockerはコンテナを起動する際に、このフックを呼び出し、GPUに必要な設定をコンテナ環境に注入するのです。

3.3. 仕組みの深掘り：NVIDIA Container RuntimeとOCIフック

NVIDIA Container Toolkitの核心は、OCI (Open Container Initiative) の仕様に準拠したカスタムランタイムである nvidia-container-runtime です。Dockerは、コンテナを実行する際にOCIランタイムを使用します（デフォルトは runc）。

NVIDIA Container Toolkitをインストールすると、Dockerのデーモン設定 (/etc/docker/daemon.json) に nvidia ランタイムが追加されます。この nvidia ランタイムは、基本的に標準の runc をラップし、コンテナ起動前にGPUアクセスに必要な前処理（デバイスファイルの追加、ライブラリのバインドマウント、環境変数の設定など）を行うフック（hook）を実行します。

具体的には：
* libnvidia-container: これは、GPUデバイス検出、ドライバーライブラリのパス検出、CUDAアプリケーションに必要な環境変数の生成など、GPU関連の低レベルな操作を行うライブラリです。nvidia-container-runtime はこのライブラリを利用します。
* nvidia-container-cli: libnvidia-container の機能をコマンドラインから利用するためのツールです。トラブルシューティングや、特定のデバイス情報を取得する際に役立ちます。例えば、nvidia-container-cli info でGPU環境の詳細を確認できます。

このアーキテクチャにより、Dockerは、あたかもホストのGPUがコンテナ内部に存在するかのように振る舞い、アプリケーションは通常のGPU計算を行うことができます。ホストのNVIDIAドライバーとコンテナ内のCUDAバージョンとの互換性も、この仕組みによって効率的に管理されます。つまり、コンテナ内のCUDAバージョンはホストのドライバーバージョンと一致している必要はなく、ドライバーがサポートする最小バージョン以上であれば問題なく動作します。

4. NVIDIA Container Toolkitのインストールと設定

NVIDIA Container Toolkitを最大限に活用するためには、適切な環境構築が不可欠です。ここでは、一般的なLinux環境（Ubuntuを例に）でのインストール手順を詳述します。

4.1. 前提条件

NVIDIA GPU:
- NVIDIA製のGPUが必要です。Pascalアーキテクチャ以降（例: GeForce GTX 10xxシリーズ、RTXシリーズ、Quadro、Teslaなど）が推奨されます。
対応するNVIDIAドライバーのインストール:
- ホストOSにNVIDIAドライバーが正しくインストールされている必要があります。これは、GPUを認識し、CUDAアプリケーションが動作するための基盤となります。最新の安定版ドライバーをNVIDIAの公式サイトからダウンロードするか、ディストリビューションのリポジトリからインストールすることをお勧めします。
- インストール後、nvidia-smi コマンドが正常に動作し、GPU情報が表示されることを確認してください。
Docker Engineのインストール:
- Docker CE (Community Edition) または Docker EE (Enterprise Edition) がホストOSにインストールされている必要があります。Dockerの公式ドキュメントに従ってインストールしてください。
- docker run hello-world が正常に動作することを確認してください。

4.2. インストール手順（Linuxベース、Ubuntu 20.04/22.04 LTSを例に）

以下の手順は、Docker公式ドキュメントおよびNVIDIA Container Toolkitの公式ドキュメントに基づいています。

古いnvidia-dockerのアンインストール（もしあれば）:
bash sudo apt-get purge nvidia-docker2 nvidia-container-toolkit nvidia-container-runtime # 古いツールキットも含む sudo apt-get autoremove
NVIDIA Container Toolkit のリポジトリとGPGキーの追加:
NVIDIA Container Toolkitのパッケージは、DockerやNVIDIAの公式リポジトリから提供されます。
“`bash
# GPGキーの追加
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg –dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

リポジトリの追加 (Ubuntu 20.04/22.04 LTS の場合)

Ubuntuのバージョンに合わせて、distribution名を確認

例: Ubuntu 20.04 -> focal, Ubuntu 22.04 -> jammy

distribution=$(. /etc/os-release;echo $ID$VERSION_ID)

echo “deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://nvidia.github.io/libnvidia-container/ubuntu/$distribution stable” | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update
`` **注意点:**distributionの部分は、お使いのUbuntuのバージョンに合わせてfocal(20.04) やjammy` (22.04) となります。他のLinuxディストリビューション（CentOS/RHELなど）の場合は、NVIDIA Container Toolkitの公式ドキュメントを参照してください。
NVIDIA Container Toolkit のインストール:
bash sudo apt-get install -y nvidia-container-toolkit
このコマンドにより、libnvidia-container、nvidia-container-runtime、nvidia-container-cli など、必要なコンポーネントがインストールされます。
Dockerデーモンの再起動:
インストール後、Dockerデーモンが新しいランタイム設定を読み込むように、再起動が必要です。
bash sudo systemctl restart docker
この再起動により、/etc/docker/daemon.json に"runtimes": { "nvidia": { ... } } のような設定が自動的に追加されることがあります。もし追加されていない場合は、手動で追加することも検討しますが、通常は自動で構成されます。

4.3. 確認方法

インストールが成功したかどうかを確認するためには、NVIDIAが提供するCUDAベースイメージを使って簡単なコンテナを実行してみるのが最も確実です。

nvidia-smi の実行:
bash docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi
- --rm: コンテナ終了時に自動的に削除します。
- --gpus all: ホストのすべてのGPUをコンテナ内で利用可能にします。
- nvidia/cuda:11.8.0-base-ubuntu22.04: NVIDIAが公式に提供するCUDAベースイメージです。バージョンは適宜変更してください。
- nvidia-smi: コンテナ内でGPU情報を表示するコマンドです。
期待される出力例:
+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | Migration C. | |===============================+======================+======================| | 0 NVIDIA GeForce RTX 3080 On | 00000000:01:00.0 Off | N/A | | 32% 45C P8 26W / 320W | 0MiB / 10240MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ ... (以下略)
もし上記のような nvidia-smi の出力が得られれば、NVIDIA Container Toolkitは正常に動作しています。
nvidia-container-cli info の実行（オプション）:
このコマンドは、Container ToolkitがGPUリソースをどのように見ているか、診断情報を表示します。
bash nvidia-container-cli info
期待される出力例:
NVRM version: 535.104.05 CUDA Driver Version: 12.2 ... Detected CUDA versions: 11.0 11.1 ... (ホストにインストールされているCUDAツールキットのバージョン)

4.4. トラブルシューティングのヒント

docker: Error response from daemon: OCI runtime create failed: ... や --gpus all が認識されない場合:
- Dockerデーモンが再起動されているか確認してください (sudo systemctl status docker)。
- /etc/docker/daemon.json に"default-runtime": "nvidia" または "runtimes": { "nvidia": { ... } } のような設定が正しく行われているか確認してください（ただし、最近のバージョンでは --gpus オプションがこの設定を自動的に利用するため、明示的に記述は不要な場合が多いです）。
- nvidia-container-toolkit パッケージが正しくインストールされているか確認してください (dpkg -l | grep nvidia-container-toolkit)。
コンテナ内で NVIDIA Driver not found や CUDA Error: ... が出る場合:
- ホストOSにNVIDIAドライバーが正しくインストールされ、nvidia-smi がホストで動作するか確認してください。
- ホストのNVIDIAドライバーと、使用しているCUDAベースイメージのCUDAバージョンとの互換性を確認してください。基本的にはドライバーがCUDAの特定バージョン以上であれば動きますが、特定の組み合わせで問題が生じることもあります。
- コンテナイメージ内のCUDAランタイム（libcuda.soなど）のパスが正しく設定されているか確認してください。公式の nvidia/cuda イメージを使用していれば問題ありません。
パーミッションの問題:
- Dockerコマンドを実行するユーザーが docker グループに属しているか確認してください (groups $USER)。属していない場合は sudo usermod -aG docker $USER を実行し、再ログインしてください。
- sudo なしで docker コマンドが実行できるようになったことを確認してください。

これらの手順と確認、トラブルシューティングのヒントに従うことで、NVIDIA Container Toolkitのインストールと設定をスムーズに行い、GPU対応コンテナの準備が整います。

5. DockerとGPU連携の具体的な実践

NVIDIA Container Toolkitのセットアップが完了したら、実際にGPUをフル活用するDockerコンテナの作成と実行に取り掛かりましょう。

5.1. 基本的なGPUコンテナの実行

最も基本的なGPU対応コンテナの実行は、--gpus オプションを使用することです。

5.1.1. すべてのGPUを利用する

ホストに搭載されているすべてのNVIDIA GPUをコンテナ内で利用可能にするには、--gpus all を指定します。

bash docker run --rm --gpus all nvidia/cuda:11.8.0-runtime-ubuntu22.04 bash -c "nvidia-smi && python -c 'import torch; print(torch.cuda.is_available())'"
* nvidia/cuda:11.8.0-runtime-ubuntu22.04: ディープラーニングフレームワークを動かすためのCUDAランタイム環境が揃ったイメージです。開発用には -devel バージョンが、本番稼働用には -runtime または -base バージョンが適しています。
* bash -c "...": コンテナ内で複数のコマンドを実行する際に便利です。
* nvidia-smi: コンテナ内のGPU情報が表示されます。
* python -c 'import torch; print(torch.cuda.is_available())': PyTorchがGPUを認識しているか確認するPythonコードです。True が返されれば成功です。

5.1.2. 特定のGPUを指定する

複数のGPUを持つシステムでは、特定のGPUのみをコンテナに割り当てたい場合があります。これは、GPUのID（nvidia-smi で表示される番号）またはUUIDで指定できます。

IDで指定:
bash # GPU 0 と GPU 1 のみを使用 docker run --rm --gpus "device=0,1" nvidia/cuda:11.8.0-runtime-ubuntu22.04 nvidia-smi
またはショートハンドで
bash docker run --rm --gpus 0,1 nvidia/cuda:11.8.0-runtime-ubuntu22.04 nvidia-smi
この場合、コンテナ内からは指定されたGPUのみが見えます。
UUIDで指定:
GPUのUUIDは nvidia-smi -L で確認できます。UUIDはデバイスIDよりも永続的で、物理的な挿し換えなどによるデバイスIDの変更に影響されません。
“`bash
# まずUUIDを確認
nvidia-smi -L
# 出力例: GPU 0: NVIDIA GeForce RTX 3080 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

UUIDを指定して実行

docker run –rm –gpus “device=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx” nvidia/cuda:11.8.0-runtime-ubuntu22.04 nvidia-smi
“`

5.1.3. 利用可能なGPUリソースの制限

特定の機能（例：グラフィック機能など）を無効にして、純粋な計算機能のみをコンテナに提供することも可能です。
bash docker run --rm --gpus "device=0,capabilities=compute,utility" nvidia/cuda:11.8.0-runtime-ubuntu22.04 nvidia-smi
capabilities オプションは、コンテナがGPUに対してどのような権限を持つかを細かく制御するために使われます。compute はCUDA計算、utility はnvidia-smiのような管理ツールへのアクセスを許可します。

5.2. DockerfileでのGPU対応イメージの構築

GPUを利用するアプリケーションを配布・デプロイするために、独自のDockerイメージを構築するのが一般的です。

5.2.1. `FROM nvidia/cuda` の利用

NVIDIAは、CUDAツールキット、cuDNN、そして人気のディープラーニングフレームワークがプリインストールされた、最適化されたベースイメージをDocker Hubの nvidia/cuda や nvcr.io/nvidia で提供しています。これらを FROM ステートメントで利用することで、一からCUDA環境を構築する手間を省けます。

CUDAベースイメージの種類と使い分け:

nvidia/cuda:<version>-base-<os_version>:
- 最も基本的なイメージで、CUDAランタイムと最小限のOS環境のみが含まれます。非常に軽量ですが、コンパイルに必要な開発ツールなどは含まれません。
nvidia/cuda:<version>-runtime-<os_version>:
- CUDAランタイムと、一般的なアプリケーションの実行に必要なライブラリが含まれます。ディープラーニングモデルの推論など、実行環境として適しています。
nvidia/cuda:<version>-devel-<os_version>:
- CUDAランタイムに加えて、CUDA開発ツールキット（コンパイラ、ヘッダーファイル、開発用ライブラリなど）が含まれます。カスタムCUDAカーネルのコンパイルや、ソースコードからディープラーニングフレームワークをビルドする際に必要となります。

例：PyTorch環境を構築するDockerfile

“`dockerfile

開発・トレーニング用にはdevelイメージを選択

FROM nvidia/cuda:11.8.0-devel-ubuntu22.04

LABEL maintainer=”Your Name your.email@example.com“

環境変数の設定 (必要に応じて)

ENV DEBIAN_FRONTEND=noninteractive
ENV PYTHON_VERSION=3.9

必要なパッケージのインストール

RUN apt-get update && apt-get install -y –no-install-recommends \
python${PYTHON_VERSION} \
python3-pip \
python3-venv \
git \
build-essential \
&& rm -rf /var/lib/apt/lists/*

Python仮想環境の作成とアクティベート (推奨)

ENV VIRTUAL_ENV=/opt/venv
RUN python${PYTHON_VERSION} -m venv ${VIRTUAL_ENV}
ENV PATH=”${VIRTUAL_ENV}/bin:${PATH}”

PyTorchのインストール

CUDAバージョンに合わせて最適なPyTorchをインストール

公式サイト (pytorch.org) のインストールコマンドを参考に

RUN pip install –no-cache-dir torch==2.0.1+cu118 torchvision==0.15.2+cu118 torchaudio==2.0.2+cu118 –index-url https://download.pytorch.org/whl/cu118

その他のPythonライブラリのインストール

COPY requirements.txt .

RUN pip install –no-cache-dir -r requirements.txt

作業ディレクトリの設定

WORKDIR /app

アプリケーションコードのコピー

COPY . /app

エントリポイントの設定

CMD [“python”, “your_script.py”]

**ビルドと実行:**bash
docker build -t my-gpu-app:latest .
docker run –rm –gpus all my-gpu-app:latest python -c “import torch; print(torch.cuda.is_available()); print(torch.zeros(1).cuda())”
“`
この例では、コンテナ内部でPyTorchがGPUを認識し、GPU上でテンソルを生成できることを確認しています。

5.2.2. cuDNNのインストール

cuDNN (CUDA Deep Neural Network library) は、ディープラーニングのプリミティブ操作（畳み込み、プーリングなど）を高速化するためのNVIDIA製のライブラリです。ほとんどのディープラーニングフレームワークは、高速化のためにcuDNNを利用します。

NVIDIAが提供する nvidia/cuda イメージには、対応するバージョンのcuDNNがすでに含まれている場合が多いですが、もし別途インストールが必要な場合は、NVIDIA DeveloperプログラムからcuDNNをダウンロードし、Dockerfile内でインストールする必要があります。

“`dockerfile

例: cuDNNを別途インストールする場合 (nvidia/cuda-devel イメージには含まれていることが多い)

RUN apt-get update && apt-get install -y –no-install-recommends libcudnn8 libcudnn8-dev

“`

5.3. サンプルプロジェクト（TensorFlow/PyTorch）

簡単なディープラーニングモデルの学習スクリプトを使って、実際にGPUが利用されていることを確認します。

例：PyTorchを使ったシンプルな学習スクリプト (train.py)

“`python
import torch
import torch.nn as nn
import torch.optim as optim
import time

GPUが利用可能かチェック

if torch.cuda.is_available():
device = torch.device(“cuda”)
print(f”GPUが利用可能です: {torch.cuda.get_device_name(0)}”)
else:
device = torch.device(“cpu”)
print(“GPUは利用できません。CPUを使用します。”)

シンプルな線形モデル

class SimpleModel(nn.Module):
def init(self):
super(SimpleModel, self).init()
self.linear = nn.Linear(1000, 1000)

def forward(self, x):
    return self.linear(x)

モデルをGPUに移動

model = SimpleModel().to(device)

データ生成

input_data = torch.randn(64, 1000).to(device)
target_data = torch.randn(64, 1000).to(device)

損失関数とオプティマイザ

criterion = nn.MSELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01)

学習ループ

print(“学習を開始します…”)
start_time = time.time()
num_epochs = 1000

for epoch in range(num_epochs):
# フォワードパス
outputs = model(input_data)
loss = criterion(outputs, target_data)

# バックワードパスと最適化
optimizer.zero_grad()
loss.backward()
optimizer.step()

if (epoch + 1) % 100 == 0:
    print(f'Epoch [{epoch+1}/{num_epochs}], Loss: {loss.item():.4f}')

end_time = time.time()
print(f”学習が完了しました。経過時間: {end_time – start_time:.2f}秒”)

GPU利用状況の確認 (TensorFlowやKerasの場合も同様にGPUが使われるか確認できます)

“`

Dockerfile (Dockerfile)

“`dockerfile
FROM nvidia/cuda:11.8.0-runtime-ubuntu22.04

ENV DEBIAN_FRONTEND=noninteractive
ENV PYTHON_VERSION=3.9

RUN apt-get update && apt-get install -y –no-install-recommends \
python${PYTHON_VERSION} \
python3-pip \
&& rm -rf /var/lib/apt/lists/*

ENV VIRTUAL_ENV=/opt/venv
RUN python${PYTHON_VERSION} -m venv ${VIRTUAL_ENV}
ENV PATH=”${VIRTUAL_ENV}/bin:${PATH}”

PyTorchインストール

RUN pip install –no-cache-dir torch==2.0.1+cu118 torchvision==0.15.2+cu118 torchaudio==2.0.2+cu118 –index-url https://download.pytorch.org/whl/cu118

WORKDIR /app
COPY train.py .

CMD [“python”, “train.py”]
“`

ビルドと実行:
“`bash

イメージをビルド

docker build -t pytorch-gpu-trainer .

コンテナを実行し、GPUを利用

別のターミナルで `watch -n 0.5 nvidia-smi` を実行してGPU使用率を監視すると良い

docker run –rm –gpus all pytorch-gpu-trainer
`` スクリプトが「GPUが利用可能です」と表示し、nvidia-smi` でGPUの使用率が上昇していれば成功です。

5.4. データ永続化とボリュームマウント

ディープラーニングでは、データセットや学習済みモデルをコンテナ外に永続化することが必須です。Dockerのボリュームマウント機能を使用します。

“`bash

ホストの /home/user/my_data をコンテナの /data にマウント

ホストの /home/user/models をコンテナの /models にマウント

docker run –rm –gpus all \
-v /home/user/my_data:/data \
-v /home/user/models:/models \
pytorch-gpu-trainer \
python train.py –data_path /data –model_save_path /models
“`
これにより、コンテナ内で生成されたデータやモデルがホストマシンに保存され、コンテナが削除されてもデータが失われることがありません。

5.5. SSH接続とJupyter Notebook

GPUコンテナをリモートサーバー上で実行し、ローカルからアクセスして作業を進めることはよくあります。

5.5.1. SSH接続可能なGPUコンテナ

DockerfileにOpenSSHサーバーを追加し、SSHで接続できるようにします。

“`dockerfile

… (上記PyTorch Dockerfileの続き) …

SSHサーバーのインストール

RUN apt-get update && apt-get install -y openssh-server \
&& mkdir -p /var/run/sshd \
&& rm -rf /var/lib/apt/lists/*

rootパスワードの設定 (本番環境ではSSHキーを使用すべき)

RUN echo ‘root:your_secure_password’ | chpasswd

SSHポートの公開

EXPOSE 22

SSHサーバーを起動するエントリーポイント

CMD [“/usr/sbin/sshd”, “-D”]
**ビルドと実行:**bash
docker build -t ssh-gpu-trainer .
docker run -d –name my-ssh-gpu-container -p 2222:22 –gpus all ssh-gpu-trainer

ローカルからSSH接続

ssh root@localhost -p 2222
`` コンテナ内でGPUコマンドを実行し、動作を確認できます。本番環境では、root` ユーザーとパスワード認証ではなく、専用ユーザーの作成とSSHキー認証を強く推奨します。

5.5.2. Jupyter Notebookサーバーの起動

データ探索やインタラクティブな開発のために、GPUコンテナ内でJupyter Notebookを起動することも非常に便利です。

“`dockerfile

… (上記PyTorch Dockerfileの続き) …

JupyterLabのインストール

RUN pip install jupyterlab

Jupyterのポート公開

EXPOSE 8888

Jupyter Notebookを起動するコマンド

–ip=0.0.0.0 で外部からのアクセスを許可

–allow-root でrootユーザーでの実行を許可 (通常は非rootユーザーを推奨)

–no-browser でブラウザを自動起動しない

–NotebookApp.token=” または –NotebookApp.password=” でパスワード設定 (セキュリティのため推奨)

CMD [“jupyter”, “lab”, “–ip=0.0.0.0”, “–port=8888”, “–allow-root”, “–no-browser”]
**ビルドと実行:**bash
docker build -t jupyter-gpu .
docker run -d –name my-jupyter-gpu-container -p 8888:8888 –gpus all jupyter-gpu

ブラウザでアクセス: http://localhost:8888/

コンテナのログからトークンを確認 (docker logs my-jupyter-gpu-container)

`` Jupyter Notebookのノートブック内でtorch.cuda.is_available()` を実行し、GPUが認識されていることを確認できます。

6. 高度なトピックとベストプラクティス

NVIDIA Container ToolkitとDockerの連携は、さらに多くの高度なシナリオに対応できます。

6.1. GPUの隔離と共有

大規模なシステムでは、複数のコンテナ間でGPUリソースを効率的に共有・隔離することが重要になります。

6.1.1. 複数のコンテナでのGPU共有

--gpus オプションで同じGPUを複数のコンテナに割り当てることは可能です。しかし、これはリソースの共有を意味し、完全なパフォーマンス隔離は提供しません。例えば、2つのコンテナが同時に同じGPUを使用すると、GPUの計算リソース（CUDAコア、メモリ帯域）を奪い合うことになります。

“`bash

2つのコンテナが同時にGPU 0 を使用

docker run -d –name c1 –gpus “device=0” my-gpu-app
docker run -d –name c2 –gpus “device=0” my-gpu-app
`` このような場合、nvidia-smi` でGPU使用率を監視し、GPUリソースのボトルネックが発生していないか確認することが重要です。

6.1.2. NVIDIA Multi-Instance GPU (MIG)

NVIDIA A100 GPU以降のモデルでは、MIG (Multi-Instance GPU) という機能が利用できます。MIGを使用すると、一つの物理GPUを最大7つまでの独立したGPUインスタンスに分割し、それぞれに専用のメモリ、キャッシュ、SMsを割り当てることができます。これにより、複数のユーザーやワークロードが物理GPUをより厳密に隔離された状態で共有し、予測可能なパフォーマンスを得ることが可能になります。

MIGをDockerで利用するには、ホストOSでMIGインスタンスを設定した後、--gpus オプションで特定のMIGデバイスを指定します。
“`bash

ホストでMIGインスタンスを作成 (nvidia-smi mig コマンドを使用)

例: 1g.5gb (1つのGPUインスタンス, 5GBメモリ) を作成し、そのデバイスIDを確認

DockerでMIGデバイスを指定

docker run –rm –gpus “device=MIG-UUID-xxxx” my-gpu-app
“`
MIGは、クラウド環境や共有HPCクラスタでGPUリソースを最大限に活用するための強力な機能です。

6.2. オーケストレーションツールとの連携

単一ホストでのDockerコンテナ運用に慣れたら、複数のホストにまたがる大規模な環境でGPUワークロードを管理するために、オーケストレーションツールを検討することになります。

6.2.1. Docker ComposeでのGPU指定

Docker Composeは、複数のDockerコンテナで構成されるアプリケーションを定義し、一元的に管理するためのツールです。docker-compose.yml ファイルでGPUを指定できます。

“`yaml

docker-compose.yml

version: ‘3.8’
services:
gpu_worker:
image: my-gpu-app:latest
# deploy セクションで GPU 設定
deploy:
resources:
reservations:
devices:
– driver: nvidia
count: all # または 1, 2 など特定の数を指定
# capabilities: [gpu, utility] # 必要に応じて capability を指定
volumes:
– ./data:/data
environment:
– SOME_ENV_VAR=value
`` この設定でdocker-compose upを実行すると、gpu_worker` サービスがGPUにアクセスできるようになります。

6.2.2. KubernetesでのNVIDIA GPUデバイスプラグイン

Kubernetesは、コンテナ化されたワークロードとサービスを自動的にデプロイ、スケーリング、管理するためのオープンソースシステムです。Kubernetes上でGPUを利用するには、NVIDIAが提供するKubernetes NVIDIA GPUデバイスプラグインを導入する必要があります。

このプラグインは、Kubernetesのノード上で実行され、ノードに搭載されたGPUリソースをKubernetesクラスタに「広告」します。これにより、ユーザーはPodの定義ファイル（YAML）でGPUリソースを要求できるようになります。

“`yaml

Kubernetes Pod定義の例

apiVersion: v1
kind: Pod
metadata:
name: gpu-pytorch-pod
spec:
containers:
– name: pytorch-container
image: my-gpu-app:latest
resources:
limits:
nvidia.com/gpu: 1 # GPUを1つ要求
volumeMounts:
– name: data-volume
mountPath: /data
volumes:
– name: data-volume
hostPath:
path: /mnt/data # ホストのパス
“`
KubernetesとNVIDIA GPUデバイスプラグインの連携は、GPUクラスタを構築・運用する上で不可欠な要素です。

6.3. NVIDIA NGC (NVIDIA GPU Cloud) とは？

NVIDIA NGCは、AI、HPC、視覚化のためのGPU最適化されたソフトウェアハブです。これには、NVIDIAが検証・最適化したコンテナイメージ、モデル、SDK、チャートなどが含まれます。

最適化されたコンテナイメージの利用: NGCから提供されるTensorFlow、PyTorch、MXNetなどのコンテナイメージは、最新のNVIDIA GPUアーキテクチャとCUDA/cuDNNライブラリに合わせて高度に最適化されています。これらのイメージを使用することで、ユーザーは手動での環境構築の手間を省き、最初から最高のパフォーマンスを引き出すことができます。
ワークフローの高速化: NGCのイメージやモデルを使用することで、環境構築、依存関係の解決、パフォーマンスチューニングにかかる時間を大幅に短縮し、開発・研究のサイクルを加速できます。

これらのNGCイメージも、NVIDIA Container ToolkitがインストールされたDocker環境で docker pull して docker run --gpus all で実行するだけで利用できます。

6.4. パフォーマンス最適化のヒント

GPUコンテナのパフォーマンスを最大限に引き出すためには、いくつかの考慮事項があります。

適切なCUDAベースイメージの選択:
- 開発・コンパイルが必要な場合は -devel イメージを、単にアプリケーションを実行する場合は -runtime または -base イメージを選択し、イメージサイズを最小限に抑えます。
- ホストのNVIDIAドライバーと互換性のあるCUDAバージョンを選択します。一般的に、ドライバーバージョンがサポートするCUDAバージョンであれば問題ありません。
cuDNNバージョンの最適化:
- 使用しているディープラーニングフレームワークとCUDAバージョンに最適なcuDNNバージョンを選択します。NVIDIA NGCのイメージは、この点で最適化されています。
データ読み込みのボトルネック解消:
- GPUの計算能力がデータ供給によって制限されないよう、データローダー（例: PyTorchのDataLoader、TensorFlowのtf.data）を最適化し、マルチプロセスや非同期I/Oを活用します。
- データセットがSSDやNVMeなどの高速ストレージに保存されていることを確認します。
nvidia-smi や nvtop での監視:
- トレーニング中や推論中に nvidia-smi や nvtop (よりインタラクティブなGPU監視ツール) でGPU使用率、メモリ使用量、温度などをリアルタイムで監視し、ボトルネックや非効率な利用がないかを確認します。
- GPU使用率が低い場合、CPU側のボトルネック（データ前処理、I/O）や、GPUが十分に活用されていないモデル設計が原因である可能性があります。

7. よくある問題とトラブルシューティング

GPUとDockerの連携においては、いくつかの一般的な問題に遭遇することがあります。ここでは、それらの解決策を提示します。

7.1. `docker: Error response from daemon: OCI runtime create failed: ...` (GPUが見つからない/設定エラー)

症状: DockerコンテナがGPUにアクセスしようとしたときに、ランタイムエラーで起動に失敗する。
原因:
- NVIDIA Container Toolkitが正しくインストールされていないか、Dockerデーモンが再起動されていない。
- ホストにNVIDIAドライバーがインストールされていないか、破損している。
- Dockerデーモンの設定ファイル (/etc/docker/daemon.json) に問題がある。
解決策:
1. ホストで nvidia-smi が正常に動作するか確認する。
2. nvidia-container-toolkit がインストールされているか確認し、もしインストールされていなければ再インストールする。
3. sudo systemctl restart docker を実行し、Dockerデーモンを再起動する。
4. /etc/docker/daemon.json の内容を必要に応じて確認する。通常は自動設定されるため、手動で変更する必要は少ないですが、問題が続く場合はNVIDIA Container Toolkitの公式ドキュメントを参照し、推奨される設定があるか確認する。

7.2. `NVIDIA Driver not found` (コンテナ内で表示される場合)

症状: コンテナ内部で nvidia-smi を実行してもドライバーが見つからない、またはCUDAアプリケーションがGPUを認識しない。
原因:
- ホストのNVIDIAドライバーが正しくインストールされていないか、バージョンが古すぎる。
- NVIDIA Container Toolkitがホストのドライバーライブラリをコンテナに正しくパススルーできていない。
解決策:
1. ホストOSで最新のNVIDIAドライバーがインストールされており、nvidia-smi が正常に動作することを確認する。
2. NVIDIA Container Toolkitを再インストールし、Dockerデーモンを再起動する。
3. コンテナイメージに、ホストのドライバーバージョンと互換性のあるCUDAバージョンが組み込まれているか確認する。NVIDIA公式の nvidia/cuda イメージを使用していれば、通常はこの問題は発生しにくいです。

7.3. CUDAバージョンとドライバーの不一致

症状: コンテナは起動するが、CUDAアプリケーションが正しく動作しない、または警告が表示される。
原因: ホストのNVIDIAドライバーのバージョンが、コンテナ内のCUDAランタイムのバージョンをサポートしていない（またはその逆）。一般的に、NVIDIAドライバーは古いCUDAバージョンをサポートしますが、新しいCUDAバージョンを動かすには新しいドライバーが必要です。
解決策:
1. ホストの nvidia-smi で表示されるCUDAバージョン（Driver Versionに対応するCUDAバージョン）と、コンテナ内で利用するCUDAベースイメージのバージョンを確認する。
2. 必要に応じて、ホストのNVIDIAドライバーを更新するか、コンテナイメージのCUDAバージョンをダウングレードする。NVIDIAのCUDA Compatibility Matrixを確認し、互換性のある組み合わせを選択する。

7.4. パーミッションエラー

症状: Dockerコマンドを実行すると、パーミッション関連のエラーが出る（例: Got permission denied while trying to connect to the Docker daemon socket）。
原因: Dockerデーモンソケットへのアクセス権がないユーザーでコマンドを実行している。
解決策:
1. Dockerコマンドを実行するユーザーを docker グループに追加する: sudo usermod -aG docker $USER。
2. グループ変更を反映させるために、一度ログアウトして再ログインするか、システムを再起動する。
3. その後、sudo なしで docker run コマンドが実行できることを確認する。

7.5. 古いNVIDIA Container Toolkitの残骸

症状: 以前の nvidia-docker や nvidia-docker2 を使用していた環境で、新しいNVIDIA Container Toolkitのインストール後に問題が発生する。
原因: 古いバージョンの設定ファイルやランタイムが残っており、新しい設定と衝突している。
解決策:
1. 古いツールキットのアンインストール手順（セクション4.2）に従って、残骸を完全に削除する。
2. /etc/docker/daemon.json や /etc/nvidia-container-runtime/config.toml など、関連する設定ファイルを確認し、不要なエントリを削除する。
3. Dockerデーモンを再起動する。

これらのトラブルシューティングのヒントは、最も一般的な問題に対処するためのものです。問題が解決しない場合は、NVIDIA Container Toolkitの公式ドキュメント、Dockerの公式ドキュメント、そして関連するフォーラム（NVIDIA Developer Forums, Stack Overflowなど）で情報を検索することをお勧めします。

8. まとめと今後の展望

本記事では、DockerとNVIDIA Container Toolkitを連携させることで、GPUの計算能力を最大限に引き出し、AI/MLやHPCワークフローを効率化する方法を詳細に解説しました。GPUコンピューティングの基礎からDockerの利点、NVIDIA Container Toolkitの仕組み、具体的なインストール・設定手順、実践的な使用例、さらには高度なトピックとトラブルシューティングまで、包括的な知識を提供しました。

NVIDIA Container Toolkitは、GPUアプリケーションの開発とデプロイにおける環境構築の複雑さを劇的に軽減し、ポータビリティと再現性を向上させるための不可欠なツールです。これにより、データサイエンティストや機械学習エンジニアは、インフラの細かな設定に煩わされることなく、モデルの開発と実験に集中できるようになります。研究室からクラウド、エッジデバイスまで、一貫したGPU環境を構築できるため、CI/CDパイプラインへの組み込みも容易になり、開発から本番運用までのサイクルを加速させることが可能です。

今後の展望:

GPU技術とコンテナ技術は、それぞれが急速に進化しています。

新しいGPUアーキテクチャと機能: NVIDIAは常に新しいGPUアーキテクチャ（Hopper, Blackwellなど）をリリースし、MIGのような先進的な機能を提供しています。NVIDIA Container Toolkitもこれらの新機能に対応し、GPUの利用効率をさらに高めていくでしょう。
コンテナランタイムの進化: DockerやKubernetesといったコンテナ技術も継続的に改善されており、よりセキュアで効率的なリソース管理機能が追加されています。NVIDIA Container Toolkitはこれらの進化に追従し、より深いレベルでの統合が進むことが予想されます。
サーバーレスGPUコンピューティング: コンテナ技術の成熟は、サーバーレス環境でのGPUコンピューティング（Function-as-a-Service, FaaS）の可能性を広げています。必要な時だけGPUリソースを起動し、利用した分だけ課金されるというモデルは、コスト効率の高いAI推論サービスなどに活用されるでしょう。
エッジAIと組み込みシステム: 小型・低消費電力のGPU（例: NVIDIA Jetsonシリーズ）がエッジデバイスに搭載されるにつれて、DockerやNVIDIA Container Toolkitを用いたエッジAIアプリケーションのデプロイと管理がより重要になります。

NVIDIA Container Toolkitは、これらの未来のトレンドを支える重要な基盤技術であり続けるでしょう。この記事で得た知識が、皆様のGPUを活用したプロジェクトの成功に貢献できれば幸いです。GPUとDockerの強力な連携を最大限に活用し、イノベーションを加速させていきましょう。

Dockerと連携！NVIDIA Container ToolkitでGPUを最大限に活かす

1. はじめに：なぜ今、GPUとコンテナの融合が必要なのか？

2. GPUコンピューティングの基礎とDockerの役割

2.1. GPUとは？そしてCUDAの重要性

2.1.1. CPUとGPUの違い：並列処理の力

2.1.2. CUDA：NVIDIA GPUをプログラミングするためのプラットフォーム

2.2. Dockerの基礎と利点

2.2.1. コンテナとは何か？仮想マシンとの比較

2.2.2. Dockerの主要な利点

2.3. なぜGPUとDockerを組み合わせるのか？

3. NVIDIA Container Toolkit (nvidia-docker2 / libnvidia-container) とは？

3.1. 課題の明確化：標準DockerでのGPUアクセスの限界

3.2. 解決策としてのNVIDIA Container Toolkit

3.2.1. 旧来のnvidia-docker1からnvidia-docker2、そしてlibnvidia-containerへの変遷

3.2.2. --gpus all オプションの実現メカニズム

3.3. 仕組みの深掘り：NVIDIA Container RuntimeとOCIフック

4. NVIDIA Container Toolkitのインストールと設定

4.1. 前提条件

4.2. インストール手順（Linuxベース、Ubuntu 20.04/22.04 LTSを例に）

リポジトリの追加 (Ubuntu 20.04/22.04 LTS の場合)

Ubuntuのバージョンに合わせて、distribution名を確認

例: Ubuntu 20.04 -> focal, Ubuntu 22.04 -> jammy

4.3. 確認方法

4.4. トラブルシューティングのヒント

5. DockerとGPU連携の具体的な実践

5.1. 基本的なGPUコンテナの実行

5.1.1. すべてのGPUを利用する

5.1.2. 特定のGPUを指定する

UUIDを指定して実行

5.1.3. 利用可能なGPUリソースの制限

5.2. DockerfileでのGPU対応イメージの構築

5.2.1. FROM nvidia/cuda の利用

開発・トレーニング用にはdevelイメージを選択

環境変数の設定 (必要に応じて)

必要なパッケージのインストール

Python仮想環境の作成とアクティベート (推奨)

PyTorchのインストール

CUDAバージョンに合わせて最適なPyTorchをインストール

公式サイト (pytorch.org) のインストールコマンドを参考に

その他のPythonライブラリのインストール

COPY requirements.txt .

RUN pip install –no-cache-dir -r requirements.txt

作業ディレクトリの設定

アプリケーションコードのコピー

エントリポイントの設定

CMD [“python”, “your_script.py”]

5.2.2. cuDNNのインストール

例: cuDNNを別途インストールする場合 (nvidia/cuda-devel イメージには含まれていることが多い)

RUN apt-get update && apt-get install -y –no-install-recommends libcudnn8 libcudnn8-dev

5.3. サンプルプロジェクト（TensorFlow/PyTorch）

GPUが利用可能かチェック

シンプルな線形モデル

モデルをGPUに移動

データ生成

損失関数とオプティマイザ

学習ループ

GPU利用状況の確認 (TensorFlowやKerasの場合も同様にGPUが使われるか確認できます)

PyTorchインストール

イメージをビルド

コンテナを実行し、GPUを利用

別のターミナルで watch -n 0.5 nvidia-smi を実行してGPU使用率を監視すると良い

5.4. データ永続化とボリュームマウント

ホストの /home/user/my_data をコンテナの /data にマウント

ホストの /home/user/models をコンテナの /models にマウント

5.5. SSH接続とJupyter Notebook

5.5.1. SSH接続可能なGPUコンテナ

… (上記PyTorch Dockerfileの続き) …

SSHサーバーのインストール

rootパスワードの設定 (本番環境ではSSHキーを使用すべき)

SSHポートの公開

SSHサーバーを起動するエントリーポイント

ローカルからSSH接続

5.5.2. Jupyter Notebookサーバーの起動

… (上記PyTorch Dockerfileの続き) …

JupyterLabのインストール

Jupyterのポート公開

Jupyter Notebookを起動するコマンド

–ip=0.0.0.0 で外部からのアクセスを許可

–allow-root でrootユーザーでの実行を許可 (通常は非rootユーザーを推奨)

–no-browser でブラウザを自動起動しない

3.2.2. `--gpus all` オプションの実現メカニズム

5.2.1. `FROM nvidia/cuda` の利用

別のターミナルで `watch -n 0.5 nvidia-smi` を実行してGPU使用率を監視すると良い

7.1. `docker: Error response from daemon: OCI runtime create failed: ...` (GPUが見つからない/設定エラー)

7.2. `NVIDIA Driver not found` (コンテナ内で表示される場合)

コメントする返信をキャンセル