결과와 시간 창으로 문제 설명
"GPU가 작동하지 않습니다" 대신 검증 가능한 관찰로 바꾸십시오. 첫 결과가 늦게 도착하거나, 단계에 일시 정지가 있거나, 허용된 출력 수가 감소하는 경우입니다. 입력 데이터셋, 애플리케이션 버전, 설정, 관찰 기간을 제시하십시오. 첫 실행은 이미 준비된 실행과 다른 단계를 포함할 수 있으므로 이를 명시하지 않고 섞지 마십시오.
경로를 파일 열기, CPU 준비, 전송, GPU 계산, 쓰기, 검증으로 나누십시오. 이러한 단계는 겹칠 수 있으므로 이 구분은 추적과 대조할 가설입니다. 동일한 시간대와 충분한 정밀도로 경계를 기록하십시오. 일시 정지 후에 수집한 하드웨어 그래프는 그 값이 이례적으로 보이더라도 일시 정지를 설명할 수 없습니다.
백분율과 메모리를 올바르게 읽기
NVIDIA SMI에서 GPU 사용률은 최소 하나의 커널이 실행된 샘플링 간격의 비율을 나타냅니다. 이는 모든 구성 요소의 성능 점수가 아닙니다. 메모리 사용률은 읽기 또는 쓰기 활동을 나타내며 점유된 메모리 양과 혼동해서는 안 됩니다. 문서에서는 환경에 따라 일부 필드를 사용할 수 없을 수 있다고도 명시합니다.
따라서 지표의 정확한 이름과 단위를 유지하십시오. 높은 메모리 양은 대기 중 보관된 데이터에 해당할 수 있고, 낮은 활동은 정상적인 준비 단계에서 나타날 수 있습니다. 반대로 높은 활동이 프로그램이 유용한 작업을 수행한다는 것을 입증하지는 않습니다. 하드웨어와 동시에 출력 및 애플리케이션 진행 상황을 살펴봐야 합니다.
상관관계가 있는 충분히 짧은 측정값 수집
대표적인 시퀀스를 선택하고 수집 범위를 해당 시퀀스로 제한하세요. 시간, GPU 식별자, 작업, 점유된 메모리, 애플리케이션 단계를 기록하세요. 동시에 시스템에서 사용할 수 있는 도구를 사용하여 CPU 프로세스와 그 대기, 읽기 및 쓰기를 관찰하세요. 모든 코어에 대한 평균은 포화된 단일 스레드를 가릴 수 있으므로 관련 프로세스도 살펴보세요.
아래 읽기 명령은 이미 NVIDIA SMI가 설치된 허가된 NVIDIA 대상용으로 제안된 것입니다. 이 가이드에서는 실행되지 않았습니다. 이 명령은 CSV의 단위를 유지하고 중단될 때까지 초당 한 번씩 관측값을 표시합니다. 사용 중인 버전에서 지원하는 필드를 확인하고 시나리오가 끝나면 수집을 중지하세요. N/A 필드는 알 수 없는 값이므로 0으로 바꾸지 마세요.
최소 로그는 작업 식별자, 시간대가 포함된 시간, 현재 단계, 식별 가능한 입력 또는 배치, 진행 상황, 그리고 발생한 오류를 연결합니다. 여기에는 비밀이나 진단에 불필요한 업무 내용이 포함되어서는 안 됩니다. 원격 측정이 누락된 경우 먼저 수집 장치와 애플리케이션 진행 상황을 확인하세요. 빈 곡선은 프로세스가 중지되었음을 증명하지 않습니다. 관찰이 없는 기간은 기억으로 재구성하지 말고 표시하세요.
nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1단서와 결론을 구분하기
애플리케이션이 입력을 기다리는 동안 GPU 활동이 감소하면 파일 경로를 살펴보세요. 긴 CPU 준비 중에 감소하면 해당 단계와 실제 병렬성을 살펴보세요. 장치가 분산 작업의 다른 참여자를 기다리면 부하 균형과 통신을 확인하세요. 여러 증상이 동시에 발생할 수 있으며, 그 상관관계는 아직 인과관계의 증거가 아닙니다.
짧은 가설과 이를 가려낼 수 있는 변경 사항을 작성하세요. 예를 들어, 이미 준비된 동일한 입력을 평소의 준비 방식과 비교하면 결과가 동일하게 유지되는 조건에서 한 단계를 분리할 수 있습니다. 배치 크기, 정밀도, 프로세스 수, 파일 위치를 동시에 변경하지 마세요. 개선을 귀속시키기 어려워집니다.
| 상관된 관찰 | 가능한 가설 | 다음 확인 |
|---|---|---|
| GPU 대기 및 긴 입력 읽기 | 데이터 공급에 의한 제한 | 준비된 하위 집합을 평소 입력과 비교 |
| 일시 중지 동안 사용 중인 CPU 스레드 | 해당 스레드에 의한 준비 또는 시작 제한 | GPU를 아직 변경하지 않고 해당 단계 프로파일링 |
| 참여자가 다른 참여자를 기다림 | 불균형 또는 통신 | 프로세스별 단계 비교 |
| 높은 활동, 적은 승인된 출력 | 비용이 큰 작업, 재시도 또는 거부된 결과 | 각 기간을 진행 상황 및 오류와 연결 |
가상 예시: 100초 루프 분석하기
가상 팀 «목업 리뷰»는 겹치지 않는 루프를 설명합니다. CPU 준비 60초, GPU 계산 20초, 그다음 내보내기 20초입니다. 총합은 100초이며 GPU 계산에 할당된 시간 비율은 20/100, 즉 20 %입니다. 이 교육용 계산은 샘플링 도구의 백분율을 예측하지 않으며 카탈로그에 있는 어떤 GPU의 측정값과도 일치하지 않습니다.
준비 시간을 계산과 출력은 그대로 둔 채 30초로 줄일 수 있다고 가정해 봅시다. 그러면 루프는 30 + 20 + 20 = 70초가 됩니다. 30초가 줄어들고 GPU 비율은 20/70, 즉 약 28,6 %입니다. 반대로 GPU 계산만 가정상 절반으로 줄이면 60 + 10 + 20 = 90초가 됩니다. 이 시나리오는 가장 긴 대기를 처리하는 것이 카드를 바꾸는 것보다 더 큰 효과를 낼 수 있는 이유를 설명합니다.
| 시나리오 | CPU 준비 | GPU 계산 | 내보내기 | 합계 |
|---|---|---|---|---|
| 초기 가설 | 60초 | 20초 | 20초 | 100초 |
| 가상으로 단축된 준비 | 30초 | 20초 | 20초 | 70초 |
| GPU 계산만 가상으로 절반으로 줄임 | 60초 | 10초 | 20초 | 90초 |
프로파일러로 단계 심층 분석
일반적인 관찰이 느린 구역을 설명하지 못한 채 위치만 알려준다면, 짧은 구간에서 애플리케이션에 맞는 프로파일러를 사용하세요. PyTorch Profiler는 CPU 및 CUDA 이벤트를 수집하고 수집 구간을 구성할 수 있습니다. 문서에서는 형태나 스택 기록을 활성화할 때 오버헤드가 발생한다고 알려줍니다. 따라서 상세 트레이스는 진단 도구이며, 그 총 시간을 프로그램의 정상 시간으로 아무런 유보 없이 제시해서는 안 됩니다.
기술적 작업을 실제 업무와 연결할 수 있도록 단계 이름을 충분히 명확하게 유지하세요. 예를 들어 파일 그룹 준비, 전송, 애플리케이션 단계 또는 출력 게시 등입니다. 가설에 필요한 세부 수준부터 시작하세요. 변경 후에는 다시 비교 가능한 관찰을 한 번 수행한 다음, 무거운 계측 없이 한 번 더 실행하세요. 이 두 번째 확인은 이점이 일상적인 조건에서도 존재하는지 검증할 수 있게 해줍니다.
문제를 가리는 수정 피하기
동시성을 높이면 GPU를 채울 수 있지만 디스크, 호스트 메모리 또는 출력에 과부하를 줄 수 있습니다. 배치 크기를 늘리면 지연 시간과 필요한 메모리가 달라질 수 있습니다. 정밀도를 낮추면 결과가 바뀔 수 있습니다. 이러한 결정이 금지되는 것은 아니지만, 표시되는 백분율이 올라간다는 이유로 채택하기보다는 동일한 비즈니스 목표를 기준으로 부작용까지 평가해야 합니다.
단순한 활동 감소를 진단하기 위해 장치를 재설정하거나 하드웨어 설정을 변경하지 마세요. 먼저 읽기부터 시작하고, 명시적인 오류는 권한을 가진 담당자가 검토하도록 하세요. 또한 비공개 경로, 기밀 설정 또는 입력 데이터가 포함된 원시 트레이스를 게시하지 마세요. 진단에 유용한 발췌본을 준비하고, 전체 증거는 팀의 허용된 범위 내에 보관하세요.
결정에 유용한 증거로 진단 마무리하기
최종 기록에는 증상, 채택한 가설, 시도한 변경, 그 조건 및 관찰된 결과를 명시해야 합니다. 동일한 입력 집합, 동일한 품질 및 동일한 종료 정의에 대한 전후 비교를 최소 하나 이상 보관하세요. 결과가 결정적이지 않다면 무엇을 배제했는지와 다음에 필요한 관찰을 기록하세요. 문서화된 기각 경로는 다른 사람이 무작위로 다시 시작하는 일을 방지합니다.
정상적인 낮은 활동이 항상 수정을 필요로 하는 것은 아닙니다. 작업이 기한, 품질 및 예산을 준수한다면 취약한 최적화보다 복잡성을 줄이는 것이 더 나을 수 있습니다. 새로운 구성을 고려한다면 입증된 제약 조건을 수령 기록에 전달하세요. 어떤 단일 측정값도 카탈로그를 분류하지 않으며, 이 예시의 어떤 값도 약속된 성능을 구성하지 않습니다.
결정을 위한 질문
100% 사용률이 모든 것이 최적화되었음을 증명하나요?
아니요. 백분율은 도구의 정의에 따른 활동을 나타낼 뿐이며, 결과의 품질이나 프로그램의 전체 효율성을 측정하지 않습니다. 수용된 출력까지의 시간, 오류, 대기 및 공유 리소스도 함께 추적하세요.
활동이 낮을 때 더 강력한 GPU를 선택해야 하나요?
제한 단계를 식별하기 전에는 아닙니다. 데이터 대기나 긴 CPU 준비는 다른 카드로도 변하지 않을 수 있습니다. 가설을 세우고, 표적화된 변경을 비교하고, 전체 경로를 검토하세요.
메트릭이 N/A인 경우 어떻게 해야 하나요?
사용 불가로 유지하고, 사용 환경에서 도구가 무엇을 지원하는지 확인하세요. 값이 없다고 해서 활동이 없는 것은 아닙니다. 범위를 명시하면서 애플리케이션 이벤트나 다른 허용된 도구로 보완하세요.