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

Cloud TPU 멀티슬라이스 환경은 데이터 센터 네트워크(DCN)를 통해 통신하는 여러 TPU Pod 슬라이스로 구성됩니다. DCN 수집 통계 도구를 사용하여 멀티슬라이스 환경이 DCN 네트워크를 얼마나 효율적으로 활용하는지 확인할 수 있습니다. 구체적으로 DCN 수집 통계 도구를 사용하면 다음을 수행할 수 있습니다.

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

DCN 수집 통계 도구의 모든 측정항목은 TPU별로 생성됩니다.

용어

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

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

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

Slack 시간

수집이 데이터를 보내고 받을 수 있는 시간 측정입니다. 여기에는 send, send-done, recv 또는 recv-done 작업이 포함되지 않습니다. 예를 들어 타임라인이 다음과 같다고 가정해 보겠습니다.

v5e 포드 칩

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

Slack 시간 = t1 + t2 + t3

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

중단 기간

수집이 발신, 발신 완료, 수신, 수신 완료 작업에 소비하는 평균 기간입니다. 참고로 여기에는 데이터 전송에 소요된 시간이 포함되지 않습니다. 예를 들어 타임라인이 다음과 같다고 가정해 보겠습니다.

v5e 포드 칩

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

중단 기간 = t발신 + t발신 완료 + t수신 + t수신 완료

관찰 기간

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

v5e 포드 칩

관찰된 기간은 다음과 같이 계산됩니다.

관찰 기간 = t발신 + t1 + t발신 완료 + t2 + t수신 + t3 + t수신 완료

발생 횟수

프로필 기간 동안 수집이 시작되고 완료된 횟수입니다. 수집은 send 작업이 발생할 때 시작되고 일치하는 recv-end 작업이 발생할 때 완료됩니다. send 작업과 일치하는 recv-done 작업은 이 측정항목에 포함되도록 프로필 기간 내에 발생해야 합니다.

집계된 중단 합계

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

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

전송되는 데이터 크기

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

필요한 대역폭

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

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

도구 상태

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

DCN 수집 통계 지원되는 TPU 런타임의 TensorFlow 버전
Slack 시간 TensorFlow 2.15.0, 텐서보드 2.15.1, tensorboard-plugin-profile 2.15.0
중단 기간 TensorFlow 2.15.0, 텐서보드 2.15.1, tensorboard-plugin-profile 2.15.0
관찰 기간 TensorFlow 2.15.0, 텐서보드 2.15.1, tensorboard-plugin-profile 2.15.0
발생 횟수 TensorFlow 2.15.0, 텐서보드 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 작업을 예약할 수 있도록 수집에 대해 sendrecv-done 작업을 팬아웃하는 것이 좋습니다. 더 많은 HLO 작업을 겹치면 TPU 중단 시간이 줄어듭니다.
  6. Trace 뷰어에서 최대로 집계된 중단 합계가 있는 DCN 수집에 대한 recv-done 작업 기간을 확인합니다. 전송 기간이 길면 일반적으로 데이터를 가져오기 위해 네트워크에서 recv-done 작업이 차단되므로 대역폭 병목 현상이 발생할 수 있습니다.
  7. recv-done 작업 기간이 Slack 시간에 비해 너무 높지 않다면 하드웨어 문제가 있을 수 있습니다.