엔지니어링 노트 · 프라이빗 RAG

ProsGrow가 RAG 원시 벡터 저장 공간을 75% 줄인 방법

ProsGrow는 SciFact에서 기준 nDCG@10의 99.58%를 유지하면서 원시 벡터 저장 공간을 75% 줄였습니다. 별도의 FP8 연구에서는 자체 품질 검증과 함께 임베딩 처리량을 69.10% 높였습니다. 이 결과는 저장 공간과 인코딩 처리 능력에 대한 서로 다른 선택지를 보여 줍니다.

· 업데이트 · ProsGrow AI 엔지니어링 · 읽는 시간 6분

원시 벡터를 4,096차원에서 1,024차원으로 줄이면서 FP16 차원 연구의 SciFact 기준 nDCG@10을 99.58% 유지합니다.

문제: 검색에는 서로 다른 두 가지 자원 비용이 있습니다

프라이빗 RAG 시스템에는 문서 인코딩, 벡터 저장, 검색 결과 순위 지정 비용이 듭니다. 유용한 운영 지점은 어떤 품질 변화를 허용할 수 있는지, 어디에서 처리 능력이 제한되는지에 따라 달라집니다. ProsGrow는 Qwen이 지원하는 표현 방식과 vLLM의 정밀도 실행 경로를 활용해 이러한 결정을 체계적으로 평가했습니다.

우리는 원시 벡터 바이트 수가 75% 적은 1,024차원 벡터를 선택했고, 별도의 실험에서는 임베딩 처리량이 69.10% 높은 동적 FP8을 선택했습니다. 각 선택에는 고유한 품질 절충이 따릅니다.

결정 1: 저장 비용에 상응하는 가치가 있는 차원 유지

Qwen3-Embedding-8B의 기본 4,096차원 출력에서 시작했습니다. SciFact 전체 테스트 분할에서 이 FP16 기준 구성의 nDCG@10은 0.79279였습니다. nDCG@10은 유용한 문서가 결과 상단에 있을수록 높은 점수를 주는 관련성 지표입니다. 출력을 1,024차원으로 줄였을 때 점수는 0.78944로, 기준 nDCG@10의 99.58%였습니다.

동일한 저장 정밀도에서의 원시 벡터 크기

기준: 4,096차원16 KiB/벡터 · nDCG@10 0.79279
ProsGrow 선택: 1,024차원4 KiB/벡터 · nDCG@10 0.78944
SciFact의 원래 FP16 차원 연구입니다. Float32 벡터 페이로드는 75% 작아지고 nDCG@10은 0.00335, 상대적으로 0.42% 감소합니다. 인덱스 구조, 메타데이터, 복제본은 이 벡터 바이트 외에 추가 저장 공간을 차지합니다.

더 강하게 압축하면 순위 품질 손실이 더 커졌습니다. 이 코퍼스에는 1,024차원을 선택했으며 Recall@100은 0.98000에서 0.97333으로 감소했습니다. 99.58% 유지라는 수치는 이 FP16 차원 실험의 nDCG@10에만 해당합니다.

작은 벡터가 도움이 되는 부분과 그렇지 않은 부분

Qwen3-Embedding-8B는 Matryoshka 표현을 제공하며, vLLM 임베딩 런타임이 이를 지원합니다. 원본 프로젝트의 이 기능은 짧으면서도 유용한 벡터를 지원합니다. ProsGrow의 기여는 워크로드에 대해 그에 따른 저장 공간과 품질의 절충을 평가한 것입니다.

float32 벡터 1억 개에서는 계산상 원시 저장 공간이 1.64 TB에서 0.41 TB로 줄어듭니다. 전체 데이터베이스 용량과 검색 지연 시간은 실제 인덱스로 별도 측정해야 합니다.

인코더는 여전히 기본 은닉 차원 너비로 계산했고, 시험한 차원들 사이의 처리량 변화는 최대 1.2%였습니다. 이후의 69.10% 처리량 향상은 별도의 정밀도 실험에서 나온 결과입니다.

결정 2: FP8로 인코딩 처리 능력의 실측 향상 확보

출력 차원과 짧은 입력 워크로드를 고정했을 때 동적 FP8은 복제본 8개에서 초당 입력 토큰 319,951개를 처리했습니다. FP16의 189,213개보다 높습니다. FP8 노드 실행 두 번 중 낮은 결과를 기준으로 69.10% 향상되었습니다.

동일한 GPU 8개에서의 임베딩 처리량

FP16 기준 · 1,024차원입력 토큰 189,213개/초
ProsGrow 동적 FP8 · 1,024차원입력 토큰 319,951개/초 · +69.10%
동일한 짧은 입력 API 조건과 vLLM 0.25.1을 사용했으며 프리픽스 캐싱은 비활성화했습니다. FP8 값은 전체 노드 실행 두 번 중 낮은 결과입니다. 이 정밀도 실험은 위의 차원 비교와 별개입니다.

더 빠른 실행 경로는 vLLM의 동적 FP8 지원에서 나옵니다. ProsGrow는 의도한 FP8 커널이 모든 GPU에서 실행되는지 확인하고 정밀도, 동시성, 복제본 배치를 함께 평가했습니다. 선택한 프로파일보다 동시성을 더 높이면 처리 능력은 거의 늘지 않았지만 평균 지연 시간은 약 두 배가 되었습니다.

최종 비교에서는 프리픽스 캐싱을 비활성화해 반복되는 벤치마크 입력이 트랜스포머 연산 대신 캐시 재사용의 이점을 얻지 못하도록 했습니다.

최적화된 노드는 입력 토큰 백만 개당 GPU 보드 에너지도 44.19% 적게 사용했습니다. 7.025 Wh에서 3.921 Wh로 줄었습니다. 이는 GPU 에너지의 실측 개선이며 호스트와 시설 전력은 지표에 포함되지 않습니다.

FP8의 품질 비용은 별도로 판단해야 합니다

조건을 맞춘 FP16 대조 구성과 FP8 두 번의 시작 실행으로 SciFact 전체 품질 평가를 반복했습니다. 1,024차원에서 보수적으로 선택한 FP8 결과의 nDCG@10은 0.786211로, 조건을 맞춘 FP16 대조 구성의 0.789717보다 0.003506 낮았습니다. Recall@100은 0.97333으로 유지되었습니다.

다른 FP8 시작 실행의 nDCG@10은 0.790021이었습니다. 채택 여부를 보수적으로 판단하기 위해 더 낮은 점수를 보고합니다. 앞선 99.58% 유지 수치는 원래의 차원 실험에만 해당하며, 차원 축소와 FP8을 결합했을 때의 품질을 보장하지 않습니다.

리랭킹: 답변을 바꿀 수 있는 후보에 연산 사용

Qwen3-Reranker-8B에서는 쿼리당 전체 문서 20개를 선택했습니다. 정책 연구에서는 후보 수와 문서 잘라내기 방식을 모두 바꿨으므로 그 효과를 후보 수만으로 설명할 수 없습니다. 선택한 정책의 nDCG@10은 0.80482였으며, 후보 집합을 줄이는 것은 연산 절감과 검색 재현율 사이의 절충입니다.

문서 20개로 고정한 조건에서 동적 FP8은 단독 측정 처리량을 초당 검색 2.7444회에서 4.6958회로 71.10% 높였습니다. 복제본 8개의 보수적 결과는 초당 21.6248회에서 44.4738회로 높아졌습니다. 즉 시간당 상위 20개 검색 77,849회에서 160,106회로 +105.66%입니다. nDCG@10은 0.804821에서 0.803368로 바뀌었고 Recall@20은 0.94000으로 유지되었습니다.

두 번의 시작 실행에서 노드 결과가 단독 FP8 속도의 8배를 넘었으며, 감사 후에도 원인은 확인되지 않았습니다. 이 처리 능력은 해당 구성에만 적용됩니다. 단독으로 측정한 71.10% 비교가 GPU당 정밀도 변경 이점을 판단하는 더 명확한 기준입니다.

고객에게 달라지는 점

1,024차원 품질 검증을 통과한 코퍼스는 벡터 페이로드가 4분의 3 줄어듭니다. FP8 검증도 통과한 짧은 입력 인덱싱 작업에서는 측정 처리량이 입력 토큰 10억 개당 약 52분에 해당하며 FP16 기준의 88분보다 짧습니다. 이 시간은 벤치마크 속도로 계산한 처리 시간 추정치입니다.

따라서 인덱스를 더 자주 갱신할 여지가 생깁니다. 온라인 검색에는 통합 용량 계획이 필요합니다. 전체 노드의 임베딩 속도와 리랭킹 속도는 별도로 측정했기 때문입니다.

ProsGrow의 기여는 워크로드 요구 사항에 맞는 운영 지점을 선택하고 검증하는 것입니다. 고객 파일럿에는 자체 관련성 판정과 답변 품질, p95 지연 시간을 포함한 전체 검색 경로의 평가가 필요합니다. 벤치마크는 구성 요소의 절충을 보여 주며, 운영 서비스에는 통합 검증이 필요합니다.

두 구성 요소의 개별 비용 모델

전체 처리 능력이 유료로 사용될 때 9월 인프라 모델은 노드 구매 비용 $100,000–$150,000을 기준으로 임베딩을 입력 토큰 백만 개당 $0.00453–$0.00646, 상위 20개 리랭킹을 검색 1,000회당 $0.03258–$0.04644로 추정합니다. 계산에는 각 구성 요소의 전체 노드 실측 속도인 입력 토큰 319,951개/초 또는 검색 44.4738회/초를 각각 사용합니다.

이 시나리오는 3년 상각, 연간 유지보수 5%, 월 720시간, 전기요금 $0.10/kWh, 전력 사용 배율 1.30, 활성 서버 전력 6 kW를 가정합니다. 이에 따라 활성 노드 시간당 인프라 비용은 $5.22–$7.44로 모델링됩니다. 6 kW 입력은 포트폴리오 가정이며 위에서 보고한 GPU 보드 에너지의 실측 개선과는 별개입니다. 수요가 낮으면 고정비가 더 적은 판매 단위에 배분됩니다.

각 구성 요소는 별도의 시험에서 GPU 8개를 모두 사용했으므로 각 최대치를 합쳐 동시 서비스 용량으로 볼 수 없습니다. 비용에는 저장 공간, 애플리케이션 운영, 인건비, 네트워킹, 서비스 예비 용량, 답변 생성이 제외됩니다. 승인된 답변당 비용은 전체 과정의 검증이 필요합니다.

측정 방법과 한계

  • 하드웨어와 모델: GPU당 명목 메모리 96 GB의 RTX PRO 6000 Blackwell Server Edition GPU 8개를 사용했으며 GPU당 복제본은 하나입니다. 임베딩에는 Qwen/Qwen3-Embedding-8B 리비전 1d8ad4ca9b3dd8059ad90a75d4983776a23d44af, 리랭킹에는 Qwen/Qwen3-Reranker-8B 리비전 77d193c791ed757ca307ee72715aa132723da912를 사용했습니다.
  • 런타임: vLLM 0.25.1을 사용했습니다. 정밀도 비교에서는 float16 활성화, 동적 FP8 가중치, 확인된 FP8 커널 경로를 사용했습니다. 최종 비교에서는 프리픽스 캐싱을 비활성화했습니다.
  • 임베딩 처리 능력: 요청당 64개인 합성 짧은 입력으로, 입력당 평균 모델 토큰 56개와 반환 차원 1,024개를 사용했습니다. 각 노드 실행은 입력 65,536개를 처리했습니다. 선택한 FP8의 공통 시간 구간은 11.467초였습니다. 두 실행의 차이는 0.47%였고 실패한 요청은 없었습니다. 실제 문서 품질은 별도로 평가했습니다.
  • 검색 품질: 제목과 초록으로 구성된 문서 5,183개, 쿼리 300개, 공식 관련성 판정으로 이루어진 BEIR SciFact 전체 테스트 분할을 사용했습니다. 게시자의 쿼리 지침과 전수 코사인 검색으로 평가했습니다. SciFact는 과학 분야 벤치마크 하나이므로 다른 코퍼스와 근사 인덱스에서는 결과가 다를 수 있습니다.
  • 리랭커 측정 범위: 각 노드 실행은 검색 2,400회를 처리했으며 검색마다 전체 문서 20개를 사용했습니다. 후보는 FP16 1,024차원 밀집 벡터 기준 구성에서 고정했으므로 FP8 임베딩과 리랭킹을 결합한 파이프라인의 측정이 아닙니다. 관측된 처리량과 품질 중 낮은 결과를 보고합니다.
  • 시간 측정과 배포: 워밍업 후 API 측정 구간은 가장 먼저 시작한 복제본부터 마지막 완료 시점까지입니다. 시작 과정과 페이로드 구성은 제외됩니다. 커넥터, 청킹, 벡터 데이터베이스 연산, 생성, 운영 환경의 큐 대기는 전체 과정의 파일럿이 필요합니다. 시간당 수치와 10억 토큰 수치는 산술적 환산이며 장시간 지속 시험 결과가 아닙니다.
  • 저장 공간과 에너지: 75% 감소는 동일한 저장 정밀도에서 원시 벡터에 해당합니다. 메타데이터, 인덱스 구조, 복제, 백업에는 추가 오버헤드가 있습니다. 에너지 수치는 GPU 보드만 포함합니다. 결과는 지정된 구성의 로컬 비교이며, 동등한 모델을 제공하는 관리형 API 대비 비용을 주장하지 않습니다.

프라이빗 RAG 검색과 시맨틱 검색

프라이빗 검색 증강 생성(RAG)을 계획하는 팀을 위해 이 연구는 임베딩 벡터 저장 공간, 문서 색인 처리 능력, 재순위화 품질을 구분합니다. 이 측정값은 시맨틱 검색 인프라 선택에 도움이 되지만, 벡터가 작아졌다는 사실만으로 데이터베이스 쿼리가 빨라졌다고 입증할 수는 없습니다. 배포 시 전체 검색 파이프라인에서 관련성, 응답 시간, 답변 품질을 검증해야 합니다.

코퍼스에 맞는 검색 절충점 찾기

ProsGrow는 품질 목표, 갱신 기한, 쿼리 지연 시간 예산에 맞춰 차원, 정밀도, 리랭킹을 함께 벤치마크할 수 있습니다.

프라이빗 RAG 파일럿 상담