Importation de modèles affinés

Préparez un modèle que vous avez affiné en dehors du service d'intelligence artificielle générative pour l'importation, puis hébergez-le dans une grappe dédiée à l'IA.

Vous pouvez affiner un modèle de base compatible en dehors du service et importer le modèle résultant à partir d'un seau de stockage d'objets ou d'une face Hugging. L'importation nécessite un artefact de modèle complet qui répond aux exigences de compatibilité de son modèle de base.

OCI Generative AI n'ajuste pas les modèles importés avec précision. Pour l'entraînement des modèles préentraînés pris en charge par le service dans le service, voir Ajuster les modèles de base dans l'intelligence artificielle générative.

Vérifier la compatibilité avant le réglage fin

Commencez avec un modèle répertorié dans Modèles compatibles pour l'importation. Consultez sa page famille de modèles pour connaître les exigences et le matériel d'hébergement compatible. Conservez une copie de la configuration du modèle de base et enregistrez l'ID modèle, la révision du référentiel et les versions de bibliothèque d'entraînement et d'exportation.

Conservez une architecture compatible avec le modèle de base pris en charge. Les mises à jour LoRA standard, lorsqu'elles sont fusionnées dans les matrices de poids d'origine, conservent leurs dimensions. D'autres modifications, telles que l'ajout de couches ou le redimensionnement du vocabulaire, nécessitent des vérifications de compatibilité distinctes.
Répondez aux exigences de version des transformateurs du modèle de base. Voir Présentation des métadonnées de configuration.
Conservez le nombre total de paramètres à ±10 % du modèle de base d'origine, comme indiqué dans le guide modèle-famille. Il s'agit du nombre total de paramètres de modèle, et pas seulement du nombre de paramètres LoRA entraînables.
Pour le réglage de précision LoRA, fusionnez un adaptateur dans le modèle de base avant le déploiement. Chaque modèle affiné importé peut contenir les pondérations fusionnées d'un seul adaptateur LoRA.

Un modèle qui se charge avec succès dans votre environnement d'entraînement doit encore réussir la validation de l'importation. Vérifiez les fichiers exportés finaux, y compris leur configuration, leur type de données de poids et leur tokenizer.

Comprendre les métadonnées de configuration

Hugging Face Transformers est la bibliothèque utilisée pour charger et enregistrer de nombreux modèles Hugging Face. Le champ transformers_version dans config.json enregistre la version de bibliothèque utilisée lors de la sérialisation de la configuration. L'enregistrement avec une autre version de bibliothèque peut modifier ce champ même si l'architecture du modèle n'est pas modifiée.

Les pages model-family requièrent que le modèle affiné utilise la même version Transformers que le modèle de base pris en charge. Comparez les versions enregistrées avant l'importation. S'ils diffèrent, vérifiez l'environnement d'exportation et confirmez la compatibilité avec Oracle Support avant de vous fier à une exportation à partir d'une autre version.

Vérifications de configuration avant l'importation
Champ ou paramètre	Que vérifier
`architectures` et `model_type`	Identifiez la classe de modèle et la famille prévues et acceptez les pondérations exportées.
`transformers_version`	Comparer avec la configuration de base. Ces métadonnées de bibliothèque sont distinctes de l'architecture et de l'étiquette de version que vous affectez à un modèle importé dans la console.
`torch_dtype` ou `dtype`	Vérifiez la précision déclarée par l'exportateur et les types de données des tenseurs stockés. La modification d'une valeur JSON ne convertit pas les pondérations.
Nombre de couches, tailles cachées, paramètres d'attention et taille de vocabulaire	Vérifiez que la configuration décrit les tenseurs et le tokenizer enregistrés. Conservez les paramètres d'architecture inchangés pour une exportation LoRA qui ne met à jour que les matrices de pondération initiales.
`quantization_config`, lorsqu'il est présent	Vérifiez qu'il décrit l'exportation réelle et que la variante de modèle résultante est compatible. La suppression des métadonnées de quantification ne convertit pas un point de reprise quantifié.

Important

Assurez la cohérence de la configuration avec le modèle. Ne modifiez pas une chaîne de version uniquement pour réussir la validation ou remplacer la configuration entière sans la vérifier par rapport aux poids exportés et à l'algorithme de jeton.

Fusionner les pondérations LoRA et vérifier la précision de l'exportation

Un point de reprise de l'adaptateur LoRA contient les paramètres de l'adaptateur et dépend du modèle de base. Les fichiers tels que adapter_model.safetensors et adapter_config.json seuls ne sont pas un modèle complet pour ce flux de travail d'importation.

Chargez la même révision de modèle de base que celle utilisée pour l'entraînement et l'adaptateur prévu.
Fusionnez l'adaptateur dans le modèle de base. Avec Hugging Face PEFT, utilisez merge_and_unload() pour une configuration LoRA prise en charge. Voir Fusionner les pondérations.
Vérifiez le type de données du modèle fusionné avant d'enregistrer. Utilisez la précision validée du modèle de base comme point de départ. La formation ou la fusion peut produire des pondérations dans un type de données différent.
Enregistrez le modèle complet et son tokenizer dans un nouveau répertoire d'exportation. Conservez le modèle de base et l'adaptateur d'origine afin de pouvoir répéter l'exportation.
Examinez la configuration enregistrée et les types de données du tenseur, puis rechargez l'exportation et exécutez les invites représentatives. Vérifiez les métadonnées du tenseur enregistrées avant toute conversion au moment du chargement qui pourrait masquer le type de données stocké initial.

Par exemple, la configuration de base Qwen/Qwen3-1.7B déclare torch_dtype comme bfloat16 (BF16). Si votre exportation fusionnée contient des pondérations float32 (FP32), convertissez les tenseurs à virgule flottante réels en BF16 et enregistrez une nouvelle exportation pour ce modèle de base. La modification de torch_dtype seulement laisse les pondérations stockées inchangées.

BF16 dans cet exemple est propre au modèle Qwen sélectionné. Vérifiez le modèle de base et ses exigences avant de choisir la précision d'un autre modèle. Un point de contrôle de formation quantifié nécessite également une procédure d'exportation appropriée; toutes les configurations PEFT ou de quantification ne prennent pas en charge la fusion.

Préparer le répertoire des artefacts de modèle

Emballez une exportation complète au format Hugging Face. Le répertoire sélectionné lors de l'importation doit contenir config.json et les fichiers nécessaires pour charger le modèle. Selon le modèle, il peut s'agir des éléments suivants :

Pondérations de modèle complètes, telles que model.safetensors, ou toutes les partitions de poids et leur index, tels que model.safetensors.index.json.
Fichiers Tokenizer, configuration Tokenizer, définitions de jeton spécial et modèle de clavardage utilisé pour le modèle, le cas échéant.
Configuration de génération et tous les fichiers de processeur requis par le modèle.

Assurez-vous que chaque partition référencée par un index est présente. Utilisez le jetoniseur et le modèle de clavardage qui correspondent au modèle exporté. Pour les modèles de clavardage, consultez les directives relatives au modèle de clavardage Face Hugging.

Pour une importation du service de stockage d'objets, chargez l'exportation complète dans son propre répertoire d'artefacts de modèle. Pour une importation Hugging Face, rendez l'exportation complète disponible dans le référentiel de modèles. Conservez différentes exportations dans des répertoires distincts afin que les fichiers de configuration et de pondération de différentes exécutions ne soient pas mélangés.

Importer et héberger le modèle affiné

Vérifiez les préalables sources dans Gestion des modèles importés et les autorisations de modèle importées requises.
Importez l'exportation préparée à partir d'un seau de stockage d'objets ou à partir du visage Hugging.
Vérifiez le statut du modèle importé et résolvez tout échec d'importation avant de le déployer.
Créer une grappe d'IA dédiée à l'hébergement pour le modèle importé. Sélectionnez une forme d'unité matérielle compatible disponible dans la région cible. Voir Formes d'unité de matériel par région.
Créez un point d'extrémité, puis testez le modèle avec des demandes représentatives avant de l'utiliser en production.

Enregistrez la révision d'exportation et les résultats d'évaluation en même temps que l'OCID du modèle importé. Utilisez un nom descriptif et une version pour distinguer les exportations réglées avec précision.

Dépanner une erreur de validation d'architecture

Si la création du modèle échoue avec le message suivant, vérifiez l'exportation complète :

The imported model architecture is not yet validated for serving.

Le message n'identifie pas la configuration ou la différence d'artefact qui nécessite une attention particulière. Une valeur architectures inchangée à elle seule n'établit pas que l'exportation répond à toutes les exigences d'importation.

Vérifiez que le modèle de base initial est répertorié comme compatible et que le répertoire d'artefacts sélectionné contient l'exportation voulue.
Comparez les fichiers config.json initiaux et exportés à l'aide des vérifications dans Présentation des métadonnées de configuration. Identifier les différences introduites lors de l'enregistrement ou de la fusion.
Examinez les types de données réels des tenseurs stockés. Pour un modèle de base BF16, vérifiez si l'exportation contient involontairement des pondérations FP32.
Vérifiez que l'exportation inclut les pondérations fusionnées du modèle de base, toutes les partitions référencées et le tokenizer correspondant. Rechargez et testez l'exportation complète localement.
Après avoir corrigé l'exportation, chargez-la dans un répertoire d'artefacts distinct et soumettez une nouvelle importation. En cas d'échec de la validation, communiquez avec Oracle Support.

Inclure l'erreur exacte, l'ID demande OPC, l'heure et le fuseau horaire de l'échec, la région, l'OCID du modèle importé si disponible, l'ID et la révision du modèle de base, les différences de configuration, les types de données de tenseur observés et les versions de bibliothèque d'entraînement, de fusion et d'exportation. Ces informations permettent de distinguer un problème d'artefact d'un problème de validation de service.

Planifier les données de formation et l'évaluation

Pour le réglage fin externe, suivez le format du jeu de données et les exigences d'entraînement du modèle et des outils sélectionnés. Les exigences du jeu de données pour la création d'un modèle personnalisé dans l'IA générative décrivent ce flux de travail distinct.

Utilisez des exemples précis et représentatifs pour les formats de tâche, de langue et de réponse que le modèle doit traiter. Vérifiez les étiquettes et supprimez les exemples en double ou en conflit.
Séparer les données d'entraînement, de validation et de test. Conservez des exemples connexes lors du fractionnement des données pour réduire la fuite d'informations.
Comparez le modèle de base et le modèle affiné sur les mêmes exemples retenus. Mesurer la qualité des tâches et vérifier les régressions dans les réponses générales.
Répétez les vérifications de représentant après la fusion, la conversion de type de données et le déploiement de point d'extrémité. Une importation réussie confirme que l'importation est terminée; évaluez les réponses du modèle pour le cas d'utilisation prévu.

Si vous voulez vous entraîner sur OCI, consultez Ajustement avec les actions rapides du service d'intelligence artificielle pour le service de science des données pour OCI pour connaître ses modèles et préalables pris en charge. Un modèle entraîné dans un autre service doit toujours répondre aux exigences d'importation de l'IA générative.

Documentation sur Oracle Cloud Infrastructure