【第2回】AlmaLinux 9/10の初期構築とNVIDIA CUDA環境の最適化：ローカルLLM基盤を構築する

ローカルLLMを自社のインフラで稼働させるための第一歩は、安定したOS環境の構築と、計算の心臓部となるGPU（Graphics Processing Unit）をOSに正しく認識させることです。前回の第1回では、エンタープライズ向けのAI基盤として「AlmaLinux 9/10」が最適である理由と、アーキテクチャの全体像を解説しました。

今回は実践編として、AlmaLinuxの初期構築から、インフラエンジニアが最も苦戦しやすい「NVIDIAドライバおよびCUDA Toolkitのクリーンなインストール」までを、コマンドレベルで徹底的に解説します。

コウ君

リナックス先生、とりあえずAlmaLinuxをインストールして、公式サイトからダウンロードしたNVIDIAのrunファイル（インストーラー）を実行してみたんですが、画面が真っ暗になったり、エラーが出てインストールが途中で止まってしまいました……。GPUのセットアップってこんなに難しいんですか？

リナックス先生

コウ君、それはLinuxでGPU環境を構築する人が必ず踏む「nouveau（ヌーヴォー）の罠」ですね。NVIDIA公式の .run スクリプトを直接実行するのは、エンタープライズの運用保守においてはアンチパターンです。パッケージマネージャ（dnf）の管理外になってしまい、将来のカーネルアップデート時にシステムが破壊される原因になります。プロのインフラエンジニアとして、パッケージ管理の原則に従ったクリーンで再現性のある構築手順を身につけましょう。

本記事では、後戻り作業が発生しない確実なセットアップ手順と、AIアプリケーションを安全に稼働させるためのコンテナ連携、そしてインフラエンジニアならではのGPUパフォーマンスチューニングまでを網羅します。

📚 本連載のカリキュラム（全8回）

1. GPU環境構築の最大の関門：nouveauの無効化

LinuxにNVIDIA GPUを搭載した状態でOSをインストールすると、デフォルトで「nouveau（ヌーヴォー）」というオープンソースのディスプレイドライバが読み込まれます。デスクトップ用途でGUIを表示するだけなら便利なのですが、AIの推論やCUDA（Compute Unified Device Architecture）を利用する際には致命的な競合を引き起こします。

1.1. nouveauとは何か？なぜ競合するのか

nouveauはリバースエンジニアリングによって開発されたドライバであり、NVIDIAのプロプライエタリ（非公開）な純正ドライバとは完全に別物です。NVIDIA公式のドライバをカーネルモジュールとしてロードしようとした際、すでにnouveauがGPUのコントロール権を握っていると、モジュールのロードに失敗しインストールが中断されます。
したがって、公式ドライバをインストールする前に、OSのカーネルレベルでnouveauを完全に「ブラックリスト化（読み込み拒否）」する必要があります。

コウ君

なるほど、インストールが途中で止まってしまったのは、そのnouveauっていうのが邪魔をしていたからなんですね。

1.2. nouveauのブラックリスト化とinitramfsの再構築

nouveauを無効化するためには、モジュールのブラックリストファイルを作成し、OS起動時に読み込まれる初期RAMディスク（initramfs）を再構築するプロセスが必要です。

以下のコマンドを root 権限（または sudo）で実行し、設定ファイルを作成します。

cat << EOF | sudo tee /etc/modprobe.d/nouveau-blacklist.conf
blacklist nouveau
options nouveau modeset=0
EOF

設定ファイルを作成しただけでは、次回の再起動時に無効化されません。カーネルが起動する際に最初に展開される initramfs イメージの中にすでにnouveauドライバが組み込まれてしまっているからです。そのため、dracut コマンドを使用して初期RAMディスクを作り直します。

# 現在のカーネルのinitramfsのバックアップを取得（念のため）
sudo mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img

# dracutでinitramfsを再構築
sudo dracut --force /boot/initramfs-$(uname -r).img $(uname -r)

# サーバーを再起動
sudo reboot

再起動後、nouveauが本当に読み込まれていないか確認します。以下のコマンドを実行し、何も出力されなければ成功（無効化完了）です。

lsmod | grep nouveau

⚠️ クラウドVM（VPS）を利用する場合の注意点
AWSのEC2（G4/G5インスタンス）や、GPU搭載のクラウドVPSをプロビジョニングする場合、ベンダーが用意したAMIやイメージの段階ですでにnouveauが無効化され、ドライバがインストール済みのケースがあります。その場合はこの手順をスキップできますが、ベアメタルサーバーや初期状態のオンプレミス環境では必須の作業となります。

2. AlmaLinux環境の事前準備と依存パッケージの導入

NVIDIAドライバはOSのカーネルと密接に連携する「カーネルモジュール（DKMS: Dynamic Kernel Module Support）」としてビルドされます。そのため、コンパイルに必要なヘッダーファイルや開発ツールチェーンをあらかじめ導入しておく必要があります。

2.1. OSの最新化とEPEL・CRBリポジトリの有効化

AlmaLinux（RHEL互換OS）で開発パッケージをインストールするには、標準リポジトリに加えて「EPEL（Extra Packages for Enterprise Linux）」と「CRB（CodeReady Builder）」リポジトリを有効化する必要があります。

# システム全体のパッケージを最新に更新
sudo dnf update -y

# EPELリポジトリのインストール
sudo dnf install -y epel-release

# CRB (CodeReady Builder) リポジトリの有効化（AlmaLinux 9の場合）
sudo dnf config-manager --set-enabled crb

2.2. カーネルヘッダーと開発ツールの導入

次に、NVIDIAドライバをカーネルモジュールとして動的にビルドするためのCコンパイラ（gcc）やカーネルヘッダーをインストールします。ここでのポイントは、「現在稼働しているカーネルのバージョンと、インストールするカーネルヘッダーのバージョンを完全に一致させること」です。

# GCC, Make等の開発ツールとDKMSをインストール
sudo dnf install -y gcc make dkms pciutils

# 稼働中のカーネルバージョンと一致するヘッダーと開発パッケージをインストール
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)
コウ君

もし dnf install kernel-devel って普通に叩いちゃったらダメなんですか？

リナックス先生

とても良い質問です。バージョンを指定せずにインストールすると、リポジトリにある最新のカーネルヘッダーが落ちてきます。もし先ほどの dnf update でカーネルが新しくなっていたのにOSを再起動していなかった場合、稼働中のカーネルとヘッダーのバージョンがズレてしまい、NVIDIAドライバのビルドが100%失敗します。インフラの現場ではこういう細かなバージョン管理が明暗を分けるんですよ。

3. NVIDIAリポジトリの追加とドライバ・CUDAのインストール

準備が整ったら、いよいよNVIDIAの公式リポジトリを dnf（パッケージマネージャ）に登録し、ドライバとCUDA Toolkitをインストールします。

3.1. CUDAネットワークリポジトリの登録

AlmaLinux 9（およびRHEL 9）用の公式CUDAリポジトリを追加します。これにより、今後 dnf update を実行した際にもドライバやツールキットが安全にアップデートされるようになります。

# NVIDIA公式リポジトリの追加 (RHEL 9用)
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

# リポジトリのキャッシュをクリアして再構築
sudo dnf clean all
sudo dnf makecache

3.2. ドライバとCUDA Toolkitのクリーンインストール

ローカルLLMを動かすためには、単なるディスプレイドライバだけでなく、GPU上で並列計算を行うための開発環境「CUDA Toolkit」が必要です。
RHEL互換OSでは、NVIDIAが提供するモジュールストリーム（dnf module）を利用して、特定のバージョンのドライバをカーネルアップデートに追従（DKMS）する形式でインストールするのがベストプラクティスです。

# ドライバモジュールのリストを確認
sudo dnf module list nvidia-driver

# dkms版の最新ドライバストリームをインストール
sudo dnf module install -y nvidia-driver:latest-dkms

# CUDA Toolkit本体をインストール
sudo dnf install -y cuda-toolkit

インストールが完了したら、モジュールをカーネルに認識させるために再度サーバーを再起動します。

PR

Linuxカーネルプログラミング 第2版 [ Kaiwan N. Billimoria ]

価格:5720円
(2026/7/17 19:10時点)
感想(0件)

sudo reboot

3.3. インストール確認と nvidia-smi コマンドの見方

再起動後、インフラエンジニアの相棒となる nvidia-smi（System Management Interface）コマンドを実行します。

nvidia-smi

表形式のステータス画面が出力されれば、ドライバのインストールは完璧に成功しています。この画面では以下の情報を確認する癖をつけてください。

  • Driver Version / CUDA Version： 右上に表示されます。ローカルLLMの推論エンジン（vLLMなど）が要求するCUDAバージョンを満たしているか確認します。
  • GPU Memory Usage： 中央の段に表示される [ 0MiB / 24576MiB ] のような表記です。これがVRAMの現在の使用量と最大容量です。
  • GPU Utilization (Volatile Uncorr. ECC)： 画面右側の % 表記です。推論が走っている間にここが100%近くに張り付けば、GPUが正しく仕事をしている証拠です。

4. コンテナ環境（Podman/Docker）とNVIDIA Container Toolkitの連携

AIアプリケーションをホストOSに直接デプロイすることは、依存関係（Pythonライブラリなど）の衝突を招くため推奨されません。第1回でも触れた通り、ローカルLLMは「コンテナ（DockerまたはPodman）」上で動かすのがエンタープライズの鉄則です。

4.1. コンテナからGPUにアクセスするための仕組み

通常、コンテナはホストOSのハードウェアから隔離されているため、GPUを直接触ることはできません。コンテナ内からホストのGPUをパススルーして利用するために必要なミドルウェアが「NVIDIA Container Toolkit」です。

⚠️ PodmanかDockerか
AlmaLinux 9では標準のコンテナエンジンとして「Podman」が推奨されています。Podmanはデーモンレスで動作し、root権限を持たずにコンテナを実行できる（Rootless）ため、セキュリティ面で優位性があります。NVIDIA Container ToolkitはPodmanとDockerのどちらにも対応しています。本記事では汎用的なインストール手順を解説します。

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

まずはコンテナエンジン（ここではPodmanとDockerの両方を想定）がインストールされている前提で、NVIDIA Container Toolkitのリポジトリを追加し、インストールします。

# リポジトリの追加
curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo

# パッケージのインストール
sudo dnf install -y nvidia-container-toolkit

Dockerを使用している場合は、Dockerデーモンに対してランタイムの設定を生成し、再起動します。（Podmanの場合は CDI(Container Device Interface) が自動で設定されるため基本的には不要です）

# Docker向けの設定
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

設定が完了したら、コンテナ内からGPUが見えるかテストします。以下のコマンドで nvidia-smi の結果がコンテナ経由で出力されれば成功です。

# Dockerの場合
sudo docker run --rm --gpus all nvidia/cuda:12.2.2-base-ubuntu22.04 nvidia-smi

# Podmanの場合 (AlmaLinux 9)
podman run --rm --device nvidia.com/gpu=all nvidia/cuda:12.2.2-base-ubuntu22.04 nvidia-smi
コウ君

おぉ、コンテナの中からでもホストのGPUリソースが見えました！これならOSの環境を汚さずに、OllamaやvLLMのコンテナを立ててガンガン検証できそうです。

5. インフラエンジニアのためのGPUパフォーマンスチューニング

環境構築の総仕上げとして、サーバー運用者としての視点から、GPUのパフォーマンスを安定させるためのチューニングを行います。ローカルLLMを24時間稼働させるAIサーバーでは、これらの設定が推論のレイテンシと消費電力に直結します。

5.1. Persistence Mode（永続モード）の有効化

Linux環境におけるNVIDIA GPUは、GPUを使用するプロセスが何もない状態になると、省電力のためにドライバの状態をアンロードし、ディープスリープ状態に近い形へ移行します。次にLLMへのリクエスト（推論）が発生した際、ドライバの初期化から始まるため、最初のレスポンスが極端に遅延（レイテンシのスパイク）してしまいます。

これを防ぐために、ドライバを常にスタンバイ状態にしておく「Persistence Mode（永続モード）」を有効にします。

# Persistence Modeを有効化
sudo nvidia-smi -pm 1

※注意：この設定は再起動すると元に戻ってしまうため、本番環境では systemd のサービスユニットを作成し、OS起動時に自動で実行されるように設計します。

5.2. 電力制限（Power Limit）とクロックの最適化

データセンターやサーバールームにGPUサーバーを配置する場合、ラックの電力容量や発熱（サーマルスロットリング）が課題になります。nvidia-smi を使用することで、GPUの消費電力の上限をハードウェアレベルで制限（Power Cap）することが可能です。

例えば、最大消費電力が350WのGPUを、効率のよい250Wに制限することで、推論性能を数%しか落とさずに、発熱と電気代を大幅に削減できます。インフラ全体のキャパシティ設計において極めて重要なテクニックです。

# GPU 0番の電力上限を250W（250,000ミリワット）に設定
sudo nvidia-smi -i 0 -pl 250
リナックス先生

クラウドのAPIに頼っていると見えない「電力」や「熱」のコントロール。これこそが、オンプレミスでハードウェアを掌握するインフラエンジニアの真骨頂ですね。これでAIモデルを受け入れるための「最強の器」が完成しましたよ。

6. まとめと次回の予告

本記事では、AlmaLinux 9/10環境におけるローカルLLM基盤の土台作りとして、以下の内容を実践しました。

  • nouveauの無効化： カーネルモジュールのブラックリスト化とinitramfsの再構築により、NVIDIAドライバインストールの障害を排除した。
  • パッケージ管理の徹底： EPEL/CRBリポジトリを活用し、稼働中のカーネルバージョンと厳密に一致したヘッダーファイルを導入した。
  • CUDA環境のクリーンインストール： dnf moduleストリームを使用し、カーネルアップデートに耐えうるDKMSベースのドライバ構築を行った。
  • コンテナ連携とチューニング： NVIDIA Container Toolkitを導入し、Persistence Modeで推論のレイテンシを最小化する運用基盤を整えた。

OSとGPUが完璧に連動するセキュアなインフラ基盤が整いました。次回、【第3回】Ollamaを使ったDockerライクなLLM導入と管理では、この強固な基盤の上に、現在最も人気のあるLLM実行エンジン「Ollama」をデプロイします。Llama 3などのモデルをコマンド一発で立ち上げ、社内ネットワークに安全にAPIエンドポイントとして公開する手法を解説します。お楽しみに！

▼ 【インフラ環境を構築しよう】 ▼

GPU搭載で検証に最適！
「高コスパおすすめVPS・ベアメタル」

VPSランキングを見る

AI基盤を支えるインフラ技術者へ
「ITエンジニア専門転職」

転職エージェントを見る

コメント