Quanta RAM serve per un indice RAG familiare multilingue?
Un indice RAG familiare multilingue spesso rientra in 16–32 GB di RAM, ma il numero di chunk e la progettazione dell’indice contano più del solo numero di lingue.
Un archivio domestico con 500.000 chunk può usare un embedding multilingue per chunk anziché una copia per ogni lingua. La memoria continua comunque a crescere a causa delle dimensioni dei vettori, dei collegamenti del grafo, dei metadati, delle cache, dei reranker e del modello generativo. L’obiettivo utile è quindi un working set di picco misurato con margine, non una regola “gigabyte per lingua” sotto carico massimo.
Inizia dai vettori, poi aggiungi la struttura di ricerca
La memoria grezza dei vettori è data dal numero di chunk moltiplicato per le dimensioni e i byte per valore. In float32, 500.000 vettori con 768 dimensioni contengono circa 1,54 GB di coordinate. Il float16 dimezza il carico delle coordinate, anche se è necessario verificare il supporto del database e il comportamento in termini di accuratezza.
Una panoramica sull’indicizzazione con grafo HNSW spiega perché HNSW mantiene un grafo di connessioni tra vicini per una ricerca approssimata veloce. Queste connessioni, gli ID, l’allineamento e l’overhead dell’allocator si aggiungono al calcolo dei vettori grezzi.
I filtri sui metadati, gli ID dei documenti, le cache di testo e le strutture duplicate durante la compilazione possono superare le aspettative. Un database basato su disco può comunque mantenere in memoria le pagine del grafo più utilizzate, mentre un motore in memoria può conservare quasi l’intero indice. I vettori grezzi sono il livello minimo, non il requisito RAM finale.
La copertura multilingue modifica i chunk più dell’aritmetica
Un modello di embedding multilingue mappa diverse lingue nello stesso spazio vettoriale, quindi l’aggiunta di una lingua non duplica automaticamente ogni vettore. La RAM aumenta quando le copie tradotte vengono suddivise in chunk separatamente, si mantengono indici specifici per lingua o la tokenizzazione produce più chunk per gli stessi documenti.
La ricerca sugli embedding multilingue valuta rappresentazioni condivise tra molte lingue, supportando progettazioni con un unico indice quando il modello scelto allinea adeguatamente tali lingue. La qualità della copertura può variare da una lingua all’altra anche quando la memoria non cambia.
Anche il generatore e il reranker competono per la memoria di sistema. Un server da 16 GB può contenere un indice moderato, ma iniziare a usare pesantemente il paging quando un LLM, un processo OCR e la cache del database vengono eseguiti insieme. Una maggiore quantità di RAM non corregge un recupero multilingue debole; impedisce soltanto che la pressione sulla memoria distorca il test.
Quando l’intervallo 16–32 GB non è più sufficiente
sedici gigabyte sono plausibili per centinaia di migliaia di vettori compatti con testo su disco e un piccolo modello locale. Trentadue gigabyte sono un punto di partenza più sicuro per circa un milione di vettori da 768 dimensioni, oltre ai servizi. Dimensioni maggiori, più repliche, indici separati per lingua o un LLM residente più grande possono giustificare 64 GB o più.
Una discussione sulla capacità relativa alla memoria degli indici HNSW mostra che i byte dei vettori grezzi possono rappresentare solo una frazione della memoria totale di HNSW una volta incluse le strutture del grafo. Le scelte implementative rendono inaffidabile qualsiasi rapporto universale.
Questi intervalli non valgono quando il database utilizza compressione, memory mapping, quantizzazione del prodotto o un grafo configurato in modo molto diverso. Inoltre, possono non valere durante la compilazione dell’indice, se il builder conserva temporaneamente sia le copie vecchie sia quelle nuove. Misura separatamente i picchi durante la ricerca a regime e la ricostruzione.
Dimensiona la RAM a partire da un working set misurato
Calcola prima i vettori grezzi, poi importa il dieci percento del corpus previsto con dimensioni finali, metadati e parametri dell’indice. Misura la memoria residente dopo una ricerca a regime, query simultanee e una ricostruzione. Moltiplica solo i componenti che scalano linearmente, quindi riserva almeno il 25 percento di margine operativo.
Esegui il prototipo accanto al carico di lavoro previsto per il database vettoriale domestico, perché i picchi del modello e del database potrebbero sovrapporsi. Registra anche l’attività di swap e il tasso di page fault.
Scegli 16 GB solo quando il picco estrapolato rimane al di sotto di circa 12 GB; scegli 32 GB quando rimane al di sotto di circa 24 GB. Passa a una capacità superiore quando le ricostruzioni o l’inferenza simultanea superano tale soglia. Ricalcola dopo aver modificato la suddivisione in chunk o le dimensioni degli embedding.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Come misurare la qualità del recupero RAG locale e interpretare recall, precisione e copertura delle citazioni
Crea un set di test RAG locale, calcola le metriche di base del recupero, interpretane i compromessi e verifica se le affermazioni nelle risposte...
Perché l’elaborazione delle funzionalità della casa intelligente diventa più importante all’aumentare del numero di sensori con la stessa frequenza di campionamento?
Monitora i calcoli per sensore e tra sensori all’aumentare del numero di dispositivi, identifica i costi di fusione non lineari e valuta le prestazioni...
Perché il costo della valutazione RAG diventa più importante con l’aumentare della libreria di documenti, a parità di volume di query?
Comprendi perché la crescita del corpus aumenta lo sforzo di valutazione del RAG senza un aumento delle query degli utenti e come i test...
