Fehlercode: E0200

Kategorie:Laufzeit: Core wurde unerwartet beendet

Dieser Fehler gibt an, dass ein TPU-Kern die Ausführung von Anweisungen vorzeitig beendet hat. Dies ist ein schwerwiegender Fehlerzustand, in dem die Hardware aufgrund eines nicht behebaren Fehlers, eines Verstoßes gegen Hardwarebeschränkungen oder einer absichtlichen Unterbrechung, die durch vom Compiler generierte Laufzeitassertions ausgelöst wird, einen Halt erzwingt.

Beispiel für eine Fehlermeldung:

INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:1:0x1d9 ...

XLA-Back-Ends:TPU

Übersicht

XLA kompiliert JAX-Programme in eine Folge von Low-Level-Assembler-Anweisungen. Zur Laufzeit führt das TPU-Gerät diese Anweisungen sequenziell aus. Der Fehler „Core Halted Unexpectedly“ (Core wurde unerwartet angehalten) tritt auf, wenn die TPU-Hardware einen nicht behebaren Zustand erreicht, der die weitere Ausführung verhindert und den Core in einen schwerwiegenden „HALTED“-Zustand zwingt.

Da dieser Fehler auf physische Hardwarefehler, Compilerfehler oder Probleme mit dem Nutzercode (insbesondere in benutzerdefinierten Kernels) zurückzuführen sein kann, müssen Sie die Log-Meldungen sorgfältig analysieren, um die genaue Ursache zu ermitteln.

Debugging

Um diesen Fehler zu beheben, müssen Sie zuerst ermitteln, welches der drei spezifischen Szenarien den unerwarteten Stopp verursacht hat. Suchen Sie in Ihren Logs nach den unten beschriebenen spezifischen Textsignaturen.

Szenario 1: Infrastrukturfehler (Hardware/Netzwerk/Strom)

Signatur:In den Logs wird explizit observed errors are: [Hardware] oder observed errors are: [Network] oder observed errors are: [Power] angegeben.

Dies deutet auf einen Fehler in der physischen Infrastruktur hin, der nicht mit Ihrer Software oder Modelllogik zusammenhängt. Der TPU-Chip, das Netzwerk, das die Chips verbindet, oder die Stromversorgung ist ausgefallen.

  • Job noch einmal versuchen:Wenn das Problem ein vorübergehender Spannungseinbruch oder ein vorübergehender Netzwerkausfall war, kann ein einfacher erneuter Versuch funktionieren.
  • Fehlerhafte Knoten identifizieren und entfernen:Wenn der Fehler bei derselben Aufgabe oder demselben Host weiterhin auftritt, ist die Hardware wahrscheinlich defekt. Verwenden Sie Ihre Clusterverwaltungstools, um den betroffenen Knoten zu „entleeren“/„abzuschirmen“ und Ihren Job auf fehlerfreien Knoten neu zu starten.

Szenario 2: Verstöße gegen Hardwarebeschränkungen

Signatur:In den Protokollen wird observed errors are: [User] angegeben.

Dies weist darauf hin, dass der XLA-Compiler eine Anweisung generiert hat, die eine unverletzliche Hardwarebeschränkung verletzt hat (z.B. eine Anweisung, die versucht, auf eine Speicheradresse außerhalb des zulässigen Bereichs im HBM- oder Scratchpad-Speicher zuzugreifen). Obwohl die Meldung „Nutzer“ lautet, wird sie selten durch Nutzercode auf hoher Ebene verursacht.

Szenario 3: Vom XLA-Compiler generierte Zusicherungsfehler

Signatur:Die Fehlermeldung enthält spezifische Details zur vom Compiler generierten Assertion, die fehlgeschlagen ist. Suchen Sie nach den folgenden Begriffen:

  • BoundsCheck, scheckne, scheckeq, schecklt, scheckge, scheckbetween

Das bedeutet, dass eine vom Compiler generierte Assertion im kompilierten Programm während der Ausführung fehlgeschlagen ist. Analysieren Sie die spezifische Fehlermeldung, um den Untertyp zu ermitteln.

Szenario 3.A: Abweichung bei der Startgruppe

Beispiel für eine Fehlermeldung:

Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:1:0x1d9 (from TensorCoreSequencer:1:0x309): scheckne: An unexpected leader shows up in the launch group with a different launch id than the current group leader.

Ursache:Dieser Fehler tritt in der Regel in TPU-Umgebungen mit mehreren Hosts auf. Dies weist darauf hin, dass die TPU-Kerne, die dasselbe Programm synchron (als Teil einer „Startgruppe“) ausführen sollen, nicht mehr synchron sind. Konkret ist ein TPU-Kern einer Synchronisierungsgruppe mit einer anderen Programm-ID als der aktuellen Gruppenleitung beigetreten. Das deutet auf inkonsistente Programme auf verschiedenen Hosts hin.

  • XLA-Flags prüfen:Alle Hosts müssen genau denselben XLA_FLAGS verwenden.
  • Auf konsistente JAX-Programme prüfen:Prüfen Sie, ob auf allen Hosts identische JAX-Programme ausgeführt werden. Docker-Images, libtpu-Versionen usw. prüfen

Szenario 3.B: Fehler bei der Bereichsprüfung

Beispiel für eine Fehlermeldung:

Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:23:0x292 (from TensorCoreSequencer:23:0xd74a): BoundsCheck 92 [deref of %s931] for %937 = dma.hbm_to_vmem [thread:$0]  /*hbm=*/%s931, /*size_in_granules=*/16384, /*vmem=*/%s935, /*dst_syncflagno=*/%s860, /*src_stride=*/512, /*dst_stride=*/128, /*steps_per_stride=*/8

Ursache:Das Programm hat versucht, auf Speicher außerhalb des zugewiesenen Bereichs zuzugreifen. Die Fehlermeldung enthält oft Details zum Speichertyp (z.B. dma.hbm_to_vmem) und zur Adressberechnung.

  • Benutzerdefinierte Kernels debuggen:Wenn Sie Pallas verwenden, prüfen Sie Ihre Indexberechnungen. Verwenden Sie pl.debug_print oder checkify, um Tensor-Indexe zu validieren.
  • Sharding prüfen:Achten Sie darauf, dass die Sharding-Anmerkungen mit den Tensorformen übereinstimmen.

Szenario 3.C: Synchronisierung von Mosaic/Pallas

Beispiel für eine Fehlermeldung:

Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:21:0xae5 (from TensorCoreSequencer:21:0x54c5): Semaphore (scratch argument 1) has a nonzero value upon exit from a Mosaic kernel. Make sure every DMA is awaited, and every semaphore signal is paired with a wait.

Ursache:Dieser Fehler bezieht sich auf Code, der vom Mosaic-Compiler (der von Pallas JAX verwendet wird) generiert wurde. Dies deutet auf ein Synchronisierungsproblem in einem benutzerdefinierten Kernel hin. TPUs verwenden Semaphoren, um Abhängigkeiten zu verwalten, z.B. um sicherzustellen, dass ein DMA abgeschlossen ist, bevor er verwendet wird. Dieser Fehler deutet darauf hin, dass auf ein Signal auf einem Semaphor nicht richtig gewartet wurde.

  • Synchronisierung prüfen:Achten Sie darauf, dass jede dma_start eine entsprechende dma_wait hat.
  • Semaphoren prüfen:Prüfen Sie, ob Semaphorsignale und Wartevorgänge streng gekoppelt sind.

Nicht kategorisierte Probleme

Wenn Ihr Fehlerlog nicht mit Szenario 1, 2 oder 3 übereinstimmt (d.h. keine „observed errors“, keine „scheck“-Tags und keine spezifischen Bounds-/Semaphore-Meldungen):