이미지 임베딩 CLIP 모델 선정 이유 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki
1. 비교 요약
항목 | CLIP | RAM++ |
---|---|---|
모델 구조 | 이미지-텍스트 멀티모달 임베딩 | 고정된 태그 기반 멀티라벨 분류 |
태스크 확장성 | 임베딩 유사도 기반 비교, 검색, 정렬 등 다양한 태스크에 활용 가능 | 고정된 태그셋 분류에 최적화됨 |
유사도 기반 처리 | 가능 (코사인 유사도 등 계산 지원) | 불가능 (태그 분류만 수행) |
평균 추론 속도 | ✅ GPU: 0.0096초/장, CPU: 0.045초/장 | ❌ GPU: 0.075초/장, CPU: 1.5초/장 |
CPU 사용률 | ✅ 4코어 기준 100% × 4 부하, 짧은 시간 집중적 사용 → 서버 자원 효율적 | ❌ 처리시간이 길어 지속적 고부하, 멀티코어 활용률 낮음 |
2. 선정 이유
a. 태그셋을 자유롭게 설계 가능 → 다양한 카테고리로 분류할 수 있음
-
CLIP은
"a photo of {tag}"
형식의 텍스트 쿼리로 원하는 태그셋을 직접 설계 가능 -
RAM++는 태그셋이 고정되어 있어 사용자가 원하는 태그로 확장/수정 불가
-
성능 비교 테스트 결과 요약
항목 CLIP RAM++ 총 처리 시간 ✅ GPU: 0.96초, CPU: 4.49초 (100장 기준)→ CPU에서도 5초 내외 처리 가능 ❗ GPU: 7.5초, CPU: 149.9초→ CPU는 실시간 처리 불가 수준 평균 추론 속도 ✅ GPU: 0.0096초/장, CPU: 0.045초/장 ❌ GPU: 0.075초/장, CPU: 1.5초/장 GPU 메모리 사용량 ✅ ~400MB, 경량 모델로 모바일·저사양 환경도 가능 ❗ 최대 5.6GB, Swin-L 백본으로 고사양 GPU 요구 CPU 사용률 ✅ 4코어 기준 100% × 4 부하, 짧은 시간 집중적 사용 → 서버 자원 효율적 ❌ 처리시간이 길어 지속적 고부하, 멀티코어 활용률 낮음 -
CLIP은 GPU 환경에서 최적이지만,
CPU 환경에서도 실시간 처리(100장에 약 4.5초) 수준의 속도를 보여줌 ✅
-
RAM++는 정확도는 높지만 CPU에서의 서빙은 사실상 불가능
→ GPU에서도 자원 소모가 큼 (메모리, 시간)
-
b. CPU 환경에서도 사용 가능
- CLIP은 CPU 환경에서도 추론 속도가 빠르고, 배치 최적화 시 실시간 대응 가능
- RAM++는 Swin-L 기반 구조로 인해 T4 GPU 이상에서만 원활하게 동작
c. 서비스 구조와의 자연스러운 연계
- 우리 서비스는 추론 기반 단건 처리보다 임베딩 재활용이 핵심
- CLIP은 임베딩을 한번 생성하면 다양한 기능(유사도, 분류, 클러스터링)에 재사용할 수 있어 성능 최적화 및 시스템 효율화에 유리