Zdefiniuj użyteczny wynik, zanim zaczniesz szukać przepustowości
W interakcji mierz oczekiwanie na pierwszy token i na pełną odpowiedź. Dla korpusu offline mierz czas potrzebny na uzyskanie wszystkich oczekiwanych wyników. W obu przypadkach ustal regułę akceptacji: poprawność na znanych odpowiedziach, jakość rankingu lub zweryfikowane wyodrębnianie pól. Składniowo poprawny JSON może wciąż zawierać błędną odpowiedź.
Rozdziel oczekiwanie w kolejce, przetwarzanie i pełną drogę obserwowaną przez Twojego klienta, gdy pozwalają na to Twoje narzędzia. Pomiar wewnątrz silnika ma inne granice niż pomiar aplikacji. Dokumentacja metryk vLLM rozróżnia między innymi oczekiwanie, pierwszy token i całkowity czas: zachowaj to rozróżnienie w swoich zapisach, niezależnie od wybranego silnika.
Źródła techniczne: vLLM — metryki zapytań i opóźnień
Zamień swoje zapytania na kryteria wyboru
Przygotuj wejścia krótkie, typowe i długie ze stabilnymi identyfikatorami. Zachowaj model, tokenizer, szablon rozmowy i parametry generowania. Policz tokeny faktycznie przesłane, łącznie z historią i dokumentami dodanymi przez aplikację. Zapisz osobno żądany batch, wysłaną współbieżność i zapytania faktycznie przetwarzane równocześnie: to niekoniecznie te same liczby.
| Wejście do ustalenia | Pomiar i jednostka | Konsekwencja dla wyboru |
|---|---|---|
| Pełny prompt i limit wyjścia | Tokeny wejścia i wyjścia na zapytanie | Sprawdź długie przypadki i odpowiedzi ucięte na limicie |
| Równoczesne zapytania i tempo napływu | Zapytania aktywne, oczekujące i zakończone | Określ obciążenie zrównoważone przy wymaganym opóźnieniu |
| Precyzja, kwantyzacja i cache | Szczyt pamięci na GPU, w bajtach lub GiB | Odrzuć ustawienia, które przekraczają pamięć przy przewidywanym obciążeniu |
| Reguła jakości i wartości odniesienia | Zaakceptowane wyjścia / oczekiwane wyjścia; metryka biznesowa | Porównuj tylko warianty spełniające to samo kryterium |
| Zakres pomiaru czasu | Pierwszy token, pełna odpowiedź lub korpus: sekundy | Porównuj czasy o tych samych granicach |
| Harmonogram aż do pobranych plików | Całkowite okno, w godzinach lub dniach | Następnie wybierz pakiet na 3, 7 lub 30 dni |
Mierzenie pamięci z kontekstem i współbieżnością
W przypadku modelu autoregresyjnego, który generuje token po tokenie, pamięć podręczna KV przechowuje stany uwagi. Jej rozmiar zależy od modelu i zachowanych tokenów. Dynamiczna pamięć podręczna może rosnąć podczas generowania; statyczna rezerwuje maksymalny rozmiar. Niektóre warstwy z ruchomym oknem ograniczają ten wzrost. Testuj więc przewidywane długości i współbieżność z faktycznie używaną strategią.
Kwantyzacja wag i kwantyzacja pamięci podręcznej to dwa odrębne wybory. Na przykład bitsandbytes zastępuje niektóre warstwy liniowe wersjami skwantyzowanymi; nie opisuje to wszystkich alokacji w Twoim uruchomieniu. Po zmianie precyzji ponownie sprawdź pamięć i jakość, zamiast zakładać, że cały szczyt zmniejsza się w tej samej proporcji.
W PyTorch odczytuj oddzielnie szczyt przydzielonych tensorów i szczyt pamięci zarezerwowanej przez alokator. Nie dodawaj ich do siebie. Wskaż mierzony GPU i jednostkę: 1 GiB odpowiada 2³⁰ bajtów. Te liczniki nie muszą obejmować całego zajęcia urządzenia. Folder pamięci szczegółowo opisuje ich ograniczenia.
Źródła techniczne: Hugging Face Transformers 5.17 — strategie pamięci podręcznej KV · Hugging Face Transformers 5.17 — kwantyzacja bitsandbytes · PyTorch 2.14 — zarządzanie pamięcią CUDA i liczniki
Mierzalny test na 300 dokumentach
Przykład do wykonania na Twoim autoryzowanym korpusie: wyodrębnij datę, kwotę i kategorię z 300 dokumentów. Sprawdź oczekiwane wartości, określ sposób postępowania z brakującymi polami i ustal próg akceptacji przed testem. Liczba dokumentów opisuje protokół; nie zakłada się żadnego czasu, wyniku ani przepustowości.
- Zamroź 300 identyfikatorów, wersję modelu, prompty, limity tokenów i regułę parsowania. Zadbaj, aby długie dokumenty były identyfikowalne w podsumowaniu.
- Wykonaj odniesienie z jednym żądaniem naraz. Oddziel wczytywanie, rozgrzewkę i pomiar; zachowaj przewidywania i błędy dla każdego dokumentu.
- Następnie zwiększaj tylko jeden parametr: batch dla przetwarzania grupowego lub współbieżność dla silnika żądań. Zachowaj te same dane wejściowe i kryteria jakości.
- Dla każdego przebiegu zarejestruj czas, szczyt pamięci, liczbę znalezionych identyfikatorów bez duplikatów i zaakceptowane wyjścia. Powtórz pomiary i zachowaj surowe wartości wraz z ich rozrzutem.
- Jeśli wariant zawiedzie, zapisz przyczynę: pamięć, obcięcie, format lub jakość. Zmniejszony batch lub wznowienie to decyzja do udokumentowania, a nie błąd do usunięcia.
Źródła techniczne: IteraGPU — szczegółowy protokół porównania przy równoważnej jakości
Wykorzystaj zasoby IteraGPU Lab v1 w odpowiednim zakresie
Notebook i towarzyszący mu skrypt oferują obliczenie wag i pomiar na małej sieci syntetycznej. Ich kod pomiarowy został uruchomiony na lokalnej RTX 5070 z PyTorch 2.11.0, na małej konfiguracji w float32. Ten test weryfikuje ten przypadek uruchomienia; nie mierzy ani LLM, ani pamięci podręcznej KV, ani GPU z katalogu na Twoich żądaniach.
Użyj notebooka, aby zrozumieć liczniki, a następnie zmierz swoje rzeczywiste obciążenie w jego środowisku. Protokół jakości i surowa tabela służą do przygotowania porównania. Wyjścia dostarczonego notebooka i wiersze wyników w CSV pozostają puste; procedura nie instaluje żadnego modelu ani sterownika. Przeczytaj wymagania wstępne z README przed uruchomieniem.
- Notebook pamięci IteraGPU Lab v1
Obliczenia i mała sieć syntetyczna do zrozumienia pomiaru pamięci.
- Protokół jakości do uzupełnienia
Stałe dane wejściowe, akceptacja wyjść i porównanie testów.
- Pusta surowa tabela
Jeden wiersz na rzeczywisty przebieg, z parametrami, pomiarami i werdyktem.
- Wymagania wstępne i ograniczenia IteraGPU Lab v1
Instrukcje i dokładny zakres już wykonanego testu lokalnego.
Przejście od pomiarów do oferty
Twoja karta wyboru powinna łączyć kompatybilne środowisko, pamięć na kartę, kontekst, współbieżność, osiągniętą jakość i zmierzone czasy. Porównaj konfiguracje spełniające te kryteria, a następnie pakiety 3-, 7- i 30-dniowe według pełnego harmonogramu: przygotowanie, przetwarzanie, ewaluacja, wznowienia i eksport. Kalkulator w dossier benchmarks korzysta z całego pakietu i rzeczywiście zwalidowanych, użytecznych korpusów.
Zachowaj tę kartę i wersje kodu w swoim notatniku. To Ty wybierasz swoje oprogramowanie i przetwarzanie; IteraGPU nie przeprowadza inspekcji zawartości Twoich plików, promptów ani obliczeń. Wybór środowiska przy zamówieniu wyraża Twoją potrzebę przygotowania: nie stanowi dowodu, że Twój model został już zainstalowany lub przetestowany.
Praktyczne pytania
Czy 24 GB wystarczą dla mojego modelu inferencyjnego?
Pojemność 24 GB nie wystarcza, by odpowiedzieć bez znajomości modelu i obciążenia. Sprawdź razem wagi, alokacje wykonawcze, kontekst i równoczesne zapytania. Konfiguracja musi kończyć długie przypadki z wymaganą jakością; sam rozmiar pliku lub szacunek wag tego nie dowodzi.
Jaki przepływ należy porównać dla korpusu offline?
Porównaj najpierw czas potrzebny na ukończenie i ewaluację tego samego korpusu. Jeśli podajesz przepływ, podaj liczbę zaakceptowanych użytecznych wyników, uwzględniony czas i błędy. Przepływ w tokenach na sekundę bez długości odpowiedzi ani kontroli jakości nie wystarcza, by rozstrzygnąć między dwiema konfiguracjami.
Czy przekroczenie pamięci wymusza zmianę GPU?
Przekroczenie pamięci wymaga najpierw zidentyfikowania ustawienia i danych wejściowych, które je wywołały. Możesz przeanalizować batch, współbieżność, długość lub precyzję, zachowując cel projektu. Każde zmniejszenie, które zmienia przetwarzane dokumenty lub oczekiwane odpowiedzi, wymaga ponownej weryfikacji jakości; więcej pamięci może być konieczne, jeśli te ograniczenia mają zostać zachowane.
Czy dostarczony notebook waliduje moją aplikację inferencyjną?
Dostarczony notebook nie waliduje Twojej aplikacji: mierzy małą sieć syntetyczną i objaśnia liczniki pamięci. Udokumentowany lokalny test dotyczy tylko tego przypadku. Twoja aplikacja musi zostać oceniona z jej modelem, danymi wejściowymi, środowiskiem i własnymi kryteriami akceptacji przed jakimkolwiek wnioskiem o pojemności lub wydajności.