1. 구조 변경으로 인한 역할 변화

• 기존에는 CPU 서버가 직접 CLIP ViT-B/32 모델로 임베딩을 수행
• 이제는 GPU 서버가 ViT-L/14 모델로 임베딩을 수행하고, CPU 서버는 단순 중계/캐싱 역할

---

2. 고려 및 의문점

a. CPU 서버에서 SerialTaskQueue나 run_in_executor가 여전히 필요한가?

• 이전에는 임베딩이 CPU 바운드였기에 run_in_executor + 직렬 큐로 관리
• 이제는 네트워크 바운드 → 비동기 요청만으로 충분
• 동시 요청 과부하 방지를 위한 asyncio.Semaphore(max_concurrent) 정도만 고려

b. GPU 서버에서도 SerialTaskQueue나 스레드 분리가 필요한가?

• PyTorch는 단일 모델 기준으로는 GPU 연산을 병렬로 처리하지 않음
  • 따라서 동시에 요청이 들어와도 내부적으로 순차 처리됨
• GPU 사용량을 체크한 후, 오히려 병렬화가 필요할수도 있음

c. 임베딩 요청의 부하 관리는 CPU 서버가 할까, GPU 서버가 할까?

• CPU 서버에서 임베딩 요청을 제한하면 전체 처리량 저하
• 부하 관리는 GPU 서버가 책임져야 함
  • (예시) GPU 서버에서 요청 큐에 쌓고, 순차 처리
  • 혹은 Celery/Queue로 분산 처리 전략 도입

d. 멀티 프로세스/멀티 컨테이너는 무엇이 다르고, 언제 고려해야 하나?

구분	개념	특징
멀티 프로세스	독립된 프로세스들이 각자 모델 로드	안정적, 적절한 병렬화 가능
멀티 컨테이너	Docker 등으로 환경 완전 분리	가장 확장성 좋지만 설정 복잡

• T4 GPU 기준으로 단일 인스턴스 VRAM 점유량 측정 필요
• 실측 기반으로 인스턴스 수 조정 및 확장 전략 수립 가능

e. 기타 실무 고려 사항

• GPU 서버의 모델 로딩 및 추론 상태는 모니터링 가능해야 함
• 비정상 요청(잘못된 URL, timeout 등)에 대한 fallback 처리
• Redis 캐싱 위치: CPU 서버에서 응답 전에 캐시하는 방식 유지
• 추후 확장을 고려한 API 설계: /embed, /status, /batch_embed 등