Gdzie odpowiedź AI traci czas

Rozłóż jedno wolne zapytanie na odcinki

Kroki wykonywane jeden po drugim się sumują. Kroki, które na siebie zachodzą, już nie, a czas, który upływa, wyznacza tylko najdłuższy łańcuch przez nie, czyli ścieżka krytyczna. Zinstrumentuj ścieżkę zapytania tak, by każdy krok był osobnym odcinkiem z czasem początku i końca, i badaj wolne zapytania, a nie typowe. Przydatny podział:

• Czekanie przed rozpoczęciem pracy: kolejka w bramce, wycofanie po limitach i ponowienia
• Retrieval: embedding zapytania, wyszukiwanie wektorowe lub po słowach kluczowych, reranking
• Każde wywołanie modelu, podzielone na czas do pierwszego tokenu i czas generowania
• Wywołania narzędzi i API uruchamiane przez model oraz kolejne rundy komunikacji między nimi
• Przetwarzanie końcowe: parsowanie, walidacja, moderacja i ewentualne wywołania naprawcze

Ponowieniom daj osobny licznik. Proxy LiteLLM na przykład ponawia nieudane wywołanie w tej samej grupie modeli, według dokumentacji domyślnie trzy razy, zanim przejdzie na model zapasowy, więc niestabilny dostawca może wyglądać jak powolność, a nie jak błędy.

Hipotetyczny budżet opóźnień

Załóżmy, że p95 asystenta wsparcia wynosi 6,1 sekundy, a product owner chce 3. W tym hipotetycznym śladzie wszystkie kroki idą po kolei, więc odcinki sumują się do całości:

• Czekanie w bramce i jedno ponowienie: 0,4 s
• Przepisanie zapytania przez duży model: 0,9 s
• Retrieval i reranking: 0,7 s
• Model odpowiedzi, czas do pierwszego tokenu przy prompcie o 9000 tokenach: 1,0 s
• Model odpowiedzi, wygenerowanie 520 tokenów: 2,6 s
• Wywołanie narzędzia statusu zamówienia, po retrievalu i przed odpowiedzią: 0,5 s

Generowanie to największy składnik, więc najpierw krótsze odpowiedzi: mają trzy akapity tam, gdzie wystarczyłby jeden. Przepisanie zapytania to dobrze zdefiniowane zadanie, z którym może poradzić sobie mniejszy model, a sprawdzenie zamówienia nie zależy od odpowiedzi, więc może iść równolegle z retrievalem. Mierz każdą zmianę osobno, bo każda może też zmienić jakość odpowiedzi. Gdy sprawdzenie zamówienia idzie równolegle, wypada ze ścieżki krytycznej i dalsze jego skracanie nic nie daje.

Co zwykle przesuwa wynik

Przewodnik OpenAI o opóźnieniach mówi wprost, od czego zacząć. Generowanie tokenów to prawie zawsze najwolniejszy krok, a skrócenie odpowiedzi o połowę może skrócić opóźnienie mniej więcej o połowę. Skrócenie promptu o połowę daje często tylko 1 do 5 procent, chyba że kontekst jest bardzo duży. Każde kolejne zapytanie wykonywane po poprzednim dodaje rundę komunikacji, więc łącz kroki, które mogą dzielić jedno wywołanie, a niezależne uruchamiaj równolegle.

Dwie kolejne dźwignie zmieniają bardziej odczucia użytkownika niż wskazanie zegara. Streaming pokazuje pierwsze słowa, gdy reszta dopiero powstaje, a widoczny postęp kolejnych kroków z narzędziami mówi użytkownikowi, że coś się dzieje. Żadna z nich nie skraca czasu całkowitego, więc mierz nadal obie wartości.

Cache prefiksów skraca czas do pierwszego tokenu dla zapytań o długim, stałym początku, takim jak instrukcje i definicje narzędzi. Dokumentacja vLLM zaznacza, że przyspiesza tylko fazę prefill i nic nie daje przy generowaniu.

Dodatkowe sygnały, gdy sam serwujesz model

Przy własnym serwerze inferencji odcinek modelu da się rozłożyć dalej. vLLM udostępnia metryki Prometheus dla czasu w kolejce, czasu prefill, czasu dekodowania, czasu do pierwszego tokenu i czasu na token wyjściowy każdego zapytania, a obok nich wskaźniki serwera, takie jak zajęta część pamięci KV cache. Dokumentacja dobrze ujmuje tę zależność: metryki serwera wyjaśniają metryki zapytań.

Jeden wzorzec, którego warto szukać, to rosnący czas w kolejce przy pełnym KV cache. Gdy brakuje miejsca w cache, vLLM wywłaszcza zapytania i przelicza je później, co według dokumentacji może pogorszyć opóźnienie całkowite. Pomaga więcej pamięci na replikę, mniej równoległych sekwencji albo więcej replik, a każda opcja ma swój koszt. Ustawienia chunked prefill wymieniają jedno opóźnienie na drugie: mniejszy budżet tokenów na partię sprzyja równemu streamingowi, większy skraca czas do pierwszego tokenu.

Mierz pod obciążeniem i na ogonie rozkładu

Opóźnienie zmierzone przez jednego inżyniera w spokojne popołudnie niewiele mówi o poniedziałkowym poranku. Odtwórz próbkę prawdziwych promptów z realistycznym tempem napływu. Polecenie benchmarku vLLM potrafi wysyłać zapytania w zadanym tempie z regulowaną nierównomiernością, ograniczać równoległość, raportować wybrane percentyle czasu do pierwszego tokenu, czasu na token i opóźnienia całkowitego oraz liczyć goodput, czyli zapytania, które spełniły zadane przez ciebie cele poziomu usług.

Ustal cel dla każdej funkcji jako percentyl, na przykład p95 czasu do pierwszego tokenu i p95 czasu całkowitego, i sprawdzaj go po każdym wydaniu. Zmiana, która poprawia medianę, a pogarsza ogon, jest regresją dla użytkowników, którzy zauważają opóźnienia.

Gdy żaden pojedynczy odcinek nie jest winny

Czasem każdy odcinek wygląda rozsądnie, a suma wciąż jest za duża, na przykład dlatego, że projekt łączy w łańcuch pięć wywołań modelu tam, gdzie wystarczyłyby dwa. Przewodnik OpenAI podpowiada, by zapytać, czy każdy krok w ogóle potrzebuje modelu językowego: potwierdzenia można zakodować na sztywno, wybory z ograniczonej listy przygotować wcześniej, a zwykły cache lub wyszukiwanie może wygrać z kolejnym wywołaniem. Taka przebudowa wymaga więcej pracy niż zmiana ustawienia i często właśnie tam leży większy zysk.