노트북에서 문서 200개로 하는 RAG 데모는 수월하게 느껴집니다. 그러다 진짜 코퍼스로 겨누면 — 어느 회사의 문서, 수년치 티켓, 실재하는 지식 베이스 — 전체가 메모리 문제가 됩니다. CPU 문제가 아니라. 메모리 문제로.
여기가 대부분의 호스팅 페이지가 건너뛰는 부분: 빠른 검색은 인덱스를 RAM에 원합니다. 텍스트의 각 청크는 임베딩이 됩니다 — 수백에서 수천 개 숫자 폭의 벡터 — 그리고 검색이란 당신의 쿼리를 그것들 전부와 빠르게 비교하는 것. 디스크에서도 되지만, 쿼리마다 레이턴시 세금을 물고, 애초에 저지연 검색이 자체 호스팅한 이유였습니다.
사이징 계산, 솔직하게
자기 코퍼스를 재세요 — 차원과 인덱스 종류가 이걸 크게 흔듭니다 — 그래도 출발점의 감으로:
- 수십만 임베딩 — 2~4 GB. 개인 지식 베이스. 여기엔 Pro가 필요 없습니다; 작은 요금제로 충분.
- 수백만 — 앱, 모델 클라이언트, 둘레의 OS와 함께 16~32 GB 를 잡으세요. 진지한 회사 지식 베이스. 여기가 Pro-32나 Pro-48 이 의미를 갖기 시작하는 곳.
- 수천만, 또는 고차원 벡터 — 48 GB 이상, 그리고 ~80 GB를 넘으면 인덱스를 여러 서버에 나눕니다. 큰 문서 자산, 멀티테넌트 검색, 여러 인덱스를 동시에 핫하게.
자세히 원하면 RAM 곡선 전체를 여기 썼습니다。
왜 고메모리 그리고 KYC 없음을 함께
48 GB RAM을 빌리는 건 쉽습니다. 그걸 암호화폐로, 신원 확인 없이 빌리는 건 쉽지 않습니다 — 진지한 메모리를 싸게 파는 호스트 대부분은 카드와 KYC 양식 뒤에서 그렇게 합니다. 당신의 임베딩은 추상적 숫자가 아닙니다; 그것이 나온 텍스트를 인코딩합니다. 당신의 문서, 고객의 콘텐츠가 벡터로 바뀐 것. 그 데이터가 프라이빗하게 결제할 만큼 민감하면, 매니지드 벡터 클라우드는 전체 요지를 무너뜨립니다 — 서버를 당신 신원에 묶는 호스트도 마찬가지.
그 조합 — 고메모리, 전용 IP, 암호화폐, KYC 없음, 야간 백업 — 이 Pro 라인의 목적입니다. 기가바이트당 가장 싸진 않고, 프라이버시가 필요 없다면 RAM은 다른 데서 더 싸게 찾을 수 있습니다. 하지만 인덱스가 당신의 제품이고 떠날 수 없다면, 이것이 맞는 모양입니다.
어디서 시작할까
인덱스에 더해 둘레 모든 것 — 앱, 모델 클라이언트, 성장 여지 — 의 여유가 있는 요금제를 고르세요. 대부분의 실재 코퍼스에는 그게 Pro-48(48 GB); 큰 것은 Pro-64나 Pro-80으로. 먼저 샘플을 로드하고, 메모리를 보고, 두려워한 숫자가 아니라 측정한 숫자에서 크기를 잡으세요.
검색이 더 큰 에이전트 시스템의 일부라면, 같은 박스가 흔히 에이전트 함대도 품습니다 — 그렇게 48 GB 요금제가 조용히 64 GB가 됩니다.
댓글
아직 댓글이 없습니다. 첫 번째가 되세요.