クイックスタート：5分でDockerでGPUを有効化する
モデル学習用に「おろしたて」のUbuntuサーバーを受け取ったばかりですか？理屈をこねる前に、まずは手を動かしましょう。Dockerでグラフィックボードの性能を最大限に引き出すための3つのステップを解説します。
1. ホストマシンのドライバ確認
Dockerを触る前に、ホストマシンがハードウェアを認識している必要があります。以下のコマンドを実行してください：
nvidia-smiGPU의スペック表とCUDAバージョンが表示されれば、作業の半分は完了です。もしcommand not foundと表示される場合は、先にsudo apt install nvidia-driver-535（または最新版）でドライバをインストールしてから続行してください。
2. NVIDIA Container Toolkitのインストール
NVIDIAが公式リポジトリにすべてをパッケージ化しています。以下のコマンドを実行して、ソースの追加とインストールを行います：
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
&& curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit3. Docker Runtimeの設定とテスト
このステップでは、Dockerエンジンにnvidiaランタイムを登録します。JSONファイルを手動で編集する代わりに、公式のコマンドを使用しましょう：
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker結果を確認する時が来ました。NVIDIAのサンプルコンテナを実行してチェックしてみましょう：
docker run --rm --gpus all nvidia/cuda:12.0.0-base-ubuntu22.04 nvidia-smiコンテナ内でGPUのスペック表が表示されましたか？おめでとうございます。これで重いAIワークロードを処理する準備が整いました。
なぜNVIDIA Container Toolkitが必要なのか？
Dockerの本質はリソースの隔離です。デフォルトの状態では、コンテナはマザーボードに刺さっている高価なグラフィックボードの存在に全く気づきません。
GPUはCPUとは異なります。ハードウェアと通信するために、ユーザースペース層で専用のドライバを必要とします。もしイメージ内に直接ドライバをインストールしようとすると、ファイルサイズが数GBも膨れ上がってしまいます。さらに、ホストマシンのドライバを更新するたびに深刻な衝突が発生することになります。
NVIDIA Container Toolkitは、スマートな「架け橋」としての役割を果たします。ドライバを上書きするのではなく、ランタイム時にホストマシンから必要なライブラリファイルやバイナリをコンテナにマッピングします。この手法により、イメージを軽量に保ちつつ、高い柔軟性を確保できます。
午前2時の「泣きたくなるエラー」への対処
私の苦い経験をお話ししましょう。あるECプロジェクトで画像処理マイクロサービスをデプロイした時のことです。ローカルのCPU環境ではスムーズに動いていましたが、GPU搭載の本番環境に持っていくと、コンテナがCUDA error: unknown errorでクラッシュし続けました。
2時間にわたる疲弊したデバッグの末、極めて初歩的な原因を突き止めました。それは、ホストのドライババージョンが、イメージ内のCUDA Toolkit의要求に対して古すぎたことです。
この鉄則を覚えておいてください：ホストのドライバは、常にコンテナが要求するCUDAバージョン以上である必要があります。 CUDA 12のドライバが入ったホストでCUDA 11のイメージを動かすことはできますが、その逆は間違いなく失敗します。
GPU의分割リソース管理
特に複数の小さなモデルを同時に動かす場合、一つのコンテナがリソースを「独占」してしまうのは避けたいものです。
- 特定のGPUを指定：
--gpus '"device=0"'を使用して、0番目のカードのみを使用します。 - リソース制限：
--memoryや--cpusフラグを組み合わせて、一つのコンテナがサーバー全体をフリーズさせるのを防ぎます。
Docker Composeでの利用（本番環境の標準）
実際の運用環境において、docker runコマンドを手動で打つのはタブーです。管理にはDocker Composeを使用します。ただし、ComposeでのGPU構文はインデントを間違えやすいので注意が必要です。
以下は、私が普段から利用している標準的なdocker-compose.ymlの設定です：
services:
ai-engine:
image: vllm/vllm-openai:latest
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]注意：このdeploy.resources設定が安定して動作するのはDocker Compose V2以降です。まだV1を使用している場合は、不要なトラブルを避けるためにすぐにアップグレードを検討してください。
イメージの最適化：ストレージを節約する
よくある間違いは、本番環境にnvidia/cuda:develイメージを使ってしまうことです。devel版にはコンパイラからヘッダーファイルまですべて含まれており、サイズは3〜4GBにもなります。
コードを実行するだけであれば、適切なバージョンを選びましょう：
base：超軽量（約150MB）。最小限のCUDAライブラリのみ。runtime：一般的なAIアプリケーションの実行に適しています。devel：ビルド段階専用。
私のおすすめは、常にマルチステージビルド（Multi-stage build）を使用することです。devel環境でコードをビルドし、実行ファイルだけをbaseイメージにコピーします。この手法により、イメージサイズを4GBから数百MBに削減でき、デプロイ速度を劇的に向上させることができます。
まとめ
NVIDIA Container Toolkit의インストールは、プロフェッショナルなAI/MLの世界への第一歩です。最初からドライバのバージョン同期とイメージサイズの最適化を意識しましょう。サーバーがGPUエラーを吐いた時は、コンテナ内で「魔法のコマンド」であるnvidia-smiを再度実行し、インフラの問題かコードの問題かを切り分けてください。GPU의デバッグで夜更かしすることなく、安眠できることを祈っています！
