경고: 이 프로젝트는 더 이상 사용되지 않습니다. TensorFlow용 Swift는 머신 러닝, 컴파일러, 차별화 가능한 프로그래밍, 시스템 설계 등에 대한 최신 연구를 통합한 머신 러닝을 위한 차세대 플랫폼의 실험이었습니다. 2021년 2월에 보관되었습니다.

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

X10 문제 디버깅

X10 가속기 백엔드는 그래프 기반 병렬 계산에 훨씬 더 높은 처리량을 제공할 수 있지만 지연된 추적 및 JIT(Just-In-Time) 컴파일로 인해 때때로 명확하지 않은 동작이 발생할 수 있습니다. 여기에는 그래프나 텐서 형태 변경으로 인한 트레이스의 빈번한 재컴파일이나 컴파일 중에 메모리 문제를 일으키는 거대한 그래프가 포함될 수 있습니다.

문제를 진단하는 한 가지 방법은 X10에서 제공하는 실행 측정항목과 카운터를 사용하는 것입니다. 모델이 느릴 때 가장 먼저 확인해야 할 것은 측정항목 보고서를 생성하는 것입니다.

측정항목

메트릭 보고서를 인쇄하려면 프로그램에 PrintX10Metrics() 호출을 추가하세요.

import TensorFlow

...
PrintX10Metrics()
...

그러면 INFO 수준에서 다양한 측정항목과 카운터가 기록됩니다.

측정항목 보고서 이해

보고서에는 다음과 같은 내용이 포함됩니다.

XLA 컴파일을 트리거한 횟수와 컴파일에 소요된 총 시간입니다.
XLA 계산을 시작한 횟수와 실행에 소요된 총 시간입니다.
우리가 생성/파괴하는 장치 데이터 핸들 수 등

이 정보는 샘플의 백분위수로 보고됩니다. 예는 다음과 같습니다:

Metric: CompileTime
  TotalSamples: 202
  Counter: 06m09s401ms746.001us
  ValueRate: 778ms572.062us / second
  Rate: 0.425201 / second
  Percentiles: 1%=001ms32.778us; 5%=001ms61.283us; 10%=001ms79.236us; 20%=001ms110.973us; 50%=001ms228.773us; 80%=001ms339.183us; 90%=001ms434.305us; 95%=002ms921.063us; 99%=21s102ms853.173us

또한 내부 소프트웨어 상태를 추적하는 정수 변수라는 카운터도 제공합니다. 예를 들어:

Counter: CachedSyncTensors
  Value: 395

알려진 주의사항

X10이 지원하는 Tensor 는 기본 Eager 모드 Tensor 와 의미상 유사하게 동작합니다. 그러나 성능 및 완전성에 대한 몇 가지 주의 사항이 있습니다.

재컴파일이 너무 많아 성능이 저하되었습니다.
XLA 컴파일은 비용이 많이 듭니다. X10은 새로운 모양이 나타날 때마다 사용자 개입 없이 자동으로 그래프를 다시 컴파일합니다. 모델은 몇 가지 훈련 단계 내에서 안정화된 모양을 확인해야 하며 그 시점부터는 재컴파일이 필요하지 않습니다. 또한 실행 경로는 같은 이유로 빠르게 안정화되어야 합니다. X10은 새 실행 경로가 발견되면 다시 컴파일됩니다. 요약하면 재컴파일을 피하기 위해 다음과 같습니다.
- 매우 가변적인 동적 형태를 피하십시오. 그러나 다양한 모양의 수가 적으면 괜찮을 수 있습니다. 가능하면 텐서를 고정된 크기로 채웁니다.
- 훈련 단계 사이의 반복 횟수가 다른 루프를 피하십시오. X10은 현재 루프를 언롤링하므로 다양한 루프 반복 횟수가 다른(언롤링된) 실행 경로로 변환됩니다.
소수의 작업은 아직 X10에서 지원되지 않습니다.
XLA 및 정적 모양(현재는 단지 nonZeroIndices )을 통해 이를 표현하는 좋은 방법이 없거나 알려진 사용 사례(여러 선형 대수 연산 및 다항 초기화)가 부족하기 때문에 현재 지원되지 않는 소수의 연산이 있습니다. . 두 번째 범주는 필요에 따라 쉽게 해결할 수 있지만 첫 번째 범주는 XLA가 아닌 CPU와의 상호 운용성을 통해서만 해결할 수 있습니다. 상호 운용성을 너무 자주 사용하면 호스트 왕복 및 여러 추적에서 완전히 융합된 모델이 조각화되기 때문에 성능에 심각한 영향을 미칩니다. 따라서 사용자는 해당 모델에서 이러한 작업을 사용하지 않는 것이 좋습니다.
Linux에서는 XLA_SAVE_TENSORS_FILE (다음 섹션에 설명되어 있음)을 사용하여 지원되지 않는 작업을 호출한 Swift 스택 추적을 가져옵니다. 함수 이름은 swift-demangle 사용하여 수동으로 demangle할 수 있습니다.

추적 획득 및 그래프 작성

그래프 추적 방식에 문제가 있다고 의심되거나 추적 프로세스를 이해하려는 경우 로그아웃하고 추적을 시각화할 수 있는 도구가 제공됩니다. XLA_SAVE_TENSORS_FILE 환경 변수를 설정하여 X10이 찾은 추적을 로그아웃하도록 할 수 있습니다.

export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt

이러한 추적 로그는 text , hlo 및 dot 의 세 가지 형식으로 제공되며 형식은 환경 변수 XLA_SAVE_TENSORS_FMT를 통해 설정할 수 있습니다.

export XLA_SAVE_TENSORS_FMT=text

애플리케이션을 실행할 때 로그아웃된 text 표현은 X10에서 사용하는 고급 텍스트 표기법으로 각 개별 추적을 표시합니다. hlo 표현은 XLA 컴파일러에 전달되는 중간 표현을 보여줍니다. 이러한 로그가 너무 커지는 것을 방지하기 위해 훈련 또는 계산 루프 내에서 반복 횟수를 제한할 수 있습니다. 또한 애플리케이션을 실행할 때마다 이 파일에 추가되므로 실행 사이에 삭제하는 것이 좋습니다.

XLA_LOG_GRAPH_CHANGES 변수를 1로 설정하면 추적 로그 내에서 그래프의 변경 사항이 발생한 위치도 표시됩니다. 이는 재컴파일이 발생할 위치를 찾는 데 매우 유용합니다.

추적을 시각적으로 표현하기 위해 dot 옵션을 사용하면 Graphviz 호환 그래프가 로그아웃됩니다. 다음과 같은 트레이스 부분을 추출하면

digraph G {
    ...
}

자체 파일에 Graphviz(설치된 것으로 가정)를 통해 시각적 다이어그램을 생성할 수 있습니다.

dot -Tpng trace.dot -o trace.png

특히 XLA_LOG_GRAPH_CHANGES 와 함께 사용할 경우 XLA_SAVE_TENSORS_FILE 환경 변수를 설정하면 성능에 상당히 부정적인 영향을 미칠 수 있습니다. 디버깅할 때만 사용하고 일반 작업에는 사용하지 마십시오.

추가 환경 변수

디버깅을 위한 추가 환경 변수는 다음과 같습니다.

XLA_USE_BF16 : 1로 설정하면 모든 Float 값을 BF16으로 변환합니다. 자동 혼합 정밀도를 제공하므로 디버깅에만 사용해야 합니다.
XLA_USE_32BIT_LONG : 1로 설정하면 S4TF Long 유형을 XLA 32비트 정수 유형으로 매핑합니다. TPU에서 64비트 정수 계산은 비용이 많이 들기 때문에 이 플래그를 설정하는 것이 도움이 될 수 있습니다. 물론 사용자는 값이 여전히 32비트 정수에 맞는지 확인해야 합니다.