Dwukierunkowy transfer KV w vLLM ogranicza powtarzaną pracę w agentach wieloturowych
AWS poinformowało o przyspieszeniu czasu do pierwszego tokenu nawet 3,3 raza dzięki dwukierunkowemu transferowi KV w vLLM, który przenosi możliwe do ponownego wykorzystania obliczenia modelu między serwerami w obu kierunkach. Czas do pierwszego tokenu, czyli TTFT, mierzy, jak długo żądanie czeka, zanim rozpocznie się jego odpowiedź. Zmiana dotyczy konkretnej nieefektywności: agenci wielokrotnie przetwarzają historię rozmowy, którą ich infrastruktura obsługująca już wcześniej obliczyła.
We wpisie z 19 października AWS podało poprawę do 1,6 raza dla Qwen3-32B i 3,3 raza dla GLM-5-FP8. Jego testy wnioskowania wieloturowego wykorzystywały instancje Amazon EC2 P5en połączone przez Elastic Fabric Adapter, sieć AWS zaprojektowaną dla wymagających rozproszonych obciążeń. Są to wyniki raportowane przez firmę, a nie niezależnie potwierdzona gwarancja wydajności.
Kluczowa rywalizacja toczy się między ponownym obliczaniem starego kontekstu a pobieraniem możliwych do wykorzystania obliczeń z innego serwera. NVIDIA Dynamo stanowi użyteczny punkt odniesienia w branży dla tego wyboru infrastrukturalnego. Dla deweloperów budujących agentów najważniejsze pytanie brzmi, czy ich własne obciążenia poświęcają wystarczająco dużo czasu na powtarzanie starej pracy, aby uzasadnić dodatkową koordynację.
Co zmienia dwukierunkowy transfer KV w vLLM
Funkcja udostępnia pracę wykonaną podczas wcześniejszej odpowiedzi serwerowi przetwarzającemu kolejne żądanie.
Pamięć podręczna klucz-wartość, czyli KV cache, przechowuje pośrednie dane uwagi, które model językowy ponownie wykorzystuje podczas przetwarzania sekwencji. Prefill przetwarza tokeny wejściowe, czyli jednostki tekstu konsumowane przez model. Decode generuje odpowiedź. W rozdzielonej obsłudze osobni workerzy obsługują te fazy.
Nowa ścieżka ma znaczenie, ponieważ serwer generujący odpowiedź posiada przydatne obliczenia z tej odpowiedzi. Kolejne żądanie może zawierać wygenerowane słowa wraz z wcześniejszą rozmową. Jeśli inne żądanie przetwarza inny serwer, użyteczna praca z pamięci podręcznej może w przeciwnym razie pozostać uwięziona po stronie generowania.
Przewodnik po konektorze NIXL opisuje stanowy serwer proxy, który śledzi lokalizacje pamięci podręcznej między turami. NIXL, NVIDIA Inference Xfer Library, zapewnia mechanizm transferu. W późniejszej turze worker prefill może pobrać kwalifikujące się bloki od workera decode przed przetworzeniem nowego wejścia.
Zmienia to źródła, z których może pochodzić praca nadająca się do ponownego użycia. Nie eliminuje potrzeby przetwarzania rzeczywiście nowego materiału.
Rozważmy przykładowego agenta programistycznego badającego nieudane kompilowanie. Odczytuje błąd, proponuje wyjaśnienie, wywołuje narzędzie i otrzymuje wynik testu. Kolejne żądanie do modelu zawiera zarówno znaną historię rozmowy, jak i nowe dowody. Powtarzanie obliczeń dla znanej części nie wnosi nic nowego do dochodzenia.
Pobieranie jest atrakcyjne, gdy przeniesienie istniejących obliczeń zajmuje mniej czasu niż ich odtworzenie. Ten warunek stanowi ekonomiczne i techniczne centrum tej funkcji. Transfer, który oszczędza obliczenia, lecz wydłuża oczekiwanie, niweczyłby jego cel.
Wyjaśnia to również, dlaczego wiadomość wykracza poza szybszy benchmark modelu. Sam model może pozostać niezmieniony, podczas gdy system obsługi zmienia sposób, w jaki wcześniejsza praca przetrwa między wywołaniami. Zachowanie infrastruktury staje się częścią responsywności agenta.
Dla zespołów produktowych to rozróżnienie pomaga określić odpowiedzialność. Powolna odpowiedź uzupełniająca nie oznacza automatycznie, że wybrany model wymaga zastąpienia. Aplikacja może ponownie płacić za kontekst, który już przetworzyła.
Dla zespołów infrastrukturalnych zmienia to jednostkę analizy. Traktowanie każdego żądania jako niezwiązanego z innymi może ukrywać możliwości widoczne tylko wtedy, gdy żądania należą do ciągłego zadania. Rozmowa staje się istotna dla harmonogramowania i zarządzania pamięcią podręczną.
Praktyczna zmiana jest zatem węższa niż trwała pamięć agenta, lecz bardziej konkretna. Dotyczy obliczeń wielokrotnego użytku przypisanych do ciągłej sekwencji wejściowej. To, czy agent pamięta właściwe fakty, pozostaje odrębnym problemem aplikacyjnym.
Ta granica sprawia, że ogłoszenie pozostaje użyteczne. Wskazuje mierzalne źródło opóźnień, nie twierdząc, że rozwiązuje jakość rozumowania, niezawodność narzędzi ani każde opóźnienie otaczające agenta.
Rosnące rozmowy wywierają presję na zespoły obsługujące modele
Najbardziej narażone są zespoły obsługujące powtarzane, bogate w kontekst wywołania modeli w ramach tego samego zadania.
Presja wynika z niedopasowania między zachowaniem aplikacji a infrastrukturą zorientowaną na żądania. Zadanie agenta trwa przez kolejne wywołania, podczas gdy system obsługi nadal musi zdecydować, jakie obliczenia przetrwają każde żądanie.
Przykładowy asystent badawczy dobrze pokazuje to niedopasowanie. Gromadzi dokumenty, porównuje ustalenia, otrzymuje korektę i poprawia odpowiedź. Każdy etap wprowadza nowe informacje, lecz znaczna część kontekstu roboczego pozostaje istotna.
Z perspektywy użytkownika te etapy należą do tego samego zadania. Z perspektywy warstwy obsługi każdy etap tworzy kolejne żądanie z wejściem do przetworzenia. Szansa polega na rozpoznaniu ciągłości bez założenia, że każda część wejścia pozostaje możliwa do ponownego wykorzystania.
To rozróżnienie ma znaczenie dla nabywców korporacyjnych oceniających demonstracje agentów. Responsywna początkowa wymiana nie dowodzi, że długa analiza pozostanie responsywna. Ocena powinna śledzić zadanie w późniejszych turach, w tym po korektach i zwrotach z narzędzi.
Ma to również znaczenie dla menedżerów inżynieryjnych wybierających obszary inwestycji. Wybór modelu, projekt aplikacji i konfiguracja obsługi dotyczą różnych źródeł opóźnień. Ogólne stwierdzenie, że agent wydaje się wolny, daje niewiele wskazówek, dopóki te źródła nie zostaną rozdzielone.
Dokumentacja vLLM w swoich wytycznych dotyczących rozdzielonego prefillingu dokonuje istotnego rozróżnienia. Rozdzielenie prefill i decode pozwala niezależnie dostrajać ich charakterystykę opóźnień. Dokumentacja ostrzega również, że sama dezagregacja nie poprawia przepustowości, czyli ilości pracy wykonywanej przez system w czasie.
To ostrzeżenie zapobiega łatwemu przejściu od szybszego rozpoczęcia odpowiedzi do większej całkowitej pojemności. Aplikacja może poprawić jedną miarę opóźnienia, podczas gdy inne wąskie gardło pozostaje bez zmian. Nabywcy powinni pytać, jaki wynik faktycznie ma osiągnąć proponowana zmiana infrastruktury.
Agent obsługi klienta ilustruje tę różnicę. Szybsze rozpoczęcie wyjaśnienia sprawia, że rozmowa wydaje się bardziej responsywna. Niekoniecznie jednak skraca powolne wyszukiwanie konta lub czas potrzebny na wykonanie zewnętrznej akcji.
Podobnie asystent programistyczny może wcześniej rozpocząć opisywanie naprawy, nie kończąc wcześniej zestawu testów. Poprawa wydajności pozostaje wartościowa, lecz jej wkład należy rozpatrywać w ramach szerszej osi czasu zadania.
Dla pracowników umysłowych powiązanie z osobistą bazą wiedzy jest praktyczne: znajdowanie przydatnych informacji i przetwarzanie powtarzanego kontekstu tworzą różne oczekiwania. Poprawa jednego nie dowodzi poprawy drugiego.
Wniosek dla zespołów produktowych jest taki, by mierzyć zarówno rozpoczęcie odpowiedzi, jak i ukończone zadania. W przeciwnym razie zysk infrastrukturalny może zostać wyolbrzymiony w marketingu lub przeoczony podczas rozwoju.
Dlatego wnioskowanie wieloturowe vLLM zasługuje na ocenę jako sekwencja. Ważne pytanie nie brzmi po prostu, czy serwer odpowiada szybko. Chodzi o to, czy powtarzane interakcje zachowują użyteczną pracę w miarę rozrastania się zadania.
Ponowne użycie konkuruje z ponownym obliczaniem, a nie z rywalizującym modelem
Najtrafniejsze porównanie dotyczy alternatywnych sposobów obsługi tego samego ciągłego obciążenia.
Przekształcanie tego ogłoszenia w ranking modeli byłoby mylące. AWS przetestowało optymalizację obsługi. Wyniki nie dowodzą, że jeden model stał się bardziej zdolny od innego.
Istniejąca linia bazowa również wymaga ostrożnego traktowania. vLLM już obsługuje automatyczne buforowanie prefiksów, które ponownie wykorzystuje obliczenia z pamięci podręcznej, gdy żądania mają wspólną początkową sekwencję. Dokumentacja wskazuje powtarzane pytania dotyczące dokumentów i rozmowy wieloturowe jako istotne obciążenia.
Dwukierunkowy transfer dotyczy zatem dostępu do obliczeń możliwych do ponownego wykorzystania między workerami. Nie wprowadza ogólnej idei unikania powtarzanego przetwarzania promptów.
To rozróżnienie zmienia sposób, w jaki zespoły powinny interpretować porównanie. Wdrożenie, które już zachowuje użyteczną lokalną pamięć podręczną, zaczyna z innego punktu niż takie, które wielokrotnie traci do niej dostęp. Dodatkowa korzyść zależy od tego, co faktycznie robi obecny system.
Podział vLLM na prefill i decode tworzy problem rozmieszczenia, a także problem obliczeniowy. Użyteczna praca może istnieć gdzieś we wdrożeniu, nie będąc dostępną tam, gdzie potrzebuje jej kolejne żądanie.
Pomocna analogia to zespół inżynieryjny powtarzający analizę, ponieważ ukończony wynik znajduje się w innej grupie. Brakującym składnikiem jest dostęp i koordynacja. Przyspieszenie pierwotnego obliczenia rozwiązałoby inną część problemu.
Dokumentacja NVIDIA dotycząca rozdzielonej obsługi zapewnia neutralne porównanie. Dynamo rozdziela workery prefill i decode oraz odróżnia to rozdzielenie od routingu opartego na lokalizacji pamięci podręcznej. Ostrzega również, że dezagregacja nie jest automatycznie lepsza dla każdego obciążenia.
Czyni to Dynamo punktem odniesienia w branży, a nie dowodem bezpośredniego zwycięstwa konkurencyjnego. Dokumentacja pokazuje, że rozmieszczenie workerów, transfer i ponowne użycie są szerszymi zagadnieniami obsługi. Nie dostarcza dopasowanego porównania z tą konfiguracją AWS.
Dla nabywców użyteczne pytanie konkurencyjne brzmi, czy alternatywny system obsługuje ich wzorce rozmów wydajniej w porównywalnych warunkach. Same nazwy produktów nie mogą na nie odpowiedzieć.
To samo rozumowanie dotyczy wnioskowania wieloturowego vLLM w ramach istniejącego wdrożenia. Zespół powinien porównać proponowaną ścieżkę z rzeczywistą bieżącą konfiguracją. Porównanie ze sztucznie słabszym układem odpowiada na węższe pytanie.
Istnieje również wybór dotyczący miejsca, w którym powinna znajdować się złożoność. Utrzymywanie pracy lokalnie może uprościć dostęp, lecz ograniczać rozmieszczenie. Pobieranie jej zdalnie może rozszerzyć możliwości ponownego użycia, wprowadzając jednocześnie koordynację i pracę związaną z transferem.
Żadne podejście nie wygrywa z definicji. Rozstrzygającym dowodem jest to, czy oszczędzone obliczenia przewyższają dodatkową pracę w warunkach operacyjnych aplikacji.
Takie ujęcie utrzymuje analizę wokół zweryfikowanego wydarzenia. Unika wymyślania rywalizacji między AWS a NVIDIA, gdy sama implementacja wykorzystuje technologię transferu NVIDIA.
Ogłoszenie lepiej rozumieć jako udoskonalenie rozproszonego wnioskowania. Udostępnia dodatkową ścieżkę ponownego użycia, a następnie pozostawia operatorom ustalenie, kiedy ta ścieżka się opłaca.
Przetrwanie pamięci podręcznej staje się częścią równania wydajności
Funkcja ponownego użycia zapewnia wartość tylko wtedy, gdy użyteczne obliczenia pozostają dostępne, gdy nadejdzie kolejne żądanie.
Dokumentacja konektora określa domyślny okres przechowywania po stronie dekodowania na 480 sekund. Opisuje także domyślny próg 64 tokenów możliwych do ponownego wykorzystania, po którego przekroczeniu uruchamiany jest transfer zwrotny. Poniżej tego progu system ponownie oblicza dane lokalnie.
Te mechanizmy ujawniają kompromis kryjący się za nagłówkiem. Przechowywanie danych w pamięci podręcznej zajmuje pamięć. Ich pobieranie wymaga dodatkowej pracy. Zbyt wczesne zwolnienie danych usuwa możliwość ich przyszłego ponownego wykorzystania.
Właściwy wybór zależy od charakteru zadania, a nie od uniwersalnej preferencji dla większego buforowania. Rozmowa wznowiona szybko daje inną możliwość niż taka, która zostaje wstrzymana, gdy człowiek analizuje wynik.
Wyobraźmy sobie wewnętrznego agenta analitycznego oczekującego na zatwierdzenie przed kontynuowaniem. Jego kolejne żądanie może nadejść po krótkiej kontroli albo po spotkaniu. Utrzymywanie obliczeń przez każdy z tych okresów ma konsekwencje dla zasobów, nawet gdy model nie odpowiada aktywnie.
Zautomatyzowany agent tworzy inny wzorzec. Zakończenie działania narzędzia, ponowne próby i harmonogramowanie aplikacji mogą określać moment nadejścia kolejnego żądania. Operatorzy powinni więc analizować rzeczywiste przerwy między turami zamiast wyciągać wnioski na podstawie dopracowanej demonstracji.
Próg pobierania rodzi równoległą kwestię. Zdalne ponowne wykorzystanie wiąże się z narzutem, więc uniknięcie obliczeń nie jest wystarczającym dowodem na szybsze żądanie. Ilość pracy możliwej do ponownego użycia musi uzasadniać pobranie.
W przypadku dwukierunkowego transferu KV w vLLM oznacza to, że decyzja konfiguracyjna może wpływać zarówno na opóźnienia, jak i presję na pamięć. Wyniki te należy analizować łącznie, zamiast optymalizować je w izolacji.
Zespół świętujący szybsze rozpoczęcie odpowiedzi powinien także pytać, jakie zasoby pozostawały zajęte między tymi odpowiedziami. Inny zespół, ograniczający utrzymywaną pamięć, powinien zapytać, ile powtarzanej pracy wróciło w konsekwencji.
To pytania ewaluacyjne, a nie dowód, że funkcja koniecznie szkodzi pojemności. Opublikowane twierdzenie wskazuje możliwość zmniejszenia opóźnień w określonych warunkach. Szersza ekonomika wdrożenia wymaga dodatkowych pomiarów.
Obsługa sesji zasługuje na podobną uwagę. System musi powiązać kontynuowane żądanie z właściwymi wcześniejszymi obliczeniami. Zmiany w aplikacji, które przerywają to powiązanie, mogą osłabić skądinąd odpowiedni przypadek użycia.
Na przykład zespół produktowy może przeprojektować sposób tworzenia lub wznawiania rozmów. Ta pozornie odrębna zmiana w aplikacji powinna skłonić do ponownej kontroli wydajności. Ścieżka ponownego wykorzystania zależy od ciągłości docierającej do warstwy obsługi.
Granica między prefill a decode w vLLM staje się zatem kwestią operacyjną nie tylko dla specjalisty od obsługi modeli. Inżynierowie aplikacji i infrastruktury potrzebują wspólnego zrozumienia tego, jak zadanie jest kontynuowane między żądaniami.
Szersza lekcja dotyczy świadomego zachowywania użytecznej pracy. Przechowywanie cache, tożsamość żądania i decyzje dotyczące transferu należą do tej samej dyskusji o wydajności. Traktowanie ich jako niepowiązanych ustawień utrudnia wyjaśnienie wynikowego zachowania.
Benchmark mierzy konkretny scenariusz braku trafienia w cache
Największe raportowane przez AWS zyski należy odczytywać w kontekście bazowej konfiguracji, która je wygenerowała.
AWS wyłączył lokalne buforowanie prefiksów na workerze prefill, aby zasymulować usunięcie danych z cache lub przekierowanie do workera bez bloków zapisanych w pamięci podręcznej danej rozmowy. W porównaniu wykorzystano jeden węzeł prefill i jeden węzeł decode.
To istotny scenariusz, lecz nie reprezentuje każdego wdrożenia produkcyjnego. Sprawdza, co dzieje się, gdy strona prefill nie ma lokalnego kontekstu nadającego się do ponownego użycia. Nie wykazuje takiej samej przewagi nad układem, który konsekwentnie zachowuje ten kontekst.
Przewodnik odtwarzania benchmarku dodaje ważny szczegół implementacyjny. Instrukcje przypinają konkretne wersje oprogramowania i zawierają poprawkę zwracającą metadane transferu w odpowiedziach strumieniowych. Odtworzenie wyniku wymaga zatem uwagi poświęconej testowanej ścieżce oprogramowania.
Ten szczegół jest użyteczny właśnie dlatego, że ma charakter operacyjny. Sama flaga funkcji nie jest wystarczającym dowodem, że wdrożenie rzeczywiście ponownie wykorzystuje zdalne obliczenia. Przepływ żądań musi przenosić informacje potrzebne do ich odnalezienia.
Niezależna weryfikacja pozostaje odrębną kwestią. Materiały do odtworzenia czynią eksperyment bardziej możliwym do zbadania, ale opublikowanie instrukcji samo w sobie nie stanowi zewnętrznej replikacji.
Nie ma potrzeby odrzucać wyniku tylko dlatego, że pochodzi od dostawcy. Właściwą reakcją jest zachowanie jego zakresu. AWS raportuje korzyść dla udokumentowanej konfiguracji; operatorzy nadal potrzebują dowodów dla własnego ruchu.
Sformułowanie „do” również ma realne znaczenie. Wskazuje korzystny zaobserwowany wynik, a nie oczekiwany rezultat dla każdego żądania. Krótsze dane wejściowe, inne wzorce ponownego wykorzystania lub inne warunki wdrożenia wymagają własnych pomiarów.
Opóźnienie rozpoczęcia odpowiedzi należy odróżniać od całkowitego czasu trwania zadania. Pierwszy token może pojawić się wcześniej, podczas gdy reszta odpowiedzi zajmie podobną ilość czasu. Praca narzędzi i przetwarzanie aplikacji mogą pozostawać poza zakresem tej poprawy.
Podobnie korzystne porównanie ustawień funkcji nie dowodzi proporcjonalnego spadku wydatków na infrastrukturę. Taki wniosek wymagałby pomiarów zasobów i pojemności obok opóźnień.
Użyteczna ocena zachowałaby bazową konfigurację produkcyjną zamiast usuwać jej istniejące optymalizacje. Następnie wskazałaby, gdzie zdalne ponowne wykorzystanie daje wartość ponad tymi optymalizacjami.
Test powinien również celowo obejmować niekorzystne przypadki. Żądania bez kontekstu możliwego do ponownego użycia, wznawiane rozmowy i zwykłe przerwania działania aplikacji pomagają określić granice poprawy.
Przypadki te nie odwracają uwagi od benchmarku. Określają, jak często korzystne warunki benchmarku występują w usłudze, z której faktycznie korzystają klienci.
To właściwy sceptyczny punkt widzenia na ogłoszenie. Mechanizm jest udokumentowany, a raportowany wynik jest konkretny. Nierozstrzygnięte pozostaje pytanie o częstotliwość i wartość tej możliwości poza testowaną konfiguracją.
Na co operatorzy powinni zwracać uwagę przez najbliższe trzy miesiące
Kolejne użyteczne dowody połączą odtwarzalne zyski w zakresie opóźnień ze zwykłym ruchem aplikacyjnym i warunkami operacyjnymi.
Pierwszym sygnałem jest niezależna replikacja względem bazowej konfiguracji zbliżonej do produkcyjnej. Mocne uzupełnienie zachowałoby istniejące zachowanie lokalnego cache i pokazało, kiedy zdalne pobieranie dodaje przyrostową korzyść.
Takie dowody wzmocniłyby argument za dwukierunkowym transferem KV w vLLM jako praktycznym dodatkiem do istniejących systemów obsługi. Znacznie mniejsza poprawa zawęziłaby jego najlepsze przypadki użycia, nie podważając pierwotnego wyniku dotyczącego braku trafienia w cache.
Replikacja powinna również czynić porównanie zrozumiałym. Czytelnicy muszą wiedzieć, co pozostało stałe, co się zmieniło i które żądania skorzystały. Pojedynczy mnożnik z nagłówka nie może wyjaśnić tych różnic.
Drugim sygnałem jest wydajność przy zróżnicowanym czasie rozmów i obciążeniu. Użyteczne raporty obejmowałyby zarówno kontynuowane sesje, jak i rozmowy wstrzymywane przed wznowieniem. Łączyłyby zachowanie opóźnień z utrzymywaną pamięcią i dostępną pojemnością obsługi.
Wyniki zachowujące responsywność w tych warunkach wspierałyby większą pewność co do szerszego wdrożenia. Wyniki wymagające wyjątkowo korzystnego czasu wskazywałyby na bardziej selektywne zastosowanie.
Ma to znaczenie, ponieważ harmonogram zadań agenta jest często ustalany poza serwerem modelu. Optymalizacja obsługi musi pasować do tego harmonogramu, a nie zakładać, że aplikacja zawsze będzie współpracować.
Trzecim sygnałem są wyraźniejsze dowody integracji wokół routingu i metadanych. Operatorzy powinni zwracać uwagę na odtwarzalne konfiguracje, które pokazują rzeczywiste zdalne ponowne wykorzystanie, wraz ze zrozumiałym zachowaniem wtedy, gdy nie może ono wystąpić.
Zmniejszyłoby to niepewność między włączeniem funkcji a uzyskaniem jej korzyści. Z kolei powtarzające się błędy integracji zwiększyłyby nakład operacyjny potrzebny do uzasadnienia wdrożenia.
Sygnały te oferują także lepszy sposób porównywania alternatyw. NVIDIA Dynamo i inne układy obsługi powinny zostać poddane temu samemu obciążeniu aplikacyjnemu i tym samym miarom wyników. Oddzielne deklaracje benchmarkowe nie mogą samodzielnie wskazać zwycięzcy.
Dla deweloperów natychmiastowa szansa ma domyślnie charakter badawczy, a nie architektoniczny. Ustal, gdzie kolejne żądania spędzają czas, zanim zdecydujesz się na bardziej złożone wdrożenie.
Dla nabywców korporacyjnych pytanie brzmi, czy zademonstrowana poprawa utrzymuje się w zadaniu przypominającym własne. Uwzględnij późniejsze tury, korekty, oczekiwanie na narzędzia i wznowioną pracę. Krótka początkowa wymiana nie odpowiada na kluczowe pytanie o ponowne wykorzystanie.
Dla zespołów produktowych istotne jest zachowanie rozróżnienia między responsywnością a użytecznością. Wcześniejsze rozpoczęcie odpowiedzi jest wartościowe, gdy odpowiedź pozostaje poprawna, a zadanie nadal kończy się niezawodnie. Metryka obsługi powinna występować obok tych wyników.
Zacznij od reprezentatywnej sesji agenta i zmierz, na co poświęcany jest jej czas. Przed wyborem optymalizacji oddziel przetwarzanie danych wejściowych, generowanie odpowiedzi, oczekiwanie na narzędzia i pracę aplikacji. Następnie porównaj zdalne ponowne wykorzystanie z zachowaniem cache obecnym już w Twoim wdrożeniu. Wymagaj dowodu, że użyteczne obliczenia przetrwają między turami i dotrą do workera, który ich potrzebuje. Śledź opóźnienie ukończonych zadań obok opóźnienia pierwszego tokenu i analizuj wykorzystanie pamięci przy tym samym obciążeniu. Dwukierunkowy transfer KV w vLLM oferuje konkretny sposób odzyskiwania powtarzanej pracy, lecz jego wartość zależy od tego, jak często praca ta daje się odzyskać. Wykorzystaj opublikowany benchmark jako możliwy do przetestowania trop, a następnie oceń funkcję względem rozmów, które faktycznie obsługuje Twoja aplikacja.
