베어메탈부터 700억 개의 매개변수가 있는 대형 모델까지 튜토리얼과 바로 사용할 수 있는 스크립트가 있습니다.

LLM が大量のデータを使用して大規模なコンピューター クラスターでトレーニングされていることはわかっています。このサイトでは、LLM トレーニング プロセスを支援および改善するために使用される多くの方法とテクノロジーが紹介されています。今日、私たちが共有したいのは、基礎となるテクノロジーを深く掘り下げ、オペレーティング システムさえ持たない大量の「ベア メタル」を LLM のトレーニング用のコンピューター クラスターに変える方法を紹介する記事です。この記事は、機械の思考方法を理解することで一般的な知能の実現に取り組んでいる AI スタートアップ企業、Imbue によるものです。もちろん、オペレーティング システムを持たない大量の「ベア メタル」を 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로 전송된 다음 이더넷 카드를 통해 100Gbps 속도로 전송되기 때문에 속도가 훨씬 느려집니다. RoCE(RDMA over Converged Ethernet)라는 기술을 사용하여 이더넷을 통해 훈련할 수 있지만 하드웨어와 소프트웨어 측면 모두에서 많은 추가 작업이 필요하며 일반적으로 InfiniBand보다 안정성이 떨어집니다. 자세한 내용은 이 백서에서 확인할 수 있습니다: https://arxiv.org/pdf/2402.15627
또한 구성 및 관리에만 사용되는 보조 이더넷이 있어 BIOS(기본 입출력 시스템), 전원 공급 장치 및 기타 낮은 수준에 대한 액세스를 허용합니다. -레벨 머신 인터페이스의 제어 인터페이스입니다. 이 관리 네트워크가 없으면 USB 드라이버, 키보드 및 모니터를 통해 각 노드를 수동으로 설정해야 합니다. 수백 대의 기계가 있는 상황에서는 이는 지속 가능한 접근 방식이 아닙니다.
이 클러스터에서 고성능 교육을 달성하려면 모든 구성 요소(InfiniBand, 이더넷, GPU 및 노드 자체)가 거의 완벽하게 작동해야 합니다. 12,000개가 넘는 연결 중 하나라도 약간 불안정하면 전체 훈련 실행 속도가 느려질 수 있습니다.
이 글의 다음 내용은 모든 것을 완벽하고 안정적으로 실행하는 방법을 소개하는 것입니다.
절차: 베어메탈을 완벽하게 작동하는 클러스터로 전환하는 방법
각 머신 구성
관리 네트워크를 통해 클러스터에 대한 초기 이더넷 연결을 설정한 후 베이스보드 관리 컨트롤러(BMC/베이스보드 관리 컨트롤러)에 대한 액세스 인증서를 얻습니다. BMC는 호스트 시스템을 원격으로 모니터링하는 전용 서비스 프로세서이며 일반적으로 별도의 네트워크에 연결됩니다. 이를 통해 물리적으로 존재하는 것처럼 시스템을 작동할 수 있으며 하드웨어 상태, BIOS 설정 및 전원 관리를 위한 API도 추가로 제공합니다.
이러한 구성 요소를 장착한 후 소매를 걷어붙이고 클러스터 설정을 시작할 수 있습니다.
0단계: 먼저 시스템 구성
iDRAC(Dell의 베이스보드 관리 컨트롤러)를 사용하여 서버에 Ubuntu 22.04를 설치한 다음 이 운영 체제를 기반으로 다른 모든 것을 설정했습니다. iDRAC의 기능 중 하나는 로컬 컴퓨터에서 ISO 이미지를 설치 및 부팅할 수 있도록 하고 브라우저를 통해 가상 콘솔을 제공하는 것입니다. 이상적으로 이는 프로세스에서 유일한 수동 설치 단계입니다.
1단계: 각 머신에 운영 체제 설치
첫 번째 머신을 구성한 후 Ubuntu의 MAAS(Metal-as-a-Service) 소프트웨어 설치를 진행하여 나머지 서버를 구성합니다. PXE(Preboot Execution Environment Protocol) 부팅 및 자동화 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가 표시되지 않음 등이 있습니다. 우리는 이러한 문제를 자동으로 확인하고 재테스트를 위해 일부 시스템을 Dell에 반환했으며 데이터 센터 직원에게 적절한 작업 주문을 제출했습니다. 클러스터를 직접 구성하면 일부 시스템의 유지 관리를 기다리는 동안 정상적인 시스템을 즉시 사용할 수 있다는 이점이 있습니다.
3단계: 최소 실행 가능 관찰 가능 머신
각 서버에서 다음 설정을 진행합니다.
1.Docker(서비스 및 교육 작업을 더 쉽게 실행하기 위해)

2. 데이터 센터 GPU 드라이버
   3. Prometheus 노드 내보내기 도구(안정적인 하드웨어/운영 체제 표시 데이터 흐름을 내보내는 데 사용)
   4. DCGM 내보내기 도구(NVIDIA GPU에서 GPU 상태, 시계,
3. 모든 비 OS 기반 RAIDZ ZFS 풀은 드라이버가 실패하더라도 시스템이 계속 작동할 수 있도록 하는 동시에 무료로 투명한 압축을 제공합니다(특히 일반 텍스트 데이터 세트 및 반복 로그의 경우) 유용함 - 이 도구를 사용하면 일반적으로
   그런 다음 기본 GPU 진단을 실행하여 GPU가 일반적으로 작동하는지 확인합니다. 그렇지 않은 경우 일반적으로 몇 초 내에 발생합니다. 하드웨어 문제는 몇 시간 내에 발생합니다.
   이 기간 동안 400개 노드 전체에 동시에 패키지를 설치하려고 할 때 대역폭 병목 현상이 발생했습니다. 데이터 센터에 배포된 여러 구성 요소에 대해 고온 과열 경고를 받은 것은 이번이 처음입니다. 이러한 첫 번째 발열 문제는 펌웨어 업데이트를 통해 대부분 해결되었습니다.
   4단계: 단일 노드 GPU 훈련
   다음 단계는 각 머신이 실제 GPU 워크로드를 자체적으로 처리할 수 있는지 확인하는 것입니다. 많은 시스템에서는 이 작업을 수행할 수 없습니다.
   GPU 관련 오류 이러한 문제는 기본적으로 GPU 카드를 카드 슬롯에 다시 삽입하여 해결할 수 있습니다. 200파운드 서버를 랙 밖으로 밀어내고 사이에 있는 모든 케이블을 제거합니다. 케이스 덮개와 GPU를 제거한 다음 GPU를 제거하고 GPU를 다시 설치한 다음 케이블을 다시 연결하고 서버를 랙에 다시 밀어 넣습니다.
   Ubuntu 서버 로그에 따르면 GPU와 PCIe 버스 또는 네트워크 카드 사이의 많은 케이블에서 "제한된 너비: x4 여러 호스트에 영향을 미치는 기타 결함도 있습니다. Dell은 펌웨어 업그레이드와 관련된 몇 가지 문제를 해결하는 데 도움을 주었습니다.
   NVMe 드라이브에는 결함이 없었지만 터치 시 전체 시스템이 잠겼습니다.
   하드 드라이브는 Linux에서 무작위 순서로 나타나 MAAS에 혼란을 야기하고 운영 체제가 잘못된 드라이브에 설치되도록 합니다.
   온도 판독이 잘못되어 팬이 항상 최고 속도로 작동합니다. 그 이유는 NVIDIA 드라이버에 문제가 있을 수 있으며 드라이버 버전을 다운그레이드하면 해결됩니다.
   CPU의 동적 확장이 제어 불가능하여 작동 코어가 2GHz로 제한됩니다.
   직접 GPU-GPU 통신(GDR 또는 GPUDirect RDMA 피어 메모리 클라이언트)을 성공적으로 적용할 수 없습니다.
   InfiniBand 구성
   0단계: UFM 설치
   InfiniBand의 장점 중 하나는 중앙 집중식 설계로 전체 네트워크에 하나의 두뇌가 있다는 것입니다. 따라서 전체 네트워크 패브릭에서 320개의 네트워크 스위치 중 하나의 인스턴스만 처리하면 됩니다. 우리의 첫 번째 작업은 어떤 스위치가 어떤 기계에 연결되어 있는지 파악한 다음 이를 배선 다이어그램과 연결하고 스위치의 물리적 위치에 따라 이름을 바꾸는 것이었습니다.
   1단계: 재배선
   처음에 UFM은 패브릭에 있어야 하는 호스트는 물론이고 320개의 스위치도 감지할 수 없었습니다. 데이터 센터 파트너와 협의한 결과 스위치의 전원이 켜져 있고 배선되어 있음을 확인했지만 여전히 감지할 수 없었습니다. 네트워크 케이블링 목록을 조사한 후 우리는 네트워크 구조의 최상위 설계가 잘못되었음을 발견했습니다. 구조는 통합되는 대신 공통 라우팅 경로 없이 연결되지 않은 8개의 네트워크로 나누어졌습니다. 재배선 후에는 모든 물리적 연결이 새로운 설계와 일치하는지 확인하는 확인 단계를 추가했습니다.
   2단계: 1만 개의 온도 알람(alert)
   물리적 배선 문제를 해결한 후 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 つの重要な手順が含まれます:
4. 追加のコア モジュールを開始します
5. 即時のハングを防ぐために PCIe アクセス コントロール サービス (ACS) が無効になっていることを確認します
   ステップ 6: 「ゴールデン」サーバーを増幅します
   次の GPU クラスターを構築するときに使用します最新のハードウェアでは、経験則として、毎週約 3% のマシンに問題が発生するため、備えてください。
   ただし、説明する必要があります。すべてのマシンに均一に 3% の故障の可能性があるわけではありません。少数の未処理のマシンでは、適切に修理されるまでさまざまな問題が繰り返し発生します。これは、同じネットワーク構造内に多数のマシンがあることの利点を強調しています。したがって、モグラたたきで何が壊れているかを確認するように、大規模なトレーニングを実行するマシンをランダムに見つけるだけではなく、信頼できることがわかっているサーバー、つまり「ゴールデン」サーバーのスケーリングに重点を置くのが私たちのアプローチです。
   ステップ 7: メンテナンス
   InfiniBand のメンテナンスには主に、UFM アラームへの対応、障害のあるケーブルとトランシーバーの交換、および場合によってはより困難なエラー (スイッチの故障など) の診断が含まれます。通常、大規模なメンテナンスにつながる要因は 2 つあります:
6. ファームウェアの更新、特にクラスターの半分だけが更新を完了している場合、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 でメモリ不足エラーが発生する可能性があります。이 문제를 방지하기 위해 우리는 완전 결정론적 데이터 로더를 구현하여 에포크 또는 단계 번호에 연결하여 모든 충돌을 쉽게 재현할 수 있도록 했습니다. 데이터 로드를 비활성화하거나 가짜 데이터(예: 올 제로 데이터)를 교체하면 오류의 근본 원인이 데이터인지 확인하는 데 도움이 됩니다.
   마지막으로 메트릭 집계 방법을 통해 네트워크 및 일반 노드 상태 통계를 기록하는 것도 도움이 됩니다. 일시적인 이더넷 연결 끊김이나 디스크 공간 부족과 같은 문제는 유용한 오류 메시지로 나타나지 않을 수 있지만 수집된 데이터와 쉽게 연관될 수 있습니다.
   스택 추적 없이 중단됩니다(나중에 시간 초과될 수 있음)
   이러한 유형의 오류를 디버깅하는 것은 유용한 정보가 부족하고 오류를 안정적으로 재현하기 어렵기 때문에 좌절스러울 수 있습니다.
   가장 기억에 남는 오류 유형 중 하나는 다음과 같은 오류 메시지와 함께 표시됩니다.
   

   Watchdog caught collective operation timeout:WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) ran for 600351 milliseconds before timing out

   
   이 오류 메시지는 훈련 실행 시 모든 GPU 작업자가 표시합니다.

이는 하나 이상의 호스트가 NCCL 작업을 완료하지 못했거나 NCCL 및 InfiniBand 연결이 중단되어 NCCL_TIMEOUT 시간 초과에 도달할 때까지 다른 모든 호스트가 동시에 텐서 작업에 멈춰 있음을 의미합니다. 안타깝게도 NCCL 소프트웨어 라이브러리의 특성상 어떤 호스트가 문제를 일으키는지 찾기가 어렵습니다.

NCCL 소프트웨어 라이브러리의 로깅을 일부 수정했습니다. 분기 버전(https://github.com/boweiliu/nccl)을 참조하세요. 이를 통해 충돌이 발생할 때 수행 중인 메시지나 작업을 더 잘 드러낼 수 있으므로 어떤 호스트나 GPU가 실행을 차단할 수 있는지 확인할 수 있습니다.

오작동하는 호스트를 식별하려면 어떤 호스트가 특정 로그 메시지를 생성하지 않는지 파악해야 하는 경우가 많습니다. 이러한 메시지가 없으면 이 호스트의 작업자가 뒤처졌거나 충돌했음을 나타냅니다.

사용 가능한 오류 메시지가 없는 기타 응답하지 않는 상황은 일반적으로 NVIDIA 드라이버 또는 NVIDIA Docker 통신 드라이버가 잠기는 원인이 되는 앞에서 언급한 Xid/SXid/ECC 오류와 같은 하드웨어 관련 문제와 관련이 있습니다. NCCL 정지를 드라이버 정지, 경합 조건 또는 Python 코드의 교착 상태와 구별하기 위해 Py-Spy 및 GDB(GNU 프로젝트 디버거)와 같은 도구를 사용하여 정지된 프로세스를 실시간으로 디버그합니다. 이 접근 방식을 사용하여 한 가지 특정 문제가 발견되었습니다. 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배 감소)가 발생하며 이는 매우 자주 발생합니다.

이것은 기본적으로 체크포인트 또는 평가에 관한 것입니다. 이는 에포크 수 또는 검증 단계 수를 확인하여 확인할 수 있습니다. 귀찮게도 MFU가 비정상일 때 자동 경고를 설정하면 오탐(false positive)이 많이 발생합니다.

• 특정 데이터 배치를 처리하는 동안 갑자기 엄청난 속도 저하(10배 감소)가 발생합니다.

이는 무작위로 매우 드물게 발생하며(아마 15분에 한 번) 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 fat-tree 설계에서 인접한 호스트를 선호하는 반면 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% 더 많은 머신을 사용하면 머신 오류가 발생할 경우 교육을 쉽게 다시 시작할 수 있어 도움이 될 수 있습니다. 각 시스템이 다른 모든 시스템과 긴밀하게 연결되도록 클러스터 네트워킹을 설정하면 해당 시스템의 작업 하위 집합을 사용할 수 있습니다.
• 학습 중에 직면하는 모든 문제는 다시 발생하기 때문에 발생하는 모든 하드웨어 또는 소프트웨어 오류에 대한 테스트 및 자동화된 솔루션을 작성하는 것이 좋습니다. 마찬가지로 모든 모호한 오류 메시지에 대해서는 오류를 더 잘 설명하는 도구를 작성하는 것이 좋습니다.
• 재현성은 우수한 과학 연구의 핵심입니다. 우리가 즉시 채택한 원칙 중 하나는 가장 단순한 것에서도 "한 번에 하나만 변경하라"는 것이었습니다.
• 신뢰하면서도 검증도 해보세요. 외부 도구를 가져오거나 새로운 인력을 영입할 때마다(회사 내부 또는 외부에서) 그들이 주장하는 내용을 다시 확인합니다. 특히 후속 단계가 해당 주장에 따라 달라지는 경우 더욱 그렇습니다.

요약

대규모 언어 모델을 교육하려면 처음부터 복잡한 인프라가 필요합니다. 우리는 우리가 운영하는 시스템을 완전히 이해하는 것이 중요하고 그것이 더 효율적이라고 믿기 때문에 인프라 설정의 세부 사항에 깊이 관여하기로 결정했습니다.

이제 프로세스를 완료한 후 이 접근 방식을 채택하게 되어 기쁩니다. 인프라를 완전히 제어하고 모든 추상화 수준에서 쉽게 디버깅할 수 있는 능력이 중요한 가치임이 입증되었습니다. 이 프로세스에는 많은 감독과 반복이 필요했지만 이를 통해 기본 워크플로를 깊이 이해하고, 호스트 상태를 보장하는 도구 세트를 구축하고, 지속적이고 원활한 교육을 보장하기 위해 시스템을 자동화하는 방법을 배우고, 궁극적으로 최첨단 언어 모델을 빠르고 반복적으로 교육할 수 있는 인프라 세트입니다.

이 인프라 구축 프로세스는 AI 에이전트를 연구하고 구축하기 위한 기본 방법론을 반영합니다. 세부 사항을 살펴보고

위 내용은 베어메탈부터 700억 개의 매개변수가 있는 대형 모델까지 튜토리얼과 바로 사용할 수 있는 스크립트가 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!