Ile pamięci RAM potrzeba do wielojęzycznego indeksu RAG dla rodziny?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Much RAM Is Needed for a Multilingual Family RAG Index? - Zima Store Online

Wielojęzyczny indeks RAG dla rodziny często mieści się w 16–32 GB pamięci RAM, ale liczba fragmentów i konstrukcja indeksu mają większe znaczenie niż sama liczba języków.

Domowe archiwum zawierające 500 000 fragmentów może używać jednego wielojęzycznego embeddingu na fragment zamiast osobnej kopii dla każdego języka. Zużycie pamięci nadal rośnie przez wymiary wektorów, połączenia grafu, metadane, pamięci podręczne, rerankery i model generujący. Dlatego warto dążyć do zmierzonego szczytowego zestawu roboczego z zapasem, a nie stosować zasady „gigabajty na język” przy maksymalnym obciążeniu.

Zacznij od wektorów, a następnie dodaj strukturę wyszukiwania

Surowe zużycie pamięci przez wektory to liczba fragmentów pomnożona przez liczbę wymiarów i liczbę bajtów na wartość. Przy formacie float32 500 000 wektorów o 768 wymiarach zawiera około 1,54 GB współrzędnych. Float16 zmniejsza o połowę rozmiar samych współrzędnych, ale należy zweryfikować obsługę tego formatu przez bazę danych oraz wpływ na dokładność.

Przegląd indeksowania grafowego HNSW wyjaśnia, dlaczego HNSW przechowuje graf połączeń między sąsiadami na potrzeby szybkiego przybliżonego wyszukiwania. Te połączenia, identyfikatory, wyrównanie i narzut alokatora zajmują dodatkową pamięć ponad surowe obliczenia dotyczące wektorów.

Filtry metadanych, identyfikatory dokumentów, pamięci podręczne tekstu i zduplikowane struktury tworzone podczas budowania indeksu mogą przekroczyć oczekiwania. Baza danych korzystająca z dysku nadal może przechowywać często używane strony grafu w pamięci, podczas gdy silnik działający w pamięci może zachowywać niemal cały indeks. Surowe wektory wyznaczają dolną granicę, a nie końcowe wymagania dotyczące pamięci RAM.

Obsługa wielu języków zmienia liczbę fragmentów bardziej niż same obliczenia

Wielojęzyczny model embeddingowy mapuje kilka języków do jednej przestrzeni wektorowej, więc dodanie języka nie powoduje automatycznego powielenia każdego wektora. Zużycie pamięci rośnie, gdy przetłumaczone kopie są dzielone na fragmenty osobno, utrzymywane są indeksy właściwe dla poszczególnych języków lub tokenizacja tworzy więcej fragmentów dla tych samych dokumentów.

Badania nad embeddingami wielojęzycznymi oceniają współdzielone reprezentacje w wielu językach, wspierając konstrukcje z jednym indeksem, gdy wybrany model odpowiednio dopasowuje te języki. Jakość obsługi może różnić się zależnie od języka, nawet jeśli zużycie pamięci pozostaje bez zmian.

Model generujący i reranker również konkurują o pamięć systemową. Serwer z 16 GB pamięci może pomieścić umiarkowany indeks, ale zacznie intensywnie korzystać z pamięci stronicowanej, gdy jednocześnie uruchomione zostaną LLM, proces OCR i pamięć podręczna bazy danych. Większa ilość pamięci RAM nie naprawi słabego wielojęzycznego wyszukiwania; zapobiegnie jedynie temu, by presja pamięci zniekształciła test.

Kiedy zakres 16–32 GB przestaje mieć zastosowanie

Szesnaście gigabajtów jest realną wartością dla setek tysięcy kompaktowych wektorów, tekstu przechowywanego na dysku i niewielkiego lokalnego modelu. Trzydzieści dwa gigabajty to bezpieczniejszy punkt wyjścia w przypadku około miliona wektorów o 768 wymiarach oraz dodatkowych usług. Większe wymiary, wiele replik, osobne indeksy językowe lub większy LLM działający stale w pamięci mogą uzasadniać 64 GB lub więcej.

Omówienie pamięci indeksu HNSW pokazuje, że surowe bajty wektorów mogą stanowić jedynie ułamek całkowitego zużycia pamięci HNSW po uwzględnieniu struktur grafowych. Wybór implementacji sprawia, że uniwersalny przelicznik jest niewiarygodny.

Podane zakresy zawodzą, gdy baza danych korzysta z kompresji, mapowania pamięci, kwantyzacji produktowej lub grafu skonfigurowanego zupełnie inaczej. Zawodzą również podczas budowania indeksu, jeśli narzędzie tymczasowo przechowuje stare i nowe kopie. Mierz osobno stabilne wyszukiwanie i szczytowe zużycie pamięci podczas przebudowy.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Dobierz pamięć RAM na podstawie zmierzonego zestawu roboczego

Najpierw oblicz rozmiar surowych wektorów, a następnie zaimportuj dziesięć procent docelowego korpusu, używając końcowych wymiarów, metadanych i parametrów indeksu. Zmierz pamięć rezydentną po rozgrzaniu wyszukiwania, przy równoczesnych zapytaniach i podczas jednej przebudowy indeksu. Mnoż przez współczynnik tylko te składniki, które rosną liniowo, a następnie pozostaw co najmniej 25% zapasu operacyjnego.

Uruchom prototyp obok planowanego obciążenia domowej bazy danych wektorowych, ponieważ maksymalne zużycie pamięci przez model i bazę danych może wystąpić jednocześnie. Zapisuj również aktywność pamięci wymiany i współczynnik błędów stron.

Wybierz 16 GB tylko wtedy, gdy ekstrapolowane zużycie szczytowe pozostaje poniżej około 12 GB; wybierz 32 GB, gdy pozostaje poniżej około 24 GB. Zwiększ tę wartość, gdy przebudowy indeksu lub równoczesne wnioskowanie przekroczą tę granicę. Wykonaj ponowne obliczenia po zmianie dzielenia tekstu na fragmenty lub wymiarów embeddingów.