프로덕션 환경에서 검색 기반 모델 배포를 위한 실용 가이드

Jina AI에서는 기업 사용자를 위한 고품질 검색 솔루션을 제공하는 것을 목표로 합니다. 이를 달성하기 위해 다양한 채널을 통해 모델에 접근할 수 있도록 하고 있습니다. 하지만 특정 사용 사례에 맞는 적절한 채널을 선택하는 것은 까다로울 수 있습니다. 이 글에서는 의사결정 과정을 안내하고 절충점을 분석하여, 사용자 프로필과 요구사항에 따라 검색 기반 모델에 접근하는 가장 좋은 방법에 대한 실용적인 지침을 제공하겠습니다.

tagJina 검색 기반 모델

Our Search Foundation Models

We've been moving the needle in search models since day one. Take a look at our model evolution below—hover or click to discover each milestone.

Jina AI

우리의 검색 기반 모델은 다음과 같습니다:

• Embeddings: 디지털 객체의 정보를 본질적 특성을 포착하는 임베딩 벡터로 변환합니다.
• Rerankers: 검색 관련성을 향상시키기 위해 쿼리-문서 세트의 심층 의미 분석을 수행합니다.
• Small language models: HTML2Markdown이나 정보 추출과 같은 틈새 작업을 위한 ReaderLM-v2와 같은 특수 SLM을 포함합니다.

이 글에서는 jina-embeddings-v3의 다양한 배포 옵션을 살펴보며, 세 가지 주요 접근 방식을 비교합니다:

• Jina API 사용
• AWS SageMaker와 같은 CSP를 통한 배포
• 상업용 라이선스로 Kubernetes 클러스터에 자체 호스팅

이 비교는 각 접근 방식의 비용 영향과 장점을 평가하여 귀하의 요구사항에 가장 적합한 옵션을 결정하는데 도움을 줄 것입니다.

tag주요 성능 지표

다양한 사용 시나리오에서 다섯 가지 주요 성능 지표를 평가했습니다:

• 요청 성공률: 임베딩 서버에 대한 성공적인 요청의 비율
• 요청 지연시간: 임베딩 서버가 요청을 처리하고 반환하는 데 걸리는 시간
• 토큰 처리량: 임베딩 서버가 초당 처리할 수 있는 토큰의 수
• 토큰당 비용: 텍스트 단위당 총 처리 비용

Kubernetes 클러스터에서 자체 호스팅되는 Jina 임베딩의 경우, 동적 배칭의 영향도 검토했습니다. 이 기능은 임베딩을 생성하기 전에 최대 배치 크기(jina-embeddings-v3의 경우 8,192)에 도달할 때까지 요청을 대기열에 넣습니다.

우리는 의도적으로 두 가지 중요한 성능 요소를 분석에서 제외했습니다:

• 자동 스케일링: 이는 가변 워크로드가 있는 클라우드 배포에 중요하지만, 그 효과는 하드웨어 효율성, 네트워크 아키텍처, 지연시간, 구현 선택과 같은 많은 변수에 따라 달라집니다. 이러한 복잡성은 현재 범위를 벗어납니다. Jina API에는 자동 스케일링이 포함되어 있으며, 우리의 결과는 이를 반영합니다.
• 양자화: 이 기술은 더 작은 임베딩 벡터를 생성하고 데이터 전송을 줄이지만, 주요 이점은 데이터 전송 감소보다는 다른 시스템 구성 요소(데이터 저장 및 벡터 거리 계산)에서 옵니다. 직접적인 모델 사용 비용에 초점을 맞추고 있기 때문에, 이 분석에서는 양자화를 제외했습니다.

마지막으로, 총소유비용과 토큰/요청당 비용을 모두 고려하여 각 접근 방식의 재무적 영향을 검토할 것입니다.

tag배포 설정

jina-embeddings-v3에 대해 세 가지 배포 및 사용 시나리오를 평가했습니다:

tagJina API 사용

모든 Jina AI 임베딩 모델은 Jina API를 통해 접근할 수 있습니다. 접근은 선불 토큰 시스템으로 작동하며, 테스트용으로 100만 토큰을 무료로 제공합니다. 독일 사무실에서 인터넷을 통한 API 호출로 성능을 평가했습니다.

tagAWS SageMaker 사용

Jina Embeddings v3는 AWS 사용자가 SageMaker를 통해 이용할 수 있습니다. 이 모델에 대한 AWS 구독이 필요합니다. 예제 코드로 AWS 계정으로 Jina AI 모델을 구독하고 사용하는 방법을 보여주는 노트북을 제공했습니다.

모델들은 Microsoft Azure와 Google Cloud Platform에서도 사용 가능하지만, 우리는 AWS에서 테스트를 집중적으로 진행했습니다. 다른 플랫폼에서도 비슷한 성능을 기대할 수 있습니다. 모든 테스트는 us-east-1 지역의 ml.g5.xlarge 인스턴스에서 실행되었습니다.

tagKubernetes에서 자체 호스팅

우리는 Python으로 FastAPI 애플리케이션을 구축하여 SentenceTransformer 라이브러리를 사용해 HuggingFace에서 jina-embeddings-v3를 로드합니다. 이 앱은 두 개의 엔드포인트를 포함합니다:

• /embed: 텍스트 구절을 입력으로 받아 임베딩을 반환
• /health: 기본적인 헬스 모니터링 제공

이를 us-east-1의 g5.xlarge 인스턴스를 사용하여 Amazon의 Elastic Kubernetes Service에 Kubernetes 서비스로 배포했습니다.

동적 배칭 사용 및 미사용

Kubernetes 클러스터에서 두 가지 구성으로 성능을 테스트했습니다: 요청을 받자마자 즉시 처리하는 구성과 동적 배칭을 사용하는 구성입니다. 동적 배칭의 경우, 서비스는 MAX_TOKENS(8192)가 대기열에 수집되거나 사전 정의된 2초 타임아웃에 도달할 때까지 기다린 후 모델을 호출하고 임베딩을 계산합니다. 이 접근 방식은 GPU 활용도를 높이고 GPU 메모리 단편화를 줄입니다.

각 배포 시나리오에 대해 세 가지 주요 매개변수를 변경하며 테스트를 실행했습니다:

• 배치 크기: 각 요청은 임베딩을 위해 1, 32, 또는 128개의 텍스트 구절을 포함
• 구절 길이: 128, 512, 또는 1,024 토큰을 포함하는 텍스트 구절 사용
• 동시 요청: 1, 5, 또는 10개의 요청을 동시에 전송

tag벤치마크 결과

아래 표는 위의 세 가지 변수의 모든 설정에 대한 평균을 나타낸 각 사용 시나리오의 결과 요약입니다.

tag요청 성공률

우리의 테스트에서 성공률은 SageMaker의 거의 완벽한 99.9%에서 자체 호스팅 솔루션의 56-58%까지 다양했으며, 이는 프로덕션 시스템에서 100% 신뢰성을 달성하기가 왜 어려운지를 보여줍니다. 세 가지 주요 요인이 이에 기여합니다:

• 네트워크 불안정성으로 인해 클라우드 환경에서도 피할 수 없는 실패가 발생
• 특히 GPU 메모리와 같은 리소스 경합으로 인해 부하 상태에서 요청 실패 발생
• 시스템 건강을 유지하기 위해 일부 요청은 필수 타임아웃 제한으로 인해 실패해야 함

tag배치 크기별 성공률

자체 호스팅 Kubernetes 구성에서는 큰 배치 크기로 인해 자주 메모리 부족 오류가 발생합니다. 동적 배칭 없이는 배치당 32개 또는 128개 항목을 포함하는 모든 요청이 이러한 이유로 실패했습니다. 동적 배칭을 구현했더라도 큰 배치에 대한 실패율은 여전히 상당히 높았습니다.

이 문제는 auto-scaling을 통해 쉽게 해결할 수 있지만，여기서는 그 옵션을 살펴보지 않기로 했습니다. auto-scaling은 예측할 수 없는 비용 증가를 초래할 수 있고，사용 가능한 수많은 auto-scaling 구성 옵션을 고려할 때 실행 가능한 인사이트를 제공하기가 어려울 것이기 때문입니다.

tag동시성 수준별 성공률

동시성 - 여러 요청을 동시에 처리하는 능력 - 은 자체 호스팅된 Kubernetes 구성에서 요청 성공률에 강력하거나 일관된 영향을 미치지 않았으며，AWS SageMaker에서도 동시성 수준이 10까지는 최소한의 영향만 있었습니다.

tag토큰 길이별 성공률

토큰 수가 많은 긴 문장은 Jina Embedding API와 동적 배치가 적용된 Kubernetes에 대해 큰 배치와 유사한 영향을 미칩니다：크기가 증가할수록 실패율이 상당히 증가합니다. 하지만 동적 배치가 없는 자체 호스팅 솔루션은 큰 배치에서 거의 항상 실패하는 반면，개별 긴 문장에서는 더 나은 성능을 보입니다. SageMaker의 경우，긴 문장 길이는 동시성과 배치 크기처럼 요청 성공률에 눈에 띄는 영향을 미치지 않았습니다.

tag요청 지연 시간

모든 지연 시간 테스트는 동시성 수준 1，5，10에서 5번씩 반복되었습니다. 응답 시간은 5번 시도의 평균값입니다. 요청 처리량은 초 단위 응답 시간의 역수에 동시성을 곱한 값입니다.

tagJina API

Jina API의 응답 시간은 주로 동시성 수준에 관계없이 배치 크기의 영향을 받습니다. 문장 길이도 성능에 영향을 미치지만，그 영향은 단순하지 않습니다. 일반적인 원칙으로，더 큰 배치 크기나 더 긴 문장으로 인해 더 많은 데이터를 포함하는 요청은 처리 시간이 더 오래 걸립니다.

동시성 1：

동시성 5:

동시성 10:

개별 요청(배치 크기 1)의 경우:

• 응답 시간은 패시지 길이에 관계없이 약 600-800ms로 비교적 안정적으로 유지됨
• 높은 동시성(5 또는 10개의 동시 요청)에서도 요청당 성능이 크게 저하되지 않음

더 큰 배치(32 및 128 항목)의 경우:

• 응답 시간이 상당히 증가하며, 배치 크기 128은 단일 요청보다 약 4-6배 더 오래 걸림
• 패시지 길이의 영향이 더 큰 배치에서 더 두드러짐
• 높은 동시성(10)과 큰 배치(128)에서는 이 조합이 상당히 긴 응답 시간을 초래하며, 가장 긴 패시지의 경우 거의 18초에 도달

처리량의 경우:

• 일반적으로 더 작은 배치가 동시 요청 실행 시 더 나은 처리량을 달성
• 동시성 10에서 배치 크기 1일 때 시스템은 초당 약 15개 요청의 최고 처리량을 달성
• 더 큰 배치는 지속적으로 더 낮은 처리량을 보이며, 여러 시나리오에서 초당 1개 미만의 요청으로 감소

tagAWS SageMaker

AWS SageMaker 테스트는 ml.g5.xlarge 인스턴스로 수행되었습니다.

동시성 1:

동시성 5:

동시성 10:

Jina API와의 주요 차이점:

• 기본 성능: SageMaker는 작은 요청(단일 항목, 짧은 패시지)에서 Jina의 700-800ms에 비해 약 200ms로 훨씬 빠름
• 확장성 동작:
  • 두 서비스 모두 더 큰 배치와 긴 패시지에서 속도가 저하됨
  • SageMaker는 큰 배치(128)와 긴 패시지(1024 토큰)에서 더 극적인 속도 저하를 보임
  • 높은 동시성(10)에서 최대 부하(배치 128, 1024 토큰)시 SageMaker는 ~26초, Jina는 ~18초 소요
• 동시성 영향:
  • 두 서비스 모두 처리량 면에서 증가된 동시성의 이점을 얻음
  • 두 서비스 모두 동시성 수준에서 유사한 처리량 패턴을 유지
  • SageMaker는 동시성 10에서 약간 더 높은 최대 처리량을 달성합니다 (17 req/s vs 15 req/s)

tag자체 호스팅 Kubernetes 클러스터

자체 호스팅 테스트는 g5.xlarge 인스턴스가 있는 Amazon의 Elastic Kubernetes Service에서 수행되었습니다.

동시성 1:

동시성 5:

동시성 10:

16,384 토큰 이상의 요청이 주어졌을 때, 우리의 자체 호스팅 설정은 일반적으로 메모리 부족 오류와 같은 서버 오류로 실패했습니다. 이는 동시성 수준과 관계없이 사실이었습니다. 따라서 그 이상의 데이터에 대한 테스트는 표시되지 않습니다.

높은 동시성은 응답 시간을 대체로 선형적으로 증가시켰습니다: 동시성 레벨 5는 1에 비해 약 5배, 레벨 10은 10배의 응답 시간이 걸렸습니다.

동적 배치는 작은 배치의 경우 응답 시간을 약 2초 정도 늦춥니다. 이는 배치 큐가 불완전한 배치를 처리하기 전에 2초를 기다리기 때문에 예상된 결과입니다. 그러나 더 큰 배치 크기의 경우에는 응답 시간에서 적당한 개선을 가져옵니다.

tag토큰 처리량

토큰 처리량은 모든 플랫폼에서 더 큰 배치 크기, 더 긴 패시지 길이, 그리고 더 높은 동시성 레벨에서 증가합니다. 따라서 실제 성능을 의미 있게 나타내지 않을 낮은 레벨의 결과는 제외하고 높은 사용량 레벨의 결과만 제시하겠습니다.

모든 테스트는 동시성 레벨 10에서 요청당 16,384 토큰으로 수행되었으며, 5개의 요청에 대한 평균을 측정했습니다. 512 토큰 패시지가 있는 배치 크기 32와 128 토큰 패시지가 있는 배치 크기 128, 두 가지 구성을 테스트했습니다. 총 토큰 수는 두 구성에서 동일하게 유지됩니다.

토큰 처리량 (초당 토큰):

높은 부하 조건에서 Jina API는 대안들보다 상당히 우수한 성능을 보여주는 반면, 여기서 테스트된 자체 호스팅 솔루션들은 현저히 낮은 성능을 보여줍니다.

tag백만 토큰당 비용

비용은 임베딩 솔루션을 선택할 때 가장 중요한 요소라고 할 수 있습니다. AI 모델 비용 계산이 복잡할 수 있지만, 다음은 다양한 옵션에 대한 비교 분석입니다:

tagJina API

이 서비스는 두 가지 선불 티어가 있는 토큰 기반 가격 모델을 따릅니다:

• 10억 토큰당 $20 (백만 당$0.02) - 프로토타이핑과 개발에 이상적인 시작 요금
• 110억 토큰당 $200 (백만 당$0.018) - 대용량에 더 경제적인 요금

이 토큰들은 리더, 리랭커, 제로샷 분류기를 포함한 Jina의 전체 제품군에서 사용할 수 있다는 점을 주목할 만합니다.

tagAWS SageMaker

SageMaker 가격은 시간당 인스턴스 비용과 모델 라이선스 비용을 결합합니다. ml.g5.xlarge 인스턴스 사용 시:

• 인스턴스 비용: $1.408/시간 (미국 동부) 또는$1.761/시간 (EU 프랑크푸르트)
• jina-embeddings-v3 라이선스: $2.50/시간
• 총 시간당 비용: 지역에 따라 $3.908-$4.261

평균 처리량 15,044 토큰/초(54.16M 토큰/시간)로 백만 토큰당 비용은 $0.0723에서$0.0788 사이입니다.

tagKubernetes를 통한 자체 호스팅

자체 호스팅 비용은 인프라 선택에 따라 크게 달라집니다. AWS EC2의 g5.xlarge 인스턴스를 기준으로:

• 인스턴스 비용: $1.006/시간 (미국 동부) 또는$1.258/시간 (EU 프랑크푸르트)
• jina-embeddings-v3 라이선스: 분기당 $5000 ($2.282/시간)
• 총 시간당 비용: 지역에 따라 $3.288-$3.540

2,588 토큰/초(9.32M 토큰/시간)의 처리량으로 백만 토큰당 비용은 $0.352-$0.379입니다. 시간당 비용은 SageMaker보다 낮지만, 낮은 처리량으로 인해 토큰당 비용이 더 높습니다.

자체 호스팅 시 중요한 고려사항:

• 고정 비용(라이선싱, 인프라)은 사용량과 관계없이 지속됨
• 온프레미스 호스팅도 라이선스 비용과 인력 비용이 필요
• 가변적인 워크로드가 비용 효율성에 크게 영향을 미칠 수 있음

tag주요 시사점

Jina API는 콜드 스타트 시간을 고려하지 않고 대안들의 최적 처리량을 가정하더라도 가장 비용 효율적인 솔루션으로 부각됩니다.

기존에 탄탄한 인프라를 보유하고 있어 서버 한계 비용이 미미한 조직의 경우 자체 호스팅이 적합할 수 있습니다. 또한 AWS 외의 클라우드 제공업체를 탐색하면 더 나은 가격을 얻을 수 있습니다.

하지만 대부분의 기업, 특히 턴키 솔루션을 찾는 중소기업의 경우 Jina API가 비교할 수 없는 비용 효율성을 제공합니다.

tag보안 및 데이터 프라이버시 고려사항

임베딩 모델의 배포 전략을 선택할 때, 성능과 비용 고려사항 외에도 보안 및 데이터 프라이버시 요구사항이 결정적인 역할을 할 수 있습니다. 우리는 다양한 보안 요구사항에 맞는 유연한 배포 옵션을 제공합니다:

tag클라우드 서비스 제공업체

주요 클라우드 제공업체와 이미 협업 중인 기업의 경우, 우리의 클라우드 마켓플레이스 제품(AWS Marketplace, Azure, GCP)은 기존 보안 프레임워크 내에서 배포할 수 있는 자연스러운 솔루션을 제공합니다. 이러한 배포의 장점:

• CSP 관계에서 상속된 보안 통제 및 컴플라이언스
• 기존 보안 정책 및 데이터 거버넌스 규칙과의 손쉬운 통합
• 기존 데이터 처리 계약의 변경이 거의 또는 전혀 필요 없음
• 기존 데이터 주권 고려사항과의 정렬

tag자체 호스팅 및 로컬 배포

엄격한 보안 요구사항이나 특정 규제 의무가 있는 조직은 종종 인프라에 대한 완전한 물리적 통제를 선호합니다. 우리의 자체 호스팅 옵션은 다음을 가능하게 합니다:

• 배포 환경에 대한 완전한 통제
• 보안 경계 내에서의 데이터 처리
• 기존 보안 모니터링 및 통제와의 통합

CC-BY-NC 모델에 대한 상업적 라이선스를 얻으려면 먼저 우리로부터 라이선스를 받아야 합니다. 영업팀에 문의해 주시기 바랍니다.

tagJina API 서비스

스타트업과 중소기업이 운영 오버헤드 없이 보안과 편의성을 비용과 균형 잡으려 할 때, 우리의 API 서비스는 엔터프라이즈급 보안을 제공합니다:

• 강력한 보안 통제를 보장하는 SOC2 인증
• 데이터 처리에 대한 완전한 GDPR 준수
• 제로 데이터 보존 정책 - 요청을 저장하거나 로깅하지 않음
• 암호화된 데이터 전송 및 안전한 인프라

Jina AI의 모델 제품은 조직이 운영 효율성을 유지하면서 보안 요구사항에 가장 잘 부합하는 배포 전략을 선택할 수 있게 합니다.

tag솔루션 선택하기

아래 순서도는 지금까지 보신 모든 실증적 테스트와 표의 결과를 요약합니다:

먼저, 보안 요구사항과 이를 충족하기 위해 얼마나 유연성을 희생할 수 있는지 고려하세요.

그다음, 기업에서 AI를 어떻게 활용할 계획인지 고려하세요:

1. 배치 처리를 최적으로 활용할 수 있는 오프라인 인덱싱 및 시간에 민감하지 않은 사용 사례
2. 검색 증강 생성 및 LLM 통합과 같은 신뢰성과 확장성에 민감한 사용
3. 온라인 검색 및 검색과 같은 시간에 민감한 사용

또한, 사내 전문성과 기존 인프라를 고려하세요:

1. 기술 스택이 이미 클라우드에 크게 의존하고 있나요?
2. 자체 호스팅이 가능한 대규모 사내 IT 운영이 있나요?

마지막으로, 예상 데이터 양을 고려하세요. AI 모델을 사용하여 매일 수백만 건의 작업을 수행할 것으로 예상되는 대규모 사용자인가요?

tag결론

많은 IT 부서에서 AI를 운영 결정에 통합하는 것은 시장에 확립된 턴키 솔루션이 부족하여 여전히 미개척 영역으로 남아있습니다. 이러한 불확실성은 전략적 계획을 어렵게 만들 수 있습니다. 우리의 정량적 분석은 귀사의 특정 워크플로우와 애플리케이션에 우리의 검색 기반 모델을 통합하는 데 있어 구체적인 지침을 제공하는 것을 목표로 합니다.

단위당 비용 측면에서 Jina API는 기업이 이용할 수 있는 가장 경제적인 옵션 중 하나로 부각됩니다. 비교할만한 기능을 제공하면서 우리의 가격대를 맞출 수 있는 대안은 거의 없습니다.

우리는 강력하고 사용자 친화적일 뿐만 아니라 모든 규모의 조직에 비용 효율적인 검색 기능을 제공하기 위해 노력하고 있습니다. 주요 클라우드 제공업체를 통해서든 자체 호스팅 배포를 통해서든, 우리의 솔루션은 순수한 비용 고려사항을 넘어서는 가장 복잡한 기업 요구사항도 수용합니다. 이 분석은 의사 결정에 도움이 되도록 다양한 비용 요소를 분석합니다.

각 조직마다 고유한 요구사항이 있다는 점을 인식하여, 하나의 글로 모든 시나리오를 다룰 수 없다는 것을 알고 있습니다. 여기서 다루지 않은 특정 요구사항이 있다면, 귀사의 구현을 어떻게 가장 잘 지원할 수 있는지 논의하기 위해 연락 주시기 바랍니다.