はじめに
GMOコネクトの永田です。
AWS の p4d.24xlarge（A100 x8）で複数の LLM を動かしていたら、ある朝突然 Docker コンテナ内の CUDA が全滅しました😇
ホスト側で nvidia-smi を叩くと GPU 8枚が正常に見えています。ドライバも CUDA バージョンも表示されています。なのにコンテナを起動すると：
ggml_cuda_init: failed to initialize CUDA: system not yet initialized
原因は nvidia-fabricmanager という、マルチ GPU 環境でしか使わないデーモンが、カーネルの自動更新に巻き込まれて静かに消えていたことでした。正直、このデーモンの存在自体を知らなかったので、同じ状況で困っている方の参考になればと思います。
先にまとめ
障害の因果チェーン：
Ubuntu unattended-upgrades がカーネルを自動更新
→ linux-modules-nvidia-580-open が引き込まれる
→ NVIDIA ドライバが server 版 → open 版に切り替わる
→ nvidia-fabricmanager が依存関係の不一致で自動削除される
→ ホストの nvidia-smi は正常に見える
→ Docker コンテナ内の CUDA 初期化だけが失敗する
押さえておくこと：
- Fabric Manager は NVSwitch 搭載マルチ GPU 環境（p4d, p5 等）で GPU 間通信を管理するデーモンです
- nvidia-smi はドライバとの通信結果を表示しているだけで、Fabric Manager の状態は見ていません
- 単一 GPU 環境では Fabric Manager は不要なので、同じカーネル更新が入っても同じ障害は起きません
- 再発防止には
unattended-upgradesでカーネル・NVIDIA パッケージを除外します
NVSwitch と Fabric Manager
マルチ GPU の通信アーキテクチャ
p4d.24xlarge には A100 GPU が 8枚搭載されていて、これらは NVSwitch を経由して相互接続されています。NVLink の直接接続と異なり、NVSwitch は全 GPU 間で直接通信できる構成を仲介するスイッチチップで、物理的にはマザーボード上に複数搭載されています。
GPU 0 ──┐ ┌── GPU 4
GPU 1 ──┤ ├── GPU 5
├── NVSwitch (x6) ──┤
GPU 2 ──┤ ├── GPU 6
GPU 3 ──┘ └── GPU 7
LLM の推論や学習で tensor parallelism（モデルを複数 GPU に分割して並列処理する手法）を使う場合、GPU 間で高速にテンソルを転送する必要があります。この転送経路を管理しているのが nvidia-fabricmanager デーモンです。
Fabric Manager の役割
Fabric Manager User Guide によると、Fabric Manager（FM）は UNIX デーモンプロセスとして動作するスタンドアロンの実行ファイルです。
FM configures the NVSwitch memory fabrics to form one memory fabric among all participating GPUs and monitors the NVLinks that support the fabric.
NVSwitch のメモリファブリックを構成して全 GPU 間の通信経路を確立し、NVLink の監視も行います。エラー発生時には通信経路の再構成も担当します。
起動すると、ログに以下のようなメッセージが出ます：
Successfully configured all the available NVSwitches to route GPU NVLink traffic.
このデーモンが動いていないと、個々の GPU は認識できても GPU 間の通信経路が確立されません。同ドキュメントにはこう書かれています：
CUDA initialization will fail with the
cudaErrorSystemNotReadyerror if the application is launched before FM completely initializes the system or when FM fails to initialize the system.
FM が未起動、または初期化に失敗した状態だと、CUDA アプリケーションは cudaErrorSystemNotReady で失敗します。
nvidia-smi に表示されない理由
nvidia-smi のドキュメント に以下の記述があります：
Much of the functionality of NVSMI is provided by the underlying NVML C-based library.
nvidia-smi は NVML（NVIDIA Management Library）経由でドライバに問い合わせた結果を表示しています。表示対象は GPU 名、メモリ使用量、温度、使用率、クロック等で、ドライバが個々の GPU を認識していればこれらは正常に表示されます。
一方、Fabric Manager は前述のとおりユーザー空間のデーモンプロセスであり、nvidia-smi / NVML の表示対象ではありません。nvidia-smi が正常に見えるのは間違いではなく、nvidia-smi の守備範囲の情報は実際に正常だからです。
問題は、NVSwitch 環境では CUDA の初期化に Fabric Manager による経路確立が前提になっている点です。nvidia-smi では異常を検知できず、CUDA アプリケーションを実行して初めて cudaErrorSystemNotReady が返ってきます。
| 確認コマンド | Fabric Manager 停止中の表示 |
|---|---|
nvidia-smi |
正常（GPU 8枚認識、ドライバ/CUDA バージョン表示） |
systemctl status nvidia-fabricmanager |
Unit nvidia-fabricmanager.service could not be found |
| Docker コンテナ内の CUDA 初期化 | failed to initialize CUDA: system not yet initialized |
Ubuntu の NVIDIA ドライバパッケージ体系
server 版と open 版 — Ubuntu 固有のパッケージ体系
Ubuntu のリポジトリには同一バージョンのドライバに対して複数のパッケージ種別が用意されています。
| パッケージ名 | 用途 | Fabric Manager との関係 |
|---|---|---|
nvidia-driver-580-server |
データセンター・サーバ向け (ERD) | Fabric Manager と同じ依存関係に属する |
nvidia-driver-580-open |
オープンカーネルモジュール版 | Fabric Manager パッケージが依存関係に 含まれない |
nvidia-driver-580 |
デスクトップ向け | Fabric Manager パッケージが依存関係に 含まれない |
Ubuntu 公式ドキュメントに以下の記載があります：
The Fabric Manager and NSCQ library are only available with the ERDs or
-serverdriver versions.
注意が必要なのは、これは NVIDIA の技術的制約ではなく、Ubuntu の apt パッケージングの問題だという点です。NVIDIA の Fabric Manager 公式ドキュメント ではパッケージ種別の制約には言及しておらず、バージョンの一致のみを求めています。実際、第4世代 NVSwitch（H100 等）向けの手順では nvidia-open-<branch> の使用を案内しています。
つまり open 版ドライバで Fabric Manager が動かないわけではありません。Ubuntu の apt 依存関係上、-server から -open に切り替わると nvidia-fabricmanager パッケージが依存関係から外れるのが問題です。
カーネル更新がドライバのパッケージ種別を切り替える
ここが今回の障害の核心です。
Ubuntu のカーネルパッケージには linux-modules-nvidia-580-server-* と linux-modules-nvidia-580-open-* があります。カーネルが自動更新されたとき、新しいカーネルバージョンに対応するモジュールパッケージが引き込まれますが、このとき 元々 server 版だったのに open 版のモジュールが選択されることがあります。
open 版モジュールが入ると、ユーザー空間のドライバパッケージも nvidia-driver-580-server から nvidia-driver-580-open に切り替わります。すると nvidia-fabricmanager-580 は apt の依存解決により自動削除されます。
# 障害発生後のパッケージ状態
$ dpkg -l | grep nvidia-driver
ii nvidia-driver-580-open 580.126.09 ← server から open に切り替わっている
$ systemctl status nvidia-fabricmanager
Unit nvidia-fabricmanager.service could not be found. ← 削除されている
この一連のパッケージ遷移は unattended-upgrades のログや /var/log/apt/history.log で確認できますが、nvidia-smi が正常に見えるため障害発生直後に「Fabric Manager が消えた」とすぐ気づくのは難しいです。
実際の障害：発生から復旧まで
発生状況
Ubuntu 24.04 の unattended-upgrades により、夜間にカーネルが自動更新されていました。
# /var/log/apt/history.log より
2026-03-30 23:10:31 linux-image-6.17.0-1009-aws:amd64 6.17.0-1009.9~24.04.2
翌朝、Docker コンテナを起動すると CUDA 初期化エラーが発生。ホスト側の nvidia-smi は 8 GPU を正常に認識しています。
原因の特定
# ドライバは動いている
$ nvidia-smi
# → A100 x8 が正常表示、Driver 580.126.09 / CUDA 13.0
# Fabric Manager は……
$ systemctl status nvidia-fabricmanager
# → Unit nvidia-fabricmanager.service could not be found.
# ドライバのパッケージ種別を確認
$ dpkg -l | grep nvidia-driver
# → nvidia-driver-580-open が入っている（本来は nvidia-driver-580-server）
nvidia-fabricmanager の存在を知っていれば、nvidia-smi 正常 + Docker CUDA 失敗の時点で疑えます。
復旧手順
# 1. open 版ドライバをパージ
sudo apt-get purge -y nvidia-driver-580-open nvidia-kernel-common-580 \
nvidia-kernel-source-580-open linux-modules-nvidia-580-open-aws \
linux-modules-nvidia-580-open-6.17.0-1009-aws
# 2. server 版ドライバ + Fabric Manager をインストール
sudo apt-get install -y nvidia-driver-580-server nvidia-fabricmanager-580
# 3. Fabric Manager を有効化してリブート
sudo systemctl enable nvidia-fabricmanager
sudo reboot
リブート後の確認：
| 確認項目 | 結果 |
|---|---|
| nvidia-smi | Driver 580.126.09 / CUDA 13.0 / A100 x8 認識 |
| nvidia-fabricmanager | active (running) |
| nvidia-driver パッケージ |
nvidia-driver-580-server 580.126.09 |
| Docker コンテナ内 CUDA | 正常起動 |
復旧作業自体は約15分でした（ドライバ再インストール + リブート + コンテナ起動 + 動作確認）。
再発防止
カーネルおよび NVIDIA 関連パッケージを unattended-upgrades の除外リストに追加します。
sudo tee -a /etc/apt/apt.conf.d/50unattended-upgrades << 'EOF'
// GPU環境の安定性のため、カーネルとNVIDIAパッケージの自動更新を除外
Unattended-Upgrade::Package-Blacklist {
"linux-image";
"linux-headers";
"linux-modules-nvidia";
"nvidia-driver";
"nvidia-kernel";
"nvidia-fabricmanager";
};
EOF
これにより、カーネルと NVIDIA ドライバの更新は手動で計画的に実施する運用になります。セキュリティパッチの適用が遅れるリスクと、ドライバ・カーネルモジュールの整合性が壊れて GPU 環境が停止するリスクのトレードオフになるので、運用体制に合わせて判断してください。
なお、apt-mark hold で個別パッケージを固定する方法もありますが、カーネル更新が新しい linux-modules-nvidia-* を引き込むチェーンを止めるには、上記のように unattended-upgrades レベルでブロックする方が確実です。
単一 GPU 環境との違い
Fabric Manager が必要なのは NVSwitch を搭載した環境だけです。
| 環境 | NVSwitch | Fabric Manager | 今回の障害の影響 |
|---|---|---|---|
| p4d.24xlarge (A100 x8) | あり | 必須 | 影響あり |
| p5.48xlarge (H100 x8) | あり | 必須 | 影響あり |
| g5.xlarge (A10G x1) | なし | 不要 | 影響なし |
| ローカル GPU マシン（単一 GPU） | なし | 不要 | 影響なし |
単一 GPU 環境では、同じカーネル自動更新で open 版に切り替わったとしても、Fabric Manager は元々不要なので CUDA は正常に動作します。ただし、カーネル更新によるドライバ互換性の問題（DKMS（Dynamic Kernel Module Support）ビルド失敗等）は別途起こりうるので、GPU 環境では自動更新の除外設定を入れておくのが無難です。
まとめ
マルチ GPU 環境で「nvidia-smi は正常なのに CUDA が動かない」に遭遇したら、Fabric Manager を疑ってみてください。
- Fabric Manager は NVSwitch 搭載マルチ GPU 環境で GPU 間通信を管理するデーモンです。不在だと CUDA が初期化できません
- nvidia-smi はドライバレベルの情報を正しく表示しているだけで、Fabric Manager の状態は守備範囲外です
- Ubuntu の
unattended-upgradesがカーネルを更新すると、NVIDIA ドライバが server → open に切り替わり、Fabric Manager が依存関係で自動削除されることがあります - マルチ GPU 環境では
unattended-upgradesでカーネル・NVIDIA パッケージを除外しておきましょう
Fabric Manager の存在を知っているだけで、次に同じ症状が出たときの切り分けが早くなるはずです。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、
幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。