Um índice RAG familiar multilingue cabe frequentemente em 16–32 GB de RAM, mas a contagem de segmentos e o desenho do índice são mais importantes do que o número de idiomas por si só.
Um arquivo doméstico com 500 000 segmentos pode usar uma incorporação multilingue por segmento, em vez de uma cópia por idioma. A memória continua a crescer devido às dimensões dos vetores, às ligações do grafo, aos metadados, às caches, aos rerankers e ao modelo de geração. O objetivo útil é, portanto, um conjunto de trabalho máximo medido com margem, e não uma regra de “gigabytes por idioma” sob carga máxima.
Comece pelos vetores e depois adicione a estrutura de pesquisa
A memória bruta dos vetores corresponde ao número de segmentos multiplicado pelas dimensões e pelos bytes por valor. Em float32, 500 000 vetores com 768 dimensões contêm cerca de 1,54 GB de coordenadas. O float16 reduz para metade essa carga de coordenadas, embora seja necessário verificar o suporte da base de dados e o comportamento da precisão.
Uma explicação geral sobre a indexação de grafos HNSW explica por que motivo o HNSW mantém um grafo de ligações entre vizinhos para uma pesquisa aproximada rápida. Essas ligações, os IDs, o alinhamento e a sobrecarga do alocador ficam acima do cálculo dos vetores brutos.
Os filtros de metadados, os IDs dos documentos, as caches de texto e as estruturas de compilação duplicadas podem ultrapassar as expectativas. Uma base de dados apoiada em disco pode ainda manter em memória as páginas quentes do grafo, enquanto um motor em memória pode conservar quase todo o índice. Os vetores brutos são o mínimo, não o requisito final de RAM.
A cobertura multilingue altera mais os segmentos do que a aritmética
Um modelo de incorporação multilingue mapeia vários idiomas para um único espaço vetorial, pelo que adicionar um idioma não duplica automaticamente todos os vetores. A RAM aumenta quando as cópias traduzidas são segmentadas separadamente, quando são mantidos índices específicos por idioma ou quando a tokenização produz mais segmentos para os mesmos documentos.
A investigação sobre incorporações multilingues avalia representações partilhadas entre vários idiomas, apoiando arquiteturas com um único índice quando o modelo escolhido alinha adequadamente esses idiomas. A qualidade da cobertura pode variar consoante o idioma, mesmo quando a memória não varia.
O gerador e o reranker também competem pela memória do sistema. Um servidor com 16 GB pode suportar um índice moderado, mas começar a usar intensivamente o armazenamento quando um LLM, um processo de OCR e a cache da base de dados são executados em conjunto. Mais RAM não corrige uma recuperação multilingue fraca; apenas impede que a pressão sobre a memória distorça o teste.
Quando o intervalo de 16–32 GB deixa de se aplicar
Dezasseis gigabytes são plausíveis para centenas de milhares de vetores compactos, com texto apoiado em disco e um modelo local pequeno. Trinta e dois gigabytes são um ponto de partida mais seguro perto de um milhão de vetores com 768 dimensões, além dos serviços. Dimensões superiores, várias réplicas, índices separados por idioma ou um LLM maior residente podem justificar 64 GB ou mais.
Uma análise sobre a memória dos índices HNSW mostra que os bytes dos vetores brutos podem representar apenas uma fração da memória total do HNSW quando as estruturas do grafo são incluídas. As escolhas de implementação tornam insegura qualquer proporção universal.
Estes intervalos deixam de ser válidos quando a base de dados utiliza compressão, mapeamento de memória, quantização de produto ou um grafo configurado de forma muito diferente. Também deixam de ser válidos durante a construção do índice, se o construtor mantiver temporariamente cópias antigas e novas. Meça separadamente os picos da pesquisa em funcionamento e da reconstrução.
Dimensione a RAM a partir de um conjunto de trabalho medido
Calcule primeiro os vetores brutos e, em seguida, ingira dez por cento do corpus pretendido com as dimensões finais, os metadados e os parâmetros do índice. Meça a memória residente após uma pesquisa aquecida, consultas simultâneas e uma reconstrução. Multiplique apenas os componentes que variam linearmente e reserve, pelo menos, 25% de margem operacional.
Execute o protótipo juntamente com a carga de trabalho planeada da base de dados vetorial doméstica, porque os picos do modelo e da base de dados podem coincidir. Registe também a atividade de swap e a taxa de falhas de página.
Escolha 16 GB apenas quando o pico extrapolado se mantiver abaixo de aproximadamente 12 GB; escolha 32 GB quando se mantiver abaixo de aproximadamente 24 GB. Opte por mais memória quando as reconstruções ou a inferência simultânea ultrapassarem esse limite. Recalcule depois de alterar a segmentação ou as dimensões das incorporações.
Centro de Tecnologia e IA
Mais para Ler

Como medir a qualidade da recuperação RAG local e interpretar a cobertura da recuperação, da precisão e das citações
Crie um conjunto de teste RAG local, calcule as principais métricas de recuperação, interprete os seus compromissos e audite se as afirmações das respostas...

Porque é que a computação das funcionalidades de casa inteligente se torna mais importante à medida que aumenta o número de sensores à mesma taxa de amostragem?
Monitorize o processamento por sensor e entre sensores à medida que o número de dispositivos aumenta, identifique os custos não lineares da fusão e...

Porque é que o custo da avaliação de RAG se torna mais importante à medida que a biblioteca de documentos cresce, com o mesmo volume de consultas?
Compreenda por que o crescimento do corpus aumenta o esforço de avaliação do RAG sem mais consultas dos utilizadores e como os testes estratificados...

