# 1,000億パラメータ規模の独自LLM「PLaMo-100B」の事前学習 ## 要旨 [[Preferred Networks]]の子会社である[[Preferred Elements]]が、[[GENIAC]]のもとで開発した100Bパラメータ規模の[[PLaMo-100B]]について、2024年5月に完了した事前学習の設計と運用上の知見を報告した記事である。データ収集から事前学習までを自社で制御し、日本語と英語のテキストを合計2T token学習した。 ## 評価結果 | モデル | Jaster (4-shot平均) | MMLU (5-shot正解率) | | --- | ---: | ---: | | PLaMo-100B | 0.678 | 0.603 | | PLaMo-100B（指示学習済み、5/13暫定版） | 0.712 | 0.569 | | tokyotech-llm/Swallow-70b-instruct-v0.1 | 0.705 | 0.669 | | GPT-4 turbo | 0.772 | — | PLaMo-100Bの暫定指示学習版は、Jaster 4-shotではGPT-3.5 turboやSwallow-70bを上回った。一方、MMLUでは同規模のモデルに劣り、その理由の一つとしてBooks3を権利侵害の疑いから学習に使わなかったことを挙げている。評価値はPFE社内測定またはGENIAC内の評価値であり、単純な横比較には注意が必要である。 ## 学習データ 学習量は前半1.5T tokenと後半0.5T tokenに分け、データ比率を変更した。 | データ | 1.5T | 0.5T | | --- | ---: | ---: | | [[RefinedWeb]] | 42% | 17% | | その他英語データセット | 28% | 33% | | [[Common Crawl]]由来の日本語データセット | 18% | 46% | | その他日本語データセット | 12% | 4% | 英語データは1.3T token、日本語データは0.7T tokenである。日本語データについては、公開データセットを集めるだけでは十分な品質を確保しにくいとして、Common Crawlのウェブクロールから独自コーパスを構築した。 処理対象は2017〜2024年の20 dumpで、約460B tokenのデータセットを作成した。CCNetのWET処理ではHTMLやMarkdownの構造を失うため、WARCを直接扱う実装を選んだ。パイプラインは、WARCから日本語HTML・テキストを抽出し、HTMLをMarkdownへ変換し、[[llm-jp corpus filter]]でフィルタリングし、MinHashでdump横断の重複を除去し、均等サイズに再シャーディングする構成である。Common Crawlの分割はMinHash以外をほぼ完全並列化でき、1,000並列で処理した。 ## 学習安定化 PLaMo-100BのアーキテクチャはLlama 2・Llama 3にほぼ準拠しつつ、[[QK-Norm]]を導入した。QとKに正規化層を入れ、アテンション計算の安定化を狙う手法である。PFEの予備実験では性能低下が見られなかった。 ![[_attachments/plamo-100b/fig01-qk-normalization.png]] （QK Normalizationを付加したSelf Attentionレイヤ。） 損失関数には[[z loss]]を追加した。これはsoftmax cross entropyの数値安定性を狙う項であり、記事では次式を示している。 $L(x)=\left(\log\left(\sum_{i=0}^{C}\exp(x[i])\right)\right)^2$ z loss自体の学習安定化効果は切り分けられていないが、性能低下は確認されなかった。また、通常の損失や下流タスクよりも学習不調時の変化が大きいことがあり、学習状態を確認するメトリクスとして有用だった。 一方、PLaMo-13Bで採用していたParallel Layersは、開発が進むと性能劣化が目立ったためPLaMo-100Bでは採用しなかった。埋め込み出力の正規化はperplexityを改善したが、JSQuADのようなデコードを要するタスクを悪化させた。Sequence Length Warmupも、PFEの設定ではほぼ効果がなかった。 ![[_attachments/plamo-100b/fig02-transformer-layers.png]] （通常のTransformer層と、Self Attention・MLPを並列に計算する構成の比較。PLaMo-100Bでは通常の構造を採用した。） ## 学習高速化 100Bモデルの学習には、データ並列・テンソル並列・パイプライン並列を組み合わせる3D parallelismを使用した。[[パイプライン並列化]]では[[Zero Bubble]]を採用し、GPUが処理できないパイプラインバブルを減らした。 ![[_attachments/plamo-100b/fig03-pipeline-baseline.png]] （一般的なパイプライン並列化の実行例。青がForward、橙がBackward、淡色がOptimizer step。） ![[_attachments/plamo-100b/fig04-zero-bubble.png]] （Zero Bubbleの実行例。Forward・Backward・重み更新を組み合わせてバブルを埋める。） Zero Bubble論文の投機的なパラメータ更新は採用しなかった。Pythonスクリプト上のイテレーション境界が曖昧になりデバッグしにくいこと、gradient clippingが常に発生して投機実行が成功するイテレーションがほとんどなかったことが理由である。後者は論文の報告と異なり、モデルサイズの違いが原因と推測している。 lm-headは当初FP8で計算していたが、train lossに大きな問題がなくても下流ベンチマークの性能が悪化した。小規模実験でz lossがFP8使用時に非常に高くなることを確認し、lm-headの計算はBF16に戻した。 ![[_attachments/plamo-100b/fig05-z-loss-fp8.png]] （lm-headをBF16とFP8で計算した場合のz lossの比較。FP8では値が大きく上昇する。） 最終的に、PLaMo-100Bは540TFLOP/s/GPU程度を達成した。これはH100のFP8理論性能1979TFLOP/sの約27%に相当する。GPU数や測定条件は異なるが、記事はLlama 3やMosaicMLのベンチマークと比べても遜色ない性能としている。 ## 記事から得られる含意 - 大規模事前学習では、データの権利・構造・品質を制御するための独自データパイプラインが、モデル構造と同じく主要な開発資産になる。 - 学習安定化の手法は、単一の大規模ランで効果を厳密に切り分けにくい。再実験が現実的でない規模では、性能低下を避ける予防策と診断メトリクスを組み合わせる必要がある。 - 低精度化は層ごとに安全性が異なる。lm-headではtrain lossだけでは問題を検出できず、z lossと下流ベンチマークを併用してFP8の適用範囲を判断した。 - Zero Bubbleは理論上のバブル削減だけでなく、投機的更新を含む実装複雑性とのトレードオフを持つ。 ## 関連 - エンティティ: [[PLaMo-100B]] / [[Preferred Networks]] / [[Preferred Elements]] / [[GENIAC]] / [[NEDO]] / [[Common Crawl]] / [[RefinedWeb]] / [[llm-jp corpus filter]] - 概念: [[言語モデル事前学習]] / [[LLM分散学習]] / [[並列化戦略]] / [[パイプライン並列化]] / [[混合精度訓練]] / [[QK-Norm]] / [[Zero Bubble]] / [[z loss]] / [[LLM評価]] - 実装基盤: [[Megatron-LM]] / [[NVIDIA H100]] ## 出典 - [[.raw/articles/plamo-100b-2024-06.md]] - [Preferred Networks,「1,000億パラメータ規模の独自LLM『PLaMo-100B』の事前学習」](https://www.preferred.jp/ja/blog/tech/plamo-100b)