Qwen3 RAG 비용 계산: 임베딩과 재순위화 후보 예산

고객 지원 지식베이스를 검색하는 RAG 시스템에서는 벡터 인덱스 크기보다 재순위화할 후보 문단 수가 비용에 더 큰 영향을 줄 수 있습니다. 아래 예산 예시에서 후보를 20개에서 100개로 늘리면 재순위화 입력량이 다섯 배가 됩니다. 결과를 다섯 개만 반환하도록 요청했다고 해서 다섯 문단만 평가했다는 뜻은 아닙니다.

이 가이드는 Orux의 qwen3-embedding-8b, qwen3-reranker-8b 현재 가격과 오프라인 Python 계산기를 제공합니다. 초기 후보 예산을 정하고 다음에 무엇을 측정할지 판단하기 위한 자료입니다. 산술 계산은 로컬에서 실행했지만, 이 글을 위해 새 모델 요청이나 검색 벤치마크를 수행하지는 않았습니다. 모든 처리량은 명시적 가정이며 독자의 애플리케이션을 측정한 결과가 아닙니다.

인덱싱, 질의 임베딩, 재순위화를 구분하세요

임베딩 모델은 텍스트를 비교 가능한 벡터로 바꿉니다. 재순위화 모델은 질의와 후보 문서의 관련성을 평가합니다. 변경되지 않은 문서는 보통 인덱스를 만들 때 한 번 임베딩하지만, 재순위화는 질의가 도착하고 후보를 고른 뒤 수행합니다. 원본 모델 설명은 Qwen 임베딩 모델 카드와 Qwen 재순위화 모델 카드를 참고하세요.

예산에는 인덱싱·갱신 때 임베딩한 문서 토큰, 검색 때 임베딩한 질의 토큰, 재순위화에서 평가한 질의·문서 토큰을 따로 집계하세요. 실제로 매 검색마다 전체 문서를 보내는 구현이 아니라면 전체 코퍼스에 월간 검색 수를 곱하면 안 됩니다. 반대로 문서 쌍 기준의 재순위화 추정에서는 질의를 한 번만 계산해서도 안 됩니다. 같은 질의가 각 후보 문서와 짝을 이루기 때문입니다.

답변을 작성하는 언어 모델은 네 번째 비용 항목입니다. 벡터 저장소, 검색 인프라, 네트워크 트래픽, 해당 세금도 계산에서 제외합니다. 비용을 분리하면 예상 밖 청구서를 조사할 때 모든 비용을 답변 모델 탓으로 돌리지 않아도 됩니다.

현재 가격: 같은 단위로 비교하기

아래는 2026년 10월 30일 확인한 Orux 공개 입력 가격입니다. 서비스 판매 가격이며 원 제작사의 공식 호스팅 API 가격이나 모델 품질 비교가 아닙니다. 1 Credit은 약 $0.005입니다. 0이라는 표시는 현재 설정 가격을 뜻하며 영구 무료, 무제한 용량, 향후 요청 성공을 약속하지 않습니다.

좌우로 밀어 전체 표를 확인하세요.

대안 모델 페이지는 bge-m3, bge-reranker-v2-m3입니다. 현재 0 가격은 제공 조건을 살펴볼 이유이지 관련성, 지연 시간, 언어 요구 사항을 충족한다는 증거가 아닙니다. 서비스에 의존하기 전에 접근 조건, 제한, 최신 견적을 확인하세요.

관련 글인 LLM 요청 비용 비교는 답변 생성이라는 다른 단계를 다룹니다. DeepSeek API 가격 가이드 역시 벡터 검색이 아닌 텍스트 생성에 관한 글입니다. 어느 것도 재순위화 가격표 대신 사용할 수 없습니다.

고객 지원 검색 예산 예시

지식베이스에 문단이 10,000개 있고 각 문단이 400토큰이라고 가정합니다. 첫 집계 기간에 검색 10,000건이 발생하며 질의 평균 길이는 40토큰입니다. 검색마다 후보 20개, 50개, 100개를 재순위화하는 경우를 비교합니다. 토큰 길이는 계획 입력값입니다. 언어, 토크나이저, 형식, 문서 구성에 따라 실제 사용량은 달라집니다.

초기 인덱싱은 10,000 × 400 = 4,000,000토큰, Qwen 임베딩 가격으로 46.6668 Credits입니다. 질의 임베딩은 10,000 × 40 = 400,000토큰, 4.66668 Credits입니다. 두 단계의 합계는 51.33348 Credits입니다. 여기서 인덱싱은 일회성 항목으로, 변경 없는 코퍼스에 반복 부과하는 비용이 아닙니다.

재순위화 추정식은 검색 수 × 후보 수 × (문서 토큰 + 질의 토큰)입니다. 후보 20개라면 10,000 × 20 × 440 = 88,000,000 입력 토큰이며, 88 × 11.6667 = 1,026.6696 Credits입니다. 이는 처리량 추정치일 뿐 실제 사용량이나 정산 기록을 대체하지 않으며 모델별 형식 오버헤드도 제외합니다.

좌우로 밀어 전체 표를 확인하세요.

합계는 초기 인덱싱, 질의 임베딩, 재순위화를 포함하지만 답변 생성은 제외합니다. 다음 기간에 인덱스가 같다면 46.6668 Credits를 빼세요. 일부를 갱신했다면 실제 재임베딩 토큰 비용으로 바꾸세요. 이 표를 지연 시간이나 정확도 실험 결과로 제시해서는 안 됩니다.

이 가정에서 후보를 20개에서 50개로 늘리면 재순위화 비용은 2.5배, 100개로 늘리면 다섯 배입니다. 처리량 공식에서 나온 비율이며 모델 품질이 그만큼 좋아진다는 주장이 아닙니다. 도표는 편집용 계산 자료이지 모델 생성 결과가 아닙니다.

API 키 없이 계산기 실행하기

아래 코드를 budget.py로 저장하고 python3 budget.py를 실행하세요. Python 표준 라이브러리만 사용하고 네트워크 요청은 보내지 않습니다. Decimal 연산으로 금액을 이진 부동소수점으로 변환하지 않고 공개 요율을 유지합니다. 다른 시점이나 앱에 적용하기 전 가격과 처리량 입력값을 바꾸세요.

"""Scenario calculator, not a tokenizer or a measured API bill. No network calls."""
from decimal import Decimal
RATE = Decimal('11.6667')  # Credits per 1M input tokens, checked 2026-10-30
USD_PER_CREDIT = Decimal('0.005')
QUERIES, CHUNKS, DOCUMENT_TOKENS, QUERY_TOKENS = 10000, 10000, 400, 40

def credits(tokens):
    return Decimal(tokens) * RATE / Decimal(1000000)

def scenario(candidates):
    index_tokens = CHUNKS * DOCUMENT_TOKENS
    query_tokens = QUERIES * QUERY_TOKENS
    pair_tokens = QUERIES * candidates * (DOCUMENT_TOKENS + QUERY_TOKENS)
    rerank = credits(pair_tokens)
    total = credits(index_tokens + query_tokens) + rerank
    return pair_tokens, rerank, total, total * USD_PER_CREDIT

if __name__ == '__main__':
    assert credits(4000000) == Decimal('46.6668')
    assert scenario(20)[1] == Decimal('1026.6696')
    assert scenario(50)[1] / scenario(20)[1] == Decimal('2.5')
    assert scenario(100)[1] / scenario(20)[1] == Decimal('5')
    print('k | rerank tokens | rerank Credits | first-period Credits | USD equivalent')
    for k in (20, 50, 100):
        print(k, *scenario(k), sep=' | ')

assert는 인덱싱 계산과 두 후보 수 비율을 검사하며, 출력값은 위 표를 재현합니다. 이는 계산기 검증이지 모델 품질이나 호스팅 요청이 보고할 정확한 토큰 수의 검증은 아닙니다. 실제 연동 후에는 첫 사용 기록과 비교해 가정한 평균 문서·질의 길이를 교체하는 것이 좋습니다.

후보 수와 반환 결과 수는 다릅니다

현재 Orux 재순위화 폼의 관련 입력은 query, documents, 선택 항목인 top_n입니다. documents 배열이 평가할 문단을 결정합니다. top_n은 반환을 원하는 결과 수이며, 비용 제어를 위해 입력 배열을 줄이는 일을 대신하지 않습니다. 20개와 100개의 예산을 비교하려면 실제로 두 후보 집합을 따로 준비하세요.

임베딩 요청은 input과 현재 노출된 encoding_format: "float"를 사용합니다. 원본 모델의 옵션과 호스팅 폼은 서로 다른 인터페이스 계약입니다. 모델 카드의 모든 기능이 Orux 요청 파라미터로 노출됐다고 추정하지 마세요. 정확한 모델 별칭과 현재 입력 폼을 연동 전에 확인하세요.

예를 들어 “청구서 이메일은 어떻게 바꾸나요?”라는 질문이라면 사용이 승인된 자체 문서에서 후보를 먼저 검색하고 그 문단만 재순위화에 보내세요. 텍스트와 문서 ID를 함께 보관해 반환 인덱스나 결과를 출처에 연결하세요. 점수는 관련성 신호이며 문서가 최신인지, 사용자에게 열람 권한이 있는지, 답변에 충분한지를 보증하지 않습니다.

필요한 근거를 유지하는 가장 작은 후보 집합 선택하기

후보에 들어오지 않은 관련 문단은 재순위화 모델이 되찾을 수 없습니다. 따라서 후보 축소가 항상 최적화는 아닙니다. 정확한 제품명, 모호한 표현, 최근 정책 변경, 유효한 답변이 없는 질문을 포함한 대표 고객 지원 질문에 정답 라벨을 만드세요. 비교 전에 올바른 답변에 필요한 출처 문단을 기록합니다.

각 후보 예산에서 필요한 문단이 재순위화 전에 검색됐는지, 처리 후 어느 순위인지, 답변 단계에 충분한 근거가 전달되는지 측정하세요. 지연 시간과 청구 사용량은 별도로 기록합니다. 재순위화 전부터 문단이 빠졌다면 검색과 문서 준비를 조사하세요. 더 크거나 비싼 모델도 받지 못한 문서를 평가할 수 없습니다.

20·50·100개를 비교할 때 평가 세트와 문서 스냅샷을 고정하세요. 그렇지 않으면 코퍼스 갱신을 모델 개선으로 오해할 수 있습니다. 이 글에는 모든 상황에 맞는 후보 수가 없습니다. 측정한 근거 포함률과 사용자 경험이 허용 범위일 때만 저렴한 설정을 유지하세요. 문서 길이, 트래픽 구성, 가격이 크게 바뀌면 다시 점검합니다.

자주 묻는 질문

Q.첫 기간 합계가 보장되는 API 청구액인가요?

아닙니다. 명시한 처리량과 가격 시점에 따른 추정치입니다. 형식 오버헤드, 실제 토큰화 차이, 답변 생성, 인프라는 제외합니다. 후보 예산을 일관되게 비교하는 데 쓰고, 예측값으로 삼기 전에 실제 요청의 사용량·청구 기록과 대조하세요.

Q.top_n을 5로 설정하면 후보 5개와 비용이 같나요?

그렇게 가정하지 마세요. 요청에는 평가하려고 제출한 모든 문서가 여전히 들어 있습니다. 입력 후보 수와 반환 결과 수를 구분하세요. 후보 감소의 예산 효과를 시험하려면 documents 배열을 줄이고 중요한 근거가 남아 있는지 확인해야 합니다.

Q.변경 없는 문서도 매 질의마다 임베딩하나요?

여기서 설명한 인덱스 기반 흐름에서는 아닙니다. 문서 임베딩을 저장하고 내용이나 임베딩 설정이 바뀔 때까지 재사용합니다. 질의 임베딩은 별도 단계입니다. 전체 코퍼스에 검색 수를 곱하지 말고 추가, 편집, 의도적인 인덱스 재생성을 계산하세요.

Q.BGE 가격이 0이면 가장 좋은 선택인가요?

아닙니다. 확인 날짜의 가격 관찰값일 뿐입니다. 검색 품질, 접근 조건, 지연 시간, 향후 가격에 관한 보장은 없습니다. 운영에 도입하기 전에 대표 질문으로 평가하고 실시간 모델 페이지를 확인하세요.

Q.계산기가 모델을 호출하거나 Credits를 쓰나요?

아닙니다. Python 표준 라이브러리로 로컬 산술을 수행하며 API 키나 네트워크 요청이 없습니다. 예산 관계를 보여줄 뿐 임베딩이나 관련성 점수를 만들지 않습니다. 이후 호스팅 모델을 호출하는 통합 테스트는 별도 작업으로 당시 가격과 제한을 따라야 합니다.

가격 확인일: 2026-10-30. 출처: Orux Qwen 임베딩, Orux Qwen 재순위화, Orux BGE 임베딩, Orux BGE 재순위화, 위의 Qwen 모델 카드 두 개.