COLUMN

1. AWS GPUインスタンスファミリー

1-1. GファミリーとPファミリー

AWSのGPUインスタンスは、大きく2つの系統に分かれています。まずはこの全体像をつかむことが、最適なインスタンス選びへの第一歩だと思います。

• Gファミリー (Graphics/Inference):
  グラフィックス処理や推論（Inference）に最適化。低レイテンシーとコスト効率を両立し、ストリーミングや仮想デスクトップ利用に向いています。
• Pファミリー (Parallel/Processing):
  機械学習、大規模推論、科学シミュレーションなどの膨大な計算を要するHPC（High Performance Computing）に特化したインスタンスシリーズです。

本コラムでは、2025年6月時点で利用可能な主要インスタンスを対象に、その特徴を掘り下げていきます。

1-2. Gファミリーの概要

Gファミリーは、グラフィック処理、軽量な機械学習向けに設計されたGPUインスタンスシリーズです。NVIDIA GRIDなどの仮想化技術をサポートしており、仮想デスクトップ利用にも最適です。基本的にPファミリーよりも低コストで利用することができます。

1-3. Pファミリーの概要

Pファミリーは、大規模な機械学習のトレーニングや科学技術計算といった、計算集約型のワークロード向けに設計された最高性能のGPUインスタンスシリーズです。EFA (Elastic Fabric Adapter) などの高速ネットワーク技術により、大規模な分散学習にも最適です。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

2. g4dn.xlargeを構築し、ベンチマークを実行する

実際に、GPUインスタンスを立ち上げてみましょう。本コラムでは、最も安価な「g4dn.xlarge」をスポットインスタンスとして起動し、PyTorch（GPU対応のAI開発フレームワーク）が使用できる環境を整えます。

2-1. 前提条件

ハンズオンを進めるには、以下の準備が完了している必要があります。

• AWSアカウントが作成済みであること
• AWS CLIがセットアップ済みであること
• インスタンス接続用のEC2キーペアが作成済みであること
• SSH接続を許可するセキュリティグループが作成済みであること
• AMI: Deep Learning AMI GPU PyTorch 2.1.0 (Ubuntu 20.04)（NVIDIAドライバ、CUDA、PyTorchなどがプリインストールされており、環境構築の手間が省けます。）

2-2. g4dn.xlargeをスポットインスタンスとして構築

2-2-1. EC2 スポットインスタンスを構築

1.1. AWS CLIに接続し、コマンドを実行します。

# コマンド実行後に出力される "InstanceId" を控えておいてください。
#--instance-market-options: スポットインスタンスを指定します。
#--block-device-mappings: ルートボリュームを100GBのgp3タイプに設定します。
aws ec2 run-instances ¥
  --image-id ami-0d527b8c289b4af7f ¥
  --instance-type g4dn.xlarge ¥
  --key-name your-key-pair-name ¥
  --security-group-ids sg-1234567890abcdef ¥
  --instance-market-options 'MarketType=spot' ¥
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]'

2-2-2. 起動したインスタンスにSSHで接続

2.1. マネジメントコンソールより構築したEC2インスタンスのパブリックIPを確認し、コマンドを実行します。

# path/to/your-key-pair-name.pem:EC2キーペアを指定してください。
# $PUBLIC_IP:パブリックIPを指定してください
ssh -i path/to/your-key-pair-name.pem ubuntu@$PUBLIC_IP

2.2. 接続後、コマンドを実行し、NVIDIAドライバとGPUの状態を確認します。

nvidia-smi

2.3. 以下のようにNVIDIA T4とGPUメモリ15360MiBが表示されれば正常に認識されています。

2-3. PyTorchの動作確認と推論速度のベンチマークテスト

2-3-1. PyTorchがGPUを使える状態になっていることを確認

1.1. コマンドを実行し、PyTorchをアクティベートします。

source activate pytorch

1.2. プロンプトの先頭に(pytorch)と表示されている状態で、[python3]と入力してPythonモードを開始します。

1.3. コマンドを実行し、PyTorchがGPUメモリを予約できていることを確認します。

import torch
import torchvision.models as models

# GPUが利用可能か確認
if not torch.cuda.is_available():
    print("Error: CUDA is not available.")
else:
    print(f"CUDA available! Using {torch.cuda.get_device_name(0)}")
    m = models.resnet50(weights=None).cuda().half().eval()
    print(torch.cuda.memory_summary())

1.4. PyTorchがGPUのメモリを利用できていることを確認することでPyTorchの正常性確認が終了します。

2-3-2. g4dnのベンチマークテストを実施

このベンチマークテストでは、32枚のダミー画像データを作成し、それらを用いて100回連続で推論（画像分類）を実行します。その後、推論にかかった時間を計測し、1秒あたりに何枚の画像を処理できるかを計算します。

2.1. テキストエディタを開き、[benchmark.py]ファイルを作成します。

nano benchmark.py

2.2. 開いたエディタ画面に、以下のベンチマークコードを全てコピー&ペーストします。

import torch
import torchvision.models as models
import time

def run_benchmark():
    # 1. モデルの準備
    try:
        model = models.resnet50(weights=None).cuda().half().eval()
        print(f"Model: ResNet50")
    except Exception as e:
        print(f"Error loading model: {e}")
        return

    # 2. ダミーの入力データを作成
    # (バッチサイズ32, 3チャンネル, 224x224ピクセル)
    batch_size = 32
    dummy_input = torch.randn(batch_size, 3, 224, 224, dtype=torch.float16).cuda()
    print(f"Batch size: {batch_size}")
    print("-" * 30)

    # 3. ウォームアップ実行 (最初の数回は準備運動なので計測しない)
    print("Warming up...")
    with torch.no_grad():
        for _ in range(10):
            _ = model(dummy_input)
    
    # GPUの処理が終わるまで待つ
    torch.cuda.synchronize()

    # 4. ベンチマーク計測
    print("Running benchmark...")
    num_iterations = 100
    
    start_time = time.time()
    with torch.no_grad():
        for _ in range(num_iterations):
            _ = model(dummy_input)
    
    # GPUの処理が終わるまで待つ
    torch.cuda.synchronize()
    end_time = time.time()

    # 5. 結果の計算と表示
    total_time = end_time - start_time
    total_images = num_iterations * batch_size
    images_per_sec = total_images / total_time

    print("-" * 30)
    print(f"Total time for {num_iterations} iterations: {total_time:.2f} seconds")
    print(f"Total images processed: {total_images}")
    print(f"Images/sec (Throughput): {images_per_sec:.2f}")
    print("-" * 30)

if __name__ == '__main__':
    if not torch.cuda.is_available():
        print("Error: CUDA is not available. Cannot run benchmark.")
    else:
        print(f"CUDA available! Using {torch.cuda.get_device_name(0)}")
        run_benchmark()

2.3. 保存し、エディタを終了します。

2.4. 以下のコマンドで、作成したベンチマークスクリプトを実行します。

source activate pytorch
python benchmark.py

最後に出力されるImages/sec (Throughput)の数値が大きいほど、推論性能が高いことを意味します。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

3. g5.xlargeにリサイズし、ベンチマークテストの結果を比較する

本コラムでは、AIのモデル学習のような、時間を要する処理を予算を気にせずに実行いただくため、実用的な使用方法としてスポットインスタンスでの構築を前提としています。この場合、リサイズはAMIを利用した再構築によって行います。

念のため、オンデマンドインスタンスで構築した際のリサイズにおける注意点を記載します。

• インスタンス世代の互換性 旧世代のインスタンスから最新のNitro世代のインスタンス（例: t3, m5, g4dn, g5 など）へは、直接リサイズできない場合があります。一般的に、同じ世代、特にNitro世代間のリサイズが最もスムーズです。
• CPUアーキテクチャの互換性 Intel/AMDベース（x86_64）のインスタンスと、AWS Gravitonプロセッサベース（Arm64）のインスタンスの間でリサイズすることはできません。OSやソフトウェアの根本的な互換性がないためです。
• 必要なドライバの有無 古いAMIから作成したインスタンスの場合、リサイズ先の新しいインスタンスが必要とするネットワークドライバ（ENA）やストレージドライバ（NVMe）が含まれていないことがあります。この場合、リサイズ後にネットワークに接続できなくなるなどの問題が発生する可能性があります。

3-1. g5.xlargeのスポットインスタンスを構築

3-1-1. g4dnインスタンスのAMIを作成し、g5.xlargeのスポットインスタンスを構築する

1.1. AWS EC2コンソールで、対象の g4dn.xlarge インスタンスを右クリック（またはチェックボックスを選択して「アクション」メニューへ）します。

1.2. [イメージとテンプレート]→[イメージを作成]を選択します。

1.3. イメージ名に、分かりやすい名前（例: my-g4dn-snapshot）を入力します。

1.4. 他はデフォルトのままで、画面右下の「イメージを作成」ボタンをクリックします。

1.5. AMIのステータスが[利用可能]になったことを確認し、AWS CLIで下記コマンドを入力し、g4dnインスタンスを終了します。

aws ec2 terminate-instances --instance-ids [元のg4dnのInstanceId]

1.6. コンソールの「AMI」画面で、作成したカスタムAMI (my-g4dn-snapshot) を選択し、そのAMI ID (ami-xxxxxxxxxxxxxxxxx) をコピーします。

1.7. 以下のコマンドの --image-id を、コピーしたカスタムAMIのIDに書き換えて実行します。

aws ec2 run-instances ¥
  --image-id ami-xxxxxxxxxxxxxxxxx ¥
  --instance-type g5.xlarge ¥
  --key-name your-key-pair-name ¥
  --security-group-ids sg-1234567890abcdef ¥
  --instance-market-options 'MarketType=spot' ¥
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]'

3-1-2. g5.xlargeインスタンスのベンチマークテストを実施する

2.1. g4dn.xlargeのベンチマークテストで作成したファイルを実行する

本コラムの手順通り、AMIから作成した場合はそのまま利用できます。

source activate pytorch
python benchmark.py

2.2. ベンチマークテストの結果を確認する

3-2. ベンチマーク結果を比較

比較結果を表に記載します。若干ではありますが、g5.xlargeインスタンスの方がコストパフォーマンスが高いことがわかります。

公式ドキュメントなどにも記載されている通り、処理時間が長くなるにつれて、より高性能なインスタンスを選択することがコスト最適化につながることが実測値からも明らかになりました。

小規模な処理には、起動時間に対する処理時間の割合が少ないため、g4dn.xlargeのようなエントリーモデルが適していると考えられます。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

4. まとめ

本コラムでは、AWSが提供するGファミリーとPファミリーという2大GPUインスタンス系統の違いを整理し、実際にエントリーモデルであるg4dn.xlargeの構築手順を案内しました。

Gファミリーは推論、Pファミリーは大規模学習という大まかな指針を理解することで、プロジェクトの要件に合わせた適切なインスタンス選定が可能になると思います。

また、ベンチマークテストでg4dn.xlargeとg5.xlargeの性能を比較したところ、高性能なインスタンスを選択することで、結果的に総コストを削減できる可能性が示されました。したがって、処理するワークロードの量に基づいたインスタンス選定がとても重要です。

今回の内容が、皆さまのプロジェクトに最適なGPUインスタンスを選定する上での一助となれば幸いです。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。