サイバーエージェントのLLM開発を支えるプライベート機械学習基盤の運用の取り組み

Cloud Operator Days Tokyo 2024 (CODT'24) の Closing Keynote の発表資料です。

サイバーエージェントの機械学習基盤 ML Platform の概要と、LLM学習のために開発した分散学習サービス Distribtued の開発、運用について話しました。

Transcript

1. サイバーエージェントの LLM開発を支える プライベート機械学習基盤の運用の取り組み CyberAgent group Infrastructure Unit 青山 健人 (Kento Aoyama) 2024.09.06 Cloud Operator Days Tokyo 2024
2. 4 目次
 1. サイバーエージェントの機械学習基盤の紹介 2. LLM 開発と分散学習基盤への挑戦 3. 今後の取り組み 
 2
3. 青山 健人 − Kento Aoyama • 株式会社サイバーエージェント グループIT推進本部 CIU (CyberAgent group Infrastructure Unit) 所属 • 前職は東京工業大学の研究員（ HPC / Container） • 機械学習基盤 ML Platform の開発・運用を担当 自己紹介 @ meta1127 3
4. 1 ｜ 
 サイバーエージェントのプライベート機械学習基盤 4
5. 5 サイバーエージェントの主要事業と関連会社 5 主な事業 • メディア事業（ e.g. ABEMA) • 広告事業 • ゲーム事業（ e.g. Cygames） • その他 CIU（CyberAgent group Infrastructure Unit）は、 CyberAgentグループ全体のインフラを支える組織です Cycloud というブランドでプライベートクラウドを展開しており、 IaaSとしてのOpenStackやKaaSであるAKEなど様々なサービスを提供しています
6. 機械学習基盤 ML Platform 6 • CIU が開発する社内向け機械学習基盤のサービス総称 ◦ Notebook インスタンスのお手軽な作成 ◦ 任意イメージの GPU コンテナのデプロイ ◦ 機械学習ジョブ基盤 /推論基盤, etc. • 社内の ML/DS エンジニア向けに開発 ◦ プロダクト開発・運用コストの削減 ◦ GPU 利用ハードルの低減と導入の推進 ◦ パブリッククラウドの GPU 不足の回避
7. 最近の関連プレスリリース 7 大規模なAI開発に対応する「NVIDIA DGX H100」を国内初導入 80基の「NVIDIA H100 Tensor コア GPU」でAI開発を大幅強化、 機械学習モデルの大規模化・構築の高速化 へ 独自の日本語 LLM（大規模言語モデル）のバージョン 3を一般公開 225億パラメータの商用利用可能なモデルを提供
8. 8 ML Platform の計算機システム情報 8 vCPU 約 12,000 Cores NFS ストレージ 約 250 TB オブジェクトストレージ 約 400 TB GPU ❏ NVIDIA H100 x 80 ❏ NVIDIA A100 x 100+ ❏ その他モデル x 100+ 外部ネットワーク 50 Gbps (Bonding 25GbE) インターコネクト 400 Gbps (ConnectX-7) x 8 * * H100 GPU ノード専用インターコネクト
9. ML Platform 上の各サービスについて 9 サービス名 概要 GPUaaS (GPU as a Service) GPU + Kubernetes 基盤かつ、マネージド JupyterNotebook 基盤 ダッシュボード、プロジェクト管理、認証情報管理や NFS 管理の機能など AI Platform Training 機械学習ジョブの実行基盤 Kubeflow のオペレーターによるジョブ実行、 Katib による HPO 等 AI Platform Prediction 機械学習サービスの推論基盤 Kserve による推論サービス提供、グローバルエンドポイントのサポート等 Distributed 分散学習ジョブの実行基盤 MPI-Operator による MPI/NCCL を利用した並列計算ジョブの実行
10. ML Platform のシステム基盤と提供サービス 10 • GPU 搭載ノード上に構成された Kubernetes クラスタ GPU as a Service (GPUaaS) の上で各サービスを提供 Storage 機械学習ジョブ・推論 
 DGX A100 
 GPU Server 分散学習
 GPUaaS（Kubernetes） Distributed AI Platform Training AI Platform Prediction GPU 環境提供基盤 
 親鳥
11. 　　　　　　 11 LLM 開発と 分散学習基盤への挑戦 
 分散学習基盤への挑戦と、運用上の課題や取り組み 2 ｜ 

12. • 近年の機械学習モデルのパラメータ数は増加傾向にあり 1ノードのGPUではメモリ量が不足 • 特に 大規模言語モデル（ LLM）では更に顕著な傾向があり、 複数ノードの分散学習によるモデル /データ並列等の工夫が必須 4 LLM 開発と分散学習基盤の背景 12 A. Gholami, et al. "AI and Memory Wall," in IEEE Micro, vol. 44, no. 3, pp. 33-39, 2024, doi: 10.1109/MM.2024.3373763
13. LLM の開発基盤を構築するために何が必要なのか 13 国内においても LLM の開発競争が激化 「LLM の開発が可能な分散学習基盤をオンプレ環境で構築する」 ために インフラチームが必要な作業は何か • GPUサーバやNIC等の見積もり、納入計画、 etc. • DC ネットワークの設計、ラックの電力設計、 etc. • 分散学習環境をユーザに提供するためのサービスの設計、開発、そして運用 ML Platform 上で分散学習用の新規サービス “Distributed” の開発
14. 14 ML Platform Distributed 14 大規模モデル向け分散学習基盤 • ノード間並列分散学習ジョブの実行サービス ◦ NVIDIA H100 GPU のみ利用可能 ◦ MPI-Operator による MPIJob の分散実行をサポート • ノード間の RDMA 通信をサポート ◦ RoCEv2 を利用した Pod 間の高速な通信が可能 ▪ SR-IOV Network Device Plugin + SR-IOV CNI + Multus CNI • Kueue によるクォータ管理とキューイングを採用 • GUI と 独自 CLI ツールから操作可能 Kueue
15. 15 MPI Operator による MPI/NCCL 環境のデプロイ 15 MPI Operator • kubeflow/mpi-operator • Kubernetes 上で MPI による計算を実現するための OSS ◦ カスタムリソース MPIJob による MPI 環境の定義、デプロイが可能 ◦ Launcher / Worker の設定を定義すると、それぞれ Pod として実行される • OpenMPI / IntelMPI をサポート ◦ バックエンドの通信は NCCL も可能 • mpirun コマンド等を直接利用しない分散フレームワークの場合でも、 バックエンドが NCCL 通信に対応していれば利用可能 ◦ e.g. deepspeed, accelerate, torch.distributed, etc.
16. 16 Kueue によるリソース管理とキューイング 16 Kueue • kubernetes-sigs/kueue • Kubernetes リソースのキューイングを提供する OSS ◦ クラスタで定義されたクォータに基づいてキューイング可能 ◦ 順序保証付きのキューイングが可能 ◦ クォータの設定次第でリソースの Preemption 等も有効化可能 • テナントごとに利用可能なフレーバー（ e.g. GPUモデル）やリソースの総量を制限可能 • MPIJob の場合は Labels に紐付けるキューの名前を指定すると対象のキューに入る ◦ kueue.x-k8s.io/queue-name=hogehoge
17. 17 プロジェクト単位のクォータ管理の例 17 • ClusterQueue で各プロジェクトで利用可能な ResourceFlavor を定義する ◦ 各テナントで利用可能なリソース（ e.g. GPUモデル種別、 GPU枚数）を制御可能 ClusterQueue A ResourceFlavor: H100 ResourceFlavor: A100 ResourceFlavor: CPU ClusterQueue B ResourceFlavor: A100 ResourceFlavor: CPU Node A H100 GPU Node B H100 GPU Node C Label: A100 A100 GPU Node D Node E Label: H100 Label: CPU
18. ML Platform の分散学習基盤サービス Distributed は • MPI-Operator による MPI を利用する分散実行ジョブのサポート • SR-IOV, Multus を活用した RoCEv2 による高速な通信をサポート • Kueue によるフレーバー単位のクォータ管理とキューイング などの OSS を最大限に活用してサービスの開発を行った ノード間の疎通確認、 NCCL通信の動作検証、想定フレームワークの動作確認、 テストデータの計測等が完了、無事にリリースしてユーザに提供開始 ... と思いきや 18 分散学習基盤の開発、リリース、そして運用へ … 18
19. H100 GPU ノードすべてを利用した分散学習でトラブル発生 • ML Platform 上の H100 GPU ノードは NVIDIA 社製 DGX H100 と 某D社製 HGX H100 の筐体の両方が存在する • 複数ベンダーの H100 マシンが混在する環境で RDMA通信に失敗する現象 に遭遇 • DGX 同士、HGX 同士の通信では問題が発生しない • リリース当初の検証では HGX のみの環境のため問題が顕在化せず • 当然、それぞれのベンダーのサポート対象外 19 分散学習基盤の運用上のトラブルについて 19 DGX1 H100 GPU NIC DGX2 H100 GPU NIC HGX1 H100 GPU NIC HGX2 H100 GPU NIC OK OK NG
20. • 関連する可能性のある様々なミドルウェアの更新や設定の確認 ◦ 各ベンダーのファームウェアの更新、設定の見直し ◦ NIC/GPU 等のファームウェア /ドライバ/カーネルモジュールの更新や設定の見直し ◦ 関連ドキュメントやマニュアルの読み漁り ... 臨時の原因究明チームを組み、根気強く調査を続けた結果、 片方の環境で NIC (ConnectX-7) の Adaptive Routing の設定が不整合な状態 であることが判明 20 分散学習基盤のトラブルシューティング (1/2) 20 H100 Node H100 GPU NIC-1 H100 GPU H100 GPU H100 GPU H100 GPU H100 GPU H100 GPU H100 GPU NIC-0 NIC-2 NIC-3 NIC-4 NIC-5 NIC-6 NIC-7 NIC-8 NIC-9 adaptive_routing_forced_en=0x1 想定していないデバイス
21. • 不整合な状態の原因は設定スクリプトのミス ◦ HGX環境とDGX環境でOS上で見える ConnectX-7 デバイスの本数が異なり、 設定対象の NICの範囲指定に誤りがあったのに気付かなかった • Adaptive Routing の設定を統一すると 混在環境でも問題なく RDMA 通信が行えるように ◦ 副次効果として、設定項目の見直しにより多少の通信性能の向上が見られた 21 分散学習基盤のトラブルシューティング (2/2) 21 H100 Node H100 GPU NIC-1 H100 GPU H100 GPU H100 GPU H100 GPU H100 GPU H100 GPU H100 GPU NIC-0 NIC-2 NIC-3 NIC-4 NIC-5 NIC-6 NIC-7 NIC-8 NIC-9 adaptive_routing_forced_en=0x1
22. • 動けばOKではない、 分散学習基盤としての性能検証 が必要 ◦ 事前に十分な検証期間を確保して性能測定が必要 • 複数ベンダー混在環境 は予想外の落とし穴 がある ◦ ベンダーサポートを受けられない範囲は自己責任 ◦ 一つ一つ根気強く仮説・検証作業をするしかない • 地道に社内に知見を蓄積していくしかない ◦ 同じ轍を踏まないためにトラブル解決の記録は文書として残しておく ◦ ベンダー提供の HPC向けの設定は参考になる ▪ 今回の HGX マシンは素の Ubuntu から我々が環境構築を行った ▪ DGX を参照設定として設定項目の見直しができた 22 分散学習基盤サービスの開発と運用から得た学び 22
23. • 計算基盤の運用として GPU 等の計算リソースの利用率監視や最適化施策も行っています ◦ JupyterNotebook カーネルの動的なインスタンス割り当て機能の実装 ◦ Training のジョブ形式の普及推進、インスタンスの有効期限の設定 ◦ ユーザ向けの利用率アラート , Slack 通知機能, etc. 23 機械学習基盤の運用 : 計算リソースの最適化施策 23 GPU モデル別の利用率（ Utilization） の監視
24. 　　　　　　 24 まとめ 
 3 ｜ 

25. • サイバーエージェントではプライベートな機械学習基盤 ML Platform を開発・運用中 • LLM 開発のための分散学習基盤サービスは様々な OSS を積極的に活用して構築した • サービスとして必要な機能は Upstream に取り込めるように OSS 活動等を行っている 今後の取り組み • Kueue によるクォータ管理の ML Platform 全サービスへの展開 • Preemption 導入 / カーネル分離等の推進による計算リソース利用の最適化 • Topology-Aware Scheduling 等のスケジューリング最適化 , etc. 機械学習基盤や分散学習基盤の開発運用に興味のある方は是非お声掛けください！ 4 全体のまとめ 25
26. Appendix ｜ 補足情報 
 26
27. DCネットワーク周辺 や Distributed の詳細 27 DCネットワーク関連の発表 @ JANOG52 https://www.janog.gr.jp/meeting/janog52/aiml400/ ML Platform Distributed 関連の発表 @ CADC2023 https://cadc.cyberagent.co.jp/2023/sessions/distributed-ml -with-kubernetes/
28. • ML Platform 全体 で Kueue によるクォータ管理に対応する ◦ 現状は Distributed + 一部 H100 GPU 利用サービスのみ対応 ◦ すべてのサービスの Kueue 対応には既存サービスの改修や運用形態の変更が必要 ▪ Kueue の Integration 対象外のリソースでは Plain Pod Integration を利用する 28 今後の取り組み : Kueue によるクォータ管理の浸透 28 サービス名 概要 GPUaaS (GPU as a Service) ✔ 対応済み（従来方式と併用） AI Platform Training 将来対応（次期バージョンで Kubeflow Integration を対応予定） AI Platform Prediction 将来対応（Plain Pod Integration による対応を予定） Distributed ✔ 対応済み
29. ML Platform 上の並列分散環境の構築に向けて 29 従来の ML Platform の機械学習基盤について整理 • 単一の Kubernetes クラスタで、すべての GPU/CPU ノードを管理 • Namespace 単位のマルチテナント環境 • 様々なワークロードが同じクラスタ上に混在 ◦ JupyterNotebook, Training Job, Inference Instance, etc. • クォータ管理は存在しない（一部例外あり） • キューイングを実現する機能はない（ k8s のデフォルト挙動） → 同じ Kubernetes クラスタ上で LLM 開発を実施する特定のテナントにのみ、 高速なノード間通信が可能な特定のノードを占有させたい
30. ML Platform 上の並列分散環境の構築に向けた要件 30 • 新規サービスに必須な要件 ◦ RoCEv2 による高速なノード間通信 が利用可能である ▪ RoCE: イーサネット上で RDMAによる高速な通信を実現するプロトコル ◦ MPI, NCCL 等の通信規格と 主要な分散フレームワーク に対応している ▪ MPI, NCCL: 分散学習のプロセス間通信で主に利用される規格 /ライブラリ ◦ クォータ管理 に基づいた キューイング が可能である • 必須ではないが欲しい項目 ◦ 継続的なメンテナンス がしやすい（技術的負債にならない） ▪ 普及した/見込みのある OSS を積極的に利用する
31. • RoCEv2 による高速なノード間通信が利用可能である ◦ SR-IOV Network Device Plugin + SR-IOV CNI + Multus CNI • MPI, NCCL 等の通信方式の分散フレームワークに対応している ◦ MPI Operator • クォータ管理に基づいたキューイングが可能である ◦ Kueue 技術選定の基準 • （可能な限り） Kubernetes 上のコンポーネントとして完結する • 標準化が進められている or 利用実績が豊富 • チームとして OSS の変更についていける / 必要に応じて upstream に貢献できる こと OSS の採用と選定基準について 31
32. 32 ML Platform Distributed のアーキテクチャ概略 32
33. 33 Distributed / MPIJob のリソース定義の例 33 • Distributed ではサーバがリクエストを元に MPIJob リソースを作成 /削除する • CLI または 定義ファイルから MPIJob を作成可能 name: pi-example # ジョブの名前 image: mpioperator/mpi-pi:openmpi # コンテナイメージの指定 sshAuthMountPath: /home/mpiuser/.ssh # SSH鍵をマウントするパス runAsUserId: 1000 # コマンドを実行するユーザのUID launcherSpec: commands: # launcher の実行コマンド - mpirun args: # launcher のコマンド引数 - /home/mpiuser/pi machineType: ml-standard-2 # worker の machineType workerSpec: commands: # worker の実行コマンド - /usr/sbin/sshd args: # worker のコマンド引数 - -De - -f - /home/mpiuser/.sshd_config machineType: ml-h100-80gb-1g # worker の machineType workerReplicas: 3 # worker のレプリカ数 slotsPerWorker: 1 # worker あたりの slots 数の指定 apiVersion: kubeflow.org/v2beta1 kind: MPIJob metadata: name: pi-example ... spec: mpiReplicaSpecs: Launcher: replicas: 1 template: spec: containers: - name: launcher command: - mpirun args: - /home/mpiuser/pi image: mpioperator/mpi-pi:openmpi ... Worker: replicas: 3 template: spec: containers: - name: worker resources: requests: cpu: "50" memory: 200Gi nvidia.com/gpu: 1 ... シンプルな設定から MPIJob の定義を作成可能 • 利用イメージ、コマンド、リソース、並列化の設定など
34. 34 Kueue によるキューイングの概要 34 • Workload: キューイングされた Job の状態を管理するリソース • LocalQueue: テナント内の Workload を管理するリソース • ClusterQueue: リソースのクォータ設定などを定義するリソース • ResourceFlavor: リソース種別を定義するリソース ClusterQueue ResourceFlavor: H100 MPIJob A LocalQueue ResourceFlavor: A100 ResourceFlavor: CPU Workload Namespace A MPIJob B LocalQueue Workload Namespace B MPIJob A: OK MPIJob B: NG kueue.x-k8s.io/queue-name kueue.x-k8s.io/queue-name