Data-Loader 환경 개요: 실험 설정

링크 표

• 초록 및 소개
• 데이터로더
• 실험 설정
• 수치 결과
• 논의
• 관련된 일
• 결론, 감사의 말, 참고자료
• A. 수치 결과 계속.

3. 실험 설정

기능과 성능을 비교하기 위해 여러 라이브러리와 데이터세트를 선택했습니다. 최대한 이해하기 쉽도록 노력했지만 데이터 로딩 분야는 지속적으로 발전하고 있으며 매일 새로운 라이브러리와 릴리스가 추가됩니다. 이와 관련하여 우리는 다음 목록이 반드시 전체적인 최고(작성 시점에서 출판 시점까지 변경될 수 있음)를 주장하거나 찾지 않고도 데이터로더의 현재 기능에 대한 좋은 개요를 제공할 것으로 기대합니다. 우리는 실험의 모든 소스 코드를 대중에게 공개하고 결과가 완전히 재현될 것으로 기대합니다.

우리는 실험을 수행하기 위해 PyTorch(Paszke et al., 2019), Torchdata(TorchData, 2021), Hub(Team, 2022a), FFCV(Leclerc et al., 2022), Webdatasets(Webdataset, 2013) 등 7개의 라이브러리를 선택했습니다. Squirrel(Team, 2022b) 및 Deep Lake(Hambardzumyan et al., 2022). 우리가 발견한 흥미로운 점 중 하나는 모든 라이브러리가 동일한 기능을 지원하는 것은 아니라는 것입니다. 예를 들어 원격 실험을 수행하기 위해 S3 버킷에 호스팅된 데이터 세트로 FFCV를 실행할 수 없었습니다. 섹션 1에서 언급했듯이 PyTorch에서 모든 실험을 실행합니다. 우리는 다른 인기 있는 기계 학습 프레임워크에서 실험을 재현하는 것을 고려했지만 두 번째 후보는 Tensorflow였을 것이기 때문에 아이디어에 반대하기로 결정했습니다. 그러나 Google이 JAX를 선호하여 Tensorflow에서 멀어지고 있다는 소문이 있습니다. 그림 1은 지난 12개월 동안 다양한 ML 프레임워크의 인기를 보여줍니다.

3.1 데이터세트

데이터 세트와 관련하여 우리는 처음에 이미지 분류를 위한 CIFAR-10(Krizhevsky et al., 2009)과 객체 감지를 위한 CoCo(Lin et al., 2014)라는 두 가지 서로 다른 학습 작업을 지원하기 위해 두 가지 클래식 데이터 세트를 선택했습니다. 몇 가지 실험을 수행하는 동안 다음과 같이 설명할 수 있는 이상한 동작(라이브러리가 예상보다 성능이 좋음)을 관찰했습니다.

CIFAR-10이 메모리에 적합합니다[2]. 이러한 이유로 우리는 무작위로 생성된 256 x 256 픽셀 크기의 컬러 이미지와 20개 중 임의의 클래스로 구성된 RANDOM이라는 세 번째 데이터 세트를 구축했습니다. 이 세 번째 데이터 세트에는 훈련용 이미지 45,000개, 검증용 이미지 5000개, 테스트용 이미지 500개가 포함되어 있습니다. CIFAR-10보다 상당히 큽니다.

벤치마크를 비교할 수 있도록 모든 라이브러리에 동일한 변환을 사용했습니다. 유일한 예외는 다양한 변환을 자체적으로 구현한 FFCV였습니다. 이미지 분류를 위해 변환 스택은 무작위 수평 뒤집기, 정규화, 컷아웃, 텐서로 변환으로 구성되었습니다.

객체 감지를 위해 우리는 주로 Albumentations(Buslaev et al., 2020)의 변환 구현에 의존했습니다. 스택은 다음과 같습니다: 무작위 크기 자르기, 무작위 수평 뒤집기, 정규화, 텐서로 변환. 이러한 변환은 이미지와 경계 상자 모두에 적용됩니다.

3.2 실험 변형

가능하다면 데이터 세트를 로컬로 S3와 동등한 버킷에 호스팅했습니다. 이를 통해 우리는 네트워크를 통한 데이터 스트림의 훈련으로 인한 속도 저하를 평가할 수 있었습니다. 섹션 4에서 훈련 설정에 대한 자세한 설명을 제공합니다.

가장 집중적인 훈련 작업에는 둘 이상의 GPU를 사용하는 것이 포함된다는 점을 고려하여 가능할 때마다 여러 GPU 장치가 있는 환경에서 동일한 실험을 실행했습니다. 실험을 실행할 당시 모든 라이브러리가 PyTorch Lightning을 완벽하게 지원하지 않았기 때문에 우리는 PyTorch의 DDP(Distributed Data Parallel)(Li et al., 2020) 라이브러리를 사용하여 다중 GPU를 구현하기로 결정했습니다.

일부 기계 학습 프로젝트의 경우 더 큰 데이터 세트의 하위 집합에만 액세스해야 할 수도 있습니다. 이러한 경우 전체 데이터 세트를 반복하지 않고도 필요한 데이터 포인트를 신속하게 필터링할 수 있으면 총 교육 시간을 크게 줄일 수 있습니다. 일부 라이브러리는 클래스(이미지 분류 작업용)와 같은 특정 기능을 기반으로 필터링을 허용합니다. 우리는 라이브러리에서 제공하는 필터링 방법(제공하는 경우)을 전혀 필터링하지 않을 때와 비교하여 속도의 이득(또는 손실)을 조사했습니다. 라이브러리가 필터링 방법을 제공하지 않을 때마다 우리는 이를 순진하게 구현했습니다. 즉, 전체 데이터세트를 스캔하고 지정된 조건과 일치하는 요소만 유지하는 것입니다. 빠른 필터링은 모든 샘플에 대한 반복을 피하기 위해 인덱스와 같은 추가 구조를 유지해야 하기 때문에 구현하기가 반드시 쉬운 것은 아닙니다.

마지막으로 표 1은 이 문서에서 살펴본 다양한 실험 및 데이터 세트와 다양한 라이브러리의 호환성을 지정합니다.

3.3 지표

실험을 구축할 때 우리의 최우선 순위는 건전한 방식으로 다양한 모든 라이브러리를 비교할 수 있는 객관적인 측정 기준을 찾는 것이었습니다.

이상적인 측정 기준은 훈련 작업의 총 실행 시간이었을 것입니다. 왜냐하면 이것이 우리가 기다리고 비용을 지불해야 하기 때문입니다. 불행하게도 그렇게 하면 우리가 실행할 수 있는 실험 수가 크게 제한되었을 것입니다. 신중한 고려 끝에 초당 처리되는 데이터 포인트(이미지) 수를 선택했는데, 이는 수치 실험을 통해 뒷받침되는 결과입니다. 이 측정항목의 두 가지 변형을 고려합니다. 하나는 ML 모델을 사용하여 학습하고 역전파를 수행하는 것이고, 다른 하나는 ML 모델을 사용하지 않고 샘플을 반복하여 GPU에 복사하는 것입니다. 두 측정항목 간의 차이는 알고리즘 1의 훈련 루프의 의사 코드에서 알 수 있습니다. 여기서 m은 속도 변수를 나타냅니다. 또한 총 실행 시간[3]과 데이터로더가 초기화되는 데 걸린 시간도 수집했습니다. 후자는 일부 라이브러리가 훈련하는 동안 속도를 높이기 위해 값비싼 계산을 미리 수행할 수 있다는 사실에 동기를 부여받았습니다. 또한 속도 계산을 위한 워밍업도 수행했습니다. 이에 대해서는 하위 섹션 3.5에서 자세히 설명합니다.

3.4 속도와 실행시간의 상관관계

3.5 실행 시간 자세히 살펴보기

각 라이브러리의 내부 메커니즘에 대한 이해를 높이기 위해 단일 실행을 통해 각 배치를 실행하고 데이터로더를 초기화하는 데 걸리는 시간을 검사하기로 결정했습니다. 그림 3은 매개변수 [4]의 단일 조합에 대해 알고리즘 1에 설명된 단계에서 각 라이브러리에 소요되는 시간을 보여줍니다. 이러한 모든 실험에는 10개 배치 이후의 컷오프가 포함되었습니다.

흥미롭게도 첫 번째 배치는 다른 배치보다 상당한 시간이 걸립니다. 이는 다음과 같이 설명할 수 있습니다. 대부분의 데이터로더는 이 시점에서 지연 로딩 데이터에 의존하기 때문에 향후 호출은 미리 가져오기, 이미 메모리에 있는 데이터 및 병렬화(GPU가 계산을 수행하는 동안 작업 수행)의 이점을 누릴 수 있습니다.

1부터 9까지의 밴드 크기는 라이브러리에 소요된 시간 이후 각 라이브러리가 얼마나 잘 확장되었는지 가장 잘 나타냅니다.

대규모 데이터 세트는 해당 너비에 따라 선형적으로 증가합니다. 대부분의 라이브러리는 너비가 균일하며 Deep Lake가 가장 짧습니다(가장 빠릅니다). 반면, 불균일한 너비를 나타내는 유일한 라이브러리는 FFCV인데, 여기서 밴드 1~3은 너무 얇아서 이미지에서 볼 수 없습니다.

마무리 기간은 상당히 오래 걸리는 FFCV와 Deep Lake를 제외하고 모든 라이브러리에서 거의 동일한 시간이 소요됩니다. 마무리에 소요되는 시간은 대부분 모델에 따라 다르며 반드시 각 라이브러리의 확장 정도를 나타내는 것은 아닙니다.

이 수치를 바탕으로 속도를 계산할 때 워밍업을 수행하기로 결정했습니다. 이는 모든 속도 계산에서 첫 번째 배치에 소요되는 시간을 무시한다는 의미입니다.

[2] 이는 일부 리뷰 문헌에서 바람직하고 예상되는 경우가 많지만 소규모 팀 및 사내 워크스테이션과 관련된 여러 실제 응용 프로그램에서는 그렇지 않은 것으로 나타났습니다.

[3] 이는 시뮬레이션 시작부터 컷오프까지의 시간으로, 실제로는 배치가 10개에 불과한 경우가 많습니다.

[4] RANDOM 데이터 세트, 단일 GPU, 작업자 0개, 배치 크기 64