Embeddings 가격 계산기

OpenAI / Voyage / Cohere / Gemini / Mistral / Together 등 15개 이상의 Embedding 모델에 대해 초기 인덱스 구축 비용 및 월간 쿼리 비용을 계산합니다. 차원 수, 최대 토큰, MRL (Matryoshka Representation Learning) 지원 여부도 목록으로 제공합니다.

완전 무료 가입 불필요 브라우저 완결 5 개 언어 다크 모드

⚠ 2026-04 시점 가격 OpenAI · Voyage · Cohere · Google

관련: 🪓 RAG 청커 · 🪙 LLM 토큰

📚 인덱스 구축

문서 수 평균 토큰

🔍 쿼리

월 쿼리 평균 토큰

📊 통계

인덱스

0 tokens

월 쿼리

0 tokens

모델	차원	Max tok	$/MT	인덱스	월 쿼리	합계	MRL

※ 가격은 2026-04 기준입니다. MRL = Matryoshka Representation Learning (차원을 나중에 축소 가능).

📖 자주 걸리는 지점

문서량과 모델을 지정해 Embedding 의 초기 구축 비용과 매월 검색 비용을 추정합니다. 처리는 브라우저 안에서 끝납니다. 여기 나오는 것은 API 요금뿐입니다 — 실제 RAG 의 총비용에는 벡터 데이터베이스의 월액, 다시 임베딩하는(재인덱싱) 비용, 그리고 검색 결과를 LLM 에 넘기는 추론 비용이 얹힙니다. 많은 구성에서 마지막 추론 비용이 Embedding 의 수십 배가 됩니다.

사례	무슨 일이 일어나는가	어떻게 하면 되는가
초기 구축 비용만 보고 정한다	문서 10만 건의 임베딩이 몇 달러로 끝난다는 것을 알면 안심하게 되지만 그 숫자는 한 번뿐입니다. 실제로 쌓이는 것은 문서가 갱신될 때마다의 재임베딩과 검색 쿼리마다의 임베딩입니다. 하루 1만 쿼리라면 월 30만 회분의 쿼리 임베딩이 상시 발생합니다.	초기 × 1회, 갱신분 × 빈도, 쿼리 × 월간 횟수 세 가지를 나누어 더하세요. 쿼리 임베딩은 1건당 수십 토큰으로 작으므로 저렴한 모델을 나눠 쓰는 선택지도 보이지만, 문서 쪽과 쿼리 쪽은 같은 모델이어야 합니다 — 벡터 공간이 다르면 거리가 의미를 갖지 않습니다. 같은 모델 안에서 차원 축소 옵션이 있다면 그쪽이 실용적입니다.
차원 수가 큰 모델을 고른다	차원 수는 그대로 벡터 데이터베이스의 저장 용량과 메모리 사용량에 영향을 줍니다. 3072 차원을 float32 로 가지면 1 벡터당 12KB, 100만 건이면 12GB 입니다. 1536 차원이면 절반, 768 차원이면 4분의 1이 됩니다. API 요금보다 이 저장 쪽 비용이 나중에 더 크게 다가오는 경우가 흔합니다. 검색 속도도 차원 수에 비례해 느려집니다.	먼저 작은 차원으로 만들어 정확도를 재고, 부족하면 올리세요. 많은 용도에서는 768~1024 차원으로 충분합니다. 차원 축소에 대응한 모델이라면 같은 모델 그대로 출력 차원을 낮출 수 있어 다시 만드는 되돌림이 작게 끝납니다. 저장 용량이 문제가 되는 규모에서는 float32 를 int8 로 양자화하면 4분의 1이 되고 정확도 저하는 몇 퍼센트에 그치는 경우가 많다는 선택지도 있습니다.
모델을 갈아탈 때의 비용을 안 본다	임베딩 모델을 바꾸면 기존 벡터는 전부 무효가 됩니다. 벡터 공간이 다르므로 신구를 섞어 거리를 재는 것은 원리적으로 불가능합니다. 즉 전 문서의 재임베딩이 필수이고 초기 구축과 같은 금액이 한 번 더 듭니다. 모델의 세대교체는 1~2년에 오므로 이것은 만약이 아니라 언제의 이야기입니다.	설계 단계에서 어느 모델로 임베딩했는지를 벡터와 함께 보존하세요. 이전 시에 어느 것이 옛 세대인지 판별할 수 있는지에 따라 작업량이 달라집니다. 아울러 원문 텍스트를 반드시 보유해 두세요 — 재임베딩에는 원문이 필요하므로 청크만 버렸다면 문서 취득부터 다시 하게 됩니다. 이전은 신구 인덱스를 병행 운용하고 검색 정확도를 비교한 뒤 전환하는 것이 안전합니다.

비용을 낮추는 가장 효과적인 수단은 애초에 임베딩하는 양을 줄이는 것입니다. 전사 문서를 통째로 넣기보다 실제로 검색되는 범위만 넣는 편이 싸고 빠르고 정확도도 오릅니다 — 무관한 문서가 늘수록 검색 결과에 섞이는 노이즈도 늘기 때문입니다. 갱신할 때마다 전 건을 다시 임베딩하는 운용도 피하세요. 문서마다 해시를 두고 내용이 바뀐 것만 재임베딩하는 것만으로 매일의 비용은 크게 내려갑니다. 분할 설계는 RAG 텍스트 청커에, 토큰 수 추정은 토큰 카운터에 정리해 두었습니다.

📖 사용법

1

인덱스 크기

문서 × 토큰
2

월 쿼리

쿼리 × 토큰
3

비교

비용/차원/정확도

❓ 자주 묻는 질문

한 번만?

초기 + 증분

차원 선택?

512-1536, MRL 가능

OSS?

BGE/E5 등 무료

🐛 이 도구에서 문제가 발생했나요?

무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.