Tencent udostępnia AngelSpec jako open source, podważając uniwersalne podejście do spekulacyjnego dekodowania

Tencent Hunyuan udostępnił AngelSpec jako open source po przedstawieniu wyników wskazujących na nawet 2,40-krotne przyspieszenie inferencji Hy3-A21B względem standardowego dekodowania autoregresyjnego. Framework łączy wsparcie dla trenowania, ewaluacji i wdrażania dwóch różnych ścieżek spekulacyjnego dekodowania. Jego główna teza podważa powszechne założenie: jedna metoda szkicowania nie jest w stanie efektywnie obsłużyć każdego obciążenia modeli językowych.

AngelSpec obejmuje multi-token prediction, czyli MTP, które proponuje kilka przyszłych tokenów za pośrednictwem lekkiego draftera autoregresyjnego. Wprowadza także DFly, system block-diffusion, który równolegle szkicuje dłuższą grupę tokenów. Tencent twierdzi, że DFly zapewnił przepustowość o 10,5% do 11,8% wyższą niż DFlash w testowanych warunkach obsługi.

To porównanie ma znaczenie, ponieważ DFlash już wcześniej odszedł od ściśle sekwencyjnego szkicowania w spekulacyjnym dekodowaniu. AngelSpec nie ogranicza się do zaproponowania kolejnego szybszego draftera. Organizuje dwa przeciwstawne podejścia wokół obciążenia, które każde z nich obsługuje najlepiej, a następnie dostosowuje weryfikację do warunków wykonawczych.

Rezultatem jest otwarty framework oferujący bardziej operacyjne spojrzenie na przyspieszanie inferencji. Deweloperzy mogą prześledzić ścieżkę trenowania, przetestować udostępnione modele szkicujące Hy3 oraz zbadać, jak wydajność zmienia się wraz z ruchem. Jednak zgłoszone przez Tencent zyski pochodzą z jego własnych modeli, konfiguracji i projektu ewaluacji. Niezależne wyniki z wdrożeń produkcyjnych pozostają kluczowym brakującym dowodem.

AngelSpec zamienia wybór badawczy w wybór wdrożeniowy

AngelSpec traktuje spekulacyjne dekodowanie jako problem doboru do obciążenia, a nie rywalizację o jedną uniwersalną architekturę szkicowania.

Badacze Tencentu przesłali pierwszą wersję artykułu AngelSpec 28 lipca 2026 r. Zmieniona wersja pojawiła się 29 lipca. Firma ogłosiła następnie wydanie open source z kodem treningowym oraz wagami modelu szkicującego Hy3-A21B.

Spekulacyjne dekodowanie wykorzystuje mniejszy lub tańszy drafter do proponowania kilku przyszłych tokenów. Pełny model docelowy sprawdza te propozycje wspólnie i akceptuje zgodny prefiks. Gdy propozycje są trafne, system generuje kilka prawidłowych tokenów, unikając równoważnej liczby kosztownych przebiegów modelu docelowego.

Metoda zachowuje rozkład wyjściowy modelu docelowego, jeśli zostanie wdrożona z wymaganym procesem weryfikacji i odrzucania. Zmienia więc efektywność generowania tokenów, zamiast zastępować odpowiedzi modelu docelowego odpowiedziami draftera.

Jakość szkicowania nadal decyduje o tym, czy teoretyczna przewaga przełoży się na praktyczne przyspieszenie. Słaby drafter generuje odrzucane tokeny, zwiększając nakład pracy bez postępu generacji. Duży drafter może przewidywać trafnie, ale zużywać zbyt wiele czasu i pamięci. Weryfikacja również może być kosztowna, gdy systemy testują więcej kandydatów, niż uzasadnia dane żądanie.

AngelSpec umieszcza te zmienne w jednym frameworku treningowym i ewaluacyjnym. Obsługuje MTP oraz równoległe blokowe spekulacyjne dekodowanie, w tym generowanie stanów ukrytych, trenowanie na długim kontekście, przepływy rollout i ocenę akceptacji online. Wydanie ma obejmować większą część drogi między checkpointem badawczym a działającą usługą inferencyjną.

Dwie ścieżki szkicowania frameworka dzielą problem według zachowania wyników. Tencent trenuje swojego draftera MTP na zróżnicowanych danych konwersacyjnych, gdzie język ma otwarty charakter, a kolejne tokeny pozostają stosunkowo niepewne. Ścieżkę block-diffusion trenuje na kodzie i matematyce, gdzie dłuższe kontynuacje często podążają za bardziej przewidywalnymi strukturami.

Ta specjalizacja jest najważniejszą zmianą wynikającą z tego wydarzenia. Wiele porównań spekulacyjnego dekodowania pyta, która metoda wygrywa średnio. AngelSpec pyta natomiast, która struktura szkicowania pasuje do konkretnego rozkładu, a następnie udostępnia obie struktury poprzez wspólną ścieżkę rozwoju.

Towarzyszące wydaniu wagi sprawiają też, że jest ono łatwiejsze do przetestowania niż artykuł opisujący niedostępny system. Tencent podaje, że udostępnił draftery MTP i DFly dla Hy3-A21B za pośrednictwem swoich kanałów modelowych. Deweloperzy nadal potrzebują odpowiadającego modelu docelowego i odpowiedniego sprzętu do obsługi, ale nie muszą odtwarzać każdego etapu trenowania przed rozpoczęciem ewaluacji.

Hy3 stanowi dla tego wydania wymagający cel. Oficjalne repozytorium modelu Hy3 opisuje model mixture-of-experts z 295 miliardami parametrów łącznie i 21 miliardami aktywnych parametrów. Wymienia także warstwę MTP z 3,8 miliarda parametrów oraz okno kontekstowe o długości 256 000 tokenów.

Te parametry sprawiają, że efektywność inferencji ma znaczenie ekonomiczne. Dla każdego tokenu aktywuje się jedynie część pełnego modelu, lecz obsługa nadal wymaga znacznej pamięci, komunikacji i obliczeń modelu docelowego. Drafter, który zwiększa liczbę zaakceptowanych wyników na krok weryfikacji, może poprawić opóźnienia lub przepustowość bez ponownego trenowania modelu podstawowego.

AngelSpec pojawia się więc jako coś więcej niż kolejny dodatek do Hy3. Oferuje jawny framework do wyboru, trenowania i oceny systemów szkicujących w miarę zmiany warunków obsługi. Ten szerszy zakres wywiera presję na uniwersalne podejście do spekulacyjnego dekodowania.

Zgłoszone zyski wywierają presję na statyczne strategie szkicowania

Najsilniejszym twierdzeniem Tencentu nie jest wyłącznie maksymalne przyspieszenie, lecz przewaga DFly na każdym testowanym poziomie współbieżności od 4 do 64.

Według artykułu DFly zapewnił od 1,98 do 2,40 razy większą szybkość end-to-end względem dekodowania autoregresyjnego na Hy3-A21B. Tencent raportuje także przepustowość wyższą o 10,5% do 11,8% niż w DFlash oraz średnio zaakceptowany wynik dłuższy o około 30%.

Współbieżność określa, ile żądań system obsługi przetwarza jednocześnie. Zmienia ona równowagę między obliczeniami, efektywnością batchowania, presją na pamięć i narzutem weryfikacji. Metoda, która wygląda na szybką dla pojedynczego żądania, może stracić przewagę, gdy wiele żądań konkuruje o te same akceleratory.

Tencent podaje, że DFly osiągnął najwyższą średnią przepustowość przy każdej testowanej współbieżności od 4 do 64. Ten zakres ma znaczenie, ponieważ obejmuje zarówno stosunkowo lekki ruch, jak i silniej batchowaną obsługę. Wynik sugeruje, że harmonogram i strategia weryfikacji DFly wniosły więcej niż sama surowa stopa akceptacji modelu szkicującego.

Liczby nadal wymagają ostrożnej interpretacji. Przyspieszenie 2,40 razy nie oznacza, że każdy użytkownik otrzyma odpowiedzi 2,40 razy szybciej. Przyspieszenie end-to-end zależy od obciążenia benchmarku, długości odpowiedzi, mieszanki żądań, polityki batchowania, profilu sprzętowego i konfiguracji bazowej.

Przepustowość i opóźnienia odpowiadają też na różne pytania. Przepustowość mierzy, ile pracy system wykonuje w czasie. Użytkownicy interaktywni częściej zwracają uwagę na czas do pierwszego tokenu i opóźnienie między kolejnymi tokenami. Usługa może zwiększyć całkowitą przepustowość, jednocześnie zapewniając mniejszą lub nierównomierną poprawę dla pojedynczego żądania.

To rozróżnienie wywiera presję na zespoły inferencyjne stosujące stałe polityki szkicowania. Statyczna polityka może wybierać jedną długość szkicowania, jedną głębokość weryfikacji lub jednego draftera dla całego ruchu. AngelSpec przekonuje, że wybory te powinny reagować na domenę, cechy żądania, obciążenie online i sprzęt wdrożeniowy.

Celem tej presji nie jest więc jedna firma. Jest nim podejście traktujące spekulacyjne dekodowanie jako stałe rozszerzenie modelu. Jeśli ustalenia Tencentu potwierdzą się gdzie indziej, operatorzy będą potrzebować logiki routingu i harmonogramowania, która rozumie, kiedy praca związana ze szkicowaniem nadal przynosi wartość.

DFlash zapewnia najbardziej bezpośrednie porównanie. Jego projekt block-diffusion wykorzystuje stany ukryte modelu docelowego do równoległego przewidywania wielu tokenów szkicujących. Podejście to pozwala uniknąć generowania każdej propozycji w osobnym sekwencyjnym kroku draftera.

Autorzy DFlash raportowali ponad sześciokrotne przyspieszenie w wybranych eksperymentach oraz zyski względem EAGLE-3. Wyniki te wykorzystywały inne modele docelowe i warunki testowe, dlatego nie należy ich bezpośrednio porównywać z maksymalnym wynikiem AngelSpec wynoszącym 2,40 razy. Istotnym twierdzeniem Tencentu jest kontrolowane porównanie DFly przedstawione w ramach własnej ewaluacji Hy3.

Systemy typu EAGLE pozostają kolejnym ważnym punktem odniesienia. Wykorzystują cechy modelu docelowego do kierowania mniejszym drafterem autoregresyjnym, często układając propozycje pod kątem efektywnej weryfikacji. Systemy te mogą zapewniać stabilne wyniki dla zróżnicowanego tekstu, lecz sekwencyjne zależności w szkicowaniu mogą ograniczać szybkość proponowania długich sekwencji kandydatów.

MTP zajmuje lżejszą pozycję w tym autoregresyjnym podejściu. Łatwiej je zintegrować, gdy model docelowy już udostępnia zgodne warstwy predykcyjne. Własne wydanie Hy3 Tencentu obejmuje warstwę MTP, co czyni ten model naturalnym środowiskiem testowym do porównania lekkiego szkicowania ze specjalizowanym systemem blokowo-równoległym.

Presja, jaką AngelSpec wywiera na istniejące wdrożenia, ma charakter praktyczny. Zespoły muszą zdecydować, czy dodatkowy model, logika harmonogramowania, profilowanie i użycie pamięci zapewniają wystarczającą liczbę zaakceptowanych tokenów, aby uzasadnić ich złożoność. Framework daje im kod i wagi do zbadania tego pytania, ale nie czyni odpowiedzi uniwersalną.

Jak AngelSpec zwiększa selektywność DFly

DFly łączy równoległe szkicowanie z informacją autoregresyjną, a następnie przeznacza pracę weryfikacyjną tam, gdzie oczekiwany zwrot jest największy.

Drafter block-diffusion przewiduje kilka pozycji jednocześnie, zamiast uzupełniać je pojedynczo. Równoległe przewidywanie skraca opóźnienie szkicowania, zwłaszcza gdy blok kandydatów jest długi. Tokeny w zdaniu lub sekwencji kodu są jednak silnie zależne od wcześniejszych tokenów w tym samym bloku.

Ta zależność tworzy słabość. Jeśli każda pozycja jest przewidywana na podstawie zamaskowanych lub niepełnych sąsiadów, późniejsze propozycje mogą nie uwzględniać informacji, które drafter autoregresyjny otrzymuje naturalnie. Jeden wczesny błąd może skrócić prefiks zaakceptowany przez model docelowy, marnując znaczną część zaproponowanego bloku.

DFly rozwiązuje to napięcie za pomocą dwóch połączonych komponentów. Jego szkielet bazowy uwzględnia cechy modelu docelowego, zachowując jednocześnie blokowo-równoległe generowanie. Autoregresyjna głowica warunkowana poprzednikami dostarcza predykcjom także informacji o wcześniejszych tokenach, poprawiając zależności wewnątrz proponowanego bloku.

Architektura nie przekształca całego szkicu w konwencjonalny proces sekwencyjny. Projekt Tencentu stara się zachować pracę równoległą w szkielecie bazowym, dodając jednocześnie wystarczająco dużo informacji o poprzednikach, aby poprawić spójność kandydatów. Ta równowaga ma kluczowe znaczenie dla deklarowanego wzrostu średniej zaakceptowanej długości.

Zaakceptowana długość to liczba zaproponowanych tokenów, które model docelowy zatwierdza przed napotkaniem niezgodności. Dłuższe zaakceptowane prefiksy rozkładają każdy kosztowny krok weryfikacji na większą liczbę użytecznych wyników. Maksymalizowanie samej zaakceptowanej długości może jednak wprowadzać w błąd, jeśli generowanie i sprawdzanie tych kandydatów zużywa zbyt dużo czasu.

AngelSpec dodaje więc adaptacyjną metodę weryfikacji o nazwie D-Cut. Głębokość weryfikacji określa, jak dużą część każdej zaproponowanej kontynuacji sprawdza model docelowy. Stała głębokość może nadmiernie inwestować w niepewnych kandydatów lub kończyć zbyt wcześnie w przypadku bardzo przewidywalnych.

D-Cut traktuje zdolność weryfikacyjną jako wspólny zasób na poziomie batcha. Szacuje oczekiwaną wartość zachowania dodatkowych pozycji kandydatów i porównuje ją z profilowanym kosztem wykonawczym. Harmonogram może następnie kierować więcej pracy weryfikacyjnej do prefiksów o wysokiej pewności w wielu żądaniach.

To decyzja dotycząca obsługi, a nie wyłącznie decyzja dotycząca modelu. Dwa żądania uruchamiane przez ten sam model mogą uzasadniać różną głębokość weryfikacji. Ustrukturyzowane uzupełnianie kodu może utrzymać długi, pewny prefiks, podczas gdy otwarta odpowiedź czatowa może rozbiec się już po kilku tokenach.

Sprzęt również zmienia te kalkulacje. Większa partia weryfikacyjna może być wydajna w jednej konfiguracji akceleratorów, a kosztowna w innej. Koszty komunikacji, przepustowość pamięci, kernele i równoległość modelu docelowego wpływają na to, czy kolejna pozycja kandydująca oszczędza czas.

Dlatego AngelSpec profiluje koszt działania zamiast opierać się wyłącznie na szacunkach prawdopodobieństwa. Kandydat może wyglądać na prawdopodobny do zaakceptowania, a mimo to oferować słabą użyteczność, jeśli jego sprawdzenie rozszerza partię do nieefektywnego kształtu. Harmonogram potrzebuje zarówno pewności, jak i zmierzonego kosztu systemowego.

Dokumentacja Nvidia dotycząca speculative decoding pokazuje, jak frameworki wdrożeniowe już udostępniają konfigurację zależną od metody. Obsługa DFlash wymaga modelu draftowego, długości draftu, tokenu maskującego oraz wybranych warstw docelowych. AngelSpec przesuwa problem jeszcze dalej, w kierunku adaptacyjnej alokacji dla aktywnych żądań.

Podział według domen uzupełnia tę adaptację czasu działania. MTP pozostaje lekką ścieżką dla odpowiedzi konwersacyjnych o większej niepewności. DFly celuje w kod i matematykę, gdzie równoległe bloki mogą wychwycić dłuższe przewidywalne sekwencje. Żadna z metod nie zyskuje automatycznie prawa do każdego żądania.

Rozważmy usługę AI do kodowania, która generuje powtarzalny zestaw testów. Importy, sygnatury funkcji i wzorce asercji mogą sprawiać, że następny blok jest stosunkowo przewidywalny. DFly może zaproponować dłuższą kontynuację, a D-Cut zachować głębszą weryfikację, gdy pewność pozostaje wysoka.

Teraz rozważmy tę samą usługę odpowiadającą na niejednoznaczne pytanie dotyczące architektury. Z tego samego promptu może wynikać kilka poprawnych wyjaśnień. Zaakceptowany prefiks może się skrócić, ponieważ model draftowy i docelowy wybierają inne sformułowania. Mniejsza propozycja MTP może uniknąć zużywania zasobów na długi blok kandydujący o niskich szansach przetrwania.

Mechanizm ten sprawia, że premiera jest ważniejsza niż pojedyncza poprawa benchmarku. Przedstawia speculative decoding jako politykę obejmującą dane treningowe, architekturę draftową, klasyfikację żądań i koszt obsługi. Przyspieszenie wynika z koordynacji tych warstw, a nie z maksymalizacji jednego odizolowanego wyniku.

Czego liczby AngelSpec nie dowodzą

AngelSpec przedstawia wiarygodne dowody własne, ale nie ustala jeszcze, że DFly wygrywa w różnych modelach, konfiguracjach sprzętowych czy ruchu produkcyjnym.

Wyniki artykułu pochodzą od zespołu, który zaprojektował framework i wytrenował modele draftowe. Zgłoszone porównania nie zostały niezależnie odtworzone w momencie premiery. Czytelnicy powinni traktować przyspieszenia jako zmierzone deklaracje firmy, a nie uniwersalne gwarancje wydajności.

Pierwszym ograniczeniem jest zależność od modelu. DFly wykorzystuje wewnętrzne cechy modelu docelowego, dlatego model draftowy jest ściśle związany z architekturą i charakterystyką treningu swojego celu. Model draftowy Hy3-A21B nie może po prostu stać się gotowym akceleratorem dla niepowiązanej rodziny modeli.

To powiązanie zwiększa koszty treningu i utrzymania. Każdy obsługiwany model docelowy może potrzebować własnego procesu ekstrakcji stanów ukrytych, mieszanki danych treningowych, checkpointu i cyklu walidacji. Aktualizacje modelu docelowego mogą również wymagać ponownego testowania kompatybilności albo świeżego treningu modelu draftowego.

Zależność od sprzętu tworzy kolejną niepewność. Tencent twierdzi, że D-Cut wykorzystuje profilowany koszt działania, uznając, że najlepsza polityka weryfikacji zmienia się między systemami. Polityka dostrojona dla jednego klastra może potrzebować nowych profili, zanim będzie dobrze działać na innych akceleratorach lub topologiach sieciowych.

Publiczne liczby nagłówkowe łączą również kilka obciążeń w przedziały. Kod, matematyka i rozmowa mają różną przewidywalność. Średnia przepustowość może ukrywać słabe kategorie, niekorzystne długości promptów lub wzorce ruchu, w których narzut draftowania zbliża się do oszczędzonego obliczania przez model docelowy.

Zachowanie przy długim kontekście zasługuje na szczególną uwagę. AngelSpec obsługuje trening z długim kontekstem, a Hy3 podaje okno kontekstowe o długości 256 000 tokenów. Jednak duże cache’e klucz-wartość zwiększają presję na pamięć i mogą zmieniać względny koszt draftowania oraz weryfikacji. Wyniki przy krótszych kontekstach nie mogą rozstrzygać wydajności w pobliżu maksymalnego okna modelu.

Zachowanie jakości również wymaga dyscypliny implementacyjnej. Speculative decoding może zachować rozkład modelu docelowego dzięki właściwemu algorytmowi akceptacji i odrzucania. Skróty wdrożeniowe, przybliżona weryfikacja, zmienione próbkowanie lub niekompatybilna kwantyzacja mogą zmienić wyniki. Operatorzy muszą walidować zarówno szybkość, jak i równoważność zachowania.

Pamięć jest kolejnym rzeczywistym kosztem. Model docelowy, model draftowy, interfejsy stanów ukrytych i dodatkowe bufory wykonawcze muszą współistnieć. Nawet lekki model draftowy może ograniczyć miejsce na cache klucz-wartość albo większe partie. Wynikający z tego kompromis pojemności może zniwelować wzrost przepustowości we wdrożeniach ograniczonych pamięcią.

Znaczenie ma także złożoność operacyjna. Usługa produkcyjna musi monitorować długość akceptacji, czas draftowania, czas weryfikacji, zachowanie kolejki i wydajność awaryjną. Routing między MTP i DFly wprowadza kolejną warstwę decyzyjną, której błędy mogą kierować niewłaściwe obciążenia do niewłaściwego modelu draftowego.

Wydanie open source sprawia, że te pytania można testować, co jest wartościowe. Nie odpowiada jednak na nie automatycznie. Zespoły powinny odtworzyć bazowy wariant autoregresyjny na własnym sprzęcie, zanim porównają którąkolwiek ścieżkę AngelSpec.

Następnie powinny rozdzielić pomiary według rodzaju obciążenia i poziomu ruchu. Przydatne kategorie obejmują interaktywny czat, uzupełnianie kodu, rozumowanie matematyczne, ślady użycia narzędzi i generowanie długich tekstów. Każda kategoria powinna uwzględniać percentyle opóźnień, przepustowość, zużycie pamięci, długość akceptacji i kontrolę równoważności wyników.

Uczciwe porównanie z DFlash wymaga też dopasowanych warunków. Należy użyć tego samego modelu docelowego, precyzji, frameworka obsługującego, rozkładu promptów, długości wyjścia i współbieżności. W przeciwnym razie twierdzenia architektoniczne mogą splątać się z jakością kerneli lub różnicami konfiguracji.

Opinie społeczności dostarczają wczesnych sygnałów, ale nie zastępują kontrolowanego odtworzenia. Raporty z lokalnych wdrożeń często wykorzystują modele skwantyzowane, sprzęt konsumencki lub zmodyfikowane silniki obsługujące. Wyniki te mogą ujawniać problemy z kompatybilnością, choć rzadko są wystarczająco zbliżone do konfiguracji artykułu, by potwierdzić jego nagłówkowy przedział.

Luka benchmarkowa nie czyni AngelSpec nieistotnym. Określa kolejny etap tej historii. Tencent dostarczył architekturę, ścieżkę kodu i wagi modelu, które zespoły zewnętrzne mogą podważyć w warunkach niekontrolowanych przez pierwotnych autorów.

Trzy sygnały zdecydują, czy AngelSpec wyjdzie poza Hy3

Znaczenie AngelSpec będzie zależeć od niezależnej replikacji, szerszego wsparcia modeli oraz dowodów, że adaptacyjny routing przetrwa rzeczywisty ruch produkcyjny.

Pierwszym sygnałem jest odtwarzalny benchmark Hy3-A21B wykonany przez niezależny zespół zajmujący się inferencją. Najmocniejszy test wykorzystywałby udostępnione wagi MTP i DFly, jednocześnie raportując sprzęt, precyzję, wersje frameworków, miks promptów i długości wyjść. Powinien porównywać dekodowanie autoregresyjne, MTP, DFlash i DFly w dopasowanych warunkach.

Replikacja zbliżona do przedziału Tencentu od 1,98 do 2,40 raza wzmocniłaby główne twierdzenie. Stałe zyski względem DFlash sugerowałyby również, że kondycjonowanie poprzednika i D-Cut wnoszą wartość wykraczającą poza ogólne draftowanie metodą block diffusion. Mniejsze lub niestabilne zyski zawęziłyby praktyczną atrakcyjność AngelSpec.

Najbardziej użyteczny niezależny raport publikowałby więcej niż średnią przepustowość. Powinien zawierać czas do pierwszego tokenu, opóźnienie między tokenami, opóźnienie ogonowe, użycie pamięci, zaakceptowaną długość i wydajność na różnych poziomach współbieżności. Takie pomiary pokazałyby, czy zbiorcza efektywność poprawia doświadczenie użytkownika.

Drugim sygnałem jest wsparcie dla innej ważnej rodziny modeli docelowych. AngelSpec ma obecnie najjaśniejsze dowody i udostępnione wagi draftowe wokół Hy3. Udany port do Qwen, Llama lub innego szeroko wdrażanego otwartego modelu sprawdziłby, czy framework uogólnia się poza architekturę Tencentu.

Portowanie ujawniłoby również rzeczywisty koszt adopcji. Badacze musieliby wygenerować ukryte stany modelu docelowego, wytrenować wyspecjalizowane modele draftowe, zintegrować weryfikację i profilować zachowanie czasu działania. Udokumentowany port wymagający rozsądnego wysiłku inżynieryjnego wzmocniłby twierdzenie frameworka o użyteczności od początku do końca.

Brak zainteresowania portami sugerowałby, że AngelSpec jest przede wszystkim pakietem optymalizacji Hy3. Taki wynik nadal mógłby przynosić korzyści użytkownikom modeli Tencentu, ale osłabiłby szerszy argument za zunifikowanym frameworkiem speculative decoding.

Trzecim sygnałem są dowody produkcyjne z mieszanych obciążeń. Argument Tencentu opiera się na heterogeniczności, więc statyczny benchmark nie może go w pełni zweryfikować. Decydującym testem jest to, czy aktywna usługa potrafi wybierać między MTP i DFly, gdy zmieniają się ruch, domeny i wykorzystanie sprzętu.

Operatorzy powinni obserwować, jak często decyzje routingu poprawiają zaakceptowane wyjście na jednostkę kosztu weryfikacji. Powinni też mierzyć wskaźniki awaryjnego powrotu i błędy routingu. Złożony system adaptacyjny musi przewyższać prostszą bazę odniesienia po uwzględnieniu narzutu monitorowania i harmonogramowania.

Ten test jest szczególnie istotny dla usług łączących czat, kodowanie, pracę matematyczną i działania agentów. Takie produkty generują wyniki o bardzo różnej entropii i długości. Zapewniają warunki, w których wyspecjalizowane draftowanie powinno przewyższać uniwersalną politykę.

Jeśli wdrożenia z mieszanymi obciążeniami wykażą stabilne zyski, konkurenci odczują presję, by udostępnić podobne mechanizmy routingu. Frameworki obsługujące mogą ewoluować od wyboru jednego algorytmu speculative decoding przy uruchomieniu do przypisywania algorytmów i budżetów weryfikacyjnych dla każdego żądania.

Jeśli zyski znikną poza starannie dobranymi obciążeniami, prostsze metody pozostaną atrakcyjne. MTP może być łatwiejsze w obsłudze, zwłaszcza gdy model jest już dostarczany z kompatybilnymi warstwami. Statyczne strategie draftowe zmniejszają także liczbę modeli i polityk, które zespoły muszą utrzymywać.

Deweloperzy oceniający wydanie powinni zachowywać wyniki testów i decyzje konfiguracyjne w przeszukiwalnej bazie wiedzy inżynieryjnej. Eksperymenty z speculative decoding obejmują wystarczająco wiele współdziałających zmiennych, że nieudokumentowane uruchomienia szybko stają się niemożliwe do porównania.

AngelSpec już zmienił pytanie stojące przed inżynierami inferencji. Wybór nie dotyczy już tylko tego, czy włączyć speculative decoding. Dotyczy tego, czy model draftowy, rozkład treningowy, polityka weryfikacji i profil sprzętowy są wystarczająco dobrze dopasowane do każdego żądania, aby oszczędzić rzeczywistą pracę.

Najbliższe jeden do trzech miesięcy powinny ujawnić, czy zespoły zewnętrzne odtworzą liczby Tencentu, przeniosą DFly poza Hy3 i zweryfikują adaptacyjny routing pod rzeczywistym obciążeniem. Do tego czasu AngelSpec pozostaje poważnym otwartym eksperymentem z obiecującymi wynikami własnymi, a nie rozstrzygniętym zwycięzcą.

Dla zespołów obsługujących dziś Hy3 użytecznym kolejnym krokiem jest kontrolowany benchmark względem istniejących konfiguracji autoregresyjnych i MTP. Dla wszystkich pozostałych kluczowe pytanie jest węższe: czy draftowanie świadome obciążenia zapewnia wystarczająco trwałą efektywność, by uzasadnić kolejny model i warstwę harmonogramowania? Odpowiedź zadecyduje, czy AngelSpec stanie się szeroko przyjętym frameworkiem inferencyjnym, czy pozostanie dobrze zaprojektowaną przewagą związaną głównie z własną rodziną modeli Tencentu.