Goodput

Serwer potrafi zakończyć dużo odpowiedzi na sekundę, ale część użytkowników czeka zbyt długo. Sam licznik wykonanej pracy wygląda dobrze, choć usługa nie dotrzymuje oczekiwanych czasów. Potrzebujesz wydajności powiązanej z wymaganiami użytkownika.

Goodput uwzględnia pracę spełniającą zadane warunki jakości usługi. W opisanej tu definicji DistServe jest to największe tempo napływu żądań, przy którym wymagany odsetek odpowiedzi mieści się w limitach opóźnienia.

Możesz ustalić, że co najmniej 90% odpowiedzi zaczyna się w pół sekundy i potem utrzymuje określone tempo. Zwiększasz obciążenie, aż system przestaje utrzymywać te warunki. Graniczne tempo jest wynikiem dla tej konfiguracji i tych progów.

Bez progów, odsetka i rodzaju obciążenia liczba niewiele mówi. Goodput nie jest po prostu liczbą wszystkich wygenerowanych tokenów — fragmentów tekstu — ani procentem odpowiedzi uznanych za prawdziwe.

Źródło mechanizmu: DistServe, §1.

Mechanizm i szczegóły

SLO (Service Level Objective) określa tutaj warunek jakości usługi: przykładowo Time to First Token do 500 ms i średni czas kolejnego tokena do 50 ms. Osobno ustalamy wymagany odsetek żądań spełniających te warunki, np. 90%. Bez progów, tego odsetka, obciążenia i liczby GPU liczba „2 żądania/s” niewiele wyjaśnia.

Ile ruchu można jeszcze przyjąć?

Własny eksperyment zawiera pięć wymyślonych prób obciążenia tej samej konfiguracji dwóch GPU. Każda ma dziesięć obserwacji. Przy napływie 1, 2, 3, 4 i 5 żądań/s oba limity spełnia odpowiednio 100%, 90%, 80%, 70% i 50% próby. Wśród tych punktów dla wymaganego poziomu 90% Goodput wynosi 2 żądania/s, czyli 1 żądanie/s/GPU. Zaostrzenie celu do 100% obniża wynik do 1 żądania/s.

Zmień wymagany odsetek, potem obejrzyj próbę dla 3 żądań/s. Dziewięć odpowiedzi spełnia limit TTFT, dziewięć limit czasu kolejnego tokena, lecz tylko osiem spełnia oba. Spóźniają się różne odpowiedzi. W naszym przykładzie zaliczamy żądanie dopiero po spełnieniu obu warunków.

Liczy się definicja pomiaru

Ta mała próba pokazuje regułę wyboru, nie estymuje pojemności prawdziwego serwera. Nie znamy wyników między badanymi punktami. DistServe, §4.2 szuka granicznego tempa przez symulację i kolejne próby, uwzględniając rozkłady długości oraz nadejścia żądań.

Inter-token Latency wyjaśnia różnicę między średnią a pojedynczymi pauzami; wybór jednej z tych miar zmienia warunek zaliczenia. Disaggregated Serving rozdziela zasoby faz, aby łatwiej dobrać je do wymagań. Więcej wygenerowanych tokenów na sekundę nie gwarantuje wyższego Goodput.