홈 서버에서 여러 RAG 컬렉션이 RAM을 두고 경쟁하는 이유는 무엇인가요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Do Multiple RAG Collections Compete for RAM on a Home Server?

여러 RAG 컬렉션이 RAM을 두고 경쟁하는 이유는 각 컬렉션이 자체 벡터, 검색 그래프, 메타데이터 인덱스, 캐시, 활성 작업 세트를 유지하기 때문입니다.

홈 서버에서는 개인정보 보호나 더 깔끔한 검색을 위해 가족 문서, 기술 매뉴얼, 사진 메타데이터, 업무 메모, 스마트홈 기록을 서로 다른 RAG 컬렉션으로 분리할 수 있습니다. 원본 파일은 디스크에 충분히 저장되더라도 검색 계층은 예상보다 훨씬 많은 메모리를 사용할 수 있습니다. 각 컬렉션은 근사 최근접 이웃 인덱스, 페이로드 필터, 세그먼트 메타데이터, 최근 액세스 페이지, 쿼리 버퍼를 로드할 수 있으며, 임베딩 및 재순위 지정 서비스는 이러한 컬렉션과 별도로 자체 상주 모델을 추가합니다.

각 컬렉션은 별도의 검색 구조를 만듭니다

벡터 컬렉션은 단순히 임베딩을 모아 둔 폴더가 아닙니다. 검색 엔진은 일반적으로 벡터 값과 함께 모든 레코드를 일일이 검색하지 않도록 돕는 이웃 그래프 또는 다른 근사 검색 구조를 유지합니다.

Weaviate는 메모리 내 근사 최근접 이웃 인덱스에서 벡터와 HNSW 그래프를 주요 메모리 소비 요소로 설명합니다.

따라서 컬렉션을 5개 만들면 동일한 임베딩 모델을 공유하고 하나의 데이터베이스 프로세스에서 실행하더라도 독립적으로 주소 지정되는 인덱스가 5개 생길 수 있습니다. 분리는 검색상의 이점이 늘어난 작업 세트를 감수할 만할 때에만 정책 및 유지 관리 측면에서 유리합니다.

차원 수와 인덱스 오버헤드는 기본 메모리 사용량을 배가합니다

원시 벡터 메모리는 벡터 수, 임베딩 차원 수, 구성 요소당 바이트 수에 따라 증가합니다. 검색 가능한 인덱스는 이러한 원시 배열 외에도 그래프 링크, 식별자, 정렬, 메타데이터, 메모리 할당자 오버헤드를 추가합니다.

Milvus는 벡터 인덱스 메모리 공식을 제공하며, HNSW 배포에는 인덱싱되지 않은 벡터만 사용할 때보다 훨씬 많은 메모리가 필요할 수 있다고 설명합니다.

각 컬렉션을 개별적으로 추정한 다음 모두 합산하세요. 문서 수가 적은 컬렉션이라도 고차원 임베딩, 최고 정밀도 구성 요소, 높은 재현율에 맞춘 그래프를 사용하면 비용이 많이 들 수 있습니다.

그래프 연결성은 RAM을 사용해 재현율과 속도를 높입니다

HNSW는 각 벡터를 인접 노드와 연결합니다. 연결 수가 많을수록 탐색과 재현율이 향상될 수 있지만, 저장되는 모든 엣지는 메모리를 사용하며 인덱스 생성 비용도 높입니다.

Redis는 그래프 연결성이 인덱스 크기와 재현율, 검색 동작 사이의 균형을 조절하는 매개변수로 제어된다고 설명합니다.

컬렉션마다 필요한 수준이 다른데도 동일하게 공격적인 기본값을 사용할 수 있습니다. 가장 까다로운 검색 워크로드에 맞춰 모든 인덱스를 조정하기보다, 소규모 아카이브나 동시성이 낮은 컬렉션에는 메모리 사용량이 적은 프로필을 사용하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

메모리 매핑은 부담을 공유 페이지 캐시로 옮깁니다

벡터나 그래프 데이터를 디스크에 저장하고 메모리 매핑을 사용하면 프로세스에 영구적으로 상주하는 할당량을 줄일 수 있습니다. 그렇다고 활성 페이지가 메모리에서 사라지는 것은 아닙니다. 운영 체제는 최근에 액세스한 인덱스 블록을 여전히 RAM에 캐시합니다.

Qdrant의 메모리 비교는 메모리 매핑 벡터가 측정되는 RAM 사용량을 줄이는 대신 스토리지를 통해 데이터를 가져오면서 지연 시간의 절충이 발생한다는 점을 보여 줍니다.

쿼리가 여러 컬렉션 사이를 오가면 각 컬렉션의 핫 페이지가 페이지 캐시에서 서로를 밀어낼 수 있습니다. 이러한 부담은 홈 서버에서 사진 앱, 컨테이너, 데이터베이스, 네트워크 공유가 사용하는 파일 시스템 데이터까지 밀어낼 수 있습니다.

RAM보다 큰 인덱스는 더 많은 스토리지 I/O를 대가로 합니다

인덱스가 물리 메모리를 초과해도 검색을 계속 수행할 수 있지만, 검색 경로의 더 많은 부분을 SSD에서 읽어야 합니다. 그러면 무작위 액세스와 캐시 미스가 검색 지연 시간의 일부가 됩니다.

PlanetScale은 RAM보다 큰 인덱스를 설명하며, 더 작은 탐색 구조는 메모리에 유지하고 더 많은 포스팅 또는 벡터 데이터는 스토리지로 옮기는 방식을 소개합니다.

검색이 가끔 실행되고 인덱스가 빠른 SSD 스토리지에 있다면 이는 홈 서버에서 좋은 절충안이 될 수 있습니다. 하지만 여러 컬렉션에 동시 쿼리가 들어오거나 느린 디스크를 애플리케이션 데이터베이스 및 미디어 워크로드와 공유한다면 적절하지 않을 수 있습니다.

중복 저장과 별도 서비스는 숨겨진 복사본을 추가합니다

동일한 임베딩이 문서 저장소, 벡터 인덱스, 애플리케이션 캐시, 백업 또는 스테이징 컬렉션에 존재할 수 있습니다. 별도의 컨테이너는 동일한 임베딩 또는 재순위 지정 모델을 서로 다른 프로세스 주소 공간에 각각 로드할 수도 있습니다.

Memgraph가 설명하는 중복 벡터 저장 방지는 인덱스 아키텍처에 따라 검색 가능한 하나의 레코드에 대해 메모리에 유지되는 복사본 수가 달라지는 이유를 보여 줍니다.

따라서 컬렉션 수는 예산의 한 부분에 불과합니다. 벡터 데이터의 중복, 이전 인덱스 버전, 임시 재구축 컬렉션, 모델 프로세스, 캐시된 결과를 먼저 점검한 후 벡터 데이터베이스만 원인이라고 결론 내리세요.

액세스 정책과 워크로드를 기준으로 컬렉션을 통합하세요

서로 다른 권한, 임베딩 차원, 보존 정책, 업데이트 일정 또는 장애 경계가 필요하다면 컬렉션을 분리하세요. 단순히 주제가 다르다는 이유만으로 항상 별도의 물리 인덱스가 필요한 것은 아닙니다.

테넌트, 소유자, 소스, 카테고리 메타데이터를 포함한 공유 컬렉션을 사용하면 하나의 인덱스를 재사용하면서 필터로 의도한 범위 안에서 검색할 수 있습니다. 다만 통합하기 전에 필터 적용 재현율을 테스트하세요. 지나치게 큰 통합 컬렉션은 자체적인 순위 지정 및 유지 관리 비용을 유발할 수 있습니다.

ZimaSpace가 설명하는 로컬 AI 런타임이 메모리를 예약하는 이유는 모니터링 결과를 해석하는 데 도움이 됩니다. 유지되는 페이지와 캐시는 누수가 아니라 재사용 가능한 작업 상태일 수 있지만, 여전히 서버의 다른 구성 요소와 메모리를 두고 경쟁합니다.