Goodput

Goodput w serwowaniu LLM uwzględnia wymagania dotyczące czasu odpowiedzi. W DistServe, §1 oznacza największe tempo napływu żądań, przy którym system utrzymuje zadany odsetek odpowiedzi spełniających wymagania opóźnienia. Wynik na GPU dzieli tę wartość przez liczbę użytych urządzeń.

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.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.