Lokalne LLM.
Odpowiednio dobrane zasoby.
Od odpowiedniego modelu do obsługiwanej usługi AI: DAXS planuje lokalną infrastrukturę LLM, sprawdza sprzęt pod rzeczywistym obciążeniem i integruje rozwiązanie z istniejącym IT.
Serwer AI zaczyna się od profilu obciążenia.
Lokalny model językowy może opracowywać wewnętrzne teksty, wspierać szkice kodu lub działać jako część wyszukiwania wiedzy. Użyteczne rozwiązanie wymaga zgodności jakości modelu, dozwolonych ścieżek danych i oczekiwanego wykorzystania. DAXS zbiera te wymagania, planuje infrastrukturę i przejmuje instalację, integrację oraz uzgodnione utrzymanie wspólnie z Państwa IT lub jako odrębny zakres usług.
Zadanie i jakość
Jakie pytania, języki, dokumenty lub zadania programistyczne rozwiązanie ma obsługiwać? Krótki czat i analiza długich materiałów wymagają różnych modeli i kontekstów.
Wykorzystanie i oczekiwanie
Ile zapytań pojawia się jednocześnie? Jak szybko powinna rozpocząć się pierwsza reakcja i ile może trwać pełna odpowiedź? Sporadyczne pojedyncze zapytania i stale używana usługa zespołowa wymagają innych rezerw.
Dane i utrzymanie
Jakie źródła i funkcje są zatwierdzone? Gdzie mogą znajdować się model, indeks wyszukiwania, logi i kopie zapasowe? Kto obsługuje aktualizacje i błędy oraz jaka droga odtworzenia jest potrzebna?
Spójnie połączyć aplikację, inferencję i utrzymanie.
Interfejs użytkownika to tylko część całości. Przed nim działają kontrole tożsamości i dostępu, a za nim usługa inferencji, magazyn modeli i ewentualne wyszukiwanie wiedzy lub interfejsy firmowe. Monitoring, aktualizacje i odtwarzanie należą do tego samego planu.
Rysunek przedstawia możliwą architekturę, a nie rzeczywistą sieć klienta. Reverse proxy może zabezpieczać TLS i punkt wejścia. Aplikacja nadal musi egzekwować prawa użytkowników. API modeli ogranicza się do potrzebnych sieci i funkcji; dostępny port inferencji nie oznacza gotowej usługi firmowej.
Więcej niż rozmiar pliku modelu.
Przy wyborze uwzględniamy wagi, potrzeby środowiska uruchomieniowego, kontekst, równoległość i całą ścieżkę danych. GPU może mieć wystarczająco dużo pamięci, a mimo to nie zapewniać wymaganego czasu odpowiedzi. Mniejszy, dobrze dobrany model może z kolei rozwiązać zadanie korzystniej ekonomicznie.
| Element | Co sprawdzamy | Dlaczego to ważne |
|---|---|---|
| GPU i VRAM | Architekturę, sterowniki, backend inferencji, obsługiwane formaty obliczeń, pojemność i przepustowość pamięci. | Wagi i KV cache zajmują pamięć. Moc obliczeniowa i transfery pamięci wpływają na różne fazy pracy; sama reklamowana wartość TOPS nie opisuje zastosowania. |
| Jeden lub kilka GPU | Podział modelu, połączenia między GPU, magistralę PCIe, energię i chłodzenie. | VRAM nie łączy się automatycznie w swobodnie dostępny wspólny zasób. Wybrany stos musi obsługiwać podział i synchronizację; dodatkowe GPU mogą tworzyć nowe wąskie gardła. |
| CPU i systemowy RAM | Środowisko uruchomieniowe, tokenizację, przygotowanie danych, procesy równoległe i ewentualną inferencję na CPU lub odciążanie GPU. | Przeniesienie części obliczeń może umożliwić uruchomienie modelu, ale zmienia profil wydajności. Transfery między RAM i GPU mogą spowalniać odpowiedź. Także serwer GPU potrzebuje odpowiednich rezerw CPU i RAM. |
| NVMe i pamięć masowa | Wersje modeli, czasy ładowania, indeks wyszukiwania, dane importu, logi, wolną przestrzeń i kopie zapasowe. | Szybkie SSD NVMe pomagają przy ładowaniu modeli i niektórych operacjach na danych. Generowanie tokenów przez model w całości mieszczący się w pamięci GPU zależy przede wszystkim od obliczeń, pamięci i środowiska uruchomieniowego. |
| Sieć i zasilanie | Łącze, dozwolone ścieżki danych, miejsce, pobór mocy, wydzielane ciepło i dostęp serwisowy. | Najlepszy pojedynczy komponent obliczeniowy niewiele daje, jeśli pod rzeczywistym obciążeniem usługę ogranicza temperatura, organizacja lub dostęp do danych. |
Pomoc w obliczeniach, nie rekomendacja zakupu.
Przybliżoną dolną granicę pamięci samych wag można oszacować wzorem liczba parametrów × bity na wagę ÷ 8 . Hipotetyczny model o ośmiu miliardach parametrów i czterech bitach na wagę daje obliczeniowo cztery gigabajty, czyli około 3,73 GiB.
Dochodzą metadane kwantyzacji, ewentualne części modelu o wyższej precyzji, KV cache, obszary robocze i środowisko uruchomieniowe. Ta wartość nie określa więc wystarczającej pojemności VRAM dla Państwa aplikacji. W modelach z architekturą ekspertową trzeba też odróżnić aktywne obliczenia od wszystkich wag, które trzeba przechowywać.
Krótka odpowiedź to inny test niż usługa zespołowa.
Okno kontekstu obejmuje informacje, które model może uwzględnić dla zapytania. Zależnie od aplikacji należą do nich instrukcje, historia rozmowy, pobrane fragmenty dokumentów i planowana odpowiedź. Nominalnie duże okno nie gwarantuje odpowiedniego sprzętu ani niezawodnego wykorzystania informacji.
KV cache
Pamięć Key-Value przechowuje stany pośrednie mechanizmu uwagi. Zapotrzebowanie zależy m.in. od architektury modelu, typu danych, faktycznie zajętego kontekstu i równocześnie aktywnych sekwencji. Więcej kontekstu i większa równoległość często znacznie zwiększają zużycie pamięci.
Prefill i decode
W fazie prefill model przetwarza kontekst wejściowy; w decode generuje kolejne tokeny. Fazy te różnie obciążają sprzęt. Długie dokumenty mogą wydłużyć czas do pierwszego tokenu, nawet gdy dalsza odpowiedź wydaje się płynna.
Przetwarzanie wsadowe i kolejka
Wspólne przetwarzanie może zwiększyć całkowitą przepustowość. Jednocześnie poszczególni użytkownicy mogą czekać dłużej. Dlatego rezerwy zasobów, kolejki, limity i odpowiednie planowanie równoległości należą do projektu.
Mierzymy rzeczywisty przypadek użycia.
Pilotaż obejmuje typowe krótkie i długie zapytania oraz jednoczesne dostępy. Analizujemy przy tym Time to First Token, pełny czas odpowiedzi, tempo generowania, kolejkę, odsetek błędów i zużycie pamięci. Tokeny na sekundę można sensownie porównywać tylko wraz z wersją modelu, kwantyzacją, kontekstem, obciążeniem i warunkami pomiaru.
Stos dopasowany do modelu i wykorzystania.
Ollama, llama.cpp i vLLM są możliwymi elementami. Wybór i konfiguracja wynikają z obsługi modeli, sprzętu, pożądanej równoległości, utrzymania i integracji. Sprawdzamy konkretną wersję zamiast uznawać ogólne polecenie instalacji za architekturę produkcyjną.
Ollama
Możliwy punkt wyjścia do zarządzania modelami i ich lokalnego udostępniania. Magazyn modeli, zatwierdzone modele, kontekst, równoległość i zabezpieczenie usługi muszą pasować do środowiska.
llama.cpp
Elastyczny element do odpowiednich modeli na różnych backendach CPU/GPU, z formatami kwantyzowanymi i pracą serwerową. Praktycznie sprawdzamy obsługę sprzętu, podział i rzeczywiście potrzebne funkcje API.
vLLM
Opcja dla odpowiednich profili inferencji serwerowej i obciążenia. Harmonogramowanie, KV cache, przetwarzanie wsadowe i ewentualne liczne GPU są wspólnie dostrajane. Większa całkowita przepustowość nie oznacza krótszego oczekiwania na każde zapytanie.
Kontener, maszyna wirtualna czy osobny host?
Kontenery mogą zapewnić powtarzalne zestawy wersji oprogramowania. Maszyna wirtualna może dodatkowo wydzielić środowisko organizacyjnie i technicznie. Odpowiedni wybór zależy od przekazywania urządzeń, sterowników, utrzymania i istniejących procedur. Zgodne API ułatwia podłączenie, ale nie zastępuje testu działania z Państwa aplikacją.
Kiedy pasuje Proxmox z GPU passthrough?
GPU passthrough przypisuje odpowiedni fizyczny GPU do maszyny wirtualnej. Muszą pasować m.in. platforma i firmware, grupy IOMMU, sterowniki hosta i gościa oraz zachowanie przy resetowaniu urządzenia. Sprawdzamy konkretną kombinację przed zobowiązaniem.
Przypisanego GPU nie można automatycznie elastycznie współdzielić między wieloma VM. vGPU i bezpośrednie przekazywanie to różne koncepcje z własnymi wymaganiami i ewentualnymi warunkami licencyjnymi. Także utrzymanie, kopie zapasowe i możliwa zmiana hosta potrzebują odpowiedniego procesu; ogólna obietnica migracji na żywo byłaby nieuzasadniona.
Odpowiedni model musi sprostać zadaniu.
Porównujemy modele na zatwierdzonych przykładach z przyszłej pracy: np. niemieckojęzycznych pytaniach branżowych, fragmentach dokumentów, zapytaniach wielojęzycznych lub konkretnym zadaniu skryptowym. Model programistyczny i model embeddingowy pełnią różne funkcje. W wyszukiwaniu wiedzy wyszukiwarka, embeddingi i model odpowiedzi muszą współdziałać.
Kwantyzacja często zmniejsza potrzeby pamięciowe. Wpływ na jakość odpowiedzi, wywołania narzędzi i szybkość sprawdzamy dla wybranego formatu. Większy model nie jest automatycznie lepszy ani bardziej opłacalny. Duży maksymalny kontekst również nie dowodzi, że model niezawodnie wykorzysta każdą zawartą w nim informację.
- Licencja: konkretnie sprawdzić wybrane wagi modelu, użytek komercyjny, dystrybucję i wymagane informacje; samo pobranie nie zastępuje tej kontroli.
- Wersja: przejrzyście zapisać model, kwantyzację, tokenizer i środowisko uruchomieniowe.
- Odbiór: sprawdzić przydatność merytoryczną, niedozwolone odpowiedzi, jakość języka i błędy na powtarzalnym zestawie pytań.
- Zmiany: najpierw testować nowe wersje modeli, zachować skuteczną drogę powrotu i odpowiednio odtworzyć indeksy wyszukiwania przy zmianie embeddingów.
Lokalnie, zewnętrznie lub w odpowiednim połączeniu.
Własny sprzęt może mieć sens przy odpowiednim wykorzystaniu, jasnych wymaganiach danych i istniejących warunkach utrzymania. Usługa zewnętrzna może lepiej pasować przy zmiennym wykorzystaniu, szczególnych możliwościach modelu lub małych zasobach własnej obsługi. Model hybrydowy łączy wyraźnie wydzielone zadania i ścieżki danych.
Porównanie obejmuje zakup lub korzystanie z usługi, energię i chłodzenie, licencje, integrację, aktualizacje, obsługę, rezerwy i skutki awarii. Lokalne przetwarzanie nie gwarantuje automatycznie bezpieczeństwa ani zgodności z RODO: modele, embeddingi, telemetria, aktualizacje, narzędzia zewnętrzne i logi również muszą odpowiadać uzgodnionej koncepcji danych.
Najpierw planujemy niewielki pilotaż z mierzalnymi wymaganiami. Jego wynik pozwala zdecydować o rozbudowie, zmianach lub prostszej alternatywie. Dalsze podstawy znajdą Państwo w Chmura i SaaS.
Obsługiwana usługa wymaga przejrzystej odpowiedzialności.
DAXS może zaplanować sprzęt i oprogramowanie, zainstalować je, połączyć z istniejącymi tożsamościami i aplikacjami oraz przejąć uzgodnione bieżące utrzymanie. Obejmuje to monitorowanie dostępności i zasobów, aktualizację wersji, obsługę błędów i dokumentację. Potrzebną dostępność i ścieżki reagowania uzgadniamy indywidualnie.
Ustalamy, które konfiguracje, komponenty aplikacji, dane indeksów i ewentualne dostrojone modele są objęte kopiami zapasowymi. Wagi modeli, które można ponownie pozyskać, i chronione dane operacyjne mają różne wymagania. Test odtwarzania jest częścią odpowiedniej koncepcji utrzymania.
Zebranie wymagań, propozycja architektury, test modelu i obciążenia, udokumentowane ścieżki danych oraz uzasadniona rekomendacja sprzętu, modelu utrzymania i kolejnych kroków integracji.
Wyjaśnimy to podczas rozmowy.
Ile VRAM potrzebuje lokalny LLM?
Zależy to od modelu i kwantyzacji, środowiska uruchomieniowego, kontekstu i równoczesnych zapytań. Sam plik modelu nie jest wystarczającą podstawą. Zanim zarekomendujemy konkretną konfigurację, testujemy zadanie z długimi zapytaniami i szczytami obciążenia.
Czy drugi GPU automatycznie przyspiesza pracę?
Nie. Wybrany stos musi obsługiwać podział. Połączenia między GPU, synchronizacja i architektura modelu wpływają na wynik. Więcej pamięci może umożliwić uruchomienie, nie przyspieszając każdej odpowiedzi.
Czy można użyć istniejącego serwera Proxmox?
Może to pasować, jeśli sprzęt, grupy IOMMU, sterowniki i przekazywanie GPU są odpowiednie. Muszą też wystarczyć rezerwy dla innych usług oraz procedury utrzymania, kopii zapasowych i odtwarzania. Sprawdzamy konkretnie istniejącą platformę.
Czy dokumenty wewnętrzne służą do trenowania modelu?
Przy wyszukiwaniu wiedzy często nie jest to potrzebne. RAG wyszukuje odpowiednie, dozwolone fragmenty dokumentów i przekazuje je modelowi jako kontekst. Zmiana wag modelu jest innym działaniem, wymagającym osobnego uzasadnienia.
Kiedy usługa zewnętrzna jest bardziej opłacalna?
Przy niewielkim lub mocno zmiennym wykorzystaniu, szczególnych wymaganiach modelu albo braku zasobów obsługi lepiej może pasować usługa zewnętrzna. Porównujemy koszty, ścieżki danych, jakość i utrzymanie w planowanym okresie użytkowania.
Wspólnie obserwować modele, obciążenie i koszty.
Oprócz wykorzystania GPU i czasu odpowiedzi analizujemy koszt użytecznego zadania. Aktualizację modelu porównujemy przed użyciem z zatwierdzonym zestawem testowym. Błędy, kolejki, limity pamięci i awarie wymagają wskazanych osób odpowiedzialnych i drogi odtworzenia. Zewnętrzna usługa zastępcza jest dopuszczalna tylko przy odpowiedniej klasie danych i zatwierdzeniu.
Omówmy Państwa przypadek użycia.
Co powinno stać się prostsze, jakie dane uczestniczą w procesie i jakie systemy już istnieją? Na tej podstawie opracujemy rozsądny początek i niewielki kolejny krok.