2024.09.06

Cloud Operator Days Tokyo 2024

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

CyberAgent group Infrastructure Unit

青山 健人 (Kento Aoyama)

目次

1. サイバーエージェントの機械学習基盤の紹介
2. LLM 開発と分散学習基盤への挑戦
3. 今後の取り組み

4
2

自己紹介

青山 健人 − Kento Aoyama●

株式会社サイバーエージェント
グループ IT推進本部
CIU (CyberAgent group Infrastructure Unit) 所属●

前職は東京工業大学の研究員（ HPC / Container）●

機械学習基盤 ML Platform の開発・運用を担当@ meta1127
3

1｜
サイバーエージェントのプライベート機械学習基盤

4サイバーエージェントの主要事業と関連会社

主な事業●

メディア事業（ e.g. ABEMA)

●

広告事業

●

ゲーム事業（ e.g. Cygames）●

その他

CIU（CyberAgent group Infrastructure Unit）は、CyberAgentグループ全体のインフラを支える組織です
Cycloud というブランドでプライベートクラウドを展開しており、IaaSとしての OpenStackやKaaSであるAKEなど様々なサービスを提供しています5機械学習基盤 ML Platform● CIU が開発する社内向け機械学習基盤のサービス総称○ Notebook インスタンスのお手軽な作成○ 任意イメージの GPU コンテナのデプロイ○ 機械学習ジョブ基盤 /推論基盤 , etc.

● 社内の ML/DS エンジニア向けに開発○ プロダクト開発・運用コストの削減○ GPU 利用ハードルの低減と導入の推進○ パブリッククラウドの GPU 不足の回避
6

最近の関連プレスリリース

大規模なAI開発に対応する「 NVIDIA DGX H100」を国内初導入

独自の日本語 LLM（大規模言語モデル）のバージョン 3を一般公開

80基の「NVIDIA H100 Tensor コア GPU」でAI開発を大幅強化、225億パラメータの商用利用可能なモデルを提供

機械学習モデルの大規模化・構築の高速化 へ
7

ML Platform の計算機システム情報vCPU

約 12,000 Cores

NFS ストレージ

約 250 TB

オブジェクトストレージ

約 400 TB

GPU❏❏❏

外部ネットワーク50 Gbps (Bonding 25GbE)

インターコネクト

400 Gbps (ConnectX-7) x 8 *NVIDIA H100 x 80
NVIDIA A100 x 100+
その他モデル x 100+

* H100 GPU ノード専用インターコネクト

8

ML Platform 上の各サービスについて

サービス名
GPUaaS (GPU as a Service)

概要
GPU + Kubernetes 基盤かつ、マネージド JupyterNotebook 基盤
ダッシュボード、プロジェクト管理、認証情報管理や NFS 管理の機能など
機械学習ジョブの実行基盤

AI Platform Training

Kubeﬂow のオペレーターによるジョブ実行、 Katib による HPO 等
機械学習サービスの推論基盤

AI Platform Prediction

Kserve による推論サービス提供、グローバルエンドポイントのサポート等
分散学習ジョブの実行基盤

Distributed

MPI-Operator による MPI/NCCL を利用した並列計算ジョブの実行9

ML Platform のシステム基盤と提供サービス● GPU 搭載ノード上に構成された Kubernetes クラスタ
GPU as a Service (GPUaaS) の上で各サービスを提供
機械学習ジョブ・推論

AI Platform
Training

分散学習

AI Platform
Prediction

Distributed

GPUaaS（Kubernetes）
GPU
DGXServer
A100

Storage
GPU 環境提供基盤

親鳥
10

LLM 開発と2 ｜ 分散学習基盤への挑戦
分散学習基盤への挑戦と、運用上の課題や取り組み

11

LLM 開発と分散学習基盤の背景●

近年の機械学習モデルのパラメータ数は増加傾向にあり●

特に 大規模言語モデル（ LLM）では更に顕著な傾向があり、1ノードの GPUではメモリ量が不足

複数ノードの分散学習によるモデル /データ並列等の工夫が必須

4
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

LLM の開発基盤を構築するために何が必要なのか
国内においても LLM の開発競争が激化「LLM の開発が可能な分散学習基盤をオンプレ環境で構築する」 ためにインフラチームが必要な作業は何か● GPUサーバや NIC等の見積もり、納入計画、 etc.
● DC ネットワークの設計、ラックの電力設計、 etc.
● 分散学習環境をユーザに提供するためのサービスの設計、開発、そして運用
ML Platform 上で分散学習用の新規サービス “Distributed” の開発

13

ML Platform Distributed

大規模モデル向け分散学習基盤●●

ノード間並列分散学習ジョブの実行サービス○

NVIDIA H100 GPU のみ利用可能○

MPI-Operator による MPIJob の分散実行をサポート

ノード間の RDMA 通信をサポート○

RoCEv2 を利用した Pod 間の高速な通信が可能■KueueSR-IOV Network Device Plugin + SR-IOV CNI + Multus CNI●

Kueue によるクォータ管理とキューイングを採用●

GUI と 独自 CLI ツールから操作可能

14

MPI Operator による MPI/NCCL 環境のデプロイ
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.
15

Kueue によるリソース管理とキューイング
Kueue●

kubernetes-sigs/kueue●

Kubernetes リソースのキューイングを提供する OSS○

クラスタで定義されたクォータに基づいてキューイング可能○

順序保証付きのキューイングが可能○

クォータの設定次第でリソースの Preemption 等も有効化可能●

テナントごとに利用可能なフレーバー（ e.g. GPUモデル）やリソースの総量を制限可能●

MPIJob の場合は Labels に紐付けるキューの名前を指定すると対象のキューに入る○

kueue.x-k8s.io/queue-name=hogehoge

16プロジェクト単位のクォータ管理の例●

ClusterQueue で各プロジェクトで利用可能な ResourceFlavor を定義する○

各テナントで利用可能なリソース（ e.g. GPUモデル種別、 GPU枚数）を制御可能
ClusterQueue A

ClusterQueue B

ResourceFlavor: H100
ResourceFlavor: A100

ResourceFlavor: A100

ResourceFlavor: CPU

ResourceFlavor: CPU

Label: H100

Label: A100

H100 GPU

H100 GPU

A100 GPU

Node A

Node B

Node C

Label: CPU

Node D

Node E

17

分散学習基盤の開発、リリース、そして運用へ …
ML Platform の分散学習基盤サービス Distributed は●

MPI-Operator による MPI を利用する分散実行ジョブのサポート●

SR-IOV, Multus を活用した RoCEv2 による高速な通信をサポート●

Kueue によるフレーバー単位のクォータ管理とキューイングなどの OSS を最大限に活用してサービスの開発を行ったノード間の疎通確認、 NCCL通信の動作検証、想定フレームワークの動作確認、テストデータの計測等が完了、無事にリリースしてユーザに提供開始 ... と思いきや

18

分散学習基盤の運用上のトラブルについて
H100 GPU ノードすべてを利用した分散学習でトラブル発生●

ML Platform 上の H100 GPU ノードは
NVIDIA 社製 DGX H100 と 某D社製 HGX H100 の筐体の両方が存在する●

複数ベンダーの H100 マシンが混在する環境で RDMA通信に失敗する現象 に遭遇●

DGX 同士、HGX 同士の通信では問題が発生しない●

リリース当初の検証では HGX のみの環境のため問題が顕在化せず●

当然、それぞれのベンダーのサポート対象外
NG

OKOK

NIC

NIC

NIC

NIC

H100 GPU

H100 GPU

H100 GPU

H100 GPU

DGX1

DGX2

HGX1

HGX2

19

分散学習基盤のトラブルシューティング (1/2)●

関連する可能性のある様々なミドルウェアの更新や設定の確認○

各ベンダーのファームウェアの更新、設定の見直し○

NIC/GPU 等のファームウェア /ドライバ /カーネルモジュールの更新や設定の見直し○

関連ドキュメントやマニュアルの読み漁り ...

臨時の原因究明チームを組み、根気強く調査を続けた結果、片方の環境で NIC (ConnectX-7) の Adaptive Routing の設定が不整合な状態 であることが判明
想定していないデバイス

adaptive_routing_forced_en=0x1

NIC-0

NIC-1

NIC-2

NIC-3

NIC-4

NIC-5

NIC-6NIC-7

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 Node

NIC-8

NIC-920分散学習基盤のトラブルシューティング (2/2)● 不整合な状態の原因は設定スクリプトのミス○ HGX環境とDGX環境でOS上で見える ConnectX-7 デバイスの本数が異なり、設定対象の NICの範囲指定に誤りがあったのに気付かなかった● Adaptive Routing の設定を統一すると 混在環境でも問題なく RDMA 通信が行えるように○ 副次効果として、設定項目の見直しにより多少の通信性能の向上が見られた

adaptive_routing_forced_en=0x1

NIC-0

NIC-1

NIC-2

NIC-3

NIC-4

NIC-5

NIC-6

NIC-7

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 GPU

H100 Node

NIC-8

NIC-921分散学習基盤サービスの開発と運用から得た学び●

動けばOKではない、 分散学習基盤としての性能検証 が必要○●●

事前に十分な検証期間を確保して性能測定が必要

複数ベンダー混在環境 は予想外の落とし穴 がある○

ベンダーサポートを受けられない範囲は自己責任○

一つ一つ根気強く仮説・検証作業をするしかない

地道に社内に知見を蓄積していくしかない○

同じ轍を踏まないためにトラブル解決の記録は文書として残しておく○

ベンダー提供の HPC向けの設定は参考になる■

今回の HGX マシンは素の Ubuntu から我々が環境構築を行った■

DGX を参照設定として設定項目の見直しができた
22

機械学習基盤の運用 : 計算リソースの最適化施策● 計算基盤の運用として GPU 等の計算リソースの利用率監視や最適化施策も行っています○ JupyterNotebook カーネルの動的なインスタンス割り当て機能の実装○ Training のジョブ形式の普及推進、インスタンスの有効期限の設定○ ユーザ向けの利用率アラート , Slack 通知機能 , etc.

GPU モデル別の利用率（ Utilization） の監視

23

3｜

まとめ24

全体のまとめ●サイバーエージェントではプライベートな機械学習基盤ML Platform を開発・運用中●

LLM 開発のための分散学習基盤サービスは様々な OSS を積極的に活用して構築した●サービスとして必要な機能は Upstream に取り込めるように OSS 活動等を行っている

今後の取り組み●

Kueue によるクォータ管理の ML Platform 全サービスへの展開●

Preemption 導入 / カーネル分離等の推進による計算リソース利用の最適化●

Topology-Aware Scheduling 等のスケジューリング最適化 , etc.

機械学習基盤や分散学習基盤の開発運用に興味のある方は是非お声掛けください！
425

Appendix ｜ 補足情報

26

DCネットワーク周辺 や Distributed の詳細

DCネットワーク関連の発表 @ JANOG52

ML Platform Distributed 関連の発表 @ CADC2023

https://www.janog.gr.jp/meeting/janog52/aiml400/

https://cadc.cyberagent.co.jp/2023/sessions/distributed-ml-with-kubernetes/27

今後の取り組み : Kueue によるクォータ管理の浸透●

ML Platform 全体 で Kueue によるクォータ管理に対応する○

現状は Distributed + 一部 H100 GPU 利用サービスのみ対応○

すべてのサービスの Kueue 対応には既存サービスの改修や運用形態の変更が必要■

Kueue の Integration 対象外のリソースでは Plain Pod Integration を利用する

サービス名

概要

GPUaaS (GPU as a Service)✔ 対応済み（従来方式と併用）

AI Platform Training

将来対応（次期バージョンで Kubeﬂow Integration を対応予定）

AI Platform Prediction

将来対応（Plain Pod Integration による対応を予定）

Distributed✔ 対応済み28

ML Platform 上の並列分散環境の構築に向けて
従来の ML Platform の機械学習基盤について整理● 単一の Kubernetes クラスタで、すべての GPU/CPU ノードを管理● Namespace 単位のマルチテナント環境● 様々なワークロードが同じクラスタ上に混在○●

JupyterNotebook, Training Job, Inference Instance, etc.

クォータ管理は存在しない（一部例外あり）● キューイングを実現する機能はない（ k8s のデフォルト挙動）→ 同じ Kubernetes クラスタ上で LLM 開発を実施する特定のテナントにのみ、高速なノード間通信が可能な特定のノードを占有させたい29

ML Platform 上の並列分散環境の構築に向けた要件● 新規サービスに必須な要件○ RoCEv2 による高速なノード間通信 が利用可能である■

RoCE: イーサネット上で RDMAによる高速な通信を実現するプロトコル○ MPI, NCCL 等の通信規格と 主要な分散フレームワーク に対応している■

MPI, NCCL: 分散学習のプロセス間通信で主に利用される規格 /ライブラリ○ クォータ管理 に基づいた キューイング が可能である● 必須ではないが欲しい項目○ 継続的なメンテナンス がしやすい（技術的負債にならない）■ 普及した /見込みのある OSS を積極的に利用する
30

OSS の採用と選定基準について● RoCEv2 による高速なノード間通信が利用可能である○ SR-IOV Network Device Plugin + SR-IOV CNI + Multus CNI● MPI, NCCL 等の通信方式の分散フレームワークに対応している○ MPI Operator● クォータ管理に基づいたキューイングが可能である○ Kueue

技術選定の基準● （可能な限り） Kubernetes 上のコンポーネントとして完結する● 標準化が進められている or 利用実績が豊富● チームとして OSS の変更についていける / 必要に応じて upstream に貢献できる こと
31

ML Platform Distributed のアーキテクチャ概略

32

Distributed / MPIJob のリソース定義の例●Distributed ではサーバがリクエストを元に MPIJob リソースを作成 /削除する●CLI または 定義ファイルから MPIJob を作成可能

name: pi-example
image: mpioperator/mpi-pi:openmpi
sshAuthMountPath: /home/mpiuser/.ssh
runAsUserId: 1000
launcherSpec:
commands:- mpirunargs:- /home/mpiuser/pi
machineType: ml-standard-2
workerSpec:
commands:- /usr/sbin/sshd
args:
- -De
- -f
- /home/mpiuser/.sshd_config
machineType: ml-h100-80gb-1gworkerReplicas: 3
slotsPerWorker: 1# ジョブの名前# コンテナイメージの指定# SSH鍵をマウントするパス# コマンドを実行するユーザのUID# launcher の実行コマンド# launcher のコマンド引数# worker の machineType# worker の実行コマンド# worker のコマンド引数# worker の machineType# worker のレプリカ数# worker あたりの slots 数の指定

シンプルな設定から MPIJob の定義を作成可能●

利用イメージ、コマンド、リソース、並列化の設定など

apiVersion: kubeflow.org/v2beta1
kind: MPIJob
metadata:
name: pi-example
...
spec:
mpiReplicaSpecs:
Launcher:
replicas: 1
template:
spec:
containers:- name: launcher
command:- mpirunargs:- /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...

33Kueue によるキューイングの概要●

Workload:

キューイングされた Job の状態を管理するリソース●

LocalQueue:

テナント内の Workload を管理するリソース●

ClusterQueue:

リソースのクォータ設定などを定義するリソース●

ResourceFlavor:

リソース種別を定義するリソース

Namespace A
MPIJob A

ClusterQueue
Workload

LocalQueue
MPIJob A: OK

kueue.x-k8s.io/queue-nameResourceFlavor: H100
ResourceFlavor: A100
ResourceFlavor: CPU

Namespace B
MPIJob B

Workload

LocalQueue
MPIJob B: NG

kueue.x-k8s.io/queue-name34