Michael Johnson두 서비스가 모델에 같은 수의 요청을 보내더라도 부하 양상은 크게 다를 수 있습니다. 10월 9일 공개된 Cohere의 Embed·Rerank 가이드는 요청 형태, 부하 일정, 지연 시간 요구사항에 따라 공유 처리와 전용 처리 중 하나를 선택하도록 안내합니다. 이는 인프라에 관한 실무 분석이며, 새로운 요금제나 제품 발표는 아닙니다.
검색 및 RAG를 구축하는 팀에게 이 분석은 인덱싱과 사용자 요청을 계획할 때 중요합니다. 호출 횟수만으로는 계산 작업량을 제대로 나타내기 어렵기 때문입니다. 임베딩을 위한 문서 배치 하나가 수많은 짧은 검색 요청보다 더 많은 리소스를 사용할 수 있습니다.
분당 요청 수가 오해를 부르는 이유
임베딩은 텍스트를 수치 표현으로 변환하며, 검색 시스템은 이를 의미 기반 매칭에 활용합니다. 카탈로그를 처음 인덱싱할 때는 애플리케이션이 설명문을 큰 배치로 보낼 수 있지만, 일반 검색에서는 모델이 짧은 질의 텍스트를 받습니다. 두 작업의 요구사항은 다릅니다. 배치 처리는 보통 처리량과 비용을 기준으로 평가하는 반면, 검색은 사용자에게 응답을 돌려주는 시간을 중시합니다.
Rerank에서는 시스템이 재정렬을 위해 모델에 넘기는 후보의 수도 중요합니다. Cohere의 예에서는 짧은 질의를 문서 50개와 비교하며, 회사는 이 처리량을 약 1만 1,000토큰으로 추산합니다. 사용자 검색 빈도가 그대로여도 후보 수가 늘면 작업량은 증가합니다.
Cohere의 계산이 보여주는 것
이 글은 사용량 기반 과금에서 전용 용량으로 전환할 때 비용상 유리해지는 대략적인 지점을 제시합니다. 토큰 약 200개 분량의 텍스트 100개를 배치 인덱싱하는 경우 분당 약 20건, 더 긴 문서의 경우 약 4건, 제시된 Rerank 시나리오에서는 약 29건입니다. 짧은 검색용 임베딩의 손익분기점은 분당 수만 건으로 추산합니다.
이 수치는 구체적인 가정을 바탕으로 계산됐습니다. NVIDIA A10 전용 GPU 한 대를 24시간 내내 최대 용량으로 가동하고, 제시된 요청 크기와 공개된 요금을 적용한 경우입니다. Cohere는 가동 시간, 하드웨어 구성, 할인, 문서량이 달라지면 그래프와 기준점도 달라진다고 별도로 설명합니다. 따라서 이를 보편적인 기준이 아니라 계산 방법을 보여주는 사례로 보는 편이 좋습니다.
다만 선택 논리는 특정 사례를 넘어 폭넓게 적용할 수 있습니다. 예측 가능한 지속적 부하는 예약된 용량을 더 효율적으로 활용할 수 있고, 긴 유휴 시간 사이에 짧은 급증이 발생하는 경우에는 실제 사용량 기반 과금이 더 적합한 경우가 많습니다. 대화형 검색에서는 예상 부하에서의 지연 시간도 확인해야 합니다. 장비의 최대 처리량이 운영 환경에서 필요한 응답 시간을 보장하지는 않습니다.
이 분석을 자체 검색 시스템에 적용하는 법
선택지를 비교하기 전에 실제 트래픽에서 몇 가지를 측정하세요. 요청당 토큰과 문서 수, 인덱싱 배치 크기, 재정렬할 후보 수, 부하가 집중되는 시간, 목표 지연 시간입니다. 그런 다음 평균 요청 수만이 아니라 실제 부하 일정에 따른 비용을 계산하세요. 전체 그림을 파악하려면 현재 요금과 배포 조건을 Cohere 요금 페이지에서 확인하세요. 전용 모델과 사용량 기반 처리에는 서로 다른 요금이 적용됩니다.
혼합형 검색에서는 카탈로그의 백그라운드 재인덱싱, 짧은 사용자 질의, 후보 재정렬을 각각 따로 평가하는 것이 합리적입니다. 이렇게 계산하면 단일 인프라가 적절한지, 아니면 파이프라인의 단계별로 서로 다른 배포 방식을 쓰는 편이 유리한지 확인할 수 있습니다. Cohere가 공개한 분석의 실무적 결론은 간단합니다. 먼저 각 요청이 발생시키는 작업량을 측정한 뒤, 과금 방식과 리소스 할당 방식을 선택하세요.