[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을 갖춘 인스턴스를 선택할 것
- 팀 차원에서 운영/모니터링 및 비용 통제가 가능할 것
테스트 및 개발용으로는 적절하며, 정식 서빙으로 이어지기 위해선 추가 검증과 리소스 할당 전략이 필요함.