🗻

富岳分散 LLM train のメモ

2025/12/14に公開

とりま既存の試みを調べてみる

13B, Megatron-DeepSpeed

Claude くんに調べてもらったので多少間違いあるかもしれません.

Megatron(分割方法)

TP(Tensor Parallel) 6
PP(Pipeline Parallel) 8
DP(Data Parallel) 288 (= 13824/(6*8)

モデル構成
--num-layers 40
--hidden-size 5184
--num-attention-heads 36
--seq-length 2048
パラメータ数計算:
~13B = 40 layers × (12 × 5184² + 4 × 5184 × vocab_size)
バッチ構成
MICRO_BATCH_SIZE = 1
GLOBAL_BATCH_SIZE = 2016
DATA_PARALLEL_SIZE = 288

Gradient Accumulation = 2016 / (1 × 288) = 7 steps

ランクマッピングの最適化
bashhostfile_name="24x2x24x2x3x2_tp ${tp}dp$ {dp}pp${pp}"
--vcoordfile /vol0503/share/hp230254/rankmap/vcoordfile_${hostfile_name}_fj
6次元トーラス 48x6x48 を 24x2x24x2x3x2 に分解してランク配置を最適化しています。

Checkpoint Activation の部分適用

bashNoCAPipe=4
SwitchRank=`expr ${PJM_NODE} * ( ${PP} - ${NoCAPipe} ) / ${PP}`
PP の最後4ステージ (後半) は checkpoint activation なし、前半4ステージはあり。メモリと再計算のバランス。
5. CPU Optimizer
bash--cpu-optimizer
--cpu-torch-adam

GPU と違い、optimizer state を HBM から退避する必要がないため CPU 上で直接計算。

トポロジ図

           ┌─────────────────────────────────────────────────┐
           │         Tofu D 6D Torus: 48 × 6 × 48            │
           │                                                  │
  TP=6     │  ┌─N0─┬─N1─┬─N2─┬─N3─┬─N4─┬─N5─┐               │
(ノード間) │  │ L0 │ L0 │ L0 │ L0 │ L0 │ L0 │ ← 同じ層を分割 │
           │  └────┴────┴────┴────┴────┴────┘               │
           │        ↓ AllReduce (TP通信)                     │
           │                                                  │
  PP=8     │  Stage0 → Stage1 → ... → Stage7                 │
(ノード間) │  (5層)    (5層)          (5層)                   │
           │        ↓ P2P (PP通信)                           │
           │                                                  │
  DP=288   │  Replica0, Replica1, ..., Replica287            │
(ノード間) │        ↓ AllReduce (勾配集約)                   │
           └─────────────────────────────────────────────────┘
通信最適化
bashLP="libtcmalloc.so:my_mpi_allreduce_utofu_thresh100m_1214_noprint.so"

カスタム AllReduce: my_mpi_allreduce_utofu - Tofu D 向け最適化
100MB閾値: 大きなメッセージの処理方法を切り替え

メモリ使用量（1ノードあたり）

モデル (TP=6分割後): 13B / 6 / 8 ≈ 270M params
  FP32 weights:     ~1.1 GB
  Gradients:        ~1.1 GB  
  Optimizer (Adam): ~2.2 GB (momentum + variance)
  Activations:      可変 (checkpoint activation で削減)
  -----------------------------------------
  合計:             ~10-15 GB / 32 GB HBM ✓

学習設定

Train tokens:     400B
LR warmup:        4B tokens
LR decay:         cosine, 400B tokens
Learning rate:    1e-4 → 1e-6
Weight decay:     0.1
Adam β1/β2:       0.9 / 0.95
Grad clip:        1.0

Fugaku-LLM 13B メモリ消費内訳

前提条件

モデル: 13B params (40層, hidden=5184, heads=36)
並列化: TP=6, PP=8, DP=288
1ノードあたり: 5層 (40/8), TP で 1/6 分割
Micro-batch: 1
Seq length: 2048
精度: FP32
HBM容量: 32 GB/node

1ノードあたりのパラメータ数

全モデル: ~13B params

1層あたり:
  Attention (QKV + O): 4 × 5184² = 107M
  FFN (fc1 + fc2):     2 × 5184 × 20736 = 215M
  LayerNorm:           無視可能
  -----------------------------------
  1層合計:             ~322M params

PP=8 (5層/stage), TP=6:
  params/node = 322M × 5 / 6 ≈ 268M params

メモリ内訳

重みなどはすべて FP32 の模様

A. Model Weights (FP32)

268M × 4 bytes = 1.07 GB

B. Gradients (FP32)

268M × 4 bytes = 1.07 GB

C. Optimizer States

--cpu-optimizer
--cpu-torch-adam

Adam optimizer は CPU メモリ上で計算 → HBM 消費 0 GB

通常の GPU 学習では:

Adam: momentum (FP32) + variance (FP32) = 8 bytes/param
268M × 8 = 2.14 GB  ← これが不要！

D. Activations

Checkpoint Activation あり (Stage 0-3):

保存するもの: 各層の入力のみ
再計算: forward 時に中間結果を再計算

Input activation per layer:
  batch × seq × (hidden/TP) × 4 bytes
  = 1 × 2048 × 864 × 4 = 7.1 MB

5層分: 7.1 × 5 = 35.5 MB

Checkpoint Activation なし (Stage 4-7):

1層あたりの中間 activation:

Attention:
  Q, K, V:           3 × 1 × 2048 × 864 × 4 = 21 MB
  Attention scores:  1 × 6 × 2048 × 2048 × 4 = 100 MB  (heads/TP × seq²)
  Softmax output:    100 MB
  Context vector:    7 MB
  
FFN:
  fc1 output:        1 × 2048 × 3456 × 4 = 28 MB  (4×hidden/TP)
  GeLU input/output: 28 MB

1層合計: ~280 MB
5層分:  ~1.4 GB

E. 通信バッファ

TP AllReduce バッファ:
  hidden/TP × seq × batch × 4 = 864 × 2048 × 1 × 4 = 7 MB × 2 (send/recv) ≈ 14 MB

PP P2P バッファ:
  同上 ≈ 14 MB

DP AllReduce (gradient):
  params × 4 = 268M × 4 = 1.07 GB
  (ただし通信と計算をオーバーラップするため一部のみ)

実効的な通信バッファ: ~0.3-0.5 GB

F. その他

PyTorch 内部バッファ:    ~0.3 GB
一時計算バッファ:        ~0.2 GB
MPI バッファ:           ~0.1 GB
-----------------------------
合計:                   ~0.6 GB

総合メモリ使用量

項目	Checkpoint ON (Stage 0-3)	Checkpoint OFF (Stage 4-7)
Weights (FP32)	1.07 GB	1.07 GB
Gradients (FP32)	1.07 GB	1.07 GB
Optimizer (Adam)	0 GB (CPU上)	0 GB (CPU上)
Activations	0.04 GB	1.4 GB
通信バッファ	0.4 GB	0.4 GB
その他	0.6 GB	0.6 GB
合計	~3.2 GB	~4.5 GB
HBM使用率	~10%	~14%

なぜこんなに余裕があるのか？

1. CPU Optimizer: Adam の m, v が HBM を消費しない（通常 2.14 GB 節約）
2. TP=6 分割: パラメータ・activationが 1/6 に
3. PP=8 分割: 各ノードは 5層のみ
4. Micro-batch=1: Activation memory が最小
5. FP32: Mixed precision ではないが、分割が効いている

メモリ図解

32 GB HBM per node
┌────────────────────────────────────────────────────────────────┐
│████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░│
│ ~4-5GB                        ~27-28 GB 空き                   │
└────────────────────────────────────────────────────────────────┘

内訳 (Checkpoint OFF の場合):
┌─────────┬─────────┬──────────────┬───────┬───────┐
│Weights  │Gradients│ Activations  │Comm   │Other  │
│ 1.07GB  │ 1.07GB  │   1.4GB      │0.4GB  │0.6GB  │
└─────────┴─────────┴──────────────┴───────┴───────┘

比較: GPU 学習 vs 富岳

項目	典型的 GPU 学習	富岳構成
Optimizer	GPU HBM 上 (2.14 GB)	CPU RAM (0 GB)
精度	Mixed (FP16/BF16)	FP32
TP配置	ノード内 NVLink	ノード間 Tofu D
メモリ効率	高 (mixed precision)	中 (FP32だが分割で対応)

この余裕の活用

HBM に ~27 GB の余裕があるので:

Micro-batch を増やせる可能性
- 現在 micro_batch=1 → 2-4 に増やせばスループット向上
- ただし通信とのバランス
より大きなモデル対応
- 100B クラスでも同じノード数で可能
通信バッファ拡大
- AllReduce の効率化

現状の設定は保守的で、安定性重視の構成と思われます。

120B クラス

120B モデルへの拡張設計

13B → 120B のスケーリング

項目	13B	120B	倍率
パラメータ数	13B	120B	9.2x
Layers	40	80	2x
Hidden size	5184	10368	2x
Attention heads	36	72	2x
FFN hidden	20736	41472	2x

パラメータ計算:
  1層: 12 × h² + vocab overhead
  13B:  12 × 5184² × 40  ≈ 13B
  120B: 12 × 10368² × 80 ≈ 103B + embedding ≈ 120B

メモリ要件の変化

現行 13B (TP=6, PP=8)

1ノードあたり: 268M params → ~3-4 GB HBM使用

120B で同じ並列度だと...

1ノードあたり: 268M × 9.2 ≈ 2.5B params
  Weights:    2.5B × 4 = 10 GB
  Gradients:  2.5B × 4 = 10 GB
  Activations: ~4-6 GB (hidden 2倍で増加)
  ----------------------------------
  合計: ~24-26 GB → ギリギリ or オーバー

拡張オプション

Option A: PP を増やす（最もシンプル）

TP=6, PP=16, DP=288
ノード数: 6 × 16 × 288 = 27,648 ノード (2倍)

項目	計算
Layers/stage	80 / 16 = 5 layers
Params/node	120B / 6 / 16 ≈ 1.25B
Weights	1.25B × 4 = 5 GB
Gradients	5 GB
Activations	~2-3 GB
合計	~12-13 GB ✓

利点: 構成がシンプル、通信パターン変更なし
欠点: ノード数 2倍、Pipeline bubble 増加

Option B: TP を増やす

TP=12, PP=8, DP=288
ノード数: 12 × 8 × 288 = 27,648 ノード (2倍)

項目	計算
Layers/stage	80 / 8 = 10 layers
Params/node	120B / 12 / 8 ≈ 1.25B
合計	~12-13 GB ✓

問題: TP=12 は Tofu D の 6方向と整合しない
     → 2段階の TP 通信が必要（効率低下）

Option C: PP + DP 調整（ノード数維持）

TP=6, PP=16, DP=144
ノード数: 6 × 16 × 144 = 13,824 ノード (同じ)

項目	計算
Params/node	120B / 6 / 16 ≈ 1.25B
メモリ	~12-13 GB ✓
Global batch	144 × micro_batch × grad_acc

利点: 同じノード数で実行可能
欠点: DP 半減でスループット低下、バッチサイズ制約

Option D: FP16 + 量子化（メモリ効率化）

TP=6, PP=8, DP=288
ノード数: 13,824 (同じ)
精度: FP16 forward/backward + FP32 master weights

項目	FP32	FP16
Weights	10 GB	5 GB
Gradients	10 GB	5 GB
Master weights	-	10 GB (CPU)
Activations	6 GB	3 GB
合計	26 GB ✗	13 GB ✓

課題: A64FX の FP16 GEMM 最適化が必要
     BF16 非対応なので loss scaling 複雑

推奨構成

最も現実的: Option A + 改良

# 120B 構成
TENSOR_MODEL_PARALLEL_SIZE=6   # 維持（Tofu D 6方向）
PIPELINE_MODEL_PARALLEL_SIZE=20 # 80層 / 20 = 4層/stage
DATA_PARALLEL_SIZE=288          # 維持

NNODES=34,560  # 6 × 20 × 288 = 34,560 (2.5倍)

--num-layers 80
--hidden-size 10368
--num-attention-heads 72
--seq-length 2048
--micro-batch-size 1
--global-batch-size 2016

メモリ見積もり

Params/node: 120B / 6 / 20 = 1B params
  Weights:     1B × 4 = 4 GB
  Gradients:   1B × 4 = 4 GB  
  Optimizer:   0 GB (CPU)
  Activations: ~2 GB (4層, hidden大)
  通信/その他: ~1 GB
  --------------------------------
  合計:        ~11 GB / 32 GB ✓ (余裕あり)

通信量の変化

TP 通信 (AllReduce per layer)

13B:  5184 × 2048 × 4 × 2 = 84 MB/layer
120B: 10368 × 2048 × 4 × 2 = 169 MB/layer (2倍)

PP 通信 (P2P per micro-batch)

13B:  5184 × 2048 × 4 = 42 MB
120B: 10368 × 2048 × 4 = 84 MB (2倍)

DP 通信 (AllReduce gradient)

13B:  268M × 4 = 1.07 GB
120B: 1B × 4 = 4 GB (約4倍)

性能予測

計算量

13B,  seq=2048: ~160 TFLOPs/iteration
120B, seq=2048: ~1.5 PFLOPs/iteration (約9倍)

学習時間（同じトークン数 400B の場合）

13B × 13,824 nodes: T 時間
120B × 34,560 nodes: 

計算: 9倍 / 2.5倍ノード = 3.6倍
通信オーバーヘッド: +20-50% (推定)

予測: 4-5倍 の学習時間

拡張構成まとめ

構成	TP	PP	DP	ノード数	メモリ/node	備考
13B (現行)	6	8	288	13,824	~4 GB	-
120B 推奨	6	20	288	34,560	~11 GB	ノード2.5倍
120B 圧縮	6	20	144	17,280	~11 GB	DP半減
120B FP16	6	10	288	17,280	~8 GB	FP16最適化必要

追加検討事項

1. Pipeline Bubble

PP=20 の場合:
  Bubble ratio ≈ (PP-1) / (PP-1 + micro_batches)
  
  micro_batch=1, grad_acc=7:
  Bubble ≈ 19 / (19 + 7) ≈ 73% ← 高すぎる！

対策:
  - Virtual Pipeline (Interleaved Schedule)
  - Micro-batch 増加

2. Activation Checkpointing 調整

80層, PP=20 → 4層/stage

メモリに余裕があるので:
  - 全 stage で checkpoint OFF 可能
  - Forward 再計算なしで高速化

3. Sequence Length 拡張

メモリ余裕を seq_len 拡張に使う:
  seq=2048 → seq=4096
  
Activation: 4倍増
KV cache 考慮: Flash Attention 実装が必要

長コンテキスト (1M) 対応には別途 Ring Attention が必要になる.

70B どうでしょう

70B モデルへの拡張設計

13B → 70B のスケーリング

項目	13B	70B (Llama2相当)	倍率
パラメータ数	13B	70B	5.4x
Layers	40	80	2x
Hidden size	5184	8192	1.58x
Attention heads	36	64	1.78x
FFN hidden	20736	28672	1.38x

パラメータ検算:
  70B ≈ 12 × 8192² × 80 + embeddings ≈ 70B ✓

現行ノード数 (13,824) で可能か？

Case 1: PP のみ増加

TP=6, PP=16, DP=144
ノード数: 6 × 16 × 144 = 13,824 ✓ (同じ)

項目	計算
Layers/stage	80 / 16 = 5 layers
Params/node	70B / 6 / 16 ≈ 729M
Weights (FP32)	729M × 4 = 2.9 GB
Gradients	2.9 GB
Optimizer	0 GB (CPU)
Activations	~1.5-2 GB
通信/その他	~1 GB
合計	~8-9 GB / 32 GB ✓

結論: 現行ノード数で余裕を持って収まる！

推奨構成

Option A: 同一ノード数（DP 半減）

# 70B 構成 A
TENSOR_MODEL_PARALLEL_SIZE=6
PIPELINE_MODEL_PARALLEL_SIZE=16
DATA_PARALLEL_SIZE=144

NNODES=13,824  # 同じ

--num-layers 80
--hidden-size 8192
--num-attention-heads 64
--seq-length 2048
--micro-batch-size 1
--global-batch-size 1008  # 144 × 7

Option B: ノード数増加（DP 維持）

# 70B 構成 B
TENSOR_MODEL_PARALLEL_SIZE=6
PIPELINE_MODEL_PARALLEL_SIZE=16
DATA_PARALLEL_SIZE=288

NNODES=27,648  # 2倍

--global-batch-size 2016  # 維持

Option C: PP=12 でバランス

# 70B 構成 C (効率重視)
TENSOR_MODEL_PARALLEL_SIZE=6
PIPELINE_MODEL_PARALLEL_SIZE=12
DATA_PARALLEL_SIZE=192

NNODES=13,824  # 同じ

項目	計算
Layers/stage	80 / 12 ≈ 7 layers
Params/node	70B / 6 / 12 ≈ 972M
メモリ	~10-11 GB ✓
Pipeline bubble	PP=12 < PP=16 で改善

構成比較

構成	TP	PP	DP	ノード数	メモリ/node	Pipeline効率	スループット
13B (現行)	6	8	288	13,824	4 GB	高	基準
70B-A	6	16	144	13,824	9 GB	中	0.5x
70B-B	6	16	288	27,648	9 GB	中	1x
70B-C	6	12	192	13,824	11 GB	高	0.7x

Pipeline Bubble 分析

Bubble ratio ≈ (PP-1) / (PP-1 + num_micro_batches)

13B (PP=8):
  grad_acc = 7
  bubble = 7 / (7 + 7) = 50%

70B-A (PP=16):
  grad_acc = 7 (GBS=1008, DP=144, micro=1)
  bubble = 15 / (15 + 7) = 68% ← やや悪化

70B-C (PP=12):
  grad_acc = 7 (GBS=1344, DP=192, micro=1)
  bubble = 11 / (11 + 7) = 61% ← 改善

Bubble 改善策

# Micro-batch を増やす (メモリ余裕あり)
--micro-batch-size 2

70B-C (PP=12, micro=2):
  grad_acc = 1344 / (2 × 192) = 3.5 → 4
  bubble = 11 / (11 + 8) = 58%

メモリ詳細 (70B-C: PP=12, TP=6)

Params/node: 70B / 6 / 12 = 972M

┌─────────────────────────────────────────────────────────────┐
│ 32 GB HBM                                                    │
├──────────┬──────────┬────────────┬────────┬────────┬────────┤
│ Weights  │ Gradients│ Activations│ Comm   │ Other  │ Free   │
│ 3.9 GB   │ 3.9 GB   │ 2.5 GB     │ 0.5 GB │ 0.5 GB │ 20.7GB │
└──────────┴──────────┴────────────┴────────┴────────┴────────┘

Activation 内訳 (7層/stage, checkpoint OFF):
  QKV:      3 × 1 × 2048 × 1365 × 4 = 33 MB/layer
  Attn:     64/6 × 2048² × 4 = 178 MB/layer
  FFN:      1 × 2048 × 4779 × 4 = 39 MB/layer
  -----------------------------------------
  1層:      ~250 MB
  7層:      ~1.75 GB

通信量比較

通信	13B	70B	増加率
TP AllReduce/layer	84 MB	134 MB	1.6x
PP P2P/micro	42 MB	67 MB	1.6x
DP AllReduce	1.07 GB	3.9 GB	3.6x

DP AllReduce が支配的になる
→ カスタム AllReduce (my_mpi_allreduce_utofu) の重要性増大

学習時間予測

同一トークン数 (400B tokens) の場合

計算量:
  13B:  ~6 × 13B × 400B = 31.2 ZFLOPs
  70B:  ~6 × 70B × 400B = 168 ZFLOPs (5.4倍)

13,824 ノードで比較:
  13B:  T 時間 (DP=288)
  70B-C: 5.4倍計算 / (DP=192/288) × 通信オーバーヘッド
       ≈ 5.4 × 1.5 × 1.2 ≈ 9.7倍

70B-C で 70B を学習: 約 10倍 の時間

27,648 ノード (2倍) の場合

70B-B (DP=288):
  5.4倍計算 / 2倍ノード × 通信 ≈ 3-4倍 の時間

最終推奨

� 70B 推奨構成

# 70B 最適構成
TENSOR_MODEL_PARALLEL_SIZE=6
PIPELINE_MODEL_PARALLEL_SIZE=12
DATA_PARALLEL_SIZE=192
NNODES=13824

--num-layers 80
--hidden-size 8192
--num-attention-heads 64
--seq-length 2048
--micro-batch-size 2
--global-batch-size 1536  # 192 × 2 × 4

# Checkpoint activation: 全 OFF 可能（メモリ余裕）
# → Forward 再計算なしで高速化

項目	値
メモリ使用	~11 GB / 32 GB (34%)
Pipeline bubble	~58%
DP効率	192/288 = 67%
総合効率	~40-45% (推定)

まとめ

モデル	ノード数	実現可能性	効率
13B (現行)	13,824	✅ 実績あり	高
70B	13,824	✅ 余裕あり	中-高
120B	13,824	⚠️ ギリギリ	低
120B	27,648+	✅ 推奨	中

70B は現行ノード数で十分実現可能で、メモリに約20GB の余裕があります。 seq_len 拡張や micro-batch 増加の余地も十分あります。

30B どうでしょう

30B モデル - 現行構成でほぼそのまま！

13B → 30B のスケーリング

項目	13B	30B	倍率
パラメータ数	13B	30B	2.3x
Layers	40	48-56	1.2-1.4x
Hidden size	5184	7168	1.38x
Attention heads	36	56	1.56x

30B 構成例:
  56 layers × 12 × 7168² ≈ 34.5B
  または
  48 layers × 12 × 7680² ≈ 34B

現行構成 (TP=6, PP=8, DP=288) で検証

30B / 6 / 8 = 625M params/node

項目	13B (現行)	30B	増加
Params/node	268M	625M	2.3x
Weights	1.07 GB	2.5 GB	2.3x
Gradients	1.07 GB	2.5 GB	2.3x
Activations	1.4 GB	2.5 GB	1.8x
通信/その他	1 GB	1.2 GB	-
合計	~4.5 GB	~8.7 GB	1.9x

8.7 GB / 32 GB = 27% 使用率

� 現行構成そのままで余裕！！

30B 推奨構成

� Option A: 完全同一構成

# 30B - 現行構成そのまま！
TENSOR_MODEL_PARALLEL_SIZE=6
PIPELINE_MODEL_PARALLEL_SIZE=8
DATA_PARALLEL_SIZE=288
NNODES=13,824  # 変更なし

--num-layers 56
--hidden-size 7168
--num-attention-heads 56
--seq-length 2048
--micro-batch-size 1
--global-batch-size 2016  # 変更なし

メモリ図解

32 GB HBM
┌────────────────────────────────────────────────────────────────┐
│████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░│
│     ~9 GB                        ~23 GB 空き！                 │
└────────────────────────────────────────────────────────────────┘

さらなる最適化の余地

Option B: Micro-batch 増加

--micro-batch-size 2  # または 4

Activation: 2.5 GB × 2 = 5 GB
合計: ~11 GB / 32 GB ✓

利点: スループット向上、Pipeline bubble 削減

Option C: Checkpoint Activation 完全 OFF

# 全 stage で checkpoint OFF
# 現行は後半4 stageのみ OFF

全 OFF の場合:
  Activation: ~2.5 GB (再計算なし)
  Forward 高速化: ~20-30%

Option D: Sequence Length 拡張

--seq-length 4096  # 2倍

Activation 増加: ~2倍
  2.5 GB → 5 GB
合計: ~11 GB / 32 GB ✓

# さらに 8192 も可能
--seq-length 8192
  Activation: ~10 GB
  合計: ~16 GB / 32 GB ✓

全構成比較

モデル	TP	PP	DP	ノード	メモリ	構成変更
13B (現行)	6	8	288	13,824	4.5 GB	-
30B	6	8	288	13,824	9 GB	なし！
30B + seq4K	6	8	288	13,824	11 GB	seq のみ
30B + seq8K	6	8	288	13,824	16 GB	seq のみ
70B	6	12	192	13,824	11 GB	PP,DP変更
120B	6	20	288	34,560	11 GB	PP,ノード増

学習時間比較

同一トークン数 (400B) の場合:

計算量比: 30B / 13B = 2.3x
構成同一なので通信パターン同じ

予測: 30B は 13B の約 2.3-2.5倍 の学習時間

結論

┌─────────────────────────────────────────────────┐
│                                                 │
│   30B は現行構成 (TP=6, PP=8, DP=288) で       │
│   そのまま学習可能！                            │
│                                                 │
│   メモリ使用率: わずか 27%                      │
│   空き容量: 23 GB                               │
│                                                 │
│   さらに seq_len 8K まで拡張可能               │
│                                                 │
└─────────────────────────────────────────────────┘

13B の学習スクリプトのモデルサイズ部分を変えるだけで 30B が学習できます。富岳チームが 13B を選んだのは、目標性能とのバランスだったと思われますが、ハードウェア的にはもっと大きなモデルも可能でしたね。