Obsługa mniejszych modeli Cloudflare zmniejsza zużycie pamięci, lecz kluczowe staje się bezpieczeństwo
Obsługa mniejszych modeli Cloudflare pozwala teraz zmieścić w pamięci GPU dwukrotnie więcej kontekstu Kimi, choć przy typowej współbieżności wiąże się z nieco wolniejszym przetwarzaniem. Firma kompresuje też wagi GLM i sprawdza współdzielone strony pamięci podręcznej, zanim obsługiwane operacje dekodowania je odczytają. Łącznie te zmiany przekształcają pamięć GPU ze sztywnego ograniczenia w zasób, którym Cloudflare może aktywnie zarządzać.
Ma to znaczenie, ponieważ modele Kimi od Moonshot AI i modele GLM od Z.ai nie są zwykłymi dodatkami do katalogu wnioskowania. Łączą dużą liczbę parametrów, długie okna kontekstowe i architektury mixture-of-experts. Model mixture-of-experts aktywuje wybrane części swojej sieci dla każdego tokenu, ograniczając obliczenia bez zmniejszania rozmiaru przechowywanych wag.
Nie chodzi tu po prostu o konflikt Cloudflare z innym dostawcą wnioskowania. Stawką jest gęste wykorzystanie zasobów kontra bezpieczna izolacja na współdzielonym sprzęcie. Upakowanie większej liczby żądań na jednym GPU poprawia ekonomikę i całkowitą przepustowość, ale zwiększa też konsekwencje błędnego zarządzania pamięcią podręczną.
Cloudflare twierdzi, że nowa konfiguracja zachowuje dokładność modelu, jednocześnie zwiększając pojemność. Większość danych potwierdzających pochodzi jednak z własnego zestawu ocen i infrastruktury Cloudflare. Kolejnym sprawdzianem będzie to, czy zyski pozostaną stabilne w różnych obciążeniach, generacjach sprzętu i przy znacznie większej skali produkcyjnej.
Co Cloudflare zmienił dla Kimi i GLM
Cloudflare połączył trzy techniki zarządzania pamięcią, ponieważ żadna pojedyncza optymalizacja nie rozwiązuje problemu obsługi modeli na skalę frontierową.
Firma opisała zmiany w relacji technicznej z 3 sierpnia technical account. Stosuje kwantyzację FP8 do pamięci podręcznej KV Kimi, kompresję INT4 do wag GLM oraz znaczniki integralności dla współdzielonych stron pamięci podręcznej. Każda z tych technik rozwiązuje inne ograniczenie w tym samym systemie wnioskowania.
Pamięć podręczna KV przechowuje klucze i wartości uwagi utworzone dla tokenów, które model już przetworzył. Pozwala modelowi kontynuować rozmowę bez ponownego przeliczania całego promptu przed każdym wygenerowanym tokenem. Długie prompty i równoległe żądania powodują szybki wzrost tej pamięci podręcznej.
Cloudflare przechowuje dane pamięci podręcznej Kimi K2.6 w FP8 e4m3 zamiast BF16. FP8 używa ośmiu bitów dla każdej wartości zmiennoprzecinkowej, podczas gdy BF16 używa szesnastu. Ta konwersja zmniejsza zapotrzebowanie pamięci podręcznej na pamięć o połowę.
Według Cloudflare dostępny kontekst w pamięci rośnie z około 686 000 tokenów do około 1,37 mln tokenów. Jest to łączna pojemność w testowanym wdrożeniu, a nie nowy limit okna kontekstowego dla jednego użytkownika. To rozróżnienie ma znaczenie, ponieważ optymalizacja przede wszystkim zwiększa współbieżność.
Cloudflare wprowadził odrębną zmianę dla GLM 5.2. Skompresował wagi modelu z FP8 do INT4, czyli czterobitowej reprezentacji całkowitoliczbowej. Rozmiar checkpointu miał zmniejszyć się z 705 GB do 421 GB, czyli o około 40 procent.
Wdrożenie z równoległością tensorową na ośmiu urządzeniach dzieli model między osiem GPU. W tej konfiguracji Cloudflare twierdzi, że użycie pamięci spadło z około 88 GB do 52 GB na GPU. Pozostała przestrzeń może pomieścić około 1,18 mln tokenów pamięci podręcznej KV.
Trzecia zmiana chroni współdzieloną pamięć podręczną powstałą w wyniku gęstszego upakowania. Każda fizyczna strona pamięci podręcznej otrzymuje znacznik zmieniający się przy każdym ponownym przydzieleniu strony. Serwer rejestruje strony i znaczniki oczekiwane przez każde żądanie.
Zanim obsługiwane operacje dekodowania odczytają te strony, Cloudflare sprawdza mapowania. Niezgodność powoduje zatrzymanie danego żądania. System powinien więc bezpiecznie odmawiać działania, zamiast odczytywać dane powiązane z innym żądaniem.
Techniki te działają ponad szerszą architekturą dużych modeli Cloudflare. Firma wcześniej opisała Infire inference jako silnik oparty na Ruście, zaprojektowany dla jej rozproszonej sieci GPU. Rozdziela także prefill i decode na odrębne pule zasobów.
Prefill przetwarza przychodzący prompt i tworzy jego początkowy stan pamięci podręcznej. Decode generuje odpowiedź token po tokenie. Fazy te w różny sposób obciążają GPU, co pozwala Cloudflare osobno optymalizować każdą pulę.
To rozdzielenie jest kluczowe dla nowego projektu. Cloudflare zachowuje pamięci podręczne BF16 i wagi FP8 tam, gdzie dominują obliczenia. Stosuje mniejsze reprezentacje tam, gdzie ograniczeniem staje się pojemność pamięci lub przepustowość.
Rezultatem nie jest jedna uniwersalnie skompresowana konfiguracja modelu. Jest to system obsługi świadomy faz, który zmienia formaty zależnie od obciążenia. Tworzy to większą złożoność operacyjną, ale pozwala uniknąć narzucania jednego kompromisu na całe żądanie.
Dlaczego mniejsze pamięci podręczne Cloudflare wygrywają z surową szybkością
Kwantyzacja pamięci podręcznej KV Kimi wygrywa, ponieważ dopuszcza więcej pracy, a nie dlatego, że każde żądanie staje się indywidualnie szybsze.
Cloudflare testował dekodowanie Kimi K2.6 na rozdzielonym wdrożeniu H200. Przy jednym równoległym żądaniu pamięć podręczna BF16 osiągała 137 tokenów na sekundę. Wersja FP8 osiągała 125, więc skompresowana pamięć podręczna była wolniejsza przy takim obciążeniu.
Ten wzorzec utrzymywał się wraz ze wzrostem współbieżności. Przy ośmiu żądaniach BF16 osiągało 731 tokenów na sekundę, wobec 689 dla FP8. Przy szesnastu żądaniach wyniki wyniosły odpowiednio 1 106 i 1 028 tokenów na sekundę.
BF16 osiągnęło 1 558 tokenów na sekundę przy 32 równoległych żądaniach. Następnie jednak wyczerpało dostępną pamięć. Cloudflare podaje, że pamięć podręczna FP8 kontynuowała pracę przy 64 żądaniach i osiągnęła 2 192 tokeny na sekundę.
Ta końcowa liczba jest o około 41 procent wyższa od najwyższej zmierzonej przepustowości BF16. Cloudflare raportuje też około 30 procent niższy koszt na token. Zysk wynika z wykonywania większej ilości pracy w tym samym wdrożeniu, a nie z przyspieszania każdego żądania przy niskim obciążeniu.
To rozróżnienie pozwala uniknąć łatwego, lecz mylącego nagłówka. Kwantyzacja wprowadza dodatkową pracę związaną z konwersją, gdy jądro uwagi odczytuje wartości z pamięci podręcznej. Przy tej samej współbieżności wyniki BF16 Cloudflare pozostawały o kilka punktów procentowych szybsze.
Kwantyzacja pamięci podręcznej KV Kimi staje się wartościowa dopiero wtedy, gdy limity pamięci uniemożliwiają większemu formatowi przyjęcie większej liczby żądań. Wymienia niewielką efektywność na pojedyncze żądanie na znacznie większą całkowitą pojemność. Jest to rozsądny kompromis, gdy popyt pozostaje wystarczająco wysoki, by wykorzystać dodatkową przestrzeń.
Jest mniej wartościowa, gdy ruch jest rzadki. Wdrożenie obsługujące tylko kilka jednoczesnych żądań poniosłoby koszt konwersji bez wykorzystania dodatkowej pojemności. Podejście Cloudflare zależy więc od kierowania wystarczającej liczby zgodnych zadań do każdej puli dekodowania.
W tym miejscu globalna infrastruktura staje się strategicznie istotna. Duzi dostawcy mogą agregować ruch od wielu klientów i utrzymywać kosztowne akceleratory w ciągłym użyciu. Mniejsi operatorzy często mierzą się z nieregularnym popytem, przez co nie są w stanie uzyskać takich samych korzyści z wykorzystania zasobów.
Cloudflare już wykorzystuje session affinity i prefix caching w Workers AI. Prefix caching ponownie używa obliczonego stanu identycznych początków promptów. Jego large-model rollout ujawnił wykorzystanie tokenów z pamięci podręcznej i wprowadził nagłówek session-affinity dla lepszego routingu pamięci podręcznej.
Nowsza optymalizacja dotyczy innej warstwy. Prefix caching pozwala uniknąć powtarzanej pracy prefill, podczas gdy FP8 zwiększa pojemność decode. Połączenie obu rozwiązań może ograniczyć zduplikowane obliczenia i dopuścić więcej aktywnych sekwencji.
Cloudflare porównał dokładność w kilku ewaluacjach. W GSM8K BF16 uzyskało 94,24, a FP8 94,09. Wyniki MMLU wyniosły odpowiednio 89,11 i 89,04.
Pamięć podręczna FP8 uzyskała 67,49 w ARC-Challenge, wobec 66,72 dla BF16. W MMLU-Pro FP8 osiągnęło 79,29, podczas gdy BF16 80,29. Poprawność wywołań narzędzi wyniosła 92,6 procent dla FP8 i 92,2 procent dla BF16.
Cloudflare opisuje te wyniki jako nierozróżnialne. Taki wniosek jest prawdopodobny w ramach przedstawionego zestawu, ale wyniki nie dowodzą uniwersalnej równoważności. Niewielkie różnice liczbowe mogą wpływać na rzadkie prompty, długie ślady agentowe lub zadania spoza wybranych ewaluacji.
Kilka testów generuje również niedeterministyczne wyniki. Niewielka różnica w wyniku może odzwierciedlać próbkowanie, szum ewaluacyjny lub kwantyzację. Aby rozdzielić te przyczyny, czytelnicy potrzebowaliby powtarzanych prób i przedziałów ufności.
Wewnętrzny benchmark mcxams firmy dał identyczne wyniki: obie konfiguracje zaliczyły 61 z 63 testów. Wewnętrzne ewaluacje mogą dobrze odzwierciedlać potrzeby produkcyjne, ale osoby z zewnątrz nie mogą niezależnie zbadać ich zakresu.
Kwantyzację pamięci podręcznej KV Kimi należy więc oceniać jako wynik operacyjny z zachęcającymi dowodami jakości. Nie jest to ogólny wniosek, że każdy model może bezpiecznie używać wartości pamięci podręcznej FP8. Rozkłady uwagi i wrażliwość numeryczna różnią się między architekturami.
Prawdziwym osiągnięciem Cloudflare jest określenie, gdzie zmiana formatu się opłaca. Prefill pozostaje ograniczony obliczeniami, więc firma zachowuje jego pamięć podręczną w BF16. Decode staje się ograniczony pamięcią, przez co mniejsza reprezentacja FP8 jest użyteczna przy większej współbieżności.
Ten wybór wspiera centralną tezę. Lepsze wnioskowanie nie zawsze oznacza szybsze wykonanie pojedynczego żądania. W skali często oznacza wykonanie większej ilości użytecznej pracy, zanim sprzęt osiągnie limit pamięci.
Prawdziwa rywalizacja dotyczy pamięci na użyteczny token
Hosting modeli frontierowych coraz bardziej zależy od wydajności pamięci, a nie tylko od nagłówkowej liczby parametrów.
Kimi K2.6 należy do rodziny modeli łączącej duże przechowywane wagi z funkcjami długiego kontekstu i agentowymi. Aktualna model documentation Cloudflare wymienia okno kontekstowe o długości 262 144 tokenów, wejścia wizualne, wywoływanie narzędzi i ustrukturyzowane wyjścia.
Te możliwości tworzą nakładające się wymagania pamięciowe. Wagi modelu muszą pozostawać dostępne podczas generowania. Każda aktywna rozmowa buduje też rosnącą pamięć podręczną KV, a batchowanie wymaga od serwera równoczesnego śledzenia wielu sekwencji.
Model może zmieścić się w pamięci GPU, a mimo to być nieekonomiczny w obsłudze. Jeśli jego wagi pozostawiają niewiele miejsca na strony pamięci podręcznej, każde wdrożenie obsługuje mniej aktywnych użytkowników. Bezczynne lub nie w pełni zapełnione batch’e marnują wtedy kosztowną pojemność akceleratorów.
To właśnie tę rywalizację mają zmienić mniejsze reprezentacje Cloudflare. Istotną miarą staje się liczba użytecznych tokenów wytworzonych na jednostkę pamięci, przy akceptowalnych granicach opóźnienia i jakości. Surowa szybkość przy jednym żądaniu ujawnia tylko część obrazu.
Ta zmiana wywiera również presję na dostawców zależnych głównie od standardowych stosów wnioskowania. Jeśli dwie usługi korzystają z podobnego sprzętu i wag modeli, dostawca z lepszym zarządzaniem pamięcią podręczną może przyjąć więcej równoległej pracy. Może też rozłożyć stałe koszty infrastruktury na większą liczbę wygenerowanych tokenów.
Ulepszenia oprogramowania nie niwelują jednak różnic sprzętowych. GPU H200 oferują znaczną pamięć o wysokiej przepustowości, podczas gdy nowsze systemy Blackwell zapewniają inne możliwości niskiej precyzji. Wyniki z jednej konfiguracji akceleratorów nie przeniosą się automatycznie na inną.
Kształt ruchu ma równie duże znaczenie. Agenci programistyczni mogą wysyłać duże prompty, ponownie używać prefiksów, wywoływać narzędzia i kontynuować pracę przez wiele tur. Sesje czatów konsumenckich mogą korzystać z krótszych promptów i mniej przewidywalnych wzorców dalszej interakcji.
Obciążenie agentowe może utrzymywać sekwencję w pamięci przez dłuższy czas. Zwiększa to wartość pojemności pamięci podręcznej, ale jednocześnie utrudnia planowanie. Jedno wyjątkowo długie żądanie może zajmować pamięć, gdy wiele mniejszych żądań czeka.
Rozdzielony projekt prefill i decode Cloudflare odpowiada na tę nierównowagę. Intensywne obliczeniowo przetwarzanie promptów działa w jednej puli. Wrażliwe na pamięć generowanie działa w drugiej, co pozwala każdej puli skalować się i używać różnych formatów numerycznych.
Ten projekt wprowadza również koszty koordynacji. Stan cache musi zostać przeniesiony lub pozostać dostępny po przekroczeniu granicy między fazami. Decyzje dotyczące routingu muszą uwzględniać dostępną pamięć, istniejące prefiksy, głębokość kolejki oraz oczekiwaną długość każdej odpowiedzi.
Projekt SGLang udostępnia framework obsługujący używany w eksperymentach Cloudflare i ruchu produkcyjnym. Cloudflare twierdzi, że współpracuje z projektem, aby włączać poprawki i funkcje do głównej gałęzi. Dzięki temu niektóre usprawnienia stają się dostępne poza jednym dostawcą.
Otwarta infrastruktura może zmniejszać lukę programistyczną między dużymi platformami a niezależnymi operatorami. Mimo to doświadczenie we wdrażaniu nadal ma znaczenie. Opublikowane jądro lub funkcja harmonogramu nie zapewniają automatycznie wolumenu ruchu, telemetrii ani planowania pojemności Cloudflare.
Ta różnica sprawia, że presja konkurencyjna ma charakter pośredni. Cloudflare nie twierdzi, że Kimi ani GLM są modelami na wyłączność. Argumentuje natomiast, że jego infrastruktura może wystarczająco wydajnie obsługiwać otwarte modele frontierowe, aby udostępniać je współdzielnie i bezserwerowo.
Twórcy modeli również korzystają z takiego układu. Moonshot AI i Z.ai mogą dotrzeć do użytkowników, którzy nie chcą konfigurować klastrów z wieloma GPU. Szersze wsparcie hostingowe może zwiększyć adopcję i dostarczyć więcej informacji zwrotnych o rzeczywistych obciążeniach.
W zamian dostawca przyjmuje na siebie trudniejszą odpowiedzialność. Musi zachować zachowanie modelu podczas transformowania formatów numerycznych. Musi także zapobiec wpływowi stanu cache jednego dzierżawcy na odpowiedzi innego.
Najsilniejsi operatorzy będą więc optymalizować jednocześnie trzy zmienne: pojemność pamięci, jakość wyników i izolację. Poprawa tylko dwóch z nich tworzy niestabilną usługę. Większa gęstość bez izolacji rodzi obawy o bezpieczeństwo, a kompresja bez testów jakości grozi cichymi regresjami.
Dla kupujących przewaga w benchmarkach pozostaje istotna, ale niewystarczająca. Imponujący model jest użyteczny tylko wtedy, gdy warstwa obsługująca zapewnia przewidywalne opóźnienia i poprawne wywołania narzędzi. Długie kolejki mogą zniwelować praktyczną wartość silniejszego modelu.
Deweloperzy powinni także oddzielać jakość modelu od jakości dostawcy. Ten sam checkpoint Kimi lub GLM może zachowywać się inaczej u różnych hostów z powodu kwantyzacji, domyślnych ustawień próbkowania, zasad cache i oprogramowania obsługującego.
Ocena produkcyjna powinna mierzyć kompletne zadania, a nie pojedyncze odpowiedzi. Przydatne sygnały obejmują poprawność wywołań narzędzi, wskaźniki przekroczeń limitu czasu, spójność długich sesji oraz opóźnienia przy realistycznej współbieżności. Te metryki pokazują, czy optymalizacja pamięci rzeczywiście poprawia aplikację.
Kompresja wag GLM zmienia kompromis między fazami
Kompresja wag GLM przyspiesza dekodowanie, ponieważ mniejsze wagi ograniczają ruch w pamięci, ale spowalnia wymagającą obliczeniowo fazę prefill.
Cloudflare przekonwertowało wagi GLM 5.2 z FP8 do INT4. Podczas dekodowania system wielokrotnie przesyła wagi modelu z pamięci GPU o wysokiej przepustowości. Przenoszenie mniejszej liczby bajtów może pozwolić na szybsze generowanie każdego tokenu, gdy wąskim gardłem jest przepustowość pamięci.
Wynik przy niskiej współbieżności był najbardziej wyraźny. Przy jednym żądaniu FP8 generował 60 tokenów na sekundę, podczas gdy INT4 osiągał 92. Oznacza to zgłoszony wzrost o 55 procent.
Przy ośmiu równoczesnych żądaniach przepustowość wzrosła z 425 do 513 tokenów na sekundę. Wzrost wyniósł 21 procent. Przy szesnastu żądaniach INT4 generował 825 tokenów na sekundę, wobec 683 dla FP8.
Poprawa pozostawała widoczna przy większym obciążeniu. INT4 osiągnął 1 267 tokenów na sekundę przy 32 żądaniach, wobec 994 dla FP8. Przy 64 żądaniach odpowiednie wyniki wyniosły 1 933 i 1 672.
Kompresja wag GLM nie przynosi takiej samej korzyści podczas prefill. Wagi INT4 muszą zostać rozwinięte przed mnożeniem macierzy. Cloudflare zmierzyło około 8 660 tokenów prefill na sekundę dla INT4, wobec 10 160 dla FP8.
Stosowanie INT4 wszędzie poświęciłoby więc przepustowość przetwarzania promptów. Cloudflare zachowuje zamiast tego FP8 dla prefill i przypisuje INT4 do dekodowania. Taki podział zachowuje najlepiej zmierzony format dla każdej fazy.
To ustalenie nawiązuje do wcześniejszych prac Cloudflare nad bezstratną kompresją wag. Projekt ten analizował wiele ścieżek wykonania, ponieważ rozmiary batchy i kształty macierzy zmieniają równowagę między dekompresją a obliczeniami.
Obecne podejście do GLM wykorzystuje stratną kwantyzację, a nie wcześniejszą metodę bezstratną. Konwersja wag FP8 do INT4 odwzorowuje więcej wartości w mniejszej liczbie reprezentowalnych stanów. Testowanie dokładności staje się niezbędne, ponieważ oryginalnych wag nie można odtworzyć dokładnie.
Cloudflare zgłosiło różnice poniżej 0,8 punktu we wszystkich ocenianych benchmarkach. Średni wynik MMLU wyniósł 86,60 dla FP8 i 86,54 dla INT4. Dokładne wyniki MMLU-Pro wyniosły 80,80 i 80,47.
W dokładności ARC-Challenge FP8 odnotował 64,93 procent, a INT4 64,85 procent. Oba formaty zaliczyły 62 z 63 przypadków w wewnętrznym benchmarku mcxams Cloudflare.
GSM8K wykazał nieco większą różnicę. FP8 osiągnął 94,39 procent dokładnych dopasowań, podczas gdy INT4 osiągnął 93,56 procent. Elastyczne punktowanie dało wyniki 94,24 i 93,48 procent.
Cloudflare twierdzi, że jakość skompresowanego modelu jest nieodróżnialna. Publiczne dane wskazują na niewielką średnią różnicę, ale pozostawiają kilka pytań otwartych. Firma nie opublikowała wyników dla każdego zachowania agentowego lub wielojęzycznego.
GLM jest powszechnie używany do programowania, korzystania z narzędzi i zadań wielojęzycznych. Ogólne benchmarki akademickie nie obejmują każdego trybu awarii w takich zastosowaniach. Nieprawidłowo sformowany argument funkcji może mieć większe znaczenie niż niewielka zmiana średniej dokładności.
Rzadkie błędy numeryczne są szczególnie trudne do wykrycia. Benchmark może wykazywać stabilną jakość zbiorczą, podczas gdy skompresowany model zmienia zachowanie w przypadku nietypowych promptów. Długie ślady rozumowania mogą wzmacniać wczesną różnicę.
Nie oznacza to, że INT4 jest nieodpowiedni. Oznacza to, że decyzje wdrożeniowe wymagają testów specyficznych dla obciążenia i ciągłego monitorowania. Dostawcy powinni porównywać dokładną konfigurację modelu otrzymywaną przez użytkowników, a nie tylko referencyjny checkpoint.
Ta sama ostrożność dotyczy deklaracji dotyczących szybkości. Liczba tokenów na sekundę zależy od długości wejścia, długości wyjścia, batchowania, sprzętu, jąder i harmonogramowania. Pomiary Cloudflare opisują testowany przez firmę system, a nie uniwersalny poziom wydajności GLM.
Mimo to podział na fazy oferuje użyteczną lekcję architektoniczną. Kwantyzacji nie należy traktować jako jednej statycznej decyzji eksportowej. Dostawca może utrzymywać wiele reprezentacji i kierować obliczenia do formatu pasującego do każdego etapu.
Ta elastyczność wiąże się z kosztami. Wiele formatów wag zużywa przestrzeń dyskową i komplikuje wdrożenie. Inżynierowie muszą zweryfikować kompatybilność, wybrać właściwe jądra i zapobiegać dryfowi konfiguracji między pulami GPU.
Dyscyplina operacyjna decyduje o tym, czy złożoność się opłaca. Jeśli żądanie trafi do niewłaściwej puli albo rewizja modelu zmieni zachowanie numeryczne, teoretyczne zyski przepustowości mają niewielkie znaczenie. Automatyzacja i obserwowalność stają się częścią samej optymalizacji.
Raportowane przez Cloudflare wyniki pokazują, dlaczego dostawcy akceptują tę złożoność. Checkpoint o 40 procent mniejszy pozostawia znaczną pamięć dla aktywnych sekwencji. Szybsze dekodowanie poprawia następnie opóźnienia w momencie, gdy użytkownicy widzą napływające tokeny.
Kompromis jest konkretny, a nie abstrakcyjny. Kompresja wag GLM zapewnia pojemność i szybkość dekodowania kosztem ryzyka numerycznego oraz narzutu w fazie prefill. Cloudflare zarządza tym kompromisem, ograniczając dany format do fazy, w której wygrywa.
Bezpieczeństwo współdzielonego cache KV staje się kwestią produkcyjną
Większa gęstość GPU zwiększa wartość każdej strony cache, a zarazem czyni błędne śledzenie własności bardziej niebezpiecznym.
Paged attention dzieli pamięć cache KV na bloki wielokrotnego użytku, zamiast wymagać jednej ciągłej alokacji dla każdego żądania. Continuous batching dodaje i usuwa sekwencje, gdy GPU pozostaje zajęte. Razem metody te ograniczają marnowanie pamięci.
Tworzą jednak również wymagający problem ewidencyjny. Fizyczne strony cache są stale przypisywane, odczytywane, zwalniane i ponownie przydzielane. System obsługujący musi zachować prawidłowe mapowanie między każdą logiczną sekwencją a jej fizycznymi stronami.
Nieaktualne mapowanie mogłoby sprawić, że żądanie odczyta nieprawidłową stronę. Mogłoby to uszkodzić odpowiedź, przerwać operację lub ujawnić stan związany z inną sekwencją. Dokładna konsekwencja zależy od awarii i otaczających ją mechanizmów kontrolnych.
Cloudflare twierdzi, że bardzo rzadkie błędy stają się istotne operacyjnie przy jego wolumenie żądań. W artykule jako ilustracyjny próg podano jeden błąd na miliard. To stwierdzenie opisuje potrzebę ochrony, a nie ujawniony wskaźnik incydentów.
Mechanizm integralności firmy wiąże zmienny tag z każdą fizyczną stroną. Żądanie zapisuje tagi, których oczekuje. Obsługiwane operacje dekodowania weryfikują te wartości przed odczytaniem współdzielonego cache.
Niezgodność tagu przerywa objęte nią żądanie. Projekt ten preferuje jawną awarię zamiast zwracania wyniku opartego na niewłaściwym stanie. Przypomina liczniki generacji używane w innych systemach zarządzania pamięcią.
Cloudflare oceniło tę kontrolę na średniej wielkości modelu produkcyjnym, używając dwóch workerów prefill i dwóch workerów dekodowania. Testy wykorzystywały wejścia o długości 8 192 tokenów i wyjścia o długości 1 000 tokenów. Raportowana współbieżność wahała się od jednego do ośmiu.
Przepustowość spadła o 0,38–0,79 procent w tych testach. Wzrost opóźnienia p95 wyniósł 0,42–0,80 procent. Cloudflare twierdzi, że nawet górna granica przedziału ufności pozostała w pobliżu jednego procenta.
Firma uruchamia walidację jako oddzielne sprawdzenie batcha. Uniknęła połączenia tej operacji z jądrem attention, ponieważ grupy wątków GPU mogłyby stworzyć wyścig. Tracker no-op pozostaje dostępny dla wdrożeń, w których sprawdzanie jest wyłączone.
Wyniki te sprawiają wrażenie, że kontrole integralności są niedrogie. Jednak ocena nie obejmowała każdego rozmiaru modelu, kształtu sekwencji ani poziomu współbieżności. Skupiała się także na obsługiwanych operacjach dekodowania, co jest zastrzeżeniem zasługującym na uwagę.
Czytelnicy nie powinni interpretować tego mechanizmu jako pełnego dowodu izolacji dzierżawców. Integralność cache jest jedną warstwą obrony w większym systemie obsługującym. Routing, alokacja pamięci, poprawność jąder i izolacja procesów nadal mają znaczenie.
Kontrola może wykryć niezgodność generacji strony, którą rozumie jej tracker. Nie może automatycznie rozpoznać każdego błędu numerycznego ani defektu oprogramowania. Prawidłowy tag nie dowodzi, że zawartość strony jest semantycznie poprawna.
Istnieje również napięcie między opcjonalnym wdrożeniem a powszechną ochroną. Cloudflare twierdzi, że sprawdzanie integralności jest włączane dla każdego wdrożenia osobno. Deklarowanym celem firmy jest uczynienie tej funkcji na tyle niedrogą, by pozostawała włączona wszędzie.
Dopóki to nie nastąpi, klienci nie mogą zakładać, że każda ścieżka modelu korzysta z tej samej ochrony. Jasna dokumentacja dotycząca zakresu ochrony pomogłaby deweloperom ocenić pozostałe ryzyko. Niezależne testy bezpieczeństwa dostarczyłyby silniejszych dowodów niż same pomiary wydajności.
Argument bezpieczeństwa odzwierciedla mimo to istotną zmianę w inżynierii inferencji. Funkcje wydajnościowe wymagają teraz wyraźnego rozumowania o stanie między żądaniami. Optymalizacji pamięci nie można już oceniać wyłącznie na podstawie wykresów przepustowości.
Kompresja zwiększa tę potrzebę. Cache FP8 Kimi pozwala utrzymać aktywnych więcej żądań. Wagi INT4 GLM tworzą więcej miejsca na strony cache. Obie zmiany zwiększają ilość współdzielonego stanu obsługiwanego przez jedno wdrożenie.
Głównym przeciwnikiem w tej historii jest zatem niebezpieczna gęstość. Celem nie jest maksymalne upakowanie za wszelką cenę. Jest nim wyższe wykorzystanie zasobów przy zachowaniu granic między żądaniami i akceptowalnego zachowania modelu.
Podejście Cloudflare umieszcza kontrolę bezpieczeństwa blisko współdzielonego zasobu. Może to wykryć błędy alokacji, zanim dane cache trafią do operacji attention. Wczesne zakończenie ogranicza także propagację uszkodzonego stanu.
Przerwane żądania nadal wpływają na niezawodność. Jeśli kontrole zaczną często się uruchamiać, użytkownicy będą widzieć błędy lub ponowienia prób, nawet gdy izolacja działa zgodnie z założeniami. Operatorzy muszą śledzić wskaźniki niezgodności, badać przyczyny i zapobiegać burzom ponowień.
Cloudflare nie ujawnił w artykule wskaźnika rozbieżności w środowisku produkcyjnym. Brak tej metryki ma większe znaczenie niż sam narzut syntetyczny. Niskokosztowa kontrola jest przydatna, ale jej wartość operacyjna staje się wyraźniejsza, gdy raportuje rzeczywiste wykrycia.
Firma ma również interes w przedstawianiu nowej gęstości jako bezpiecznej. Jej dowody należy traktować jako ujawnienie techniczne pochodzące od operatora systemu. Są informacyjne, ale nie są równoznaczne z niezależnym audytem.
Dla deweloperów szersza lekcja ma wymiar praktyczny. Współdzielone wnioskowanie ukrywa złożoność infrastruktury, ale jej nie eliminuje. Oceny dostawców powinny obejmować mechanizmy izolacji, obsługę awarii i przejrzystość incydentów, obok opóźnień i jakości modeli.
Na co zwracać uwagę w miarę upowszechniania się optymalizacji
Trzy sygnały pokażą, czy obsługa mniejszych modeli przez Cloudflare stanie się trwałą przewagą, czy pozostanie wyspecjalizowaną konfiguracją.
Pierwszym sygnałem będzie szersze wdrożenie pamięci podręcznej FP8. Cloudflare informuje, że rozszerza użycie pamięci podręcznych KV FP8 na większą część swojej floty. Obsługa dodatkowych modeli i sprzętu pokazałaby, że kwantyzacja pamięci podręcznej Kimi KV sprawdza się szerzej niż w jednym zmierzonym środowisku.
Przydatne dowody obejmowałyby dane dotyczące współbieżności, opóźnień krańcowych i jakości dla różnych długości sekwencji. Stabilne wyniki w tych wymiarach wzmocniłyby argument Cloudflare dotyczący efektywności pamięci. Częste wyjątki specyficzne dla modeli osłabiłyby go.
Drugim sygnałem będzie walidacja NVFP4 na procesorach GPU Blackwell. NVFP4 to czterobitowy format zmiennoprzecinkowy Nvidia dla nowszego sprzętu. Cloudflare podaje, że testuje tę reprezentację jako kolejną drogę do zmniejszenia rozmiaru wag.
Udane wdrożenie mogłoby rozszerzyć kompresję wag GLM poza INT4 i ponownie zmienić równowagę między prefill a decode. Sprawdziłoby również, czy Cloudflare potrafi przenieść swoją strategię uwzględniającą fazy na kolejne generacje akceleratorów.
Istotnym wynikiem nie jest pojedyncza liczba szczytowej przepustowości. Warto obserwować opóźnienia end-to-end, oceny jakości i pojemność pamięci przy batchowaniu produkcyjnym. Te pomiary pokażą, czy niższa precyzja zapewnia użyteczne korzyści na poziomie aplikacji.
Trzecim sygnałem będzie powszechne pokrycie kontrolami integralności pamięci podręcznej. Cloudflare chce włączyć kontrole wszędzie, przy znikomym koszcie. Osiągnięcie tego celu połączyłoby większą gęstość ze spójnym domyślnym mechanizmem bezpieczeństwa.
Ujawnienia dotyczące pokrycia powinny wskazywać obsługiwane modele, operacje i sprzęt. Metryki wykrywania wniosłyby jeszcze większą wartość, zwłaszcza gdyby Cloudflare wyjaśnił, jak często występują rozbieżności i co je powoduje.
Te sygnały są ważne, ponieważ obecne dowody firmy są mocne, ale ograniczone. Pokazują istotne zyski dla wybranych modeli i wdrożeń. Nie dowodzą, że każde obciążenie korzysta z tych samych formatów.
Deweloperzy powinni testować hostowane systemy Kimi i GLM z użyciem realistycznych promptów, łańcuchów narzędzi i współbieżności. Należy śledzić czas do pierwszego tokenu, szybkość generowania, wskaźniki przekroczeń limitu czasu i skuteczność realizacji pełnych zadań. Warto porównywać zachowanie po aktualizacjach modeli po stronie dostawcy.
Zespoły powinny także zachowywać własną historię ocen. Przeszukiwalna baza wiedzy inżynierskiej może połączyć wyniki benchmarków, incydenty, zmiany konfiguracji i komunikaty dostawców. Ten kontekst pomaga odróżnić regresję modelu od zmiany infrastruktury.
Cloudflare przesunął debatę o modelach granicznych poza prostą kwestię dostępności. Trudniejsze pytanie brzmi, czy dostawca potrafi utrzymać duże modele jako szybkie, ekonomiczne, dokładne i odizolowane przy rzeczywistej współbieżności. Obserwuj trzy sygnały wdrożenia, a następnie oceniaj system na podstawie pełnych obciążeń, a nie jednego benchmarku czy wykresu przepustowości.
