AWSのGPUリソースとGPT-OSS構築(AMI化を含める)

Posted at 2025-09-06

0. この記事のゴール
1. EC2 の GPU インスタンス早見表
2. GPU世代と Compute Capability（CC）の超要点
3. 初回で踏んだ落とし穴（ショート版）
4. 実機ログのごく一部（抜粋・短縮）
5. まとめ（前編）
後編：AMI構築 & Ollamaデプロイ（G6/L4 編・手順の完全版）

前編：EC2 GPUインスタンス超入門 & 初回トラブル（ショート）

前編は導入編で、AWSのGPUリソースを紹介し、
後編で「成功した手順（g6/L4 編）」「AMI運用・EBS設計」を詳細公開します。
結論と手順だけ見たい方は、後編へどうぞ。

0. この記事のゴール

どのEC2 GPUを選べば GPT-OSS を安定稼働できるかの勘所を掴む
私が**最初に詰まったポイント（落とし穴）**をショートに把握する
次回の**完全手順（成功例）**を読みやすくするための共通前提を揃える

1. EC2 の GPU インスタンス早見表（用途別の勘所）

ファミリ	搭載GPU	VRAM	向いている用途（私見）	ひとこと
G4dn	NVIDIA T4	16GB	各種モデルの最小検証、軽量推論/画像処理	低コストで「まず動かす」。ただし新しめ最適化は弱め
G5	NVIDIA A10G	24GB	20B級の安定推論・軽微な微調整、余裕ある検証環境	Ampere世代で最適化カーネルの適用範囲が広い
G6	NVIDIA L4	24GB	生成AI推論の省電力/高効率、最近のソフト最適化の恩恵を受けやすい	Ada世代。FA3/FlashInfer 周辺との相性も良好
（参考）G6e	NVIDIA L40S	48GB	画像/動画が重い・大きめKVなど	余裕重視。コストは上がる

料金はリージョン/時期で変動。実使用リージョンの公式価格表で要確認（リンクは末尾）。

2. GPU世代と Compute Capability（CC）の超要点

**T4（G4dn）**は CC=7.5（Turing）
**A10G（G5）**は一般に CC=8.6（Ampere）
**L4（G6）**は CC=8.9（Ada）
この CCの差が、量子化方式（例：MXFP4）や最適化カーネル（例：FlashAttention 3）の対応可否に直結します。
→ T4（7.5）は新しめ機能の要件を満たさないことがあるため、gpt-oss では G5/G6 推奨という結論に落ち着きました。

3. 初回で踏んだ落とし穴（ショート版）

3.1 T4（G4dn）で MXFP4 量子化が通らない

gpt-oss 構成では MXFP4 が最小 CC>=8.0 以上を要求する場面があり、T4（CC 7.5）では起動時にエラー。
例）The quantization method mxfp4 is not supported for the current GPU. Minimum capability: 80. Current capability: 75.
⇒ G4dn → G5/G6 に切替が最速ルート。

3.2 L4（G6）で “Sinks are only supported in FlashAttention 3”

gpt-oss 起動時、Attention Sink 機構を使う経路で FA3（FlashAttention 3）前提のアサートに詰まる事例。
- vLLM 0.10.1+gptoss 周辺は FA3/FlashInfer/トリトンのバージョン整合がポイント。
- backend/環境変数の指定（FA3 or FlashInfer）と CUDA 12.8+ 系の整合を見直して解消。

ストレージ不足

当初の見積もりが甘く、50GB しか確保していない状態でした。検証用途でも余裕を持たせるのが無難です。目安としては モデル用に最低 20GB、環境構築用に 30GB、さらにキャッシュや一時ファイルの余裕を見込み、合計 100GB 以上を推奨します。

4. 実機ログのごく一部（抜粋・短縮）

（※詳細な「成功手順」は次回。ここでは失敗の気配が分かる箇所だけを共有）

nvidia-smi（G4dn/T4）
Value error: The quantization method mxfp4 is not supported for the current GPU.
Minimum capability: 80. Current capability: 75.

5. まとめ（前編）

結論：G4dn（T4, CC7.5）は gpt-oss 最新系の量子化/FA3周りで詰まりやすい。
**G5（A10G, CC8.6）/G6（L4, CC8.9）**へ切り替えると、量子化・注意機構・ドライバ/ツールチェインの要件が満たしやすい。
EBSはgp3でOK。容量と IOPS/スループットを分離して設計できる。

後編：AMI構築 & Ollamaデプロイ（G6/L4 編・手順の完全版)

目的：EC2（G6/L4想定）に GPT-OSS を Ollama で安定稼働させ、AMI 化→再展開までを一気通貫で再現可能にする。
方針：GPUドライバ → モデル格納先の外付けEBS → Ollama(systemd) → API化 → AMI 作成/再利用の順で最小構成に絞って説明。

1. 前提と完成像（要点だけ）

インスタンスタイプ：g6.xlarge（L4 / 24GB VRAM）推奨。g5.xlarge（A10G / 24GB）でも可。
OS：Ubuntu 22.04/24.04 系
モデル格納：EBS（gp3, 60GiB 〜）を /mnt/model/ollama に固定（UUID で fstab 登録）
推論エンジン：Ollama（MXFP4 をネイティブ対応）
API：デフォルト 11434/TCP（必要なIPのみに限定公開）
AMI 化：ルートのみを AMI に含め、モデルEBSは別管理（起動後に再アタッチ/再マウント）

2. 構築編（初回サーバ／AMIの元になる機体）

2.1 ディスク構成とマウント（EBS をモデル置き場に）

まず EBS（例：60GiB, gp3, IOPS=3000）を追加アタッチ済みとする。

# 物理確認
lsblk
# ここでは追加EBSが /dev/nvme1n1 に見えている想定（実機で要確認）

# フォーマット（空ディスクの場合のみ）
sudo mkfs -t ext4 /dev/nvme1n1

# マウントポイント作成＆マウント
sudo mkdir -p /mnt/model
sudo mount /dev/nvme1n1 /mnt/model
findmnt /mnt/model

# UUID を控えて fstab に登録（※デバイス名はブレるためUUIDが鉄板）
sudo blkid /dev/nvme1n1
# 例: UUID="21a20a5f-14ef-46cf-9368-59df0d367498"

echo 'UUID=21a20a5f-14ef-46cf-9368-59df0d367498 /mnt/model ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

# パーミッション（後で /mnt/model/ollama を ollama ユーザに委譲）
sudo chown root:root /mnt/model
sudo chmod 755 /mnt /mnt/model

メモ：Nitro 世代は EBS も NVMe 名で見える。/etc/fstab は UUID 固定が安全。

2.2 NVIDIA ドライバ導入（L4/A10G）

sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential dkms linux-headers-$(uname -r) ubuntu-drivers-common curl

# 推奨ドライバを自動選択（L4/A10G なら 55x/57x 系が入る想定）
sudo ubuntu-drivers autoinstall
sudo reboot

再ログイン後に確認：

nvidia-smi
# Driver Version / CUDA Version が表示され、 GPU が認識されていればOK（例：L4 / 23034MiB）

3. Ollama セットアップ（MXFP4 対応・systemd化）

3.1 インストール & モデルディレクトリ変更

# インストール（公式スクリプト）
curl -fsSL https://ollama.com/install.sh | sh

# モデル格納先を EBS に変更（systemd の drop-in で環境変数を設定）
sudo mkdir -p /mnt/model/ollama
sudo chown -R root:root /mnt/model/ollama
sudo chmod 755 /mnt/model/ollama

sudo mkdir -p /etc/systemd/system/ollama.service.d
cat <<'EOF' | sudo tee /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/mnt/model/ollama"
# 任意：CORSが必要なら（例） OLLAMA_ORIGINS を設定
# Environment="OLLAMA_ORIGINS=*://localhost"
# 任意：運用チューニング
# Environment="OLLAMA_KEEP_ALIVE=30m"
# Environment="OLLAMA_MAX_LOADED_MODELS=1"
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now ollama
sudo systemctl status ollama --no-pager -l

注意:
セキュリティ：0.0.0.0:11434 で待受する場合、Security Group で 11434/TCP を自分のIPに限定（0.0.0.0/0 は避ける）。

3.2 gpt-oss:20b を取得して動作確認

# MXFP4 量子化済みの gpt-oss:20b を取得（モデルは /mnt/model/ollama に落ちる）
ollama pull gpt-oss:20b

# 対話で軽く試走
ollama run gpt-oss:20b
# 入力: Hello
# 終了: Ctrl+C

# 使用量と配置の確認
df -hT | grep /mnt/model
sudo du -xh --max-depth=1 /mnt/model

4. API 化（OpenAI 互換 /v1 とネイティブ /api）

4.1 OpenAI 互換エンドポイント（/v1）

# Chat Completions 互換（最小例）
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-oss:20b",
    "messages": [{"role":"user","content":"3つの箇条書きで自己紹介して"}],
    "stream": false
  }'

4.2 Ollama ネイティブ API（/api/generate）

curl http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-oss:20b",
    "prompt": "日本語で短い俳句を1つ",
    "stream": false
  }'

Python から使う場合は pip install ollama 後、from ollama import Client で Client(host="http://:11434") を指定。

5. AMI 作成（モデルEBSを含めない）

5.1 事前クリーニング

# モデルEBSは切り離して AMI に含めない（重要）
sudo systemctl stop ollama

# 念のため fstab を確認（/mnt/model の行がUUID指定であること）
cat /etc/fstab

# アンマウント
sudo umount /mnt/model

EC2 コンソール → Volumes で、/mnt/model だった EBS を Detach（状態が available になるまで待つ）。

その後、Instances → Actions → Image and templates → Create image で AMI を作成。

Instance volumes の一覧にルート（/）のみが含まれていることを確認（モデルEBSが含まれていないこと）。

「Reboot instance」は有効のまま（デフォルト）推奨。

これでルート最小のクリーン AMI が作れる。モデルは別EBSで使い回し/再取得する設計。

6. AMI 利用（新インスタンス起動 → データEBSマウント）

6.1 起動設定

Instance type：g6.xlarge or g5.xlarge

Security Group：11434/TCP と 22/TCP を自分のIPのみに開放

Storage：ルートは AMI が設定（例：40GB）。別途データEBS（例：60GB, /dev/sdf）を追加。

6.2 データEBSのマウント（UUIDで恒久化）

# 例：新規（空）EBS の場合のみフォーマット
# sudo mkfs.ext4 /dev/nvme1n1

sudo mkdir -p /mnt/model
sudo mount /dev/nvme1n1 /mnt/model

# UUID を控え、fstab に **UUID で**登録（/dev/nvme1n1 直書きは不可）
UUID=$(sudo blkid -s UUID -o value /dev/nvme1n1)
echo "UUID=${UUID} /mnt/model ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstab
sudo mount -a

# （初回のみ）ディレクトリ作成と権限
sudo mkdir -p /mnt/model/ollama
sudo chown -R root:root /mnt/model/ollama
sudo chmod 755 /mnt/model/ollama

# Ollama 再起動（override は AMI に含まれているため、そのまま /mnt/model/ollama を読む）
sudo systemctl restart ollama
sudo systemctl status ollama --no-pager -l

7. トラブルシュート（よくある詰まり）

ポート競合：Error: ... 127.0.0.1:11434: bind: address already in use → OLLAMA_HOST でポート変更 or 既存プロセス停止。

OLLAMA_MODELS が反映されない：環境変数を変更したら、systemctl daemon-reload → systemctl restart ollama。

マウント抜け：起動後 /mnt/model が自動マウントされていない → fstab が UUID 記載か確認、sudo mount -a で検証。

ダウンロード遅い：gp3 スループット不足かネットワーク。IOPS/Throughput 増強や一時的に別AZ/EBSサイズで回避。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up