HyperAI超神经

Profiler v1.9의 개선 사항은 런타임 및/또는 메모리 측면에서 가장 많은 에너지를 소모하는 실행 단계를 타겟팅하는 데 중점을 두고 있으며, GPU와 CPU 간의 작업 부하 분포를 시각화합니다.

Profiler v1.9에는 다음을 포함한 5가지 새로운 주요 기능이 추가되었습니다.

1. 분산된 훈련 뷰: 이를 통해 분산된 학습 작업에 소모되는 시간과 메모리를 파악할 수 있습니다. 훈련 모델이 있다고 가정해 보겠습니다. 부하를 워커 노드로 나누어 병렬로 실행하면 블랙박스처럼 동작하여 다양한 문제가 발생할 수 있습니다. 이 모델의 전반적인 목표는 학습 속도를 높이는 것입니다. 이 분산형 교육 뷰는 단일 노드 내에서 문제를 진단하고 디버깅하는 데 도움이 됩니다.

2. 메모리 보기: 이 보기를 통해 메모리 사용량을 더 잘 이해할 수 있습니다. 이 도구는 프로그램의 다양한 작업 단계에서 활성 메모리 할당을 표시하여 메모리 부족 오류를 방지하는 데 도움이 됩니다.

3. GPU 애플리케이션 시각화: 이 도구는 GPU가 완전히 활용되도록 보장합니다.

4. 클라우드 스토리지 지원: 이제 Tensorboard 플러그인은 Azure Blob Storage, Amazon S3 및 Google Cloud Platform에서 구문 분석된 데이터를 읽을 수 있습니다.

5. 소스 코드로 이동: 이 기능은 스택 추적 정보의 시각화를 지원하고 소스 코드로 바로 이동할 수 있게 해줍니다. 이를 통해 프로파일링 결과에 따라 코드를 빠르게 최적화하고 반복할 수 있습니다.

PyTorch 프로파일러 Colab 포털

Colab 포털 중국어 버전

Colab 콘텐츠 한눈에 보기:

데이터 및 모델 준비
Profiler를 사용하여 실행 이벤트 기록
프로파일러 실행
TensorBoard를 사용하여 결과를 보고 모델 성능을 분석하세요
Profiler를 사용하여 성능 개선
다른 고급 기능을 사용하여 성능 분석

PyTorch 프로파일링 시작하기

첫 번째:

$ pip install torch-tb-profiler

import torch.profiler as profiler
With profiler.profile(XXXX)

주목: CUDA 및 CPU 분석에 대한 자세한 내용은 다음을 참조하세요. 여기

with torch.profiler.profile( 
activities=[ 
torch.profiler.ProfilerActivity.CPU, 
torch.profiler.ProfilerActivity.CUDA],

profiler.record_function("$NAME"): 함수 블록에 데코레이터를 추가할 수 있습니다.
profiler.profile 아래의 Profile_memory=True 매개변수를 사용하면 CPU와 GPU의 메모리 사용량을 분석할 수 있습니다.

PyTorch 모델 성능 시각화

### 분산 학습

최근 딥 러닝 분야의 발전으로 대규모 데이터 세트와 대규모 모델의 가치가 입증되었는데, 이는 모델을 학습하는 데 더 많은 컴퓨팅 리소스가 필요하다는 것을 의미합니다.

분산 데이터 병렬 처리(DDP)와 NVIDIA 멀티카드 통신 프레임워크(NCCL)는 PyTorch에서 딥 러닝 학습을 가속화하기 위해 널리 채택된 패러다임입니다.

이 버전의 PyTorch Profiler에서는 NCCL 백엔드를 사용한 DDP가 지원됩니다.
여기에 이미지 설명을 삽입하세요

컴퓨팅/통신 개요

분산형 학습 뷰의 "컴퓨팅/통신 개요"에서 사용자는 모든 작업자 간의 "로드 밸런서" 노드의 컴퓨팅 및 통신 비율을 관찰할 수 있으며, 이는 세분성에 따라 측정됩니다.

로드 밸런서 관련 링크: 여기

시나리오 1:

한 작업자의 계산 및 중복 시간이 다른 작업자보다 길다면 이는 작업 부하 분산에 문제가 있거나 한 노드가 뒤처져 있음을 나타낼 수 있습니다. 계산은 GPU 커널 시간의 합계에서 오버랩 시간을 뺀 것입니다. 중복 시간이란 계산 과정 중에 통신을 끼워 넣어서 절약한 시간을 말합니다.

더 긴 오버랩은 계산과 통신 사이의 병렬성이 더 우수함을 나타냅니다.이상적으로는 계산과 통신이 완전히 겹치게 될 것입니다. 의사소통은 전체 의사소통 시간에서 중복 시간을 뺀 시간입니다.

다음 예는 이것이 Tensorboard에서 어떻게 표시되는지 보여줍니다.
여기에 이미지 설명을 삽입하세요
낙오자의 예

시나리오 2:

배치 크기가 작은 경우(즉, 모든 워커에 대한 계산이 작은 경우) 또는 전송할 데이터가 큰 경우 계산 대 통신 비율도 작을 수 있으며, 이 경우 Profiler에서 GPU 사용률과 대기 시간을 확인할 수 있습니다.

사용자는 이러한 계산/통신 관점을 기반으로 코드를 검토하고 그래디언트 축적을 채택하거나 배치 크기를 늘려 통신 비율을 낮춤으로써 통신을 줄일 수 있습니다. DDP 통신 시간은 모델 크기에 따라 달라집니다. 배치 크기는 모델 크기와 아무런 관련이 없습니다. 따라서 배치 크기를 늘리면 계산 시간이 길어지고 계산-통신 인스턴스도 더 커질 수 있습니다.

### 동기화/통신 개요

동기화/통신 보기에서 사용자는 통신 효율성을 관찰할 수 있습니다. 이는 단계 시간에서 계산 및 통신 시간을 빼서 계산됩니다. 동기화 시간이란 전체 통신 시간 중 다른 작업자와 대기하고 동기화하는 데 소요되는 부분입니다. 동기화/통신 뷰에는 초기화, 데이터 로더, CPU 계산 등이 포함됩니다.

이 관점에서 우리는 다음을 볼 수 있습니다.전체 통신량 중 실제로 데이터 교환에 사용되는 비율은 얼마이며, 다른 작업자가 데이터를 제공할 때까지 기다리는 유휴 시간은 얼마입니까?

예를 들어, 비효율적인 작업 부하 분산이나 낙오자 문제가 있는 경우 동기화/통신 보기에서 이를 발견할 수 있습니다. 이 보기에서는 일부 근로자가 다른 근로자보다 더 오래 기다리고 있다는 것을 보여줍니다.

위의 표에서 우리는 각 노드의 모든 통신 사업자에 대한 자세한 통계를 알 수 있습니다. 이 표를 사용하면 어떤 연산자 유형이 호출되는지, 각 연산자가 몇 번 호출되는지, 각 연산자가 전송하는 데이터 크기 등을 파악할 수 있습니다.

메모리 뷰

이 도구는 모델 내 운영자의 하드웨어 리소스 소비량을 이해하는 데 사용할 수 있습니다. 운영자 수준에서 시간과 메모리 소비를 이해하면 성능 병목 현상을 해결하고 모델 실행 속도를 높이는 데 도움이 될 수 있습니다.GPU 메모리 크기가 제한되어 있으므로 메모리 사용 효율성을 최적화하면 다음과 같은 이점이 있습니다.

더 큰 모델을 실행하고 터미널 수준 작업에서 더 나은 성능을 발휘할 수 있습니다.
더 큰 배치 크기를 허용하여 학습 속도를 높입니다.

프로파일러는 프로파일러 간격 동안 모든 메모리 할당을 기록합니다. GPU 측이나 호스트 측에서 각 연산자의 메모리 사용량 세부 정보를 보려면 "장치"를 선택하세요.

참고: 다음 메모리 데이터를 생성하려면 profile_memory=True를 활성화해야 합니다.

타임라인의 GPU 메트릭

이 기능을 사용하면 하나 이상의 GPU가 충분히 활용되지 않을 때 성능 문제를 쉽게 디버깅할 수 있습니다. 이상적으로는 프로그램의 GPU 활용도가 높아야 하고(최대 100% GPU 활용도), CPU 간 통신 비용이 최소화되어야 하며, 전력 소모가 없어야 합니다.

개요: 개요 페이지에서는 세 가지 중요한 GPU 사용 지표(GPU 활용도, 추정 SM 효율성, 추정 달성 점유율)의 결과를 다양한 수준에서 강조하여 보여줍니다.

기본적으로 각 GPU에는 많은 SM이 있고, 각 SM에는 많은 Warp가 있는데, Warp는 동시에 많은 스레드를 실행할 수 있습니다. 워프 실행에는 많은 스레드가 있는데, 그 숫자가 GPU에 따라 달라지기 때문입니다. 높은 수준의 관점에서 볼 때, 타임라인의 GPU 지표는 개발자가 전체 스택에 대한 전체적인 관점을 얻는 데 도움이 될 수 있으며, 이는 매우 중요합니다.

GPU 사용률이 낮으면 모델에 문제가 있을 가능성이 있습니다. 일반적인 원인은 다음과 같습니다.

커널의 병렬 처리가 부족합니다. 즉, 배치 크기가 너무 작습니다.
루프에서 작은 커널을 호출한다는 것은 시작 오버헤드가 상각되지 않는다는 것을 의미합니다.
CPU 또는 I/O 병목 현상으로 인해 작업 부하가 부족하고 GPU 활용도가 낮아집니다.

개요 페이지의 성능 권장 사항 섹션에는 GPU 활용도를 개선하기 위한 실행 가능한 제안이 포함되어 있습니다. 이 예에서는 GPU 활용도가 낮으므로 성능을 개선하기 위해 배치 크기를 늘리는 것이 좋습니다. 성능 권장 사항에 따라 배치 크기를 4에서 32로 늘리자 GPU 사용률이 60.68% 증가했습니다.

GPU 사용률: 프로파일러에서는 GPU 엔진이 워크로드를 실행할 때 단계 간격 시간이 나타납니다. 활용률이 높을수록 좋습니다. GPU 활용도만으로 성능 병목 현상을 판단하는 것은 정확하지 않습니다. 이것을 사용해서는 실행 중인 스트리밍 멀티프로세서의 수를 알 수 없습니다.

이 지표는 유휴 기간을 감지하는 데 유용하지만, 값이 높다고 해서 반드시 GPU가 매우 효율적으로 사용되고 있다는 것을 의미하지는 않습니다. 예를 들어, 지속적으로 실행되는 단일 스레드 커널의 GPU 사용률은 100%가 됩니다.

추정 스트림 프로세서 효율성(Est. SM Efficiency)은 더 자세한 지표입니다. 이는 추적 중에 사용 중이던 SM의 백분율, SM에 적어도 하나의 활성 워프가 있었던 시간의 백분율, 워프가 유휴 상태였던 시간의 백분율을 나타냅니다.

NVIDIA 문서: 여기

추정 SM 효율성에도 한계가 있습니다. 예를 들어, 블록당 스레드가 하나만 있는 커널은 모든 SM을 완전히 활용할 수 없습니다. 각 SM의 활용도는 SM 효율성만으로는 알 수 없습니다. 메모리 로드 결과를 기다리는 동안의 일시 정지를 포함하여 각 SM에서 수행되는 작업에 대해서만 알 수 있습니다.

SM의 높은 활용도를 유지하려면 정지가 발생할 때마다 충분한 수의 레디 랩이 실행되도록 보장해야 합니다.

성능 진단 문제에 대해서는 Est. 달성된 점유율은 추정 점유율보다 더 정확합니다. SM 효율성 및 GPU 활용도. 추정된 달성 점유율은 SM당 얼마나 많은 워프가 동시에 활성화될 수 있는지를 나타냅니다. 충분한 수의 활성 워프를 갖는 것은 종종 좋은 처리량을 달성하는 데 중요합니다. GPU 활용도 및 SM 효율성과 달리 이 값을 최대한 높게 만드는 것이 최종 목표는 아닙니다.

경험적 관점에서 볼 때, 이 지표를 15% 이상으로 높이면 처리량이 크게 향상될 수 있습니다. 하지만 어느 순간, 수익이 점점 줄어드는 것을 경험하게 됩니다. 예를 들어, 값이 30%에 도달하면 그에 따른 혜택은 불확실해집니다. 이 지표는 커널 실행 중 모든 워프 스케줄러의 평균을 보여줍니다.

NVIDIA 문서: 여기

Est의 값이 클수록 점유율을 달성할수록 더 좋습니다.

세부 정보: Resnet50_batchsize4

세부 정보: Resnet50_batchsize32

커널 뷰: 커널에는 "SM당 블록"과 "추정 달성 점유율"이 있습니다.

추정 달성된 점유율은 모델의 성능을 비교하는 데 유용한 도구입니다.

SM당 평균 블록 수:

SM당 블록 수 = 커널의 블록 수 / GPU의 SM 수. 이 숫자가 1보다 작으면 GPU 멀티프로세서가 완전히 활용되지 않았음을 나타냅니다. "SM당 평균 블록"은 이 커널 이름의 모든 실행에 대한 가중 평균이며, 각 실행의 지속 시간을 가중치로 사용합니다.

평균 추정치 달성된 점유율

Est의 정의 달성된 점유율은 위에 설명한 것과 동일합니다. 평균 추정치 달성된 점유율은 커널 이름의 모든 실행에 대한 가중 평균이며, 각 실행의 기간을 가중치로 사용합니다.

추적 보기:

추적 보기는 모델에서 운영자의 지속 시간과 어떤 시스템이 작업을 수행했는지를 보여주는 타임라인을 표시합니다. 이러한 보기는 입력이나 모델 학습으로 인해 발생하는 높은 오버헤드와 긴 실행 시간을 식별하는 데 도움이 될 수 있습니다. 현재 추적 보기에는 GPU 사용률과 추정값이 표시됩니다. 타임라인에 따른 SM 효율성.

위의 예에서 스레드 28022의 "ProfilerStep5" 동안의 GPU 사용률은 "Optimizer.step" 동안의 GPU 사용률보다 높습니다. 확대해서 원인을 확인할 수 있습니다.

위 그림에서 볼 수 있듯이, 전자의 커널은 후자의 커널보다 더 길다. 후자의 경우 커널 실행 시간이 너무 짧아 GPU 활용도가 낮습니다.

추정 SM 효율성: 각 코어에는 계산된 EST가 있습니다. SM 효율성은 0-100% 사이입니다. 예를 들어, 아래 커널은 타일이 64개뿐이고, 이 GPU의 SM이 80이므로 "예상 SM 효율성"은 64/80, 즉 0.8입니다.

클라우드 스토리지 지원

pip install tensorboard를 실행한 후 클라우드 공급자를 통해 데이터를 읽으려면 다음을 실행할 수 있습니다.

torch-tb-profiler[blob] 
torch-tb-profiler[gs] 
torch-tb-profiler[s3]

pip install torch-tb-profiler[blob], pip install torch-tb-profiler[gs] 또는 pip install torch-tb-profiler[S3]를 사용하여 클라우드 공급자로부터 데이터를 읽을 수 있습니다.

자세한 내용은 다음을 참조하세요. 여기

소스 코드로 이동

TensorBoard와 PyTorch Profiler를 Visual Studio Code(VS Code)에 직접 통합하는 가장 큰 이점 중 하나는 Profiler 스택 추적에서 소스 코드(파일 및 줄)로 바로 이동할 수 있다는 것입니다. VS Code Python 확장 기능은 이제 TensorBoard 통합을 지원합니다.

소스 코드로 이동하는 기능은 Tensorboard가 VS Code에서 실행 중일 때만 사용할 수 있습니다. with_stack=True로 프로파일링을 하면, 스택 추적이 플러그인 UI에 나타납니다. PyTorch Profiler에서 스택 추적을 클릭하면 VS Code에서 해당 파일이 열리고 디버깅을 위해 해당 코드로 바로 이동합니다. 이를 통해 분석 결과와 제안을 기반으로 코드를 신속하게 최적화하고 수정할 수 있습니다.

Visual Studio Code 플러그인 UI를 사용하여 소스 코드로 이동

배치 크기 성능을 최적화하는 방법에 대한 자세한 내용은 다음 튜토리얼을 참조하세요. 여기

PyTorch Profiler는 PyTorch Lightning과도 통합될 수 있습니다. trainer.profiler=pytorch로 번개 훈련 작업을 시작하면 추적 정보가 생성됩니다.

자세한 예: 여기

원래 주소: 여기