GPU 기반 vLLM 자동화를 GitLab CI/CD 및 RunPod를 활용해 실현

![이미지는 컨테이너 관리 인터페이스를 보여주며, 배포, 파드 목록 및 관리(중지/시작/삭제) 작업이 연결된 블록 형태로 구성되어 있습니다. (AI에서 제공한 이미지 설명)|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

시작

대규모 언어 모델(LLM)을 실행하는 것은 상당한 컴퓨팅 자원을 요구합니다. 그리고 다양한 그래픽 처리 장치(GPU)를 테스트해야 할 때는 클라우드에서 컴퓨팅 능력을 임시로 임대해야 합니다.

이러한 자원을 수동으로 관리하는 것은 시간이 오래 걸리며, 오류를 유발하고 확장성 측면에서 복잡하며 여러 단점이 있습니다. 예를 들어, 각 직원이 얼마를 지출했는지에 대한 통제가 없고, 가상 머신을 종료하는 것을 자주 잊는 직원들이 존재합니다.리드 DevOps로서 저는 RunPod에서 우리 팀이 GPU 인스턴스를 배포하고 관리하며 삭제하는 과정을 단순화하는 방법을 제공해야 하는 문제를 마주했습니다. 특히 vLLM을 사용한 추론(inference)에 집중했습니다.

이 문제를 해결하기 위해 저는 GitLab CI/CD 파이프라인을 개발하여 RunPod 그래픽 모듈의 전체 생애 주기를 GitLab 인터페이스에서 자동화했습니다.

이 솔루션은 그래픽 처리 장치(GPU) 자원 관리를 단순화하고, 작업 프로세스의 효율성을 높이며, 배포 프로세스의 투명성을 확보하도록 설계되었습니다. 이 글에서는 설정 방법과 작동 방식에 대해 설명하겠습니다.

문제

RunPod 계정이 올바르게 구성되어 있든 아니든, 팀원별로 자원 사용량과 요금을 추적하는 것은 불편합니다. GPU 계산은 비싸기 때문에, 특히 자동화된 방식으로 이에 대한 통제가 매우 중요합니다.

이걸 말할 필요가 있겠습니까? 수동 실행은 시간과 지속적인 주의가 필요하죠.사람은 반복적인 시도 속에서 오류를 범하기 마련입니다.

또 다른 문제(현재까지 확정적으로 해결하지 못한 문제)는 GPU 스코프의 자동 관리입니다. 여러 vLLM이 병렬로 작동하는 것이 순차적으로 작동하는 것보다 훨씬 더 좋기 때문입니다.

해결책: GitLab CI/CD 파이프라인

연구 결과로 제가 제안하고 싶은 파일이 있습니다 - .gitlab-ci.yml. 이 파일은 Pod 생성 및 삭제, vLLM 설정을 위해 간단한 cURL 요청을 사용합니다.

작동 방식

저는 코드를 다음과 같은 단계로 나누었습니다:

  • deploy
  • listing
  • destroy
  • stop
  • start

미래에는 다음과 같은 추가 단계가 추가될 예정입니다:

  • 이메일 전송
  • Discourse에 알림 전송세 가지 마지막 단계는 listing이 완료되어야 합니다. 이 단계에서 Pod ID가 확인되므로, Pod 생성 단계에서는 이 ID를 얻을 수 없습니다. Pod 배포에 필요한 시간이 다르기 때문에 API는 배포가 완료되기 전에 응답을 반환하기 때문입니다. 이 목적을 위해 별도의 listing 단계를 마련했습니다.

각 단계는 Gitlab Pipeline에서 상세한 로그를 제공합니다. 이는 초기 단계에서 도움이 되며 신입 직원의 연동에도 유리합니다.

새로운 파이프라인 실행 시 변수를 재정의할 수 있습니다(그렇지 않으면 코드 수정을 통해 변수를 추가해야 합니다).

설치 가이드 (간략히)

Gitlab의 CI 프로젝트 내 Variables 섹션에 중요한 변수를 저장해야 합니다. 코드는 이 변수들을 참조합니다. 예를 들어 다음과 같은 변수들이 있습니다:- RUNPOD_API_KEY: RunPod의 API 키

  • HG_TOKEN: Hugging Face의 토큰
  • RUNPOD_SSH_PUBLIC_KEYS: 컨테이너에 접근하기 위한 공개 SSH 키(여러 개일 경우 \n으로 분리)
  • RUNPOD_SSH_PRIVATE_KEY: GitLab Runner가 컨테이너에 연결하기 위한 개인 SSH 키
    (민감한 데이터를 마스킹하여 로그에 노출되지 않도록 합니다)

왜 이러한 접근 방식이 유용한가?이 접근법은 다음과 같은 장점이 있습니다:

  • 다양한 수준의 AI 엔지니어를 역할에 따라 분리할 수 있으며, 하나의 CI가 모든 사용자에게 적합합니다.
  • 각 직원에게 자체적인 파이프라인 공간과 이력이 제공됩니다.
  • 계정 비용을 직원별로 쉽게 분할할 수 있습니다.
  • 실행 및 현재 스탠드의 제어를 쉽게 수행할 수 있습니다.
  • 다양한 구성은 브랜치 형태로 쉽게 저장할 수 있습니다.
  • 필요에 따라 무한정 수의 데모 스탠드를 빠르게 배포할 수 있습니다.
  • DevOps에 대한 일반적인 접근법으로, 모든 엔지니어가 지원합니다.
  • 개발팀 간의 코드 이동이 매우 용이합니다.
  • 가장 중요한 점은, AI 요소를 프로젝트 아키텍처에 통합할 때 GitLab 워크플로우와 100% 호환됩니다.

결론이 GitLab CI/CD 구성은 그래픽 처리 장치(RunPod 인스턴스)를 사용하여 AI 작업을 수행하는 데 안정적이고 편리한 방법을 제공합니다. 이는 DevOps 실천과 인공지능 모델 도입 사이의 격차를 해소합니다. 코드와 자세한 지침은 레포지토리에서 확인할 수 있습니다. 저(작성자)는 여러분이 이 구성에 도전해보기를 권장하며, 유용하다고 생각하면 별을 남기고, 개선 아이디어가 있다면 기여해 주기를 바랍니다! 또한 저의 웹사이트 https://discuss.rabkesov.ru를 방문해 저의 작업에 대해 더 자세히 알아보고, 토론에 참여해보는 것도 좋습니다.

관련 주제