はじめに Kubernetes上でLLMの推論などGPUを使うワークロードを動かすには、GPUノードにドライバを入れ、PodからGPUを利用できる状態にしておく必要があります。本記事では、インターネットに接続できないAirGap環境のRKE2クラスタに対して、NVIDIA GPU DriverとNVIDIA GPU Operatorを導入し、Kubernetes上でGPUを使えるようにするまでの手順を紹介します。 SUSE AIのようなKubernetes上のAI基盤を構築する際の前提作業にあたりますが、手順自体は特定のAI基盤に依存しない汎用的な内容です。RKE2以外のKubernetesディストリビューションでも、containerdのソケットや設定ファイルのパスを読み替えれば応用できます。 GPU設定に必要なツール KubernetesでGPUを使うには、ノードのOS側でGPUを動かす「NVIDIA GPU Driver」と、Kubernetes側でGPUをリソースとして扱うためのコンポーネント群をまとめて管理する「NVIDIA GPU Operator」の2つが必要です。 NVIDIA GPU Driver NVIDIA GPU Driverは、OSがGPUを認識・制御するためのソフトウェアです。カーネルモジュール（ nvidia 、 nvidia_uvm など）と、 libnvidia-ml.so や libcuda.so といったユーザー空間ライブラリ、 nvidia-smi などの管理ツールで構成されます。コンテナ内のCUDAアプリケーションも、最終的にはホスト上のこのドライバを経由してGPUを利用します。 Kubernetesで使う場合、ドライバの導入方法は次の2通りです。 ホストOSに直接インストールする ：OSのパッケージ管理でドライバを入れる方法です。 GPU Operatorのドライバコンテナで入れる ：GPU Operatorがドライバ入りのコンテナを各ノードで動かし、カーネルモジュールをロードする方法です。 ホストOSに直接インストールする方法はドライバをOSのパッケージ管理で扱えるため、OSの更新やイメージ管理とあわせてドライバを管理したい場合に向いています。また、Kubernetes以外のプロセスからもGPUを使いやすくなります。 GPU Operatorのドライバコンテナで入れる方法は、OperatorがすべてのGPUノードにドライバを自動で導入し、更新も管理するため、GPUノードが多い場合や頻繁に増減する場合に向いています。 本記事では前者のホストOSへの直接インストールの手順を解説します。 なお、ドライバのバージョンはGPU Operatorのサポート対象から選びます（ Release Notes ）。 NVIDIA GPU Operator NVIDIA GPU Operatorは、KubernetesでGPUを使うために必要なNVIDIAのソフトウェア一式を、Operatorパターンで自動的にデプロイ・管理する仕組みです。本来はノードごとに個別に設定する必要があるコンテナランタイムの設定やDevice Pluginなどを、 ClusterPolicy というカスタムリソースでまとめて宣言的に管理できます。 出典： About the NVIDIA GPU Operator GPU Operatorが管理する主なコンポーネントと、本記事での扱いは次のとおりです。 コンポーネント 役割 本記事での扱い Node Feature Discovery（NFD） ノードのハードウェア情報を検出し、NVIDIA GPU搭載ノードにラベルを付与 有効 GPU Feature Discovery（GFD） GPUの型番・メモリ量・ドライババージョンなどを nvidia.com/* ラベルとして付与 有効 NVIDIA Container Toolkit コンテナランタイム（containerd）を設定し、コンテナからGPUを使えるようにする 有効 NVIDIA Device Plugin GPUを拡張リソース nvidia.com/gpu としてkubeletに登録し、Podへ割り当てる 有効（タイムスライシング設定あり） DCGM Exporter GPUの使用率や温度などのメトリクスをPrometheus形式で公開 有効 Operator Validator ドライバ・Toolkit・Device Pluginが正しく動作しているか検証 有効 NVIDIA Driver（コンテナ） ドライバをコンテナとして導入 無効（ホストに導入済みのため） MIG Manager MIG対応GPUの分割構成を管理 無効（MIG非対応のGPUノードを使うため） 設定手順 設定概要 AirGap環境では、インターネットに接続できる作業用端末で必要な資材を集め、閉域側のノードやレジストリへ運び込んでから設定します。全体の流れは次のとおりです。 作業用端末でNVIDIA GPU Driverのパッケージ（.deb）をダウンロードし、GPUノードへ転送する GPUノードにNVIDIA GPU Driverをインストールし、動作を確認する 必要に応じてGPUノードにラベルとテイントを設定する 作業用端末でGPU OperatorのHelmチャートとコンテナイメージを取得し、閉域内のHelmリポジトリ・コンテナレジストリへ登録する RKE2のHelmChartリソースでGPU OperatorをDownstream Clusterにインストールし、動作を確認する インターネットに接続できるのは作業用端末だけです。Downstream Clusterは、閉域内のHarborからチャートとイメージを取得します。 前提条件 GPUノードのOSが、NVIDIA GPU DriverとGPU Operatorのサポート対象であること（ Platform Support ） SUSE Rancher PrimeのRancher Management Server（以下、RMS）と、RMSから管理されるRKE2のDownstream Clusterが構築済みであること RMSとDownstream ClusterはAirGap環境にあり、インターネットに接続できないこと Downstream ClusterのRKE2がcontainerd 2.x系を同梱していること（GPU Operator v25.10以降のCDIを使う前提） インターネットに接続できる作業用端末があり、GPUノードと同じOS・バージョン（本記事ではUbuntu 24.04）であること 作業用端末に helm 、 skopeo 、 kubectl 、Docker（またはPodman）が導入されていること 作業用端末からGPUノードへSSH接続できること 作業用端末からDownstream Clusterを kubectl で操作できること（RMSから取得したkubeconfigを利用） 作業用端末とDownstream Clusterの両方から接続できる、OCI対応のコンテナレジストリ・Helmリポジトリがあること。また、Downstream Clusterの各ノードがそこからイメージを取得できること（RKE2の registries.yaml 設定など） 構築環境 本記事の検証環境は次のとおりです。GPU Operatorの各コンポーネントは、v26.3.3のデフォルトバージョンを使っています。 項目 バージョン・設定 OS Ubuntu 24.04 RKE2 v1.36.3+rke2r1 Rancher Prime v2.15.2 搭載GPU NVIDIA Tesla T4（AWS g4dn.2xlarge） コンテナレジストリ・Helmリポジトリ Harbor NVIDIA GPU Driver 580.178.04（nvidia-driver-580-server） NVIDIA GPU Operator v26.3.3 NVIDIA Container Toolkit v1.19.1 NVIDIA Device Plugin / GPU Feature Discovery v0.19.3 DCGM Exporter 4.5.3-4.8.2-distroless Node Feature Discovery v0.18.3 NVIDIA GPU Driver 設定手順 最初にGPUノードで、搭載されているGPUの種類とカーネルバージョンを確認します。カーネルバージョンは、後でカーネルヘッダをダウンロードする際に使います。 $ lspci | grep -i nvidia # 出力例 00:1e.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev a1) $ uname -r # 出力例 7.0.0-1012-aws 次に、作業用端末でドライバのパッケージをダウンロードします。apt-get install –download-onlyは、実行した環境に導入済みのパッケージをダウンロード対象から外します。そこで、GPUノードと同じUbuntu 24.04のクリーンなコンテナを起動し、その中でダウンロードします。こうすると作業用端末の環境に左右されず、依存パッケージを漏れなく集められます。 $ mkdir -p ~/nvidia-driver-pkgs $ docker run --rm -it -v ~/nvidia-driver-pkgs:/pkgs ubuntu:24.04 bash コンテナ内で、利用可能なドライバを確認します。データセンター向けGPUでは、末尾が -server のパッケージを選びます。 # apt-get update # apt-cache search nvidia-driver | grep server # 出力例 nvidia-driver-470-server - NVIDIA Server Driver metapackage ・ ・ ・ nvidia-driver-580-server - NVIDIA Server Driver metapackage 使用するドライバを決めたら、カーネルヘッダとあわせてダウンロードします。ドライバのDKMSモジュールはGPUノード上でビルドされるため、GPUノードのカーネルに対応した linux-headers が必要です。指定できるバージョンは Launchpad で確認できます。 7.0.0-1012-aws のカーネルバージョンで nvidia-driver-580-server をインストールする場合は、コンテナ内で次のように実行します。ダウンロードしたパッケージは、マウントした /pkgs 経由で作業用端末の ~/nvidia-driver-pkgs に保存されます。 # apt-get install --download-only -y \ nvidia-driver-580-server=580.178.04-0ubuntu0.24.04.1 \ linux-headers-<GPUノードのカーネルバージョン> # cp /var/cache/apt/archives/*.deb /pkgs/ # exit クリーンなコンテナでダウンロードするため、GPUノードに導入済みの基本パッケージも含まれます。GPUノードのパッケージが古い場合、インストール時にそれらも更新される点に注意してください。 ダウンロードしたパッケージを、作業用端末からGPUノードに転送します。 $ scp -r -i <SSH鍵> ~/nvidia-driver-pkgs ubuntu@<GPUノードIP>:~/ GPUノード上でパッケージをインストールし、再起動します。 $ cd ~/nvidia-driver-pkgs $ apt-get install -y --no-download ./*.deb $ sudo reboot 動作確認 再起動後、インストールが正常に完了したかをGPUノード上で確認します。まず、 nvidia-smi でGPUの情報とドライババージョンが表示されることを確認します。 $ nvidia-smi # 出力例 Fri Sep 25 06:34:12 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.178.04 Driver Version: 580.178.04 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 32C P0 26W / 70W | 0MiB / 15360MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ 次に、NVIDIAのカーネルモジュールがロードされていることを確認します。 $ lsmod | grep nvidia # 出力例 nvidia_uvm 2080768 0 nvidia_drm 139264 0 nvidia_modeset 1687552 1 nvidia_drm nvidia 105373696 3 nvidia_uvm,nvidia_drm,nvidia_modeset drm_ttm_helper 20480 1 nvidia_drm video 77824 1 nvidia_modeset 最後に、GPU Operatorの各コンポーネントがドライバとのやり取りに使う libnvidia-ml.so が存在することも確認しておきます（ RKE2 GPU Operators ）。 $ find /usr/ -iname libnvidia-ml.so* # 出力例 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.580.178.04 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so ノードラベリング・テイント設定 GPUを使うアプリケーションだけをGPUノードに配置したい場合は、ラベルとテイントで管理します。ここからの kubectl は、Downstream Clusterのkubeconfigを設定した作業用端末（またはRancher UIのkubectlシェル）で実行します。 ラベルは、ワークロードの nodeSelector や nodeAffinity でGPUノードを指定するために付与します。GPU Operatorの導入後は nvidia.com/gpu.present=true などのラベルも自動で付与されるため、独自ラベルは運用上の必要に応じて付けてください。 $ kubectl label node <GPUノード名> accelerator=nvidia-gpu テイントは、GPUを使わないPodがGPUノードに配置されるのを防ぐために設定します。 $ kubectl taint nodes <GPUノード名> nvidia.com/gpu=dedicated:NoSchedule GPU OperatorのDaemonSetは、デフォルトで nvidia.com/gpu キーの NoSchedule テイントを許容する設定になっているため、このテイントを先に設定しても導入に影響はありません。一方、GPUを使うワークロード側には同じキーの tolerations を設定する必要があります。 NVIDIA GPU Operator 設定手順 まず、閉域内のHarborに次の2つのプロジェクトを作成します。 nvidia-chart ：GPU OperatorのHelmチャート用 nvidia ：GPU Operatorが使うコンテナイメージ用 プロジェクトを非公開にする場合は、Downstream Cluster側にも認証情報の設定が必要です（イメージは registries.yaml 、チャートはHelmChartリソースの認証用フィールド）。 作業用端末からNVIDIA GPU OperatorのHelmチャートをダウンロードします。 $ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia $ helm repo update $ helm pull nvidia/gpu-operator --version v26.3.3 Helmリポジトリにログインし、チャートをOCI形式で登録します。本記事のHarborは自己署名証明書のためTLS検証をスキップしています。 $ helm registry login <Helmリポジトリのドメイン> \ --username <Helmリポジトリのユーザ名> \ --password <Helmリポジトリのパスワード> \ --insecure $ helm push gpu-operator-v26.3.3.tgz oci://<Helmリポジトリのドメイン>/nvidia-chart --insecure-skip-tls-verify 次に、GPU Operatorが使うコンテナイメージを skopeo でコンテナレジストリへコピーします。 コピー元イメージ 使用するコンポーネント nvcr.io/nvidia/gpu-operator:v26.3.3 GPU Operator本体、Operator Validator nvcr.io/nvidia/k8s/container-toolkit:v1.19.1 NVIDIA Container Toolkit nvcr.io/nvidia/k8s-device-plugin:v0.19.3 NVIDIA Device Plugin、GPU Feature Discovery nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless DCGM Exporter registry.k8s.io/nfd/node-feature-discovery:v0.18.3 Node Feature Discovery ${src#*/} で先頭の nvcr.io/ を取り除き、 <コンテナレジストリのドメイン>/nvidia/... という同じ階層でコピーしています。NFDのみ取得元が異なるため、個別にコピーします。 $ REGISTRY=<コンテナレジストリのドメイン> $ skopeo login --tls-verify=false ${REGISTRY} $ for src in \ nvcr.io/nvidia/gpu-operator:v26.3.3 \ nvcr.io/nvidia/k8s/container-toolkit:v1.19.1 \ nvcr.io/nvidia/k8s-device-plugin:v0.19.3 \ nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless; do skopeo copy --dest-tls-verify=false docker://${src} docker://${REGISTRY}/${src#*/} done $ skopeo copy --dest-tls-verify=false \ docker://registry.k8s.io/nfd/node-feature-discovery:v0.18.3 \ docker://${REGISTRY}/nvidia/node-feature-discovery:v0.18.3 RKE2のHelmChartリソースとして、GPU Operatorのインストール設定を記載した gpu-operator-helm-chart.yaml を作成します。ポイントは次の3点です。 イメージの参照先 ：各コンポーネントの repository を閉域内のレジストリに向けます。 ホスト導入済みドライバの利用 ： driver.enabled: false とし、使わないコンポーネントも無効にして、ミラーが必要なイメージを減らしています。MIG対応GPUを使う場合は migManager を有効にし、 k8s-mig-manager イメージもコピーしてください。 RKE2固有の設定 ：RKE2のcontainerdはソケットの場所が標準と異なるため、 toolkit.env で CONTAINERD_SOCKET を指定します（ RKE2 GPU Operators ）。 devicePlugin.config はタイムスライシングの設定です。 replicas: 4 により、1枚の物理GPUを4つの nvidia.com/gpu として公開し、複数のPodで時分割共有できます。ただし、Pod間でGPUメモリは分離されないため、不要な場合は config ブロックごと削除してください（ Time-Slicing GPUs ）。 apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: gpu-operator namespace: kube-system spec: chart: oci://<Helmリポジトリのドメイン>/nvidia-chart/gpu-operator version: v26.3.3 targetNamespace: gpu-operator createNamespace: true insecureSkipTLSVerify: true valuesContent: |- validator: repository: <コンテナレジストリのドメイン>/nvidia image: gpu-operator version: v26.3.3 operator: repository: <コンテナレジストリのドメイン>/nvidia image: gpu-operator version: v26.3.3 devicePlugin: repository: <コンテナレジストリのドメイン>/nvidia image: k8s-device-plugin version: v0.19.3 # タイムスライシングを使わない場合はconfigブロックを削除 config: create: true name: "time-slicing-config" default: "t4-sharing" data: t4-sharing: |- version: v1 flags: migStrategy: none sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 dcgmExporter: repository: <コンテナレジストリのドメイン>/nvidia/k8s image: dcgm-exporter version: 4.5.3-4.8.2-distroless gfd: repository: <コンテナレジストリのドメイン>/nvidia image: k8s-device-plugin version: v0.19.3 toolkit: repository: <コンテナレジストリのドメイン>/nvidia/k8s image: container-toolkit version: v1.19.1 env: - name: CONTAINERD_SOCKET value: /run/k3s/containerd/containerd.sock node-feature-discovery: image: repository: <コンテナレジストリのドメイン>/nvidia/node-feature-discovery tag: v0.18.3 # ホストにドライバを導入済みのため無効化 driver: enabled: false # 本記事では使わないコンポーネント migManager: enabled: false vgpuDeviceManager: enabled: false vfioManager: enabled: false sandboxDevicePlugin: enabled: false kataSandboxDevicePlugin: enabled: false ccManager: enabled: false 作成したHelmChartリソースをDownstream Clusterに適用します。RKE2のHelm Controllerがチャートを取得し、GPU Operatorをインストールします。 $ kubectl apply -f gpu-operator-helm-chart.yaml Container Toolkitは設定を反映するためにcontainerdへ再読み込みを指示し、その影響でGPUノードのRKE2が再起動します。稼働中のワークロードがある場合は、作業タイミングに注意してください。 動作確認 GPU OperatorのPodがすべて Running または Completed になっていることを確認します。出力例はGPUノード2台の環境のものです。 $ kubectl get pod -n gpu-operator # 出力例 NAME READY STATUS RESTARTS AGE gpu-feature-discovery-8t85l 2/2 Running 0 5m gpu-feature-discovery-kkwbb 2/2 Running 0 5m gpu-operator-7974d8cf9-qq7bh 1/1 Running 0 5m gpu-operator-node-feature-discovery-gc-5c84b6f5c4-tmf9k 1/1 Running 0 5m gpu-operator-node-feature-discovery-master-6db6986c58-bjdsg 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-55v8j 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-b944b 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-cxrxs 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-kmmv2 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-qnz9w 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-wxln9 1/1 Running 0 5m nvidia-container-toolkit-daemonset-4kkbt 1/1 Running 0 5m nvidia-container-toolkit-daemonset-vbgnc 1/1 Running 0 5m nvidia-cuda-validator-b8grf 0/1 Completed 0 5m nvidia-cuda-validator-z7skc 0/1 Completed 0 5m nvidia-dcgm-exporter-6dhd5 1/1 Running 0 5m nvidia-dcgm-exporter-8mhhp 1/1 Running 0 5m nvidia-device-plugin-daemonset-6v4xz 2/2 Running 0 5m nvidia-device-plugin-daemonset-snx4x 2/2 Running 0 5m nvidia-operator-validator-4ldlj 1/1 Running 0 5m nvidia-operator-validator-kctw6 1/1 Running 0 5m GPU Operator全体の状態を表すClusterPolicyが ready になっていることも確認します。 $ kubectl get clusterpolicy # 出力例 NAME STATUS AGE cluster-policy ready <作成日時> 以下のコマンドを実行し、GPUノードのラベルに nvidia.com/gpu.machine などのGPU関連ラベルが付与されていることを確認します。 $ kubectl get node <GPUノード名> -o jsonpath='{.metadata.labels}' | tr ',' '\n' | grep "nvidia.com" # 出力例 "nvidia.com/cuda.driver-version.full":"580.178.04" "nvidia.com/cuda.driver-version.major":"580" "nvidia.com/cuda.driver-version.minor":"178" "nvidia.com/cuda.driver-version.revision":"04" "nvidia.com/cuda.driver.major":"580" "nvidia.com/cuda.driver.minor":"178" "nvidia.com/cuda.driver.rev":"04" "nvidia.com/cuda.runtime-version.full":"13.0" "nvidia.com/cuda.runtime-version.major":"13" "nvidia.com/cuda.runtime-version.minor":"0" "nvidia.com/cuda.runtime.major":"13" "nvidia.com/cuda.runtime.minor":"0" "nvidia.com/gfd.timestamp":"1790646472" "nvidia.com/gpu.compute.major":"7" "nvidia.com/gpu.compute.minor":"5" "nvidia.com/gpu.count":"1" "nvidia.com/gpu.deploy.container-toolkit":"true" "nvidia.com/gpu.deploy.dcgm":"true" "nvidia.com/gpu.deploy.dcgm-exporter":"true" "nvidia.com/gpu.deploy.device-plugin":"true" "nvidia.com/gpu.deploy.driver":"true" "nvidia.com/gpu.deploy.gpu-feature-discovery":"true" "nvidia.com/gpu.deploy.node-status-exporter":"true" "nvidia.com/gpu.deploy.operator-validator":"true" "nvidia.com/gpu.family":"turing" "nvidia.com/gpu.machine":"g4dn.2xlarge" "nvidia.com/gpu.memory":"15360" "nvidia.com/gpu.mode":"compute" "nvidia.com/gpu.present":"true" "nvidia.com/gpu.product":"Tesla-T4-SHARED" "nvidia.com/gpu.replicas":"4" "nvidia.com/gpu.sharing-strategy":"time-slicing" "nvidia.com/mig.capable":"false" "nvidia.com/mig.strategy":"single" "nvidia.com/mps.capable":"false" "nvidia.com/vgpu.present":"false" ノードの割り当て可能リソースに nvidia.com/gpu が追加されていることを確認します。値は「物理GPUの枚数 × タイムスライシングのreplicas」で、本記事では1 × 4 = 4です。タイムスライシングを使わない場合は物理GPUの枚数と一致します。 $ kubectl get node <GPUノード名> -o jsonpath='{.status.allocatable}' # 出力例 {"cpu":"8","ephemeral-storage":"196555267123","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"32479456Ki","nvidia.com/gpu":"4","pods":"110"} GPUノード上で、NVIDIAコンテナランタイムのバイナリが配置され、RKE2のcontainerd設定にNVIDIAランタイムが追加されていることを確認します。 $ ls /usr/local/nvidia/toolkit/nvidia-container-runtime # 出力例 /usr/local/nvidia/toolkit/nvidia-container-runtime $ grep nvidia /var/lib/rancher/rke2/agent/etc/containerd/config.toml # 出力例 [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'] [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'.options] BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime" [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia-cdi'] [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia-cdi'.options] BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime.cdi" おわりに 本記事では、AirGap環境のRKE2クラスタに対して、ホストへのNVIDIA GPU Driverの導入と、HelmChartリソースによるNVIDIA GPU Operatorの導入を行いました。AirGap環境では、依存パッケージを漏れなく集めることと、イメージの参照先をすべて閉域内のレジストリに向けることが主なポイントです。 これで、GPUを使うAIアプリケーションをクラスタ上で動かす準備が整いました。次回はSUSE AI Factoryのインストール方法について解説したいと思います。 参考 About the NVIDIA GPU Operator Installing the NVIDIA GPU Operator Install NVIDIA GPU Operator in Air-Gapped Environments NVIDIA GPU Operator Release Notes NVIDIA GPU Operator Platform Support Time-Slicing GPUs in Kubernetes RKE2 Documentation – GPU Operators nvidia-graphics-drivers-580-server package in Ubuntu（Launchpad） ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SUSE RancherでのGPUノード設定方法解説 〜AirGap環境へのNVIDIA GPU Driver・GPU Operator導入〜 first appeared on SIOS Tech Lab .

みなさまこんにちは。自動車・製造インダストリーソリューションアーキテクトの 小川 です。10月に入っても関東は秋雨模様のお天気から徐々に秋晴れの日も増えてきましたね。こちらの「 月刊AWS製造 」ブログでは直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例や今後開催予定のイベントなどを毎月お届けしています。最近Amazonの独自チップ開発に関する記事やニュースが複数出ていたので、今月は製品設計開発領域でのAI活用に関して、ピックアップトピックとして触れさせて頂きます。 ピックアップトピック: Amazonの独自チップ開発とEDAツールベンダーとのコラボレーションに垣間見るAIネイティブ設計 Amazonは2015年1月に半導体設計開発を行うAnnapurna Labsをチームに加え、AWSのデータセンター ネットワーク や 仮想化基盤 、 Graviton や Trainium 、 Inferentia などの独自チップを内製で開発し利用・提供しています。これらのチップはチップ単位で外販しておらず、独自チップを社内で運用しドッグフーディングできているのは、大規模なインフラを運用しているAWSだからできるユニークな取り組みと言えます。顧客の機能要求をチップレベルで実装しAIチップのロードマップを形作ったストーリーなども こちらのAmazon News で触れられているので、ご興味ある方は参照ください。 EDAツールベンダーのSynopsysと組む狙い 先日 9/30に EDAツール大手のSynopsys社とAmazonが総額10億ドルにおよぶライセンス契約と双方の協業についてプレスリリース を行いました。この契約にはSynopsysが有するIPやソフトウェアプロダクトをAmazonが利用する契約に加えて、SynopsysがAWSのクラウド環境を使用して、EDAアプリケーションの開発スピードを早めたり、AIネイティブなエンジニアリングを目指す事で、双方のチームの生産性を上げることが掲げられています。 先端プロセスの半導体は1チップのトランジスタ数が 10 Billion を超える世界になっており、Amazonも公開しているものだと、 Graviton4のチップで 730億のトランジスタ を集積しています。このような巨大チップを開発するにはEDAを駆使し大量のコンピューティング能力を使ってシミュレーションする必要があり、人的にも物的にも開発リソースの逼迫が次世代チップの開発の妨げになっています。この壁を乗り越えるアプローチがAIネイティブなエンジニアリングであり、EDAツールベンダーとコラボレーションすることで、設計者は使い慣れた開発ツールの延長でAIを活用して開発を効率化できる機会を得られる可能性があります。 製造業の設計開発現場でのAI活用の現在地 製造業の設計開発現場ではエレキ設計のEDA、メカ設計のCAD、工学シミュレーションのCAE など各種ツールチェーンを用いて設計開発を行っています。ソフトウェア開発の領域ではAWSだと Kiro に代表されるコーディングエージェントの台頭によって AI活用が急速に進んでいますが、CAD、CAE、EDAなど各種アプリケーションを操作して開発を行う現場では、その特性上 エンジニアリング現場でのAI活用はユースケース毎に分けて活用されているというのが現在地です。 例えばシミュレーション結果を予測するAIサロゲートモデル、マニュアルドキュメントやナレッジを検索/要約して設計作業を支援するRAG、自然言語でCADやCAEのアプリケーションを操作するMCPなどの活用が挙げられます。これらはアプリケーションベンダー側でもAIの新プロダクトとして提供したり、既存CAD/CAE/EDAツールにAI機能を付加するなどの動きがあり、先のSynopsysのプレスリリースはこれらの流れを組むものです。かたや、複数ベンダーのツールチェーンをAIエージェントが横断的に連携処理させたり、自社のルールに則った設計内容になっているかAIにチェックさせたい、といった需要もよく聞かれ、これには独自にカスタムしたエージェントやMCPを用意したり、自社の設計データやドキュメントならびにツールチェーンのナレッジなどを加えたファインチューニングによる独自AIモデルを作成するようなアプローチが考えられます。AWSでは製品設計開発における AI活用のデモ 、 ワークショップ 、 情報発信 など数々行っていますので、チェックして頂き、気になるものがあれば近くのAWSメンバーに相談ください。 この分野はすさまじいスピードで進化しており、最近も空間認知能力をもつとされる GPT-6 Astra がリリースされた事で、吊るしの基盤モデルで3D設計も職人級の仕事ができてしまうようになる日もそう遠くないのかもしれません。 直近で開催予定のイベント 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催、AWSもブース展示を行います。AWSブースのテーマは「日本の担い手と、フィジカルAI社会を実現するAWS Japan 」です。安川電機様とコラボレーションした展示や、今回 CEATEC AWARDを受賞 した「AIエージェントがロボットを育てる ― 一行の指示から実機までをつなぐPhysical AI自律R&D基盤」など複数の展示を行う予定ですので是非AWSブースにお立ち寄りください。 11/7 JAWS FESTA 2026 年に一度、全国各地で開催されるJAWS-UGのお祭イベント。 JAWS-UG （ユーザーコミュニティ）主催 で、特定業種ではなく 横断的な技術テーマ が中心で、製造業「専用」のトラックやセッションはありませんが、スマート農業×AI/XR、IoT現場活用、設計書のAI活用、BCP、データ基盤 といった、製造業でも応用できるセッションが複数あります。 11/18 – 20 EdgeTech+2026 組込み・エッジ技術を中心にAI/IoT/セキュリティ等の最新技術を集めた、300社以上が出展する国内最大級のエッジテクノロジー総合展示会です。パシフィコ横浜で開催され、AWSは組み込み開発や自動車関連の講演を予定しています。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造業でフィルタリングしたセッションカタログ の他、キーノートや展示などでも製造業に関わるトピックが例年存在します。オンラインで視聴できる内容もありますので、是非チェックしてください。 製造関連ブログのご紹介 9/2 Building a Production AI Agent on AWS: A Six-Pillar Walkthrough 「PoC では動いたエージェントが、本番にはなかなか載らない」。その原因を、作る・試す・動かす・守る・観測する・統制する（Build / Test / Run / Secure / Observe / Govern）の 6 つの柱に分解して解説した記事です。走る例として自動車製造工場の部品在庫エージェントを使い、Amazon Bedrock AgentCore や Bedrock Guardrails、Cedar によるポリシー制御を組み合わせています。エージェントの試作は済んだものの、本番運用に向けた守りと統制の設計をこれから固めたい方に参考になります。 9/9 Manage ESG data and simplify Sustainability reporting with Amazon Quick サステナビリティ報告の難所は、設備管理・調達・カーボン会計など各所に散らばった情報を監査に耐える開示へまとめ上げる点にあります。本記事は Amazon Quick をサステナビリティ情報のハブとして、要件分析からレポート生成までを 5 つのフェーズで組み立て、ESRS や CDP など複数フレームワークへ一元データからマッピングする構成を示します。報告フレームワークへの対応に追われている方の負担を軽くするヒントになります。 9/10 How Apollo Tyres Uses AI-Driven APC for First Time Right Tyre Extrusion タイヤの押出ラインでは、レシピを変えるたびに規格外の材料が出る立ち上げが発生し、1 日 30〜35 回の段取り替えを行う現場では総生産量の 5〜6% を占めていました。Apollo Tyres 様は、エッジで動く予測モデルと閉ループの APC 制御で最適な立ち上げ速度を自動付与し、立ち上げ時の手直しを約 26%、安定化時間を約 40% 削減、月あたり約 20 時間の生産時間を回収しました。Apollo Tyres Ltd の Harsh Vardhan 氏との共著です。段取り替えの多いプロセス系ラインで歩留まりとスループットの両立を狙う方におすすめです。 9/10 Reducing paint shop downtime with Industrial Data Fabric on AWS システムごとにデータが閉じていると、ライン停止の原因を SCADA や MES、停止ログの突き合わせで探すことになり、根本原因分析に 2〜4 時間かかることもあります。Mahindra 様の塗装工場では、分断データを Industrial Data Fabric で文脈化したナレッジグラフ（Amazon Neptune）に統合し、Amazon Bedrock AgentCore 上の 2 つのエージェントが上流の原因まで自然言語で提示します。平均修復時間（MTTR）を 20%、他工場への横展開時間を 30% 削減しました。同じ仕組みを複数拠点へ広げたい方の設計の参考になります。 9/27 Building AI-augmented B-pillar DFMEA on AWS: Architecture, multi-agent orchestration, and implementation 設計 FMEA（DFMEA）は品質工学の中核ですが、手作業では潜在的な故障モードを見落としやすい課題があります。本記事は自動車の B ピラーを題材に、オントロジーで表現した知識グラフとマルチエージェントのオーケストレーションで、故障モードの網羅性とトレーサビリティ（ISO 26262 / IATF 16949）を高める実装例をサンプルコードとともに示します。確信度が低い場合は人に差し戻す設計で、自律化と品質保証を両立します。FMEA の網羅性やトレーサビリティに課題を感じる設計・品質部門の方に向いた内容です。 9/30 【開催報告】組み込みソフトウェア開発でも AI エージェントは活用できる ─ 日立産業制御ソリューションズ様とのワークショップ 日立産業制御ソリューションズ様との共催ワークショップでは、既存の組み込みコード（HVAC 制御システム）を題材に、コードの読み解きから仕様の捉え直し、設計、実装、テストまでを AI コーディングエージェント Kiro で体験しました。指示を GitLab の Issue に書き、エージェントが経過をコメントに書き戻すことで、人が判断した箇所がチケットに残る点が長期保守向きです。2 回のワークショップに開発者 102 名が参加しました。既存コードの保守・仕様化という上流工程で AI を活用した効率化を進めたい方におすすめです。 製造関連の主要なサービスアップデート 9/18 Amazon Bedrock AgentCore の新しい AgentCore Runtime が一般提供開始 エージェント実行基盤のサーバーレス環境が刷新されました。セッション中に使われていないメモリを回収する弾力的なメモリ管理と、イメージサイズによらず一定の高速なコールドスタートが特長です。現場支援や保全のエージェントを本番運用する際のコスト最適化につながります。東京リージョン（ap-northeast-1）でも利用できます。ピックアップトピックで触れたエージェントの本番化を下支えする機能です。 9/18 Amazon SageMaker HyperPod Inference Gateway HyperPod 上での大規模言語モデル推論に向けた、Kubernetes ネイティブなルーティング層です。KV キャッシュの使用率やキューの深さといった実シグナルに基づいてルーティングし、初回トークンまでの遅延を最大 82% 削減します。大規模な産業向け AI 推論基盤を運用する際に関係します。 9/26 Amazon CloudWatch Omni アプリケーションと AI エージェントを単一の画面で観測できる新しいオブザーバビリティ機能です。OpenTelemetry ベースで既存のテレメトリをそのまま取り込み、サービスの自動検出や依存関係のマッピングを提供します。前述のエージェントの可観測性（Observe の柱）を実装する際の選択肢になります。 9/26 Amazon EventBridge の強化されたカスタムイベントバス 組織をまたいだイベント駆動アプリケーション向けに、カスタムイベントバスが強化されました。AWS RAM 経由で複数アカウントが共有できる集中バス、順序保証、コンテンツベースの重複排除などに対応します。工場やサプライチェーンをまたぐイベント連携の基盤として活用できます。 最後まで読んでいただきありがとうございました。 季節の変わり目で寒暖差疲労を起こしやすい時期ですので、風邪などお召しにならないよう体調管理に気をつけてお過ごしください。また来月も 月刊AWS製造ブログ でお会いしましょう！ 著者について 小川 貴士 (Takashi Ogawa) 国内システムインテグレーターでインフラエンジニアとして従事した後、HPCソリューションアーキテクトとしてAWSに入社。現在は自動車・製造業にフォーカスするインダストリーソリューションアーキテクトとして、主にR&D部門のお客様のDXをご支援しています。

NTTデータ3年目社員の栫と、1年目社員の喜田（@kidatakeru）、齋藤（@maaya）です。 2026年7月30日・31日に東京ビッグサイトで開催されたGoogle Cloud Next Tokyo 26のDAY 2レポートです。 DAY 2で特に印象に残ったのは、運用に関する話題の多さです。 基調講演ではAIエージェントを動かし続けるための基盤が紹介され、各セッションでもデータベース移行に伴うチューニング、ハイブリッドクラウド運用、障害対応、オブザーバビリティなど、システムを継続的に運用するための工夫が語られていました。 新機能そのものよりも、「作った後にどう運用するか」に焦点