Busca vetorial: HotKV vs. vector sets do Redis 8, de 1 a 100 clientes

A busca vetorial sustenta muitos recursos de IA: recuperação para RAG, cache semântico, memória de agentes. O Redis 8 traz vector sets, um tipo de dados em beta, integrados ao servidor, então é a comparação óbvia. Carregamos os mesmos embeddings da OpenAI no HotKV e no Redis 8.10.2, executamos as mesmas 1.000 consultas em cada um com 1 a 100 conexões de cliente simultâneas e medimos quão precisas eram as respostas, quantas consultas por segundo cada motor atendia e quanto tempo cada consulta levava.

Em resumo. Em 999.000 vetores, com recall mínimo de 95%, o HotKV atendeu 1,4 vez as consultas por segundo do Redis com um cliente e 7,9 vezes com 100 clientes (51.146 contra 6.510). Com 99% de recall, as razões foram 1,8 e 5,4. A latência mediana do HotKV foi menor em todas as quantidades de clientes. O throughput do Redis já tinha estabilizado com 32 clientes, enquanto o do HotKV continuou crescendo até 100. O HotKV carregou os vetores cerca de 5 vezes mais rápido, e o recall dele foi maior em toda profundidade de busca. É um conjunto de dados em uma máquina, o build do HotKV é um build de desenvolvimento não lançado, e não medimos o Query Engine do Redis nem o modo de 8 bits dele, então leia isto como uma medição, não como um ranking.

O que testamos

Dados

As primeiras 999.000 linhas do dbpedia-entities-openai-1M, de Kumar Shivendu e Nirant Kasliwal (licença MIT) e, para um índice menor, as primeiras 100.000 linhas. As linhas são entidades da DBpedia com embeddings gerados pelo text-embedding-ada-002 da OpenAI, com 1.536 dimensões. As últimas 1.000 linhas são as consultas, então nenhuma linha aparece nos dois conjuntos. O gabarito são os 10 vizinhos mais próximos exatos de cada consulta, calculados por força bruta em ponto flutuante de 64 bits, independentemente de qualquer um dos motores, de modo que ambos são avaliados contra o mesmo gabarito.

Motores e configurações

• Motores. Commit c8dafd37 do HotKV (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH), um build de desenvolvimento não lançado, compilado com as flags de release padrão, não com -march=native. Redis 8.10.2 compilado a partir da tag de release com um make padrão (VADD, VSIM). Ambos constroem grafos HNSW.
• Configurações do índice. Similaridade de cosseno, HNSW com M=16 e ef_construction=200 em ambos, definidos explicitamente. Esses valores também são os padrões de cada motor.
• Precisão. Vetores float32 de precisão total em ambos. O Redis usa por padrão quantização de 8 bits, então rodou com NOQUANT.
• Máquina. Uma Azure Standard_D160alds_v7 (AMD EPYC 9V45, 160 vCPUs). Os dois servidores foram fixados nas mesmas 128 vCPUs e os geradores de carga nas outras 32, tudo via loopback. O HotKV rodou com 128 threads e o Redis com as threads de E/S padrão dele. Testamos 1, 4, 8 e 16, e a configuração não fez diferença consistente.
• Gerador de carga. Um processo por conexão de cliente, cada um mantendo uma requisição em andamento, com as requisições montadas antes da parte cronometrada. O processo gerador de carga mais ocupado usou 8% de uma CPU em qualquer execução, então o cliente nunca definiu o limite.

Procedimento

Para as profundidades de busca (ef) de 40, 80, 150 e 300, e 500 no índice maior, executamos as 1.000 consultas repetidamente com 1, 2, 4, 8, 16, 32, 50 e 100 clientes: um segundo de aquecimento, depois quatro segundos contados, três vezes cada, alternando a ordem dos dois motores. Informamos a mediana. O recall foi medido separadamente, por uma única conexão. O HotKV foi carregado por 32 conexões em todas as execuções. Os índices do Redis foram construídos uma vez, por 32 conexões com VADD ... CAS, salvos e carregados para as medições. Os scripts e cada execução estão no repositório do benchmark.

Resultados

Metas de recall equivalentes

Os dois motores não atingem o mesmo recall com o mesmo ef, então comparamos o throughput em metas mínimas de recall compartilhadas: para cada meta, a profundidade de busca medida mais rápida que a atinge. As profundidades e os recalls atingidos estão nas tabelas, porque diferem um pouco. Isso usa profundidades medidas, não interpolação. Consultas por segundo em 999.000 vetores:

A latência mediana é HotKV / Redis. O mesmo padrão valeu para uma meta de 90%: 90.003 contra 7.973 consultas por segundo com 100 clientes (11,3 vezes), ambos com ef 40.

Todas as profundidades de busca

Consultas por segundo em 999.000 vetores. Em 100.000 vetores o padrão é o mesmo. Com 95% de recall, o HotKV atendeu 1,5 vez as consultas por segundo do Redis com um cliente (1.816 contra 1.214) e 8,9 vezes com 100 (63.247 contra 7.119).

Quanto disso é ruído

Cada célula é a mediana de três execuções. Metade das células teve uma dispersão entre a menor e a maior execução de 1,3% da mediana ou menos, nove em cada dez de 7% ou menos, e a maior foi de 26% (Redis, 100.000 vetores, ef 300, 50 clientes). O relatório lista todas as execuções.

O recall foi medido uma vez por construção de índice. Três construções independentes de cada motor em 100.000 vetores diferiram em até 0,013 na mesma profundidade, então o recall maior do HotKV é claro até ef 300 e está dentro da variação entre construções em ef 500 no índice menor.

Carga e memória

Carregados por 32 conexões cada, o HotKV levou 188 segundos para os 999.000 vetores (5.325 por segundo) e o Redis, 935 segundos (1.069 por segundo), incluindo o tempo que o gerador de carga gastou formatando cada vetor. Em 100.000 vetores foram 15 segundos contra 57. O Redis carregou mais rápido com CAS do que sem ele em uma verificação com 20.000 vetores (2.279 contra 1.488 vetores por segundo), então o usamos. A carga do Redis ocorreu em uma etapa anterior, com o Redis fixado em quatro vCPUs enquanto outras verificações rodavam na máquina; o HotKV carregou sozinho em 128 vCPUs. O tempo de carga do Redis é, portanto, um limite inferior de sua velocidade, não uma comparação em condições iguais.

Depois de carregar 999.000 vetores, o processo do HotKV ocupava 6,77 GB e o do Redis, 7,01 GB.

O que limita o Redis 8.10.2 aqui

Os vector sets do Redis executam cada busca em uma thread própria, mas o código do HNSW tem um número fixo de slots de thread (32, definido quando o Redis é compilado), e os vetores são adicionados na thread principal. Nas nossas execuções, a partir de 32 clientes, o Redis manteve entre 6 e 30 das vCPUs da máquina ocupadas e o throughput dele tinha estabilizado. O HotKV manteve cerca de 92 vCPUs ocupadas com 100 clientes e ef 80, e o throughput dele ainda estava crescendo. É assim que cada motor se comporta nesta máquina, não algo que o benchmark configurou.

Limitações

Estas são medições da HotKV Ltd das versões e da configuração acima, não uma afirmação sobre toda implantação do Redis.

A configuração do teste

• Um build de desenvolvimento. O commit c8dafd37 é um build de desenvolvimento, não uma versão lançada.
• Um conjunto de dados, uma máquina. Embeddings da OpenAI de 1.536 dimensões, apenas os 10 primeiros resultados, float32, cosseno. Outras dimensões, dados ou hardware podem dar razões diferentes.
• O cliente divide a máquina. Os geradores de carga rodaram em vCPUs separadas, mas compartilharam o sistema de memória e o cache de último nível com os servidores.
• Persistência desativada. Nenhum dos servidores gravou snapshots nem um arquivo append-only.

O que não foi medido

• O modo de 8 bits do Redis. O Redis armazena por padrão vetores quantizados de 8 bits, o que usa menos memória. Comparamos float32 com float32.
• O Redis Query Engine. O Redis também oferece busca vetorial por meio de FT.CREATE e FT.SEARCH. Testamos apenas vector sets, então os resultados não dizem nada sobre o Query Engine.
• Carga e recarga do Redis. Os índices do Redis foram construídos em uma execução anterior com o Redis fixado em quatro vCPUs, salvos e recarregados para as medições, então os tempos de carga do Redis são um limite inferior e não são comparáveis em condições iguais com os do HotKV. Buscar em um índice recarregado foi cerca de 10 por cento mais lento do que em um recém-construído em uma verificação com 20.000 vetores, de modo que os números de consultas do Redis podem estar baixos em proporção semelhante.

Experimente você mesmo

A busca vetorial está integrada ao mesmo servidor do cache de prompts do HotKV, e o mesmo índice vetorial sustenta o cache semântico e a memória de agentes. A busca vetorial está incluída em todos os planos do HotKV Cloud. O cache de prompts, o cache semântico e a memória de agentes vêm com o plano Performance e superiores. Comece no HotKV Cloud ou fale com as vendas para fazer um benchmark com os seus próprios embeddings.