Catégorie : Exécution : décalage du tampon d'entrée du programme
Cette erreur se produit lorsque le runtime XLA détecte une incompatibilité entre la taille d'un tampon de mémoire attendu par un programme compilé et la taille du tampon réellement fourni au moment de l'exécution.
Exemple de message d'erreur :
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).
Backends XLA : TPU
Présentation
Le message d'erreur indique les tailles attendues et réelles, ainsi que les formes et les mises en page des Tensors. Notez que ces erreurs peuvent se produire même si deux tenseurs ont la même forme, mais que leur taille en mémoire peut être différente si leur disposition physique (la façon dont les données sont mosaïquées et organisées sur le matériel) est différente.
Ces erreurs sont principalement dues aux raisons suivantes :
- Incompatibilité entre la configuration du point de contrôle et celle de XLA : un modèle est entraîné et un point de contrôle est enregistré. La disposition physique des poids dans ce point de contrôle est déterminée par la version et la configuration exactes de XLA (par exemple, les indicateurs XLA) à ce moment-là. Ce point de contrôle est ensuite chargé dans un environnement différent où la configuration a changé. Un nouvel indicateur, une valeur par défaut différente ou une modification du code du modèle/XLA peuvent entraîner l'attente d'une disposition physique différente pour les poids par le runtime. Lorsque l'ancien tampon du point de contrôle est transmis au nouveau programme XLA compilé, le runtime génère une erreur.
- Dispositions spécifiques au matériel/à la topologie : le compilateur XLA est libre de choisir différentes dispositions physiques pour les Tensors afin d'optimiser les performances sur différents matériels. Une mise en page optimale pour un TPU v4 peut être différente de celle d'un TPU v5, ou même pour différentes tranches de pods de la même puce (par exemple, 4x4x4 par rapport à 4x8). Cette erreur se produit lorsqu'un modèle est compilé avec une hypothèse concernant la mise en page d'une topologie, mais qu'il est planifié sur une autre topologie au moment de l'exécution, ou lorsqu'il existe un bug dans la logique de mise en page du compilateur pour un matériel spécifique.
Débogage
- Assurer la cohérence de la configuration entre l'exportation du modèle et les réexécutions à partir des points de contrôle
- Évitez d'utiliser d'anciens points de contrôle avec un nouveau code, sauf si vous êtes certain qu'aucune modification affectant la mise en page n'a été apportée.
- Si vous soupçonnez une incompatibilité entre le point de contrôle et la configuration, la solution la plus fiable consiste à réexporter le modèle enregistré en utilisant exactement la même base de code et la même configuration que celles que vous utilisez pour l'inférence ou le réglage fin.
- Vérifiez si des modifications de configuration (par exemple, des indicateurs XLA) ont été apportées entre les deux exécutions.
- Mises en page spécifiques au matériel/à la topologie
- Vérifiez s'il existe des incompatibilités de version ou de topologie matérielles si vous changez de matériel ou de topologie.