ホームページ > 記事 > テクノロジー周辺機器 > ベアメタルから 700 億のパラメータを備えた大規模モデルまで、チュートリアルとすぐに使えるスクリプトがここにあります
ベアメタルから 700 億のパラメータを備えた大規模モデルまで、チュートリアルとすぐに使えるスクリプトがここにあります
- 王林オリジナル
- 2024-07-24 20:13:31456ブラウズ
LLM が大量のデータを使用して大規模なコンピューター クラスターでトレーニングされていることはわかっています。このサイトでは、LLM トレーニング プロセスを支援および改善するために使用される多くの方法とテクノロジーが紹介されています。今日、私たちが共有したいのは、基礎となるテクノロジーを深く掘り下げ、オペレーティング システムさえ持たない大量の「ベア メタル」を LLM のトレーニング用のコンピューター クラスターに変える方法を紹介する記事です。この記事は、機械がどのように考えるかを理解することで一般的な知能の実現に取り組んでいる AI スタートアップ企業、Imue によるものです。もちろん、オペレーティング システムを持たない大量の「ベア メタル」を LLM をトレーニングするためのコンピューター クラスターに変換することは、探索と試行錯誤に満ちた簡単なプロセスではありませんが、Imbue は最終的に 700 億のパラメーターを備えた LLM のトレーニングに成功しました。その過程で役立つ多くの経験。この記事では、チームが独自の LLM トレーニング インフラストラクチャを構築するプロセスを詳しく説明し、監視、検査、デバッグを容易にするためにチームが作成した多くのツールとスクリプトを共有します。独自の LLM トレーニング インフラストラクチャの構築に興味がある場合、または LLM がどのように作成されるかに興味がある場合は、この記事を読んで収集する価値があります。以下は Imbue チームによる元の記事です。はじめに 私たちの研究者とエンジニアの小さなチームは、数か月をかけて独自のインフラストラクチャ上で 700 億のパラメーター モデルをゼロからトレーニングし、そのモデルは推論関連のタスクでゼロサンプルを上回るパフォーマンスを発揮しました。本日は、初期クラスターの構築からオペレーティング システムのインストール、トレーニング中にエラーが発生した場合の自動回復の設定まで、必要なインフラストラクチャをセットアップするプロセスを共有します。各ステップで直面する課題と解決策について詳しく説明します。これらの学習に加えて、他のチームが独自のモデル トレーニング用に安定したインフラストラクチャを簡単に作成できるようにするために、これまでに開発したスクリプトの多くもリリースする予定です。プロセス全体を通じて、当社のエンジニア チームは Voltage Park と協力してコンピューター クラスターを準備し、実稼働アプリケーションの基盤を構築しました。このプロセス全体には以下が含まれます。 1. 各マシンの構成 2. InfiniBand の構成 3. マシンが完全に正常であることの確認 4. 一般的なトレーニングの問題の診断 5. インフラストラクチャ ツールの改善 各ステップについては、以下で詳しく説明します。背景: 仕組み 計算を実行する際の目標は、大規模な言語モデルを迅速に実験できるようにすることです。これを行うには、高速で相互通信できる多数の高速 GPU が必要です。この記事では、511 台のマシンに分散された 4088 個の H100 GPU、つまりマシンあたり 8 個の GPU を備えたクラスターに焦点を当てます。 GPU を搭載したコンピュータが 511 台ある理由は、InfiniBand ネットワークを管理する役割を持つ Unified Fabric Manager ノード用に一部の接続を予約する必要があるためです。 GPU を備えた 511 ホストでは、各 GPU が ConnectX-7 ネットワーク カードに直接接続されており、InfiniBand ネットワーク上の任意の GPU に 400 Gbps でデータを転送できます。当社の InfiniBand ネットワーク トポロジは「完全にノンブロッキング」であり、理論的には GPU が最大速度で相互に通信できるようになります。これを実現するために、3 層 InfiniBand ネットワーク アーキテクチャ、つまり 3 層 InfiniBand スイッチを使用します。適切な接続を使用すると、ネットワーク全体でこの高レベルのスループットを実現できます。下の画像は、この InfiniBand ネットワークの概要を示しています:
ネットワークをトレーニングするときの通信は、イーサネットではなく、InfiniBand 上で行われることに注意してください。これらのマシンもイーサネットに接続されていますが、このネットワークの役割は、データセットやチェックポイントなどのデータを転送することです。データの送信にイーサネットを使用する場合、データは GPU から CPU に転送され、その後イーサネット カードを介して 100 Gbps の速度で転送されるため、速度は大幅に遅くなります。 RDMA over Converged Ethernet (RoCE) と呼ばれるテクノロジーを使用してイーサネット経由でトレーニングすることは可能ですが、ハードウェア側とソフトウェア側の両方で多くの追加作業が必要となり、一般に InfiniBand よりも信頼性が低くなります。詳細は、この論文でご覧いただけます: https://arxiv.org/pdf/2402.15627
構成と管理のみに使用されるセカンダリ イーサネットもあり、BIOS (基本入出力システム)、電源、その他の低レベルのアクセスを可能にします。 -level マシン インターフェイスの制御インターフェイス。この管理ネットワークがなければ、USB ドライバー、キーボード、モニターを使用して各ノードを手動でセットアップする必要があります。何百ものマシンがある状況では、これは持続可能なアプローチではありません。
このクラスターで高パフォーマンスのトレーニングを実現するには、すべてのコンポーネント (InfiniBand、イーサネット、GPU、ノード自体) がほぼ完璧に動作する必要があります。これら 12,000 以上の接続のいずれかが少し不安定であると、トレーニング全体の実行が遅くなる可能性があります。
この記事の次の内容は、すべてを完璧かつ安定して実行する方法を紹介することです。
手順: ベアメタルを完全に動作可能なクラスターに変える方法
各マシンの構成
管理ネットワークを介してクラスターへの最初のイーサネット接続を確立した後、ベースボード管理コントローラー (BMC/ベースボード管理コントローラー) へのアクセスが証明書を取得します。 BMC は、ホスト システムをリモートで監視する専用のサービス プロセッサであり、通常は別のネットワークに接続されます。これにより、あたかも物理的にその場にいるかのようにマシンを操作できるようになり、さらにハードウェアの健全性、BIOS 設定、電源管理のための API も提供されます。
これらのコンポーネントを装備したら、腕まくりしてクラスターのセットアップを開始できます。
ステップ 0: 最初にマシンを構成する
まず、iDRAC (デルのベースボード管理コントローラー) を使用してサーバーに Ubuntu 22.04 をインストールし、その後、このオペレーティング システムに基づいて他のすべてをセットアップしました。 iDRAC の機能の 1 つは、ローカル コンピュータからの ISO イメージのインストールと起動を可能にし、ブラウザを介して仮想コンソールを提供することです。理想的には、これがプロセスにおける唯一の手動インストール手順です。
ステップ 1: 各マシンにオペレーティング システムをインストールする
最初のマシンを構成した後、残りのサーバーの構成に役立つ Ubuntu の Metal-as-a-Service (MAAS) ソフトウェアのインストールに進みます。 Preboot ExecutionEnvironment Protocol（PXE）ブートおよび自動化 iDRAC ツールを使用して、各マシンにネットワークからブートするように指示し、PXE ブート要求に応答するように MAAS を設定します。初期ネットワーク ブートを実行するとき、サーバーはローカル ドライブに何もインストールすることなく、動的 IP 割り当てプロトコル DHCP 経由で MAAS から IP と初期カーネルを取得します。これは、繰り返し可能なオペレーティング システムのインストールを自動化するための基本環境です。理論的には、最初の起動を待つだけですべてが処理されます。しかし実際には、MAAS と BMC の統合は信頼性が低いため、iDRAC API を使用して各マシンの MAC アドレス (一意の物理ハードウェア識別子) を事前に収集します。
このトレーニングプロセス全体において、MAAS は通常、脊椎スタックのより信頼性の高いコンポーネントです。ただし、最初に私たちのセットアップに特有の問題がいくつか発生しました。たとえば、最初の数台のマシンを構成するとき、時計があまりにも離れていたために HTTPS 証明書の検証の問題が発生し、apt 経由で何もインストールできませんでした。関連して、MAAS サーバーは多くのこと (DHCP サーバー、ホスト名を IP に解決する DNS サーバー、ホストと公式 Ubuntu パッケージ サーバー間の HTTP プロキシ、NTP サーバー、cloud-init 構成管理、グラウンド) を担当する必要があるため、 MAC アドレス、IP、ホスト名、カスタム メタデータを接続するために使用される真実データベース）のため、これらの問題を根本原因から解決することは困難です。さらに、設計目標は、グリーンフィールド展開の管理の複雑さと、ノードとさまざまなデバッグ/異常な中間状態の段階的な移行に対処することであるため、MAAS 構成ライフサイクルの学習曲線の問題もあります。
ステップ 2: 壊れたマシンを診断する
主にサーバーの物理的な問題が原因で、約 10% のマシンが起動に失敗していることがわかりました。これは、大規模な GPU クラスターをセットアップするための一般的なシナリオです。私たちが遭遇した状況には、ネットワーク ケーブルの欠落または不正、iDRAC のハードウェアの問題、電源ユニットの損傷、NVME (不揮発性メモリ高速) ドライバの損傷、内部配線の欠落、ネットワーク カードまたは GPU の表示なしなどがあります。これらの問題を自動的にチェックし、再テストのために一部のマシンをデルに返却し、データセンター スタッフに適切な作業指示を提出しました。クラスターを自分で構成する利点の 1 つは、一部のマシンのメンテナンスを待っている間、正常なマシンをすぐに使用できることです。
ステップ 3: 実行可能な最小限の監視可能なマシン
各サーバーで次のセットアップを進めます:
1.Docker (サービスとトレーニング ジョブの実行を容易にするため)
- データセンター GPU ドライバー
3. Prometheus ノード エクスポート ツール (安定したハードウェア/オペレーティング システム インジケーター データ フローのエクスポートに使用)
4. DCGM エクスポート ツール (GPU ステータス、クロック、 - すべての非 OS 駆動の RAIDZ ZFS プール。これにより、ドライバーに障害が発生した場合でもマシンが動作し続けることができると同時に、透過的な圧縮も無料で提供されます (特にプレーン テキスト データ セットや反復的なログの場合) 便利 - このツールを使用すると、通常、使用率が増加しますツールを使用しない場合と比較して、使用可能なスペースが 10 倍になります)
その後、基本的な GPU 診断を実行して、GPU が通常機能しているかどうかを判断します。機能していない場合は、通常、数秒以内に発生します。ハードウェアの問題は数時間以内に発生します。
この間、400 ノードすべてに同時にパッケージをインストールしようとすると、帯域幅のボトルネックが発生しました。データセンターに導入されている複数のコンポーネントで高温過熱アラートを受け取ったのはこれが初めてです。これらの最初の発熱問題は、ファームウェアのアップデートによって大部分が解決されました。
ステップ 4: シングルノード GPU トレーニング
次のステップは、各マシンが実際の GPU ワークロードを独自に処理できることを確認することです。多くのマシンではこれを行うことができません:
GPU 関連のエラー これらの問題は基本的に、GPU カードをカード スロットに再挿入することで解決できます。200 ポンドのサーバーをラックからスライドさせて、その間にあるすべてのケーブルを取り外します。ケース カバーと GPU を取り外し、GPU を取り外し、再度 GPU を取り付け、ケーブルを再度取り付けて、サーバーをラックに押し戻します。
Ubuntu サーバーのログによると、GPU と PCIe バスまたはネットワーク カード間の多くのケーブルで「幅が制限されています: x4 いくつかのホストに影響を与えるその他の不具合もいくつかあります。デルは、ファームウェアのアップグレードに関するいくつかの問題の解決を支援してくれました。
NVMe ドライブには問題はありませんでしたが、触れるとマシン全体がロックされました。
Linux ではハードドライブがランダムな順序で表示されるため、MAAS が混乱し、オペレーティング システムが間違ったドライブにインストールされる原因になります。
温度の読み取り値が間違っているため、ファンが常にフルスピードで動作します。原因は NVIDIA ドライバーに問題がある可能性がありますが、ドライバーのバージョンをダウングレードすることで解決できます。
CPU の動的スケーリングが制御不能になり、動作コアが 2 GHz に制限されます。
直接 GPU-GPU 通信 (GDR または GPUDirect RDMA Peer Memory Client) を正常に適用できません。
InfiniBand を構成する
ステップ 0: UFM をインストールする
InfiniBand の利点の 1 つは、ネットワーク全体が 1 つの頭脳を持つように集中化された設計であることです。したがって、ネットワーク ファブリック全体で 320 ネットワーク スイッチの 1 つのインスタンスのみを処理する必要があります。私たちの最初のタスクは、どのスイッチがどのマシンに接続しているかを把握し、それを配線図と関連付け、スイッチの物理的な位置に基づいてスイッチの名前を変更することでした。
ステップ 1: 再配線
当初、UFM は、ファブリック内に存在するはずのホストはおろか、これらの 320 スイッチを検出できませんでした。データセンター パートナーと相談した結果、スイッチの電源がオンになって配線されていることを確認しましたが、依然としてスイッチを検出できませんでした。ネットワークのケーブル配線リストを調べた結果、ネットワーク構造のトップレベルの設計が間違っていることに気付きました。構造は統一される代わりに、共通のルーティング パスを持たない 8 つの切断されたネットワークに分割されていました。再配線後、すべての物理接続が新しい設計と一致していることを確認するチェック手順を追加しました。
ステップ 2: 1 万件の温度アラーム (アラート)
物理配線の問題を解決した後、InfiniBand はネットワーク構造内のすべての InfiniBand スイッチとの接続を正常に確立しました。しかし、ほぼすべてのスイッチ ポートが、データを送信していないにもかかわらず、過度の温度 (場合によっては 70°C を超える) を報告し始めました。この問題は、同じラック内のスイッチ間の空きスペースが原因で、熱気が前面に逆流することが原因であることがわかりました。データセンター パートナーは、問題を迅速に診断し、適切な解決策を開発するのに役立ちました。
ステップ 3: 1800 のアラーム
多くのポートではエラー率が高かったり、正常な状態と損傷した状態の間を行ったり来たりする「フラッピング」と呼ばれます。これらの問題は、ポートが実際に使用されている場合にのみ発生します。ファブリック全体が 10,000 の高度に冗長なリンクで構成されているため、事前に検出するのは困難です。当社のデータ センター パートナーが警報ポートの清掃と再取り付けを支援し、交換を待つ間残りの警報トランシーバーを無効にしました。
InfiniBand はハードウェア障害に対する回復力がありますが、ファブリックの約 10% で障害が発生し始めると、適応ルーティングなどの機能が時折失われるリンクを考慮して確実に機能しなくなります。
この間、100 ～ 200 台のマシンを使用してマルチノード トレーニングを実行することに成功しました。私たちのプロセスはある程度即興的なものです。時々、ランダムなノードのセットを起動し、そのパフォーマンスを観察し、できるだけ多くのノードを実行し続けるようにします。この方法を使用すると、InfiniBand ネットワーク構造の信頼できるサブセットを見つけることができますが、トレーニングに使用されるノードのセット、つまりデフォルトの InfiniBand リンクを毎回変更する必要があるため、これは非常に困難です。
ステップ 4: InfiniBand の書き込み
InfiniBand の問題をより効率的に診断するために、ファブリック全体のすべてのポートを介してできるだけ多くのデータを同時にプッシュするクラスター全体のワークロードを設計しました。これは、クラスタ全体で大規模な all-reduce ワークロードを実行することとは異なります。この場合、NCCL を使用して、サーバー PCIe モジュール (SXM) スロットを介した GPU 通信に NVLink を使用して個々のノード間の通信を最適化する必要があります。
代わりに、強引なアプローチを選択し、簡単に成功しました。 UFM は、ほとんどのポートのデータ転送量が理論上の容量の 97% を超えるとアラートの発行を開始し、一部のスイッチが一時的にダウンします。その日の終わりまで生き残ったと思われるすべてのポートは十分に堅牢でしたが、残りのポートは無効化されるか、修理が保留されて削除されました。
ステップ 5: GPUDirect RDMA
CPU コンピューティング オーバーヘッドを発生させずに GPU 通信を可能にするために、InfiniBand ネットワーク カード間の直接通信を可能にする GPUDirect RDMA と呼ばれる機能を有効にします。これには 2 つの重要な手順が含まれます: - 追加のコア モジュールを開始します
- 即時のハングを防ぐために PCIe アクセス コントロール サービス (ACS) が無効になっていることを確認します
ステップ 6: 「ゴールデン」サーバーを増幅します
次の GPU クラスターを構築するときに使用します最新のハードウェアでは、経験則として、毎週約 3% のマシンに問題が発生するため、備えてください。
ただし、説明する必要があります。すべてのマシンに均一に 3% の故障の可能性があるわけではありません。少数の未処理のマシンでは、適切に修理されるまでさまざまな問題が繰り返し発生します。これは、同じネットワーク構造内に多数のマシンがあることの利点を強調しています。したがって、モグラたたきで何が壊れているかを確認するように、大規模なトレーニングを実行するマシンをランダムに見つけるだけではなく、信頼できることがわかっているサーバー、つまり「ゴールデン」サーバーのスケーリングに重点を置くのが私たちのアプローチです。
ステップ 7: メンテナンス
InfiniBand のメンテナンスには主に、UFM アラームへの対応、障害のあるケーブルとトランシーバーの交換、および場合によってはより困難なエラー (スイッチの故障など) の診断が含まれます。通常、大規模なメンテナンスにつながる要因は 2 つあります: - ファームウェアの更新、特にクラスターの半分だけが更新を完了している場合、UFM 状態の破損につながり、すべての InfiniBand スイッチで UFM の再起動が必要になる可能性があります。
2. GPU ボックスを同時に大規模に再起動します。これにより、UFM 状態が大量の更新でフラッディングされ、UFM サービスの再起動も必要になる可能性があります。
マシンが完全に健全であることを確認する
このプロセス中に、個々のマシンが誤動作したり、トレーニングが遅くなる可能性がある複数の原因を発見しました。これらの障害モードの多くはすぐには明らかではないため、ホストが十分に健全であるかどうかを確認するために、多数のヘルス チェック スクリプトを作成しました。ここでコードを公開しました: https://github.com/imbue-ai/cluster-health
これらのヘルスチェックの多くはランタイム環境に固有であり、必ずしも基盤となるハードウェアに関連しているわけではないこと、また必ずしもそうではないことに注意してください。修正または自動化が簡単です。これは仕様によるものです。マシンをトレーニングできる状態にするという全体的な目標を達成するには、「はい」か「いいえ」で簡単に答えられ、細かい詳細をいくらでも要約できる単一のエントリ ポイントが必要でした。
GPU ヘルスチェック
GPU の数が正しいこと、ECC (エラー訂正コード) チェックが有効であること、ECC エラーがないことをチェックします。また、NVLink トポロジ (GPU を相互に接続する) が稼働しており、エラーがないことも確認しました。
ディスクスペースヘルスチェック
ホストのディスクスペース使用率が95%を超えているかどうかをチェックします。
Docker Health Check
GPUを接続した状態でDockerがコンテナを実行できるか(つまりNVIDIA Container Runtimeが正しく動作しているか)を確認し、監視/分析に関係するDockerコンテナが有効化されているか、正しいホスト権限を取得しているかを確認しました。 。
Dmesg ヘルスチェック
ハードウェア Xid または SXid エラー (NVIDIA GPU または GPU 間 NVIDIA スイッチによって引き起こされる障害) がないか dmesg をチェックしました。また、すべての dmesg ログ行を読み取り、それらがすべて「共通/予期されるログ行」リストに分類できることを確認します。
iDRAC ヘルスチェック
マシン上の iDRAC エラーをチェックしましたが、致命的ではないエラー メッセージは無視されました。これは Dell コンピュータに固有のチェックであるため、オープン ソース コードには含まれていません。
ディスク ヘルス チェック
zpool がインストールされていること、Docker がそれに適切に接続されていること、CPU をロックアップすることなく実際にアクセスできることを確認しました。
InfiniBand ヘルスチェック
InfiniBand のエラー率が増加していないか、ドライバーのファームウェアが古くなっていないかをチェックします。
Nvlink ヘルスチェック
マシン上の NVLink エラーをチェックします。実際には、これによってトレーニングの失敗が発生することはないようですが、トレーニングの速度が低下する可能性があります。
GDR ヘルスチェック
マシン上で GDR が有効になっているかどうかを確認しました。
VBIOS ヘルスチェック
GPU の VBIOS バージョンと H100 ベースボードのファームウェアが最新であることを確認しました。
Flint ヘルスチェック
flint と hca_self_test を使用して、Mellanox OFED ドライバー、ネットワーク カード ファームウェア、およびトランシーバー ファームウェアが正しいバージョンであること、およびそれらが NVIDIA ドライバー用に正しくコンパイルされていることを確認しました。
PSB ヘルスチェック
PCIe デバイスにクエリを実行して、GPU、PSB (PCIe スイッチ バス)、およびネットワーク カード間の接続の速度と幅が予想どおりであることを確認しました。スイッチのファームウェアが最新であることも確認しました。このスクリプトは Imbue ではなく Dell によって開発されたため、現時点では共有できません。
これらの簡単なヘルス チェックに加えて、次のようなより複雑なヘルス チェックも実行します。
PyTorch による行列計算の初期化、NVLink 帯域幅、GPU の計算速度とメモリの測定。 InfiniBand と NVLink をテストするために、適切な GDR フラグを設定します。
ib_write_bw と –use_cuda を使用して、IB カード経由でデータを送信し、PCIe および InfiniBand カードの帯域幅を測定します。このプロセスは長時間 (約 15 分) にわたって続き、バタバタしている InfiniBand リンクが確実に識別されました。
マルチノード診断を実行して、NCCL の初期化機能と、ランダムに停止するかどうかを確認します。ストールがある場合は、フォークされた NCCL コードにより追加のログが追加されます。問題を検出するには 12 ～ 24 時間かかるため、通常は新しいノード上でのみ、または問題が疑われる場合にのみこれを実行します。
DCGM エクスポートで GPU クロック スロットル イベントがないか確認します (予期される gpu_idle と power_cap を除く)。これらの電力イベントをチェックするには、すべての GPU、InfiniBand カード、CPU とディスクを同時にチェックするマルチノード トレーニングを実行するのが最善の方法です。
トレーニングの一般的な問題を診断します
ハードウェアが適切に動作したら、トレーニングを開始できます。
このセクションでは、クラスター上で大規模な言語モデルのトレーニングを実行した経験に基づいて、いくつかの具体的なデバッグ手順と洞察を共有します。
起動時のクラッシュ
これは、(理論的には) 簡単に再現して反復できるため、ある意味、遭遇する可能性のある最高のバグです。
まず、コードが正しいバージョン、構成、環境変数で実行されていることを確認しました。基本的ではありますが、スタートアップ トレーニング プロセスが再現可能であり、チェックが容易であることを保証することが重要であることがわかりました。大きな理由の 1 つは、Docker イメージのキャッシュや不透明なシークレット構成などの中間抽象化が混乱を引き起こす可能性があることです。
私たちが実行するもう 1 つの基本的なチェックは、すべてのマシンがオンラインであり、スタック トレースや出力されたログが簡単に集約して検査できることを確認することです。ここでは Loki、Prometheus、および Grafana ソフトウェア スタックを使用しましたが、適切なログ集約または追跡 SaaS ツールであればどれでも使用できます。これらのトレーニングの実行は本質的に同期的かつ分散されるため、多くの場合、最初のエラーが無関係なエラーの連鎖につながります。ここで、ヘルスチェックは、ハードドライブの破損、GPU の欠落または無効などのエラーをすぐに検出するのにも役立ちます。
障害が発生した場合に自動的に再起動するシステムを構築しました。そのため、さまざまな再起動による混乱を招くエラーを避けるために、ログとエラーの集計がさらに重要になります。私たちが遭遇する一般的なエラーには次のようなものがあります:
1. 「ランク間で順方向の順序が異なります。ランク 0 は 43 個のパラメータをすべて収集していますが、ランク 1228 は 1 つのパラメータをすべて収集しています。」これは PyTorch の Fully Sharded Data Parallel (FSDP) 実装の奇妙な機能であることがわかり、再起動すると解決されました。
2. GPU メモリ不足 (OOM) エラー。「CUDA メモリが不足しています。割り当てようとしました...」起動中に GPU #0 が過剰に使用されてしまうため、これらの問題を修正しました。
3.CPU/RAM メモリ不足 (OOM) エラー。これらのエラーはエラー ログで見つけるのが簡単ではありませんが、通常は Docker コンテナの外部のホストの dmesg ログを通じて検出できます。フォークされたプロセスまたはネットワーク ピアを停止するために OOM Killer が呼び出される場合、それらは主に CalledProcessError または ConnectionError として現れることがわかります。 OOM Killer 呼び出しが dmesg から検出された場合、単純にヘルスチェックを放棄してボックスを再起動することを好みます。また、手動ガベージ コレクションが適切に行われているかどうかコード パスをチェックし (これを無効にする方法については以下のセクションを参照)、また、テンソルを計算したり CPU に移動しようとする予期せぬ試みがないかどうかもチェックしました。
トレーニング中のクラッシュ
最初のタスクは、システムの自動実行を有効にして、すべてのヘルス チェックを自動的に再実行し、異常なホストが見つからなくなったら再起動できるようにすることです。 Xid エラーや SXid エラーなど、いくつかのランダムなハードウェア エラーが発生しました。これにより、意味のある Python スタック トレースが生成されずに実行がクラッシュする可能性がありました。行の再マッピングなどの一部の問題は、再起動することで回復できます。訂正不可能な ECC エラーなど、その他のエラーでは、多くの場合、ハードウェアのメンテナンスや部品の交換が必要になります。
さらに、不正な形式のトレーニング データもクラッシュを引き起こす可能性があることを観察しました。たとえば、コーパス内に非常に大きな単一のドキュメントがある場合、GPU または CPU でメモリ不足エラーが発生する可能性があります。この問題を防ぐために、完全に決定的なデータ ローダーを実装しました。これにより、エポックまたはステップ番号に関連付けることで、すべてのクラッシュを簡単に再現できるようになりました。データのロードを無効にするか、偽のデータ (すべてゼロのデータなど) を置き換えることで、エラーの根本原因がデータにあるかどうかを確認するのに役立つことがわかりました。
最後に、メトリック集計方法を使用してネットワークと一般的なノードの健全性統計を記録することも役立ちます。イーサネットの短時間の切断やディスク容量の不足などの問題は、有益なエラー メッセージとして表示されない場合がありますが、収集されたデータと簡単に関連付けることができます。
スタック トレースなしでハングする (後でタイムアウトになる可能性もあります)
この種のエラーのデバッグは、役立つ情報が不足しており、確実に再現することが難しいため、イライラする可能性があります。
最も記憶に残るエラー タイプの 1 つは、次のようなエラー メッセージを伴います:Watchdog caught collective operation timeout:WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) ran for 600351 milliseconds before timing out
このエラー メッセージは、トレーニング実行中のすべての GPU ワーカーによって発行されます。
これは、1 つ以上のホストが NCCL 操作を完了できなかったか、NCCL と InfiniBand 接続がクラッシュしたため、NCCL_TIMEOUT タイムアウトに達するまで他のすべてのホストが同時にテンソル操作でスタックしたことを意味します。残念ながら、NCCL ソフトウェア ライブラリの性質上、どのホストが問題の原因となっているかを特定することは困難です。
NCCL ソフトウェア ライブラリのログにいくつかの変更を加えました。フォークされたバージョンを参照してください: https://github.com/boweiliu/nccl。これにより、クラッシュが発生したときに実行されているメッセージや操作がより明確になり、どのホストまたは GPU が実行をブロックしているかを特定できる可能性があります。
不正な動作をしているホストを特定するには、どのホストが特定のログ メッセージを生成していないのかを把握する必要があることに注意してください。このようなメッセージがない場合は、このホスト上のワーカーが遅れているか、クラッシュしていることを示しています。
利用可能なエラー メッセージがないその他の応答しない状況は、通常、NVIDIA ドライバーまたは NVIDIA Docker 通信ドライバーのロックを引き起こす前述の Xid/SXid/ECC エラーなどのハードウェア関連の問題に関連しています。 NCCL のハングをドライバーのハングや、Python コードの競合状態やデッドロックと区別するために、Py-Spy や GNU プロジェクト デバッガー (GDB) などのツールを使用して、発生した停止プロセスをリアルタイムでデバッグします。このアプローチを使用すると、1 つの特定の問題が発見されました。Python スレッド設定の構成エラーにより、一部のホストで 8 つのマルチスレッド NCCL GPU プロセスを正しく起動できず、PyTorch の前の初期化コード段階で競合状態が発生しました。
- トレーニングの速度低下 (MFU によって測定)
ツールの欠如により、この種の問題は以前の問題よりもさらにイライラさせられます。 Py-Spy、スタック トレース検査、GDB の使用に加えて、NVIDIA Nsight とプロファイリング ツールも採用しました。これらのツールの中には、高度に分散された設定では使用するのが難しいものもあります。
残念ながら、全体的な速度の低下や、以前に示したモデルの浮動小数点使用率 (MFU) よりも遅い速度には多くの理由が考えられます。
まず、構成、コード、環境変数を複数回チェックすると便利であることがわかりました。私たちが経験したエラーには、間違ったモデルの実行、間違ったバッチ サイズ、間違った UFM または NCCL 設定、CUDA_DEVICE_MAX_CONNECTIONS エラーなどがあります。これにより、最適なパフォーマンスが得られなくなります。
また、平滑化されていない MFU 曲線は問題クラスの診断に役立つことが多いため、(平滑化された平均やウィンドウ化された平均ではなく) 瞬間的な (つまり、バッチごとの) MFU を測定することも有用であることがわかりました。トレーニングの速度低下の原因となる問題には次のようなものがあります:
- 非常に低い MFU (予想の 10 分の 1 未満) からトレーニングをすぐに開始し、安定した状態を維持する
これは、InfiniBand ネットワーク接続に関するハードウェアの問題である可能性が高くなります。 T2 または T3 レイヤ スイッチがクラッシュします。 GPU と NIC の間のハードウェアの問題もこの状況を引き起こす可能性があり、その場合、dmesg は次のようなエラーを報告します: PCIe x16 レーンは…によって制限されています
- 予想される MFU の 30% から直ちにトレーニングを開始し、安定した状態を維持してください
その理由ホストの GDR 設定 (NVIDIA ピア メモリ) または GDR 環境変数が正しくありません。
- 予想される MFU の約 60 ～ 80% から直ちにトレーニングを開始し、安定した状態を維持してください
最も一般的な理由は、InfiniBand リンクの品質の低下または障害、特に InfiniBand NIC に関連する単一の GPU 障害であり、結果として NCCL ルーティングが発生しますトラフィックはローカル NVLink 経由で、同じホスト上の別の GPU 上の NIC を使用します。 CPU スロットリングによってもこの問題が発生する可能性があるため、一部のホストで BIOS 設定を調整する必要があります。
- データの特定のバッチを処理するときに突然の大幅な速度低下 (10 分の 1 の低下) が発生します。これは非常に頻繁に発生します
これは基本的にすべてチェックポイント設定または評価に関するものです。これは、エポック数またはステップ検証の数をチェックすることで判断できます。厄介なことに、MFU が異常な場合に自動アラートを設定すると、誤検知が多くなります。
- 特定のデータバッチの処理中に突然の大幅な速度低下 (10 分の 1 の低下)
これはランダムかつかなりまれに (おそらく 15 分に 1 回) 発生し、MFU の直後に完全に良好な状態に回復します。
最も一般的な原因は、他の CPU を集中的に使用するワークロードが実行中のホストにスケジュールされていることであるようです。特定のホストを識別するプロファイリング ツールを構築するよりも、PID によって CPU を大まかに監視する方が簡単であることがわかりました。原因は、データ ローダーのボトルネックなど、時折発生するネットワーク接続の問題である可能性があります。データ ロード、チェックポイント、NCCL 以外のコードのメトリクス データを監視し、Python コードのタイミング ログを追加しました。これは非常に信頼性が高いことが証明されました。
- MFU は実行中に徐々に速度が低下しますが、再起動するたびに 100% に戻ります
理論的には、原因はスイッチの熱の蓄積である可能性がありますが、これが起こるのは見たことがありません。ただし、Python と NVIDIA プロファイラーを使用したところ、パフォーマンス低下の原因は自動ガベージ コレクションであると考えられます。
これらの速度低下を解決するためにデバッグを行っているときに、スループットがほぼ定期的に低下することが判明しました。トレーニングが進むにつれて、この低下は分散コンピューティングへの影響を増大させるでしょう。このことから、ドロップの原因は自動ガベージ コレクションに関連しているのではないかという推測が生まれ、この疑いは分析とテストを通じて検証されました。すべてのホストで自動ガベージ コレクションを無効にし、特定の間隔でのみガベージ コレクションを設定すると、このスループットの「低下」は解消されました。
ZeRO-3 に基づく同期分散トレーニング アルゴリズムである FSDP を使用します。ブロッキング操作中に、ガベージ コレクションを実行する単一のワーカー プロセスにより、他のすべてのワーカーの速度が低下する可能性があります。ワーカー プロセスが数百ある場合、これにより大幅な速度低下が発生する可能性があります。
パフォーマンスは最初は良好ですが、その後突然 (予想の 70% まで) 低下し、高頻度で (15 秒ごと) 継続します
これは NVIDIA GPU の「クロック スロットルの理由」に関連していることがわかりました。 NVIDIA DCGM によって解決されるため、適切な設定を行うことでこの問題を解決できます。熱の問題 (GPU の温度が高いか、コンソールの冷却ファンの故障または効果の低下) または電源の障害がこの問題を引き起こす可能性があります。また、CPU/RAM/ディスクとともに 8 つの GPU 使用率と 8x NIC InfiniBand 使用率をすべて最大にすると、特定の電源ハードウェアを備えた一部のホストで電圧の問題が発生しますが、それらをすべて使用するだけです (通常、これは実際のトレーニング実行)。
パフォーマンスの問題の相関関係
- パフォーマンスは良いが、ノイズが通常より多い（予想されるMFUの90%と100%の間の高周波ホワイトノイズの分散）
これはInfiniBandハードウェアにも関連していますが、通常はある程度のレベルがありますT2 層への冗長性の低いホストではなく、ネットワークの上位層のリンクに起因するパフォーマンスの低下やジッターの影響を軽減します。
残念ながら、これらの問題の多くは特定のホストを特定するのが難しく、InfiniBand スイッチ テクノロジのトポロジ認識型の性質により、InfiniBand 関連の問題は特に特定が困難です。 InfiniBand ファットツリー設計では、InfiniBand は隣接するホストを優先しているように見えますが、UFM は非対称リンク速度でパケットをルーティングできます。
スループットの問題をデバッグするための完全性チェックリスト
以下は、スループット問題をデバッグするための簡単な概要/フローチャート/完全性チェックリストです:
- このシステムは以前に適切に動作していましたか?
- 最近どのような変更を加えましたか (コードのマージ、ドライバーの更新など)?
- あなたが実行しているホストは健康ですか? Docker Hub、GitHub などのサードパーティ SaaS を含むすべての依存サービスは適切に実行されていますか?
- 現在実行されているコード、環境、構成、バージョン、ホストリスト、ランキング順序、ランダムシードが前回とまったく同じであると確信していますか? (そのようなチェックが実装できれば。)
- 問題は再現できますか?
- は他のものとどのように関係していますか?他のプロセスは？毎日の crontab スケジュールされたタスク?ホスト、DCGM、または UFM インジケーター?
- あなたのツールはこれらの指標を正しく測定していますか?
- コードの縮小バージョンを実行するとき (より小さいモデル、偽のデータ、チェックポイントの保存または読み込みを行わない) を実行しても問題はまだ存在しますか?
改善されたインフラストラクチャ ツール
上記の手順を完了すると、モデルをトレーニングする際に、少なくとも何かが壊れるまでは、良好なパフォーマンスを達成できるようになります。
このセクションでは、理想的には人間の介入を最小限に抑えながら、一貫した安定したトレーニングを保証するためのいくつかのツールとシステムを紹介します。私たちのチームは小規模であるため、手動で修理するのに十分な人材がいないため、このプロセスも可能な限り自動化したいと考えています。
このプロセス中に発生したほぼすべての問題は、マシンまたはネットワーク コンポーネントの障害に起因する可能性があります。このような種類の障害は大規模なクラスターでよく発生するため、私たちのアプローチは、障害が発生したマシンとネットワーク コンポーネントを自動的に無効にして、修復リクエストを送信することです。
機械の故障
実行がクラッシュした場合に、最新のチェックポイントから自動的に再起動するシステムを開発しました。この再起動プロセスでは、利用可能な各マシンが最初にヘルス チェックされ、次に合格したヘルス チェック結果に基づいて各マシンが分類され、最も健全なマシンでトレーニングを再開しようとします。
ネットワーク コンポーネントの障害
私たちが観察したすべてのネットワーク障害は UFM によって検出可能であり、UFM イベント ログに記録されたため、対応は簡単でした。UFM ログを解析して適切なアクションを実行するだけでした。
UFM イベント システムは非常に複雑で、数十のイベント タイプが含まれています。ただし、実際には、問題のあるイベントはわずかで、ほとんどがリンク障害または高シンボル エラー手法に関連していることがわかりました。これらのイベントを特定したら、UFM イベント ログを解析するスクリプトを作成し、最近のイベントに関連付けられたリンクとポートを無効にし、これらのネットワーク コンポーネントのメンテナンス作業指示を要求し、メンテナンスが完了したらこれらのコンポーネントを再度有効にすることができます。
ローカル イメージ ファイル システム
これらの大規模な分散トレーニングでは、クラスターとイーサネット間のデータ交換速度が大きなボトルネックであることが長い間知られていました。共有イーサネット接続の帯域幅は約 10Gbit/秒ですが、数百のワーカーがデータセットとモデル チェックポイントを同時にダウンロードすると、すぐに飽和する可能性があります。
この目的のために、クラウド ストレージのミラーとしてクラスター内にローカル ファイル システムを構築することにしました。これは本質的に、S3 から読み取られるファイルの量を削減できるキャッシュ スペースです。クラスターのチャーン (メンテナンス上の理由でマシンが無効になったり交換されたりする場合) を考慮して、各ファイルのコピーを 3 つ用意し、コンシステント ハッシュを使用して負荷を均等に分散し、クラスターのチャーン中のパフォーマンスを最大化して、ファイルの移動を大幅に削減します。クラスターのディスク容量は限られているため、ファイルのライフサイクルを追跡し、不要になったファイルを削除するツールを開発する必要がありました。
ローカル分散 Docker レジストリ
私たちは、Docker イメージのピアツーピア転送用の優れたオープンソース ソフトウェアである Kraken を使用しました。ソフトウェアにはほとんど問題がありませんでしたが、タスクと実装の複雑さを考えると、これは私たちにとって非常に驚きでした。ツールアドレス: https://github.com/uber/kraken
さまざまなパフォーマンス監視ツール
デフォルトのTorchアナライザーとNVIDIAのNsight Systemsをセットアップしました。後者は、順方向/逆方向のパスと NCCL 通信に必要な正確な時間を理解するのに役立ち、さらに、特定のモデル サイズとワーカーの数がボトルネックになるかどうかを判断するのに役立ちます。ただし、Nsight Systems は、Docker を特権モードで実行する必要があり、パフォーマンス監視イベントに関連するセキュリティ チェックを無効にする必要があり、構成を保存するにはトレーニング プロセス全体を停止する必要があることが多いため、使用するのが少し難しいです。
さらに、遅いトレーニング バッチを検出し、その考えられる原因を理解するためのツールを作成しました。これは便利だと思いました。最も便利なツールは、各バッチにかかる時間を監視し、バッチが遅すぎる場合はワーカーのスタック トレースを破棄します。これにより、軽微なハードウェアまたはソフトウェアの問題があるホストを簡単に見つけることができます。
マシンを異なるグループに分割して、障害のあるホストを特定します
このクラスターを使用し始めてから最初の数か月間 (ヘルスチェックが今ほど徹底していなかった頃)、次のような状況によく遭遇しました: グループ内で誤動作が発生マシンでのトレーニング中に問題が発生したのですが、どのマシンに問題があるのかは不明でした。障害のあるホストを見つけるために、一連のマシンを異なるグループに分割し、マシンの各グループで小規模なトレーニングを実行することを簡単にするツールを開発しました。
たとえば、48 台のマシンでのトレーニングの実行が失敗した場合は、それぞれ 8 台のマシンからなる 6 つのグループで小規模なトレーニングを実行し、次にそれぞれ 6 台のマシンからなる 8 つのグループでより小規模なトレーニングを実行します。通常、2 つのフェーズのうち 1 回の実行のみが失敗するため、両方のフェーズで失敗したマシンには障害があると確信して結論付けることができます。
反省と教訓
インフラストラクチャの設定と維持の過程で、私たちはいくつかの有益な教訓を学びました:
- 便利な練習は、マシンの位置を交換することです。実行時には、マシンに障害が発生した場合にトレーニングを簡単に再開できるように、必要なマシンより 10 ～ 20% 多くのマシンを使用すると便利です。各マシンが他のすべてのマシンに緊密に接続されるようにクラスター ネットワークをセットアップすると、それらのマシンの動作中のサブセットを使用できるようになります。
- トレーニング中に遭遇するすべての問題は再発するため、遭遇するハードウェアまたはソフトウェアの障害ごとにテストと自動化されたソリューションを作成することは有益です。同様に、あいまいなエラー メッセージごとに、エラーをより適切に説明するツールを作成する価値があります。
- 再現性は優れた科学研究の鍵です。私たちがすぐに採用した原則の 1 つは、たとえ最も単純な事柄であっても、「一度に 1 つのことのみを変更する」というものでした。
- 信頼するだけでなく、検証することも必要です。外部ツールを導入したり、新しい人材を (社内外から) 招聘するときは常に、特に後続のステップがそれらの主張に依存している場合には、その主張を再確認します。
概要
大規模な言語モデルをトレーニングするには、最初から複雑なインフラストラクチャが必要です。当社がインフラストラクチャの設定の詳細に深く関与することを選択したのは、当社が運用しているシステムを完全に理解することが重要であると考えており、またその方が効率的であると信じているためです。
さて、このプロセスを経て、このアプローチを採用してよかったと思います。インフラストラクチャを完全に制御し、あらゆる抽象レベルで簡単にデバッグできる機能が重要な価値があることが証明されました。このプロセスには多くの監視と反復が必要でしたが、そのおかげで基礎となるワークフローを深く理解し、ホストの健全性を確保するためのツール セットを構築し、システムを自動化して継続的なスムーズなトレーニングを保証する方法を学び、最終的には最先端の言語モデルを迅速かつ反復的にトレーニングできるようにするインフラストラクチャのセット。
このインフラストラクチャ構築プロセスは、AI エージェントの研究と構築のための基本的な方法論を反映しています: 詳細を探索します
以上がベアメタルから 700 億のパラメータを備えた大規模モデルまで、チュートリアルとすぐに使えるスクリプトがここにありますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。