멀티슬라이스 환경 프로파일링

참고: 이 페이지는 Cloud TPU API에 적용됩니다. Ironwood(TPU7x)의 경우 Google Kubernetes Engine(GKE)을 사용해야 합니다. 자세한 내용은 GKE의 TPU 정보를 참조하세요.

Cloud TPU 멀티슬라이스 환경은 데이터 센터 네트워크(DCN)를 통해 통신하는 TPU 슬라이스 여러 개로 구성됩니다. XProf의 Megascale 통계 도구를 사용하여 멀티슬라이스 환경에서 DCN 네트워크를 얼마나 효과적으로 활용하는지에 대한 정보를 볼 수 있습니다. 구체적으로 Megascale 통계 도구를 사용하면 다음을 수행할 수 있습니다.

• 수집된 데이터를 기반으로 슬라이스 간 네트워크 성능 보기 및 이해
• 성능 병목 현상 식별
• 모델 성능 최적화

Megascale 통계 도구의 모든 측정항목은 TPU별로 생성됩니다. 이 도구를 사용 설정하려면 프레임워크에서 프로필을 캡처하는 동일한 단계를 수행하고 XProfiler 라이브러리를 사용하여 프로필을 볼 수 있는 텐서보드 XProf 인스턴스를 설정합니다. 워크로드가 멀티슬라이스 워크로드로 실행된 경우 텐서보드에 모든 멀티슬라이스 워크로드에 대한 'Megascale 통계' 도구가 표시됩니다.

XProf의 Megascale 통계 도구에 대한 자세한 내용은 Megascale 통계 도구 가이드를 참조하세요.

용어

DCN 수집 통계 도구는 멀티슬라이스 환경 내에서 TPU 슬라이스 간에 발생하는 통신을 설명하는 측정항목을 표시합니다. TPU 런타임이 슬라이스 간 통신을 시작하면 일련의 작업이 사용됩니다.

• send: 호스트를 중단하여 직접 메모리 액세스(DMA)를 시작하고 호스트에 채워진 버퍼를 제공하여 데이터 전송을 시작합니다.
• send-done: 데이터 전송이 완료됐음을 호스트에 알립니다.
• recv: 호스트가 전송된 데이터로 채울 수 있도록 빈 버퍼를 제공합니다.
• recv-done: 데이터가 수신되었음을 호스트에 알립니다.

참고: 실제 데이터 전송은 send 작업이 완료된 후에 수행됩니다. send-done 작업은 데이터가 전송된 후에 수행됩니다. 마찬가지로 데이터는 recv 작업이 완료된 후에 수신됩니다. recv-done 작업은 데이터가 수신된 후에 수행됩니다.

수집은 send 작업이 수행될 때 시작되고 일치하는 recv-done 작업이 수행될 때 완료됩니다.

Slack 시간

수집에서 데이터를 전송 및 수신할 수 있는 시간 측정값입니다. send, send-done, recv 또는 recv-done 작업은 여기에 포함되지 않습니다. 예를 들어 다음 타임라인을 가정해 보겠습니다.

이 예시에서 Slack 시간은 다음과 같이 계산됩니다.

Slack 시간 = t₁ + t₂ + t₃

Slack 시간을 늘리면 수집에 사용되는 TPU가 중단될 가능성이 줄어듭니다. 다른 샤딩 방법을 선택하여 slack 시간을 늘릴 수 있습니다.

중단 기간

수집이 send, send-done, recv, recv-done 작업에 소비하는 평균 기간입니다. 여기에는 데이터 전송에 소요된 시간이 포함되지 않습니다. 예를 들어 다음 타임라인을 가정해 보겠습니다.

이 예시에서 중단 기간은 다음과 같이 계산됩니다.

중단 기간 = t_send + t_send-done + t_recv + t_recv-done

모니터링된 기간

데이터 전송 및 수신 시간을 포함한 send 작업과 recv-done 작업 간의 시간입니다. 예를 들어 다음 타임라인을 가정해 보겠습니다.

모니터링된 기간은 다음과 같이 계산됩니다.

모니터링된 기간 = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-done

발생 횟수

프로필 기간 중에 수집이 시작되고 완료된 횟수입니다. 수집은 send 작업이 수행될 때 시작되고 일치하는 recv-end 작업이 수행될 때 완료됩니다. send 작업과 해당 recv-done 작업이 이 측정항목에 포함되려면 프로필 기간 내에 수행되어야 합니다.

집계된 중단 합계

수집이 프로필 기간 중에 TPU를 중지한 시간 합계입니다. 집계된 중단 합계는 다음과 같이 계산합니다.

집계된 중단 합계 = 중단 기간 * 발생 횟수

전송된 데이터 크기

프로필 기간 중에 수집을 위해 네트워크를 통해 전송된 데이터양입니다.

필요한 대역폭

제공된 slack 내에서 데이터를 전송하는 데 필요한 대역폭입니다. 이 측정항목을 사용하면 프로필 기간 중에 네트워크 대역폭을 경쟁하는 수집의 수를 확인할 수 있습니다. 필요한 대역폭은 다음과 같이 계산합니다.

필요한 대역폭 = 전송된 데이터 크기 / slack 시간

도구 상태

다음 표에는 DCN 수집 통계 도구에 표시되는 각 측정항목에 필요한 TensorFlow 또는 TPU 런타임 버전이 나와 있습니다.

DCN 수집 통계	지원되는 TPU 런타임의 TensorFlow 버전
Slack 시간	TensorFlow 2.15.0, tensorboard 2.15.1 및 tensorboard-plugin-profile 2.15.0
중단 기간	TensorFlow 2.15.0, tensorboard 2.15.1 및 tensorboard-plugin-profile 2.15.0
모니터링된 기간	TensorFlow 2.15.0, tensorboard 2.15.1 및 tensorboard-plugin-profile 2.15.0
발생 횟수	TensorFlow 2.15.0, tensorboard 2.15.1 및 tensorboard-plugin-profile 2.15.0
집계된 중단 합계	tf-nightly, tb-nightly, tbp-nightly
전송된 데이터 크기	tf-nightly, tb-nightly, tbp-nightly
필요한 대역폭	tf-nightly, tb-nightly, tbp-nightly

DCN 수집 통계 도구 분석 방법

1. 텐서보드 서버를 실행하고 프로필 탭으로 이동합니다.

2. DCN 수집 통계 도구의 테이블을 집계된 중단 합계를 기준으로 내림차순으로 정렬합니다.

3. 집계된 중단 합계가 가장 높은 DCN 수집 이름을 식별합니다. 이 수집의 집계된 중단 기간이 다른 그룹에 비해 크게 높은 경우 이는 DCN 수집에 병목 현상이 있음을 나타낼 수 있습니다.

4. DCN 수집에 필요한 대역폭에 코어 수를 곱합니다. 코어가 v4 TPU 호스트당 8개 있으므로 수집에 필요한 대역폭은 표시된 값의 8배입니다. 필요한 대역폭이 TPU의 최대 네트워크 대역폭보다 큰 경우 이는 네트워크 혼잡을 의미할 수 있습니다. 필요한 대역폭을 줄이려면 사용하는 샤딩 메커니즘을 변경해 봅니다. 샤딩 메커니즘에 대한 자세한 내용은 Cloud TPU 멀티슬라이스 개요를 참조하세요.

5. HLO 덤프를 생성하여 컴파일러 문제가 있는지 확인합니다. 더 겹치는 HLO 작업을 예약할 수 있도록 수집에 대해 send 및 recv-done 작업을 팬아웃하는 것이 좋습니다. 더 많은 HLO 작업을 겹치면 TPU 중단 시간이 줄어듭니다.

6. DCN 수집에 대한 Trace 뷰어에서 최대로 집계된 중단 합계가 있는 recv-done 작업의 기간을 확인합니다. 전송 기간이 길면 일반적으로 데이터를 가져오기 위해 네트워크에서 recv-done 작업이 차단되므로 대역폭 병목 현상이 발생할 수 있습니다.

7. recv-done 작업 기간이 slack 시간에 비해 너무 높지 않은 경우 이는 하드웨어 문제를 나타낼 수 있습니다.