대규모 딥러닝 훈련을 위한 캐시 최적화 실습

1. 프로젝트 배경 및 캐싱 전략

먼저 관련 배경을 공유해보겠습니다.

최근 몇 년 동안 AI 교육 애플리케이션이 점점 더 널리 보급되었습니다. 인프라 관점에서 보면 빅데이터든 AI 훈련 클러스터든 대부분 스토리지와 컴퓨팅을 분리한 아키텍처를 사용한다. 예를 들어 대규모 컴퓨팅 클러스터에 많은 GPU 어레이가 배치되고 다른 클러스터는 스토리지입니다. Microsoft의 Azure 또는 Amazon의 S3와 같은 일부 클라우드 스토리지를 사용할 수도 있습니다.

이러한 인프라의 특징은 우선 컴퓨팅 클러스터에 매우 고가의 GPU가 많이 있고, 각 GPU에는 수십 TB의 스토리지와 같은 일정량의 로컬 스토리지가 있는 경우가 많습니다. SSD. 이러한 기계 배열에서는 원격 엔드에 연결하기 위해 고속 네트워크가 종종 사용됩니다. 예를 들어 Coco, 이미지 넷, YouTube 8M과 같은 초대형 교육 데이터는 네트워크를 통해 연결됩니다.

위 그림과 같이 데이터는 다음 AI 훈련의 병목 현상이 될 수 있습니다. 우리는 데이터 세트가 점점 더 커지고 AI가 널리 사용됨에 따라 더 많은 훈련 데이터가 축적되고 있음을 관찰했습니다. 동시에 GPU 트랙은 매우 부피가 큽니다. 예를 들어, AMD 및 TPU와 같은 제조업체는 GPU 및 TPU와 같은 가속기를 더 빠르고 빠르게 만들기 위해 하드웨어 및 소프트웨어를 최적화하는 데 많은 에너지를 소비했습니다. 가속기가 회사 내에서 널리 사용됨에 따라 클러스터 배포가 점점 더 커지고 있습니다. 여기에 있는 두 표는 데이터 세트와 GPU 속도에 따른 약간의 차이를 나타냅니다. 이전 K80부터 V100, P100, A100까지 속도가 굉장히 빠르다. 그러나 속도가 빨라질수록 GPU 가격은 점점 더 비싸집니다. IO 속도와 같은 데이터가 GPU 속도를 따라갈 수 있는지 여부는 큰 과제입니다.

위 그림과 같이 많은 대기업 응용 프로그램에서 원격 데이터를 읽을 때 GPU가 유휴 상태인 현상을 관찰했습니다. GPU가 원격 데이터를 읽기를 기다리고 있기 때문에 IO가 병목 현상을 일으키고 값비싼 GPU가 낭비되는 결과를 낳는다. 이러한 병목 현상을 완화하기 위해 많은 최적화 작업이 진행되고 있으며 캐싱은 가장 중요한 최적화 방향 중 하나입니다. 여기에 두 가지 방법이 있습니다.

첫 번째는 많은 애플리케이션 시나리오, 특히 K8s 및 Docker와 같은 기본 AI 교육 아키텍처에서 많은 로컬 디스크가 사용된다는 것입니다. 앞서 언급했듯이 GPU 시스템에는 특정 로컬 저장소가 있으며 로컬 디스크를 사용하여 일부 캐싱을 수행하고 데이터를 먼저 캐시할 수 있습니다.

GPU Docker를 시작한 후 GPU AI 훈련을 즉시 시작하는 대신 먼저 데이터를 다운로드하고 원격 끝에서 Docker로 데이터를 다운로드하거나 마운트할 수 있습니다. Docker에 다운로드한 후 학습을 시작하세요. 이런 방식으로 후속 학습 데이터 읽기를 최대한 로컬 데이터 읽기로 전환할 수 있습니다. 로컬 IO의 성능은 현재 GPU 교육을 지원하기에 충분합니다. VLDB 2020에는 데이터 캐싱을 위해 DALI를 기반으로 한 CoorDL이라는 논문이 있습니다.

이 방법도 많은 문제를 가져옵니다. 우선, 로컬 공간이 제한되어 있어 캐시되는 데이터도 제한됩니다. 데이터 세트가 점점 커지면 모든 데이터를 캐시하기가 어렵습니다. 또한 AI 시나리오와 빅데이터 시나리오의 큰 차이점은 AI 시나리오의 데이터 세트가 상대적으로 제한적이라는 것입니다. 테이블이 많고 비즈니스가 다양한 빅데이터 시나리오와 달리 각 비즈니스의 데이터 테이블 간의 콘텐츠 격차가 매우 큽니다. AI 시나리오에서는 데이터 세트의 크기와 수가 빅 데이터 시나리오보다 훨씬 적습니다. 따라서 회사에 제출된 많은 업무들이 동일한 데이터를 읽는 경우가 종종 발견됩니다. 모든 사람이 자신의 로컬 컴퓨터에 데이터를 다운로드하면 공유할 수 없으며 많은 데이터 복사본이 로컬 컴퓨터에 반복적으로 저장됩니다. 이 접근 방식은 분명히 많은 문제를 갖고 있으며 충분히 효율적이지 않습니다.

두 번째 방법은 다음에 소개하겠습니다. 로컬 스토리지가 별로 좋지 않은데 지금 당장은 Alluxio와 같은 분산 캐시를 사용하여 문제를 완화할 수 있을까요? 분산 캐시는 데이터를 로드할 수 있는 용량이 매우 큽니다. 또한, Alluxio는 분산 캐시로서 공유가 쉽습니다. 데이터는 Alluxio로 다운로드되며 다른 클라이언트도 캐시에서 이 데이터를 읽을 수 있습니다. Alluxio를 사용하면 위에서 언급한 문제를 쉽게 해결할 수 있고 AI 훈련 성능을 크게 향상시킬 수 있을 것으로 보입니다. Microsoft India Research가 FAST2020에 발표한 Quiver라는 제목의 논문에서 이 솔루션을 언급했습니다. 그러나 우리의 분석에 따르면 완벽해 보이는 할당 계획은 여전히 ​​상대적으로 정적이고 효율적이지 않습니다. 동시에 어떤 종류의 캐시 제거 알고리즘을 사용해야 하는지도 논의할 가치가 있는 문제입니다.

위 그림과 같이 Alluxio를 AI 훈련용 캐시로 활용하는 어플리케이션입니다. K8s를 사용하여 전체 클러스터 작업을 예약하고 GPU, CPU, 메모리와 같은 리소스를 관리하세요. 사용자가 K8s에 작업을 제출하면 K8s는 먼저 플러그인을 만들고 Alluxio 마스터에게 데이터의 이 부분을 다운로드하도록 알립니다. 즉, 먼저 준비 작업을 수행하고 작업에 필요할 수 있는 일부 작업을 캐시해 보십시오. 물론 Alluxio는 그만큼 많은 데이터를 사용하기 때문에 완전히 캐시할 필요는 없습니다. 나머지는 아직 캐시되지 않은 경우 원격 끝에서 읽혀집니다. 또한 Alluxio 마스터는 이러한 명령을 받은 후 작업자에게 원격 끝으로 이동하도록 요청할 수 있습니다. 클라우드 스토리지일 수도 있고 데이터를 다운로드하는 Hadoop 클러스터일 수도 있습니다. 이때 K8s는 GPU 클러스터에도 작업을 예약합니다. 예를 들어 위 그림에서 이러한 클러스터에서는 첫 번째 노드와 세 번째 노드를 선택하여 훈련 작업을 시작합니다. 학습 작업을 시작한 후에는 데이터를 읽어야 합니다. PyTorch, Tensorflow 등 현재 주류 프레임워크에는 Prefetch도 내장되어 있는데, 이는 데이터를 미리 읽는다는 의미입니다. 훈련 데이터 IO를 지원하기 위해 미리 캐싱되어 있는 캐싱된 데이터를 Alluxio에서 읽어옵니다. 물론 일부 데이터를 읽지 않은 것으로 확인되면 Alluxio는 원격으로 읽을 수도 있습니다. Alluxio는 통합 인터페이스로서 훌륭합니다. 동시에 작업 간에 데이터를 공유할 수도 있습니다.

예를 들어, 다른 사람이 동일한 데이터로 다른 작업을 제출하여 동일한 데이터 세트를 소비합니다. 이때 작업이 K8s에 제출되면 Alluxio는 알게 됩니다. 데이터의 이 부분을 사용할 수 있습니다. Alluxio가 더 나은 작업을 원한다면 데이터가 어느 시스템에 예약될지 알 수도 있습니다. 예를 들어 현재 노드 1, 노드 3, 노드 4에 예약되어 있습니다. 노드 4 데이터의 일부 복사본을 만들 수도 있습니다. 이러한 방식으로 Alluxio 내에서도 모든 데이터는 여러 머신에서 읽을 필요가 없고 로컬에서 읽혀집니다. 그래서 알룩시오는 AI 훈련에서 IO 문제를 크게 완화하고 최적화한 것으로 보인다. 하지만 자세히 살펴보면 두 가지 문제점을 발견할 수 있습니다.

첫 번째 문제는 캐시 제거 알고리즘이 매우 비효율적이라는 점입니다. AI 시나리오에서는 데이터에 액세스하는 모드가 과거와 매우 다르기 때문입니다. 두 번째 문제는 캐시가 자원으로서 대역폭(즉, 원격 저장소의 읽기 속도)과 상반된 관계를 갖는다는 점이다. 캐시가 크면 원격 끝에서 데이터를 읽을 가능성이 줄어듭니다. 캐시가 작으면 원격 끝에서 많은 데이터를 읽어야 합니다. 이러한 자원을 어떻게 잘 계획하고 배분할 것인지도 고려해야 할 문제이다.

캐시 제거 알고리즘을 논의하기 전에 먼저 AI 훈련에서 데이터 접근 과정을 살펴보겠습니다. AI 훈련에서는 여러 epoch로 나누어 반복적으로 훈련하게 됩니다. 각 학습 에포크에서 각 데이터 조각을 읽고 한 번만 읽습니다. 학습의 과적합을 방지하기 위해 각 에포크가 끝난 후 다음 에포크에서는 읽기 순서가 바뀌고 셔플이 수행됩니다. 즉, 모든 데이터는 매 에포크마다 한 번씩 읽혀지지만 순서는 다릅니다.

Alluxio의 기본 LRU 제거 알고리즘은 분명히 AI 훈련 시나리오에 잘 적용될 수 없습니다. LRU는 캐시 지역성을 활용하기 때문입니다. 지역성은 두 가지 측면으로 나누어진다. 첫 번째는 시간 지역성, 즉 지금 접근하고 있는 데이터가 곧 접근될 수 있다는 것이다. 이것은 AI 훈련에는 존재하지 않습니다. 지금 액세스한 데이터는 다음 라운드에서만 액세스할 수 있고, 다음 라운드에서도 액세스할 수 있기 때문입니다. 데이터가 다른 데이터보다 더 쉽게 접근할 수 있는 특별한 가능성은 없습니다. 다른 측면에는 데이터 지역성과 공간 지역성이 있습니다. 즉, Alluxio가 상대적으로 큰 블록을 사용하여 데이터를 캐시하는 이유는 특정 데이터를 읽으면 주변의 데이터도 읽을 수 있기 때문입니다. 예를 들어 빅 데이터 시나리오에서 OLA

P 애플리케이션은 테이블을 자주 스캔하므로 주변 데이터에 즉시 액세스할 수 있습니다. 하지만 AI 훈련 시나리오에는 적용할 수 없습니다. 매번 섞이기 때문에 읽는 순서가 매번 다릅니다. 따라서 LRU 제거 알고리즘은 AI 훈련 시나리오에 적합하지 않습니다.

LRU뿐만 아니라 LFU와 같은 주류 제거 알고리즘에도 이러한 문제가 있습니다. 전체 AI 훈련이 데이터에 대해 매우 동일한 액세스 권한을 갖기 때문입니다. 따라서 데이터의 일부만 캐시하면 되고 절대 건드릴 필요가 없는 가장 간단한 캐싱 알고리즘을 사용할 수 있습니다. 작업이 수행된 후에는 항상 데이터의 일부만 캐시됩니다. 절대로 제거하지 마십시오. 제거 알고리즘은 필요하지 않습니다. 이것은 아마도 최고의 제거 메커니즘일 것입니다.

위 사진의 예시처럼요. 위는 LRU 알고리즘이고 아래는 Equalization 방식이다. 처음에는 두 개의 데이터만 캐시할 수 있습니다. 문제를 단순화해 보겠습니다. 캐시 D와 B라는 두 가지 용량만 있고 중간은 액세스 순서입니다. 예를 들어, 가장 먼저 액세스한 것은 B입니다. LRU인 경우 B가 캐시에 적중됩니다. 다음 접근은 C이다. C는 D와 B의 캐시에 없다. 따라서 LRU 정책에 따라 D는 교체되고 C는 유지된다. 즉, 이때 캐시는 C와 B이다. 다음으로 방문한 곳은 A인데, 역시 C와 B에는 없다. 따라서 B는 제거되고 C와 A로 대체됩니다. 다음은 D인데, D는 캐시에 없으므로 D와 A로 대체됩니다. 비유하자면, 이후의 모든 액세스는 캐시에 도달하지 않는다는 것을 알 수 있습니다. 그 이유는 LRU 캐싱을 하면 교체가 되지만 실제로는 한 에포크에 한 번 접근했고, 이번 에포크에는 다시는 접근하지 않기 때문이다. 대신 LRU가 이를 캐시합니다. LRU는 도움이 되지 않을 뿐만 아니라 실제로 상황을 더욱 악화시킵니다. 다음 방법과 같이 유니폼을 사용하는 것이 좋습니다.

다음 균일 방식은 항상 D와 B를 캐시에 캐시하고 절대 교체하지 않습니다. 이 경우 적어도 50%의 적중률을 찾을 수 있습니다. 그러면 캐싱 알고리즘이 복잡할 필요가 없다는 것을 알 수 있습니다. LRU, LFU 등의 알고리즘을 사용하지 마세요.

두 번째 질문은 캐시와 원격 대역폭의 관계에 관한 것입니다. GPU가 데이터를 기다리는 것을 방지하기 위해 이제 데이터 미리 읽기 기능이 모든 주류 AI 프레임워크에 내장되어 있습니다. 따라서 GPU가 훈련 중일 때 실제로 CPU가 다음 라운드에 사용될 수 있는 데이터를 사전 준비하도록 트리거합니다. 이를 통해 GPU의 컴퓨팅 성능을 최대한 활용할 수 있습니다. 그러나 원격 저장소의 IO가 병목 현상이 발생하면 GPU가 CPU를 기다려야 함을 의미합니다. 따라서 GPU는 유휴 시간이 많아 리소스 낭비가 발생합니다. IO 문제를 완화할 수 있는 더 나은 일정 관리 방법이 있기를 바랍니다.

캐시 및 원격 IO는 전체 작업 처리량에 큰 영향을 미칩니다. 따라서 GPU, CPU, 메모리 외에 캐시, 네트워크도 예약해야 합니다. 과거 Hadoop, Yarn, 마이소스, K8s 등 빅데이터 개발 과정에서는 주로 스케줄링된 CPU, 메모리, GPU가 이루어졌습니다. 네트워크, 특히 캐시에 대한 제어가 좋지 않습니다. 따라서 우리는 AI 시나리오에서 전체 클러스터의 최적화를 달성하기 위해 잘 예약되고 할당되어야 한다고 믿습니다.

2. SiloD 프레임워크

는 EuroSys 2023에서 이러한 기사를 발표했습니다. 컴퓨팅 리소스와 스토리지 리소스를 예약하는 통합 프레임워크입니다.

전체적인 아키텍처는 위의 그림과 같습니다. 왼쪽 하단에는 클러스터의 CPU 및 GPU 하드웨어 컴퓨팅 리소스와 NFS, 클라우드 스토리지 HDFS 등과 같은 스토리지 리소스가 있습니다. 상위 수준에는 TensorFlow, PyTorch 등과 같은 일부 AI 훈련 프레임워크가 있습니다. 우리는 SiloD를 제안한 컴퓨팅 및 스토리지 자원을 균일하게 관리하고 할당하는 플러그인을 추가해야 한다고 생각합니다.

위 그림과 같이 작업이 어느 정도의 처리량과 성능을 얻을 수 있는지는 GPU와 IO의 최소값에 따라 결정됩니다. 사용되는 원격 IO 수, 원격 네트워킹이 사용되는 정도. 이러한 공식을 통해 액세스 속도를 계산할 수 있습니다. 작업 속도에 캐시 실패율(1-c/d)을 곱합니다. 여기서 c는 캐시 크기이고 d는 데이터 세트입니다. 즉, 데이터가 IO만 고려하여 병목 현상이 발생할 수 있는 경우 대략적인 처리량은 (b/(1-c/d))와 같습니다. 여기서 b는 원격 대역폭입니다. 위의 세 가지 수식을 결합하면 오른쪽의 수식을 통해 작업이 궁극적으로 달성하고자 하는 성능이 무엇인지 추론할 수 있습니다. 이 수식을 사용하여 IO 병목 현상이 없을 때의 성능과 IO 병목 현상이 있을 때의 성능을 계산할 수 있습니다. IO 병목 현상은 둘 중 하나를 선택합니다.

위의 수식을 구한 후 이를 미분하여 캐시의 효율성, 즉 캐시 효율성을 얻습니다. 즉, 작업이 많아도 캐시를 할당할 때 균등하게 처리할 수 없습니다. 다양한 데이터 세트와 속도를 기반으로 하는 각 작업은 할당되는 캐시 양이 매우 다릅니다. 다음은 이 공식을 예로 들어 설명합니다. 매우 빠르고 훈련이 매우 빠른 작업을 찾고 데이터 세트가 작다면 이는 더 큰 캐시를 할당하고 이점이 더 커진다는 의미입니다.

위 관찰을 바탕으로 SiloD를 캐시 및 네트워크 할당에 사용할 수 있습니다. 또한, 캐시의 크기는 각 작업의 속도와 데이터 세트의 전체 크기에 따라 할당됩니다. 웹에서도 마찬가지입니다. 따라서 전체 아키텍처는 다음과 같습니다. K8s와 같은 주류 작업 스케줄링 외에도 데이터 관리도 있습니다. 그림의 왼쪽을 예로 들면, 캐시 관리에는 전체 클러스터에 할당된 캐시의 크기, 각 작업 캐시의 크기, 각 작업이 사용하는 원격 IO의 크기에 대한 통계나 모니터링이 필요합니다. 다음 작업은 Alluxio 방법과 매우 유사하며 둘 다 데이터 교육에 API를 사용할 수 있습니다. 각 작업자의 캐시를 사용하여 로컬 작업에 대한 캐싱 지원을 제공합니다. 물론 클러스터의 노드에 걸쳐 있을 수도 있고 공유할 수도 있습니다.

사전 테스트와 실험을 통해 이러한 할당 방법은 전체 클러스터의 활용도와 처리량을 최대 8배까지 크게 향상시킬 수 있는 것으로 나타났습니다. 작업 대기 및 GPU 유휴 상태를 분명히 완화할 수 있습니다.

위의 소개를 요약해 보겠습니다.

먼저, AI 또는 딥 러닝 훈련 시나리오에서는 LRU 및 LFU와 같은 전통적인 캐싱 전략이 적합하지 않습니다. 유니폼을 직접 사용하는 것이 좋습니다.

두 번째, 캐싱과 원격 대역폭은 전반적인 성능에 매우 큰 역할을 하는 한 쌍의 파트너입니다.

셋째, K8s, Yarn 등 주요 스케줄링 프레임워크를 SiloD에서 쉽게 상속받을 수 있습니다.

마지막으로, 우리는 논문에서 몇 가지 실험을 했습니다. 다양한 스케줄링 전략으로 인해 처리량이 확실히 향상될 수 있습니다.

3. 분산 캐싱 전략 및 복사본 관리

오픈 소스 작업도 수행했습니다. 분산 캐싱 전략 및 복제본 관리에 대한 이 작업은 커뮤니티에 제출되었으며 현재 홍보 단계에 있습니다. Alluxio 마스터는 주로 Meta 관리와 전체 작업자 클러스터 관리를 담당합니다. 실제로 데이터를 캐시하는 것은 작업자입니다. 데이터를 캐시하기 위해 블록 단위로 많은 블록이 있습니다. 한 가지 문제는 현재 캐싱 전략이 단일 작업자를 대상으로 한다는 것입니다. 작업자 내의 각 데이터를 제거할지 여부를 계산할 때 하나의 작업자에 대해서만 계산하면 되고 현지화됩니다.

위 예시와 같이 작업자 1에 블록 A, 블록 B, 블록 C가 있는 경우 LRU 기준으로 블록 C가 가장 오랫동안 사용되지 않은 것으로 계산됩니다. , 블록 C가 제거됩니다. 전반적인 상황을 살펴보면 이것이 좋지 않다는 것을 알 수 있습니다. 블록 C에는 전체 클러스터에 복사본이 하나만 있기 때문입니다. 제거된 후 다른 사람이 블록 C에 액세스하려는 경우 원격 끝에서만 데이터를 가져올 수 있으므로 성능과 비용 손실이 발생합니다. 우리는 글로벌 제거 전략을 제안합니다. 이 경우 블록 C를 제거해서는 안 되며, 복사본이 더 많은 블록을 제거해야 합니다. 이 예에서 블록 A는 다른 노드에 여전히 두 개의 복사본을 갖고 있기 때문에 제거되어야 하며, 이는 비용 및 성능 측면에서 더 좋습니다.

위 그림과 같이 우리가 하는 일은 각 워커에 대한 Replica 정보를 유지하는 것입니다. 예를 들어 작업자가 복사본을 추가하거나 제거하면 먼저 마스터에게 보고하고, 마스터는 이 정보를 하트비트 반환 값으로 사용하여 다른 관련 작업자에게 반환합니다. 다른 작업자는 전체 글로벌 복사본의 실시간 변경 사항을 알 수 있습니다. 동시에 복사 정보가 업데이트됩니다. 따라서 내부 작업자를 제거할 때 각 작업자가 전 세계에 몇 개의 복사본을 보유하고 있는지 알 수 있고 일부 가중치를 설계할 수 있습니다. 예를 들어 LRU는 그대로 사용하지만 어떤 데이터를 제거하고 교체할지 종합적으로 고려하기 위해 복제본 수에 대한 가중치가 추가됩니다.

사전 테스트를 마친 후 빅데이터든 AI 교육이든 다양한 분야에서 큰 개선을 가져올 수 있습니다. 따라서 이는 단지 하나의 시스템에서 한 명의 작업자에 대한 캐시 적중을 최적화하는 것이 아닙니다. 우리의 목표는 전체 클러스터의 캐시 적중률을 향상시키는 것입니다.

마지막으로 전체 내용을 요약해 보겠습니다. 우선, AI 훈련 시나리오에서는 균일한 캐시 제거 알고리즘이 기존 LRU 및 LFU보다 우수합니다. 둘째, 캐시와 원격 네트워킹도 할당하고 예약해야 하는 리소스입니다. 셋째, 캐시를 최적화할 때 하나의 작업이나 하나의 작업자로 제한하지 말고 전체 엔드투엔드 전역 매개변수를 고려해야 전체 클러스터의 효율성과 성능이 더 향상될 수 있습니다.

위 내용은 대규모 딥러닝 훈련을 위한 캐시 최적화 실습의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!