Journal LLM auto-hébergés ou non : mon expérience

26
29
mai
2024

Sommaire

Introduction

En tant que grand utilisateur des LLM (Large Language Models), je trouve que ce sont d'excellents outils pour diverses tâches comme l'analyse de logs, l'aide à la programmation de scripts, etc. Cependant, une question cruciale se pose rapidement : faut-il les auto-héberger ou les utiliser via des services en ligne ? Dans cet article, je partage mon expérience sur ce sujet.

Catégories de LLM

Je classe les LLM en trois catégories principales :

1. Les petits modèles

Ces modèles peuvent tourner localement sur votre machine, lentement sur le CPU ou plus rapidement avec un GPU d'au moins 8 Go de mémoire (NVIDIA, AMD ou Mac). Ils fonctionnent en local, sans connexion internet, ce qui est idéal pour la confidentialité. Cependant, ils sont vite limités et conviennent mieux pour des tâches spécifiques comme le RAG (Retrieval Augmented Generation) ou s'ils ont été fine-tunés dans un domaine précis.

Exemples : LLaMA 3 8b, Mistral 7b, phi3 3b, et tous les modèles en dessous de 10 à 15 milliards de paramètres.

2. Les modèles moyens

Ces modèles peuvent également tourner localement si vous avez un bon GPU avec suffisamment de mémoire (32 Go, voire 16 Go pour certains modèles quantifiés sur 2 bits). Ils sont plus intelligents que les petits modèles, mais moins que les grands. Dans mon expérience, ils suffisent dans 95% des cas pour l'aide au codage et 100% pour la traduction ou la correction de texte.

Exemples : LLaMA 3 70b, Mistral 8x7b (celui que j'utilise au quotidien), Command-R (35b), et tous les modèles jusqu'à 100 milliards de paramètres.

3. Les grands modèles

Pour faire tourner ces modèles localement, il faut beaucoup d'argent. Ce sont généralement des modèles non ouverts ou des modèles ouverts de très grande taille.

Exemples : le futur LLaMA 3 400b, Mistral 8x22b, QWen 110b, Command-R-Plus, DBRX.

Auto-hébergement ou services en ligne

L'auto-hébergement peut se faire de manière complète (frontend et backend) ou hybride (frontend auto-hébergé et inférence sur un endpoint distant). Pour le frontend, j'utilise deux containers Docker chez moi : Chat UI de Hugging Face et Open Webui.

Pour le backend, on peut soit auto-héberger l'inférence avec des outils comme OLLaMa ou LLaMA.cpp, soit utiliser un endpoint externe via une API (OpenAI, Mistral AI, Together AI, Hugging Face, Groq, etc.). Ces endpoints offrent généralement des bibliothèques pour Python ou JavaScript, compatibles avec l'API OpenAI.

Bien que l'inférence sur un endpoint ne soit pas idéale pour la confidentialité, c'est tout de même mieux que rien, car on peut changer d'endpoint pour brouiller les pistes.

Ma configuration

J'ai acheté d'occasion un ordinateur Dell Precision 5820 avec 32 Go de RAM, un CPU Xeon W-2125, une alimentation de 900W et deux cartes NVIDIA Quadro P5000 de 16 Go de RAM chacune, pour un total de 646 CHF.

J'ai installé Ubuntu Server 22.4 avec Docker et les pilotes NVIDIA. Ma machine dispose donc de 32 Go de RAM GPU utilisables pour l'inférence. J'utilise OLLaMa, réparti sur les deux cartes, et Mistral 8x7b quantifié sur 4 bits (2 bits sur une seule carte, mais l'inférence est deux fois plus lente). En inférence, je fais environ 24 tokens/seconde. Le chargement initial du modèle (24 Go) prend un peu de temps. J'ai également essayé LLaMA 3 70b quantifié sur 2 bits, mais c'est très lent (3 tokens/seconde).

Consommation électrique

Au repos, mon infrastructure (1 serveur Proxmox, 1 serveur de sauvegarde Proxmox, 1 Synology DS218+, la machine d'inférence, le routeur, le switch et l'onduleur) consomme environ 260W.

En inférence, la consommation monte à environ 420W, soit une puissance supplémentaire de 200W. Sur 24h, cela représente une consommation de 6,19 kWh, soit un coût de 1,61 CHF/jour.

Pour réduire cette consommation et les coûts, plusieurs options sont possibles :

  1. Installer des panneaux solaires (trop cher pour moi actuellement, mais je vais brancher un panneau solaire de 600W maximum sur une prise, comme autorisé en Suisse).
  2. Arrêter la machine d'inférence la nuit.
  3. Faire l'inférence sur des endpoints (moins idéal pour la confidentialité).

Inférence sur des endpoints

Hugging Face permet de faire de l'inférence sur tous les modèles de moins de 10 Go de RAM et sur quelques gros modèles (LLaMA 3 70b, Mistral 8x22b, etc.). Il est possible de cloner Chat UI qui tourne sur Hugging Face et de le faire tourner dans un espace privé. Attention, cela peut parfois être lent le soir, même avec un abonnement à 9€/mois.

Together AI est une société américaine qui offre un crédit de 25$ à l'ouverture d'un compte. Les prix sont les suivants :

  • Mistral 8x7b : 0,60$/million de tokens
  • LLaMA 3 70b : 0,90$/million de tokens
  • Mistral 8x22b : 1,20$/million de tokens

Mistral AI est une société française qui propose des modèles Mistral, avec un paiement au million de tokens selon le poids du modèle.

Groq permet une inférence très rapide (300 à 500 tokens/seconde pour LLaMA 3 ou Mistral 8x7b). Lors de ma dernière utilisation, c'était gratuit car en phase de bêta.

Les modèles propriétaires comme ChatGPT sont généralement trop chers, bien qu'ils puissent résoudre certains problèmes que mes modèles ne parviennent pas à résoudre (et vice-versa).

Conclusion

En résumé, l'auto-hébergement des LLM offre un meilleur contrôle sur la confidentialité, mais nécessite des investissements en matériel et en consommation électrique. Les services en ligne sont une alternative intéressante, mais avec des compromis en termes de confidentialité et de coûts. Le choix dépendra de vos besoins spécifiques et de votre budget.

  • # Consommation électrique au repos

    Posté par  . Évalué à 4 (+2/-0).

    Au repos, une consommation de 260W me semble juste énorme. Sais-tu d'où vient ce gâchis d'énergie ?

    • [^] # Re: Consommation électrique au repos

      Posté par  (site web personnel) . Évalué à 4 (+3/-1).

      Pour 3 serveurs dont un avec un Xeon et deux cartes Nvidia ? Ce n'est pas hors norme.

      Adhérer à l'April, ça vous tente ?

      • [^] # Re: Consommation électrique au repos

        Posté par  . Évalué à 4 (+2/-0).

        Ah, oui, je n'avais pas réalisé qu'il y avait plusieurs serveurs dans le décompte.
        Effectivement ce n'est pas hors norme, même si ça reste beaucoup pour ne rien faire :)

        • [^] # Re: Consommation électrique au repos

          Posté par  (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 29 mai 2024 à 16:50.

          Tout dépend ce que le serveur sert. Si les 3/4 du temps ce sont des services qui ne sont pas utilisés on peut se poser la question si ça ne vaut pas le coup d'avoir un hyperviseur plus petit et qui démarre des VMs à la demande quite à mettre en place une petite api accessible depuis un smartphone pour démarrer des VMS durant n minutes à la demande.

          Et dans ce cas là un pc qui prend qu'une dizaine de watts quand il est au ralenti avec des disques qui se mettent en veille suffit peut-être.

          Évidemment c'est difficile d'arrêter certains services comme mail/xmpp/dns…mais ce ne sont pas forcément les plus coûteux en ressources.

    • [^] # Re: Consommation électrique au repos

      Posté par  . Évalué à 5 (+3/-0).

      1 serveur Proxmox, 1 serveur de sauvegarde Proxmox, 1 Synology DS218+, la machine d'inférence, le routeur, le switch et l'onduleur

      4 machines, un routeur, un switch et un onduleur.

      Non, c'est n'est pas tant que ça pour cette infrastructure.

      Oui, c'est beaucoup quand même pour « ne rien faire », mais on ne sais pas encore faire des machines comme les smartphones : ne rien consommer au repos. C'est dommage :(

    • [^] # Re: Consommation électrique au repos

      Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

      En fait, lorsque je parlais du repos de ma machine, j'aurais dû préciser "sans inférence", car le reste de l'infrastructure continue à fonctionner. La machine consomme environ 100 watts au repos en mode inférence.

      En ce qui concerne mon Proxmox, je loue des conteneurs pour du stockage de sauvegardes, ce qui me permet de couvrir les coûts d'électricité associés à son fonctionnement. Je suis salarié à 80 % et indépendant à 20 %. Sur mon Proxmox, j'exécute également ma domotique, mon site web personnel ainsi que divers autres services Web.

      Sur mon NAS, je gère la vidéosurveillance, le stockage de mes photos, des médias (téléchargés légalement depuis Internet) et l'une de mes boîtes e-mail. Mon serveur Proxmox Backup effectue quant à lui des sauvegardes chiffrées sur une storage box chez Hetzner.

      Chez moi, tous les appareils informatiques sont éteints lorsqu'ils ne sont pas utilisés grâce aux prises connectées gérées par ma domotique, ce qui permet d'éviter la consommation en veille de la télévision et des autres appareils.

      Au cours de l'année allant du 1er avril 2023 au 31 mars 2024, notre consommation électrique s'est établie à 4553 kWh pour une villa occupée par trois personnes (selon BKW, notre fournisseur d'énergie).

  • # Tester en local

    Posté par  (site web personnel) . Évalué à 6 (+5/-1). Dernière modification le 29 mai 2024 à 15:52.

    Merci pour ce retour !
    Si vous voulez tester facilement ces llm en local, il existe jan.ai qui est très simple à installer et configurer.

  • # L'apprentissage des logs ?

    Posté par  . Évalué à 10 (+8/-0).

    Merci pour ce retour.
    Je suis curieux de comprendre le fonctionnement des LLM appliqué à l’analyse de logs.
    Puisque tu baignes dedans, si tu as de la lecture à ce sujet ou l'envie te prends d'écrire un chti journal ;-)

    • [^] # Re: L'apprentissage des logs ?

      Posté par  . Évalué à 3 (+1/-0).

      Je ne sais pas si c'est possible, mais j'aimerai un LLM et pouvoir lui dire:

      MOI: "tiens, vla mon /var/log/messages (ou mon journalct --no-tail), lis moi tout ça, et extrait moi des informations pertinentes"

      LLM: "Bien sûr, j'ai constaté de multiples tentatives de connexions ssh et des messages smartctl"

      MOI: "oublie les connexions ssh, donne moi le message smartclt"

      LLM: "le message indique que le disque secondaire du système est en train de mourir"

      MOI: "donne moi les commandes pour sauvegarder le disque"

      LLM: …

      Voilà un peu ce que j'aimerai que les LLM fassent. Faire des greps, je sais faire. Lire un journal aussi. Doit y'avoir moyen de faire manger ça à un LLM pour qu'il corrèle un peu les données?

      • [^] # Re: L'apprentissage des logs ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        Oui, c'est possible, mais il y a une information importante à prendre en compte : le contexte.

        C'est la fenêtre sur laquelle le LLM peut travailler (historique, longueur du prompt, ce qu'on passe en paramètre…).

        Cette fenêtre est glissante, ce qui signifie que le LLM ne se souvient pas de ce qu'il y avait avant lorsque le contexte est trop grand.

        • Llama3, toutes les versions, c'est 8k tokens (8192 tokens).
        • Mixtral 8x7b, c'est 32k tokens
        • Mixtral 8x22b, c'est 68k tokens.

        On peut augmenter la fenêtre de contexte avec le fine-tuning, mais plus la fenêtre de contexte est grande, plus le modèle a besoin de RAM pour travailler. Donc, le contexte est un compromis.

        Le problème du fichier de log, c'est sa taille : si il est trop gros, il ne se souviendra pas du début et notamment des instructions qui sont passées. Il faudra donc faire régulièrement un log-rotate, ou nettoyer en enlevant ce qui n'est pas pertinent, ou prendre les 20 dernières lignes, par exemple, et envoyer régulièrement le bout de log au LLM.

        Ensuite, il suffit de le prompter, genre : Tu es un spécialiste de l'analyse de log sous Linux, les logs n'ont aucun secret pour toi. Dans le contexte, il y a le log, fais-moi une analyse et remonte-moi si tu vois un problème pour l'exploitation de la machine.

        J'ai fait l'exercice sur une de mes machines, ce n'est pas très pertinent ; je met sa réponse ci-dessous. Je préfère la supervision qui fait mieux le boulot.

        Réponse du LLM (Mixtral 8x7b)

        Ce journal semble provenir d'un serveur de messagerie Postfix qui traite et livre des messages électroniques. Voici ce que je peux déduire des entrées de journal fournies :

        • La première entrée montre qu'un message électronique avec l'ID 45BC8325AF2 a été reçu par postfix/cleanup pour livraison. Il fait 821 octets et est adressé à backupemail@docker-media.localdomain.
        • La deuxième entrée indique que le message a été accepté dans la file d'attente Postfix (nrcpt=1) avec l'état "file active".
        • Dans la troisième entrée, postfix/local tente de livrer localement mais échoue en raison d'une erreur lors de l'écriture dans le fichier du répertoire de messagerie pour l'utilisateur backupemail : "cannot update mailbox /var/mail/backupemail for user backupemail. error writing message: File too large" (dsn=5.2.2).
        • La quatrième entrée montre que la notification d'erreur de livraison a été générée avec l'ID 4B9B9325AF3, qui est envoyé à l'expéditeur d'origine du message bounce. Cela fait partie des pratiques standard de Postfix lorsqu'un e-mail ne peut pas être livré avec succès.
        • Dans les cinquième et sixième entrées, postfix/qmgr supprime les deux messages (IDs 45BC8325AF2 et 4B9B9325AF3) de la file d'attente après leur traitement.
        • Le journal montre également des activités planifiées par cron à 14:23:01, 15:23:01 et 15:30:01 (CRON[xxxxx]). Il semble qu'un script situé dans /opt/IMAPbackup soit exécuté par l'utilisateur backupemail.
        • La dernière entrée montre une erreur de dockerd liée à l'impossibilité de fermer stdin pour le processus d74bc6b1b294b33c4ae7df99ac9c3f0b852ad64e9545c566f564f1fa10b752b0. Ce message d'erreur n'est pas lié aux entrées de journal Postfix et peut être un problème distinct qui doit être enquêté séparément.

        En résumé, il semble qu'il y ait eu un e-mail adressé à backupemail@docker-media.localdomain qui n'a pas pu être livré en raison d'une limitation de taille du fichier sur /var/mail/backupemail. Le serveur de messagerie a généré une notification d'erreur et supprimé les deux messages de la file d'attente. De plus, certaines tâches planifiées ont été exécutées par l'utilisateur backupemail à 15:30:01, mais elles ne semblent pas avoir causé de problèmes avec la livraison Postfix.

        • [^] # Re: L'apprentissage des logs ?

          Posté par  (site web personnel) . Évalué à 4 (+1/-0).

          Sachant que les LLM ne sont pas fiables (hallucinations et autres), j'ai quand même de gros doute de leur confier ce genre de tâches car derrière il faut vérifier s'il ne s'est pas planté dans ce qu'il a dit. Ce qui implique de refaire l'analyse avec des méthodes plus usuelles si on veut une certaine fiabilité.

          Ce genre de tâches devrait être réalisé avec des outils dédiés avec une plus grande certitude quant au résultat obtenu et des limitations réelles.

  • # Suspend to ram ou disque?

    Posté par  (site web personnel) . Évalué à 4 (+3/-0).

    "Arrêter la machine d'inférence la nuit."

    "Suspend to ram" ou "Suspend to disk" n'est pas possible je suppose avec les GPUs?

  • # groq

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Merci pour ce journal, avoir la consommation électrique est primordiale.

    Pour de l'inférence, il vaut mieux utiliser des services spécialisés, comme groq. ça doit être 10 fois plus efficace que du NVidia (ou AMD, ROCm, tout ça, et MAC) pour l'inférence.

    https://groq.com/

    Quelle est la consommation d'un M2 ou un M3 pour la même chose ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.