소식

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

imbue.com에서 선택됨

작성자: 임부 팀

기계 심장 편집

편집자: 팬더

우리는 LLM이 대규모 데이터를 사용하여 대규모 컴퓨터 클러스터에서 훈련된다는 것을 알고 있습니다. Machine Heart는 LLM 훈련 프로세스를 지원하고 개선하기 위한 다양한 방법과 기술을 도입했습니다. 오늘 우리가 공유하고 싶은 기사는 기본 기술을 심층적으로 살펴보고 운영 체제도 없는 수많은 "베어 메탈"을 LLM 교육을 위한 컴퓨터 클러스터로 전환하는 방법을 소개하는 기사입니다.

이 기사는 기계가 생각하는 방식을 이해하여 일반 지능을 달성하기 위해 노력하는 AI 스타트업 Imbue에서 발췌한 것입니다.

물론, 운영 체제가 없는 "베어메탈" 무리를 LLM 훈련을 위한 컴퓨터 클러스터로 전환하는 것은 탐색과 시행착오로 가득 찬 쉬운 과정이 아니지만 Imbue는 마침내 700억 개의 매개변수를 사용하여 LLM을 성공적으로 훈련하고 축적했습니다. 그 과정에서 많은 유용한 경험을 했습니다.

이 기사에서는 자체 LLM 교육 인프라를 구축하는 팀의 전체 프로세스에 대한 심층적인 소개를 제공하고 모니터링, 검사 및 오류 수정을 용이하게 하기 위해 작성한 많은 도구와 스크립트를 공유합니다.

자신만의 LLM 교육 인프라를 구축하는 데 관심이 있거나 LLM이 어떻게 만들어지는지 궁금하다면 이 기사를 읽고 수집할 가치가 있습니다.

다음은 Imbue팀 글의 원문입니다.

소개

우리의 소규모 연구원 및 엔지니어 팀은 자체 인프라에서 처음부터 700억 개의 매개변수 모델을 훈련하는 데 몇 달을 보냈으며 이 모델은 추론 관련 작업에서 제로샷 모델보다 성능이 뛰어났습니다.

오늘은 초기 클러스터 구성과 운영체제 설치부터 훈련 중 오류 발생 시 자동 복구 설정까지 필요한 인프라를 설정하는 과정을 공유합니다. 각 단계에서 직면한 과제와 솔루션을 자세히 설명합니다. 이러한 학습 외에도 우리는 다른 팀이 자체 모델 교육을 위한 안정적인 인프라를 더 쉽게 만들 수 있도록 개발한 많은 스크립트를 출시할 예정입니다.

프로세스 전반에 걸쳐 우리 엔지니어 팀은 Bolt Park와 협력하여 컴퓨터 클러스터를 준비하고 생산 애플리케이션의 기반을 구축했습니다. 이 전체 프로세스에는 다음이 포함됩니다.

1. 각 머신 구성

2. InfiniBand 구성

3. 기계가 완전히 건강한지 확인하십시오

4. 일반적인 훈련 문제 진단

5. 인프라 도구 개선

각 단계는 아래에 자세히 설명되어 있습니다.

배경: 어떻게 만들어졌는가

계산을 수행하는 우리의 목표는 대규모 언어 모델을 신속하게 실험하는 것입니다. 이를 위해서는 다수의 고속 GPU가 필요하고, 이들 GPU 간의 고속 통신이 필요합니다.

이 문서에서는 511대의 컴퓨터에 분산된 4088개의 H100 GPU 또는 컴퓨터당 8개의 GPU를 포함하는 클러스터에 중점을 둘 것입니다. GPU가 장착된 컴퓨터가 511대인 이유는 InfiniBand 네트워크를 관리하는 역할을 하는 Unified Fabric Manager 노드용으로 일부 연결을 예약해야 하기 때문입니다. 511 GPU 장착 호스트에서 각 GPU는 ConnectX-7 네트워크 카드에 직접 연결되어 InfiniBand 네트워크의 모든 GPU에 400Gbps로 데이터를 전송할 수 있습니다.

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) 소프트웨어 설치를 진행하여 나머지 서버 구성을 돕습니다. iDRAC 부팅 및 자동화 도구는 PXE(Preboot Execution Environment Protocol)를 사용하여 각 시스템에 네트워크에서 부팅하도록 지시하고 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 내보내기 도구(GPU 상태, 시계, 활용도 등 NVIDIA GPU에서 추가 표시기 데이터를 내보내는 데 사용됨)

5. 운영 체제가 아닌 모든 드라이버에 대한 RAIDZ ZFS 풀. 드라이버에 오류가 발생하더라도 시스템이 계속 작동할 수 있도록 하는 동시에 무료로 투명한 압축을 제공합니다. 이는 특히 일반 텍스트 데이터 세트 및 반복 로그에 유용합니다. 상대적으로 이 방법을 사용하면 도구를 사용하면 일반적으로 이 도구를 사용하지 않을 때보다 사용 가능한 공간이 최대 10배 늘어납니다.)

그런 다음 기본 GPU 진단을 실행하여 GPU가 일반적으로 제대로 작동하는지 확인합니다. 그렇지 않은 경우 일반적으로 몇 시간 내에 하드웨어 문제가 발생합니다.

이 기간 동안 400개 노드 모두에 패키지를 동시에 설치하려고 하면 대역폭 병목 현상이 발생했습니다. 데이터 센터에 배포된 여러 구성 요소에 대해 고온 과열 경고를 받은 것은 이번이 처음입니다. 이러한 첫 번째 발열 문제는 펌웨어 업데이트를 통해 대부분 해결되었습니다.

4단계: 단일 노드 GPU 훈련

다음 단계는 각 시스템이 자체적으로 실제 GPU 워크로드를 처리할 수 있는지 확인하는 것입니다. 많은 기계에서는 이 작업을 수행할 수 없으며 다음과 같은 문제가 있습니다.

일반적으로 GPU 카드를 카드 슬롯에 다시 삽입하면 해결될 수 있는 GPU 관련 오류: 200파운드 서버를 랙 밖으로 밀어내고 덮개와 GPU 사이의 모든 케이블을 제거한 다음 GPU를 제거하고 GPU를 다시 설치한 다음 케이블을 다시 연결하고 서버를 랙에 다시 밀어 넣습니다.

Ubuntu 서버 로그에 따르면 GPU와 PCIe 버스 또는 네트워크 카드 사이의 많은 케이블에서 "제한된 너비: x4 < x16"이라는 오류가 발생했습니다. PCIe 스위치 버스 펌웨어를 업데이트한 후 호스트의 약 4분의 1이 내부 PCIe 케이블을 다시 연결해야 한다는 사실을 발견했습니다. 아마도 케이스와 GPU 사이의 케이블이 매우 약하기 때문일 것입니다. 즉, GPU에서 유지 관리가 수행될 때마다 이러한 케이블이 밀려나거나 당겨집니다.

여러 호스트에도 영향을 미치는 몇 가지 기타 중단이 발생했습니다. Dell은 펌웨어 업그레이드와 관련된 몇 가지 문제를 해결하는 데 도움을 주었습니다.

NVMe 드라이브에는 결함이 나타나지 않았지만 만졌을 때 전체 시스템이 잠겼습니다.

Linux에서는 하드 드라이브가 무작위 순서로 나타나 MAAS에 혼란을 일으키고 운영 체제가 잘못된 드라이브에 설치되는 원인이 됩니다.

온도 판독값이 잘못되어 팬이 항상 최고 속도로 작동합니다. 그 이유는 NVIDIA 드라이버에 문제가 있을 수 있으며 드라이버 버전을 다운그레이드하면 해결됩니다.

CPU의 동적 확장이 통제 불능 상태가 되어 작동 코어가 2GHz로 제한되었습니다.

직접 GPU-GPU 통신(GDR 또는 GPUDirect RDMA 피어 메모리 클라이언트)을 성공적으로 적용할 수 없습니다.

InfiniBand 구성

0단계: UFM 설치

InfiniBand의 장점 중 하나는 중앙 집중식 설계로 전체 네트워크에 하나의 두뇌가 있다는 것입니다. 따라서 전체 네트워크 구조에서 320개의 네트워크 스위치 중 하나의 인스턴스만 처리하면 됩니다. 우리의 첫 번째 작업은 어떤 스위치가 어떤 기계에 연결되어 있는지 파악한 다음 이를 배선 다이어그램과 연결하고 스위치의 물리적 위치에 따라 이름을 바꾸는 것이었습니다.

1단계: 재배선

처음에 UFM은 패브릭에 존재해야 하는 호스트는 물론이고 320개의 스위치도 감지할 수 없었습니다. 데이터 센터 파트너와 협의한 결과 스위치의 전원이 켜져 있고 배선되어 있음을 확인했지만 여전히 감지할 수 없었습니다. 네트워크 케이블링 목록을 조사한 후 우리는 네트워크 구조의 최상위 설계가 잘못되었음을 발견했습니다. 구조는 통합되는 대신 공통 라우팅 경로 없이 연결되지 않은 8개의 네트워크로 나누어졌습니다. 재배선 후에는 모든 물리적 연결이 새로운 설계와 일치하는지 확인하는 확인 단계를 추가했습니다.

2단계: 1만 개의 온도 알람(경고)

물리적 배선 문제가 해결된 후 InfiniBand는 네트워크 패브릭의 모든 InfiniBand 스위치에 대한 연결을 성공적으로 설정했습니다. 그러나 거의 모든 스위치 포트는 데이터를 전송하지 않는데도 과도한 온도를 보고하기 시작했으며 때로는 70°C를 초과하는 경우도 있었습니다. 우리는 이 문제가 동일한 랙에 있는 스위치 사이의 열린 공간에서 발생하여 뜨거운 공기가 전면으로 다시 흘러가는 것을 발견했습니다. 데이터 센터 파트너는 문제를 신속하게 진단하고 적절한 해결 방법을 개발하는 데 도움을 주었습니다.

3단계: 알람 1,800개

또한 많은 포트는 오류율이 높거나 정상 상태와 손상된 상태 사이를 오가는 현상을 "플래핑(flapping)"이라고 합니다. 이러한 문제는 포트가 실제로 사용될 때만 발생하므로 전체 구조가 10,000개의 고도로 중복된 링크로 구성되어 있기 때문에 사전에 감지하기가 어렵습니다. 우리의 데이터 센터 파트너는 알람 포트를 청소하고 다시 설치하는 데 도움을 주었으며 교체를 기다리는 동안 나머지 알람 트랜시버를 비활성화했습니다.

InfiniBand는 하드웨어 오류에 대한 복원력이 있지만 패브릭의 약 10%에 오류가 발생하기 시작하면 적응형 라우팅과 같은 기능이 가끔씩 끊어지는 링크를 처리하기 위해 안정적으로 작동하지 않습니다.

이 기간 동안 우리는 100~200대의 머신을 사용하여 다중 노드 교육을 성공적으로 실행했습니다. 우리의 프로세스는 다소 즉흥적으로 진행됩니다. 때때로 무작위 노드 세트를 가동하고 성능을 관찰한 다음 가능한 많은 노드를 계속 실행하려고 노력합니다. 이 방법을 사용하면 InfiniBand 네트워크 구조의 신뢰할 수 있는 하위 집합을 찾을 수 있지만 훈련에 사용되는 노드 집합을 변경해야 할 때마다 기본 InfiniBand 링크가 변경되므로 매우 어렵습니다.

4단계: InfiniBand가 미친 듯이 타오르고 있습니다.

InfiniBand 문제를 보다 효율적으로 진단하기 위해 패브릭의 모든 포트를 통해 동시에 최대한 많은 데이터를 푸시하는 전체 클러스터에 대한 워크로드를 설계했습니다. 이는 SXM(서버 PCIe 모듈) 슬롯을 통한 GPU 통신용 NVLink를 사용하여 개별 노드 간 통신을 최적화하기 위해 NCCL을 사용해야 하는 전체 클러스터에서 대규모 전체 축소 워크로드를 실행하는 것과는 다릅니다.

대신, 우리는 무차별적인 접근 방식을 선택했고 쉽게 성공했습니다. UFM은 대부분의 포트의 데이터 전송량이 이론상 용량의 97%를 초과하면 경고를 발행하기 시작하며 일부 스위치는 일시적으로 다운됩니다. 우리가 생각했던 모든 포트는 충분히 견고했고, 나머지 포트는 수리를 위해 비활성화되거나 제거되었습니다.

5단계: GPUDirect RDMA

CPU 컴퓨팅 오버헤드를 발생시키지 않고 GPU 통신을 허용하기 위해 InfiniBand 네트워크 카드 간의 직접 통신을 허용하는 GPUDirect RDMA라는 기능을 활성화했습니다. 여기에는 두 가지 주요 단계가 포함됩니다.

1. 추가 커널 모듈 시작

2. 즉시 중단(즉시 중단)을 방지하려면 PCIe 액세스 제어 서비스(ACS)가 비활성화되어 있는지 확인하십시오.

6단계: "골드" 서버 확장

최신 하드웨어를 사용하여 GPU 클러스터를 구축하려면 경험상 매주 약 3%의 시스템이 실패할 수 있도록 준비해야 합니다.

그러나 모든 기계의 고장 확률이 3%로 균일한 것은 아니지만, 처리되지 않은 소수의 기계는 제대로 수리될 때까지 다양한 문제가 반복적으로 발생한다는 점에 유의해야 합니다. 이는 동일한 네트워크 구조에 많은 수의 시스템을 보유하는 이점을 강조합니다. 따라서 두더지를 두들겨 두들겨 두들겨서 고장난 부분을 확인하는 등 대규모 교육을 실행할 무작위 기계를 찾는 대신, 신뢰할 수 있는 것으로 알려진 서버, 즉 "황금" 서버를 확장하는 데 초점을 맞추는 것이 우리의 접근 방식입니다.

7단계: 유지 관리

InfiniBand의 유지 관리에는 주로 UFM 경보에 대한 응답, 결함이 있는 케이블 및 트랜시버 교체, 때로는 더 어려운 오류(예: 스위치 오류) 진단이 포함됩니다. 일반적으로 대규모 유지 관리를 초래하는 두 가지 요소가 있습니다.

1. 특히 클러스터의 절반만 업데이트를 완료한 경우 펌웨어 업데이트로 인해 UFM 상태가 손상되고 모든 InfiniBand 스위치에서 UFM을 다시 시작해야 할 수 있습니다.

2. GPU 상자는 동시에 대규모로 다시 시작되므로 UFM 상태에 많은 업데이트가 주입될 수 있으며 UFM 서비스를 다시 시작해야 할 수도 있습니다.

기계가 완전히 건강한지 확인하십시오

그 과정에서 우리는 개별 기계가 오작동하거나 훈련 속도를 늦출 수 있는 여러 가지 방법을 발견했습니다. 이러한 오류 모드 중 다수는 즉시 명백하지 않으므로 호스트가 충분히 건강한지 확인하기 위해 여러 가지 상태 확인 스크립트를 작성했습니다. 우리는 여기에 코드를 게시했습니다: https://github.com/imbue-ai/cluster-health

이러한 상태 확인 중 다수는 런타임 환경에만 적용되며 반드시 기본 하드웨어와 관련이 있는 것은 아니며 수정 또는 자동화가 반드시 쉬운 것도 아닙니다. 이는 의도적으로 설계된 것입니다. 기계를 훈련할 수 있도록 준비한다는 전반적인 목표를 달성하기 위해 우리는 간단하게 예 또는 아니요로 대답할 수 있고 수많은 세부 사항을 요약할 수 있는 단일 진입점을 원했습니다.

GPU 상태 확인

GPU 개수가 올바른지, ECC(Error Correction Code) 검사가 활성화되어 있는지, ECC 오류가 없는지 확인했습니다. 또한 NVLink 토폴로지(GPU를 서로 연결하는)가 오류 없이 실행되고 있는지 확인했습니다.

디스크 공간 상태 점검

호스트의 디스크 공간 활용도가 95%를 초과하는지 확인했습니다.

도커 상태 확인

Docker가 GPU가 연결된 컨테이너를 실행할 수 있는지(즉, NVIDIA Container Runtime이 제대로 작동하는지), 모니터링/분석과 관련된 Docker 컨테이너가 활성화되고 올바른 호스트 권한을 가지고 있는지 확인했습니다.

Dmesg 상태 확인

dmesg에서 하드웨어 Xids 또는 SXid 오류(NVIDIA GPU 또는 GPU 간 NVIDIA 스위치로 인한 오류)를 확인했습니다. 또한 모든 dmesg 로그 줄을 읽어 공통/예상 로그 줄 목록으로 분류할 수 있는지 확인합니다.

iDRAC 상태 점검

치명적이지 않은 오류 메시지를 무시한 시스템에서 iDRAC 오류를 확인했습니다. 이는 Dell 컴퓨터에만 적용되는 검사이므로 당사의 오픈 소스 코드에는 포함되어 있지 않습니다.

디스크 상태 점검

zpool이 설치되어 있는지, Docker가 zpool에 제대로 연결되어 있는지, CPU를 잠그지 않고도 실제로 zpool에 연결할 수 있는지 확인했습니다.

InfiniBand 상태 점검

InfiniBand의 오류율이 증가했는지, 드라이버 펌웨어가 최신 버전인지 확인했습니다.

Nvlink 상태 확인

머신에서 NVLink 오류를 확인했습니다. 실제로 이로 인해 훈련 ​​실패가 발생하지는 않지만 훈련 속도가 느려질 수 있습니다.

동독 상태 점검

머신에서 GDR이 활성화되어 있는지 확인했습니다.

VBIOS 상태 점검

GPU의 VBIOS 버전과 H100 베이스보드 펌웨어가 최신인지 확인했습니다.

플린트 건강검진

우리는 flint와 hca_self_test를 사용하여 Mellanox OFED 드라이버, 네트워크 카드 펌웨어 및 트랜시버 펌웨어가 올바른 버전인지, NVIDIA 드라이버에 맞게 올바르게 컴파일되었는지 확인했습니다.

PSB 상태 점검

GPU, PSB(PCIe 스위치 버스) 및 네트워크 카드 간의 연결 속도와 너비가 예상한 것인지 확인하기 위해 PCIe 장치에 쿼리했습니다. 또한 스위치 펌웨어가 최신인지 확인했습니다. 이 스크립트는 Imbue가 아닌 Dell에서 개발한 것이므로 지금은 공유할 수 없습니다.

이러한 빠른 상태 확인 외에도 다음과 같은 좀 더 복잡한 상태 확인도 실행합니다.

PyTorch를 통해 행렬 계산을 초기화하고 NVLink 대역폭과 GPU 계산 속도 및 메모리를 측정합니다. InfiniBand 및 NVLink를 테스트하기 위해 적절한 GDR 플래그를 설정했습니다.

ib_write_bw 및 –use_cuda를 사용하여 IB 카드를 통해 데이터를 전송하고 PCIe 및 InfiniBand 카드 대역폭을 측정합니다. 이 과정은 펄럭이는 InfiniBand 링크가 발견되었는지 확인하기 위해 오랜 시간(약 15분) 동안 지속되었습니다.

다중 노드 진단 실행을 실행하여 NCCL 초기화 기능과 무작위로 중단되는지 여부를 확인하십시오. 일시 중지가 있는 경우 포크된 NCCL 코드는 추가 로깅을 추가합니다. 문제를 감지하는 데 12~24시간이 걸리므로 일반적으로 새 노드에서 또는 문제가 의심되는 경우에만 이 작업을 실행합니다.

GPU 클럭 조절 이벤트가 있는지 DCGM 내보내기를 확인하세요(예상되는 gpu_idle 및 power_cap 제외). 이러한 전원 이벤트를 확인하는 가장 좋은 방법은 모든 GPU, InfiniBand 카드, CPU 및 디스크를 동시에 확인하는 다중 노드 교육을 실행하는 것입니다.

일반적인 교육 문제 진단

하드웨어가 제대로 작동하면 교육을 시작할 수 있습니다.

이 섹션에서는 클러스터에서 대규모 언어 모델 교육을 실행한 경험을 바탕으로 몇 가지 구체적인 디버깅 단계와 통찰력을 공유합니다.

시작 시 충돌이 발생함

어떤 면에서 이것은 (이론적으로) 재현 및 반복이 쉽기 때문에 만날 수 있는 최고의 버그입니다.

먼저 코드가 올바른 버전, 구성 및 환경 변수에서 실행되고 있는지 확인했습니다. 기본적이지만 스타트업 교육 프로세스를 재현 가능하고 쉽게 확인할 수 있도록 하는 것이 매우 중요하다고 생각했습니다. 한 가지 이유는 Docker 이미지 캐싱이나 불투명한 비밀 구성과 같은 중간 추상화로 인해 혼란이 발생할 수 있기 때문입니다.

우리가 수행하는 또 다른 기본 점검은 모든 시스템이 온라인 상태인지, 내보낸 스택 추적이나 로그를 쉽게 집계하고 검사할 수 있는지 확인하는 것입니다. Loki, Prometheus 및 Grafana 소프트웨어 스택을 사용했지만 적합한 로그 집계 또는 추적 SaaS 도구를 사용하면 됩니다. 이러한 훈련 실행은 본질적으로 동기식이며 분산되어 있기 때문에 첫 번째 오류로 인해 관련 없는 오류가 연쇄적으로 발생하는 경우가 많습니다. 여기에서 상태 점검은 손상된 하드 드라이브, 누락되거나 유효하지 않은 GPU 등의 오류를 즉시 감지하는 데도 도움이 될 수 있습니다.

우리는 장애 발생 시 자동으로 다시 시작하는 시스템을 구축했습니다. 이를 통해 여러 다시 시작으로 인한 혼란스러운 오류를 방지하기 위해 로그 및 오류 집계가 더욱 중요해졌습니다. 우리가 직면하는 몇 가지 일반적인 오류는 다음과 같습니다.

1. "정렬 순서는 순위에 따라 다릅니다. 순위 0은 43개의 매개변수를 모두 수집하고 순위 1228은 1개의 매개변수를 모두 수집합니다."와 같은 오류. 우리는 이것이 PyTorch의 FSDP(Fully Sharded Data Parallel) 구현의 이상한 기능이라는 것을 발견했으며, 이는 재시작으로 해결되었습니다.

2. 다음과 같은 GPU 메모리 부족(OOM) 오류: "CUDA out of memory. Tried to 할당..." 구성과 코드를 여러 번 확인하고 최근 코드 수정 사항을 실행 취소합니다(작업 중 잘못된 PyTorch 장치 사양으로 인해). 시작되어 GPU#0의 과도한 사용으로 인해 이러한 문제가 해결되었습니다.

3. CPU/RAM 메모리 부족(OOM) 오류 이러한 오류는 오류 로그에서 찾기가 쉽지 않으며 일반적으로 Docker 컨테이너 외부 호스트의 dmesg 로그를 통해 감지할 수 있습니다. OOM Killer가 포크된 프로세스나 네트워크 피어를 중지하기 위해 호출하면 주로 CalledProcessError 또는 ConnectionError로 나타나는 것을 볼 수 있습니다. dmesg에서 OOM Killer 호출이 감지되면 상태 확인을 중단하고 상자를 재부팅하는 것을 선호합니다. 또한 적절한 수동 가비지 수집을 위한 코드 경로를 확인했으며(이 기능을 비활성화하는 방법은 아래 섹션에 있음) 계산을 수행하거나 텐서를 CPU로 이동하려는 예상치 못한 시도도 확인했습니다.

훈련 중 충돌

첫 번째 우선 순위는 모든 상태 확인을 자동으로 다시 실행한 다음 비정상 호스트가 발견되지 않으면 다시 시작할 수 있도록 시스템을 자동화하는 것입니다. Xid 및 SXid 오류를 포함한 일부 무작위 하드웨어 오류가 발생했습니다. 이러한 오류로 인해 의미 있는 Python 스택 추적을 내보내지 않고 실행이 중단될 수 있습니다. 행 다시 매핑과 같은 일부 문제는 재부팅하여 복구할 수 있습니다. 수정할 수 없는 ECC 오류와 같은 다른 문제에는 하드웨어 유지 관리나 부품 교체가 필요한 경우가 많습니다.

또한 잘못된 훈련 데이터가 충돌을 일으킬 수도 있음을 관찰했습니다. 예를 들어, 코퍼스에 매우 큰 단일 문서가 있는 경우 GPU 또는 CPU에서 메모리 부족 오류가 발생할 수 있습니다. 이 문제를 방지하기 위해 우리는 완전 결정론적 데이터 로더를 사용하여 에포크 또는 단계 번호에 연결하여 모든 충돌을 쉽게 재현할 수 있도록 합니다. 데이터 로드를 비활성화하거나 가짜 데이터(예: 올 제로 데이터)를 교체하면 오류의 근본 원인이 데이터인지 확인하는 데 도움이 됩니다.

마지막으로 메트릭 집계 방법을 통해 네트워크 및 일반 노드 상태 통계를 기록하는 것도 도움이 될 수 있습니다. 일시적인 이더넷 연결 끊김이나 디스크 공간 부족과 같은 문제는 유용한 오류 메시지로 나타나지 않을 수 있지만 수집된 데이터와 쉽게 연관될 수 있습니다.

스택 추적 없이 중단됨(나중에 시간 초과 문제가 발생할 수 있음)

이러한 문제에 대한 유용한 정보가 부족하고 문제를 안정적으로 재현하기 어렵기 때문에 이러한 유형의 오류를 디버깅하는 것은 실망스러울 수 있습니다.

가장 기억에 남는 오류 유형 중 하나는 다음과 같은 오류 메시지와 함께 표시됩니다.

감시견이 집합 작업 시간 초과를 포착했습니다.WorkNCCL(SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout(ms)=600000)은 시간 초과되기 전에 600351밀리초 동안 실행되었습니다.

그리고 훈련 실행에 참여한 모든 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 미만)에서 즉시 훈련을 시작하고 안정성을 유지합니다.

이는 T2 또는 T3 레이어 스위치 충돌과 같은 InfiniBand 네트워크 연결의 하드웨어 문제일 가능성이 높습니다. GPU와 NIC 사이의 하드웨어 문제로 인해 이러한 상황이 발생할 수도 있으며, 이 경우 dmesg는 다음과 같은 오류를 보고합니다: PCIe x16 레인 제한…

예상 MFU의 30%에서 즉시 훈련을 시작하고 꾸준히 유지하십시오.

이는 한 호스트(NVIDIA 피어 메모리)의 잘못된 GDR 설정 또는 잘못된 GDR 환경 변수로 인해 발생할 수 있습니다.

예상 MFU의 약 60-80%에서 즉시 훈련을 시작하고 꾸준히 유지하십시오.

가장 일반적인 원인은 InfiniBand 링크 품질이 좋지 않거나 결함이 있는 것입니다. 특히 단일 GPU의 InfiniBand NIC 관련 오류로 인해 NCCL이 기본 NVLink를 통해 트래픽을 라우팅하고 동일한 호스트의 다른 GPU에서 NIC를 사용하려고 시도합니다. CPU 조절로 인해 이 문제가 발생할 수도 있으며, 일부 호스트에서 BIOS 설정을 조정해야 합니다.

특정 데이터 배치를 처리할 때 갑자기 엄청난 속도 저하(10배 감소)가 발생하며 이는 매우 자주 발생합니다.

이는 기본적으로 체크포인트 또는 평가에 관한 것입니다. 이는 시대 또는 단계 수를 확인하여 확인할 수 있습니다. 귀찮게도 MFU가 비정상일 때 자동 알람을 설정하면 잘못된 알람이 많이 나타납니다.

특정 데이터 배치를 처리할 때 급격한 속도 저하(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/s입니다. 수백 명의 작업자가 데이터 세트와 모델 체크포인트를 동시에 다운로드하면 이 대역폭이 빠르게 포화될 수 있습니다.

이를 위해 우리는 클라우드 스토리지의 미러로 클러스터 내부에 로컬 파일 시스템을 구축하기로 결정했습니다. 이는 본질적으로 S3에서 읽는 파일의 양을 줄일 수 있는 캐시 공간입니다. 클러스터 이탈(예: 유지 관리를 위해 시스템이 비활성화되거나 교체되는 경우)을 고려하기 위해 각 파일에 대해 3개의 복사본이 있으며 일관된 해싱을 사용하여 로드를 균등하게 분산하여 클러스터 이탈 중에 성능을 최대화합니다. 클러스터의 디스크 공간이 제한되어 있기 때문에 파일의 수명 주기를 추적하고 더 이상 유용하지 않은 파일을 제거하는 도구를 개발해야 했습니다.

로컬 분산 Docker 레지스트리

우리는 Docker 이미지를 지점 간 전송을 위한 훌륭한 오픈 소스 소프트웨어인 Kraken을 사용했습니다. 우리는 소프트웨어에 거의 문제가 없었는데, 이는 우리 작업과 구현의 복잡성을 고려하면 매우 놀라운 일이었습니다. 도구 주소: https://github.com/uber/kraken

다양한 성능 모니터링 도구

기본 Torch 분석기와 NVIDIA의 Nsight 시스템을 설정했습니다. 후자는 정방향/역방향 패스와 NCCL 통신에 필요한 정확한 시간을 이해하는 데 도움이 되며, 더 나아가 주어진 모델 크기와 작업자 수가 병목 현상이 될지 여부를 판단하는 데도 도움이 됩니다. 그러나 Nsight Systems는 성능 모니터링 이벤트와 관련된 보안 검사를 비활성화해야 하는 권한 있는 모드에서 Docker를 실행해야 하고 구성을 저장하려면 전체 훈련 프로세스를 중지해야 하는 경우가 많기 때문에 사용하기가 약간 어렵습니다.

또한 우리는 느린 훈련 배치를 감지하고 그 가능한 원인을 이해하는 도구를 작성했습니다. 우리는 이것이 유용하다고 생각했습니다. 가장 유용한 도구는 각 배치에 소요되는 시간을 모니터링하고 배치가 너무 느린 경우 작업자의 스택 추적을 삭제하므로 사소한 하드웨어 또는 소프트웨어 문제가 있는 호스트를 더 쉽게 찾을 수 있습니다.

장애가 발생한 호스트를 찾기 위해 시스템을 여러 그룹으로 나누기

클러스터를 사용하고 처음 몇 달 동안(상태 확인이 지금처럼 철저하지 않았을 때) 머신 그룹에 대한 교육을 하다가 오류가 발생하는 상황이 자주 발생했지만 어떤 머신에 문제가 있는지 명확하지 않았습니다. . 질문. 결함이 있는 호스트를 찾기 위해 우리는 머신 세트를 여러 그룹으로 쉽게 분할하고 각 머신 그룹에 대해 소규모 교육을 실행할 수 있는 도구를 개발했습니다.

예를 들어, 48개 머신에 대한 훈련 실행이 실패하면 각각 8개 머신으로 구성된 6개 그룹에서 소규모 트레이닝 실행을 실행한 다음 각각 6개 머신으로 구성된 8개 그룹에서 소규모 트레이닝을 실행합니다. 일반적으로 두 단계 중 한 번만 실행하면 실패하므로 두 단계 모두에서 실패하는 시스템에 결함이 있다는 결론을 내릴 수 있다는 확신을 갖게 됩니다.

성찰과 교훈

인프라를 설정하고 유지 관리하는 과정에서 우리는 몇 가지 유용한 교훈을 배웠습니다.

유용한 접근 방식 중 하나는 기계의 위치를 ​​바꾸는 것입니다. 런타임 시 필요한 것보다 10~20% 더 많은 머신을 사용하면 머신 오류가 발생할 경우 교육을 쉽게 다시 시작할 수 있어 도움이 될 수 있습니다. 각 시스템이 다른 모든 시스템에 긴밀하게 연결되도록 클러스터 네트워킹을 설정하면 해당 시스템의 작업 하위 집합을 사용할 수 있습니다.

훈련 중에 직면하는 모든 문제는 다시 발생하기 때문에 발생하는 모든 하드웨어 또는 소프트웨어 오류에 대한 테스트 및 자동화된 솔루션을 작성하는 것이 좋습니다. 마찬가지로 모든 모호한 오류 메시지에 대해서는 오류를 더 잘 설명하는 도구를 작성하는 것이 좋습니다.

재현성은 좋은 과학 연구의 핵심입니다. 우리가 즉시 채택한 큰 원칙 중 하나는 가장 단순한 것에서도 "한 번에 하나만 변경하라"는 것이었습니다.

신뢰하고 검증도 해보세요. 외부 도구를 가져오거나 새로운 인력을 영입할 때마다(회사 내부 또는 외부에서) 그들이 주장하는 내용을 다시 확인합니다. 특히 후속 단계가 해당 주장에 따라 달라지는 경우 더욱 그렇습니다.

요약하다

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

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

이 인프라 구축 프로세스는 AI 에이전트를 연구하고 구축하기 위한 기본 방법론을 반영합니다. 세부 사항을 탐색하고 기존 프로세스를 지속적으로 개선하며 유용한 도구와 시스템을 구축하여 의욕 넘치는 팀이 더 큰 과제를 해결할 수 있도록 지원합니다.