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=""
ステータスと CHECK の失敗
一般に、XLA では、ステータスと CHECK マクロの失敗という 2 つのメカニズムで破損した実行にフラグを設定できます。
ステータスは、致命的ではない回復可能なエラーを対象としています。この関数は戻り、呼び出し元が明示的に返された Status オブジェクトをチェックするパスに沿って実行が続行されると想定されています。これは、無効なユーザー入力や想定されるリソース制約を処理する場合に便利です。
一方、CHECK の失敗は、コードが正しければ発生しないはずのプログラマーのエラーや不変条件の違反を対象としています。CHECK が有効になっている場合、プログラムはエラー メッセージをログに記録して直ちに終了します。たとえば、ポインタを逆参照する前に、ポインタが null でないことを確認するなど、内部整合性を確保できます。
エラーコード
エラーコードの一覧は、こちらでご確認いただけます。