Automatización de vLLM con GPU mediante GitLab CI/CD y RunPod

![La imagen muestra la interfaz de gestión de contenedores, donde las acciones de despliegue, lista y gestión de pods (stop/start/destroy) están organizadas en forma de bloques relacionados. (Credito de la imagen por IA)|690x190](upload://vIBp6USq9mV03c5dOg4tHNxgJAj.png)

GitHub

Medium

https://komnata-lomki.medium.com/automating-vllm-on-gpu-using-gitlab-ci-cd-and-runpod-8040d8efb70d?source=friends_link&sk=97b512eef8bfc1ca12aa6518135bc957

Comienzo

Ejecutar modelos de lenguaje grandes (LLM) puede requerir recursos computacionales significativos. Y cuando se necesita probar diferentes tarjetas gráficas, se debe alquilar potencia en la nube.

Gestionar estos recursos manualmente consume mucho tiempo, conduce a errores, es difícil de escalar y tiene muchos inconvenientes. Por ejemplo, no hay control sobre cuánto dinero ha gastado cada empleado y quién suele olvidarse de apagar las máquinas virtuales.Como Lead DevOps, me enfrenté al problema de proporcionar un método simplificado para desplegar, gestionar y eliminar instancias de GPU en RunPod para nuestro equipo. Nuestro principal interés era el inferencia utilizando vLLM en diferentes GPUs.

Para resolver este problema, desarrollé un pipeline de GitLab CI/CD que automatiza todo el ciclo de vida de los módulos gráficos de RunPod directamente desde la interfaz de GitLab.

Esta solución busca simplificar la gestión de recursos de procesador gráfico, mejorar la eficiencia del proceso de trabajo y garantizar la transparencia del proceso de despliegue. En este post, les contaré cómo configurarlo y cómo funciona.

Problema

Independientemente de si la cuenta en RunPod está correctamente configurada, existen inconvenientes en cuanto al control y facturación por parte del equipo. Las computaciones GPU son costosas, por lo tanto, el control, especialmente automatizado, es especialmente importante en este ámbito.

¿Es necesario mencionar que el lanzamiento manual requiere más tiempo y atención constante?Es natural que las personas cometan errores, especialmente en condiciones de múltiples intentos.

Hay otra problema (que aún no se ha resuelto de forma garantizada) — el control automático del scope de GPU. Ya que trabajar en paralelo con varios vLLM es claramente mejor que hacerlo de forma secuencial.

Solución: Pipeline de GitLab CI/CD

Después de investigar, he creado un archivo que quiero presentar — .gitlab-ci.yml. Utiliza solicitudes simples cURL para crear y eliminar Pods, así como configurar vLLM.

Cómo funciona

He dividido el código en etapas:

  • deploy
  • listing
  • destroy
  • stop
  • start

En el futuro se añadirán más pasos:

  • envío de correos electrónicos
  • envío de notificaciones a DiscourseLos tres últimos pasos requieren que se ejecute un listing. Dado que en esta etapa se conoce el ID del Pod, no es posible obtenerlo en la fase de creación del Pod, ya que el tiempo de despliegue puede variar y la API responde antes de que el despliegue finalice. Para este propósito, se creó un paso separado llamado listing.

Cada paso incluye registro detallado en el pipeline de GitLab. Esto debería ayudar en las fases iniciales y es conveniente para la integración de nuevos empleados.

Al iniciar un nuevo pipeline, es posible sobrescribir variables (de lo contrario, introduce las variables mediante la edición del código).

Guía de instalación (breve)

Las variables importantes deben almacenarse en GitLab, en la sección Variables del proyecto CI. El código hace referencia a ellas. Son variables como:- RUNPOD_API_KEY: Su clave API de RunPod

  • HG_TOKEN: Su token de Hugging Face
  • RUNPOD_SSH_PUBLIC_KEYS: Sus claves SSH públicas para acceder al pod (si aplica, separadas por \n si hay varias)
  • RUNPOD_SSH_PRIVATE_KEY: Su clave SSH privada para que GitLab Runner pueda conectarse al pod
    (Use la ocultación de datos sensibles para que no aparezcan en los logs en texto plano)

Por qué este enfoque es útilEste enfoque es útil para:

  • Dividir a los ingenieros de IA de distintos niveles según sus roles — un CI es adecuado para todos.
  • Cada empleado tiene su propio espacio de Pipeline con historial.
  • Facilita la división de costos del cuenta entre empleados.
  • Facilita el control de lanzamientos y entornos actuales.
  • Facilita el almacenamiento de distintas configuraciones como ramas.
  • Permite desplegar rápidamente cualquier número de entornos de demostración.
  • Enfoque universal en DevOps — soporta a cualquier ingeniero.
  • Facilita la portabilidad del código entre equipos de desarrollo.
  • Lo más importante: 100% compatibilidad con los workflows de GitLab al integrar elementos de IA en la arquitectura del proyecto.

ConclusiónEsta configuración de GitLab CI/CD proporciona una forma confiable y cómoda de interactuar con instancias de GPU de RunPod para tareas de IA. Elimina la brecha entre las prácticas DevOps y la implementación de modelos de inteligencia artificial. Puedes encontrar el código e instrucciones detalladas en el repositorio. Como autor, te invito a probarlo, a dejar una estrella si lo consideras útil, y a contribuir con tus ideas de mejora. Quizás también te interese visitar mi sitio web https://discuss.rabkesov.ru para conocer más sobre mi trabajo y participar en discusiones.

Más sobre el tema