Skip to content
Published on

Slurm 完全攻略：HPC/AI クラスター ワークロードマネージャー実践ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Authors
  • Name
    Twitter

1. Slurm とは

Slurm（Simple Linux Utility for Resource Management）は、Linux クラスター向けのオープンソース、耐障害性、高拡張性ワークロードマネージャーである。HPC（High-Performance Computing）および AI 学習インフラにおける事実上の標準だ。

1.1 3つの中核機能

  1. リソース割り当て：ユーザーに対し、指定時間コンピュートノードへの排他的／共有アクセスを付与
  2. ジョブ実行フレームワーク：割り当てられたノード上で並列ジョブを起動・実行・モニタリング
  3. キュー管理：高度なスケジューリングアルゴリズムによるリソース競合の調整

1.2 歴史

年イベント
2002Lawrence Livermore National Laboratory（LLNL）にて初回リリース
2010コア開発者らが SchedMD を設立（商用サポート、開発、教育）
2025.12NVIDIA が SchedMD を買収 — オープンソース・ベンダー中立維持を約束

1.3 誰が使っているのか

  • TOP500 スーパーコンピューターの約 60〜65% が Slurm を使用
  • 代表的なシステム：Frontier（Oak Ridge、第1位）、Perlmutter（NERSC）、Polaris（Argonne）
  • クラウド：AWS ParallelCluster、Google Cloud HPC、Azure CycleCloud
  • AI 企業：大規模 LLM 学習、画像生成モデル学習
  • 産業：自動運転、ヘルスケア、エネルギー、金融、政府系研究所

ライセンス：GNU GPL v2（オープンソース）

2. アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│                   Slurm Architecture                         │
│                                                              │
│  ┌────────────────┐        ┌────────────────┐                │
│  │  slurmctld     │        │  slurmctld     │                │
│  │  (Primary)     │◄──────►│  (Backup)      │                │
│  │  Head Node     │  HA    │  Backup Node   │                │
│  └───────┬────────┘        └────────────────┘                │
│          │ RPC (TCP)                                         │
│  ┌───────┼──────────────────────────────────┐                │
│  │       ▼          ▼          ▼            │                │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐    │                │
│  │  │ slurmd  │ │ slurmd  │ │ slurmd  │    │ Compute Nodes  │
│  │  │ Node 01 │ │ Node 02 │ │ Node N  │    │                │
│  │  └─────────┘ └─────────┘ └─────────┘    │                │
│  └──────────────────────────────────────────┘                │
│                                                              │
│  ┌────────────────┐        ┌────────────────┐                │
│  │  slurmdbd      │        │  slurmrestd    │                │
│  │  (Database)    │        │  (REST API)    │                │
│  │  MySQL/MariaDB │        │  JSON / JWT    │                │
│  └────────────────┘        └────────────────┘                │
└─────────────────────────────────────────────────────────────┘

2.1 デーモンごとの役割

デーモン役割配置場所
slurmctld中央管理（スケジューリング、リソース監視、ジョブキュー）ヘッドノード
slurmdタスク実行、リソース使用量監視、状態報告全コンピュートノード
slurmdbdジョブアカウンティング、履歴、使用統計（MySQL/MariaDB バックエンド）DB サーバー
slurmrestdHTTP RESTful API（JSON、JWT 認証）API サーバー

2.2 プラグインアーキテクチャ

Slurm は拡張可能なプラグインアーキテクチャに対応している：

  • 認証（auth/munge、auth/jwt）
  • コンテナ（OCI、Singularity、Enroot）
  • GPU/GRES 管理
  • MPI 実装（PMIx、PMI2）
  • スケジューリングアルゴリズム（backfill、priority multifactor）
  • プロセストラッキング（cgroup、linuxproc）

3. 中核概念

3.1 Node、Partition、Job

概念説明
Node基本的なコンピュートリソース。CPU、メモリ、GPU、ディスク属性を持つ
Partitionノードの論理的なグループ ＝ ジョブキュー。アクセス制御、リソース上限、優先度を設定
Jobユーザーに指定時間割り当てられたリソース。一意な ID、リソース要件、状態を保持
Job Stepジョブ内の並列タスクの集合。個別の Job よりオーバーヘッドが少ない
Job 1234
  ├── Step 0: データ前処理（1ノード）
  ├── Step 1: 学習（4ノード、32タスク）
  └── Step 2: 評価（1ノード）

3.2 Account、QoS、Fairshare

Account：リソース使用量追跡のための階層的な組織単位

root
├── engineering
│   ├── ml-team
│   └── platform-team
└── research
    ├── physics
    └── biology

QoS（Quality of Service）：ジョブの挙動を制御する上限と優先度のセット

  1. スケジューリング優先度
  2. プリエンプション（先取り）ポリシー
  3. リソース上限（CPU、GPU、メモリ、同時実行ジョブ数）

Fairshare：過去のリソース使用量を考慮した公平割り当てスケジューリング

  • 各アカウントに投資／資格に比例した share を割り当て
  • 使用量が少ないユーザー → 高優先度、使用量が多いユーザー → 低優先度
  • 直近の使用量により大きな重みを付与（減衰ファクター）

3.3 優先度計算（Multifactor）

Job Priority = site_factor
             + (WeightAge)       × age_factor       -- 待ち時間
             + (WeightFairshare) × fairshare_factor  -- 公平分配
             + (WeightJobSize)   × job_size_factor   -- ジョブサイズ
             + (WeightPartition) × partition_factor   -- パーティション等級
             + (WeightQOS)       × QOS_factor        -- QoS 等級
             + TRES weights                           -- GPU 等リソース重み
             - nice_factor                            -- ユーザー譲歩値

4. 必須コマンド

4.1 sbatch — バッチジョブの投入

# 基本的な投入
sbatch job.sh

# オプションのオーバーライド
sbatch --partition=gpu --nodes=2 --gres=gpu:4 --time=24:00:00 train.sh

# ジョブ名と出力先を指定
sbatch --job-name=my_training --output=train_%j.log job.sh

# 特定のアカウントと QoS を指定
sbatch --account=ml-team --qos=high job.sh

4.2 srun — 並列ジョブ／ステップの実行

# 3ノードでホスト名を出力
srun -N3 -l /bin/hostname

# インタラクティブ GPU ジョブ
srun --partition=gpu --gres=gpu:1 --pty bash

# GPU バインド付きで実行
srun --ntasks=4 --gpus-per-task=1 --gpu-bind=closest python train.py

4.3 salloc — リソースのインタラクティブ割り当て

# GPU ノード2台、4時間の割り当て
salloc --nodes=2 --gres=gpu:4 --time=04:00:00 --partition=gpu

# 特定機能を要求
salloc -N1 --constraint=a100 --gres=gpu:8 --mem=512G

4.4 squeue — ジョブキューの照会

# 自分のジョブのみ表示
squeue -u $USER

# カスタムフォーマット
squeue -o "%.10i %.9P %.20j %.8u %.2t %.10M %.6D %R"

# PENDING ジョブと理由を表示
squeue -t PENDING -o "%.10i %.20j %.8u %.10M %R"

4.5 sinfo — システム情報の照会

# パーティションの概要
sinfo

# GPU リソースを表示
sinfo -o "%20N %10c %10m %20G %10t"

# アイドルノード
sinfo -t idle

4.6 scancel — ジョブの取り消し

scancel 12345              # 特定のジョブを取り消し
scancel -u $USER           # 自分のジョブをすべて取り消し
scancel -t PENDING -u $USER  # PENDING ジョブのみ取り消し
scancel 12345_[1-10]       # 特定の Array タスクを取り消し

4.7 sacct — ジョブアカウンティング

# 完了したジョブの照会
sacct -u $USER

# 詳細フォーマット
sacct -j 12345 --format=JobID,JobName,Partition,State,Elapsed,MaxRSS,MaxVMSize,TotalCPU

# 日付範囲で照会
sacct --starttime=2026-01-01 --endtime=2026-01-31 -u $USER

4.8 scontrol — 管理制御

scontrol show job 12345       # ジョブの詳細情報
scontrol show node gpu-001    # ノードの詳細情報
scontrol hold 12345           # ジョブの保留
scontrol release 12345        # 保留の解除
scontrol update JobId=12345 TimeLimit=48:00:00  # 制限時間の変更
scontrol ping                 # コントローラーへの接続テスト

5. ジョブスクリプトの例

5.1 基本的な CPU ジョブ

#!/bin/bash
#SBATCH --job-name=basic_job
#SBATCH --partition=compute
#SBATCH --nodes=1
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=2
#SBATCH --mem=16G
#SBATCH --time=02:00:00
#SBATCH --output=output_%j.log
#SBATCH --error=error_%j.log

module load gcc/12.2.0
module load openmpi/4.1.5

echo "Job started on $(hostname) at $(date)"
echo "SLURM_JOB_ID: $SLURM_JOB_ID"
echo "SLURM_NODELIST: $SLURM_NODELIST"

srun ./my_simulation --input data.csv --output results/
echo "Job completed at $(date)"

5.2 単一ノード GPU ジョブ

#!/bin/bash
#SBATCH --job-name=gpu_training
#SBATCH --partition=gpu
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=64G
#SBATCH --gres=gpu:a100:2
#SBATCH --time=12:00:00
#SBATCH --output=train_%j.log

module load cuda/12.2
module load anaconda/2024
conda activate ml_env

echo "Available GPUs: $CUDA_VISIBLE_DEVICES"
nvidia-smi

python train.py \
    --model resnet50 \
    --batch-size 256 \
    --epochs 100 \
    --data /shared/datasets/imagenet \
    --output /scratch/$USER/checkpoints/

5.3 マルチノード MPI ジョブ

#!/bin/bash
#SBATCH --job-name=mpi_job
#SBATCH --partition=compute
#SBATCH --nodes=8
#SBATCH --ntasks-per-node=32
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=4G
#SBATCH --time=24:00:00
#SBATCH --exclusive

module load openmpi/4.1.5

echo "Running on $SLURM_NNODES nodes with $SLURM_NTASKS total tasks"
srun ./weather_simulation --grid-size 4096x4096x128 --timesteps 10000

5.4 Job Array（ハイパーパラメータスイープ）

#!/bin/bash
#SBATCH --job-name=hparam_sweep
#SBATCH --partition=gpu
#SBATCH --array=0-19%5            # 20タスク、最大5つ同時実行
#SBATCH --nodes=1
#SBATCH --gres=gpu:1
#SBATCH --mem=32G
#SBATCH --time=06:00:00
#SBATCH --output=sweep_%A_%a.log  # %A=Array ID, %a=Task ID

LEARNING_RATES=(0.1 0.01 0.001 0.0001 0.00001)
BATCH_SIZES=(32 64 128 256)

LR_IDX=$((SLURM_ARRAY_TASK_ID / 4))
BS_IDX=$((SLURM_ARRAY_TASK_ID % 4))
LR=${LEARNING_RATES[$LR_IDX]}
BS=${BATCH_SIZES[$BS_IDX]}

echo "Task $SLURM_ARRAY_TASK_ID: LR=$LR, BS=$BS"
python train.py --lr $LR --batch-size $BS \
    --experiment-name "sweep_${SLURM_ARRAY_JOB_ID}_${SLURM_ARRAY_TASK_ID}"

5.5 Job Dependencies（パイプライン）

# Step 1: 前処理
JOB1=$(sbatch --parsable preprocess.sh)

# Step 2: 学習（前処理成功後）
JOB2=$(sbatch --parsable --dependency=afterok:$JOB1 train.sh)

# Step 3: 評価（学習成功後）
JOB3=$(sbatch --parsable --dependency=afterok:$JOB2 evaluate.sh)

# Step 4: クリーンアップ（全ジョブ完了後、成功・失敗を問わず）
JOB4=$(sbatch --parsable --dependency=afterany:$JOB1:$JOB2:$JOB3 cleanup.sh)

依存関係のタイプ：

タイプ意味
after:jobidジョブ開始後
afterok:jobidジョブの正常完了後
afternotok:jobidジョブ失敗後
afterany:jobidジョブ完了後（成功・失敗を問わず）
aftercorr:jobidArray：対応するタスクの正常完了後
singleton同名のジョブが同時に1つだけ実行される

6. GPU スケジューリング（GRES）

6.1 設定

slurm.conf：

GresTypes=gpu,mps,shard
NodeName=gpu-node[01-08] Gres=gpu:a100:8 CPUs=128 RealMemory=1024000
AccountingStorageTres=gres/gpu

gres.conf：

# 自動検出（推奨）
AutoDetect=nvml    # NVIDIA
# AutoDetect=rsmi  # AMD
# AutoDetect=nrt   # Intel Arc

6.2 GPU のリクエスト方法

# 任意タイプの GPU 2基
sbatch --gres=gpu:2 job.sh

# 特定の GPU タイプ
sbatch --gres=gpu:a100:4 job.sh

# ノードあたりの GPU
sbatch --nodes=4 --gpus-per-node=8 job.sh

# タスクあたりの GPU + CPU/メモリアフィニティ
sbatch --ntasks=8 --gpus-per-task=1 --cpus-per-gpu=8 --mem-per-gpu=32G job.sh

Slurm は GPU の隔離のために CUDA_VISIBLE_DEVICES を自動設定する。

6.3 GPU 共有オプション

方法説明設定
MPS (Multi-Process Service)マルチプロセスによる GPU 共有、カーネル並列実行Gres=gpu:a100:8,mps:800
MIG (Multi-Instance GPU)A100/H100 を独立インスタンスに分割AutoDetect=nvml（自動検出）
Shard隔離なしの GPU 共有（軽量推論向け）Gres=gpu:2,shard:64

7. AI/ML 分散学習

7.1 PyTorch DDP（マルチノード）

sbatch スクリプト（4ノード x 8GPU = 32GPU）：

#!/bin/bash
#SBATCH --job-name=ddp-multigpu
#SBATCH --partition=gpu
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=1
#SBATCH --gres=gpu:8
#SBATCH --cpus-per-task=64
#SBATCH --mem=0
#SBATCH --exclusive
#SBATCH --time=72:00:00
#SBATCH --output=ddp_%j.log

export MASTER_PORT=$(( RANDOM % (50000 - 30000 + 1) + 30000 ))
export MASTER_ADDR=$(scontrol show hostnames $SLURM_JOB_NODELIST | head -n 1)
export WORLD_SIZE=$(( SLURM_NNODES * 8 ))

echo "MASTER_ADDR=$MASTER_ADDR, MASTER_PORT=$MASTER_PORT, WORLD_SIZE=$WORLD_SIZE"

# NCCL 設定
export NCCL_DEBUG=INFO
export NCCL_SOCKET_IFNAME=^docker0,lo

srun torchrun \
    --nnodes $SLURM_NNODES \
    --nproc_per_node 8 \
    --rdzv_id $SLURM_JOB_ID \
    --rdzv_backend c10d \
    --rdzv_endpoint $MASTER_ADDR:$MASTER_PORT \
    train.py \
        --model llama-7b \
        --data /shared/datasets/openwebtext \
        --batch-size 32 \
        --gradient-accumulation-steps 4

Python 学習スクリプトのパターン：

import os
import torch
import torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
from torch.utils.data.distributed import DistributedSampler

def setup():
    dist.init_process_group(backend="nccl")
    rank = dist.get_rank()
    world_size = dist.get_world_size()
    local_rank = int(os.environ["LOCAL_RANK"])
    torch.cuda.set_device(local_rank)
    return rank, world_size, local_rank

def main():
    rank, world_size, local_rank = setup()

    model = MyModel().cuda(local_rank)
    model = DDP(model, device_ids=[local_rank])

    dataset = MyDataset(...)
    sampler = DistributedSampler(dataset, num_replicas=world_size, rank=rank)
    dataloader = DataLoader(dataset, sampler=sampler, batch_size=32)

    for epoch in range(num_epochs):
        sampler.set_epoch(epoch)  # シャッフルに必須
        for batch in dataloader:
            ...

    dist.destroy_process_group()

7.2 DeepSpeed（マルチノード）

#!/bin/bash
#SBATCH --job-name=deepspeed-train
#SBATCH --partition=gpu
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=1
#SBATCH --gres=gpu:8
#SBATCH --cpus-per-task=64
#SBATCH --mem=0
#SBATCH --exclusive
#SBATCH --time=96:00:00

export MASTER_ADDR=$(scontrol show hostnames $SLURM_JOB_NODELIST | head -n 1)
export MASTER_PORT=$(( RANDOM % (50000 - 30000 + 1) + 30000 ))
export NNODES=$SLURM_NNODES
export NUM_PROCESSES=$(( NNODES * 8 ))

srun bash -c 'accelerate launch \
    --main_process_ip $MASTER_ADDR \
    --main_process_port $MASTER_PORT \
    --machine_rank $SLURM_NODEID \
    --num_processes $NUM_PROCESSES \
    --num_machines $NNODES \
    --use_deepspeed \
    --zero_stage 2 \
    --mixed_precision fp16 \
    train.py \
        --model_name_or_path meta-llama/Llama-2-7b \
        --per_device_train_batch_size 4 \
        --gradient_accumulation_steps 8'

7.3 Horovod（MPI ベース）

#!/bin/bash
#SBATCH --job-name=horovod-train
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=4
#SBATCH --gres=gpu:4

module load openmpi/4.1.5 cuda/12.2
srun --mpi=pmix python train_horovod.py --epochs 100 --batch-size 64

8. コンテナ統合

8.1 Singularity / Apptainer

#!/bin/bash
#SBATCH --job-name=container_job
#SBATCH --gres=gpu:1
#SBATCH --time=04:00:00

# --nv フラグで GPU サポート
srun singularity exec --nv \
    --bind /scratch/$USER:/data \
    --bind /shared/datasets:/datasets \
    /shared/containers/pytorch_24.03.sif \
    python train.py --data /datasets/imagenet

8.2 Enroot + Pyxis（NVIDIA）

Enroot は NVIDIA の軽量コンテナランタイムであり、Pyxis は Slurm の SPANK プラグインとして srun --container-* フラグを提供する。

#!/bin/bash
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --gres=gpu:8
#SBATCH --exclusive

srun --container-image=nvcr.io/nvidia/pytorch:24.03-py3 \
     --container-mounts=/shared/data:/data,/scratch/$USER:/workspace \
     --container-workdir=/workspace \
     torchrun \
         --nnodes=$SLURM_NNODES \
         --nproc_per_node=8 \
         --rdzv_backend=c10d \
         --rdzv_endpoint=$(scontrol show hostnames $SLURM_JOB_NODELIST | head -n 1):29500 \
         train.py --data /data

NVIDIA DGX SuperPOD および DGX Cloud で広く利用されている。

9. 設定（slurm.conf）

9.1 主要設定パラメータ

# クラスター識別
ClusterName=my_cluster
SlurmctldHost=controller01
SlurmctldHost=controller02     # バックアップコントローラー

# 認証
AuthType=auth/munge

# スケジューリング
SchedulerType=sched/backfill
SelectType=select/cons_tres     # 追跡可能な消費型リソース
SelectTypeParameters=CR_Core_Memory
PriorityType=priority/multifactor
PriorityWeightAge=1000
PriorityWeightFairshare=10000
PriorityWeightJobSize=500
PriorityWeightQOS=2000
PriorityDecayHalfLife=7-0       # 7日間

# リソース管理
ProctrackType=proctrack/cgroup
TaskPlugin=task/cgroup,task/affinity
GresTypes=gpu,mps,shard

# アカウンティング
AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageTres=gres/gpu

# ジョブのデフォルト値
DefMemPerCPU=4096               # 4GB
MaxMemPerCPU=16384              # 16GB
DisableRootJobs=YES
MpiDefault=pmix_v4

# ノード定義
NodeName=compute[001-100] CPUs=64 RealMemory=256000 State=UNKNOWN
NodeName=gpu[001-032] CPUs=128 RealMemory=1024000 Gres=gpu:a100:8 Feature=a100,nvlink

# パーティション定義
PartitionName=compute Nodes=compute[001-100] Default=YES MaxTime=7-00:00:00
PartitionName=gpu Nodes=gpu[001-032] MaxTime=3-00:00:00 AllowGroups=gpu-users
PartitionName=debug Nodes=compute[001-004],gpu[001-002] MaxTime=01:00:00 PriorityTier=100

9.2 cgroup.conf

ConstrainCores=yes          # CPU コアピニング
ConstrainRAMSpace=yes       # メモリ上限を強制
AllowedRAMSpace=100         # 割り当てメモリの %（超過時は OOM Kill）
ConstrainSwapSpace=yes
ConstrainDevices=yes        # デバイス隔離（GPU）

10. 高度な機能

10.1 Backfill スケジューリング

Slurm の補助スケジューリングループ。短い低優先度ジョブが長い高優先度ジョブの開始を遅延させない限り、先に実行されることを許可する。

SchedulerType=sched/backfill
SchedulerParameters=bf_interval=30,bf_resolution=300,bf_max_job_test=1200

効果的に機能させるには、ジョブの制限時間（--time）の指定が必須である。

10.2 Preemption（プリエンプション）

# slurm.conf
PreemptType=preempt/qos
PreemptMode=REQUEUE              # CANCEL, REQUEUE, SUSPEND, GANG
PreemptExemptTime=00:05:00       # プリエンプション前の猶予時間
モード動作
CANCEL低優先度ジョブを終了
REQUEUE可能であれば再キュー、不可であれば取り消し
SUSPENDジョブを一時停止
GANGタイムシェアリング

10.3 Job Array の大規模投入

# 1000タスク、最大50同時実行
sbatch --array=0-999%50 sweep.sh

# 環境変数: SLURM_ARRAY_JOB_ID, SLURM_ARRAY_TASK_ID
# MaxArraySize: 最大 4,000,001（設定可能）

11. モニタリングとトラブルシューティング

11.1 診断コマンド

scontrol ping           # コントローラーへの接続テスト
sdiag                   # スケジューラー診断（スレッド、キュー、バックフィルサイクル）
scontrol show node X    # ノード状態の確認
sacct -j ID --format=JobID,Elapsed,TotalCPU,ReqMem,MaxRSS,State  # ジョブ効率

11.2 よくある問題と解決策

問題診断解決策
ノードが DRAINscontrol show node問題修正後に scontrol update NodeName=X State=RESUME
ジョブが PENDINGsqueue -j ID -o "%R"（Reason 確認）リソース、パーティション上限、QoS、依存関係を確認
GPU 未検出slurmd -C、slurmd -Gドライバー、gres.conf の AutoDetect、デバイスファイルを確認
OOM Killsacct --format=MaxRSS,ReqMemより多くのメモリを要求するか、cgroup 上限を調整
slurmctld 過負荷sdiag（スレッド数）RPC レート制限、ポーリング頻度の削減

11.3 よくある PENDING 理由

理由意味
Resourcesリソース待ち
Priorityより高い優先度のジョブが先にある
Dependency依存ジョブの完了待ち
QOSMaxJobsPerUserLimitQoS のジョブ数上限に到達
PartitionTimeLimit要求時間がパーティション上限を超過
ReqNodeNotAvail要求したノードが利用不可

12. 他のスケジューラーとの比較

特性SlurmPBS Pro / TorqueIBM LSFKubernetes
ライセンスGPL v2（オープンソース）AGPL / 商用商用（IBM）Apache 2.0
主な用途HPC、AI 学習HPC、従来型バッチエンタープライズ HPCクラウドマイクロサービス
スケーラビリティ100K+ ノード50K+100K+5K+
GPU サポートネイティブ GRES、MIG、MPSフックベースGPU-awareDevice Plugin
MPI サポートネイティブ（PMIx）ネイティブネイティブMPI Operator
Fairshare内蔵Maui/Moab が必要内蔵非搭載
TOP500 採用率約 60〜65%約 10〜15%約 10〜15%まれ

トレンド：Slurm（学習）+ Kubernetes（推論／サービング）のハイブリッド構成が主流

13. References

公式ドキュメント

  1. Slurm 公式ドキュメント — 全機能の基準リファレンス
  2. Quick Start User Guide
  3. Quick Start Admin Guide
  4. Slurm GRES Scheduling
  5. Slurm Job Array
  6. Slurm Containers Guide
  7. Slurm Configuration Tool — Web ベースの slurm.conf 生成ツール
  8. Slurm Rosetta Stone (PDF) — PBS/LSF/SGE コマンド対照表
  9. GitHub: SchedMD/slurm

AI/ML 分散学習

  1. PyTorch DDP Multi-Node Slurm Examples
  2. PyTorch Multi-Node Training Tutorial
  3. NVIDIA DGX Cloud DeepSpeed Examples
  4. Multi-Node Training on Slurm (GitHub Gist)

コンテナ

  1. NVIDIA Pyxis GitHub
  2. AWS ParallelCluster Pyxis Tutorial

チュートリアル

  1. LLNL Slurm Quick Start Guide
  2. Princeton Slurm Resources
  3. NERSC Training Libraries Documentation
  4. Nebius Slurm Blog
  5. NVIDIA Acquires SchedMD
Discuss on Twitter • View on GitHub