0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ysit

SageMaker HyperPod × H100×32基でLLM学習を回して得た実践

0
Posted at

はじめに

本記事では、Amazon SageMaker HyperPodでp5.48xlarge × 4ノード（H100×8/ノード = 合計32GPU）を使い、LLMの事前学習およびファインチューニングを実施した際に得られた実践的な知見をまとめます。

対象読者

  • HyperPodの導入を検討中、または導入初期のMLエンジニア
  • マルチノードGPUクラスタでの分散学習に関心がある方
  • SageMaker Training Jobsからのステップアップを考えている方

なぜHyperPodを選んだか

SageMaker Training Jobsでは、ジョブ単位でクラスタが起動・破棄されるため、長時間の事前学習では障害時にゼロからやり直しになるリスクがあります。HyperPodは永続クラスタとしてGPUノードを維持しつつ、自動障害検知・ノード交換・ジョブ再開の仕組みを提供してくれるため、数日〜数週間にわたる大規模学習に適しています。

今回は以下の2つのワークロードを同一クラスタで実施しました。

  1. 事前学習（Pre-training）: 70Bパラメータ規模のモデルを独自コーパスでスクラッチ学習
  2. ファインチューニング（SFT + DPO）: 事前学習済みモデルに対するInstruction Tuning

構成概要

項目 値
オーケストレーター Slurm
コントローラーノード ml.m5.xlarge × 1
ワーカーノード ml.p5.48xlarge × 4
GPU/ノード NVIDIA H100 80GB × 8
合計GPU数 32基
ノード間通信 EFA（3,200 Gbps）
ストレージ FSx for Lustre

クラスタ構成とアーキテクチャ

全体アーキテクチャ

インスタンスグループ設計

HyperPodではインスタンスグループ単位でノードを管理します。最小構成として、コントローラーグループとコンピュートグループの2つを定義しました。

create_cluster.json の構成ポイント:

{
  "ClusterName": "hyperpod-llm-training",
  "InstanceGroups": [
    {
      "InstanceGroupName": "controller-group",
      "InstanceType": "ml.m5.xlarge",
      "InstanceCount": 1,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://my-hyperpod-config/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::123456789012:role/HyperPodExecutionRole",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group",
      "InstanceType": "ml.p5.48xlarge",
      "InstanceCount": 4,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://my-hyperpod-config/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::123456789012:role/HyperPodExecutionRole",
      "ThreadsPerCore": 1
    }
  ],
  "VpcConfig": {
    "SecurityGroupIds": ["sg-xxxxxxxxxxxxxxxxx"],
    "Subnets": ["subnet-xxxxxxxxxxxxxxxxx"]
  }
}

provisioning_parameters.json のポイント:

{
  "version": "1.0.0",
  "workload_manager": "slurm",
  "controller_group": "controller-group",
  "worker_groups": [
    {
      "instance_group_name": "worker-group",
      "partition_name": "gpu"
    }
  ],
  "fsx_dns_name": "fs-xxxxxxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com",
  "fsx_mountname": "xxxxxxxx"
}

fsx_dns_name と fsx_mountname はFSx for Lustreのコンソールから確認できます。ここを間違えるとライフサイクルスクリプトがマウントに失敗し、クラスタ作成がタイムアウトします。

ライフサイクルスクリプトのカスタマイズ

AWSが提供する awsome-distributed-training リポジトリのサンプルスクリプトをベースにカスタマイズしました。

on_create.sh で行った主な追加処理:

#!/bin/bash
set -ex

# ベースのセットアップスクリプト実行
bash /opt/ml/scripts/setup_base.sh

# カスタムパッケージのインストール
pip install torch==2.2.0 --index-url https://download.pytorch.org/whl/cu121
pip install deepspeed==0.14.0
pip install flash-attn==2.5.6 --no-build-isolation

# Conda環境の構築（全ノード共通）
if [ -f /fsx/envs/setup_conda.sh ]; then
    bash /fsx/envs/setup_conda.sh
fi

# NCCL設定の永続化
cat >> /etc/environment << 'EOF'
NCCL_PROTO=Simple
NCCL_ALGO=Ring,Tree
FI_PROVIDER=efa
FI_EFA_USE_DEVICE_RDMA=1
NCCL_SOCKET_IFNAME=en
EOF

echo "Lifecycle script completed successfully"

ライフサイクルスクリプトは全ノードで実行されます。コントローラーノードとワーカーノードで処理を分けたい場合は、スクリプト内でインスタンスグループ名を判定するロジックを入れてください。

FSx for Lustreの設計

FSx for Lustreはクラスタの共有ストレージとして使用します。学習データ、チェックポイント、ログ出力すべてをFSx上に配置することで、全ノードから同一パスでアクセスできます。

用途 パス 推奨設定
学習データ /fsx/data/ S3連携（自動インポート）
チェックポイント /fsx/checkpoints/ 高スループット設定
コード・設定 /fsx/code/ -
Conda環境 /fsx/envs/ -
ログ出力 /fsx/logs/ -

今回は PERSISTENT_2 デプロイメントタイプ、ストレージ容量 4.8 TiB、スループット 1000 MB/s/TiB で構成しました。チェックポイントの書き込みがボトルネックにならないよう、スループットは余裕を持たせています。

分散学習の最適化

FSDP vs DeepSpeed ZeROの選択

4ノード32GPUの環境で事前学習とファインチューニングの両方を試した結果、以下の使い分けに落ち着きました。

項目 事前学習（70B） ファインチューニング（SFT/DPO）
採用手法 FSDP (Full Shard) DeepSpeed ZeRO Stage 3
理由 PyTorch nativeで安定、HyperPodとの親和性が高い QLoRA等と組み合わせやすく、メモリ効率が良い
Mixed Precision BF16 BF16
Gradient Checkpointing 有効 有効

選択のポイント:

  • FSDP: PyTorchに統合されておりバージョン管理がシンプル。torch.distributed の一部なのでHyperPodのSlurmジョブとの連携がスムーズ。事前学習のような長時間ジョブでは安定性を最優先
  • DeepSpeed ZeRO: Offload機能やQLoRAとの組み合わせなど柔軟性が高い。ファインチューニングでは学習時間が比較的短いため、多少の設定の複雑さは許容できる

NCCL環境変数チューニング

マルチノード分散学習ではNCCLの設定が性能を大きく左右します。p5.48xlargeのEFA環境で効果があった設定をまとめます。

# EFA（Elastic Fabric Adapter）の有効化
export FI_PROVIDER=efa
export FI_EFA_USE_DEVICE_RDMA=1

# NCCLプロトコル・アルゴリズム
export NCCL_PROTO=Simple
export NCCL_ALGO=Ring,Tree

# ネットワークインターフェース指定
export NCCL_SOCKET_IFNAME=en

# デバッグ（問題切り分け時のみINFOに）
export NCCL_DEBUG=WARN
# export NCCL_DEBUG=INFO  # トラブルシュート時

# タイムアウト設定（マルチノードではデフォルト値では短い場合がある）
export NCCL_TIMEOUT=1800000  # 30分（ミリ秒）

NCCL_DEBUG=INFO は詳細なログが大量に出力されるため、常時有効にしないでください。問題切り分け時のみ使用し、通常運用では WARN に設定します。INFO のままジョブを実行すると、ログ出力自体がボトルネックになり学習速度が低下するケースがあります。

EFA 3,200 Gbpsを活かすネットワーク設定

p5.48xlargeは32基のEFAデバイスを搭載し、合計3,200 Gbpsのネットワーク帯域を提供します。この帯域を最大限活用するために以下を確認します。

  1. セキュリティグループ: 同一セキュリティグループ内の全トラフィックを許可（IngressにSelf参照ルールを追加）
  2. サブネット: 全ノードが同一AZ・同一サブネットに配置されていること
  3. Placement Group: HyperPodではクラスタプレイスメントグループが自動的に設定される
# EFAの動作確認コマンド
fi_info -p efa
# "provider: efa" が表示されればOK

# NCCLテストでノード間帯域を計測
# (NCCL Testsを事前にビルドしておく)
srun --nodes=2 --ntasks-per-node=8 --gpus-per-node=8 \
  /fsx/nccl-tests/build/all_reduce_perf \
  -b 8 -e 8G -f 2 -g 1

Slurmジョブスクリプトの実践例

事前学習ジョブ（FSDP）

#!/bin/bash
#SBATCH --job-name=pretrain-70b
#SBATCH --partition=gpu
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --gpus-per-node=8
#SBATCH --cpus-per-task=12
#SBATCH --exclusive
#SBATCH --output=/fsx/logs/pretrain-%j.out
#SBATCH --error=/fsx/logs/pretrain-%j.err
#SBATCH --export=ALL

# ノード一覧の取得
export MASTER_ADDR=$(scontrol show hostname $SLURM_NODELIST | head -n 1)
export MASTER_PORT=29500

# NCCL環境変数
export FI_PROVIDER=efa
export FI_EFA_USE_DEVICE_RDMA=1
export NCCL_PROTO=Simple
export NCCL_ALGO=Ring,Tree
export NCCL_SOCKET_IFNAME=en
export NCCL_DEBUG=WARN

# torchrunによる分散起動
srun torchrun \
  --nnodes=$SLURM_NNODES \
  --nproc_per_node=8 \
  --rdzv_id=$SLURM_JOB_ID \
  --rdzv_backend=c10d \
  --rdzv_endpoint=$MASTER_ADDR:$MASTER_PORT \
  /fsx/code/train.py \
    --model_config /fsx/code/configs/model_70b.yaml \
    --data_path /fsx/data/corpus/ \
    --output_dir /fsx/checkpoints/pretrain-70b/ \
    --fsdp_config /fsx/code/configs/fsdp.yaml \
    --bf16 \
    --gradient_checkpointing \
    --per_device_train_batch_size 2 \
    --gradient_accumulation_steps 4 \
    --save_steps 500 \
    --logging_steps 10

srun + torchrun の組み合わせでは、srun がノード単位のプロセス起動を管理し、torchrun が各ノード内のGPUプロセスを管理します。--ntasks-per-node=8 は torchrun の --nproc_per_node=8 と整合させてください。

ファインチューニングジョブ（DeepSpeed）

#!/bin/bash
#SBATCH --job-name=sft-70b
#SBATCH --partition=gpu
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=1
#SBATCH --gpus-per-node=8
#SBATCH --cpus-per-task=96
#SBATCH --exclusive
#SBATCH --output=/fsx/logs/sft-%j.out
#SBATCH --error=/fsx/logs/sft-%j.err
#SBATCH --export=ALL

export MASTER_ADDR=$(scontrol show hostname $SLURM_NODELIST | head -n 1)
export MASTER_PORT=29500

# NCCL環境変数（省略: 上記と同じ）
export FI_PROVIDER=efa
export FI_EFA_USE_DEVICE_RDMA=1
export NCCL_PROTO=Simple
export NCCL_SOCKET_IFNAME=en
export NCCL_DEBUG=WARN

srun bash -c ' \
  deepspeed \
    --num_gpus=8 \
    --num_nodes=$SLURM_NNODES \
    --master_addr=$MASTER_ADDR \
    --master_port=$MASTER_PORT \
    --hostfile="" \
    /fsx/code/sft_train.py \
      --deepspeed /fsx/code/configs/ds_z3_config.json \
      --model_name_or_path /fsx/checkpoints/pretrain-70b/final/ \
      --data_path /fsx/data/sft/ \
      --output_dir /fsx/checkpoints/sft-70b/ \
      --bf16 \
      --gradient_checkpointing \
      --per_device_train_batch_size 1 \
      --gradient_accumulation_steps 8 \
      --save_steps 200 \
      --logging_steps 5
'

Mixed Precision（BF16）とGradient Checkpointing

BF16（Brain Floating Point 16） はH100でネイティブサポートされており、FP16と比較してダイナミックレンジが広いため、Loss Scalingが不要です。事前学習・ファインチューニングいずれもBF16を使用しました。

Gradient Checkpointing は、フォワードパス時に中間活性値を保持せず、バックワードパス時に再計算することでGPUメモリを節約する手法です。70Bモデルを40GPUで学習する際には必須でした。

# FSDP設定例（fsdp.yaml）
fsdp:
  sharding_strategy: FULL_SHARD
  auto_wrap_policy: TRANSFORMER_BASED_WRAP
  backward_prefetch: BACKWARD_PRE
  mixed_precision:
    param_dtype: bfloat16
    reduce_dtype: bfloat16
    buffer_dtype: bfloat16
  activation_checkpointing: true
  limit_all_gathers: true

耐障害性とオートリジューム

HyperPodのヘルスモニタリング

HyperPodは各ノードでヘルスモニタリングエージェントが稼働しており、以下の障害を自動検知します。

  • GPU障害: ECC（Error Correcting Code）エラー、GPU応答なし
  • NVLink/NVSwitchエラー: ノード内GPU間通信の異常
  • EFA障害: ノード間通信の異常
  • ストレージ障害: FSxマウントの異常

自動ノード復旧のフロー

HyperPodの自動ノード復旧（Auto Resume）は以下の流れで動作します。

auto-resumeを有効にするには、Slurmジョブスクリプトに以下のコメントを追加します:

#SBATCH --comment='{"auto_resume": true}'

auto-resumeが正しく動作するためには、学習スクリプト側でチェックポイントからの再開ロジックを実装しておく必要があります。HyperPodはジョブを再投入するだけなので、スクリプトが --resume_from_checkpoint latest のような引数を正しく処理できることが前提です。

チェックポイント戦略

チェックポイントの保存間隔は、復旧コスト（やり直しの計算時間） と チェックポイント保存コスト（I/O時間・ストレージ容量） のトレードオフで決定します。

今回の設計指針:

項目 事前学習 ファインチューニング
保存間隔 500ステップごと 200ステップごと
保持世代数 最新3世代 最新5世代
1チェックポイントのサイズ 約260GB（70B, BF16, FSDP Full Shard） 約50GB（LoRAアダプタ + Optimizer State）
保存先 /fsx/checkpoints/ /fsx/checkpoints/ 
# チェックポイント保存の実装例（PyTorch FSDP）
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP
from torch.distributed.fsdp import StateDictType

def save_checkpoint(model, optimizer, scheduler, step, path):
    """FSx for Lustreにチェックポイントを保存"""
    save_dir = f"{path}/step_{step}"
    os.makedirs(save_dir, exist_ok=True)

    # FSDP: フルステートディクトとして保存
    with FSDP.state_dict_type(
        model,
        StateDictType.FULL_STATE_DICT
    ):
        state = {
            "model": model.state_dict(),
            "optimizer": optimizer.state_dict(),
            "scheduler": scheduler.state_dict(),
            "step": step,
        }
        # Rank 0のみ保存
        if dist.get_rank() == 0:
            torch.save(state, f"{save_dir}/checkpoint.pt")

    dist.barrier()

    # 古い世代の削除（最新3世代のみ保持）
    if dist.get_rank() == 0:
        cleanup_old_checkpoints(path, keep=3)

FSDP Sharded State Dictを使うと各ランクが分割されたステートのみを保存するため、保存時のメモリ使用量と保存時間を削減できます。ただし、ノード構成が変わった場合のリストアが複雑になるため、auto-resume用途では Full State Dict の方が安全です。

CloudWatchでの障害監視

HyperPodのログは CloudWatch Logs の /aws/sagemaker/Clusters/<cluster-name> ロググループに自動送信されます。

監視すべき主要なログストリーム:

ログストリーム 内容
LifecycleConfig/<instance-id> ライフサイクルスクリプトの実行ログ
HealthMonitoring/<instance-id> ヘルスチェックの結果
Slurm/slurmctld Slurmコントローラーのログ

CloudWatch Alarmの推奨設定:

メトリクス: ログフィルターパターン "ERROR" or "FATAL" or "gpu_health_check: FAIL"
条件: 1回以上検出 / 5分間
アクション: SNSトピック → Slack通知

コスト最適化

p5.48xlarge の料金概算

p5.48xlargeのオンデマンド料金（2026年3月時点、東京リージョン概算）:

項目 金額
p5.48xlarge 単価 約 $68.80/時間
4ノード/時間 約 $275.20/時間

HyperPodクラスタは永続的に動作するため、クラスタを停止しない限り課金が継続します。学習が完了したらクラスタを削除（または不要なインスタンスグループを縮小）するワークフローを必ず組み込んでください。

Flexible Training Plans（キャパシティ予約）

p5インスタンスはオンデマンドでの確保が難しい場合があります。Flexible Training Plans（旧Capacity Reservations for ML）を活用することで、以下のメリットが得られます。

  • 確実なキャパシティ確保: 指定期間中のGPUインスタンスを予約
  • 割引料金: オンデマンドと比較して最大40%程度のコスト削減
  • SageMaker統合: HyperPodクラスタ作成時に直接紐付け可能
# Flexible Training Planの作成例（AWS CLI）
aws sagemaker create-training-plan \
  --training-plan-name "hyperpod-h100-4nodes" \
  --training-plan-offering-id "trn-offering-xxxxxxxx" \
  --target-resources '[
    {
      "InstanceType": "ml.p5.48xlarge",
      "InstanceCount": 4
    }
  ]'

クラスタスケーリング戦略

学習が走っていない時間帯のコストを削減するために、以下の戦略を採用を検討してください。

  1. ワーカーノード数の動的変更: UpdateCluster APIでワーカーノード数を減らす（ただしノード削除→再追加にはライフサイクルスクリプトの再実行が必要）
  2. 開発/テストとプロダクション学習の時間帯分離: 日中は1〜2ノードでの開発・デバッグ、夜間・週末にフルノードで本番学習
  3. 不要時のクラスタ削除: 長期間使わない場合はクラスタごと削除し、再作成のスクリプトを整備

実際に効果があった施策:

  • バッチサイズの最適化: Gradient Accumulation Stepsを調整してGPU利用率を90%以上に維持
  • データローダーの最適化: num_workers の調整とデータのプリフェッチにより、GPU待ち時間を削減
  • 学習ジョブの即時投入: 前のジョブ完了後に自動的に次のジョブが投入されるようSlurmジョブチェーンを構成

ハマりどころと実践Tips

ここからが本記事の核心です。5ノード規模のHyperPodクラスタを運用する中で遭遇した問題と対処法をまとめます。

1. EFAが有効にならないケース

問題: fi_info -p efa でEFAプロバイダーが表示されない、または NCCLテストで期待する帯域が出ない。

切り分け手順:

# 1. EFAデバイスの確認
lspci | grep -i efa
# → EFAデバイスが表示されない場合、インスタンスタイプまたはAMIの問題

# 2. EFAドライバの確認
modinfo efa
# → ドライバがロードされていなければ再インストール

# 3. セキュリティグループの確認
#    → 自身のセキュリティグループからの全インバウンドトラフィックを許可しているか

# 4. libfabricのバージョン確認
fi_info --version
# → HyperPod AMIにバンドルされたバージョンが古い場合がある

# 5. NCCL Testsでの帯域計測
srun --nodes=2 --ntasks-per-node=8 --gpus-per-node=8 \
  /fsx/nccl-tests/build/all_reduce_perf -b 1G -e 4G -f 2 -g 1
# → p5.48xlarge 2ノード間で bus bandwidth 100+ GB/s が目安

2. NCCLタイムアウトの原因パターンと対処法

NCCLタイムアウト（NCCL WARN Timeout）は最も頻繁に遭遇するエラーの一つです。

パターン 原因 対処
ジョブ開始直後にタイムアウト ランデブーエンドポイントへの接続失敗 MASTER_ADDR の解決確認、ポート開放確認
学習途中でランダムに発生 一部ノードのGPU/EFA障害 ヘルスモニタリングログ確認、NCCLデバッグ有効化
特定ステップで毎回発生 OOM（Out of Memory）で一部ランクがクラッシュ バッチサイズ削減、Gradient Checkpointing確認
チェックポイント保存後に発生 FSx I/Oの遅延でランク間の同期がずれる dist.barrier() の配置見直し、タイムアウト値の延長 
# タイムアウト値の延長（デフォルト30分→60分）
import torch.distributed as dist
import datetime

dist.init_process_group(
    backend="nccl",
    timeout=datetime.timedelta(minutes=60)
)

3. FSx for Lustreのスループットボトルネック

問題: 多数のGPUから同時にデータを読み込むと、FSxのスループットが飽和して学習速度が低下する。

対処法:

# ボトルネックの確認
lctl get_param llite.*.stats  # Lustreクライアント統計

# 対策
1. FSxのスループット設定を引き上げる（1000 MB/s/TiB 以上推奨）
2. データローダーでプリフェッチを有効化（num_workers=4〜8）
3. 学習データをシャード化し、各ノードが異なるシャードを読むように設計
4. チェックポイント保存を非同期化（別スレッドで書き込み）
5. 小さなファイルが大量にある場合は tar アーカイブにまとめてシーケンシャルリードに最適化

4. コンテナ利用時（Enroot/Pyxis）のGPUデバイスマッピング

HyperPodのSlurm環境では、Enroot（コンテナランタイム）とPyxis（Slurmプラグイン）を使ってコンテナ内で学習を実行できます。

問題: コンテナ内でGPUが正しく認識されない、またはEFAデバイスがマウントされない。

対処法:

#!/bin/bash
#SBATCH --job-name=container-training
#SBATCH --partition=gpu
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --gpus-per-node=8
#SBATCH --container-image=/fsx/containers/pytorch-training.sqsh
#SBATCH --container-mounts=/fsx:/fsx

# Pyxis使用時のポイント:
# 1. --container-mounts で FSx をコンテナ内にマウント
# 2. GPUとEFAデバイスは自動的にマッピングされる（Pyxis + NVIDIA Container Runtime）
# 3. ただし /dev/infiniband がマウントされていることを確認

srun --container-image=/fsx/containers/pytorch-training.sqsh \
     --container-mounts=/fsx:/fsx \
     bash -c '
       # コンテナ内でのデバイス確認
       nvidia-smi  # GPU確認
       fi_info -p efa  # EFA確認

       torchrun --nnodes=$SLURM_NNODES --nproc_per_node=8 \
         --rdzv_id=$SLURM_JOB_ID \
         --rdzv_backend=c10d \
         --rdzv_endpoint=$MASTER_ADDR:$MASTER_PORT \
         /fsx/code/train.py
     '

Tips: コンテナイメージは Enroot形式（.sqsh） に変換しておく必要があります。Docker Hubからの変換例:

enroot import docker://nvcr.io#nvidia/pytorch:24.02-py3
enroot create nvidia+pytorch+24.02-py3.sqsh

まとめ

HyperPodを4ノード規模で運用した所感

SageMaker HyperPodで p5.48xlarge × 4ノード（H100 × 32基）を運用しました。以下が率直な所感です。

メリット:

  • 耐障害性: 運用中にGPU障害が2回発生しましたが、いずれもノード置き換えで学習を継続しました
  • マネージドSlurm: Slurmの構築・運用をAWSが担ってくれるため、インフラ管理の負荷が大幅に軽減されました。slurmctld の冗長化やノードの自動登録などが標準で組み込まれています
  • FSx統合: 共有ストレージとして FSx for Lustre がシームレスに使えるため、データの配置やチェックポイント管理がシンプルになりました

注意点:

  • 初期セットアップの学習コスト: ライフサイクルスクリプト、Slurm設定、NCCL環境変数など、最初の構築には相応の知識と試行錯誤が必要です
  • コスト管理の重要性: 永続クラスタのため、意図しない課金に注意が必要です。運用ルールとアラートの整備が必須です
  • デバッグの難しさ: マルチノード環境での問題切り分けには慣れが必要です。本記事のTipsが参考になれば幸いです

小規模（4ノード）でもHyperPodを使うメリット

「HyperPodは大規模クラスタ向けでは？」と思われるかもしれませんが、4ノード程度でも以下の点でメリットを感じました。

  1. GPU障害への備え: H100は高価であり、障害時の自動復旧は規模に関わらず価値がある
  2. Slurmによるジョブ管理: 事前学習とファインチューニングを同一クラスタで効率的に切り替えられる
  3. 再現性: ライフサイクルスクリプトで環境構築がコード化されるため、クラスタの再現が容易

今後の展望

  • EKSオーケストレーターの検証: Slurmに代わるEKSベースのオーケストレーターが利用可能になっており、Kubernetes運用に慣れたチームにはこちらが適する可能性
  • スケールアップ: 今回の4ノードから10〜20ノード規模へのスケールアップを計画中
  • SageMaker Trainium（trn2）の検討: コスト効率を重視する場合の選択肢として評価予定

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?