GitHub
Medium
Início
Executar modelos de linguagem de grande porte (LLM) pode exigir recursos computacionais significativos. E quando é necessário testar diferentes GPUs, é preciso alugar poder de cálculo na nuvem.
Gerenciar esses recursos manualmente é demorado, propenso a erros, difícil de escalar e possui diversos problemas. Por exemplo, não há controle sobre quanto cada funcionário gastou e quem mais frequentemente esquece de desligar as máquinas virtuais.Como Lead DevOps, enfrentei o problema de fornecer um método simplificado para implantar, gerenciar e destruir instâncias de GPU no RunPod para nossa equipe. Nosso foco principal era o inferência utilizando vLLM em diferentes GPUs.
Para resolver esse problema, desenvolvi um pipeline GitLab CI/CD que automatiza todo o ciclo de vida dos módulos gráficos do RunPod diretamente da interface do GitLab.
Essa solução visa simplificar o gerenciamento de recursos de GPU, aumentar a eficiência do processo de trabalho e garantir a transparência do processo de implantação. Neste post, vou explicar como configurá-lo e como ele funciona.
Problema
Independentemente de o conta no RunPod estar corretamente configurada, existem inconvenientes em relação ao controle e faturamento por membros da equipe. Cálculos de GPU são caros, portanto, o controle — especialmente automatizado — é particularmente importante nesse contexto.
É preciso dizer que o lançamento manual exige mais tempo e atenção contínua?É natural que os humanos cometam erros, especialmente em ambientes com múltiplas tentativas.
Há outra questão (ainda não resolvida de forma garantida) — o gerenciamento automático do escopo GPU. Pois, claramente, trabalhar em paralelo com vários vLLM é melhor do que fazer isso sequencialmente.
Solução: Pipeline GitLab CI/CD
Após pesquisas, criei um arquivo que desejo apresentar — .gitlab-ci.yml. Ele utiliza requisições simples com cURL, para criar e remover Pods, e configurar o vLLM.
Como funciona
Dividi o código em etapas:
- deploy
- listing
- destroy
- stop
- start
Em breve serão adicionadas etapas extras:
- envio de e-mails
- envio de notificações para o DiscourseOs três últimos estágios exigem que seja executado o listing. Como neste estágio é conhecido o ID do Pod, ele não pode ser obtido no estágio de criação do Pod, pois o tempo de deploy varia e a API responde antes que o deploy seja concluído. Para esse propósito, foi criado um passo separado de listing.
Cada passo contém registro detalhado no Gitlab Pipeline. Isso deve ajudar nas fases iniciais e é conveniente para a integração de novos colaboradores.
Ao iniciar um novo pipeline, é possível sobrescrever as variáveis (caso contrário, insira as variáveis via edição do código).
Guia de instalação (resumido)
As variáveis importantes devem ser armazenadas no Gitlab, na seção Variables do projeto CI. O código acessa essas variáveis. São variáveis como:- RUNPOD_API_KEY: Seu chave API do RunPod
- HG_TOKEN: Seu token do Hugging Face
- RUNPOD_SSH_PUBLIC_KEYS: Seus chaves SSH públicas para acesso ao pod (se aplicável, separadas por \n, se houver mais de uma)
- RUNPOD_SSH_PRIVATE_KEY: Sua chave SSH privada, para que o GitLab Runner possa se conectar ao pod
(Use a máscara de dados sensíveis para que eles não apareçam em logs abertos)
Por que esse método é útilEsse abordagem é útil para:
- Divisão de engenheiros de IA de diferentes níveis por papéis — um CI é adequado para todos
- Cada funcionário tem seu próprio espaço de Pipeline com histórico
- Divisão fácil de custos do plano por funcionários
- Controle fácil de execuções e ambientes atuais
- Armazenamento fácil de diferentes configurações como branches
- Deploy rápido de quantos ambientes de demonstração forem necessários
- Abordagem universal em DevOps — suporta qualquer engenheiro
- Portabilidade fácil do código entre equipes de desenvolvimento
- O mais importante: 100% compatibilidade com o workflow do GitLab ao integrar elementos de IA na arquitetura do projeto