TTFT mierzy się jako różnicę czasu między wysłaniem żądania a odebraniem pierwszego niepustego tokena (wymaga trybu strumieniowego). Na łączny czas składają się: (1) kolejkowanie i wejście żądania do batcha, (2) faza prefill — równoległe przetworzenie wszystkich tokenów promptu przez wszystkie warstwy modelu wraz z zbudowaniem KV cache, (3) obliczenie logitów ostatniej pozycji i próbkowanie pierwszego tokena, (4) detokenizacja i transfer sieciowy. Faza prefill jest compute-bound (operacja macierz-macierz nasycająca GPU), więc TTFT rośnie z długością promptu i rozmiarem modelu. Typowe techniki obniżające TTFT: chunked-prefill, ponowne użycie prefiksu/KV cache (prefix caching), dezagregacja faz prefill i decode, równoległość tensorowa oraz mocniejszy sprzęt obliczeniowy.
Sama przepustowość (tokeny/s) i całkowita latencja nie oddają tego, jak szybko użytkownik widzi początek odpowiedzi. TTFT wyodrębnia opóźnienie startu generacji, które w interfejsach strumieniowych i konwersacyjnych decyduje o odczuwalnej responsywności, i pozwala optymalizować oraz kontraktować (SLO) fazę prefill niezależnie od fazy decode.
Czas oczekiwania żądania na przyjęcie do bieżącego batcha przez scheduler serwera inferencji, zanim rozpocznie się obliczanie.
Równoległe przetworzenie wszystkich tokenów promptu przez wszystkie warstwy modelu; główny, compute-bound składnik TTFT.
Zapisanie kluczy i wartości (K, V) dla wszystkich tokenów promptu i warstw, wykorzystywane później w fazie decode.
Dekodowanie pierwszego tokena wyjściowego z logitów ostatniej pozycji (greedy, top-k, top-p, temperatura).
Bez streamingu serwer zwraca całą odpowiedź naraz, więc nie da się zmierzyć rzeczywistego czasu do pierwszego tokena.
TTFT czyste (od startu prefill) i end-to-end (z czasem kolejkowania) dają różne liczby, co utrudnia porównania.
Ładowanie wag, kompilacja grafu i alokacja pamięci zawyżają pierwszy pomiar TTFT.
Niektóre API zwracają pusty lub metadanych pierwszy chunk (np. rola), co zaniża TTFT jeśli policzy się go jako token.
Opóźnienia sieci i detokenizacji wpływają na TTFT odczuwany przez klienta, choć bywają pomijane w pomiarach serwerowych.
TTFT wraz z TPOT i przepustowością staje się standardowym zestawem metryk w inżynierii wydajności inferencji LLM (m.in. przewodniki Databricks, NVIDIA).
Rozdzielenie fazy obliczania promptu i generacji tokenów na osobne maszyny, umożliwiające niezależne zarządzanie TTFT i przepustowością generacji.
Dezagregacja faz prefill i decode na różne GPU pozwala niezależnie optymalizować TTFT (prefill) oraz czas na token (decode) zamiast godzić je kompromisem.
Dzielenie prefill na kawałki i harmonogram bez przestojów pozwala utrzymać wysoką przepustowość, kontrolując wpływ batchingu na TTFT i latencję.
Złożoność czasowa: O(n^2 * d). Złożoność przestrzenna: O(n * d * L).
TTFT jest zdominowany przez compute-bound prefill — gęstą operację macierz-macierz nasycającą jednostki obliczeniowe akceleratora.
Liczba tokenów wejściowych; główny czynnik TTFT.
Liczba parametrów i warstw wpływa na koszt prefill na token.
Wydajność obliczeniowa akceleratora determinuje szybkość prefill.
Większe batche i obciążenie wydłużają kolejkowanie i mogą podnosić TTFT.
Buforowanie wspólnego prefiksu skraca prefill i TTFT.
Dzielenie prefill na kawałki równoważy TTFT z przepustowością.
Rozłożenie modelu na wiele GPU może skrócić prefill dużych modeli.
TTFT mierzy koszt prefill — gęstej operacji macierz-macierz aktywującej wszystkie parametry modelu nad wszystkimi tokenami promptu.
Prefill przetwarza wszystkie tokeny promptu równolegle (macierz-macierz), w przeciwieństwie do sekwencyjnej fazy decode, której TTFT nie obejmuje.
Prefill jest compute-bound operacją macierz-macierz, która silnie korzysta z wysokiej wydajności FLOPS i tensor cores — skraca to TTFT.
Akceleratory macierzowe (TPU) dobrze obsługują compute-bound prefill dla dużych promptów.
Na CPU prefill długich promptów jest wolny, co prowadzi do wysokiego TTFT.