[V1.5] [모델 배포 방식] GCP에 올리기 - 100-hours-a-week/6-nemo-ai GitHub Wiki

Version 2 실험:

GCP 기반 Transformers 모델 서빙 보고서

1. 실험 배경

Colab 환경의 세션 유지 불가 및 크레딧 소모 속도 문제를 해결하기 위해, 보다 안정적이고 지속 가능한 모델 서빙 환경을 찾는 과정에서 GCP 인스턴스를 활용한 실험을 진행하였습니다.

특히 GCP에 모델을 직접 업로드하고, 독립된 VM 환경에서 실행함으로써 더 높은 안정성과 유연성을 확보할 수 있을 것으로 기대되었습니다.


2. 실험 구성 및 환경

  • 인스턴스 타입: e2-medium (2 vCPU, 4GB RAM)
  • 스토리지: 로컬 디스크 (초기 10GB → 실험 중 30GB로 확장)
  • 사용 모델: Gemma 2B
  • 라이브러리: HuggingFace transformers
  • 기타: GPU 미사용 (할당 불가 문제로 CPU 테스트)

3. 진행 방식

  • pip install을 통해 필요한 패키지 설치
  • 가상환경(virtualenv) 안에서 git을 통해 모델 코드 및 리소스 업로드
  • FastAPI는 미구현 상태, 대신 단순한 model_testing.py 스크립트로 프롬프트 테스트 진행
  • 외부 접속 및 서빙은 아직 연결하지 않았으며, 추후 필요 시 static IP 또는 도메인 연결 예정

4. 문제점 및 트러블슈팅

4.1 GPU 할당 문제

  • GCP 프로젝트 간 GPU 할당 제약으로 인해, 현재 사용 중인 프로젝트에서는 GPU를 사용할 수 없었음
  • 따라서 실험은 CPU 인스턴스를 기반으로 진행
  • 이 방식을 채택할 경우, GPU 사용이 가능한 프로젝트에서 재검증 필요

4.2 디스크 용량 부족

  • OSError: [Errno 28] No space left on device 오류 발생
  • 원인은 디스크 용량 부족 (기본 10GB)
  • 임시로 30GB로 증설하여 실험 재시도
  • 실제 서비스 운영을 고려하면 100GB 이상의 용량 확보 필요

4.3 메모리 부족 시 프로세스 자동 종료

  • 모델 실행 중 메모리 부족 상황에서 사전 경고 없이 프로세스가 강제 종료되는 현상 발생
  • RAM이 부족한 환경에서는 안정적인 추론 보장이 어려움

5. 평가 및 판단

  • 장점
    • 독립 VM 환경으로 세션 유지 문제 해결 가능
    • FastAPI, 도메인 연결 등 원하는 방식으로 자유롭게 구성 가능
    • 팀원이 각자 가진 GCP 크레딧 활용 가능
  • 단점
    • RAM/디스크 자원 부족 시 실행 불안정
    • Colab보다 더 빠르게 요금이 발생할 수 있으며, 현재 실험만으로도 약 1,000원 비용 소모
    • 팀원 계정 간 크레딧 이전이 불가능하므로 계정 이동 및 통합 관리에 번거로움 존재

6. 결론

GCP 기반 모델 서빙은 안정성 측면에서 Colab 대비 확실한 이점이 있으며, 실제 서비스 운영 환경으로의 확장 가능성도 높음.

다만, GPU 사용 제약, 초기 디스크 및 RAM 설정 부족, 비용 증가 요소 등이 있으므로 다음 조건을 충족하는 경우에 한해 유의미한 선택지로 판단됨:

  • GPU가 할당된 프로젝트에서 운영 가능할 것
  • 충분한 디스크 및 RAM을 갖춘 인스턴스를 선택할 것
  • 팀 차원에서 운영/모니터링 및 비용 통제가 가능할 것

테스트 및 개발용으로는 적절하며, 정식 서빙으로 이어지기 위해선 추가 검증과 리소스 할당 전략이 필요함.