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 宏失败。
状态适用于非严重的可恢复错误。假设该函数会返回，并且执行会继续沿着调用方明确检查返回的 Status 对象的路径进行。这对于处理无效的用户输入或预期的资源限制非常有用。
另一方面，CHECK 失败涵盖了程序员的错误或不应发生的违反不变量的情况（如果代码正确）。如果激活了 CHECK，程序将记录错误消息并立即终止。它可以确保内部一致性，例如在取消引用指针之前检查该指针是否为非 null。
错误代码
以下是包含所有错误代码的索引列表。