Długi kontekst zamienia wnioskowanie w problem zarządzania pamięcią

Ten sam model może tworzyć różne obciążenia

Krótkie pytanie i długa analiza dokumentu mogą wykorzystywać ten sam model, jednocześnie stawiając bardzo różne wymagania systemowi. Należy przetworzyć więcej kontekstu, a usługa musi zachować stan roboczy podczas generowania odpowiedzi. Wiele jednoczesnych żądań zwielokrotnia te wymagania.

Dlatego demonstracja z jednym podpowiedzią jest słabą podstawą do określenia wielkości usługi produkcyjnej. Profil pamięci zależy od kombinacji żądań i zastosowanych ustawień, a nie tylko od liczby parametrów wydrukowanej na karcie modelu.

Wstępne wypełnianie i dekodowanie wykonują inną pracę

Wnioskowanie powszechnie odróżnia przetwarzanie danych wejściowych, często nazywane wstępnym wypełnianiem, od późniejszego generowania tokenów wyjściowych, czyli dekodowania. Na tych etapach można skorzystać z różnych opcji planowania i zasobów. Architektura Dynamo modułu NVIDIA wyraźnie obsługuje zdezagregowane wnioskowanie, routing uwzględniający kontekst pamięci podręcznej i zarządzanie pamięcią podręczną pomiędzy warstwami pamięci. NVIDIA Dynamo: architektura wnioskowania rozproszonego ↗

Jest to dowód na to, że stos oprogramowania rozwiązuje problem. Nie jest twierdzeniem, że oddzielenie etapów usprawni każde wdrożenie. Dodatkowa koordynacja i przenoszenie danych wiążą się z kosztami, a niewielka usługa może nie wymagać złożoności projektu rozproszonego.

Kontekst buforowany jest przydatny, ale nie darmowy

Ponowne użycie odpowiedniego stanu pamięci podręcznej pozwala uniknąć powtarzania pracy. Utrzymywanie tego stanu zużywa zasoby, a przenoszenie go między lokalizacjami lub warstwami pamięci może spowodować ruch i opóźnienia. Korzyści zależą od tego, czy żądania rzeczywiście wykorzystują wystarczający kontekst, aby uzasadnić ustalenia.

Asystent dokumentu wielokrotnie zadający pytania dotyczące tego samego materiału może zachowywać się inaczej niż usługa otrzymująca niepowiązane żądania. Test porównawczy powinien reprezentować oczekiwany wzorzec ponownego użycia, a nie zakładać, że każde żądanie jest trafieniem w pamięć podręczną.

Powinno również obejmować, co się dzieje, gdy pamięć podręczna jest zimna, pełna lub niedostępna. Warunki te mają znaczenie podczas ponownego uruchamiania i skoków zapotrzebowania, gdy usługa często ma najmniejszą wolną moc obliczeniową.

Rozmiar dystrybucji żądań

Zmierz typowe i wymagające dane wejściowe, oczekiwane długości wyjściowe i realistyczną współbieżność. Rejestruj szczytowe wykorzystanie pamięci, czas do pierwszego wyjścia i stałą wydajność generacji. Podczas porównywania systemów należy zachować stałe ustawienia jakości wydruku.

Wynik może sugerować akcelerator z większą pamięcią, inną strategię planowania lub bardziej rygorystyczne ograniczenia aplikacji w kontekście. Może również ujawnić, że zmiany oprogramowania zapewniają wystarczającą pojemność bez wymiany sprzętu.

Lekcja zakupowa polega na tym, aby unikać traktowania pamięci jako statycznego obliczenia rozmiaru modelu. Działająca usługa wnioskowania ma zmieniającą się populację żądań. Zrozumienie tej populacji daje znacznie silniejszą podstawę do wyboru pamięci GPU, zasobów hosta i oprogramowania używanego do ich koordynacji.