przetwarzanie partiami w trybie ciągłym

Technika 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.

W Polsce nazywane też:

batching ciągłyprzetwarzanie partiamiłączenie żądańkolejkowanie żądań

Karta obsługująca jedną rozmowę w fazie generowania pracuje na dwóch procentach mocy. Dziewięćdziesiąt osiem procent sprzętu za dziesiątki tysięcy dolarów stoi i czeka, aż wagi przepłyną z pamięci do rdzeni. Żaden model biznesowy tego nie udźwignie.

Czym jest batching ciągły

Batching ciągły to technika serwowania modeli, w której wiele niezależnych rozmów jest przetwarzanych równolegle przez ten sam silnik, dzieląc jeden odczyt wag z pamięci. W odróżnieniu od batchingu statycznego, żądania mogą dołączać do partii i opuszczać ją w trakcie przetwarzania, bez czekania, aż wszystkie zakończą generowanie.

Dlaczego to działa

Wagi odczytane z pamięci są te same dla wszystkich. Skoro wąskim gardłem przy generowaniu jest odczyt, a nie liczenie, to jeden odczyt może obsłużyć dwieście rozmów zamiast jednej — przy niemal niezmienionym czasie. Rdzenie, które i tak stały bezczynnie, dostają pracę.

To jest cała ekonomia serwowania modeli w jednym zdaniu.

Co z tego wynika dla ciebie

Kolejka istnieje, bo trzeba poczekać na skompletowanie partii albo na zwolnienie miejsca w trwającej.

Czas odpowiedzi się waha, bo partia bywa raz pełna, raz prawie pusta, a ty nie masz wglądu w to, ilu innych użytkowników akurat pisze.

Limity tokenów na minutę istnieją, bo miejsce w partii jest skończone, a zajmuje je nie twoje ostatnie zdanie, tylko cały kontekst przesyłany od nowa.

Długie konteksty są droższe, bo pamięć podręczna twojej rozmowy blokuje miejsce, którego nie da się oddać nikomu innemu — i to ona, a nie wagi, ogranicza liczbę rozmów mieszczących się w jednej karcie.

Ograniczenie

Batching poprawia przepustowość systemu kosztem czasu do pierwszego tokena pojedynczego użytkownika. Dostawcy balansują te dwie wielkości i różnią się w tym wyborze — co jest jednym z niewielu realnych kryteriów różnicujących oferty tego samego modelu.

akcelerator obliczeniowyUkład zaprojektowany do wykonywania wielu prostych operacji równolegle — karta graficzna, TPU lub NPU. Dla modeli językowych liczą się w nim dwa parametry osobno: moc obliczeniowa, która rządzi przetwarzaniem promptu, i przepustowość pamięci, która rządzi generowaniem odpowiedzi.czas do pierwszego tokenaMetryka 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.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ę.Infrastruktura wnioskowania modeliSprzęt i oprogramowanie dedykowane do uruchamiania modeli AI w czasie rzeczywistym — GPU accelerators, batching, quantization, model serving — odpowiadające na żądania z odpowiednią latencją i kosztem. Własna infrastruktura uzasadniona przy dużych wolumenach lub wymaganiach data sovereignty.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.Koszt tokenówKoszt operacji modelu językowego mierzony w tokenach — funkcja rozmiaru kontekstu, długości outputu i ceny modelu. Kluczowa metryka projektowa dla agentów w skali. Context window bloat jako główny winowajca wysokich kosztów. Model routing i prompt caching jako strategie optymalizacji.