이 페이지는 Cloud Translation API를 통해 번역되었습니다.

권장사항 및 추천 워크플로

이 페이지에서는 튜토리얼을 이미 실행했다고 가정하고 신경망 아키텍처 검색 권장사항을 설명합니다. 첫 번째 섹션에서는 신경망 아키텍처 검색 작업에 수행할 수 있는 전체 워크플로를 요약해서 보여줍니다. 나머지 다음 섹션에서는 각 단계에 대해 자세히 설명합니다. 첫 번째 신경망 아키텍처 검색 작업을 실행하기 전 이 전체 페이지를 진행하는 것이 좋습니다.

일반 신경망 아키텍처 검색

위 그림은 일반적인 신경망 아키텍처 검색 곡선을 보여줍니다. 여기에서 Y-axis는 시도-리워드를 보여주고 X-axis는 지금까지 실행된 시도 수를 보여줍니다. 처음 최대 100-200회 시도는 대부분 컨트롤러에 의한 검색 공간의 임의 탐색입니다. 이러한 초기 탐색 중에는 검색 공간에서 많은 종류의 모델이 시도되기 때문에 리워드에 큰 분산이 나타납니다. 시도 수가 증가함에 따라 컨트롤러가 더 나은 모델을 찾기 시작합니다. 따라서 먼저 리워드가 증가하기 시작하고 이후 리워드-분산 및 리워드-증가가 감소되기 시작하여 수렴을 보여줍니다. 수렴이 발생하는 시도 수는 검색-공간 크기에 따라 달라지지만 일반적으로 최대 2,000회 정도에 해당합니다.

신경망 아키텍처 검색의 두 단계: 프록시 태스크 및 전체 학습

신경망 아키텍처 검색은 다음과 같은 두 단계를 통해 작동합니다.

단계1-검색에는 전체 학습 중 상당히 작은 표현이 사용되며, 일반적으로 최대 1-2 시간 내에 완료됩니다. 이 표현을 프록시 태스크라고 부르며 검색 비용을 낮게 유지하는 데 도움이 됩니다.
Stage2-full-training에서는 stage1-search에서 상위 최대 10개의 점수 모델에 대한 전체 학습을 수행합니다. 검색의 확률적 특성으로 인해 stage1-search의 최상위 모델이 stage2-full-training 중 최상위 모델이 아닐 수 있으므로 전체 학습을 위한 모델 풀을 선택하는 것이 중요합니다.

컨트롤러는 전체 학습이 아닌 작은 프록시 작업에서 보상 신호를 받기 때문에 작업에 가장 적합한 프록시 작업을 찾아야 합니다.

신경망 아키텍처 검색 비용

신경망 아키텍처 검색 비용은 search-cost = num-trials-to-converge * avg-proxy-task-cost로 지정됩니다. 프록시 태스크 컴퓨팅 시간이 전체 학습 시간의 약 1/30이고 수렴에 필요한 시도 수가 약 최대 2,000개라고 가정하면 검색 비용은 최대 67 * full-training-cost가 됩니다.

신경망 아키텍처 검색 비용이 높으므로 프록시 태스크를 조정하고 첫 번째 검색에 더 작은 검색 공간을 사용하는 것이 좋습니다.

신경망 아키텍처 검색의 두 단계 간 데이터 세트 분할

기준 학습에 training-data와 validation-data가 이미 있다고 가정하면 NAS 신경망 아키텍처 검색의 두 단계에 대해 다음 데이터 세트 분할이 권장됩니다.

Stage1-search 학습: training-data의 최대 90%
Stage1-search 검증: training-data의 최대 10%
Stage2-full-training 학습: training-data의 100%
Stage2-full-training 검증: validation-data의 100%

stage2-full-training 데이터 분할은 일반 학습과 동일합니다. 그러나 stage1-search는 검증에 학습 데이터 분할을 사용합니다. stage1 및 stage2에서 서로 다른 검증 데이터를 사용하면 데이터 세트 분할로 인한 모델 검색 편향을 감지할 수 있습니다. training-data는 파티션 나누기를 수행하기 전에 학습 데이터가 잘 섞여 있는지 확인하고 최종 10% training-data-split이 원본 검증 데이터와 비슷한 분포를 갖는지 확인합니다.

소규모 또는 불균형 데이터

제한된 학습 데이터 또는 일부 클래스가 매우 드물게 발생하는 불균형 데이터 세트에는 아키텍처 검색이 권장되지 않습니다. 데이터 부족으로 인해 기준 학습에 이미 증강을 과도하게 사용하고 있다면 model-search는 권장되지 않습니다.

이 경우 최적의 아키텍처를 검색하는 대신 augmentation-search만 실행하여 최적의 증강 정책을 검색할 수 있습니다.

검색 공간 설계

아키텍처 검색은 증강 검색 또는 초매개변수 검색(예: 학습률 또는 옵티마이저 설정)과 혼용되지 않아야 합니다. 아키텍처 검색의 목표는 아키텍처에 기반한 차이만 있는 경우 모델-A 성능을 모델-B 성능과 비교하기 위한 것입니다. 따라서 증강 및 초매개변수 설정은 동일하게 유지됩니다.
아키텍처 검색이 완료된 후 또 다른 단계로 증강 검색을 수행할 수 있습니다.
신경망 아키텍처 검색은 검색 공간 크기를 최대 10^20까지 늘릴 수 있습니다. 하지만 검색 공간이 더 크다면 검색 공간을 상호 배타적인 부분으로 나눌 수 있습니다. 예를 들어 디코더와 별개로 인코더를 검색하거나 헤드를 먼저 검색할 수 있습니다. 그래도 모든 항목에 대해 공동 검색을 수행하길 원하면 이전에 발견된 최상의 개별 옵션 주위에 더 작은 검색 공간을 만들 수 있습니다.
(선택사항) 검색 공간을 설계할 때 block-design에서 model-scaling을 분리할 수 있습니다. 블록 설계 검색은 먼저 축소된 모델을 사용하여 수행되어야 합니다. 이렇게 하면 프록시 태스크 런타임의 비용이 훨씬 낮게 유지될 수 있습니다. 그런 후 개별 검색을 수행하여 모델을 확장할 수 있습니다. 자세한 내용은 Examples of scaled down models을 참조하세요.

학습 및 검색 시간 최적화

신경망 아키텍처 검색을 실행하기 전에는 기준 모델의 학습 시간을 최적화하는 것이 중요합니다. 그러면 장기 실행 비용이 절약됩니다. 몇 가지 학습 최적화 옵션은 다음과 같습니다.

데이터 로드 속도 최대화:
- 데이터가 상주하는 버킷이 작업과 동일한 리전에 있는지 확인합니다.
- TensorFlow를 사용하는 경우 Best practice summary를 참고하세요. 데이터에 TFRecord 형식을 사용해 볼 수도 있습니다.
- PyTorch를 사용하는 경우 효율적인 PyTorch 학습은 가이드라인을 따르세요.
분산 학습을 사용하여 여러 가속기 또는 여러 머신을 활용합니다.
혼합 정밀도 학습을 사용하여 학습 속도를 크게 늘리고 메모리 사용을 줄이세요. TensorFlow 혼합 정밀도 학습은 Mixed Precision을 참조하세요.
일부 가속기(A100)는 일반적으로 더 비용 효율적입니다.
GPU 사용률을 극대화하도록 배치 크기를 조정합니다. 다음 그래프는 GPU 사용률 미달(50%)을 보여줍니다. 배치 크기를 늘리면 GPU 사용률을 높일 수 있습니다. 하지만 검색 시 메모리 부족 오류가 늘어날 수 있으므로 배치 크기는 신중하게 늘려야 합니다.
특정 아키텍처 블록이 검색 공간과 독립적인 경우 더 빠른 학습을 위해 이러한 블록에 대해 선행 학습된 체크포인트를 로드할 수 있습니다. 선행 학습된 체크포인트는 검색 공간에서 동일해야 하며 편향을 초래해서는 안 됩니다. 예를 들어 검색 공간이 디코더 전용인 경우 인코더는 선행 학습된 체크포인트를 사용할 수 있습니다.

각 검색 시도당 GPU 수

시도당 더 적은 개수의 CPU를 사용하여 시작 시간을 줄입니다. 예를 들어 2개 GPU는 시작하는 데 5분이 걸리고, 8개 GPU는 20분이 걸립니다. 시도당 GPU 2개를 사용하여 신경망 아키텍처 검색 작업 프록시 태스크를 실행하는 것이 더 효율적입니다.

검색의 총 시도 및 병렬 시도 횟수

총 시도 설정

최적의 프록시 태스크를 검색하고 선택하면 전체 검색을 시작할 수 있습니다. 수렴할 시도 횟수는 미리 알 수 없습니다. 수렴이 발생하는 시도 수는 검색-공간 크기에 따라 달라지지만 일반적으로 약 2,000회 정도에 해당합니다.

--max_nas_trial에 매우 높은 설정인 약 5,000-10,000을 설정한 다음 검색 플롯에 수렴이 표시되면 조기에 검색 작업을 취소하는 것이 좋습니다. search_resume 명령어를 사용하여 이전 검색 작업을 재개할 수도 있습니다. 하지만 다른 검색 재개 작업에서 검색을 재개할 수는 없습니다. 따라서 원래 검색 작업은 한 번만 재개할 수 있습니다.

병렬 시도 횟수 설정

stage1-search 작업은 한 번에 --max_parallel_nas_trial개의 시도를 동시에 실행하여 일괄 처리를 실행합니다. 이는 검색 작업의 전반적인 런타임을 줄이는 데 중요합니다. 검색의 예상 일수를 계산할 수 있습니다. days-required-for-search = (trials-to-converge / max-parallel-nas-trial) * (avg-trial-duration-in-hours / 24) 참고: 처음에는 상한값으로 시작하기 적절한 3000을 trials-to-converge의 대략적인 추정치로 사용할 수 있습니다. 처음에는 2시간을 avg-trial-duration-in-hours의 대략적인 추정치로 사용할 수 있습니다. 이 시간은 각 프록시 태스크에 걸리는 적절한 상한값입니다. 프로젝트의 가속기 할당량과 days-required-for-search에 따라 --max_parallel_nas_trial 설정을 최대 20-50으로 사용하는 것이 좋습니다. 예를 들어 --max_parallel_nas_trial을 20으로 설정하고 각 프록시 태스크가 NVIDIA T4 GPU 두 개를 사용한다면 할당량을 최소 40개의 NVIDIA T4 GPU로 예약해야 합니다. --max_parallel_nas_trial 설정은 전체 검색 결과에 영향을 미치지 않지만 days-required-for-search에는 영향을 미칩니다. max_parallel_nas_trial의 설정을 에 약 10개(GPU 20개) 정도로 작게 할 수도 있지만 대략적으로 days-required-for-search를 추정하고 작업 제한 시간 한도 내에 있는지 확인해야 합니다.

일반적으로 stage2-full-training 작업은 모든 시도를 병렬로 학습시킵니다. 일반적으로 병렬로 실행되는 상위 10개 실험입니다. 하지만 각 stage2-full-training 시도에서 사용 사례에 너무 많은 GPU(예: 각 8개의 GPU)가 사용되고 할당량이 충분하지 않은 경우 stage2 작업을 일괄적으로 수동으로 실행할 수 있습니다. 예를 들어 5번의 시도에 대해 stage2-full-training을 실행한 후 다음 5번 시도에 대해 다른 stage2-full-training을 실행합니다.

기본 작업 제한 시간

기본 NAS 작업 제한 시간은 14일로 설정되며, 그 이후에는 작업이 취소됩니다. 더 긴 시간 동안 작업이 실행될 것으로 예상되면 검색 작업을 추가 14일 동안 한 번만 더 재개할 수 있습니다. 전체적으로 검색 작업은 재개를 포함하여 28일 동안 실행할 수 있습니다.

최대 실패 시도 횟수 설정

최대 실패 시도 횟수는 max_nas_trial 설정의 약 1/3로 설정해야 합니다. 실패한 시도 횟수가 이 한도에 도달하면 작업이 취소됩니다.

검색을 중지해야 하는 경우

다음 경우에 검색을 중지해야 합니다.

검색 곡선이 수렴되기 시작함(편차 감소): 참고: 지연 제한이 사용되지 않거나 느슨한 지연 제한과 함께 하드 지연 제한이 사용되는 경우 곡선에서 리워드 증가를 표시하지 않을 수 있지만 여전히 수렴을 표시해야 합니다. 이는 검색 시 컨트롤러가 조기에 양호한 정확성을 확인했을 수 있기 때문입니다.
시도의 20% 이상에 잘못된 리워드(실패)가 표시됩니다.
검색 곡선은 위와 같이 최대 500회까지 시도 후에도 증가하거나 수렴하지 않습니다. 리워드 증가 또는 편차 감소가 표시되면 계속할 수 있습니다.