벡터 검색: HotKV 대 Redis 8 벡터 세트, 클라이언트 1개에서 100개까지

벡터 검색은 RAG를 위한 검색, 시맨틱 캐싱, 에이전트 메모리 등 많은 AI 기능의 밑바탕에 있습니다. Redis 8에는 서버에 내장된 벡터 세트(베타 데이터 타입)가 포함되어 있으므로 당연한 비교 대상입니다. 저희는 동일한 OpenAI 임베딩을 HotKV와 Redis 8.10.2에 각각 로드하고, 동시 클라이언트 연결 1~100개로 각각에 동일한 쿼리 1,000개를 실행하여, 답변이 얼마나 정확한지, 각 엔진이 초당 몇 개의 쿼리를 처리했는지, 각 쿼리에 얼마나 걸렸는지를 측정했습니다.

요약. 벡터 999,000개, 최소 재현율 95% 조건에서 HotKV는 클라이언트 1개일 때 Redis의 1.4배, 클라이언트 100개일 때 7.9배의 초당 쿼리 수를 처리했습니다(51,146 대 6,510). 재현율 99%에서는 이 배수가 1.8배와 5.4배였습니다. HotKV의 지연 시간 중앙값은 모든 클라이언트 수에서 더 낮았습니다. Redis의 처리량은 클라이언트 32개 시점에 이미 정체되었지만, HotKV의 처리량은 100개까지 계속 증가했습니다. HotKV는 벡터를 약 5배 빠르게 로드했으며, 모든 검색 깊이에서 재현율이 더 높았습니다. 이는 머신 한 대에서 측정한 데이터셋 하나의 결과이고, HotKV 빌드는 아직 출시되지 않은 개발 빌드이며, Redis의 Query Engine이나 8비트 모드는 측정하지 않았으므로, 순위가 아니라 하나의 측정 결과로 읽어 주십시오.

테스트 내용

데이터

Kumar Shivendu 및 Nirant Kasliwal의 dbpedia-entities-openai-1M(MIT 라이선스)에서 처음 999,000개 행을 사용했고, 더 작은 인덱스에는 처음 100,000개 행을 사용했습니다. 각 행은 OpenAI text-embedding-ada-002 모델로 임베딩한 1,536차원의 DBpedia 엔터티입니다. 마지막 1,000개 행은 쿼리이므로 두 세트에 모두 나타나는 행은 없습니다. 정답 기준은 모든 쿼리에 대한 정확한 상위 10개 최근접 이웃으로, 두 엔진과 무관하게 64비트 부동소수점으로 전수 탐색(brute force)하여 계산했으므로 두 엔진은 동일한 정답 데이터를 기준으로 채점됩니다.

엔진과 설정

• 엔진. HotKV는 커밋 c8dafd37(VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH) 빌드로, -march=native 대신 기본 릴리스 플래그로 컴파일한 미출시 개발 빌드입니다. Redis는 릴리스 태그에서 기본 make 명령으로 빌드한 8.10.2 버전입니다(VADD, VSIM). 두 엔진 모두 HNSW 그래프를 구축합니다.
• 인덱스 설정. 두 엔진 모두 코사인 유사도와 M=16, ef_construction=200인 HNSW를 명시적으로 설정했습니다. 이 값은 각 엔진의 기본값이기도 합니다.
• 정밀도. 두 엔진 모두 전체 정밀도 float32 벡터를 사용했습니다. Redis는 기본적으로 8비트 양자화를 사용하므로 NOQUANT 옵션으로 실행했습니다.
• 머신. Azure Standard_D160alds_v7 한 대(AMD EPYC 9V45, vCPU 160개)를 사용했습니다. 두 서버는 동일한 vCPU 128개에, 부하 생성기는 나머지 32개에 고정했으며, 모든 통신은 루프백으로 이루어졌습니다. HotKV는 스레드 128개로, Redis는 기본 I/O 스레드 설정으로 실행했습니다. 1, 4, 8, 16을 시도해 보았지만 이 설정은 일관된 차이를 만들지 않았습니다.
• 부하 생성기. 클라이언트 연결마다 프로세스 하나를 두었고, 각 프로세스는 처리 중인 요청을 하나씩 유지했으며, 요청은 측정 구간 전에 미리 만들어 두었습니다. 어느 실행에서든 가장 바쁜 부하 생성기 프로세스가 사용한 CPU는 CPU 하나의 8%였으므로, 클라이언트가 한계를 결정한 적은 없습니다.

절차

검색 깊이(ef) 40, 80, 150, 300(더 큰 인덱스에서는 500도 포함)에 대해, 클라이언트 1, 2, 4, 8, 16, 32, 50, 100개로 쿼리 1,000개를 반복 실행했습니다: 1초 워밍업 후 4초를 측정하는 과정을 각각 3회 수행했으며, 두 엔진의 실행 순서는 번갈아 바꿨습니다. 보고하는 값은 중앙값입니다. 재현율은 연결 하나로 별도로 측정했습니다. HotKV는 모든 실행에서 연결 32개로 로드했습니다. Redis 인덱스는 연결 32개와 VADD ... CAS 방식으로 한 번만 구축해 저장했고, 측정에는 저장된 인덱스를 로드해 사용했습니다. 스크립트와 모든 시행 결과는 벤치마크 저장소에 있습니다.

결과

동일한 재현율 목표에서의 비교

두 엔진은 같은 ef에서 같은 재현율에 도달하지 않으므로, 공통의 최소 재현율 목표에서 처리량을 비교합니다: 각 목표에 대해, 그 목표에 도달하는 측정된 검색 깊이 중 가장 빠른 깊이를 사용합니다. 도달한 깊이와 재현율은 조금씩 다르므로 표에 함께 표시했습니다. 보간이 아니라 실제로 측정한 깊이를 사용합니다. 벡터 999,000개에서의 초당 쿼리 수:

지연 시간 중앙값은 HotKV / Redis 순입니다. 90% 목표에서도 같은 패턴이 나타났습니다: 클라이언트 100개에서 초당 쿼리 90,003개 대 7,973개(11.3배)였으며, 둘 다 ef 40에서 측정했습니다.

모든 검색 깊이

벡터 999,000개에서의 초당 쿼리 수입니다. 벡터 100,000개에서도 패턴은 같습니다. 재현율 95%에서 HotKV는 클라이언트 1개일 때 Redis의 1.5배(1,816 대 1,214), 100개일 때 8.9배(63,247 대 7,119)의 초당 쿼리 수를 처리했습니다.

이 중 노이즈는 얼마나 되는가

각 셀은 3회 시행의 중앙값입니다. 셀의 절반은 최저 시행과 최고 시행 간 편차가 중앙값의 1.3% 이하였고, 10개 중 9개는 7% 이하였으며, 가장 큰 편차는 26%였습니다(Redis, 벡터 100,000개, ef 300, 클라이언트 50개). 보고서에 모든 시행이 나와 있습니다.

재현율은 인덱스 빌드마다 한 번씩 측정했습니다. 벡터 100,000개에서 각 엔진의 독립적인 빌드 3개는 같은 깊이에서 최대 0.013까지 차이가 났으므로, HotKV의 더 높은 재현율은 ef 300까지는 분명하지만, 더 작은 인덱스의 ef 500에서는 빌드 간 변동 범위 안에 있습니다.

로딩과 메모리

각각 연결 32개로 로드했을 때, 벡터 999,000개를 로드하는 데 HotKV는 188초(초당 5,325개), Redis는 935초(초당 1,069개)가 걸렸으며, 여기에는 부하 생성기가 각 벡터를 포맷하는 데 쓴 시간이 포함됩니다. 벡터 100,000개에서는 15초 대 57초였습니다. 벡터 20,000개로 확인한 결과 Redis는 CAS 옵션을 사용할 때 사용하지 않을 때보다 빠르게 로드했으므로(초당 벡터 2,279개 대 1,488개), 이 옵션을 사용했습니다. Redis 로딩은 이전 단계에서 Redis를 vCPU 4개에 고정한 상태로, 같은 머신에서 다른 점검이 돌아가는 동안 이루어졌습니다. HotKV는 vCPU 128개에서 단독으로 로딩했습니다. 따라서 Redis의 로딩 시간은 속도의 하한이며 동일 조건의 비교가 아닙니다.

벡터 999,000개를 로드한 후 HotKV 프로세스는 6.77 GB, Redis 프로세스는 7.01 GB를 차지했습니다.

이 테스트에서 Redis 8.10.2를 제한하는 요인

Redis 벡터 세트는 각 검색을 별도의 스레드에서 실행하지만, HNSW 코드에는 고정된 수의 스레드 슬롯(Redis 컴파일 시 설정되는 32개)이 있으며, 벡터 추가는 메인 스레드에서 이루어집니다. 저희 실행에서 클라이언트 32개 이상부터 Redis는 머신의 vCPU 중 6개에서 30개 사이를 가동했으며 처리량은 정체되어 있었습니다. HotKV는 ef 80, 클라이언트 100개에서 약 92개의 vCPU를 가동했으며 처리량은 여전히 증가하고 있었습니다. 이는 이 머신에서 각 엔진이 보이는 동작이며, 벤치마크가 설정한 것이 아닙니다.

한계

이는 위의 버전과 구성에 대해 HotKV Ltd가 측정한 결과이며, 모든 Redis 배포에 대한 주장이 아닙니다.

테스트 구성

• 개발 빌드. 커밋 c8dafd37 빌드는 릴리스가 아닌 개발 빌드입니다.
• 데이터셋 하나, 머신 한 대. 1,536차원 OpenAI 임베딩, 상위 10개만, float32, 코사인. 다른 차원, 데이터, 하드웨어에서는 배수가 달라질 수 있습니다.
• 클라이언트가 머신을 공유합니다. 부하 생성기는 별도의 vCPU에서 실행되었지만 메모리 시스템과 라스트 레벨 캐시를 서버와 공유했습니다.
• 영속성 비활성화. 두 서버 모두 스냅샷이나 추가 전용 파일(append-only file)을 기록하지 않았습니다.

측정하지 않은 항목

• Redis의 8비트 모드. Redis는 기본적으로 8비트로 양자화된 벡터를 저장하며, 이 방식은 메모리를 덜 사용합니다. 저희는 float32 대 float32 조건으로 비교했습니다.
• Redis Query Engine. Redis는 FT.CREATE 및 FT.SEARCH 명령을 통한 벡터 검색도 제공합니다. 저희는 벡터 세트만 테스트했으므로, 이 결과는 Query Engine에 대해 아무것도 말해 주지 않습니다.
• Redis 로딩과 재로딩. Redis 인덱스는 이전 실행에서 Redis를 vCPU 4개에 고정한 상태로 구축한 뒤 저장하고 측정 시 다시 불러왔으므로, Redis의 로딩 시간은 하한이며 HotKV와 동일 조건으로 비교할 수 없습니다. 벡터 20,000개 점검에서 다시 불러온 인덱스 검색은 새로 구축한 인덱스보다 약 10% 느렸으므로, Redis의 쿼리 수치도 그만큼 낮게 나왔을 수 있습니다.

직접 사용해 보십시오

벡터 검색은 HotKV의 프롬프트 캐시와 같은 서버에 내장되어 있으며, 같은 벡터 인덱스가 시맨틱 캐시와 에이전트 메모리를 뒷받침합니다. 벡터 검색은 모든 HotKV Cloud 플랜에 포함되며, 프롬프트 캐시, 시맨틱 캐시, 에이전트 메모리는 Performance 플랜 이상에서 제공됩니다. HotKV Cloud에서 시작하거나, 자체 임베딩으로 벤치마크해 보려면 영업팀에 문의하십시오.