GitHub
Medium
Inizio
Eseguire modelli linguistici di grandi dimensioni (LLM) può richiedere risorse computazionali significative. Quando si desidera testare diversi tipi di GPU, è necessario noleggiare potenza cloud.
Gestire questi risorse manualmente richiede molto tempo, porta a errori, è complesso da scalare e presenta numerosi svantaggi. Ad esempio, non c’è controllo su quanto ogni dipendente ha speso e chi dimentica più spesso di spegnere le macchine virtuali.Come Lead DevOps, mi sono trovato di fronte al problema di fornire un modo semplificato per il provisioning, la gestione e la distruzione degli istanze GPU su RunPod per la nostra squadra. La nostra priorità era l’inferenza utilizzando vLLM su diverse GPU.
Per risolvere questo problema, ho sviluppato un pipeline GitLab CI/CD che automatizza tutto il ciclo di vita dei moduli grafici di RunPod direttamente dall’interfaccia di GitLab.
Questa soluzione mira a semplificare la gestione delle risorse di GPU, aumentare l’efficienza del processo di lavoro e garantire la trasparenza del processo di provisioning. In questo post vi spiegherò come è stato configurato e come funziona.
Il problema
Indipendentemente da quanto correttamente sia configurato l’account su RunPod, ci sono inconvenienti relativi al controllo e al billing per i membri della squadra. I calcoli GPU sono costosi, quindi il controllo, soprattutto automatizzato, è particolarmente importante in questo ambito.
È necessario parlare del fatto che l’avvio manuale richiede più tempo e attenzione costante?È naturale che gli esseri umani commettano errori, soprattutto in condizioni di prove multiple.
C’è un’altra problematica (che al momento non è stata risolta in modo definitivo) — il controllo automatico dello scope GPU. Infatti, lavorare in parallelo con più istanze di vLLM è chiaramente più efficace rispetto a un’implementazione sequenziale.
Soluzione: Pipeline GitLab CI/CD
Dopo le ricerche, ho ottenuto un file che vorrei presentare — .gitlab-ci.yml. Utilizza semplici richieste cURL per creare e eliminare i Pod, configurare vLLM.
Come funziona
Ho suddiviso il codice in fasi:
- deploy
- listing
- destroy
- stop
- start
In futuro saranno aggiunti ulteriori passaggi:
- invio di email
- invio di notifiche su DiscourseI tre ultimi passaggi richiedono che sia eseguito il listing. Poiché in questa fase viene determinato l’ID del Pod, non è possibile ottenerlo durante la fase di creazione del Pod, poiché il tempo di deploy varia e l’API risponde prima che il deploy sia completato. A tale scopo è stato creato un passaggio separato dedicato al listing.
Ogni passaggio include un dettagliato logging all’interno del Gitlab Pipeline. Ciò dovrebbe aiutare nelle fasi iniziali e facilitare l’integrazione di nuovi membri del team.
Al lancio di un nuovo pipeline è possibile sovrascrivere le variabili (altrimenti, inserire le variabili modificando il codice).
Guida all’installazione (breve)
Le variabili importanti devono essere memorizzate nel Gitlab, nella sezione Variables del progetto CI. Il codice fa riferimento a queste variabili. Si tratta di variabili come:- RUNPOD_API_KEY: Il tuo chiave API di RunPod
- HG_TOKEN: Il tuo token di Hugging Face
- RUNPOD_SSH_PUBLIC_KEYS: I tuoi chiavi SSH pubbliche per accedere al pod (se applicabile, separate da \n se ce ne sono più di una)
- RUNPOD_SSH_PRIVATE_KEY: La tua chiave SSH privata, in modo che GitLab Runner possa connettersi al pod
(usa la mascheratura dei dati sensibili in modo che non appaiano in chiaro nei log)
Perché questo approccio è utileQuesto approccio è utile per:
- Separare gli ingegneri AI di diversi livelli per ruoli – un CI è adatto a tutti
- Ogni dipendente ha il proprio spazio Pipeline con storia
- Dividere facilmente i costi dell’account tra i dipendenti
- Controllare facilmente i lanci e i server in corso
- Archiviare facilmente diverse configurazioni come branch
- Sviluppare rapidamente quante più demo server si desidera
- Approccio universale nel DevOps – supporta qualsiasi ingegnere
- Portabilità semplice del codice tra squadre di sviluppo
- Il punto più importante: 100% compatibilità con i workflow di GitLab quando si integrano elementi AI nell’architettura del progetto