Kategorie:Laufzeit: Puffer für Programmeingabe stimmt nicht überein
Dieser Fehler tritt auf, wenn die XLA-Laufzeit eine Diskrepanz zwischen der Größe eines Speicherpuffers, der von einem kompilierten Programm erwartet wird, und der Größe des Puffers erkennt, der tatsächlich zur Ausführungszeit bereitgestellt wird.
Beispiel für eine Fehlermeldung:
XlaRuntimeError: INVALID_ARGUMENT: Executable(jit_embedding_pipeline_step_fn) expected parameter 2482 of size 5242880 (bf16[16,1280,40]{2,1,0:T(8,128)(2,1)}) but got buffer with incompatible size 1638400 (bf16[16,1280,40]{1,2,0:T(8,128)(2,1)}): while running replica 0 and partition 0 of a replicated computation (other replicas may have failed as well).
XLA-Back-Ends:TPU
Übersicht
Die Fehlermeldung enthält sowohl die erwarteten als auch die tatsächlichen Größen sowie die Tensorformen und ‑layouts. Diese Fehler können auch dann auftreten, wenn zwei Tensoren dieselbe Form haben, ihre Größe im Arbeitsspeicher jedoch unterschiedlich ist, weil ihr physisches Layout (wie die Daten auf der Hardware angeordnet sind) unterschiedlich ist.
Diese Fehler werden hauptsächlich durch Folgendes verursacht:
- Checkpoint- und XLA-Konfigurationsabweichung: Ein Modell wird trainiert und ein Prüfpunkt wird gespeichert. Das physische Layout der Gewichte in diesem Prüfpunkt wird durch die genaue XLA-Version und -Konfiguration (z.B. XLA-Flags) zu diesem Zeitpunkt bestimmt. Später wird dieser Prüfpunkt in einer anderen Umgebung geladen, in der sich die Konfiguration geändert hat. Ein neues Flag, ein anderer Standardwert oder eine Änderung im Modell-/XLA-Code kann dazu führen, dass die Laufzeit ein anderes physisches Layout für die Gewichte erwartet. Wenn der alte Puffer aus dem Prüfpunkt an das neue kompilierte XLA-Programm übergeben wird, gibt die Laufzeit einen Fehler aus.
- Hardware-/topologiespezifische Layouts: Der XLA-Compiler kann verschiedene physische Layouts für Tensoren auswählen, um die Leistung auf unterschiedlicher Hardware zu optimieren. Ein Layout, das für v4-TPUs optimiert ist, kann sich von einem für v5-TPUs unterscheiden oder sogar für verschiedene Pod-Slices desselben Chips (z.B. 4 x 4 x 4 im Vergleich zu 4 x 8). Der Fehler tritt auf, wenn ein Modell mit einer Annahme zum Layout einer Topologie kompiliert wird, es zur Laufzeit jedoch auf einer anderen Topologie geplant wird oder wenn ein Fehler in der Layoutlogik des Compilers für eine bestimmte Hardware vorliegt.
Debugging
- Achten Sie auf eine konsistente Konfiguration zwischen dem Modelexport und den erneuten Ausführungen von Prüfpunkten:
- Vermeiden Sie die Verwendung alter Checkpoints mit neuem Code, es sei denn, Sie sind sicher, dass keine layoutbezogenen Änderungen vorgenommen wurden.
- Gespeichertes Modell noch einmal exportieren: Wenn Sie einen Checkpoint-/Konfigurationskonflikt vermuten, ist es am zuverlässigsten, das gespeicherte Modell noch einmal mit genau derselben (und aktuellen) Codebasis und Konfiguration zu exportieren, die Sie für die Inferenz oder das Fine-Tuning verwenden.
- Prüfen Sie, ob sich die Konfiguration (z.B. XLA-Flags) zwischen den beiden Läufen geändert hat.
- Hardware-/topologiespezifische Layouts:
- Prüfen Sie, ob es zu Inkompatibilitäten bei der Hardwareversion und der Topologie kommt, wenn Sie die Hardware oder die Topologie wechseln.