TL;DR
- AWS
g6e.8xlarge（NVIDIA L40S 48GB × 1枚）で、独自アーキテクチャ LLM OpenMythos の 300Mパラメータ / 3Bトークン 事前学習をゼロから回した記録です。 - Claude と対話しながら学習プランを立て、
FineWeb-Eduをストリーミングしながら FSDP + AdamW で学習しました。 - 当初「g6e.8xlarge・12時間で終わる」と見積もったが、実際は 約6.7日（≒161時間） かかり、コストは**当初想定の約10倍（≒$800〜$1,000）**に膨張。
- それでも loss は
12.0 → 3.2まで低下し、3,200 step 付近で「大阪」「東京」といった正しい固有名詞が出力され始めました。小規模でも「ちゃんと学習している」ことが確認できたのが最大の収穫です。
この記事は個人の構築メモをClaude Codeに整理してもらったものです。アーキテクチャの詳細解説というより「1枚GPUでLLM事前学習を回すと何が起きるか」の実録です。
概要（3トピック早わかり）
忙しい人向けに、本記事の要点を「ハイパーパラメータ」「教訓」「GPUクォータ申請」の3つに整理しました。
🔧 ① ハイパーパラメータ設定
モデル（mythos_300m / 実339M） — 3B相当を単一GPU向けに半減
-
dim=1024（2048→半減、重み約1/4）／n_heads=16／max_seq_len=2048 - MoE:
n_experts=32・per_tok=2／アテンション: MLA構成
学習設定
-
seq_len=2048／lr=6e-4（min×0.1 の cosine）／warmup=300 -
AdamW(0.9, 0.95, wd=0.1, fused)／bf16／FSDP（FULL_SHARD）
バッチ（VRAM制約で調整）
-
micro_batch8→2→3／grad_accum=85／global_batch=522,240 -
total_steps=5,744（3Bトークン）／ckpt_every=200
💡 ② 教訓
- 見積もりは実測せよ — 机上/LLM(Gemini)の「12時間」が実際は約161時間・コスト約10倍に。早期に数stepを走らせ1step実測→総step数で外挿する。
-
バッチはVRAM限界まで詰める —
micro_batch2→3 で空きVRAMを使い切り約20%高速化。 - ディスクも見積もる — メモリ・GPUだけ見てディスクを忘れ、ckpt保存でクラッシュ→S3マウントへ変更。
-
壊れないckptが命綱 — 原子的書き込み（tmp→
os.replace）が復旧を救った。
📋 ③ GPUのクォータ申請
- 前提 — GPU系(G/VT/P)は既定クォータ0のことが多く事前申請必須。単位は台数でなくvCPU数。
- 通りやすさ — On-Demand G/VT の小〜中規模(12〜48)は当日〜数時間で自動承認。
- 壁 — 64やP系96など大枠は却下→「account team経由で」。Spotは各リージョン8止まり。
- リージョン差 — 東京は12申請でも8に減額、バージニア(us-east-1)は12〜48が満額承認で通りやすい。
各トピックの詳細は、①→§3・§4.5、②→§8、③→付録A を参照。
1. やりたかったこと
GPU を使ったモデル学習が初めてだったので、以下を目標に設定しました。
- クラウドの単一GPUインスタンスで、フルスクラッチの事前学習をやりきる
- MoE / MLA / 再帰ブロックといったモダンな構成要素を含むモデルを、24〜48GB VRAM に収まるサイズへダウンサイジングして動かす
- 学習の進捗（loss・生成テキスト）を追いながら、コストとスループットの現実を把握する
2. 実行環境
| 項目 | 内容 |
|---|---|
| クラウド | AWS EC2 g6e.8xlarge
|
| GPU | NVIDIA L40S 48GB × 1 |
| 概算コスト | 約 $120 / 日（オンデマンド） |
| フレームワーク | PyTorch（FSDP / AdamW） |
| データセット |
HuggingFaceFW/fineweb-edu（sample-10BT, streaming） |
| トークナイザ |
gpt-oss-20b 系（vocab_size = 199,998） |
| チェックポイント保存先 | 当初ローカルディスク → 容量不足を機に S3 マウント（/mnt/s3files/chkpt/...）へ変更（詳細は §8.1） |
nvidia-smi で見るとピーク時 VRAM 使用量は約32GB（48GB中）でした。
name, memory.total [MiB], memory.used [MiB], memory.free [MiB]
NVIDIA L40S, 46068 MiB, 31945 MiB, 13516 MiB
3. モデル構成（300M ダウンサイジング版）
OpenMythos は、MLA（Multi-head Latent Attention）+ MoE（Mixture of Experts）+ 再帰ブロック（recurrent loop） を組み合わせた構成です。元々は 3B 相当の設定でしたが、単一GPUで安定して回すために各パラメータを半減させた mythos_300m を用意しました。
# open_mythos/variants.py
def mythos_300m() -> MythosConfig:
"""ダウンサイジング版（約0.3B〜0.4B）。VRAM消費を大幅に削減し、24GB環境での学習・推論を安定化。"""
return MythosConfig(
vocab_size=32000,
dim=1024, # 隠れ層の次元数。2048 -> 1024 に半減（重みが約1/4に減少）
n_heads=16, # 各ヘッド次元 dim/n_heads = 1024/16 = 64 を維持
n_kv_heads=4,
max_seq_len=2048, # 4096 -> 2048（アテンションのコンテキストVRAMを節約）
max_loop_iters=8, # 16 -> 8（再帰ループのアクティベーションキャッシュを削減）
prelude_layers=2,
coda_layers=2,
attn_type="mla",
kv_lora_rank=128, # dim縮小に合わせてLoRAランクも半減
q_lora_rank=256, # 同上
qk_rope_head_dim=32,
qk_nope_head_dim=64,
v_head_dim=64,
n_experts=32, # 64 -> 32（MoE全体の容量を削減）
n_shared_experts=1, # 2 -> 1
n_experts_per_tok=2, # 4 -> 2（1トークンあたりの計算量を軽量化）
expert_dim=1024, # dimに合わせて 2048 -> 1024
act_threshold=0.99,
rope_theta=500000.0,
lora_rank=8,
)
ダウンサイジングのポイントは「
dimを半分にすると重みが約1/4になる」こと。ただしn_heads/expert_dim/qk_rope_head_dimなど他パラメータとの整合性を崩さないよう注意が必要です。実際に学習を回したときの実パラメータ数は 339,241,922（約339M） でした（
vocab_sizeは実トークナイザに合わせて 199,998 に上書きされるため）。
4. 学習スクリプト
FineWeb-Edu をストリーミングで読みつつ、FSDP + AdamW で事前学習します（training/g6e_8xl_12H_300m.py）。要点だけ抜粋します。
4.1 データローダ（ストリーミング + shard分割）
FineWeb-Edu は数兆トークン規模なのでディスクに落とさず streaming=True で必要な分だけ取得。(rank, worker_id) ごとに shard を決定的に割り当てることで、プロセス間の調整なしに重複なくカバーします。
class FineWebEduDataset(IterableDataset):
def __iter__(self):
worker = get_worker_info()
num_workers = worker.num_workers if worker else 1
worker_id = worker.id if worker else 0
total_shards = self.world_size * num_workers
shard_index = self.rank * num_workers + worker_id
ds = load_dataset(
"HuggingFaceFW/fineweb-edu",
name=self.subset,
split="train",
streaming=True,
).shard(num_shards=total_shards, index=shard_index)
buf = []
for sample in ds:
buf.extend(self.encoding.encode(sample["text"]))
while len(buf) >= self.seq_len + 1:
chunk = buf[: self.seq_len + 1]
buf = buf[self.seq_len + 1 :]
yield (
torch.tensor(chunk[:-1], dtype=torch.long), # input
torch.tensor(chunk[1:], dtype=torch.long), # target（1つずらし）
)
ドキュメントを連結して固定長に切り出すことで全ステップが同一 shape になり、FSDP 下での再コンパイルや pad マスクが不要になります。
4.2 学習率スケジュール（linear warmup → cosine decay）
def get_lr(step, warmup, total, max_lr, min_lr):
if step < warmup:
return max_lr * step / warmup
if step >= total:
return min_lr
decay = (step - warmup) / (total - warmup)
return min_lr + 0.5 * (max_lr - min_lr) * (1.0 + math.cos(math.pi * decay))
4.3 FSDP ラップと mixed precision
mp_policy = MixedPrecision(param_dtype=amp_dtype, reduce_dtype=amp_dtype, buffer_dtype=amp_dtype)
wrap_policy = ModuleWrapPolicy({TransformerBlock, RecurrentBlock})
model = FSDP(
model,
sharding_strategy=ShardingStrategy.FULL_SHARD,
mixed_precision=mp_policy,
auto_wrap_policy=wrap_policy,
device_id=local_rank,
)
amp_dtype は L40S が bf16 対応なので torch.bfloat16 を使用。
4.4 チェックポイント（FSDP FULL_STATE_DICT + 原子的書き込み）
- FSDP 下ではモデルとオプティマイザの state を同一の
FULL_STATE_DICTコンテキスト内でまとめて gather（分けると resume 時に silent divergence の実績あり）。 -
tmpに書いてからos.replaceで原子的に置換 → 途中killでも前のckptが壊れない。 - ファイル名は
step_{N:07d}.ptでゼロ埋め → 辞書順ソート＝時系列順。keep_last=3で古いものを削除。
if ddp:
with FSDP.state_dict_type(model, StateDictType.FULL_STATE_DICT,
FullStateDictConfig(offload_to_cpu=True, rank0_only=True)):
model_state = model.state_dict()
optim_state = FSDP.optim_state_dict(model, optimizer)
4.5 主なハイパーパラメータ
| パラメータ | 値 |
|---|---|
seq_len |
2048 |
micro_batch |
3（当初8→VRAM不足で2→最終的に3へ。詳細は §8） |
grad_accum |
85（micro_batch=3 時。=2 の時は128） |
| global batch tokens | 522,240（=2 の時は524,288） |
target_tokens |
3,000,000,000（3B） |
total_steps |
5,744（micro_batch=2 時は5,722） |
warmup_steps |
300 |
lr |
6e-4（min = lr×0.1） |
weight_decay |
0.1 |
| optimizer | AdamW (β=0.9,0.95, fused=True) |
ckpt_every |
200 step |
5. 実行方法
# 学習（バックグラウンド実行 + ログ追記）
# ※ HF_TOKEN は自分のトークンに置き換えてください（公開時は必ずマスク）
HF_TOKEN=<your_hf_token> PYTHONPATH=. \
nohup python training/g6e_8xl_12H_300m.py >> logs/g6e_8xl_12H_300m.log 2>&1 &
マルチGPUの場合:
torchrun --nproc_per_node=$(python -c "import torch; print(torch.cuda.device_count())") \
training/g6e_8xl_12H_300m.py
6. チェックポイントの評価
保存済み ckpt を読み込んで、①LTI 安定性（ρ(A) < 1）、②簡単な生成テストを行います（eval/model_300m.py）。
import torch
from open_mythos import OpenMythos
from open_mythos.variants import mythos_300m
from open_mythos.tokenizer import MythosTokenizer
chkpt = "checkpoints_300m/step_0000600.pt"
ckpt = torch.load(chkpt, weights_only=False)
print(f"Step: {ckpt['step']}, vocab_size: {ckpt['vocab_size']}")
cfg = mythos_300m()
cfg.vocab_size = ckpt["vocab_size"]
cfg.max_seq_len = 2048
model = OpenMythos(cfg)
model.load_state_dict(ckpt["model"])
model.eval().cuda()
# LTI 安定性（再帰ブロックの状態遷移行列 A のスペクトル半径）
A = model.recurrent.injection.get_A()
print(f"ρ(A) max = {A.abs().max().item():.6f}") # 0.0001〜0.999 の範囲なら OK
print(f"ρ(A) min = {A.abs().min().item():.6f}")
# 生成テスト
tok = MythosTokenizer()
prompt = torch.tensor([tok.encode("The capital of Japan is")]).cuda()
with torch.no_grad():
out = model.generate(prompt, max_new_tokens=32, n_loops=8, temperature=0.7, top_k=50)
print(tok.decode(out[0].tolist()))
PYTHONPATH=. python eval/model_300m.py
7. 学習の進捗と結果
7.1 loss の推移（抜粋）
step 10/5744 | loss 12.0400 | gnorm 3.14 | lr 1.80e-05 | 0.0B tokens
step 50/5744 | loss 8.4242 | gnorm 1.55 | lr 9.80e-05 | 0.0B tokens
step 100/5744 | loss 6.9817 | gnorm 0.63 | lr 1.98e-04 | 0.1B tokens
step 200/5744 | loss 5.8883 | gnorm 1.68 | lr 3.98e-04 | 0.1B tokens
step 3200/5744 | loss 3.3487 | gnorm 0.30 | lr 3.02e-04 | 1.7B tokens ← 「大阪」「東京」が出現
step 5744/5744 | loss 3.2xxx | gnorm 0.25 | lr 6.00e-05 | 3.0B tokens ← 学習完了
- 開始時 loss 12.04 → 最終 約3.2 まで低下。
- 学習期間: 2026-05-23 19:11 〜 2026-05-30 12:42（約6.7日 / ≒161時間）。
7.2 生成テキストの変化
200 step 時点（まだデタラメだが英語の体裁は出来ている）:
The capital of Japan is a name of the most important in the earth, which was the first to the second half of the 1950s; as the only one of the first
3,200 step 時点（loss 3.34）:
「大阪」「東京」といった正しい固有名詞が出力され始めた。単なる次トークン予測の繰り返しでも、モデルが世界知識を獲得していく様子が確認できた。
8. ハマったところ・学び
8.1 チェックポイント保存でディスク容量不足クラッシュ（→ 進捗ロールバック）
学習途中の 2026-05-24 19:58 頃、step 800 のチェックポイント保存でディスク容量不足エラーが発生し、プロセスが停止しました。
2026-05-24 19:58:10 | step 800/5722 | loss 4.0474 | ... ← ここで保存失敗・プロセス停止
（step 800 の "Checkpoint saved" ログが無い）
2026-05-24 23:08:29 | GPUs: 1 | ... ← 再起動
2026-05-24 23:08:35 | Resuming from checkpoint: .../step_0000600.pt
2026-05-24 23:08:42 | Resumed at step 600 ← step 800ではなく 600 から再開
根本原因は EC2 インスタンスの見積もりミスでした。最初にインスタンスを選ぶ際、メモリと GPU（VRAM）だけに注目し、ディスク（EBS）容量を考慮していなかったのです。チェックポイントは当初ローカルディスクに保存していたため、ckpt_every=200・keep_last=3 でも数百MB〜GB級の .pt が積み上がり、step 800 の書き込みで空き容量が枯渇しました。
対処: エラー発生後、チェックポイント保存先を S3 をマウントした /mnt/s3files/chkpt/... に変更。これによりローカルディスク容量に縛られず、以降は保存が安定しました（途中経過 のログでも保存先が checkpoints_300m/... → /mnt/s3files/chkpt/checkpoints_300m/... に切り替わっています）。
-
原子的書き込み（tmp →
os.replace）のおかげで既存 ckpt は無傷だったので、直前のstep_0000600.ptから安全に resume できた。ここは実装の設計が効いた点。 - ただし step 600〜800 の学習はやり直しになった（約200step ぶんロールバック）。
- 教訓その1: インスタンス見積もりは メモリ・GPU だけでなくディスク容量も必ず含める。特にチェックポイントを頻繁に書く学習では EBS がすぐ埋まる。
- 教訓その2: 長時間・単一GPUの事前学習では、チェックポイント保存先の空き容量監視と
keep_lastの実効性チェックを最初にやっておくべきだった。保存先を最初から S3 等のオブジェクトストレージにしておけば、この事故は防げた。
8.2 micro-batch を 2→3 に上げたら約20%高速化
VRAM がまだ余っていた（48GB中13GB空き）ので、再起動のタイミングで micro_batch を 2 → 3 に引き上げました。
micro_batch=2: seq_len=2048 | grad_accum=128 | global_batch_tokens=524,288 | total_steps=5,722
micro_batch=3: seq_len=2048 | grad_accum=85 | global_batch_tokens=522,240 | total_steps=5,744
- ログ出力間隔（
log_every=10、＝10 step ごと）の実時間: 約20分（mb=2）→ 約16分（mb=3） と 約20%高速化（1 step あたりに換算すると約2.0分 → 約1.6分）。 -
micro_batchを上げる＝grad_accumが減る（128→85）ため、GPUの1回あたり処理量が増えて利用効率が改善した。 - 変更後の VRAM 使用状況は以下。48GB をほぼ使い切り、空きは 448MiB。mb=2 時の「13GB 余り」から一転して限界まで詰められた。
$ nvidia-smi --query-gpu=name,memory.total,memory.used,memory.free --format=csv
name, memory.total [MiB], memory.used [MiB], memory.free [MiB]
NVIDIA L40S, 46068 MiB, 45013 MiB, 448 MiB
micro_batch=2 |
micro_batch=3 |
|
|---|---|---|
| VRAM 使用 | 31,945 MiB | 45,013 MiB |
| VRAM 空き | 13,516 MiB | 448 MiB |
| 10 step あたり所要時間 | 約20分 | 約16分 |
- 当初プランは
micro_batch=8だったが VRAM不足エラーで一度2まで下げていた。バッチ設計は VRAM ギリギリまで詰めるのが正義で、最初から余った13GBを使い切るべきだった（結果的に mb=3 がこの L40S 48GB での実用上限だった）。
8.3 見積もりは10倍外れる
| 項目 | 当初見積もり | 実績 |
|---|---|---|
| 所要時間 | 12時間 | 約161時間（6.7日） |
| コスト | 〜$100 | 約$800〜$1,000 |
- 「g6e.8xlarge・12時間で 3Bトークン + 300Mパラメータ」という見積もりは大幅に楽観的だった。
- 1枚 L40S だけでも 約$120/日。フルスクラッチ事前学習は、小規模でも油断すると簡単に4桁ドルに届く。
なぜ外れたか＝机上見積もりだけで走らせた
- この「12時間」は 机上計算（LLM／Gemini に確認した理論値） で、実機での計測に基づくものではなかった。FLOPs ベースの理論スループットは、実際の I/O・データローダ・MoE ルーティング・VRAM 制約による
micro_batch低下などを織り込めず、桁で外れる。 -
教訓: 机上・LLM の見積もりを信じて本番を回さない。まず数〜数十 step だけ実行して「1 step あたりの実測時間」を測り、そこから総ステップ数で外挿する。
- 例: 今回なら 10 step 走らせれば「10 step ≒ 20分 → 全 5,744 step ≒ 約191時間」と初日中に分かった。これで予算とスケジュールを即座に見直せた。
- 実測は
micro_batchを変えるたびにやり直す（本件では mb=2→3 で 20分→16分に変化）。バッチ設定を確定してから外挿するのが正しい順序。
8.4 それでも得たもの
- 単一GPUでもフルスクラッチ事前学習は完走できる（時間とお金はかかる）。
- loss と生成テキストの両方で、モデルが着実に学習していることを可視化できた。
- FSDP のチェックポイント/レジューム、ストリーミングデータローダなど、実運用で必要な足回りを一通り実装・検証できた。
-
原子的なチェックポイント書き込み（tmp→
os.replace）が、ディスク容量不足クラッシュからの復旧を救った。長時間ジョブでは「壊れないチェックポイント」と「保存先の容量監視」が本当に効いてくる。
9. まとめ
初めての GPU 事前学習として、AWS の単一 L40S で 300M パラメータ・3B トークンの OpenMythos を完走させました。技術的には FSDP + ストリーミング + MoE/MLA/再帰ブロックという構成を一通り動かせたこと、コスト面では「見積もりは軽く10倍外れる」という現実を体験できたことが大きな収穫です。
次のステップとしては、
-
micro_batchを VRAM 限界まで上げてスループット改善 -
sample-100BT/defaultでのトークン数スケールアップ - マルチGPU（
torchrun）でのスケール検証
あたりを試したいところです。
付録A. GPUインスタンスを使うためのクォータ緩和申請メモ
そもそも GPU 搭載インスタンス（G/VT/P 系）は、新規アカウントだと デフォルトのクォータ（上限 vCPU 数）が 0 のことが多く、そのままでは起動できません。事前に Service Quotas で緩和申請（Quota Increase）を出す必要があります。今回申請した7件のケース記録から、申請項目と通りやすさを整理します。
対象は
us-east-1（バージニア北部）7件とap-northeast-1（東京）4件の申請記録です。両リージョンで同種の申請を出しているため、リージョン間の難易度比較もできます（→ A.4）。
A.1 申請に必要な項目
Service Quotas から出す際に指定するのは以下です（却下時に account team へ渡す情報も含む）。
| 項目 | 内容・例 |
|---|---|
| Service |
EC2 Instances（オンデマンド）/ EC2 Spot Instances（スポット） |
| Region | 例: US East (Northern Virginia)
|
| Primary Instance Type |
All G and VT instances / All P instances / All P Spot Instance Requests
|
| Limit name |
Instance Limit（=実質 vCPU 数）/ Spot は vCPU Limit
|
| New limit value | 希望 vCPU 数（例: 12 / 32 / 48 / 64 / 96） |
| Use case description | ワークロード説明（自動起票だと This support case was created by Service Quotas） |
GPU 系で大きな枠を求めて却下された場合、account team 経由の申請に以下が要求されます:
- ワークロード / ユースケースの詳細な説明
- 必要な GPU インスタンスタイプと数量
- キャパシティが必要になる 想定タイムライン（時期）
ポイント: 単位は「台数」ではなく vCPU 数。例えば
g6e.8xlargeは 32 vCPU なので、All G and VT instances = 48の枠があれば1台（32 vCPU）は起動できます。
A.2 申請結果一覧（us-east-1・7件）
| # | 日付 | 種別 | インスタンス | 希望値(vCPU) | 結果 | 付与値 | 処理時間 |
|---|---|---|---|---|---|---|---|
| 1 | 05-19 | On-Demand | All G and VT | 12 | ✅ 承認 | 12 | 約1.5h（当日） |
| 2 | 05-20 | On-Demand | All P | 32 | ✅ 承認 | 32 | 約7h（当日） |
| 3 | 05-22 | On-Demand | All G and VT | 32 | ✅ 承認 | 32 | 約35分（当日） |
| 4 | 05-22 | On-Demand | All P | 96 | ❌ 却下 | – | 約2h |
| 5 | 05-22 | On-Demand | All G and VT | 64 | ❌ 却下 | – | 約5h |
| 6 | 05-23 | On-Demand | All G and VT | 48 | ✅ 承認 | 48 | 約7h（当日） |
| 7 | 05-23 | Spot | All P Spot | 96 | ⚠️ 部分承認 | 8 | 当日 |
A.3 申請結果一覧（東京 ap-northeast-1・4件）
| # | 日付 | 種別 | インスタンス | 希望値(vCPU) | 結果 | 付与値 |
|---|---|---|---|---|---|---|
| 1 | 05-19 | On-Demand | Running On-Demand G and VT | 4 | ✅ 全量承認 | 4 |
| 2 | 05-19 | On-Demand | Running On-Demand G and VT | 12 | ⚠️ 部分承認 | 8 |
| 3 | 05-23 | Spot | All P Spot | 96 | ⚠️ 部分承認 | 8 |
| 4 | 05-23 | Spot | All G and VT Spot | 96 | ⚠️ 部分承認 | 8 |
Spot 側は「不十分なら詳細なユースケースを添えて再申請を」とのコメント付き（us-east-1 と同じ扱い）。
A.4 リージョン比較：東京(ap-northeast-1) は明確に渋い
同じ「On-Demand G/VT・12 vCPU」の申請でも、リージョンで結果が割れました。
| 申請内容 | us-east-1（バージニア） | ap-northeast-1（東京） |
|---|---|---|
| On-Demand G/VT 4 vCPU | （申請なし） | ✅ 4（全量） |
| On-Demand G/VT 12 vCPU | ✅ 12（全量） | ⚠️ 8（減額） |
| On-Demand G/VT 32 / 48 vCPU | ✅ 全量承認 | （申請なし） |
| Spot P / G 96 vCPU | ⚠️ 8（P Spot） | ⚠️ 8（P・G とも） |
- 決定的な差は On-Demand G/VT の 12 vCPU。バージニアは満額12どころか32・48まで通ったのに、東京は12申請で8しか出なかった。同じ「GPUを1台動かしたいだけ」の規模でも、東京のほうが GPU 供給がタイトで枠を絞られる傾向。
- Spot はどちらのリージョンも8止まり。GPU スポットは容量事情でリージョンを問わず渋い。
- 結論として 「リージョンによって申請の通りやすさは実際に違う」 ことがデータで確認できた。**GPU を確保しやすいのは（少なくとも今回は）バージニア(us-east-1)**で、実際の学習もそちらで走らせた。
A.5 通りやすさの傾向（この記録から読み取れること）
- 小〜中規模の G/VT オンデマンドは自動承認されやすい: 12 / 32 / 48 vCPU はいずれも当日〜数時間で全承認。数十分で通ったケースもある。
-
一定ラインを超えると「標準サポートでは承認不可」の壁:
- G/VT の 64 vCPU は却下（48 までは通ったのに）。
- P 系の 96 vCPU も却下（P の 32 は承認済み）。
- いずれも 「GPU インスタンスの追加増枠は account team / 特別レビュー経由で」 という定型回答。標準の Service Quotas 自動フローで通るのは “小さめの枠” まで、と考えておくのが現実的。
- Spot の P 系は特に渋い: 96 希望に対し 付与は 8 のみの部分承認。GPU スポットは容量事情でほぼ絞られると考えたほうがよい。
- 処理時間はバラつく: 同じ内容でも約35分〜約7時間。即時ではないので、使いたい日から逆算して早めに申請しておくべき。
A.6 実務的な教訓
- GPU を使うなら、まずクォータ申請がボトルネック。インスタンス選定（メモリ/GPU/ディスク → §8.1）より前に、そもそも「起動枠があるか」を確認する。
- リージョン選びが効く。同じ規模でも東京(8)よりバージニア(12〜48)のほうが通りやすかった。GPU を確実に確保したいなら us-east-1 など供給に余裕のあるリージョンを第一候補に。
- 一度に大きな枠を狙うより、段階的に上げるほうが通りやすい（バージニアで 12→32→48 と刻んだものは通り、64 で弾かれた）。
- 大規模 GPU / スポットが必要なら、最初から AWS の account team・Sales 経由で、ワークロード説明・必要タイプと数量・タイムラインを添えて申請する。
- 今回の学習に使った
g6e.8xlarge（L40S・32 vCPU）は、バージニアのAll G and VT instances = 48の承認枠で無事に起動できた。
本記事は個人プロジェクトの構築メモを整理したものです。数値・生成例・クォータ申請結果はすべて実際のログ／ケース記録に基づいています。