AIREITERpplx-embed-v2-late 기반으로 PDF 검색 시스템의 예산을 잡고 있다면 먼저 짚어야 할 부분이 있습니다. Perplexity는 모델 가중치를 공개했지만, 아직 v2-late의 API 가격을 발표하지 않았고 공개 Embeddings API 카탈로그에도 모델을 올리지 않았습니다. 현재 현실적인 선택지는 멀티모달 검색을 직접 호스팅하는 것이며, 기존 v1 API 가격은 비교 기준으로만 활용할 수 있습니다.
가격부터 확인하면, v2-late는 아직 공개 Embeddings API 요금표에 없다
2026년 10월 7일 기준 공식 Embeddings API 빠른 시작 문서에는 v1 모델 네 가지가 등록돼 있습니다. pplx-embed-v2-late-0.6b와 pplx-embed-v2-late-9b는 목록에 없으므로, 현재로서는 v2-late의 토큰당 API 비용을 근거 있게 산정할 수 없습니다.
| 현재 API 문서에 등록된 Perplexity 모델 | 100만 토큰당 가격 | 용도 |
|---|---|---|
pplx-embed-v1-0.6b | $0.004 | 독립적인 텍스트, 쿼리, 문장 |
pplx-embed-v1-4b | $0.030 | 독립적인 텍스트, 쿼리, 문장 |
pplx-embed-context-v1-0.6b | $0.008 | 서로 연관된 문서 청크 |
pplx-embed-context-v1-4b | $0.050 | 서로 연관된 문서 청크 |
위 가격은 종량제 API 요금이며, late-interaction 계열의 가격이 아닙니다. Perplexity의 출시 발표는 late-interaction, dense, contextual 임베딩을 API Platform에 순차적으로 제공할 예정이라고 설명합니다. 다만 이는 출시 계획에 대한 안내일 뿐, 현재 이용 가능한 v2-late 엔드포인트나 가격을 확정한 발표는 아닙니다.
구매 결정을 위해서는 예산을 다음 두 항목으로 나눠 보는 편이 정확합니다.
- 관리형 API 비용: 위 v1 모델에는 적용되지만, v2-late 요금은 아직 공개되지 않았습니다.
- 셀프 호스팅 비용: v2-late를 운영하는 데 필요한 GPU 시간, 페이지 렌더링, 모델 저장 공간, 토큰 벡터 인덱스 저장 공간, 쿼리 처리 비용입니다.
v1 가격에 PDF 페이지 수를 곱한 뒤 그 결과를 v2-late 견적으로 사용하면 안 됩니다. 두 모델은 표현 방식이 다르고, v1 API는 텍스트 임베딩용이지 문서에 설명된 렌더링 페이지 기반 워크플로를 위한 API가 아닙니다.
pplx-embed-v2-late에서 실제로 제공하는 것
Perplexity는 late-interaction 체크포인트 두 가지를 공개했습니다. pplx-embed-v2-late-0.6b와 pplx-embed-v2-late-9b입니다. 9B 모델 카드에 따르면 작은 모델의 활성 파라미터는 340M, 큰 모델은 7.4B입니다. 두 모델 모두 토큰마다 128차원 벡터를 출력하며, 페이지 전체를 하나의 벡터로 축약하지 않고 MaxSim을 사용합니다.
| 모델 | 활성 파라미터 | ViDoRe v3 이미지 nDCG@10 | ViDoRe v3 Markdown nDCG@10 | 실제 활용처 |
|---|---|---|---|---|
pplx-embed-v2-late-0.6b | 340M | 62.3% | 61.2% | 가벼운 쿼리 처리 또는 소규모 배포 |
pplx-embed-v2-late-9b | 7.4B | 65.2% | 64.7% | 품질 중심의 인덱싱 및 검색 |
벤치마크 수치는 독립적인 PDF 테스트 결과가 아니라 모델 카드에 제시된 결과입니다. 9B는 이미지 검색에서 2.9%포인트, Markdown 검색에서 3.5%포인트 앞서며, 활성 파라미터 수는 약 21.8배 많습니다. 두 체크포인트 모두 Hugging Face에서 MIT 라이선스로 제공됩니다.
배포에서 중요한 부분은 두 모델이 공유하는 임베딩 공간입니다. Perplexity에 따르면 9B로 만든 인덱스를 0.6B 모델로 검색할 수 있습니다. 오프라인 문서 인코딩에는 9B를 사용하고 쿼리에는 0.6B를 사용하는 구성이 가능하지만, 먼저 두 모델 간 recall을 검증해야 합니다. 이 방식도 9B 인덱스 저장 공간까지 줄여주지는 않습니다.
실제로 구축할 수 있는 PDF 검색 구성
v2-late 워크플로에서는 렌더링한 PDF 페이지 하나하나를 이미지 문서로 취급합니다. 그러면 텍스트 쿼리로 페이지 안의 단어뿐 아니라 표 구조, 차트, 레이아웃까지 검색할 수 있습니다. OCR을 검색의 중심 표현으로 삼지 않아도 되는 방식입니다. 이는 Sentence Transformers의 시각 문서 검색 문서에서 설명하는 시각 문서 검색 패턴과 같습니다.
여기서 말하는 “OCR-free”는 OCR 결과를 검색 신호로 사용하지 않는다는 뜻입니다. 추출한 텍스트는 필터링, 인용, 접근성 지원, 보조 검색을 위해 여전히 유용합니다.
1. 페이지를 렌더링하고 메타데이터를 보존하기
모든 페이지를 일정한 해상도의 RGB 이미지로 렌더링한 뒤, 각 이미지와 함께 다음과 같은 레코드를 저장합니다.
| 필드 | 예시 |
|---|---|
document_id | contract-2026-04 |
page_number | 17 |
image_path | pages/contract-2026-04/017.png |
source_uri | 내부 PDF 객체 URL |
text_fallback | 선택 사항인 추출 텍스트 |
document_id와 page_number는 이미지 파일명에만 넣지 말고 검색 레코드에 별도로 보존해야 합니다. 관련 페이지를 찾은 뒤에는 같은 문서의 앞뒤 페이지도 함께 가져오는 것이 좋습니다. 표, 각주, 정의가 페이지 경계를 넘어 이어지는 경우가 많기 때문입니다.
2. 호환되는 인코더 설치하기
9B 모델 카드에서는 비교적 최신 라이브러리를 요구합니다.
pip install "sentence-transformers>=6.0.0" "transformers>=5.4.0" pillow제공된 예제는 MultiVectorEncoder를 사용하며, 모델 카드에서는 9B 체크포인트를 불러올 때 CUDA를 지정합니다.
from PIL import Image
from sentence_transformers import MultiVectorEncoder
model = MultiVectorEncoder(
"perplexity-ai/pplx-embed-v2-late-9b",
device="cuda",
)사용 가능한 서버 하드웨어에 큰 체크포인트를 올리기 어렵다면 0.6B 식별자를 사용하면 됩니다. 모델 카드에는 공식 VRAM 최소 요구량, 처리량 표, 지연 시간 보장이 나와 있지 않습니다. 따라서 실제 도입 전에 페이지 해상도, 배치 크기, GPU 구성에 따른 성능을 직접 측정해야 합니다.
3. 텍스트 쿼리와 페이지 이미지를 따로 인코딩하기
이 모델은 입력 유형에 따라 호출 방식을 나눠야 합니다. 쿼리 텍스트는 encode_query로, 렌더링한 페이지는 encode_document로 처리합니다.
query_embeddings = model.encode_query([
"Which clause governs termination after a material breach?"
])
page = Image.open("pages/contract-2026-04/017.png").convert("RGB")
page_embeddings = model.encode_document([page])
scores = model.similarity(query_embeddings, page_embeddings)
print(scores)텍스트와 이미지 문서를 하나의 혼합 배치에 넣어서는 안 됩니다. 모델 카드에서도 입력은 각각 동질적인 형태로 분리해야 하며, 이 체크포인트가 기대하는 [Q] / [D] 마커 설정을 사용한다고 설명합니다. model.similarity()는 토큰 단위 표현에 MaxSim을 적용합니다.
실제 문서 컬렉션에서는 페이지를 오프라인에서 인코딩하고, 멀티 벡터 표현은 late-interaction 인덱스에 저장하는 방식이 적합합니다. 페이지 메타데이터는 별도의 사이드카 저장소에 보관하면 됩니다. 규모가 작다면 모든 후보를 비교하는 방식으로도 충분하지만, 컬렉션이 커지면 MaxSim을 지원하는 시스템을 사용하거나 dense 1단계 검색 후 제한된 후보 집합에 v2-late를 재랭킹하는 구성이 현실적입니다.
4. 페이지를 검색한 뒤 근거 범위를 넓히기
페이지 단위 검색 결과에는 보통 다음 항목을 함께 반환하는 것이 좋습니다.
- 일치한 페이지와 점수
- 문서 ID와 원문 링크
- 같은 문서에 속한 앞뒤 페이지 한두 장
- 인용에 사용할 페이지 이미지와 선택적인 추출 텍스트
이렇게 하면 시각적으로는 정확한 페이지를 찾았지만, 정의는 16페이지에서 시작하고 표는 17페이지까지 이어지는 경우처럼 답변이 불완전해지는 일을 줄일 수 있습니다. 결과를 직접 확인할 수 있다는 점도 장점입니다. 사용자는 보이지 않는 OCR 변환 결과를 믿는 대신, 검색에 사용된 차트나 표를 직접 확인할 수 있습니다.
API 토큰 외에 고려해야 할 비용
현재 v2-late API 가격은 공개되지 않았기 때문에 네 가지 v1 요금과 직접 비교할 수 없습니다. 따라서 실제 운영 비용은 모델 카드에서 가격을 제시하지 않은 배포 요소에 의해 좌우됩니다.
| 비용 요소 | 확인된 내용 | 계획 수립 시 의미 |
|---|---|---|
| 모델 가중치 | Hugging Face의 9B 저장소에는 약 33.6 GB와 F32 텐서가 표시돼 있습니다. | 인덱싱을 시작하기 전부터 가중치 저장 및 로딩 비용이 발생합니다. |
| 표현 방식 | 토큰마다 128차원 벡터를 만들고 MaxSim으로 점수를 계산합니다. | 페이지 하나가 단일 dense 벡터가 아니라 다수의 벡터를 생성합니다. |
| 인덱싱 | 9B로 만든 인덱스를 0.6B로 검색할 수 있습니다. | 쿼리가 많다면 더 높은 연산 비용을 오프라인 작업으로 분리할 수 있습니다. |
| 검색 | late interaction은 쿼리 토큰과 문서 토큰을 비교합니다. | MaxSim을 지원하는 인덱스를 사용하거나 재채점 전에 후보 수를 제한해야 합니다. |
| API 과금 | v2-late 요금은 공개되지 않았습니다. | 현재로서는 관리형 API 비용을 예측하지 않는 편이 안전합니다. |
Hugging Face의 late-interaction 가이드에는 다른 모델을 기준으로 한 유용한 규모 참고 자료가 있습니다. 4,874개 패시지 예제에서 608,414개의 토큰 벡터가 생성됐고, 원시 float32 저장 공간은 311.5 MB였습니다. 압축한 PLAID 인덱스는 92 MB를 사용했습니다. 이 수치는 v2-late의 견적이 아니지만, “128차원”이라고 해서 인덱스가 작아지는 것은 아니라는 점을 보여줍니다. 중요한 배수는 토큰 수입니다.
인덱싱 처리량 역시 실제 사용할 하드웨어에서 측정해야 합니다. 한 사용자가 LocalLLaMA에 올린 보고에 따르면, pplx-embed-v1-4b는 A100 80GB에서 벡터 10,000개를 인덱싱하는 데 약 45분이 걸렸고, Qwen3-Embedding-4B는 6분이 걸렸습니다. 이 보고는 v2-late가 아닌 v1에 관한 내용입니다. 따라서 v2-late 성능을 주장하는 근거가 아니라, Perplexity 임베딩 처리량을 반드시 직접 측정해야 한다는 경고로 보는 것이 맞습니다.
“pplx embed가 표준 masked attention이 아니라 bidirectional attention을 사용하기 때문일 수 있다고 생각합니다.” — u/Velocita84, r/LocalLLaMA
어떤 배포 방식을 선택해야 할까?
| 요구 사항 | 현재 가장 적합한 방식 | 이유 |
|---|---|---|
| 관리형 엔드포인트를 사용하는 저렴한 텍스트 전용 RAG | Perplexity v1 API | 100만 토큰당 $0.004에서 $0.05 사이의 공개 가격이 있습니다. |
| 차트, 표, 스캔 페이지, 레이아웃이 중요한 경우 | pplx-embed-v2-late 셀프 호스팅 | 문서에 설명된 워크플로가 렌더링된 페이지를 직접 검색합니다. |
| 쿼리가 자주 발생하는 대규모 문서 집합 | 오프라인 9B 인덱스와 0.6B 쿼리 인코더 조합 또는 dense 우선 검색 후 v2-late 재랭킹 | 인덱싱 품질과 쿼리 시점의 연산 비용을 분리할 수 있습니다. |
| 소규모 프로토타입 또는 하드웨어 제약이 있는 테스트 | 대표 페이지 샘플에 0.6B 체크포인트 적용 | 활성 파라미터 수가 적지만, 페이지 인코딩 속도와 저장 공간은 여전히 측정해야 합니다. |
| 관리형 v2-late 엔드포인트가 반드시 필요한 경우 | 공식 API 모델 ID와 요금표가 나올 때까지 대기 | 현재 공개 임베딩 문서에는 어느 쪽도 등록돼 있지 않습니다. |
추천하는 방법은 전체 인덱스를 만들기 전에 대표 페이지 100~500장을 대상으로 0.6B와 9B의 교차 모델 구성을 먼저 검증하는 것입니다. 스캔 페이지, 표, 다단 레이아웃, 답변이 페이지 경계를 넘어가는 페이지를 샘플에 포함하세요. 목표 k에서의 recall, 페이지 인코딩 처리량, 원시 및 압축 인덱스 크기, 쿼리 지연 시간을 기록하는 것이 좋습니다. 아직 해당 API로 판매되지 않는 모델에 v1 토큰 가격을 그대로 대입하는 것보다 이런 실측 자료가 훨씬 유용합니다.
pplx-embed-v2-late PDF 검색 FAQ
pplx-embed-v2-late의 API 가격이 있나요?
이 가이드에서 확인한 공개 Perplexity Embeddings API 문서에는 가격이 없습니다. 공개된 100만 토큰당 $0.004~$0.05 가격은 v1 일반 모델과 contextualized 모델에 적용됩니다.
pplx-embed-v2-late는 공식 출시됐나요?
네. Perplexity는 Hugging Face에 0.6B와 9B 오픈 웨이트 체크포인트를 공개했습니다. 가중치 공개와 관리형 API 제공은 서로 다른 단계입니다.
PDF 검색에 OCR이 필요한가요?
시각적 검색 신호만 놓고 보면 필요하지 않습니다. 각 페이지를 이미지로 렌더링한 뒤 문서로 인코딩하면 됩니다. OCR이나 추출 텍스트는 필터링, 인용, 접근성 지원, 보조 검색에 여전히 유용합니다.
0.6B 모델로 9B가 만든 인덱스를 검색할 수 있나요?
Perplexity의 모델 카드에 따르면 두 모델은 임베딩 공간을 공유하므로 해당 구성이 가능합니다. 다만 모델 카드에는 모델 간 검색 성능 차이가 공개돼 있지 않으므로, 실제 문서 집합에서 품질을 측정해야 합니다.
텍스트와 이미지 페이지를 하나의 배치에서 처리할 수 있나요?
아니요. 모델 카드에서는 텍스트와 이미지 입력을 같은 인코딩 배치에서 혼합하는 방식을 지원하지 않는다고 설명합니다. 텍스트와 이미지 인코딩 호출을 각각 동질적인 입력으로 유지해야 합니다.
그래도 별도의 reranker가 필요한가요?
반드시 필요한 것은 아닙니다. MaxSim이 이미 late-interaction 점수 계산 방식으로 사용됩니다. 다만 대규모 문서 집합에서 모든 페이지 토큰 벡터를 검색하는 것보다, dense 1단계 검색 후 v2-late로 재랭킹하는 구성이 더 실용적일 수 있습니다.
PDF 페이지 하나당 정확한 저장 비용은 얼마인가요?
Perplexity는 v2-late의 페이지 단위 저장 공간 계산기를 공개하지 않았습니다. 보존하는 페이지 토큰 수, 벡터 정밀도, 메타데이터, 인덱스 압축 방식을 기준으로 추정한 뒤 대표 샘플로 검증해야 합니다.
0.6B와 9B 중 무엇을 선택해야 하나요?
오프라인 인덱싱 품질이 우선이고 모델과 인덱싱 작업에 필요한 비용을 감당할 수 있다면 9B를 사용하세요. 더 작은 배포 환경이나 쿼리 인코더에는 0.6B가 적합합니다. 9B 인덱스에 대해 문서화된 공유 임베딩 공간 구성을 사용하는 경우도 여기에 포함됩니다. 벤치마크 차이는 측정할 수 있지만, 모델 카드에는 모든 환경에 적용할 수 있는 품질 또는 지연 시간 기준이 제시돼 있지 않습니다.
도입 여부를 결정하는 기준은 간단합니다. 지금 당장 가격이 정해진 관리형 Perplexity 엔드포인트가 필요하다면 v2-late는 아직 그 요구를 충족하지 못합니다. 반대로 셀프 호스팅이 가능하고 PDF에 OCR이나 텍스트 청킹으로 놓치기 쉬운 정보가 포함돼 있다면, 대표 페이지를 렌더링해 late-interaction 파이프라인을 먼저 벤치마크한 뒤 규모를 키우는 것이 좋습니다.