XLA-Fehler werden in verschiedene XLA-Fehlerquellen kategorisiert. Jede Quelle enthält eine Liste mit zusätzlichem Kontext, der neben der Fehlermeldung an jeden Fehler in der Kategorie angehängt wird.
🚧 Die Standardisierung ist noch in Arbeit. Daher ist noch nicht allen Fehlermeldungen ein Fehlercode angehängt.
Ein Beispiel für ein Fehlerlog:
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=""
Status und CHECK-Fehler
Im Allgemeinen können wir in XLA die beschädigte Ausführung mit zwei Mechanismen kennzeichnen: Status und CHECK-Makrofehler.
Status sind für nicht schwerwiegende, behebbare Fehler vorgesehen. Es wird davon ausgegangen, dass die Funktion zurückkehrt und die Ausführung auf dem Pfad fortgesetzt wird, auf dem der Aufrufer das zurückgegebene Status-Objekt explizit prüft. Das ist nützlich, um ungültige Nutzereingaben oder erwartete Ressourcenbeschränkungen zu verarbeiten.
CHECK-Fehler hingegen decken Programmierfehler oder Verletzungen von Invarianten ab, die bei korrektem Code niemals auftreten sollten. Im Falle eines aktivierten CHECK wird die Fehlermeldung protokolliert und das Programm sofort beendet. So kann beispielsweise die interne Konsistenz sichergestellt werden, indem geprüft wird, ob ein Zeiger ungleich null ist, bevor er dereferenziert wird.