Za HTTP — co dzieje się z prośbą po drugiej stronie

Między twoim fetch a pierwszym bajtem odpowiedzi stoi sześć warstw, z których tylko jedna jest modelem — a i ona dzieli się na dwie fazy o zupełnie różnym charakterze. Przez cztery poprzednie artykuły oglądaliśmy mechanizm na własnym urządzeniu, gdzie wszystko było widoczne. Teraz ten sam mechanizm przenosi się na cudzy serwer i staje się niewidzialny.

To nie znaczy, że przestaje obowiązywać. Znaczy tylko, że trzeba go wywnioskować.

Dobra wiadomość jest taka, że masz już wszystko, czego do tego potrzeba. Wiesz, że wagi trzeba przeczytać przy każdym tokenie. Wiesz, że historia rozmowy zajmuje pamięć i nie zwalnia jej do końca sesji. Wiesz, że generowanie marnuje kartę w dziewięćdziesięciu ośmiu procentach. Cała reszta tego toru to konsekwencje tych trzech faktów.

Sześć warstw między tobą a wagami

Prześledźmy drogę pojedynczej prośby. Nie po to, żeby zapamiętać nazwy, tylko żeby zobaczyć, gdzie ucieka czas.

Sieć. Twoje żądanie leci do najbliższego punktu wejścia dostawcy. Od Wrocławia do Frankfurtu to kilkanaście milisekund, do Wirginii sto kilkadziesiąt. Zwykle pomijalne, ale warto wiedzieć, że to jedyna warstwa, na którą naprawdę nie masz żadnego wpływu poza wyborem regionu.

Brama. Sprawdzenie klucza, przypisanie do organizacji, zliczenie limitów, decyzja, czy w ogóle cię wpuścić. Milisekundy — chyba że akurat wypadłeś z limitu, wtedy to jedyna warstwa, jaką zobaczysz.

Router. Nazwa modelu, którą podałeś, nie wskazuje maszyny. Wskazuje pulę maszyn, prawdopodobnie w kilku regionach, prawdopodobnie na różnym sprzęcie. Router wybiera, do której trafisz — na podstawie obciążenia, a coraz częściej także na podstawie tego, czy któraś z nich ma już w pamięci fragment twojej rozmowy. Ta ostatnia przesłanka jest ważniejsza, niż się wydaje, i wrócę do niej w artykule o cache’owaniu.

Kolejka. Twoja prośba czeka, aż zwolni się miejsce w partii przetwarzanej wspólnie z innymi. To tutaj ginie większość czasu, którego nie umiesz sobie wytłumaczyć — i to tutaj leży temat następnego artykułu.

Silnik inferencyjny. Prefill, potem decode, dokładnie jak na twoim laptopie. Tylko że przeplatany z kilkuset innymi rozmowami.

Droga powrotna. Tokeny wracają strumieniem, przechodząc po drodze przez filtry bezpieczeństwa i liczniki zużycia.

Model siedzi w warstwie piątej. Pięć pozostałych to zwykła inżynieria systemów rozproszonych, która z uczeniem maszynowym nie ma nic wspólnego — a odpowiada za większość tego, co odczuwasz jako „to API dziś muli”.

Droga jednej prośby

webflux · maszyneria modelu

Od fetch do pierwszego bajtu odpowiedzi. Z siedmiu przystanków tylko dwa to model.

1

Sieć

Do najbliższego punktu wejścia dostawcy

10–150 ms

2

Brama

Klucz, organizacja, limity

1–5 ms

3

Router

Wybór maszyny z puli, nie modelu

2–10 ms

4

Kolejka

Czekanie na miejsce w partii

0–2000 ms

tu ginie czas

5

Prefill

Czytanie promptu, wypełnianie pamięci podręcznej

50–3000 ms

model

6

Decode

Pisanie odpowiedzi, token po tokenie

20–700 tok/s

model

7

Powrót

Filtry wyjścia, liczniki, strumień

na bieżąco

czas do pierwszego tokena

tokeny na sekundę

Warstwy 1–4 i 7 to zwykła inżynieria systemów rozproszonych. Z uczeniem maszynowym nie mają nic wspólnego — a odpowiadają za większość tego, co odczuwasz jako „dziś muli".

Czasy orientacyjne · zależą od dostawcy i regionu Maszyneria agenta →

Jedna liczba, która nie mówi nic

Kiedy ktoś pyta, ile trwa odpowiedź z API, pytanie jest źle postawione. Nie ma jednej liczby, są trzy i mierzą różne rzeczy.

Czas do pierwszego tokena obejmuje sieć, bramę, router, kolejkę i prefill. To jest cisza po naciśnięciu przycisku. Dla użytkownika siedzącego przed ekranem jest to jedyna metryka, która się liczy, bo od momentu, gdy tekst zaczyna płynąć, wrażenie szybkości jest już zbudowane.

Tokeny na sekundę to czysty decode. Zależy od rozmiaru modelu, przepustowości pamięci i tego, ilu innych ludzi dzieli z tobą tę kartę.

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

Te trzy liczby bywają ze sobą sprzeczne. Dostawca, który upycha więcej rozmów w jednej partii, poprawia przepustowość całego systemu i pogarsza czas do pierwszego tokena. Dostawca, który przetwarza twoją prośbę natychmiast, marnuje kartę i musi to gdzieś odbić w cenie.

Stąd bierze się rzecz, która wygląda na sprzeczność w recenzjach, a nią nie jest: ten sam dostawca bywa „najszybszy” w jednym teście i „najwolniejszy” w drugim. Bo testy mierzyły różne metryki zadania o różnym profilu. Pytanie „który dostawca jest szybszy” nie ma odpowiedzi bez podania, co konkretnie robisz.

Cennik jest mapą fizyki

Wróćmy do rozróżnienia z poprzedniego artykułu, bo teraz zobaczymy je w wersji, którą można przeczytać w tabelce na stronie dostawcy.

Tokeny wejściowe kosztują zwykle trzy do pięciu razy mniej niż wyjściowe. Nie jest to zachęta do pisania krótkich promptów ani sprytna polityka cenowa. To jest odzwierciedlenie tego, ile kartograficznego czasu zabiera jedno i drugie.

Token wejściowy jest przetwarzany w prefillu, razem z tysiącem innych, przy wykorzystaniu karty bliskim stu procent. Token wyjściowy wymaga osobnego przejścia przez cały model, przy wykorzystaniu karty rzędu dwóch procent. Różnica w cenie nie jest arbitralna — jest po prostu mniejsza niż różnica w koszcie, bo batching pozwala dostawcy część tej przepaści odrobić.

Kiedy więc patrzysz na cennik i widzisz dwie kolumny, nie patrzysz na decyzję marketingową. Patrzysz na prefill i decode, przepisane na złotówki.

Co naprawdę znaczy „limit”

Dostawcy podają zwykle dwa limity: liczbę żądań na minutę i liczbę tokenów na minutę. Drugi jest ważniejszy i dla wielu ludzi zaskakujący, bo liczy się do niego cały kontekst, nie tylko to, co dopisałeś.

Wyślij dwadzieścia razy tę samą rozmowę o długości trzydziestu tysięcy tokenów, dopisując za każdym razem jedno zdanie, a zużyjesz sześćset tysięcy tokenów wejściowych, nie dwadzieścia zdań. Twój limit wyczerpie się na dwudziestu wymianach.

Powód jest ten sam co zawsze. Model nie pamięta poprzedniej tury — pamięć podręczna, którą zbudował, została zwolniona zaraz po odpowiedzi, bo blokowała miejsce potrzebne komu innemu. Za każdym razem cała historia musi przejść prefill od nowa.

To nie jest limit administracyjny. To jest rachunek za pracę, która naprawdę się wykonuje. I to jest jednocześnie powód, dla którego cache’owanie promptów, o którym będzie osobny artykuł, potrafi ściąć rachunek trzykrotnie.

Czego nie widzisz, a co się wydarzyło

Kilka rzeczy dzieje się z twoją prośbą bez twojej wiedzy i warto o nich wiedzieć, choćby po to, żeby nie przypisywać modelowi cudzych zasług i cudzych błędów.

Twój prompt bywa przepisywany. Nie zawsze i nie u wszystkich, ale bywa — dodana instrukcja systemowa, normalizacja formatu, wstrzyknięta data. Model, do którego trafia twój tekst, dostaje coś nieco innego niż to, co wysłałeś.

Odpowiedź bywa zatrzymywana. Filtry bezpieczeństwa działają na wyjściu i mogą przerwać strumień w połowie. To nie jest awaria modelu — to warstwa szósta.

Nie zawsze dostajesz ten sam model. Etykieta wskazuje rodzinę i wersję, ale konkretna maszyna może mieć inną precyzję wag, inny runtime, inną konfigurację. Wracamy tu do wniosku z drugiego artykułu: nazwa modelu opisuje jedną z czterech zmiennych.

Twoja prośba nie jest przetwarzana sama. Dzieli kartę z dziesiątkami innych i to jest najważniejsza z tych niewidzialnych rzeczy.

Dlaczego to w ogóle działa tak, a nie inaczej

Można by zapytać, dlaczego dostawca nie da po prostu każdemu klientowi własnej karty i nie przestanie kombinować z kolejkami.

Odpowiedź policzyliśmy w poprzednim artykule. Karta obsługująca jedną rozmowę w fazie decode pracuje na dwóch procentach mocy. Dziewięćdziesiąt osiem procent sprzętu za trzydzieści tysięcy dolarów stoi i czeka, aż wagi przepłyną z pamięci do rdzeni.

Żaden model biznesowy tego nie udźwignie. Cena za token musiałaby być pięćdziesiąt razy wyższa.

Więc dostawca robi jedyną rzecz, jaką może zrobić: wkłada do jednej karty tyle rozmów, ile się da, bo wagi odczytane z pamięci są te same dla wszystkich. Jeden odczyt, dwieście rozmów. To jest cała ekonomia tej branży w jednym zdaniu.

I z tej jednej decyzji wynika absolutnie wszystko, co odczuwasz jako dziwactwa API. Kolejka istnieje, bo trzeba poczekać na skompletowanie partii. Czas odpowiedzi się waha, bo partia jest raz pełna, raz pusta. Limity istnieją, bo miejsce w partii jest skończone. Długie konteksty są droższe, bo zjadają pamięć, której nie da się dać nikomu innemu.

Co dalej

Opisałem kolejkę jako miejsce, w którym ginie czas, i zostawiłem to bez wyjaśnienia. Teraz je uzupełnimy.

Następny artykuł jest o tym, co dokładnie dzieje się w tej partii: jak dwieście rozmów przechodzi przez jedną kartę naraz, dlaczego twoja prośba czasem czeka na cudzą, i dlaczego mechanizm, który wygląda na kolejkę w urzędzie, jest w rzeczywistości jedyną rzeczą, dzięki której API kosztuje tyle, ile kosztuje.

To będzie ten sam prefill i decode, które widziałeś na własnym laptopie — tylko pomnożone przez dwieście i poukładane w czasie przez algorytm, który musi godzić sprzeczne interesy.