XLA 오류는 다양한 XLA 오류 소스로 분류됩니다. 각 소스에는 오류 메시지 외에 추가 컨텍스트 목록이 있으며, 이 목록은 카테고리 내 각 오류에 첨부됩니다.
🚧 이 표준화 작업은 진행 중이므로 아직 모든 오류 메시지에 오류 코드가 첨부되어 있지는 않습니다.
오류 로그의 예는 다음과 같습니다.
XlaRuntimeError: RESOURCE_EXHAUSTED: XLA:TPU compile permanent error. Ran out of memory in memory space hbm. Used 49.34G of 32.00G hbm. Exceeded hbm capacity by 17.34G. Total hbm usage >= 49.34G: reserved 3.12M program unknown size arguments 49.34G
JaxRuntimeError: RESOURCE_EXHAUSTED: Ran out of memory in memory space vmem while allocating on stack for %ragged_latency_optimized_all_gather_lhs_contracting_gated_matmul_kernel.18 = bf16[2048,4096]{1,0:T(8,128)(2,1)} custom-call(%get-tuple-element.18273, %get-tuple-element.18274, %get-tuple-element.18275, %get-tuple-element.18276, %get-tuple-element.18277, /*index=5*/%bitcast.8695, %get-tuple-element.19201, %get-tuple-element.19202, %get-tuple-element.19203, %get-tuple-element.19204), custom_call_target=""
상태 및 확인 실패
일반적으로 XLA에서는 상태와 CHECK 매크로 실패라는 두 가지 메커니즘으로 손상된 실행을 표시할 수 있습니다.
상태는 심각하지 않고 복구 가능한 오류를 위한 것입니다. 함수가 반환되고 호출자가 반환된 상태 객체를 명시적으로 확인하는 경로를 따라 실행이 계속된다고 가정합니다. 잘못된 사용자 입력이나 예상되는 리소스 제약 조건을 처리하는 데 유용합니다.
반면, CHECK 실패는 프로그래머의 오류나 코드가 올바른 경우 발생해서는 안 되는 불변량 위반을 다룹니다. 활성화된 CHECK의 경우 프로그램은 오류 메시지를 로깅하고 즉시 종료됩니다. 포인터를 역참조하기 전에 포인터가 null이 아닌지 확인하는 등 내부 일관성을 보장할 수 있습니다.
오류 코드
다음은 모든 오류 코드가 포함된 색인 목록입니다.