Routing uwzględniający prefiksy w Amazon SageMaker skraca opóźnienia, ale kluczowy jest powtarzalny kontekst
Routing uwzględniający prefiksy w Amazon SageMaker skrócił w testach AWS medianę czasu do pierwszego tokena nawet o 77%, zmieniając sposób kierowania powtarzających się promptów. Zamiast rozdzielać każde żądanie bez względu na jego treść, SageMaker może teraz utrzymywać żądania o zgodnych początkach na tej samej instancji modelu. Dzięki temu wcześniej obliczony kontekst z większym prawdopodobieństwem pozostaje dostępny.
Wynik ten podważa podstawowe założenie dotyczące skalowania endpointów dużych modeli językowych. Dodawanie instancji nie zapewnia automatycznie wydajnej inferencji, gdy zwykłe równoważenie obciążenia oddziela żądania od użytecznych danych w pamięci podręcznej. Flota może dysponować dużą mocą akceleratorów, a mimo to wielokrotnie przetwarzać te same instrukcje, dokumenty lub historię rozmów.
AWS pozycjonuje więc routing jako część stosu optymalizacji inferencji, obok silników modeli, akceleratorów i oprogramowania do buforowania. Bezpośrednim przeciwnikiem jest równoważenie obciążenia nieświadome pamięci podręcznej, które rozkłada pracę równomiernie, ale ignoruje to, co każda instancja już wie. AWS informuje o znaczących korzyściach, choć jego najlepsze wyniki pochodzą z kontrolowanego benchmarku z długim kontekstem, a nie z niezależnych testów produkcyjnych.
Routing uwzględniający prefiksy w Amazon SageMaker zmienia domyślny kompromis
AWS przeniosło lokalność promptów z obejścia na poziomie aplikacji do warstwy routingu zarządzanych endpointów.
AWS ogłosiło tę funkcję 10 września 2026 r. dla endpointów inferencji czasu rzeczywistego Amazon SageMaker. Nowa strategia analizuje początek przychodzącego żądania i konsekwentnie kieruje zgodne początki do tej samej instancji.
Podstawowa idea jest prosta. Wiele żądań do LLM zawiera dużą stałą sekcję, po której następuje znacznie mniejsza sekcja zmienna. Asystent obsługi klienta może otrzymywać ten sam dokument dotyczący polityki firmy i instrukcje operacyjne przed każdym nowym pytaniem klienta.
Aplikacja wykorzystująca generowanie wspomagane wyszukiwaniem często działa według tego samego wzorca. Umieszcza pobrany dokument przed zapytaniem użytkownika, dlatego kilka pytań dotyczących tego dokumentu zaczyna się od identycznego tekstu. Asystenci programistyczni również ponownie wysyłają pliki, importy, instrukcje i niedawny kontekst edycji.
Serwery modeli mają już mechanizm pozwalający wykorzystać tę powtarzalność. Pamięć podręczna klucz-wartość, powszechnie nazywana pamięcią podręczną KV, przechowuje stany uwagi obliczone podczas przetwarzania wcześniejszych tokenów przez model. Buforowanie prefiksów zachowuje stany możliwe do ponownego użycia między powiązanymi żądaniami o zgodnych początkach promptów.
Problem pojawia się, gdy endpoint rozrasta się na wiele instancji. Losowy routing może kierować kolejne żądania z tym samym prefiksem do różnych maszyn. Każda z nich ponownie przetwarza wtedy wspólny kontekst, ponieważ użyteczny wpis w pamięci podręcznej znajduje się gdzie indziej.
Routing uwzględniający prefiksy w Amazon SageMaker próbuje zachować tę lokalność. Dziesięć żądań współdzielących prefiks powinno zazwyczaj trafić do tej samej maszyny, umożliwiając jej serwerowi modelu ponowne wykorzystanie obliczeń z pamięci podręcznej. Żądania z innymi prefiksami nadal mogą być rozdzielane po całej flocie.
Funkcja nie zastępuje buforowania prefiksów wewnątrz silnika obsługującego model. Kontener nadal musi uruchamiać oprogramowanie zdolne do zachowywania i ponownego wykorzystywania stanów KV. AWS testowało tę strategię z vLLM i twierdzi, że najnowsze wersje vLLM domyślnie włączają buforowanie prefiksów.
Wprowadzenie tej funkcji dodaje trzeci wybór routingu do endpointów czasu rzeczywistego SageMaker. Losowy routing pozostaje domyślny i rozdziela ruch bez uwzględniania powiązań między żądaniami. Routing według najmniejszej liczby oczekujących żądań preferuje instancję z największą dostępną mocą przetwarzania.
Routing uwzględniający prefiksy stawia na inny kompromis. Akceptuje pewne powiązanie między treścią a instancjami, ponieważ zaoszczędzone obliczenia promptów mogą przewyższać wartość idealnie wymiennego ruchu.
AWS dodało ochronę przed przeciążeniem, aby ograniczyć to ryzyko. Gdy preferowana instancja osiągnie skonfigurowany próg współbieżności, SageMaker wysyła żądanie do mniej zajętej instancji. Takie żądanie może utracić trafienie w pamięci podręcznej, ale powinno uniknąć dołączenia do przeciążonej kolejki.
Usługa ma również zachowywać większość przypisania żądań podczas skalowania floty. Według AWS dodanie lub usunięcie instancji przesuwa tylko część ruchu. Takie zachowanie ogranicza zakłócenia w pamięci podręcznej, które spowodowałoby całkowite ponowne rozdzielenie.
Oficjalna konfiguracja routingu potwierdza zachowanie przy przeciążeniu. Wymienia ona strategie losową, według najmniejszej liczby oczekujących żądań oraz uwzględniającą prefiksy jako obsługiwane opcje.
To więcej niż wygodne ustawienie, ponieważ zmienia ono odpowiedzialność za trwały problem systemowy. Zespoły wcześniej musiały tworzyć przywiązanie sesji, wdrażać wyspecjalizowane routery albo akceptować niższe wykorzystanie pamięci podręcznej. SageMaker oferuje teraz wrażliwe na treść przypisywanie żądań w swojej warstwie zarządzanych endpointów.
To rozróżnienie oddziela tę funkcję również od routingu modeli. Nie wybiera ona spośród różnych modeli podstawowych na podstawie ceny, jakości ani typu zadania. Wybiera, która instancja tego samego wdrożonego obciążenia powinna otrzymać żądanie.
Ten węższy zakres jest istotny. AWS nie twierdzi, że jeden przełącznik optymalizuje każdy element obsługi LLM. Rozwiązuje problem powtarzalnej pracy wstępnego przetwarzania, która staje się szczególnie kosztowna, gdy aplikacje dołączają długi, powracający kontekst do każdego żądania.
Wynik 77% opóźnienia wynika z długich wspólnych promptów
AWS odnotowało największą poprawę, gdy każde żądanie ponownie wykorzystywało prefiks liczący 8 000 tokenów, co czyniło benchmark korzystnym dla lokalności pamięci podręcznej.
Firma porównała routing uwzględniający prefiksy z domyślną losową strategią SageMaker. W teście użyto Llama 3.1 70B Instruct, siedmiu instancji ml.p5.48xlarge oraz vLLM z włączonym buforowaniem prefiksów.
AWS uruchomiło 16 konfiguracji obejmujących endpointy pojedynczego modelu, endpointy komponentów inferencyjnych, natywne API Invoke oraz API zgodne z OpenAI. Firma poinformowała, że każdy test zakończył się powodzeniem.
Najlepsze wyniki uzyskano dla obciążeń z długim kontekstem utrzymywanych przez godzinę. Każde żądanie współdzieliło prefiks o długości 8 000 tokenów, tworząc duży blok powtarzalnych obliczeń, które pamięć podręczna mogła wyeliminować.
W tych warunkach AWS podaje, że P50 czasu do pierwszego tokena spadło od 71% do 77%. P50 to wynik medianowy, co oznacza, że połowa mierzonych żądań odpowiedziała szybciej, a połowa wolniej.
P90 czasu do pierwszego tokena spadło od 33% do 37%. Ten percentyl reprezentuje wolniejszą część rozkładu żądań, dlatego często ma większe znaczenie dla celów dotyczących poziomu usług. Mniejsza poprawa P90 sugeruje, że routing nie może wyeliminować każdego źródła opóźnień końcowych.
AWS poinformowało, że współczynniki trafień pamięci podręcznej KV wzrosły z około 25% do nawet 82%. Przepustowość wzrosła od 15% do 16%, co pokazuje, że pominięta praca wstępnego przetwarzania uwolniła również moc obliczeniową.
Liczby te tworzą główny argument za routingiem uwzględniającym prefiksy w Amazon SageMaker. Zysk medianowego opóźnienia jest uderzający, ale zmiana współczynnika trafień w pamięci podręcznej wyjaśnia, dlaczego do niego doszło. Router częściej umożliwiał dostęp do istniejących obliczeń zapisanych w pamięci podręcznej.
Wyniki były skromniejsze w przypadku krótszych rozmów w stylu ShareGPT o zmiennej długości. W 30-minutowych testach mediana czasu do pierwszego tokena poprawiła się od 13% do 16%. Przepustowość wzrosła jedynie o 1,7% do 2%.
Opóźnienie P90 nadal poprawiło się od 24% do 37% w tych krótszych testach. Według AWS współczynniki trafień pamięci podręcznej wzrosły z około 30% do 80%. Jednak każde udane trafienie pomijało mniej pracy, ponieważ prefiksy możliwe do ponownego wykorzystania były krótsze.
Ten kontrast jest najważniejszym szczegółem w benchmarku AWS. Przypisywanie żądań z uwzględnieniem prefiksów nie jest stałym mnożnikiem dla każdej aplikacji LLM. Jego wartość zależy od tego, jak duża część kontekstu się powtarza i jak kosztowne jest jej przetworzenie.
Raportowany narzut routingu wynosił od 1,3 do 1,9 milisekundy na żądanie. AWS zmierzyło czas modelu do pierwszego tokena od 63 do 280 milisekund podczas testów. W tym zakresie obliczenie routingu stanowiło relatywnie niewielką część czasu odpowiedzi.
Ruch pozostał również zrównoważony w testowanych scenariuszach. Każda z siedmiu instancji otrzymała od 13,3% do 15,4% żądań. Idealny podział przypisałby każdej instancji około 14,3%.
Wynik ten odpowiada na najbardziej oczywisty zarzut wobec przywiązania do prefiksu. Utrzymywanie zgodnych żądań razem może tworzyć gorące punkty, jeśli jeden prefiks stanie się nieproporcjonalnie popularny. AWS twierdzi, że próg przeciążenia zapobiegł temu problemowi w benchmarku.
Mimo to liczby wymagają ostrożnego ujęcia. AWS przygotowało i opublikowało testy, a żadna niezależna organizacja nie zweryfikowała raportowanych korzyści. Firma nie przedstawiła również szerokiego zbioru śladów produkcyjnych od niepowiązanych klientów.
Test z długim kontekstem celowo tworzy znaczące możliwości ponownego użycia. Jest to właściwe do pomiaru zamierzonego efektu funkcji, ale nie reprezentuje każdego endpointu. Usługa przetwarzająca niepowiązane, krótkie prompty oferowałaby znacznie mniej pracy możliwej do ponownego wykorzystania.
Benchmark porównuje również nową strategię z losowym routingiem. Zespoły używające już własnego routera świadomego pamięci podręcznej, przywiązania sesji lub rozproszonej pamięci podręcznej KV mogą uzyskać mniejszą dodatkową korzyść. Ich właściwym punktem odniesienia nie musi być domyślne ustawienie SageMaker.
Najbardziej jednoznaczny wniosek jest zatem warunkowy. Funkcja może znacząco skrócić opóźnienia, gdy żądania współdzielą długie prefiksy, a silnik obsługujący zachowuje ich stany KV. Nie składa takiej samej obietnicy dla zróżnicowanego ruchu odpornego na buforowanie.
Ten warunkowy wynik odzwierciedla szersze badania nad buforowaniem prefiksów. Artykuł z NeurIPS z 2025 r. wykazał, że inteligentniejsze zachowywanie pamięci podręcznej poprawiało wydajność, ale udokumentował również ograniczoną pojemność pamięci podręcznej i problemy z usuwaniem wpisów.
Routing rozwiązuje jedną część tego systemu. Zwiększa prawdopodobieństwo, że żądanie trafi do instancji zawierającej odpowiedni stan. Nie może zagwarantować, że stan pozostanie w pamięci w chwili nadejścia żądania.
Routing świadomy pamięci podręcznej wywiera presję na zwykłe load balancery
Wprowadzenie tej funkcji ujawnia niedopasowanie między konwencjonalnym równoważeniem żądań a stanowym charakterem współczesnej inferencji LLM.
Tradycyjne usługi internetowe często traktują wymienne repliki jako pożądaną cechę projektu. Load balancer może wysyłać każde żądanie do dowolnego sprawnego serwera, wykorzystując losowość lub głębokość kolejki do rozdzielania pracy. Aplikacja powinna dawać ten sam wynik niezależnie od przypisania.
Repliki LLM mogą generować równoważne odpowiedzi, mając jednocześnie bardzo różne koszty przygotowania. Jeden GPU może już przechowywać stany uwagi dla długiej umowy, pliku kodu lub rozmowy. Inny GPU może potrzebować odtworzyć te stany przed wygenerowaniem pierwszego tokena.
Routing nieświadomy pamięci podręcznej ignoruje tę różnicę. Może wybrać najmniej zapełnioną kolejkę, lecz nadal wskazać maszynę z największą ilością powielonej pracy wstępnego przetwarzania. Lokalnie bardziej zajęta maszyna może odpowiedzieć szybciej, ponieważ zawiera już zgodny prefiks.
To napięcie nie jest unikalne dla AWS. Systemy inferencji open source również traktują planowanie żądań i lokalizację pamięci podręcznej jako powiązane problemy. Ruch ten obejmuje stosy oparte na vLLM, wyspecjalizowane bramy Kubernetes, rozproszone pamięci podręczne oraz architektury prefill-decode.
AWS omawiało bardziej rozbudowaną wersję w ramach SageMaker HyperPod. Jego inteligentny routing obsługuje strategie uwzględniające prefiksy, świadome KV i round-robin wraz z warstwowym buforowaniem.
Projekt HyperPod może śledzić buforowane prefiksy i rozszerzać pamięć masową poza pamięć GPU. Wykorzystuje lokalną pamięć CPU jako jedną warstwę cache’u i może zapewniać rozproszoną drugą warstwę. Takie podejście obsługuje większą infrastrukturę zarządzaną przez Kubernetes, zapewniając głębszą kontrolę operacyjną.
Nowa funkcja endpointów czasu rzeczywistego ma prostszą rolę. Utrzymuje żądania blisko prawdopodobnych lokalizacji cache’u, bez wymagania od użytkowników obsługi klastra inferencyjnego ani rozproszonego cache’u. Dzięki temu technika staje się dostępna dla zespołów korzystających ze standardowych zarządzanych endpointów.
Środowisko zarządzane wywiera również presję na projekty niestandardowego routingu w konkretny sposób. AWS niekoniecznie udostępnia każdy sygnał rozmieszczenia ani każdą politykę zarządzania cache’em obsługiwaną przez te projekty. Zmniejsza natomiast wysiłek potrzebny do uzyskania istotnej części korzyści.
Dla zespołów platformowych może to zmienić kalkulację między tworzeniem własnego rozwiązania a zakupem gotowego. Niestandardowy router wymaga wdrożenia, aktualizacji, telemetrii, obsługi awarii i koordynacji z autoskalowaniem. Konfigurację wariantu produkcyjnego łatwiej wdrożyć, gdy jej ograniczenia odpowiadają obciążeniu.
Presja konkurencyjna obejmuje również innych dostawców zarządzanej inferencji. Klienci mogą coraz częściej oceniać platformę LLM według tego, jak dobrze koordynuje routing, cache’owanie i skalowanie, a nie wyłącznie według dostępnych modeli czy typów akceleratorów.
Ma to znaczenie, ponieważ efektywność inferencji coraz bardziej zależy od całej ścieżki obsługi. Kwantyzacja modelu może zmniejszyć użycie pamięci. Ciągłe batchowanie może łączyć aktywne żądania. Dekodowanie spekulatywne może przyspieszać generowanie tokenów w odpowiednich warunkach.
Rozmieszczenie uwzględniające cache eliminuje inne źródło marnotrawstwa. Pozwala uniknąć ponownego przetwarzania promptów, które system już obsłużył. Metody te mogą współistnieć, dlatego dostawcy infrastruktury mają motywację, by pakować je jako zintegrowany stos.
Prace AWS nad rozproszoną inferencją ilustrują ten kierunek. Architektura oddziela wymagające obliczeniowo wstępne wypełnianie od wymagającego przepustowości pamięci dekodowania i koordynuje transfery KV między workerami.
Ten bardziej zaawansowany projekt traktuje inferencję jako problem systemów rozproszonych. Decyzje routingu uwzględniają presję kolejek, lokalizację cache’u i wyspecjalizowane role workerów. Ogólny sieciowy load balancer nie dysponuje takimi sygnałami na poziomie aplikacji.
Zwykły routing nadal ma jednak uzasadnione zastosowania. Losowe rozmieszczenie pozostaje odpowiednie, gdy żądania są niezależne lub gdy model nie ma skutecznego cache’u prefiksów. Podejście least-outstanding-requests może pomagać, gdy czasy przetwarzania są zróżnicowane, a współdzielony kontekst oferuje niewielką lokalność.
Routing uwzględniający prefiksy nie jest zatem uniwersalnym zamiennikiem. To strategia specyficzna dla danego obciążenia, która przedkłada kontekst możliwy do ponownego wykorzystania nad idealnie równy rozkład żądań. Mechanizm kontroli przeciążenia AWS próbuje równoważyć oba cele.
Funkcja powinna zainteresować zespoły budujące asystentów dokumentowych i wewnętrzne systemy wyszukiwania. Takie aplikacje wielokrotnie przedstawiają te same podręczniki, polityki, specyfikacje lub zapisy projektowe, zanim zmienią pytanie.
Zespoły budujące przeszukiwalną bazę wiedzy powinny rozpoznać ten wzorzec. Jakość wyszukiwania określa, jaki kontekst trafia do promptu, podczas gdy routing wpływa na to, czy przetwarzanie tego kontekstu może zostać ponownie wykorzystane.
Agenci wieloturowi to kolejny silny kandydat. Każda nowa tura często zawiera wcześniejsze wiadomości, instrukcje narzędzi i zgromadzony stan zadania. Ten rosnący wspólny początek sprawia, że faza prefill staje się droższa, jednocześnie tworząc okazję do ponownego użycia cache’u.
Asystenci programistyczni również wykazują wyraźną lokalność. Kilka żądań może współdzielić instrukcje repozytorium, otwarty plik, pobliskie symbole i historię rozmowy. Końcowe żądanie uzupełnienia się zmienia, lecz znaczna część poprzedzającego go kontekstu pozostaje stabilna.
Te wzorce wyjaśniają, dlaczego routing stał się teraz funkcją konkurencyjną. Dłuższe okna kontekstowe zachęciły aplikacje do wysyłania większej ilości materiałów referencyjnych przy każdym wywołaniu. Przepływy pracy agentów również powtarzają istotne instrukcje i historie w wielu krokach.
Nowym wąskim gardłem nie jest wyłącznie liczba generowanych tokenów. Jest nim wielokrotne przygotowywanie dużych, znanych danych wejściowych przed rozpoczęciem generowania. To sprawia, że czas do pierwszego tokenu staje się odrębną kwestią produktową względem szybkości generowania tokenów.
Czego benchmark nie gwarantuje
Routing uwzględniający prefiksy zwiększa szanse na ponowne użycie cache’u, ale serializacja, eksmisja, izolacja tenantów i nierównomierny rozkład ruchu mogą zniwelować oczekiwaną przewagę.
Pierwszą niewiadomą jest dopasowanie do obciążenia. Endpoint obsługujący niepowiązane prompty może generować niewiele użytecznych dopasowań prefiksów. W takim środowisku router dodaje niewielki koszt decyzyjny, nie pomijając przy tym dużej części obliczeń modelu.
Nawet powierzchownie podobne prompty mogą nie zostać dopasowane. Natywne API Invoke SageMaker opiera prefiks routingu na bajtach z treści żądania. Różnice w białych znakach JSON, kolejności pól lub formatowaniu mogą zmienić te bajty.
Aplikacje muszą zatem konsekwentnie serializować żądania. Stabilny prompt systemowy nie wystarczy, jeśli biblioteki klienckie pakują go inaczej. Zespoły korzystające z kilku usług lub języków programowania powinny sprawdzić, czy równoważne żądania tworzą identyczne dane wejściowe routingu.
API zgodne z OpenAI wykorzystuje natomiast znaki wyodrębnione z tekstu wiadomości. Eliminuje to część wrażliwości na surowy JSON, choć zmiany w sekwencji wiadomości nadal wpływają na prefiks. Dynamiczne metadane umieszczone na początku promptu mogą rozpraszać powiązane żądania.
Długość prefiksu tworzy kolejny problem strojenia. SageMaker akceptuje skonfigurowany zakres od 1 024 do 65 536. W przypadku natywnego API wartość ta oznacza bajty; w przypadku API zgodnego z OpenAI oznacza znaki.
Krótki wybór może grupować zbyt wiele żądań wokół ogólnego początku. Zwiększa to prawdopodobieństwo kierowania nadmiernego ruchu do jednej instancji. Próg współbieżności uruchamia wtedy przepełnienie, poświęcając powinowactwo cache’u w celu zachowania pojemności.
Długi wybór tworzy odwrotny problem. Niewielkie różnice występujące w wybranym regionie mogą rozdzielić żądania, które w innym przypadku współdzielą kosztowny kontekst. Flota pozostaje zrównoważona, ale poprawa wskaźnika trafień cache’u maleje.
Właściwa wartość zależy od rzeczywistej struktury promptów. Zespoły muszą wiedzieć, gdzie kończą się wspólne instrukcje, a zaczyna unikalny materiał. Potrzebują też wystarczającej ilości treści różnicującej, aby powszechnie używany szablon nie stał się jednym koszykiem routingu.
Eksmisja cache’u pozostaje poza bezpośrednią kontrolą routera. Pamięć GPU jest ograniczona, a serwery modeli muszą odzyskiwać bloki KV w miarę napływu nowych żądań. Żądanie może trafić do oczekiwanej instancji, gdy odpowiedni wpis już zniknął.
Przytoczone wcześniej badanie cache’u prefiksów wykazało, że polityka eksmisji istotnie wpływa na współczynniki trafień. Sugeruje to, że rozmieszczenie i retencję należy oceniać łącznie.
Autoskalowanie tworzy kolejne źródło zmian w cache’u. AWS twierdzi, że większość ruchu pozostaje przypisana podczas zmian floty, lecz nowe instancje zaczynają bez użytecznych lokalnych prefiksów. Zdarzenia skalowania w górę mogą tymczasowo obniżyć wskaźniki trafień, dopóki popularne konteksty nie rozgrzeją tych maszyn.
Zdarzenia skalowania w dół mogą usuwać maszyny przechowujące wartościowe wpisy. Stabilne ponowne mapowanie ogranicza zakłócenia, ale nie może zachować zawartości cache’u na instancji, która znika. Nagłe zmiany ruchu mogą zatem osłabić wynik benchmarku w stanie ustalonym.
Popularne prefiksy tworzą również fundamentalny konflikt. Utrzymywanie każdego pasującego żądania na jednej maszynie maksymalizuje lokalność, dopóki maszyna nie zostanie nasycona. Rozproszenie ruchu chroni opóźnienia pod obciążeniem, ale powiela obliczenia buforowane na większej liczbie instancji.
ConcurrencyThreshold SageMaker bezpośrednio ujawnia ten kompromis. Dopuszczalna wartość mieści się w zakresie od 1 do 1 024 żądań w trakcie realizacji. Zachowawczy próg sprzyja rozkładowi obciążenia, podczas gdy wyższe ustawienie dłużej chroni powinowactwo.
Nie ma jednego właściwego progu dla każdego modelu. Duże prompty, długie odpowiedzi, ustawienia kwantyzacji, równoległość tensorowa i zachowanie batchowania wpływają na bezpieczną współbieżność. Operatorzy muszą dostroić wartość do własnych celów poziomu usług.
Separacja tenantów wymaga podobnej uwagi. Dwie organizacje mogą używać identycznych instrukcji systemowych, jednocześnie wymagając niezależnej obsługi operacyjnej. SageMaker obsługuje opcjonalny identyfikator uwzględniający prefiksy, aby rozdzielać ich grupy routingu.
Użytkownicy natywnego API mogą podać X-Amzn-SageMaker-Prefix-Aware-Id, maksymalnie 64 znaki ASCII. Żądania zgodne z OpenAI mogą używać pola prompt_cache_key. AWS łączy identyfikator z prefiksem podczas wyboru instancji.
Funkcja zapewnia izolację routingu, jednak ogłoszenia AWS nie należy odczytywać jako szerokiego twierdzenia o izolacji danych w ramach każdego frameworka obsługującego. Zespoły nadal muszą ocenić zachowanie kontenerów, zarządzanie pamięcią, logowanie i pełny model bezpieczeństwa.
Funkcja wymaga również co najmniej dwóch instancji, aby zapewnić istotną różnicę w routingu. Przy jednej instancji każde żądanie i tak trafia w to samo miejsce. Małe wdrożenia nie zyskują więc niczego na samym powinowactwie rozmieszczenia.
AWS twierdzi, że na warstwie routingu endpointu nie są wymagane zmiany kontenera modelu. Framework obsługi nadal jednak potrzebuje działającego cache’owania prefiksów. Niezgodny lub nieprawidłowo skonfigurowany silnik otrzyma zlokalizowany ruch bez ponownego wykorzystania bazowych obliczeń.
Połączenie Llama 3.1 70B i vLLM w benchmarku weryfikuje jedną ważną konfigurację. Nie potwierdza identycznej poprawy dla każdej architektury, środowiska uruchomieniowego, metody kwantyzacji, konfiguracji adapterów ani rozkładu promptów.
Dynamiczne adaptery Low-Rank Adaptation dodają kolejną warstwę rozmieszczenia. AWS twierdzi, że wybór uwzględniający prefiksy działa wśród instancji, które już przechowują żądany adapter. Ten węższy zbiór kwalifikujących się instancji może ograniczać możliwości równoważenia routera.
Wreszcie, najbardziej widoczny wskaźnik nie opisuje całego doświadczenia użytkownika. Czas do pierwszego tokenu wpływa na postrzeganą responsywność, szczególnie w produktach interaktywnych. Nie opisuje bezpośrednio jakości odpowiedzi, całkowitego czasu generowania ani niezawodności ukończenia.
Poprawa przepustowości była również znacznie mniejsza niż wzrost mediany opóźnień. Przepustowość dla długiego kontekstu wzrosła maksymalnie o 16%, podczas gdy dla krótkiego kontekstu nie wzrosła o więcej niż 2% w testach AWS. Planowanie pojemności powinno opierać się na odpowiednim wskaźniku, a nie wyłącznie na nagłówkowym opóźnieniu.
Z tych powodów wartość 77% należy traktować jako górny wynik benchmarku AWS. Stanowi dowód, że lokalność może mieć duże znaczenie, a nie gwarancję wydajności dla każdego endpointu SageMaker.
Trzy sygnały pokażą, czy korzyści utrzymają się w produkcji
Kolejnym testem będzie to, czy klienci zdołają odtworzyć wzrosty trafień cache’u AWS bez tworzenia niestabilnych gorących punktów lub wykonywania rozległych prac nad inżynierią promptów.
Pierwszym sygnałem jest telemetria cache’u w produkcji. Zespoły powinny porównać routing losowy i uwzględniający prefiksy, używając tego samego śladu ruchu, rozmiaru floty, silnika obsługi i polityki autoskalowania. Sama mediana opóźnień nie wyjaśni wyniku.
Współczynnik trafień cache’u KV powinien rosnąć wraz z niższym opóźnieniem prefill. Operatorzy powinni również śledzić P90 i P99 czasu do pierwszego tokenu, głębokość kolejki, częstotliwość przepełnień oraz rozkład ruchu na poziomie instancji.
Jeśli trafienia cache’u poprawią się, a opóźnienia krańcowe pozostaną stabilne, główny argument AWS stanie się silniejszy. Jeśli mediana opóźnienia spadnie, ale przepełnienia lub opóźnienia P99 wzrosną, korzyść będzie wymagać węższych kryteriów wdrożenia.
Porównanie powinno obejmować zimne starty i okresy skalowania. Godzinny benchmark stanu ustalonego może ukryć koszt rozgrzewania, który pojawia się po wdrożeniach, wymianie instancji lub nagłym skalowaniu w górę. Rzeczywiste usługi regularnie doświadczają takich przejść.
Drugim sygnałem są szersze dane dotyczące środowisk uruchomieniowych i modeli. AWS przetestowało duży otwarty model z vLLM, ale klienci korzystają z różnorodnych architektur i kontenerów. Wyniki dla mniejszych modeli, modeli mixture of experts, modeli skwantyzowanych i obciążeń z długimi odpowiedziami wyjaśnią zakres zastosowania tej funkcji.
Obciążenia z krótkim kontekstem zasługują na szczególną uwagę, ponieważ AWS już odnotowało dla nich mniejsze wzrosty przepustowości. Jeśli niezależne testy potwierdzą jedynie umiarkowaną poprawę, routing uwzględniający prefiksy pozostanie wartościowy głównie dla aplikacji intensywnie wykorzystujących dokumenty i aplikacji agentowych.
Jeśli porównywalne korzyści pojawią się dla różnych modeli i wzorców promptów, lokalność routingu będzie wyglądać na standardowy wymóg zarządzanego wnioskowania. Inni dostawcy znajdą się pod presją, by udostępnić podobną konfigurację i obserwowalność.
Trzecim sygnałem jest przejście od heurystycznego powinowactwa prefiksów w kierunku routingu opartego na jawnym stanie cache. Podobieństwo prefiksów szacuje, gdzie powinien znajdować się użyteczny stan. Systemy świadome KV mogą śledzić rzeczywiste bloki, zdarzenia eksmisji lub transfery w całej flocie.
AWS już oferuje bardziej zaawansowane opcje świadome cache za pośrednictwem SageMaker HyperPod. Jego endpointy czasu rzeczywistego mogą z czasem udostępnić bogatsze sygnały cache, obsługę rozproszonego cache lub bardziej adaptacyjne polityki. Konkurenci i projekty open source podążają w podobnych kierunkach.
Jeśli zarządzane endpointy zyskają dokładną świadomość stanu cache, obecne wydanie będzie wyglądać jak dostępna pierwsza warstwa większej transformacji. Jeśli złożoność sprawi, że te funkcje pozostaną ograniczone do wyspecjalizowanych klastrów, routing uwzględniający prefiksy może pozostać praktycznym rozwiązaniem pośrednim.
Dla deweloperów natychmiastowym działaniem powinny być pomiary, a nie migracja oparta na założeniach. Zidentyfikuj powtarzające się sekcje promptów, ujednolić serializację, włącz cache prefiksów na poziomie silnika i przetestuj kilka długości prefiksów. Porównuj rozkłady opóźnień, a nie tylko średnie.
Nabywcy korporacyjni powinni pytać dostawców, gdzie znajduje się inteligencja routingu i jakie wskaźniki udostępniają. Platforma reklamująca cache prefiksów bez zachowania lokalności między replikami może zapewniać rozczarowujące współczynniki trafień przy dużej skali.
Pracownicy wiedzy odczują ten efekt pośrednio. Asystenci dokumentowi, narzędzia do programowania i długo działający agenci powinni zaczynać odpowiadać szybciej, gdy wielokrotnie korzystają z tego samego kontekstu. Zysk powinien być widoczny przed pierwszym wygenerowanym tokenem, niekoniecznie przez cały czas trwania odpowiedzi.
Routing uwzględniający prefiksy w Amazon SageMaker stanowi wiarygodny argument, że równoważenie obciążenia musi rozumieć kontekst LLM, który można ponownie wykorzystać. Wyniki AWS pokazują, jak kosztowne może stać się rozmieszczanie nieuwzględniające cache przy współdzielonym prefiksie o długości 8 000 tokenów.
Otwarte pozostaje pytanie, jak często rzeczywisty ruch odpowiada temu korzystnemu wzorcowi. Zespoły powinny przetestować własne ślady ruchu, w tym zdarzenia skalowania i intensywnie używane prefiksy, zanim potraktują główną podawaną liczbę jako prognozę operacyjną.
Monitoruj współczynnik trafień cache, najwolniejsze żądania oraz częstotliwość routingu przepełnieniowego. Łącznie te miary pokażą, czy SageMaker zachowuje użyteczny kontekst, czy jedynie przestawia ruch.
