Błędy XLA są podzielone na różne źródła błędów XLA. Każde źródło ma listę dodatkowych informacji kontekstowych innych niż komunikat o błędzie, które będą dołączane do każdego błędu w danej kategorii.
🚧 Pamiętaj, że standaryzacja jest w toku, więc nie wszystkie komunikaty o błędach mają jeszcze dołączony kod błędu.
Przykładowy dziennik błędów może wyglądać tak:
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=""
Stany i błędy CHECK
W XLA możemy oznaczać uszkodzone wykonanie za pomocą 2 mechanizmów: stanów i błędów makra CHECK.
Stany są przeznaczone dla błędów niekrytycznych, które można naprawić. Zakładamy, że funkcja zwraca wartość, a wykonywanie jest kontynuowane w miejscu, w którym wywołujący jawnie sprawdza zwrócony obiekt stanu. Przydaje się do obsługi nieprawidłowych danych wejściowych użytkownika lub oczekiwanych ograniczeń zasobów.
Z drugiej strony błędy CHECK obejmują błędy programisty lub naruszenia niezmienników, które nie powinny nigdy wystąpić, jeśli kod jest prawidłowy. W przypadku aktywnego polecenia CHECK program zarejestruje komunikat o błędzie i natychmiast zakończy działanie. Może to zapewnić wewnętrzną spójność, np. sprawdzić, czy wskaźnik nie jest pusty przed jego dereferencją.
Kody błędów
Oto lista indeksów ze wszystkimi kodami błędów.