czas do pierwszego tokena

Metryka mierząca czas od wysłania żądania do otrzymania pierwszego tokenu odpowiedzi. Obejmuje sieć, bramę, kolejkę i prefill. Jest niezależna od liczby tokenów na sekundę i bywa z nią sprzeczna, bo optymalizacje poprawiające przepustowość systemu pogarszają czas oczekiwania.

W Polsce nazywane też:

czas do pierwszego tokenaopóźnienie pierwszego tokenucisza po wysłaniu

Pytanie o to, ile trwa odpowiedź z API, jest źle postawione. Nie ma jednej liczby, są trzy i mierzą różne rzeczy.

Czym jest czas do pierwszego tokena

Czas do pierwszego tokena, w skrócie TTFT, to metryka mierząca odstęp między wysłaniem żądania a otrzymaniem pierwszego fragmentu odpowiedzi. Obejmuje drogę sieciową, uwierzytelnienie w bramie, wybór maszyny, czekanie w kolejce na miejsce w partii oraz przetworzenie promptu.

Dla użytkownika siedzącego przed ekranem jest to jedyna metryka, która się liczy.

Trzy metryki, nie jedna

TTFT mierzy ciszę po naciśnięciu przycisku i zależy głównie od długości promptu oraz od obciążenia dostawcy.

Liczba tokenów na sekundę mierzy tempo generowania i zależy od rozmiaru modelu, przepustowości pamięci i liczby rozmów dzielących z tobą kartę.

Czas całkowity jest sumą obu i ma sens przy zadaniach wsadowych, gdzie nikt nie patrzy na ekran.

Dlaczego bywają sprzeczne

Dostawca upychający więcej rozmów w jednej partii poprawia przepustowość całego systemu i pogarsza czas do pierwszego tokena, bo twoja prośba czeka na skompletowanie partii. Dostawca przetwarzający żądania natychmiast marnuje sprzęt i musi to odbić w cenie.

Stąd bierze się zjawisko wyglądające na sprzeczność w porównaniach: ten sam dostawca bywa najszybszy w jednym teście i najwolniejszy w drugim. Testy mierzyły różne metryki na zadaniach o różnym profilu.

Co z tym zrobić

Przy wyborze dostawcy zmierz obie metryki na własnym profilu ruchu, nie na cudzym benchmarku. Jeśli twoje zadania mają krótkie prompty i długie odpowiedzi, TTFT jest prawie bez znaczenia. Jeśli wysyłasz długie dokumenty, TTFT jest całym problemem.

Streaming nie przyspiesza niczego — maskuje czas generowania, którego nie da się usunąć. Nie maskuje natomiast ciszy przed pierwszym tokenem.

Powiązane pojęcia

przetwarzanie partiami w trybie ciągłymTechnika serwowania modeli, w której wiele równoległych rozmów dzieli jeden odczyt wag z pamięci, a żądania dołączają i opuszczają partię w trakcie jej przetwarzania. Podstawa ekonomii API — bez niej koszt tokenu byłby wielokrotnie wyższy.przetwarzanie promptu i generowanieDwie fazy pracy modelu o przeciwnej charakterystyce. Prefill przetwarza cały prompt równolegle, obciąża rdzenie i decyduje o czasie do pierwszego tokena. Decode generuje odpowiedź sekwencyjnie, obciąża pamięć i decyduje o liczbie tokenów na sekundę.wnioskowanie modeluUżycie wytrenowanego modelu do wygenerowania odpowiedzi, przy zamrożonych wagach. Dzieli się na przetworzenie promptu i sekwencyjne generowanie token po tokenie — stąd różne stawki za tokeny wejściowe i wyjściowe oraz to, że długa odpowiedź kosztuje czasowo więcej niż długi prompt.Opóźnienie agentoweŁączny czas od zlecenia zadania agentowi do dostarczenia wyników — suma wywołań modelu, narzędzi, retrieval i orchestration overhead. Kluczowa metryka dla interaktywnych zastosowań wymagająca decyzji: równoległe wywołania, cachowanie, dobór modelu, sync vs async.Ograniczenie wywołań APIMechanizm ograniczający wywołania API w danym oknie czasowym — wymagający od agentów exponential backoff przy błędach 429, queue-based throttling i monitoringu zużycia. Jeden agent w pętli bez rate limit management może zablokować wszystkie inne agenty w organizacji.