1. 테스트 개요

a. 목표

• 이미지 임베딩 파이프라인에서 병목이 GPU 추론인지, 이미지 로딩 및 전처리인지를 구분하기 위한 실험을 수행

b. 왜 이 테스트가 필요한가?

목적	설명
병목 위치 명확화	추론을 제거했을 때도 latency가 유지되면, 병목은 전처리 또는 로딩 단계에 있다는 증거가 된다
멀티 스트림 전략의 유효성 검증	스트림 수를 늘리는 것이 병렬 처리에 도움이 되는지 실측을 통해 확인
추후 최적화 방향 결정	CPU 기반 병목이면 전처리 최적화나 Gunicorn 병렬 구조가 필요하고, GPU 병목이면 배치 최적화나 모델 경량화가 우선됨

---

2. 테스트를 위해 변경한 코드 요약

• 추론을 제거하고 dummy 텐서 반환

  with torch.no_grad():
      # batch_features = model.encode_image(image_input)
      batch_features = torch.zeros((len(batch_filenames), 512))
  

---

3. 테스트 시나리오

• 부하 도구: k6
• 사용자 시뮬레이션: 동시 사용자(VU) 최대 30명
• 실행 시간: 3분간 유지
• 요청 주기: 각 사용자는 응답 수신 후 3~5초 랜덤 휴식
• 요청 데이터: 30~50장의 이미지 리스트 포함된 embedding 요청

---

4. 테스트 결과

항목	스트림 1 (세마포어 4)	스트림 4 (세마포어 8)
embedding_duration (avg)	2048 ms	3284 ms ❗
http_req_duration (avg)	2.04 s	3.28 s ❗
http_req_duration (max)	7.74 s	39.65 s ❗
iteration_duration (avg)	6.05 s	7.25 s
GPU 사용률	거의 0% (추론 제거됨)	거의 0%
CPU 사용률	90% 이상 (전처리 포화)	90% 이상 (전처리 포화)

a. 해석

• 추론 제거 후에도 평균 latency는 여전히 2~3초 수준 → 병목은 GPU가 아님

• 스트림 수 증가로 latency가 오히려 악화됨

  → CPU 병목 상태에서 동시에 많은 요청을 처리하면서 전처리 경합 발생

• 최대 응답 시간이 39초까지 발생한 점은 동시성 증가로 인한 tail latency 폭증을 의미

b. 결론

• GPU 추론은 병목이 아니며, 현재 구조의 병목은 이미지 로딩과 전처리 (CPU-bound)
• 현재 상태로 멀티 스트림 전략은 CPU 병목 환경에서 효과 없으며, 오히려 latency를 악화시킬 수 있음