저자:  (1) Iason Ofeidis, 뉴헤이븐 소재 예일대학교 전기공학과 및 예일 네트워크 과학 연구소 {동등 기여};  (2) Diego Kiedanski, 뉴헤이븐 소재 예일대학교 전기공학과 및 예일 네트워크 과학 연구소 {동등 기여};  (3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, CA, USA, 전기 공학과, Yale University, New Haven의 네트워크 과학 연구소.  링크 표   초록 및 소개   데이터로더   실험 설정   수치 결과   논의   관련된 일   결론, 감사의 말씀, 참고자료   A. 수치 결과 계속.  4. 수치 결과  첫 번째 실험 세트에서는 작업자 수(2 참조)와 배치 크기를 변경할 때 모든 라이브러리의 성능을 평가했습니다. 이 실험은 Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090 및 10TB 스토리지(6GB/s)를 갖춘 HDD[5] 사양의 로컬 서버에서 실행되었습니다.  우리는 0, 1, 2 워커의 가능한 모든 조합에 대해 기본(단일 GPU), 분산(2개의 GPU), 필터링(단일 GPU)의 세 가지 모드를 평가했습니다. CIFAR10 및 RANDOM의 경우 배치 크기는 16, 64 또는 128이었습니다. CoCo의 경우 더 작은 값인 1, 2, 4를 사용했습니다. 이 모든 실험에서는 컷오프 10과 모델을 실행하는 변형(전진 및 역방향 패스).  4.1 배치 크기와 작업자에 따른 속도  실험을 검토하면서 가장 먼저 알아차린 것은 라이브러리 간의 차이가 문제와 사용된 데이터 세트에 따라 다르다는 것입니다. 그림 4는 단일 GPU에서 CIFAR10에 대한 비교 중 하나를 보여 주는 반면, 5는 단일 GPU에서 CoCo에 대해 동일한 결과를 보여줍니다.  이는 후자의 경우 정방향 및 역방향 전달을 계산하는 데 걸리는 시간이 전체 실행 시간을 지배하지만 이미지의 경우에는 그렇지 않다는 점을 고려하면 예상된 것입니다.   분류. 또한 초당 샘플 4000개에서 단 20개까지 전반적인 속도 차이를 확인할 수 있습니다.  둘째, 배치 크기를 늘리면 거의 모든 경우에 처리 속도가 향상된다는 점을 지적합니다. 다만, 근로자 수의 경우에는 그러하지 아니하다. 그림 6에서는 작업자 수가 증가함에 따라 FFCV 성능이 저하되는 반면 Deep Lake는 2명이 아닌 1명의 작업자에서 정체되는 것을 볼 수 있습니다. 한 가지 설명은 라이브러리에 필요에 따라 스레드와 프로세스를 확장하는 방법을 결정하는 자체 내부 알고리즘이 있다는 것입니다. 위의 사항은 이러한 라이브러리 사용자와 관련이 있습니다. 그 중 하나에 대한 경험이 다른 라이브러리로 잘 변환되지 않을 수 있기 때문입니다.  4.2 DDP 사용 시 속도 향상  데이터로더의 바람직한 기능은 GPU 수에 따라 선형적으로 확장할 수 있는 기능입니다. 이는 항상 가능한 것은 아니며 각 라이브러리의 내부 로딩 메커니즘에 따라 다릅니다. 하나 또는 두 개의 GPU를 사용할 때 속도 증가를 비교하여 이러한 라이브러리의 성능을 살펴봅니다. 그림 7은 RANDOM 데이터 세트의 결과를 보여줍니다. 각 막대는 모든 배치 크기, 작업자 수 및 반복에서 달성된 최대 속도를 나타냅니다. 어떤 면에서 이는 라이브러리가 달성할 수 있는 최대 속도를 반영합니다. 우리는 라이브러리 속도가 평균 선형 증가의 절반에도 못 미치는 약 40% 향상되는 것을 관찰했습니다. 특히 두 가지 경우가 놀랍습니다. 한편, Torchdata는 단일 GPU보다 GPU 2개를 사용하면 성능이 더 나쁩니다. 반면, FFCV는 이론적으로 가능한 것 이상의 속도 증가를 달성했습니다. 여기에는 여러 가지 아티팩트가 작용할 수 있지만 아마도 이는 우리가 실행할 수 있는 반복 횟수가 제한되어 있기 때문일 것입니다(제한된 리소스로 인해). 또한, 이는 아마도   Torchdata의 구성 오류를 나타냅니다. 다중 GPU 환경에서 실행되는 실험에 대한 문서는 대부분의 라이브러리에 대해 제한되어 있습니다.   4.3 전진 패스와 후진 패스 유무 비교  알고리즘 1을 제시할 때 논의한 것처럼 우리는 속도 계산에 정방향 및 역방향 패스를 통합할지 여부를 결정해야 했습니다. 둘 다에 대한 주장이 있습니다. 한편으로는 정방향 및 역방향 전달을 포함하여 알고리즘의 실제 훈련 시간을 더 잘 반영합니다. 동시에 일부 라이브러리는 정방향 단계에서 일반적으로 수행되는 단계를 선제적으로 최적화할 수 있으므로   거기서 멈추는 것은 실제보다 더 오래 걸리는 것처럼 보일 것입니다.  반면에 정방향 및 역방향 전달에 걸리는 시간이 데이터만 로드하는 데 걸리는 시간보다 훨씬 더 큰 경우 계산에 해당 시간을 포함하면 필연적으로 라이브러리 간의 차이가 숨겨집니다.  동작 변화가 눈에 띄는지 이해하기 위해 RANDOM 데이터세트를 사용하여 계산에 두 모델 작업을 포함할 때와 포함하지 않을 때의 평균 속도 차이를 비교했습니다. 결과는 그림 8에 나와 있습니다. 모델을 제외하면 대부분의 라이브러리의 속도가 약간 증가한 것을 확인할 수 있으며(성능이 절반으로 떨어지는 FFCV 제외), 가장 중요한 것은 라이브러리 간의 상대적 성능이 거의 동일하게 유지된다는 것입니다.  4.4 데이터 필터링 시 속도 균형  필터링 실험을 위해 CIFAR10과 RANDOM에 대해 유지할 두 개의 클래스인 개와 트럭, 각각 0과 13을 선택했습니다. CoCO의 경우 피자, 소파, 고양이의 세 가지 클래스를 선택했습니다.  우리는 대부분의 라이브러리에 전체 데이터 세트에 대한 반복을 방지하는 좋은 필터링 메커니즘이 없다는 것을 관찰했습니다. 예를 들어, PyTorch 필터링 구현을 위해서는 원하는 이미지의 인덱스를 사용하여 사용자 정의 샘플러를 구축해야 합니다.  이는 작은 데이터 세트의 경우 매우 빠르지만 대규모 데이터 세트의 경우 실행 불가능합니다. PyTorch를 사용하여 CoCo를 필터링하는 것은 엄청나게 비쌉니다. 일반적으로 필터링할 때와 필터링하지 않을 때의 성능은 매우 비슷했습니다[6]. 그림과 유사   그림 7, 그림 9에서는 필터링 결과로 인한 속도 저하를 볼 수 있습니다. Torchdata 및 Webdataset의 경우 상당한 속도였음에도 불구하고 CoCo Dataset으로 작업할 때 결과가 반전되는 것을 확인했습니다.  4.5 네트워크를 통해 스트리밍하는 동안 훈련  이상적으로는 기계 학습 훈련 프로세스에서 데이터 세트 스토리지를 분리하고 두 위치에 관계없이 데이터를 저장하는 데이터베이스를 선택한 ML 프레임워크에 간단히 연결할 수 있습니다. 여기에는 훈련 데이터를 네트워크를 통해 전송하고 상당한 속도 손실이 포함됩니다. 클라우드에서 GPU 가속 하드웨어를 임대하는 데 드는 비용이 높기 때문에 편리함을 누릴 가치가 없는 것처럼 보일 수 있습니다. 하지만 그렇지 않습니까?  이 문서에서 고려한 라이브러리 중 일부는 인터넷을 통해 액세스할 수 있는 데이터 세트를 지정할 수 있습니다. Webdataset, Hub 및 Deep Lake는 특히 이 기능에 능숙합니다[7]. 그러면 질문은 사용 편의성과 실행 시간 사이의 균형이 얼마나 큽니까?  우리는 이 질문에 대한 통찰력을 제공하기 위해 다음 실험을 설정했습니다. 우리는 데이터 출처를 변경하면서 Hub, Deep Lake 및 Webdataset의 세 라이브러리에 대해 RANDOM 데이터세트의 전체 2개 시대를 실행했습니다. 세 가지 위치가 고려되었습니다. 실험의 하드 드라이브를 실행하는 머신의 로컬 복사본, S3 버킷(머신과 가장 가까운 지역)의 복사본, MinIO(S3와 동등한 오픈 소스로 사용할 수 있는 오픈 소스)에 저장된 복사본입니다. 로컬에서 호스팅됨) 동일한 로컬 네트워크 내의 유사한 컴퓨터에서 실행됩니다(두 컴퓨터 모두 WiFi를 통해 연결되었습니다). 실험의 컴퓨터에는 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz, 16GB RAM, NVIDIA GeForce RTX가 탑재되어 있었습니다.   2070 Rev 및 256GB 스토리지를 갖춘 Samsung SSD 850 하드 드라이브. 지연 시간과 관련하여 실험을 실행하는 워크스테이션에서 MinIO 서버(같은 방, 동일한 로컬 WiFi에 있음)까지의 왕복 시간은 59.2 ± 58.5ms(최소 8.8ms)가 소요된 반면, AWS의 S3 버킷까지의 왕복 시간은 59.2 ± 58.5ms(최소 8.8ms)가 걸렸습니다. 서버 소요 시간은 17.3 ± 1.3ms(최소 14.8ms)였습니다.  그림 10은 9개 실험의 총 실행 시간을 나타내며 흰색 백분율은 로컬 사례에 비해 속도 저하(실행 시간 증가)를 나타냅니다. Hub와 Webdataset의 경우 AWS로 이전하면서 상당한 증가가 있었음에도 불구하고 Deep Lake는 13% 증가에 그쳐 거의 동일한 속도를 유지하는 것을 확인할 수 있습니다. 결과에서 또 다른 유용한 통찰력을 추출할 수 있습니다. 그림 10에서 볼 수 있듯이 MinIO 설정은 AWS 설정보다 거의 두 배나 심각한 속도 저하를 보여줍니다. 이 출력은 주로 위에 표시된 평균 왕복 시간의 차이로 설명될 수 있으며 다음을 강조합니다. 로컬 네트워크(예: 내부 회사 네트워크[8])는 복잡한 구성과 제한으로 인해 데이터 세트를 호스팅하는 가장 효율적인 방법이 아닐 수 있습니다. 또한 이 결과는 네트워크를 통해 데이터세트를 제공하는 스토리지가 원격 교육을 활성화하는 데 중요한 역할을 하며 데이터세트를 제공하는 모범 사례에 대한 질문을 촉발할 수 있음을 나타냅니다. 즉, S3의 데이터는 단일 MinIO 인스턴스에 액세스하는 동안 로드 밸런싱을 통해 여러 서버에서 병렬로 제공됩니다.  모든 추가 실험에 대한 플롯은 부록 A에서 확인할 수 있습니다.  이 문서는 CC 4.0 라이선스에 따라   있습니다. arxiv에서 볼 수  [5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf  [6] 속도가 빠르다. PyTorch용 샘플러 구축은 사전에 수행되므로 총 실행 시간에 상당한 영향을 미칩니다.  [7] Squirrel에는 이 기능이 있지만 MinIO 주소를 지정하지 못했기 때문에 비교에서 제외했습니다. Torchdata에서도 비슷한 문제가 있었습니다.  [8] 이 경우 대학 네트워크

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

We cover the most cutting edge academic research and expert blog posts on serialization. Also big fans of the Serial pod

Data-Loader 환경 개요: 수치 결과

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps