Os erros do XLA são categorizados em diferentes fontes de erros do XLA. Cada fonte tem uma lista de um contexto adicional além da mensagem de erro, que será anexada a cada erro na categoria.
🚧 Essa padronização ainda está em andamento. Por isso, nem todas as mensagens de erro têm um código anexado.
Um exemplo de registro de erros pode ser assim:
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 e falhas de CHECK
Em geral, no XLA, podemos sinalizar a execução corrompida com dois mecanismos: status e falhas de macro CHECK.
Os status são destinados a erros não fatais e recuperáveis. A premissa é que a função retorna, e a execução continua pelo caminho em que o autor da chamada verifica explicitamente o objeto Status retornado. É útil para lidar com entradas de usuário inválidas ou restrições de recursos esperadas.
Por outro lado, as falhas de CHECK abrangem erros de programação ou violações de invariantes que nunca devem acontecer se o código estiver correto. Em caso de um CHECK ativado, o programa vai registrar a mensagem de erro e terminar imediatamente. Isso pode garantir a consistência interna, como verificar se um ponteiro não é nulo antes de desreferenciá-lo.
Códigos de erro
Confira uma lista de índice com todos os códigos de erro.