Exécutez Llama sans GPU ! LLM quantifié avec LLMWare et Quantized Dragon

Introduction

À mesure que les technologies LLM sont de plus en plus adoptées et que l'écosystème commence à mûrir, les organisations commencent à reconnaître les limites et les coûts de l'utilisation des technologies LLM. De nombreuses entreprises, initialement enthousiasmées par l'application des technologies LLM , ont abandonné les initiatives centralisées, poursuivant plutôt une stratégie consistant à encourager les efforts décentralisés pour intégrer des services tels que ChatGPT et Claude dans leurs flux de travail.

Il y a plusieurs raisons à ce phénomène. Le manque d'expertise LLM, les exigences MLOps et le recours à une infrastructure GPU spécialisée sont autant d'obstacles à la mise en œuvre d'initiatives d'IA à grande échelle. Parmi ceux-ci, cependant, le problème le plus épineux est la dépendance aux GPU.

Dans cet article, nous discuterons des difficultés spécifiques posées par le recours aux GPU, explorerons une solution potentielle et examinerons un exemple passionnant d'une des entreprises pionnières travaillant dans ce domaine.

Disponibilité du GPU comme limites des LLM

Les modèles les plus accessibles au public et les plus performants, tels que GPT-4, Llama 2 et Claude, reposent tous sur une infrastructure GPU hautement spécialisée. GPT-4, l’un des plus grands modèles disponibles dans le commerce, fonctionne sur un cluster de 8 GPU A100. Le modèle 70B de Llama 2, qui est beaucoup plus petit, nécessite toujours au moins un GPU A40 pour fonctionner à une vitesse raisonnable.

Ce niveau d'exigence en matière de GPU exclut pratiquement la possibilité d'exécuter ces modèles localement : un GPU A100, en supposant que vous puissiez trouver un vendeur, coûte près de 25 000 $. Une fois que vous avez obtenu les GPU, vous avez besoin de compétences spécialisées pour configurer et entretenir les serveurs. Très peu d’organisations seraient prêtes à engager une telle dépense pour expérimenter les technologies LLM.

Pour résoudre ce problème, plusieurs startups et fournisseurs de cloud ont développé des offres PaaS étendues. Certains services comme Replicate, que j'ai utilisé dans des articles et projets précédents, permettent aux utilisateurs de louer des serveurs GPU et de payer pour le temps de calcul utilisé. D'autres fournisseurs, comme OpenAI et Anthropic, proposent leurs modèles sous forme d'API par jeton, éliminant ainsi davantage les complexités infrastructurelles. Cependant, ces services nécessitent que les données soient envoyées à un réseau externe, ce qui rend leur utilisation impossible pour les organisations soucieuses de la confidentialité. De plus, bon nombre de ces services souffrent de pénuries lors des pics de demande, car l'utilisation du GPU dépasse la disponibilité, ce qui en fait des options peu fiables pour les charges de travail critiques en production.

De plus, le temps passé par les GPU, quel que soit le mode de facturation, est coûteux pour les tâches de calcul importantes : les entreprises qui possèdent et exploitent ces GPU ont besoin d'un retour sur investissement, après tout. Bien que ces coûts soient presque négligeables pour les cas d'utilisation expérimentaux, les cas d'utilisation commerciale nécessitent souvent l'intégration de contextes volumineux, des réglages précis ou des exemples à plusieurs plans. Ces coûts représentent un obstacle important à l’adoption, en particulier pour les organisations disposant de grands ensembles de données ou celles qui ne disposent pas des ressources financières des grandes entreprises américaines.

Dans un article précédent, nous avons exploré la compression des paramètres comme stratégie permettant de réduire la dépendance aux GPU. Dans l'article d'aujourd'hui, nous explorerons une autre technique passionnante appelée quantification.

Cependant, avant de nous lancer dans l’exploration, nous souhaiterions peut-être en apprendre un peu plus sur la quantification.

Quantification (lecture facultative)

Dans cette section, nous passerons brièvement en revue les bases de la quantification. Cependant, si vous recherchez simplement un moyen d'exécuter de puissants LLM localement sur votre ordinateur, n'hésitez pas à ignorer cette section pour le moment et à y revenir plus tard. LLMWare, la société dont nous allons utiliser la technologie aujourd'hui, a créé des outils étonnants qui vous permettent de démarrer avec des modèles quantifiés sans avoir à vous lancer dans les implémentations C/C++ derrière tout cela.

Qu’est-ce que la quantification ?

La quantification est une technique qui cherche à réduire les besoins de calcul et de mémoire liés à l'exécution d'un LLM en utilisant des types numériques de moindre précision. De nombreux modèles open source populaires, tels que Llama, Falcon et Alpaca, utilisent PyTorch comme framework sous-jacent. Par défaut, les modèles PyTorch utilisent des virgules flottantes de 32 bits, ce qui signifie qu'un seul paramètre occupe 32 « bits » dans la mémoire du GPU. La quantification vise à remplacer ces paramètres par des virgules flottantes de 16 bits, des entiers de 8 bits, voire des entiers de 4 bits. Une quantification réussie entraîne des améliorations spectaculaires de la vitesse de calcul et une réduction de l'utilisation de la mémoire, ce qui signifie que les grands modèles deviennent exécutables sur des GPU bas de gamme, des puces graphiques intégrées ou même des CPU. Cette idée existe depuis un certain temps - PyTorch lui-même a ajouté la prise en charge des virgules flottantes 16 bits et des compilations de modèles à mesure que la technologie mûrissait, mais les progrès ont été lents en raison des premières décisions de conception dans le framework PyTorch.

La quantification dégrade-t-elle les performances ?

À ce stade, il est naturel de se demander si cela ne dégraderait pas gravement la précision du modèle ? La réponse courte est oui, mais seulement si vous le faites avec négligence. Chaque optimisation comporte des compromis inhérents, mais grâce à certaines techniques spécialisées, les chercheurs ont réussi à obtenir des performances incroyablement stables à partir de modèles hautement quantifiés. Sans entrer dans les détails techniques extrêmes, passons en revue les grandes lignes des stratégies les plus couramment utilisées actuellement. Si vous souhaitez en savoir plus, vous pouvez en savoir plus dans un guide de HuggingFace.

Quantification calibrée

Pendant le processus de quantification, un ensemble de données d'étalonnage est exécuté dans le modèle. La valeur de chaque paramètre est enregistrée et la plage est utilisée pour déterminer comment les paramètres sont quantifiés. En supposant que l'ensemble de données d'étalonnage soit représentatif des entrées que le modèle rencontrera, cela se traduit par une précision améliorée du modèle résultant.

Prise en compte de la quantification

Alors que la quantification calibrée se produit après la formation, la formation basée sur la quantification tente d'optimiser le modèle pendant la formation. Pendant que le modèle est en formation, les activations sont soumises à une « fausse quantification », simulant les erreurs qui seront probablement introduites par le processus de quantification. Le modèle est alors capable de s’adapter aux erreurs, ce qui donne lieu à un modèle plus robuste capable de s’adapter spécifiquement aux distorsions potentielles.

Lama.cpp et GGUF

Alors que la quantification et les optimisations de PyTorch ont longtemps été bloquées par la conception du framework, deux technologies open source récentes ont surmonté ces barrières et rendu les technologies de quantification beaucoup plus accessibles au grand public. Examinons-les brièvement ci-dessous.

Lama.cpp

Llama.cpp était un projet de Georgi Gerganov visant à porter le modèle Llama en C/C++. Cela a éliminé la complexité introduite par PyTorch et l'implémentation native a permis d'implémenter directement la quantification. Par conséquent, le modèle résultant pourrait fonctionner avec une quantification entière jusqu’à 4 bits, ce qui permettrait d’exécuter des modèles Lama comportant un nombre élevé de paramètres sans GPU spécialisé.

Le projet a depuis été étendu par la communauté pour inclure une liste de modèles open source, notamment des modèles populaires comme Falcon et Mistral.

GGUF

GGUF est le format de fichier de Llama.cpp pour stocker et transférer les informations du modèle. Les modèles quantifiés sont stockés dans ce format afin qu'ils puissent être chargés et exécutés par l'utilisateur final. GGUF est le format successeur de GGML et vise à améliorer GGML en offrant plus d'extensibilité, de compatibilité ascendante et de stabilité tout en permettant un développement rapide.

Le développement d'un format de fichier universel a ouvert la porte à la communauté open source pour étendre le Llama.cpp afin d'optimiser d'autres modèles, et des innovateurs comme TheBloke et LLMWare ont travaillé au cours des derniers mois pour miniaturiser les modèles open source populaires.

Modèle de dragon quantifié de LLMWare

Dans l'exemple d'aujourd'hui, nous utiliserons des bibliothèques open source et des modèles quantifiés fournis par LLMWare, qui fournit des outils pratiques pour créer rapidement des flux de travail RAG spécialisés.

Qui est LLMWare ?

LLMWare, une société d'IA générative spécialisée dans les secteurs juridique et financier, est activement impliquée dans la communauté de la quantification. Comme je l'ai déjà écrit, leur concentration sur les secteurs soucieux de la confidentialité en fait un candidat naturel pour expérimenter et innover dans les technologies de miniaturisation.

Auparavant, j'ai écrit sur leurs modèles BLING optimisés pour RAG qui exploitent des performances incroyables sur 1 à 3 milliards de modèles de paramètres pour des tâches spécialisées telles que l'examen des contrats et l'analyse financière. Alors que la plupart des modèles open source avec un tel nombre de paramètres ont tendance à n'être utiles que pour les problèmes de jouets, LLMWare est capable de générer des performances prêtes pour la production à partir de ces modèles en les entraînant à des tâches étroitement ciblées. Ces modèles miniaturisés peuvent alors fonctionner sans GPU externe, ce qui permet une confidentialité et une évolutivité accrues.

Qu’est-ce que Dragon ?

Dragon est une collection de LLM qui peuvent être considérés comme des versions plus puissantes de leurs cousins BLING. L'intention initiale de Dragon était de former un modèle à paramètres plus élevés en utilisant les mêmes techniques de réglage fin des instructions, offrant ainsi une option aux utilisateurs qui ont besoin de plus de performances et ont accès à des GPU bas de gamme.

Le nombre de paramètres ajoutés a donné lieu à des modèles plus puissants, capables d'exploiter des fenêtres contextuelles plus grandes et de générer des sorties plus complexes, mais exigeait que l'utilisateur dispose d'un matériel plus spécialisé, tel qu'un ordinateur portable intégré à un GPU ou un conteneur de calcul cloud avec un GPU connecté. Cependant, ils représentaient toujours une amélioration par rapport aux modèles extrêmement grands, qui nécessitaient d’attendre pour accéder aux rares GPU A40 ou A100.

Dragon quantifié, le meilleur des deux mondes

Compte tenu de ce qui précède, il est facile de comprendre pourquoi la quantification a donné un coup de pouce significatif à la suite d'outils d'IA de LLMWare. Grâce à la quantification, un utilisateur peut exécuter des modèles de niveau Dragon sur le même environnement que les modèles BLING, permettant ainsi une analyse beaucoup plus puissante sur des ordinateurs courants.

Au cours du mois dernier, LLMWare a publié des versions quantifiées de plusieurs modèles Dragon. Aujourd'hui, nous allons évaluer le modèle Dragon de LLMWare construit sur Llama avec un problème RAG d'analyse juridique et le comparer avec un modèle BLING similaire. Les utilisateurs intéressés peuvent également explorer d'autres modèles - un modèle basé sur Mistral et un modèle basé sur Yi sont disponibles auprès de LLMWare au moment d'écrire ces lignes. De plus, LLMWare a facilité l'exécution d'inférences sur les modèles Llama.cpp grâce à leurs intégrations étroites avec la bibliothèque ctransformers, qui permet d'échanger de manière transparente les modèles gguf avec les modèles basés sur PyTorch.

Nous utiliserons un Macbook Air avec puce M1 pour cette expérience, ce qui signifie que nous n'utiliserons que du matériel largement disponible pour cet exercice.

Tester le dragon quantifié

N'oubliez pas que dans mon article précédent, nous avons construit une application RAG axée sur la recherche de législation. Nous avons utilisé la recherche vectorielle pour effectuer une recherche rapide dans plusieurs grandes législations, trouvé des sections pertinentes à notre question sur l'intérêt du partenariat dans la zone d'opportunité qualifiée et analysé la question via un modèle BLING. Dans l'article d'aujourd'hui, nous poserons la même question via le modèle Dragon quantifié de LLMWare et déterminerons s'il fonctionne mieux que les modèles BLING.

Afin de nous concentrer sur la comparaison de modèles et de réduire la quantité de connaissances préalables requises, nous effectuerons manuellement une grande partie de l'analyse PDF et de la recherche vectorielle. Cela a l'avantage supplémentaire de rendre le problème artificiellement plus difficile pour le modèle - la recherche d'intégration par défaut de LLMWare réduit le matériel source à environ 1 000 jetons, mais la gestion manuelle de l'analyse nous permet d'augmenter le contexte jusqu'à environ 3 000 jetons. Cela nous aidera à démontrer clairement la différence entre les modèles Dragon et BLING.

Cependant, vous devriez pouvoir vous intégrer facilement au reste de l'écosystème de LLMWare si vous souhaitez exploiter leurs outils en suivant les étapes de configuration de mon dernier article sur LLMWare. En fait, si vous remplacez simplement le nom des modèles BLING par le modèle Dragon quantifié de cet article, tout devrait fonctionner de manière transparente.

Sans plus tarder, commençons !

Commençons par importer les dépendances requises :

 import sklearn import sklearn.metrics # for cosine similarity from llmware.prompts import Prompt import time import os from openai import OpenAI from PyPDF2 import PdfReader client = OpenAI() # the library now loads the key automatically as an environment variable.

Nous pouvons maintenant charger le PDF. Dans l'exemple précédent, nous avons chargé plusieurs lois importantes, mais pour aujourd'hui, nous nous concentrerons uniquement sur la version PDF de la loi de 2017 sur les réductions d'impôts et l'emploi.

 reader = PdfReader([path to PDF of tax cuts and jobs act])

Nous pouvons maintenant générer les intégrations pour chaque page :

 embeddings = [] for pg in reader.pages: text = pg.extract_text() embeddings.append(client.embeddings.create( input=text, model="text-embedding-ada-002" ).data[0].embedding)

Générons également les intégrations pour la question que nous allons poser :

 question = 'What is a qualified opportunity zone partnership interest?' q_embed = client.embeddings.create( input=question, model="text-embedding-ada-002" ).data[0].embedding

Avec l'intégration en main, nous pouvons effectuer une recherche vectorielle. Notre espace de recherche étant petit, nous pouvons simplement le faire manuellement.

 cos_sim = [(idx, sklearn.metrics.pairwise.cosine_similarity([e], [q_embed])[0][0]) for idx, e in enumerate(embeddings)]

Nous pouvons maintenant prendre la page la plus pertinente (qui est l'index 132 ou la page 133 si vous souhaitez vérifier les résultats) :

 most_relevant = sorted(cos_sim, key=lambda x: x[1], reverse=True)[0][0]

Et ce faisant, nous sommes arrivés à l’étape la plus cruciale. Nous allons instancier un objet LLMWare Prompter avec le modèle quantifié Llama Dragon. La classe Prompter est essentielle ici car elle gère l'ingénierie des invites pour nous et garantit que notre invite est cohérente avec la structure des données d'entraînement de Dragon. La classe prompt gère également automatiquement la liaison llamacpp, vous pouvez donc utiliser le modèle Dragon quantifié exactement comme les autres modèles.

 model_name = "llmware/dragon-llama-7b-gguf" prompter = Prompt().load_model(model_name) response = prompter.prompt_main(question, context='\n\n'.join([reader.pages[132].extract_text()]), prompt_name="default_with_context", temperature=0.3)

Attendez un peu et vous devriez voir l'appel de fonction revenir. Imprimez maintenant les résultats :

 print(response['llm_response'])

Et vous devriez voir quelque chose comme ce qui suit :

 • A capital or profits interest acquired by the qualified opportunity fund after December 31, 2017, from the partnership solely in exchange for cash; •As of the time such interest was acquired, the partnership was a qualified opportunity zone business (or, in the case of a new partnership, it was being organized for purposes of being a qualified opportunity zone business); •During substantially all of the qualified opportunity fund's holding period for such interest, the partnership qualified as a qualified opportunity zone business.

C'est une très bonne réponse !

À titre de comparaison, voyons comment un modèle BLING fonctionnerait sur le même problème. L’un des problèmes auxquels nous pouvons nous attendre est que la grande taille du contexte peut « submerger » un modèle à paramètres inférieurs et conduire à une réponse moins informative. Dans mes expériences précédentes, le lama tondu 2.7b était l'un des plus performants pour ce problème, j'ai donc décidé de l'utiliser comme représentant des modèles BLING.

 model_name_2 = "llmware/bling-sheared-llama-2.7b-0.1" prompter2 = Prompt().load_model(model_name_2) response = prompter2.prompt_main(question, context='\n\n'.join([reader.pages[132].extract_text()]), prompt_name="default_with_context", temperature=0.3)

Après quelques traitements, vous devriez voir quelque chose comme ceci.

 A qualified opportunity zone partnership interest is a capital or profits interest in a domestic partnership if such interest is acquired by the qualified opportunity fund after December 31, 2017, from the partnership solely in exchange for cash.

La réponse est toujours bonne mais manque certains détails capturés par le modèle Dragon. Plus précisément, la réponse ne tient pas compte de l’exigence de période de détention et de la nouvelle analyse de rentabilisation. Cela est conforme à nos attentes concernant la difficulté des modèles à paramètres inférieurs à traiter des contextes plus larges. Les lecteurs intéressés peuvent étendre cette expérience en utilisant des modèles à paramètres encore plus faibles ou en augmentant la taille du contexte donné. Vous devriez voir l’effet devenir de plus en plus prononcé, après quoi le modèle donnera une réponse courte et tronquée.

De cette expérience, il devrait être clair que les modèles Dragon quantifiés sont capables de surpasser les modèles à paramètres inférieurs pour les cas d'utilisation prévus sans compromettre sensiblement la précision du modèle.

Et avec cela, nous avons utilisé un modèle quantifié pour résoudre un cas d'utilisation réel et avons découvert ses caractéristiques de performance au cours du processus !

Conclusion

Aujourd'hui, nous avons exploré le domaine passionnant de la quantification LLM et examiné comment des entreprises comme LLMWare profitent de ces développements pour améliorer leurs modèles de langage spécialisés. Comme je l’ai déjà expliqué, la miniaturisation représente l’une des voies les plus prometteuses vers l’adoption généralisée des technologies d’IA. En combinant spécialisation, réglage fin et quantification, les innovateurs dans le domaine de l'IA peuvent créer des modèles évolutifs et performants qui résolvent des problèmes du monde réel.

Vous pouvez trouver le framework RAG de LLMWare sur Github et leurs modèles DRAGON et BLING sur le référentiel Hugging Face de LLMWare.

À propos, je travaille sur un projet passionnant qui cherche à utiliser l’IA linguistique et la miniaturisation pour révolutionner l’éducation dans les pays en développement. Nous travaillons avec des militants et des éducateurs incroyables du monde entier et nous nous efforçons de réduire la fracture numérique mondiale. Si vous souhaitez en savoir plus sur mon projet ou simplement parler de développements passionnants dans l'espace LLM, n'hésitez pas à me contacter sur Github ou LinkedIn .