대규모 자체 호스팅 RAG: 벡터 인덱스가 실제로 얼마나의 RAM을 먹는가

모든 RAG 튜토리얼은 문서 몇백 개를 가진 노트북에서 돌고, 힘들이지 않는 것처럼 느껴집니다. 그다음 실제 코퍼스에 향하게 하면 — 회사의 문서, 몇 년치 티켓, 지식 베이스 — 갑자기 메모리가 대화의 전부가 됩니다.

RAG는 CPU로 스케일하지 않습니다. RAM으로 스케일합니다.

인덱스가 왜 메모리를 원하는가

검색은 모든 텍스트 청크를 임베딩 — 수백에서 수천 개 숫자 길이의 벡터 — 으로 바꿔 작동합니다. 검색은 당신의 쿼리 벡터를 그 모두와 비교하는 것, 빠르게. "빠르게"가 핵심어: 낮은 지연을 위해 인덱스는 RAM에 살아야 합니다. 디스크에서도 되지만 모든 쿼리가 벌금을 물고, 낮은 지연의 검색이야말로 애초에 자체 호스팅의 목적이었습니다.

그래서 메모리 청구는 두 가지로 스케일합니다: 청크가 몇 개인지, 그리고 각 벡터가 얼마나 넓은지.

실제 숫자, 대략

자신의 것을 측정하세요 — 차원과 인덱스 유형이 이것을 크게 움직입니다 — 하지만 출발의 느낌으로:

• 수십만 임베딩 — 2~4 GB에 편안. 개인 지식 베이스, 단일 제품의 문서.
• 낮은 수백만 — 앱, 모델 클라이언트, 주변의 OS와 함께 16~32 GB를 계획하세요. 이것은 진지한 회사 지식 베이스나 다중 소스 RAG.
• 수천만, 또는 고차원 벡터 — 이제 48~80 GB, 그 너머는 여러 박스에. 큰 문서 자산, 멀티테넌트 검색, 또는 여러 인덱스를 동시에 따뜻하게 유지.

큰 인덱스도 쥐는 멀티 에이전트 시스템은 두 비용을 같은 박스에 쌓습니다 — 그것이 32 GB 요금제가 조용히 64 GB짜리가 되는 방식입니다.

엔진 선택, 간략히

이미 Postgres를 돌린다면 pgvector가 가장 품이 덜 드는 선택지 — 지켜봐야 할 새 서비스가 아니라 확장입니다. 수백만 벡터가 있고 빠른 필터 검색을 원하면 Qdrant나 Weaviate 같은 전용 엔진이 별도 프로세스를 법니다. 첫날부터 과잉 설계하지 마세요; 이미 운영하는 것을 돌리고 검색이 실제로 느려질 때 떼어내세요.

왜 굳이 자체 호스팅하나

사람들이 실제로 이것을 하는 두 이유, 그리고 어느 것도 "몇 달러 아끼려"가 아닙니다:

프라이버시. 임베딩은 추상이 아니라 — 유래한 텍스트를 인코딩합니다. 당신의 문서, 고객의 콘텐츠, 내부 메모가 벡터로 바뀌어 제3자의 서버로 보내집니다. 자체 호스팅은 그것을 당신이 통제하는 기기에 둡니다. 데이터가 KYC 없이 암호화폐로도 내는 만큼 민감하면, 관리형 벡터 클라우드가 전체 의미를 뒤집습니다.

정액. 관리형 벡터 서비스는 저장한 벡터와 실행한 쿼리로 청구합니다. VPS는 월 하나의 숫자이고 원하는 만큼 두드릴 수 있습니다. 규모에서는 예측 가능이 계량을 이깁니다.

사이징에 무엇을 뜻하나

짐작이 아니라 코퍼스를 측정하는 것에서 시작하세요. 임베딩 수와 차원을 얻고, 샘플을 로드하고, 상주 메모리를 보고, 외삽하세요. 그다음 인덱스와 주변의 모든 것 — 앱, 모델 클라이언트, 자랄 여지 — 을 위한 여유가 있는 요금제를 고르세요.

수백만 벡터를 넘는 것을 프라이빗하게 쥔다면, Pro 라인이 전용 IP와 야간 백업으로 32에서 80 GB를 돌리고, 인덱스가 곧 제품이고 잃으면 아플 때 그것이 중요합니다.