Catégorie : Incompatibilité du tampon d'entrée du programme lors de l'exécution
Cette erreur se produit lorsque le runtime XLA détecte une incohérence entre la taille d'un tampon de mémoire attendue 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 Tensors 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 éléments suivants :
- Incompatibilité entre le point de contrôle et la configuration 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 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.
- Mises en page spécifiques au matériel/à la topologie : le compilateur XLA est libre de choisir différentes mises en page 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 de celle de différentes tranches de pod de la même puce (par exemple, 4x4x4 vs 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
- Assurez-vous que la configuration est cohérente 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.
- Réexportez le modèle enregistré : si vous pensez qu'il existe 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 (actuelles) que celles que vous utilisez pour l'inférence ou l'ajustement 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 si les versions matérielles et les topologies ne sont pas incompatibles si vous changez de matériel ou de topologies.