Dlaczego zadania tworzenia osadzeń spowalniają interaktywny czat AI w domu?

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.

Why Do Embedding Jobs Slow Interactive Home AI Chat?

Zadania tworzenia embeddingów spowalniają interaktywny czat AI w domu, ponieważ długie zadania wykonywane w tle konkurują z czatem o czas akceleratora, przygotowanie danych przez CPU, pamięć i dostęp do pamięci masowej.

Osobista baza wiedzy może dzielić tysiące dokumentów na fragmenty, tokenizować je, uruchamiać model embeddingów, normalizować wektory oraz zapisywać indeksy przez kilka minut lub nawet godzin. Żądania czatu pojawiają się nieprzewidywalnie i wymagają krótkiego czasu do wygenerowania pierwszego tokena, podczas gdy potok embeddingów preferuje duże partie maksymalizujące przepustowość. Jeśli oba zadania współdzielą jeden GPU, CPU, pulę RAM-u lub urządzenie NVMe, zadanie wykonywane w tle może zająć kolejki, zanim prompt użytkownika dotrze do modelu. Poniższe sekcje omawiają każdy punkt rywalizacji i pokazują, jak chronić interaktywny czas odpowiedzi.

Potoki embeddingów to długotrwałe zadania wsadowe

Pobieranie dokumentów obejmuje więcej niż jedno wywołanie modelu. Odczytuje pliki, wyodrębnia tekst, dzieli treść na fragmenty, tokenizuje partie danych, oblicza wektory oraz zapisuje metadane i struktury indeksów.

Duże partie zwiększają przepustowość przetwarzania wsadowego, ale mogą wydłużyć czas, po którym żądanie wrażliwe na opóźnienia otrzyma czas akceleratora.

Początkowy import biblioteki lub pełne ponowne indeksowanie znacznie różnią się więc od utworzenia embeddingu jednej nowej notatki po jej zapisaniu.

Wstępne przetwarzanie czatu i obliczenia embeddingów konkurują o ten sam akcelerator

Interaktywny czat rozpoczyna się od wstępnego przetwarzania promptu, które intensywnie wykorzystuje moc obliczeniową. Modele embeddingów również przetwarzają pełne sekwencje tokenów przez warstwy transformera, często w dużych partiach wykonywanych równolegle.

Badania nad zakłóceniami podczas wstępnego przetwarzania promptu pokazują, dlaczego intensywne obliczenia związane z promptem mogą spowalniać równoczesne dekodowanie i obsługę pierwszego tokena.

Jeśli środowisko uruchomieniowe nie stosuje wywłaszczania ani priorytetyzacji czatu, krótkie pytanie może czekać za bieżącą partią embeddingów, mimo że sam model czatu jest już załadowany.

Mniejsze partie embeddingów skracają najdłuższy czas blokowania, ale mogą obniżyć całkowitą przepustowość pobierania dokumentów.

Oddzielne modele zwiększają presję na pamięć

Model czatu, model embeddingów, reranker i środowisko uruchomieniowe wektorów mogą przechowywać w pamięci własne wagi i pule alokatora. Ich łączny rozmiar zmniejsza ilość miejsca na pamięć podręczną KV czatu i obsługę równoczesnych użytkowników.

Artykuł ZimaSpace dotyczący konkurencji o pamięć akceleratora wyjaśnia, dlaczego niskie wykorzystanie mocy obliczeniowej nie oznacza, że pozostało wystarczająco dużo pamięci na interaktywne żądanie.

Gdy pamięci zaczyna brakować, system może ograniczyć równoczesność czatu, usunąć model z pamięci, przenieść część warstw poza akcelerator lub uruchomić ponowne ładowanie modelu po zakończeniu etapu tworzenia embeddingów.

W niektórych architekturach możliwe jest używanie jednego współdzielonego kodera do wyszukiwania i czatu, ale oddzielne modele wyspecjalizowane w konkretnych zadaniach często zapewniają lepsze wyniki i wiążą się z odrębnymi kosztami pamięci.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Praca CPU i pamięci masowej może opóźniać wyszukiwanie przed wnioskowaniem

Tokenizacja, analiza plików PDF, OCR, tworzenie sum kontrolnych i zapisy w bazie wektorów mogą nasycać wątki CPU oraz generować losowe operacje wejścia-wyjścia na tej samej pamięci masowej, na której znajdują się pliki modeli i historia czatu.

Indeksowanie w tle powoduje rywalizację podczas indeksowania, nawet gdy żaden widoczny dla użytkownika wykres użycia CPU nie pokazuje pełnego nasycenia.

Wyszukiwanie na potrzeby czatu może wtedy czekać na blokady bazy danych, brak danych w pamięci podręcznej lub zajętą kolejkę NVMe, zanim prompt zostanie złożony.

Reguły priorytetów i dopuszczania chronią czat

Planuj indeksowanie w ograniczonych partiach, rób przerwy między partiami, ogranicz jego równoczesność i dopuszczaj nowe zadania w tle tylko wtedy, gdy kolejki interaktywne są puste lub znajdują się poniżej ustalonego progu.

Llumnix wykorzystuje dynamiczne priorytety do obsługi żądań o różnych wymaganiach dotyczących opóźnień i zasobów.

Serwer domowy może wdrożyć prostszą zasadę: czat i głos otrzymują dostęp natychmiast, natomiast embeddingi działają z niższym priorytetem lub w oknach konserwacyjnych.

Mierz zakłócenia zamiast zgadywać

Rejestruj czas czatu do wygenerowania pierwszego tokena, opóźnienie między tokenami, opóźnienie wyszukiwania, liczbę fragmentów embeddingów na sekundę, użycie pamięci GPU, nasycenie CPU i opóźnienie pamięci masowej — zarówno przy wyłączonym, jak i włączonym zadaniu tworzenia embeddingów.

Jeśli czat czeka tylko na granicach partii, zmniejsz rozmiar partii lub włącz wywłaszczanie. Jeśli pojawiają się ponowne ładowania modeli, zmniejsz liczbę modeli przechowywanych w pamięci lub rozdziel procesy robocze. Jeśli wyszukiwanie się zatrzymuje, przenieś zapisy indeksu lub pliki modeli na inną ścieżkę wejścia-wyjścia.

Przydatnym celem nie jest możliwie najszybsze ponowne indeksowanie. Chodzi o uzyskanie największej szybkości pobierania dokumentów w tle przy zachowaniu interaktywnego czasu odpowiedzi gospodarstwa domowego w jego normalnym zakresie.

Po utworzeniu biblioteki przełącz się z regularnych pełnych skanów na przyrostowe wykrywanie zmian, aby obciążenie pracą w tle pozostało proporcjonalne do ilości nowej treści.

FAQ

Czy oddzielny model embeddingów zawsze spowolni czat?

Nie. Może pozostawać bezczynny lub działać na innym urządzeniu. Spowolnienie pojawia się wtedy, gdy współdzielone są zasoby obliczeniowe, pamięć, CPU, pamięć masowa lub ścieżki planowania.

Czy zmniejszenie rozmiaru partii embeddingów zawsze pomaga?

Skraca pojedyncze okresy blokowania, ale może zwiększyć narzut i całkowity czas pobierania dokumentów. Priorytety i wywłaszczanie mogą pozwolić zachować większą przepustowość.

Czy embeddingi powinny działać w nocy?

Duże importy często powinny być wykonywane nocą. Aktualizacje przyrostowe mogą działać w ciągu dnia, jeśli ich zakres jest ograniczony i ustępują miejsca żądaniom interaktywnym.