生成AIゼミで使用したスライド

生成 A I ゼミ 片桐・星野研究室 M1 林 俊一郎 2025年 5月

用語確認 生成AIを構造的に分類 ① Transformer ・LLM ・音声生成 ・LLM ・動画生成 ・画像生成 GPT 拡散モデル Transformer ② Diffusion(拡散)モデル ・画像生成 ③ DiT(① + ② - U-Net) ・動画生成 生成AI ・CNN (画像分類) ・線形回帰 深層モデル 機械学習 AI ・群知能 例：アリ

LLM Attention層 １層 例：80層（Llama3.3 70B） U-Netと異なり，各層の構造は全く同じ HPCの分散並列向き MLP層 正規化 Attention層 https://www.youtube.com/watch?v=mmWuqh7XDx4&t=982s MLP層は活性化関数を一回通すだけの 一般的な２層パーセプトロン(※MoEは例外) FFN層 正規化

• https://www.youtube.com/watch?v=mmWuqh7XDx4&t=982s

LLMモデルの重みの 各GPUへの分割手法 ①PP：パイプライン並列 ②TP：Tensor並列 ③DP：データ並列 ←重みに限らず最適化関数の状態や勾配の分散

①PP：パイプライン並列

Megatronモデルの重み分割① パイプライン並列(PP) 例：80層（Llama3.3 70B） ⇩ 前半40層と後半40層を別のノードに 40層 Attention層 MLP層 正規化 ・ ・ ・ 垂直分割といわれる 40層 Attention層 FFN層 正規化

PPの注意点 学習ではパイプラインBubbleが発生 ある時刻:tで GPUは ・上1基 ・下3基 以外遊んでる 対策： マイクロバッチで Bubbleを軽減 https://research.google/blog/introducing-gpipe-an-open-source-library-for-efficiently-training-large-scale-neural-network-models/

• https://research.google/blog/introducing-gpipe-an-open-source-library-for-efficiently-training-large-scale-neural-network-models/

最適化の例 Deepseek https://github.com/deepseek-ai/DualPipe

• https://github.com/deepseek-ai/DualPipe

LLMの規模感 例：Llama3.3 70B 8bitの型でサイズは70GB 16bit (BF16)では140GB 不老のV100は1基につきVRAM 32GBなので 1ノード(4基)＝128GBに収まらない ⇩ マルチノードでのモデル分割が必要 高速な推論にはこの重みが全て GPUメモリ内に収まる必要がある 例：重みの半分をCPUにオフロードした場合 スループットは1/100未満に

②TP：Tensor並列

Megatronモデルの重み分割② Tensor並列(TP)：各層内部での重み水平分割 Attention層 MLP層 正規化 https://www.researchgate.net/figure/The-model-parallelism-strategy-proposed-in-Megatron-LM-paper-28-effectively-reduces-the_fig2_382459921

• https://www.researchgate.net/figure/The-model-parallelism-strategy-proposed-in-Megatron-LM-paper-28-effectively-reduces-the_fig2_382459921

片方のノードに注目 TPによって 70GB ÷ 4GPU = 17.5GB < 32GB(1基のV100)に収まる https://icts.nagoya-u.ac.jp/ja/sc/overview.html

• https://icts.nagoya-u.ac.jp/ja/sc/overview.html

×重みだけGPUメモリに収まれば良い の場合 CUDA Graphで約１割 32 GB × 0.9 = 29 GBしか使えない KVキャッシュは全GPUで同じサイズのコピーを持つ コンテキスト長の上限と スループットを上げるための同時バッチ処理数の制約になる

Tensor並列(TP)の注意点 ノードをまたぐTPでは高速通信 InfiniBandが必須 PP・TPの vLLM Blog Llama3.1 (405B) 2 ノードで 計 16 GPUのH100で推論 https://blog.vllm.ai/2024/07/23/llama31.html

• https://blog.vllm.ai/
• https://blog.vllm.ai/2024/07/23/llama31.html

③DP：データ並列 重みに限らない最適化関数の状態や勾配の分散

③データ並列：DP 例: Adam等の最適化関数の状態や勾配を分散 DeepSpeed AIが提案したZeROデータ並列が有名 アニメーションでDeepSpeed (ZeRO1)の仕組みを完全に理解する https://zenn.dev/turing_motors/articles/d00c46a79dc976 DDP⇨単に勾配だけを AllReduce ZeRO stage 1⇨状態 stage 2⇨勾配 stage 3⇨重み …までを分散

• https://zenn.dev/turing_motors/articles/d00c46a79dc976

ZeRO 3 の注意点 ⇨重みも垂直に分割する TPとは併用できる（Zero3で分割後TP） PPとの併用は複雑になる割にメリットが薄い

モジュール単位の最適化 Flash Attention GPT-2での処理速度は約3倍 Flash Attention-2 ↑の約2倍高速 A100 理論性能の順伝播：73%，逆伝播：63%（※H100では35%） Flash Attention-3 H100 理論性能の75%

FlashAttention ＝ループ＋ GPU内のSRAM の最適化 https://www.youtube.com/watch?v=mmWuqh7XDx4

• https://www.youtube.com/watch?v=mmWuqh7XDx4

FlashAttention ＝ループ＋GPU内のSRAM の最適化

学習プラットフォーム選定

LLMの全体像 RFHL：強化学習アルゴリズム SFT DPO PPO GRPO(汎化) TRL 微調整 事後学習 量子化 蒸留 GGUF・AWQ等 事前学習 重み等の公開 新アーキテクチャ ・MoE ・マルチモーダル Transformer ・合成データ ・報酬関数として フィードバック 推論 MCP通信 マルチエージェント・RAG 低ランク行列学習 Lora，QLora 混合精度 位置エンコード技術 トークナイザ 要変換 Megatron GPU分散 任意のアプリ EP(MoE並列) TP(Tensor並列) PP(パイプライン並列) パイプライン Bubble対策 ZeRO2 以降 PPで通信量が増加 分散 DP(データ並列) ZeRO1 ZeRO2 DDP(AllReduce) ZeRO3 Infinity FSDP(Pytorch) TP・PP でもなく各層の パラメータを複数のGPUに 分割する完全 シャーディング

データ並列：DP（再掲） 例: Adam等の最適化関数の状態や勾配を分散 DeepSpeed AIが提案したZeROデータ並列が有名 アニメーションでDeepSpeed (ZeRO1)の仕組みを完全に理解する https://zenn.dev/turing_motors/articles/d00c46a79dc976 DDP⇨単に勾配だけを AllReduce ZeRO stage 1⇨状態 stage 2⇨勾配 stage 3⇨重み …までを分散

• https://zenn.dev/turing_motors/articles/d00c46a79dc976

注意点 • 横田研の藤井氏が用いた Megatron-DeepSpeed リポジトリ ⇩ Megatron-LMのフォークで ・マルチモーダル ・MoE に非対応 ※2023年当時は最新の Megatron-Coreだった

SWIFT by Model Scope 先日AAAI で査読済み論文 としてアクセプトされた A Scalable lightWeight Infrastructure for Fine-Tuning

事前学習（≠追加学習） テキストであれば何でも良い NトークンからN個の ??? を同時に予測させることで効率化 https://www.youtube.com/watch?v=mmWuqh7XDx4

• https://www.youtube.com/watch?v=mmWuqh7XDx4

事後学習 DeepSeek-AIが編み出したGRPO(熟考モデル化) 各トークンごとに 学習せずに LLMの推論結果 Completions全体を 報酬関数で計算 バッチ推論で 数十倍高速に https://huggingface.co/docs/trl/grpo_trainer

• https://huggingface.co/docs/trl/grpo_trainer

評価側も同時に 学習が必要 ＝収束が遅い https://qiita.com/pocokhc/items/b50a56febeab2c990bea

• https://qiita.com/pocokhc/items/b50a56febeab2c990bea

注意点 • Megatron LMに対し，独立し新モジュールなどのアプデが途絶えた Megatron-DeepSpeed • DeepSeek-R1の強化学習：GRPOがトレンド TRL(Transformer Reinforce Learning)をimport • GRPO(やDPO)は1トークンごとの学習は行えず，入力に対する completion(回答)全体まで出力させて報酬関数に渡す バッチ推論の高速化がネック＝ の出番 • InfiniBand使える & H100ほど演算早くない ⇒PPよりTP使ったほうがシンプル（特に学習時のPPバブルを回避）

学習・推論・テスト環境別に ノードを分け同期する例 合成データセット作成

不老TypeⅡ上でリアルタイムに 3Dを採点(合成データも作成) ④高得点の生成コードは保存 (データセットやRAGで活用) 学習ノードにフィードバック MCP通信 ⓪初期データセットの作成 ④点数 ④ ①画像＋指示 ②3D生成コード ③+多視点スクショ Megatron TRL(GRPO) VLM学習ノード 3D可視化ノード VLM推論で3D採点ノード

④高得点の生成コードは保存 HPC-CUDA-Engineer(仮） Sakana AIの進化的最適化 ワークフローもDifyで組める データセット：要検討 教師あり・なし→両方可 MCP通信 ④点数 ④ ①指示 ②CUDA生成コード ③＋結果 Megatron TRL(GRPO) LLM学習ノード CUDA実行ノード 監査役：LLM推論ノード

現GitHubトレンド1位と4位のリポジトリ ※2025/4 時点 １位：Diff-synth studio(拡散モデル 例:DiTのWan2.1等 動画生成AI学習・推論プラットフォーム) ４位：SWIFT (Scaleable lightweight Infrastructure for Fine-Tuning) • LLMのマルチノード学習プラットフォーム(Python100%) • Web-UIサポート • Pretraining, Fine-tuning(Fullパラメータ・PEFT(Lora等))対応 • V100も明記されてる(他だとH100，A100前提のリポジトリも…) • vLLMを用いたGRPO • DeepSpeed zero3まで対応 • マルチモーダル対応 • 新モデルへのアプデが早い • 最近Megatron並列(PP,TP,SP,CP…)にも対応!（ただしVLMを除く↓対応モデル一覧） https://swift.readthedocs.io/en/latest/Instruction/Supported-models-and-datasets.html

• https://swift.readthedocs.io/en/latest/Instruction/Supported-models-and-datasets.html

•あ

•あ

Swift環境構築 • module load • gcc11.3 cuda12.1 • python3.11.7(default) • git clone https://github.com/modelscope/ms-swift.git • cd ms-swift • pip3 install -e .

他の学習・推論 プラットフォーム紹介

Open-R1 DeepSeek-R1は悪くないが VLM非対応 Open-R1をフォークした VLM-R1やV1-R等の GitHubリポジトリもあるが …△汎用性・将来性

Meta開発の推論プラットフォーム llama.cpp Ollama • MacやCPUでの推論に強い • .safetensorとは異なる重み データ格納方式.ggufを考案 • llama.cppのラッパー • 1ノード向け

量子化モデルの等，小規模なLLMの 推論・学習コード→Unsloth等が有名 • やや小型向けのファインチューニングをGoogleColabで使える 形で提供。大抵の最新モデルの量子化GGUF版も即日リリース

をHPCに入れる 学習・推論・3Dソフト等の実行ノード間のMCP通信のHubとして

コンテナの基本知識 Docker Kubernetes (k8s) • 開発環境 • コンテナの一種 • 複数のコンテナは docker_compose.yamlで管理 • 本番環境へのデプロイ • マルチコンテナの自動管理

不老の環境 RHLE7 ＝やや古い→cgroup v2に対応していないせいで コンテナやk8s系のツールが壊滅的 Singularity＝HPC版のdocker ※Singularity Composeは機能が少なすぎ sudo(管理者権限コマンド)は使えない ソースコードをwgetやgitで入手してmake後 …/ユーザ名/モジュール名/binに配置し export PATH= …/ユーザ名/モジュール名/bin:${PATH} 等とすれば使えるものもある

結論 不老でユーザ権限でsingularity 以外のコンテナを動かすのは無理

Docker Composeに困り…累計１週間浪費 • 約２日 Singularity Compose→機能不足でyaml書き変えを断念 • 約１日 singularity-CRIのバイナリインストール成功※sykube以外× • 約１日 sykubeのバイナリインストール断念(要sudo) • 約１日 RootLess Docker→Cgroup v2(RHLE 8～対応) • ↑Userneteが使用 • ↑ k3sが使用 • Singularity使わない前提でminikube • Podmanってオープンソースでユーザ権限で使える!?構築でハマる→remoteのみイ ンストール=deamonを別で用意する必要あり ※RHEL8推奨だと実感 約１日 OpenShift v4.1(それ以降はRHLE7非対応) https://docs.redhat.com/ja/documentation/red_hat_container_development_kit/3.13/html /getting_started_guide/converting_an_existing_docker_compose_project#using-kompose

• https://docs.redhat.com/ja/documentation/red_hat_container_development_kit/3.13/html/getting_started_guide/converting_an_existing_docker_compose_project

Podman Composeは失敗 $ podman compose up -d Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: Get "http://d/v5.4.1/libpod/_ping": dial unix /run/user/19623/podman/podman.sock: connect: no such file or directory [@flow-cx05 docker]$ ^C [@flow-cx05 docker]$ podman machine init Looking up Podman Machine image at quay.io/podman/machine-os:5.4 to create VM Getting image source signatures Copying blob d982f2a01613 done | Copying config 44136fa355 done | Writing manifest to image destination d982f2a01613fbd566d81266a619f7bad958268def3a3f924a8e209f48578d75 Extracting compressed file: podman-machine-default-amd64.qcow2: done Error: exit status 1 [@flow-cx05 docker]$ podman machine start Error: podman-machine-default: VM does not exist

OpenShift 商用ライセンス不要な上流ブランチ：OKD 3.11 https://github.com/openshift/origin https://qiita.com/pocokhc/items/b50a56febeab2c990bea

• https://github.com/openshift/origin
• https://qiita.com/pocokhc/items/b50a56febeab2c990bea

OKD 3.11のインストール wget https://github.com/openshift/origin/releases/download/v3.11.0/openshift-originclient-tools-v3.11.0-0cbc58b-linux-64bit.tar.gz ocとkubectlをhome/ユーザID/bin直下にコピー [@flow-cx05 ~]$ chmod +x $HOME/bin/oc $HOME/bin/kubectl [@flow-cx05 ~]$ oc version oc v3.11.0+0cbc58b kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO [@flow-cx05 ~]$ kubectl version error: no configuration has been provided（←問題なし）

• https://github.com/openshift/origin/releases/download/v3.11.0/openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit.tar.gz

マルチコンテナ運用のデファクトである Kubernetesと比較 OKD3.11 Kubernetes ローカル(1ノード)→MiniShift ローカル(1ノード)→Minikube ※手元のPCでクラスターをテスト可

しかし，これも失敗 MiniShiftはハイパーバイザー上で動作 ⇨このハイパーバイザーが要sudo(管理者権限)

最後の希望 cgroup v1に唯一対応したrootlessコンテナ：LXC ⇨RHEL7.1で非推奨 https://rootlesscontaine.rs/how-it-works/cgroups/

• https://rootlesscontaine.rs/how-it-works/cgroups/

スパコン管理者に相談したところ ⇨Docker Composeなら Singularity で再現できますよね ※通信とか自分でsingularity用に修正すれば ToDo ① singularity build用の.defを複数書く ② Difyのdocker_compose.yamlを中心に再現 RHEL8(cgroup v1)未満のHPCのためだけに上記を行うのは… あと１年でアップデートされる不老でやるべきか迷った

GWのほとんどを費やし Singularityに変換成功 9個のコンテナのエラーメッセージを１つずつ潰していき 自作のrun_dify_sif.shの他 以下の２つのファイルを修正することで成功した ① dify/docker/.env ② dify/docker/nginx/default.conf.template https://github.com/langgenius/dify ※ChatGPT plusプランのo3を制限目前まで使うほど大変な課題だった

• https://github.com/langgenius/dify

Difyでワークフローを新規作成する様子

Difyの機能をテストしている場面

ToDo ①セキュリティに配慮し，TLS（HTTPS）に対応 ②RAG・プラグインなどの各機能をテスト ③最新版のDifyに対応(v1.3.0で開発済み) ④以下のGitHubリポジトリで公開 https://github.com/3dify-project/dify-singularity

• https://github.com/3dify-project/dify-singularity