Buforowanie długich prefiksów

Każdy długi prompt wiąże się z kosztem wstępnego przetwarzania (prefill), podczas którego jego tokeny są kodowane przed generowaniem. Gdy ten sam długi prefiks powtarza się w wielu wywołaniach — na przykład prompt systemowy, specyfikacja narzędzia lub obszerny dokument referencyjny — buforowanie promptów pozwala dostawcy ponownie wykorzystać wcześniej obliczony stan mechanizmu uwagi zamiast obliczać go ponownie.

• Trafienia do bufora znacznie zmniejszają opóźnienie i koszt danych wejściowych.
• Oszczędności rosną wraz z rozmiarem prefiksu i częstotliwością jego ponownego użycia.

Bufory wykorzystują dokładne dopasowanie prefiksu tokenów od początku promptu. Buforowany fragment rozciąga się od początku do pierwszego miejsca rozbieżności. Zmiana czegokolwiek na początku powoduje, że cała dalsza część nie zostanie pobrana z bufora.

Wniosek: układ maksymalizujący liczbę trafień umieszcza najbardziej stabilne treści na początku, a najbardziej zmienne — na końcu.

Należy ułożyć treści od najbardziej do najmniej stabilnych: niezmienne reguły systemowe i definicje narzędzi, następnie duże, stabilne materiały referencyjne, dalej kontekst stabilny w ramach sesji, a na końcu zmienne dane wejściowe i pytanie dla danego żądania.

• Stabilne -> początek (możliwe do buforowania).
• Zmienna -> koniec (tylko ta część jest przetwarzana ponownie).

Ta jedna zasada kolejności odpowiada za większość korzyści z buforowania.

Niektórzy dostawcy pozwalają oznaczać jawne punkty buforowania. Należy umieszczać je na końcu każdego stabilnego segmentu, aby system mógł buforować treść do tego miejsca. Największy stabilny blok — korpus referencyjny lub długi prompt systemowy — należy oznaczyć jako możliwy do buforowania.

Bez jawnych znaczników należy mimo wszystko stosować kolejność według stabilności, aby niejawne dopasowanie prefiksu nadal przynosiło korzyści.

Subtelne, niezamierzone zmiany niepostrzeżenie przerywają buforowanie: znacznik czasu w promptcie systemowym, identyfikator żądania dodany na początku, zmieniona kolejność definicji narzędzi lub niedeterministyczna kolejność kluczy JSON. Każda taka zmiana przesuwa prefiks i wymusza ponowne przeliczenie całości.

Należy przeanalizować prefiks pod kątem wszystkiego, co zmienia się między wywołaniami, i przenieść takie elementy za obszar buforowany.

Cache wygasa po czasie życia (TTL) ustalonym przez dostawcę, często odnawianym przy każdym trafieniu. Zimne chybienia powtarzają się, jeśli wywołania są zbyt rzadkie. W przypadku skokowych obciążeń o dużej częstotliwości cache się opłaca; przy rzadkich, rozproszonych wywołaniach może wygasnąć między użyciami.

Dopasuj wzorzec ruchu do TTL i rozważ pingi keep-alive dla wartościowych prefiksów.

Cache zazwyczaj wiąże się z niewielką dodatkową opłatą za zapisanie wpisu i dużą zniżką za jego odczyt. Ekonomia sprzyja ponownemu użyciu: koszt jednego zapisu rozłożony na wiele odczytów daje dużą oszczędność netto; jednorazowe użycie, które tylko zapisuje dane, może kosztować nieco więcej.

• Dużo ponownych użyć -> intensywnie korzystaj z cache.
• Prefiksy używane tylko raz -> cache może się nie opłacać.

Zadbaj o deterministyczność promptu systemowego i specyfikacji narzędzi oraz przypinaj ich wersje. Sortuj definicje narzędzi w sposób kanoniczny, unikaj osadzania dynamicznych danych i zmieniaj je wyłącznie w ramach zaplanowanych wydań. Stabilny blok systemowy staje się długowiecznym wpisem cache o wysokim współczynniku trafień, współdzielonym przez wszystkie żądania.

Traktuj cache'owany prefiks jak artefakt z wersją, a nie jak ciąg znaków, który można swobodnie modyfikować.

W pętlach agentów rosnąca rozmowa jest naturalnym cache'em: każda tura rozszerza prefiks, który ponownie wykorzystuje następna. Dodawaj nowe tury na końcu i nigdy nie przepisuj wcześniejszych, aby poprzedni cache pozostał prawidłowy.

Gdy musisz skompaktować kontekst, zrób to tak, aby dla kolejnych tur powstał nowy stabilny prefiks, zamiast wielokrotnie modyfikować stare.

Instrumentuj rozwiązanie. Większość dostawców raportuje liczbę tokenów wejściowych obsłużonych z cache i bez niego dla każdego wywołania. Śledź współczynnik trafień, a jeśli jest niski, sprawdź prefiks pod kątem dryfu. Spadek współczynnika trafień zwykle wskazuje na niedawno wprowadzoną dynamiczną wartość na początku promptu.

• Rejestruj cached_tokens / total_input_tokens.
• Generuj alert, gdy po wdrożeniu współczynnik trafień spadnie.

Aby kontrolować koszt długich prefiksów: uporządkuj treść według stabilności, oznacz największy stabilny blok jako punkt graniczny cache, usuń ukryty dryf, ustal na stałe i wersjonuj bloki systemowe oraz blok narzędzi, stosuj model append-only w pętlach agentów i monitoruj współczynnik trafień. Celem jest jeden duży prefiks wielokrotnego użytku oraz niewielki, zmienny ogon przeliczany przy każdym wywołaniu.

Cache'owanie promptów pozwala ponownie wykorzystać fazę prefill dla dokładnie zgodnego, stabilnego prefiksu, znacznie zmniejszając opóźnienie i koszt tokenów wejściowych przy częstym ponownym użyciu. Uporządkuj treść od najbardziej stabilnej, oznacz duży stabilny blok jako punkt graniczny i przenieś całą zmienność na koniec. Usuń ukryty dryf, przypinaj wersje bloków systemowych i narzędzi, stosuj model append-only w pętlach agentów oraz monitoruj współczynnik trafień, aby jego spadek sygnalizował nowo wprowadzoną zmienną wartość na początku promptu.