GitHub
Medium
Début
L’exécution de grands modèles de langage (LLM) peut nécessiter des ressources computationnelles importantes. Et lorsqu’il faut tester différents GPU, il faut alors louer des ressources dans le cloud.
Gérer ces ressources manuellement prend beaucoup de temps, conduit à des erreurs, est difficile à échelonner et présente de nombreux inconvénients. Par exemple, il n’y a pas de contrôle sur combien chaque employé a dépensé d’argent, et qui oublie souvent d’éteindre les machines virtuelles.En tant que Lead DevOps, j’ai rencontré un problème lié à la nécessité d’offrir une méthode simplifiée pour déployer, gérer et supprimer des instances GPU sur RunPod pour notre équipe. Notre priorité était l’inférence utilisant vLLM sur différents GPU.
Pour résoudre ce problème, j’ai développé un pipeline GitLab CI/CD qui automatise tout le cycle de vie des modules graphiques de RunPod directement depuis l’interface GitLab.
Cette solution vise à simplifier la gestion des ressources de la carte graphique, à augmenter l’efficacité du processus de travail et à garantir la transparence du processus de déploiement. Dans cet article, je vous expliquerai la configuration et le fonctionnement de cette solution.
Problème
Quelle que soit la configuration correcte du compte sur RunPod, il existe des difficultés en matière de contrôle et de facturation par membre de l’équipe. Les calculs GPU sont coûteux, donc un contrôle, surtout automatisé, est particulièrement crucial dans ce domaine.
N’est-ce pas évident que le lancement manuel exige plus de temps et d’attention constante ?Il est naturel pour les humains de commettre des erreurs, surtout dans des conditions de multiples tentatives.
Il existe une autre problématique (dont la solution n’a pas encore été garantie) : la gestion automatique du scope GPU. En effet, le travail parallèle avec plusieurs instances vLLM est clairement préférable à une exécution séquentielle.
Solution : Pipeline GitLab CI/CD
Après des recherches, j’ai obtenu un fichier que je souhaite présenter : .gitlab-ci.yml. Il utilise des requêtes cURL simples pour créer et supprimer des Pods, ainsi que configurer vLLM.
Comment cela fonctionne
J’ai divisé le code en étapes :
- deploy
- listing
- destroy
- stop
- start
Dans l’avenir, des étapes supplémentaires seront ajoutées :
- envoi d’e-mails
- envoi de notifications sur DiscourseLes trois derniers étapes exigent que le listing soit effectué. Puisque c’est à ce stade que l’ID du Pod est connu, il est impossible d’obtenir cet ID lors de la création du Pod, car le déploiement nécessite un temps de réponse variable et l’API ne répond que lorsque le déploiement est terminé. C’est pourquoi un étape de listing a été spécifiquement créée.
Chaque étape contient un journal détaillé dans le pipeline GitLab. Cela devrait aider au début et faciliter l’intégration des nouveaux employés.
Lors du lancement d’un nouveau pipeline, les variables peuvent être redéfinies (sinon, veuillez les ajouter via la modification du code).
Guide d’installation (version courte)
Les variables importantes doivent être stockées dans GitLab, dans la section Variables du projet CI. Le code y fait référence. Il s’agit de variables telles que :- RUNPOD_API_KEY : Votre clé API RunPod
- HG_TOKEN : Votre token Hugging Face
- RUNPOD_SSH_PUBLIC_KEYS : Vos clés SSH publiques pour accéder au pod (si applicable, séparées par \n si plusieurs)
- RUNPOD_SSH_PRIVATE_KEY : Votre clé SSH privée pour permettre à GitLab Runner de se connecter au pod
(Utilisez le masquage des données sensibles afin qu’elles ne soient pas exposées en clair dans les logs)
Pourquoi cette approche est utileCet approche est utile pour :
- Séparer les ingénieurs en intelligence artificielle selon leurs niveaux de compétence en attribuant des rôles distincts – un CI convient à tous
- Chaque employé dispose de son propre espace Pipeline avec son historique
- Faciliter la répartition des coûts de compte par employé
- Faciliter le contrôle des lancements et des environnements en cours
- Faciliter le stockage de différentes configurations sous forme de branches
- Faciliter la création rapide de n’importe combien d’environnements de démonstration
- Approche universelle en DevOps – compatible avec tout ingénieur
- Facilité de transfert du code entre équipes de développement
- Enfin, 100 % de compatibilité avec les workflows GitLab lors de l’intégration d’éléments d’intelligence artificielle dans l’architecture du projet