Transformers documentation
Kernels
Kernels
Cette page documente les utilitaires de configuration des noyaux.
kernelize
Enregistrer temporairement les wrappers de noyaux cachés afin que kernelize puisse les découvrir et les remplacer.
KernelConfig
classe transformers.KernelConfig
< source >( kernel_mapping = Noneuse_local_kernel = Falseinherit_mapping = True )
Classe de configuration du noyau. Cette classe est utilisée pour configurer le mappage du noyau pour un modèle.
Transforme un simple kernel_mapping de la forme : { “RMSNorm”: (“kernels-community/layer_norm:LlamaRMSNorm”, {“version”: 1, “trust_remote_code”: True}), … },
ou pour un chemin local :
{ “RMSNorm”: “/home/user/liger_kernels:LigerRMSNorm”, … },
en un mappage imbriqué :
{ “RMSNorm”: { “cuda”: { Mode.INFERENCE: LayerRepository( repo_id=“kernels-community/layer_norm”, layer_name=“LlamaRMSNorm”, version=1, trust_remote_code=True, ) } } }
ou pour un chemin local :
{ “RMSNorm”: { “cuda”: { Mode.INFERENCE: LocalLayerRepository( repo_path=Path(“/home/user/liger_kernels”), layer_name=“LigerRMSNorm”, ) } } }
qui est compatible avec la bibliothèque kernels.
L'appareil est déduit des paramètres du modèle s'il n'est pas fourni. Le Mode est déduit de l'état d'entraînement du modèle.
sanitize_kernel_mapping
< source >( model )
Paramètres
- model — L'instance du modèle dont les modules sont vérifiés pour les attributs kernel_layer_name enregistrés.
Lève
ValueError
ValueError— Si un layer_name n'est pas enregistré dans le modèle, si un device n'est pas pris en charge, ou si un repo_name n'est pas une chaîne « org/repo:layer_name » valide.
Valide le kernel_mapping afin de garantir que :
- Chaque layer_name de la correspondance est enregistré dans le modèle (c'est-à-dire que le modèle contient un module avec un kernel_layer_name correspondant).
- Chaque valeur de noyau est
- soit une chaîne de la forme ‘org/repo:layer_name’, soit un tuple contenant la même chaîne et un dictionnaire de la forme {“revision”/“version/trust_remote_code”: …},
- ou un dictionnaire associant les types de périphériques pris en charge à de telles valeurs, comme ci-dessus.
- Chaque clé d’appareil dans un dict est l’une des valeurs suivantes : « cuda », « rocm », « xpu », « npu », « neuron », « tpu » ou « mps ».
- Chaque clé trust remote code doit être un booléen.
- Chaque clé de révision ou de version doit exister de manière mutuellement exclusive si elle a été transmise explicitement.
- Chaque repo_name est un nom de dépôt et de couche valide au format ‘org/repo:layer_name’ (c’est-à-dire une chaîne contenant à la fois un slash et un deux-points).
- Si un chemin local est détecté, il doit être au format ‘/abs/path:layer_name’, où le chemin absolu pointe vers le dépôt du noyau, par exemple “/home/user/layer_norm”.