Qdrant e Milvus: RAM pode mudar o resultado

Para uma aplicação de RAG, Qdrant é um ponto de partida forte se vetores e índice couberem na RAM; sob pressão de memória, vale testar Milvus com índice compacto antes de decidir. No benchmark reproduzível VECTOR-ADIS, a configuração Qdrant teve throughput médio 52% maior nos testes em memória, mas a configuração Milvus com IVF_SQ8 chegou a 2,8 vezes o throughput de Qdrant com HNSW em mmap no regime mais pressionado.

Essa mudança de posição é uma razão para dimensionar a comparação pela carga real, sem declarar um vencedor geral. Para escolher o banco do RAG, compare latência e vazão no mesmo patamar de recall, com a mesma coleção, os mesmos filtros e o mesmo limite de RAM; inclua inserção e atualização se o conteúdo muda durante o dia.

Quando a coleção deixa de caber confortavelmente na RAM

RAM e armazenamento de uma estação de teste delimitam as condições em que Qdrant e Milvus são comparados.

Na condição em memória, o teste mediu buscas sobre dados residentes; no extremo, a coleção, o índice e o processo passaram a disputar um orçamento limitado de memória. Entre esses pontos houve ainda um regime próximo do limite, no qual Qdrant continuou à frente. A virada apareceu junto com a pressão de memória e com outra escolha de índice e armazenamento.

O tamanho bruto dos embeddings é apenas parte da conta. Estruturas de busca, metadados, buffers do serviço e cache ocupam memória também. Uma amostra de documentos pode produzir latência excelente porque permanece residente, enquanto a coleção de produção exige leituras adicionais do armazenamento. Para a equipe, interessa observar a memória efetivamente consumida na consulta, inclusive sob concorrência, e deixar folga para a ingestão e os filtros.

O índice muda o custo da busca

IVF_SQ8 do Milvus compacta vetores, enquanto HNSW com mmap organiza a busca do Qdrant sob limites de memória.

O índice IVF_SQ8 do Milvus agrupa vetores e compacta cada dimensão em uma representação de 8 bits, segundo a documentação do IVF_SQ8. O parâmetro nprobe controla quantos grupos são examinados: ampliar a busca tende a melhorar o recall, mas aumenta a latência. Essa compactação ajuda a acomodar mais vetores no orçamento de memória, embora a aproximação e a quantização devam ser avaliadas na qualidade dos resultados.

Na configuração sob maior pressão de memória, Qdrant usou HNSW com dados mapeados por mmap. HNSW percorre conexões entre vizinhos, enquanto mmap permite acessar dados mantidos em arquivo conforme a necessidade. Assim, a comparação extrema coloca frente a frente estratégias distintas para lidar com RAM escassa. Ela mostra uma vantagem daquela configuração Milvus naquele conjunto de dados, sem estabelecer que qualquer instalação Milvus será mais rápida que qualquer instalação Qdrant.

Recall equivalente vem antes do placar de velocidade

Em um estudo experimental da Frontiers, os bancos rodaram em uma estação com 8 GB de RAM e limite de 4 GB por contêiner, usando Milvus com IVF_FLAT e Qdrant com HNSW. Com 10 mil embeddings de imagens CIFAR-10, Milvus alcançou Recall@5 de 1,00 e Qdrant, 0,88; com 5 mil embeddings STL-10, os valores foram 1,00 e 0,82. O trabalho mediu conjuntos residentes em memória, portanto esses resultados de recall não testam a inversão observada sob escassez de RAM.

O mesmo estudo registrou consultas mais rápidas do Qdrant em parte das condições. Ao ampliar a exploração do grafo HNSW, porém, o recall melhorou e a latência subiu: a configuração inicial veloz deixou de representar o mesmo nível de qualidade. A página de benchmarks do Qdrant também condiciona comparações de velocidade a patamares semelhantes de precisão. Para RAG, há ainda uma segunda checagem: recuperar vizinhos vetoriais não garante que os trechos necessários para responder às perguntas estejam entre os resultados.

Consulta rápida e atualização rápida são vantagens diferentes

Nas medições com CIFAR-10, Qdrant respondeu mais depressa às consultas top-k avaliadas, enquanto Milvus concluiu a carga inicial de vetores mais rapidamente; nas atualizações individuais, Qdrant levou vantagem. Essas medidas descrevem operações diferentes. Se o corpus é publicado em lotes grandes e consultado depois, a ingestão inicial pesa de um modo; se documentos são corrigidos continuamente, o custo de atualização durante as buscas merece peso próprio.

Também há diferença entre latência de uma consulta isolada e throughput com muitas consultas simultâneas. O primeiro indicador ajuda a estimar o tempo de resposta percebido por uma pessoa; o segundo mostra quantas requisições o serviço sustenta sob concorrência. No RAG, filtros por permissão, idioma ou tipo de documento podem alterar ambos. Comparar apenas uma coluna de requisições por segundo omite a carga que o banco terá de servir.

Onde começar a escolha

Se a coleção completa cabe na RAM com folga e o recall exigido é atingível, teste primeiro Qdrant para a carga de consultas planejada e mantenha Milvus como comparação no mesmo ambiente.
Se vetores e índice se aproximam do limite de memória, inclua Milvus com índice compacto e Qdrant com a política de armazenamento pretendida. O resultado sob pressão de RAM justifica essa prioridade de teste, mas o índice e o recall precisam entrar na decisão.
Se a base muda frequentemente, separe ingestão inicial de atualização contínua. A opção mais rápida para consultar pode ter outro custo para manter o conteúdo recente.

Essas condições formam uma árvore de decisão: primeiro verifique se a qualidade de recuperação é suficiente, depois se a configuração cabe no orçamento de memória e, por fim, qual delas atende à latência e à vazão da operação dominante. Uma opção que ganha apenas por reduzir recall não cumpre a mesma tarefa.

Um teste local que separa os efeitos

Use os próprios documentos e embeddings do RAG, preservando dimensões, métrica de distância, metadados, filtros e consultas entre os bancos. Fixe versões, recursos do nó e parâmetros dos índices. Monte uma referência de busca exata para medir recall dos vizinhos e um conjunto de perguntas com trechos esperados para avaliar a recuperação útil à resposta; as duas medidas capturam falhas diferentes.

Execute uma carga que caiba na RAM e outra próxima do limite previsto para produção. Registre tamanho dos vetores, índice, memória do processo e comportamento do cache.
Ajuste os parâmetros de busca até atingir recall comparável. Sob a mesma concorrência, compare latência mediana, cauda de latência e throughput, inclusive com os filtros reais.
Meça carga inicial, inserção incremental e atualização enquanto consultas continuam. Faça rodadas com cache aquecido e após reinício para distinguir o efeito do armazenamento.

Escolha a configuração que mantém os trechos necessários recuperáveis e cumpre os limites de memória e resposta no regime em que a coleção realmente operará. Se o resultado muda entre os dois regimes, a capacidade planejada deve refletir o crescimento esperado do corpus, e não apenas o desempenho do protótipo residente em RAM.