LoRA par rapport à QLoRA : quels sont les changements et quels éléments restent ?

LoRA et QLoRA sont des approches de finetuning, mais elles répondent à des contraintes de ressources différentes. LoRA entraîne de petits modules d'adaptation en parallèle d'un modèle de base ; QLoRA combine cette approche d'adaptation avec un modèle de base quantifié pendant le finetuning afin de réduire la charge mémoire.

Un modèle de base à pleine précision et un modèle de base entraîné en quantification connectés à de petites mises à jour d'adaptateur LoRA.
LoRA modifie ce qui est entraîné ; QLoRA modifie aussi la représentation de la base pendant le finetuning.

Ce que signifie LoRA en pratique

Low-Rank Adaptation (LoRA) ajoute des mises à jour à faible rang entraînables au lieu de modifier chaque paramètre du modèle de base. L'adaptateur obtenu est généralement bien plus petit qu'un modèle entièrement affiné, mais il n'a de sens qu'en relation avec le modèle de base, l'architecture et le processus de chargement attendus.

Pour la conservation, cette relation est le fait principal. Un fichier nommé « style-v7 » ne précise pas à un futur vous quelle base il utilise, quel projet l'a produit ou quelle version vous souhaitiez conserver. Considérez l'adaptateur et le contexte dont vous avez besoin pour le récupérer comme une famille délibérée.

Ce que QLoRA apporte

QLoRA utilise un modèle de base quantifié lors de l'entraînement des adaptateurs LoRA. Son objectif principal est de rendre l'entraînement des grands modèles plus efficace en termes de mémoire. Cela ne signifie pas que tous les artefacts produits par l'exécution sont interchangeables avec la configuration non quantifiée, ni qu'il n'est plus nécessaire de conserver le modèle de base, la configuration et les sorties terminées que vous souhaitez préserver.

N'utilisez pas « QLoRA » comme étiquette de stockage. Le terme décrit une méthode de finetuning et des contraintes liées au modèle de base. Il ne promet pas qu'un archivage rendra tous les fichiers produits plus petits et ne remplace pas un test de récupération exact.

Qu'est-ce que vous devez conserver après une exécution terminée ?

Conservez assez de contexte pour identifier sans ambiguïté l'artefact terminé : l'adaptateur publié, l'identité ou la révision du modèle de base visé, la configuration et les éléments d'évaluation nécessaires au projet, ainsi qu'un nom clair de projet et de version. Conservez séparément les éléments de gestion des exécutions si votre pile d'entraînement en a besoin pour reprendre le travail.

Une fois une version terminée, un archivage local peut préserver les fichiers associés comme une famille et permettre leur récupération exacte. N'archivez pas une exécution en cours uniquement pour libérer rapidement de l'espace : terminez-la, conservez ce dont elle a besoin, puis appliquez un workflow de stockage à l'ensemble d'artefacts final.

Où s'inscrit Tensor Archive

Tensor Archive est un outil de stockage et de récupération local, et non un framework de mise au point. Après la limite de complétion, vous pouvez analyser une famille liée, l'archiver, vérifier la possibilité de récupération et restaurer une copie séparée avant de supprimer manuellement une source redondante. Cela est particulièrement utile lorsque l'on conserve ensemble une base et ses adaptateurs terminés ou des versions très proches.

Une règle pratique à retenir

Si la méthode elle-même ne vous est pas familière, commencez par découvrir ce que signifie LoRA en AI. Employez les termes LoRA ou QLoRA pour décrire la manière dont l'objet a été produit, puis consultez checkpoint ou LoRA pour identifier les dépendances des fichiers terminés. Pour la séquence de stockage, lisez le guide d'archivage des checkpoints terminés.

Références

Gardez le modèle. Videz le disque de travail. Télécharger gratuitement ↓