개발자가 8GB VRAM에서 임베드, 리랭크, 제로샷 모델을 서빙하기 위한 아키텍처 조언을 구합니다

문제 개요

개발자가 FastAPI를 통해 단일 Docker 컨테이너에서 실행되는 로컬 코딩 에이전트를 위한 통합 지식 그래프/RAG 서비스를 구축 중입니다. 시스템은 처음에 Windows(WSL)에서 괜찮게 실행되었지만, 네이티브 Linux로 이동한 후 스트레스 테스트에서 심각한 메모리 한계 문제가 드러났습니다.

하드웨어 및 모델 제약

하드웨어:

• 8GB VRAM (노트북 GPU)
• ~16GB 시스템 RAM (Docker 한계에 빠르게 도달하며, 모델이 로드되면 보통 ~6GB만 사용 가능)

모델 스택:

• 임베딩: nomic-ai/nomic-embed-text-v2-moe
• 재순위화: BAAI/bge-reranker-base
• 분류: MoritzLaurer/ModernBERT-large-zeroshot-v2.0 (텍스트 쌍을 4가지 관계: 의존성, 확장, 모순, 무관계로 분류하는 데 사용)

기술적 과제

개발자는 코드 청크와 자연어 텍스트를 이러한 모델에 입력하고 가변적이고 긴 시퀀스를 처리해야 하기 때문에 텍스트를 적극적으로 잘라낼 수 없습니다.

발생한 구체적인 문제:

• 지연 시간 대 OOM: GPU를 깨끗하게 유지하기 위해 torch.cuda.empty_cache()를 사용하면 드라이버 동기화로 인해 요청당 18-20초의 지연 시간 급증이 발생합니다. 이를 제거하면 동시 요청이 들어올 때 GPU가 즉시 OOM 상태가 됩니다.
• 시스템 RAM 폭발 (Linux Exit 137): Hugging Face pipeline("zero-shot-classification")을 사용하면 CPU RAM이 엄청나게 부풀어 오릅니다. 잘라내기 없이 파이프라인은 GPU로 보내기 전에 메모리에 거대한 조합 행렬을 생성하여 Linux 커널이 컨테이너를 즉시 종료시킵니다.
• VRAM 급증: cudnn.benchmark = True는 모든 고유 시퀀스 길이에 대한 작업 공간을 캐싱하여 스트레스 테스트 중 몇 초 만에 3GB의 여유 VRAM을 소모했습니다.

현재 구현

개발자는 다음과 같은 해결책을 적용한 순수 Python/FastAPI 설정을 가지고 있습니다:

• HF 파이프라인을 우회하고 ModernBERT를 위한 수동 NLI 추론 루프 작성
• asyncio.Lock()을 사용하여 직렬 실행 강제 (한 번에 하나의 모델만 GPU 사용)
• FastAPI 백그라운드 작업을 통해 결정적 할당 해제 (del inputs + gc.collect()) 사용

이 접근 방식은 더 나은 성능을 보이지만 3분 스트레스 테스트에서 여전히 불안정합니다.

커뮤니티에 대한 질문

개발자는 다음에 대한 조언을 구하고 있습니다:

• 모델 대안: 8GB 환경에 더 잘 맞으면서 Zero-Shot NLI와 재순위화에 대해 높은 정확도를 유지하는 더 작고 빠른 모델
• 사전 구축된 아키텍처: 이전에 infinity_emb를 살펴보았지만 모델을 이중 로드하지 않고 사용자 정의 4방향 NLI 분류 로직을 통합하는 데 어려움을 겪었습니다. TEI(Text Generation Inference), TensorRT 또는 인코더 모델에 최적화된 다른 솔루션을 고려 중
• 서빙 전략: 단일 소비자 GPU에서 3개의 트랜스포머 모델을 호스팅할 때 메모리를 서로 방해하지 않도록 하는 표준 설계 패턴