Szybka odpowiedź na jedno krótkie pytanie pokazuje, że lokalny model językowy zasadniczo działa. Przy wyborze infrastruktury znacznie więcej mówi test przyszłych zadań i ich rzeczywistego obciążenia. Obejmuje to jakość odpowiedzi, czas oczekiwania, dłuższe dane wejściowe, jednoczesne użycie i działanie po awarii.
Pilotaż jest szczególnie przydatny, gdy z góry wiadomo, jaką decyzję ma umożliwić jego wynik. Na przykład: czy wystarczy obecne środowisko, potrzeba innego sprzętu, czy lepsza będzie usługa zewnętrzna lub hybrydowa? Plan testu wynika z tego pytania.
Zacząć od małego zbioru reprezentatywnych zadań
Odpowiednie zadania testowe wynikają z planowanego procesu pracy: krótkie pytanie merytoryczne, podsumowanie dłuższego zatwierdzonego dokumentu albo projekt skryptu do sprawdzenia. Dla każdego zadania określa się, po czym poznać użyteczny wynik.
Pytania o wiedzę powinny uwzględniać oczekiwane źródła i przypadki bez wystarczających podstaw. Kod wymaga weryfikacji technicznej i odpowiednich testów. Poufne dane oryginalne wykorzystuje się wyłącznie w zatwierdzonym do tego środowisku; do przygotowania mogą wystarczyć dane oczyszczone lub specjalnie utworzone do testu.
Oddzielnie oceniać jakość i szybkość
Model, który szybko podaje błędne wyniki, nie spełnia celu. Dlatego najpierw ocenia się użyteczność merytoryczną, niezbędne poprawki i postępowanie przy brakujących informacjach. Następnie można porównać czas odpowiedzi i nakład potrzebny do uzyskania tej jakości.
Zapisuje się wersję modelu, kwantyzację, oprogramowanie inferencyjne, ustawienia i dane testowe. W przeciwnym razie szybsza odpowiedź może wynikać ze zmienionego zadania lub innego poziomu jakości. Zmiany zbioru dokumentów też mogą wpływać na porównanie aplikacji RAG.
Rozłożyć czas oczekiwania na części
- Czas do pierwszego tokenu
- Określa, kiedy zaczyna się generowanie wyniku. Mogą na niego wpływać kolejka i przetwarzanie wejścia. Warto też mierzyć odczuwany czas od wysłania żądania w aplikacji do pojawienia się odpowiedzi.
- Generowanie odpowiedzi
- Szybkość generowania wpływa na czas tworzenia dłuższej odpowiedzi. Wysoka łączna przepustowość serwera nie mówi jeszcze, jak szybko pojedynczy użytkownik otrzyma swoją odpowiedź.
- Całkowity czas
- Obejmuje całą operację aplikacji. Mogą dojść wyszukiwanie, przygotowanie dokumentów, wywołania narzędzi i drogi sieciowe.
- Rozrzut i błędy
- Typowe wartości rozpatruje się razem z wolniejszymi przypadkami brzegowymi. Liczba pomiarów, przekroczone limity czasu i przerwane zadania są częścią wyniku.
Oficjalna dokumentacja metryk vLLM (link zewnętrzny) rozróżnia między innymi pomiary oczekiwania, wejścia i wyjścia. Dostępne metryki konkretnego środowiska wykonawczego sprawdza się dla używanej wersji. Pomiary różnych komponentów muszą dotyczyć tego samego okresu i zadania.
Testować krótkie rozmowy, długie konteksty i współbieżność
Długi kontekst wymaga dodatkowych obliczeń i pamięci. Jednoczesne żądania współdzielą dostępne zasoby. Dokumentacja kontekstu Ollama (link zewnętrzny) i dokumentacja optymalizacji vLLM (link zewnętrzny) wyjaśniają te zależności; konkretne ustawienia zależą od wersji i sprzętu.
Sensowny test łączy więc krótkie i dłuższe wejścia ze współbieżnością odpowiadającą planowanemu użyciu. Poza równomiernym napływem żądań uwzględnia też przewidywane szczyty. Jeżeli przetwarzanie partiami zwiększa przepustowość, nadal trzeba sprawdzić, czy czasy pojedynczych odpowiedzi odpowiadają użytkownikom.
Przykładowy plan testów
Najpierw wykonać te same zadania merytoryczne pojedynczo. Następnie sprawdzić razem krótkie żądania i zadania na zatwierdzonych dokumentach. Potem odtworzyć przewidywany okres szczytu i obserwować przeciążenie. Wartości docelowe uzgadnia się wcześniej z użytkownikami.
Ten plan jest przykładem do dostosowania. Nie zawiera zmierzonych wyników wydajności DAXS i nie zastępuje oceny konkretnego środowiska.
Rozróżniać uruchomienie, zwykłą pracę i przywrócenie działania
Po restarcie model może wymagać załadowania. Ten zimny start mierzy się oddzielnie od pracy z już załadowanym modelem. Szybkie dyski NVMe mogą wspierać ładowanie i operacje na danych; nie oznacza to ogólnego przyspieszenia generowania tokenów przez model znajdujący się w całości w pamięci GPU.
Pilotaż obejmuje również utratę połączenia, przerwane zadanie i restart usługi. Aplikacja powinna jasno pokazywać stan i oferować sensowną ścieżkę ponowienia lub przekazania pracy. Przeciążenie nie może prowadzić bez ostrzeżenia do niepełnych wyników.
Przełożyć wyniki na decyzję o architekturze
Porównuje się użyteczne wyniki, nakład poprawek, opóźnienia, pojemność i bieżącą eksploatację. Koszt całkowity obejmuje też administrację, konserwację, energię, kopie zapasowe i wymaganą dostępność. Dla usług zewnętrznych dochodzą rzeczywiste koszty użycia i uzgodnione drogi danych.
Wynikiem może być mniejszy odpowiedni model, dodatkowe zasoby, ograniczona kolejka lub inny model eksploatacji. Rozwiązania lokalne, zewnętrzne i hybrydowe ocenia się na tym samym zadaniu. Pilotaż ma umożliwić uzasadnioną kolejną decyzję, bez późniejszego usprawiedliwiania zakupu sprzętu założonego z góry.
DAXS planuje test, przygotowuje odpowiednie środowisko i ocenia wyniki z Państwa zespołem IT. Podstawy techniczne wyjaśnia nasza strona specjalistyczna o lokalnych LLM i infrastrukturze. Przy podłączonych zasobach wiedzy jakość wyszukiwania, źródeł i uprawnień należy do tych samych ram oceny.
