OpenAI ou DIY ? Découvrir le véritable coût de l'auto-hébergement de grands modèles de langage

Votre standard de service a été positionné comme « AIdriven » en intégrant de grands modèles de langage. La page d'accueil de votre site Web présente fièrement l'impact révolutionnaire de vos services basés sur l'IA à travers des démos interactives et des études de cas. C’est également la première marque que votre entreprise laisse dans le domaine mondial de la GenAI.

Votre base d'utilisateurs, petite mais fidèle, bénéficie d'une expérience client améliorée et vous pouvez voir un potentiel de croissance future. Cependant, alors que le mois entre dans sa troisième semaine, vous recevez un e-mail d'OpenAI qui vous surprend :

Il y a à peine une semaine, vous parliez à des clients, évaluiez l'adéquation du produit au marché (PMF), et maintenant, des milliers d'utilisateurs affluent vers votre site Web. (tout peut devenir viral sur les réseaux sociaux de nos jours) et faire planter votre service alimenté par l'IA.

En conséquence, votre service autrefois fiable frustre non seulement les utilisateurs existants, mais affecte également les nouveaux utilisateurs.

Une solution rapide et évidente consiste à rétablir le service immédiatement en augmentant les limites d'utilisation.

Cependant, cette solution temporaire a entraîné un sentiment de malaise. Vous ne pouvez pas vous empêcher d’avoir l’impression d’être enfermé dans une dépendance à l’égard d’un seul fournisseur, avec un contrôle limité sur votre propre IA et ses coûts associés.

« Dois-je le faire moi-même ? » vous demandez-vous.

Vous savez déjà que les grands modèles de langage (LLM) open source sont devenus une réalité. Sur des plateformes comme Hugging Face, des milliers de modèles sont disponibles pour une utilisation immédiate, ce qui offre la possibilité de traiter le langage naturel.

Cependant, les LLM les plus puissants que vous rencontrerez ont des milliards de paramètres, pèsent des centaines de gigaoctets et nécessitent des efforts importants pour évoluer. Dans un système temps réel nécessitant une faible latence, vous ne pouvez pas simplement les connecter à votre application comme vous le faites avec les modèles traditionnels.

Même si vous avez confiance dans la capacité de votre équipe à construire l'infrastructure nécessaire, la véritable préoccupation concerne les implications financières de cette transformation, notamment :

• Coût de mise au point
• Coût d'hébergement
• Coût de service

Donc, une question majeure. La question est : devriez-vous augmenter la limite d'utilisation, ou devriez-vous emprunter la voie auto-hébergée, autrement connue sous le nom de « propre » ?

Faites quelques calculs avec Llama 2

Tout d'abord, don ? ne te précipite pas. C'est une décision importante.

Si vous consultez votre ingénieur en machine learning (ML), il vous dira probablement que Lama 2 est un LLM open source et semble être un bon choix car sur la plupart des tâches, il effectue la même chose que le GPT que vous utilisez actuellement -3 est tout aussi bien.

Vous constaterez également que le modèle est disponible en trois tailles - 7 milliards, 1,3 milliard et 700 millions de paramètres - et vous décidez d'utiliser le plus grand modèle à 7 milliards de paramètres pour rester compétitif avec le modèle OpenAI que vous utilisez actuellement.

LLaMA 2 utilise bfloat16 pour l'entraînement, donc chaque paramètre consomme 2 octets. Cela signifie que la taille du modèle sera de 140 Go.

Si vous pensez que ce modèle demande beaucoup d’ajustements, ne vous inquiétez pas. Avec LoRA, vous n'avez pas besoin d'affiner l'ensemble du modèle avant le déploiement.

En fait, vous n'aurez peut-être besoin d'affiner qu'environ 0,1 % du total des paramètres, soit 70 Mo, ce qui consomme 0,14 Go en représentation bfloat16.

Impressionnant, n'est-ce pas ?

Pour gérer la surcharge de mémoire lors du réglage fin (par exemple, rétropropagation, stockage des activations, stockage des ensembles de données), il est préférable de conserver environ 5 fois l'espace mémoire consommé par les paramètres pouvant être entraînés.

Décomposons cela en détail :

Les poids du modèle LLaMA 2 70B sont fixes lors de l'utilisation de LoRA, cela n'entraîne donc pas de surcharge de mémoire → Mémoire requise = 140 Go.

Cependant, afin d'ajuster la couche LoRA, nous devons maintenir 0,14 Go * (5x) = 0,7 Go.

Cela entraîne un besoin total de mémoire d'environ 141 Go lors du réglage fin.

En supposant que vous ne disposez pas actuellement d’infrastructure de formation, nous supposons que vous préférez utiliser AWS. Selon la tarification à la demande d'AWS EC2, le coût de calcul est d'environ 2,80 $ par heure, donc le coût du réglage fin est d'environ 67 $ par jour, ce qui ne représente pas une dépense énorme car le réglage fin ne dure pas plusieurs jours.

L'intelligence artificielle est à l'opposé d'un restaurant : le coût principal est le service plutôt que la préparation

Lors du déploiement, vous devez conserver deux poids en mémoire :

• Poids de modèle, consommant 140 Go de mémoire.
• LoRA affine les poids et consomme 0,14 Go de mémoire.

Le total est de 140,14 Go.

Bien sûr, vous pouvez annuler le calcul du gradient, mais il est toujours recommandé de conserver environ 1,5 fois la mémoire – environ 210 Go – pour tenir compte de toute surcharge inattendue.

Encore une fois, sur la base de la tarification à la demande AWS EC2, le calcul GPU coûte environ 3,70 $ par heure, soit environ 90 $ par jour pour conserver le modèle dans la mémoire de production et répondre aux demandes entrantes.

Cela équivaut à environ 2 700 $ par mois.

Une autre chose à considérer est que des échecs inattendus se produisent tout le temps. Si vous ne disposez pas d'un mécanisme de sauvegarde, vos utilisateurs cesseront de recevoir des prédictions de modèle. Si vous souhaitez éviter que cela ne se produise, vous devez conserver un autre modèle redondant au cas où la première demande de modèle échouerait.

Cela porterait donc votre coût à 180 $ par jour ou 5 400 $ par mois. Vous êtes presque proche du coût actuel d’utilisation d’OpenAI.

À quel moment les coûts de l'OpenAI et des modèles open source sont-ils liés ?

Si vous continuez à utiliser OpenAI, voici le nombre de mots que vous pouvez traiter par jour pour correspondre aux coûts de réglage et de service ci-dessus pour l'utilisation de LLaMA 2. .

Selon les tarifs d'OpenAI, le coût du réglage fin de GPT 3.5 Turbo est de 0,0080 $ pour 1 000 jetons.

En supposant que la plupart des mots ont deux jetons, pour correspondre au coût de réglage fin du modèle open source LLaMA 2 70B (67 $ par jour), vous devrez alimenter le modèle OpenAI avec environ 4,15 millions de mots.

En général, le nombre moyen de mots sur un papier A4 est de 300, ce qui signifie que nous pouvons alimenter le modèle avec environ 14 000 pages de données pour correspondre au coût de réglage fin de l'open source, ce qui est un nombre énorme.

Vous ne disposez peut-être pas de beaucoup de données de réglage fin, donc le coût du réglage fin avec OpenAI est toujours inférieur.

Un autre point qui peut paraître évident est que ce coût de mise au point n'est pas lié au temps de formation, mais à la quantité de données sur lesquelles le modèle est affiné. Ce n'est pas le cas lors du réglage fin des modèles open source, car le coût dépendra de la quantité de données et de la durée d'utilisation des ressources informatiques AWS.

En ce qui concerne le coût du service, selon la page de tarification d'OpenAI, un GPT 3.5 Turbo affiné coûte 0,003 $ pour 1 000 jetons pour l'entrée et 0,006 $ pour la sortie pour 1 000 jetons.

Nous supposons une moyenne de 0,004 $ pour 1 000 jetons. Pour atteindre le coût de 180 $ par jour, nous devons traiter environ 22,2 millions de mots par jour via l'API.

Cela équivaut à plus de 74 000 pages de données, avec 300 mots par page.

Cependant, l'avantage est que vous n'avez pas besoin de vous assurer que le modèle fonctionne 24h/24 et 7j/7, car OpenAI propose une tarification à l'utilisation.

Si votre modèle n’est jamais utilisé, vous n’avez rien à payer.

Résumé : Quand est-il vraiment judicieux de posséder une entreprise ?

Au début, passer à une IA auto-hébergée peut sembler tentant. Mais méfiez-vous des coûts cachés et des maux de tête qui en découlent.

À l'exception des nuits blanches occasionnelles où vous vous demandez pourquoi votre service basé sur l'IA est en panne, presque toutes les difficultés liées à la gestion des LLM dans les systèmes de production disparaissent si vous faites appel à un fournisseur tiers.

Surtout lorsque votre service ne repose pas principalement sur « l'IA », mais sur quelque chose d'autre qui repose sur l'IA.

Pour les grandes entreprises, le coût de possession annuel de 65 000 $ est peut-être une goutte d'eau dans l'océan, mais pour la plupart des entreprises, c'est un chiffre qui ne peut être ignoré.

De plus, il ne faut pas oublier les autres coûts supplémentaires tels que le talent et la maintenance, qui peuvent facilement augmenter le coût total à plus de 200 000 $ à 250 000 $ par an.

Bien sûr, avoir un modèle dès le départ a ses avantages, comme garder le contrôle sur vos données et votre utilisation.

Cependant, pour rendre l'auto-hébergement possible, vous aurez besoin d'un volume de demandes d'utilisateurs bien supérieur à la norme d'environ 22,2 millions de mots par jour, et vous devrez disposer des ressources nécessaires pour gérer à la fois les talents et la logistique.

Pour la plupart des cas d'utilisation, il n'est peut-être pas financièrement rentable d'avoir un modèle au lieu d'utiliser une API.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!