**Przedstawiamy SPEED-Bench: Ujednolicony i różnorodny benchmark dla dekodowania spekulacyjnego**

Speculative decoding to niedawno odkryta, ale już absolutnie niezbędna technika w świecie szybkich modeli językowych. Zamiast czekać, aż model generuje tokeny jeden po drugim, pozwala ona na równoczesne przewidywanie kilku przyszłych tokenów za pomocą szybszego modelu pomocniczego, a następnie weryfikację ich przez główny model. Brzmi prosto? Może, ale w praktyce to chaos — każdy zespół badawczy testuje to inaczej, na innych danych, w innych warunkach. Wyniki są nieporównywalne, a wnioski z jednej pracy często nie przenoszą się na inne środowiska. Właśnie dlatego zespół NVIDIA postanowił położyć kres tej anarchii, wprowadzając SPEED-Bench — pierwszy naprawdę kompleksowy benchmark do oceny speculative decoding w warunkach zbliżonych do produkcji. To nie jest kolejny akademicki eksperyment na małym zbiorze danych. To narzędzie, które zmienia sposób, w jaki branża myśli o przyspieszaniu wnioskowania LLM.

Speculative decoding zadomowił się w sercu współczesnych systemów obsługujących duże modele językowe, ale jego rzeczywista wydajność zależy od setek czynników — od semantyki wejścia, przez rozmiar batcha, aż po konfigurację sprzętu. Dotychczasowe benchmarki albo były zbyt wąskie, albo zbyt sztuczne. SPEED-Bench zmienia to fundamentalnie, oferując dwa niezależne zestawy danych i ujednolicony framework pomiarowy, który integruje się z produkcyjnymi silnikami wnioskowania takimi jak TensorRT-LLM, vLLM i SGLang. To nie jest teoretyczna gra — to narzędzie stworzone dla praktyków, którzy muszą wiedzieć, co faktycznie dzieje się w ich systemach.

Chaos w ocenie speculative decoding — jak to się zaczęło

Speculative decoding ma genialnie prostą ideę: zamiast czekać, aż model generuje jeden token na raz (co jest wąskim gardłem we wnikaniu), używamy lekkiego modelu pomocniczego do spekulacji kilku przyszłych tokenów naraz. Następnie główny model weryfikuje je równolegle. Jeśli spekulacja się powiedzie, wygrywamy na szybkości. Jeśli nie, cofamy się i kontynuujemy prawidłowo. Matematycznie jest to eleganckie — dokładnie zachowujemy rozkład wyjścia głównego modelu, a jednocześnie potencjalnie uzyskujemy znaczące przyspieszenie.

Problem pojawia się w momencie, gdy trzeba ocenić, jak dobrze to działa. Każda publikacja naukowa testowała to na innych danych, przy innych ustawieniach. Jeden zespół używał 100 promptów, inny 1000. Jeden testował krótkie sekwencje wejściowe (mniej niż 100 tokenów), inny pracował z kontekstem 32 tysiące tokenów. Batch size jeden, batch size 512 — kompletnie różne wyniki. Niektóre benchmarki używały losowych tokenów jako wejścia, co całkowicie zniekształcało rzeczywiste zachowanie. Rezultat? Artykuły publikowały przyspieszenia, które w praktyce się nie materializowały, a zespoły nie mogły porównać swoich algorytmów w sensowny sposób.

Dodatkowo większość istniejących benchmarków nie odzwierciedlała rzeczywistych warunków serwowania. W produkcji modele pracują z wysoką współbieżnością, długimi sekwencjami wejściowymi, różnymi domenami semantycznymi. Tymczasem akademickie benchmarki często testowały przy batch size jeden z krótkimi promptami. To jak testowanie samochodu sportowego w warunkach laboratoryjnych zamiast na autostradzie — wyniki mogą być całkowicie mylące.

Architektura SPEED-Bench — dwa zestawy danych dla dwóch problemów

SPEED-Bench rozwiązuje ten problem elegancko, oddzielając dwa zupełnie różne aspekty speculative decoding. Po pierwsze, jakość spekulacji — czyli jak dobrze model pomocniczy przewiduje przyszłe tokeny. Po drugie, rzeczywiste przyspieszenie systemu — czyli ile tokenów na sekundę możemy wygenerować w warunkach produkcji.

Pierwszy zestaw danych to Qualitative split. Jego celem jest zmierzenie dokładności spekulacji (tzw. acceptance rates i acceptance lengths) w szerokim spektrum domen semantycznych. Zespół NVIDIA zebrał dane z 18 publicznie dostępnych źródeł i podzielił je na 11 kategorii: Coding, Math, Humanities, STEM, Writing, Summarization, Roleplay, RAG, Multilingual, Reasoning i QA. Każda kategoria zawiera 80 próbek, łącznie 880 promptów.

Ale czekaj — to brzmi jak każdy inny benchmark, prawda? Nie do końca. Kluczowa innowacja tkwi w tym, jak wybierają próbki. Zamiast losowo brać próbki z każdej kategorii, SPEED-Bench używa algorytmu selekcji opartego na osadzeniach tekstu. Każdy kandydat jest konwertowany na wektor gęsty przy użyciu pretrenowanego embeddera (OpenAI text-embedding-3-small). Następnie algorytm minimalizuje średnią podobieństwo cosinusowe między próbkami w każdej kategorii. Innymi słowy, wybiera próbki, które są od siebie jak najbardziej różne semantycznie.

Dlaczego to ważne? Ponieważ ujawnia zachowanie zależne od domeny w speculative decoding. Domeny nisko-entropijne (Coding, Math) zachowują się zupełnie inaczej niż domeny wysoko-entropijne (Roleplay, Writing). Jeśli benchmark zawiera tylko podobne próbki z jednej kategorii, nigdy tego nie odkryjesz. Porównanie z poprzednim benchmarkiem (SpecBench) pokazuje, że SPEED-Bench osiąga średnio niższe podobieństwo semantyczne między próbkami — co oznacza lepsze pokrycie rzeczywistej różnorodności w każdej domenie.

Throughput split — symulacja rzeczywistych warunków serwowania

Drugi zestaw danych to Throughput split, i tutaj rzeczy stają się poważne. Qualitative split mierzy dokładność spekulacji, ale nic nie mówi nam o rzeczywistej wydajności systemu. W produkcji liczy się przede wszystkim: ile tokenów na sekundę możemy wygenerować (Output TPS) i jaka jest latencja dla pojedynczego użytkownika (User TPS).

Throughput split jest konstruowany z myślą o realistycznych warunkach serwowania. Zawiera buckety o stałych długościach sekwencji wejściowych (ISL) od 1k do 32k tokenów — to odzwierciedla rosnące znaczenie aplikacji długocontextowych takich jak asystenci kodowania czy retrieval-augmented generation. Dla każdego bucketu ISL prompty są zagregowane w trzy kategorie trudności odpowiadające domenom nisko-, mieszano- i wysoko-entropijnym. Każdy bucket zawiera 1536 promptów (512 na kategorię trudności), co daje wystarczającą objętość do skonstruowania stabilnych krzywych Pareto dla szerokiego zakresu batch size'ów — od 2 aż do 512.

To jest kluczowe, ponieważ w produkcji batch size drastycznie wpływa na to, czy wnioskowanie jest bound na obliczenia czy bound na pamięć. Przy małych batch size'ach GPU nie jest w pełni wykorzystany — to compute-bound. Przy dużych batch size'ach saturujemy przepustowość pamięci — to memory-bound. Speculative decoding ma zupełnie inny wpływ na wydajność w tych dwóch reżimach. SPEED-Bench to uwzględnia, testując rzeczywiste warianty batch size'ów.

Dodatkowo SPEED-Bench unika używania losowych tokenów do benchmarkingu throughput. Może się to wydawać szczegółem, ale zespół wykazał, że losowe tokeny drastycznie zniekształcają zachowanie akceptacji, routing w modelach MoE i pomiary throughput, prowadząc do zbyt optymistycznych wniosków. Prompty są zamiast tego obcinane lub padowane w kontrolowany sposób, zachowując ich semantyczną treść.

Ujednolicony framework pomiarowy — koniec z nieporównywalnością

Tutaj pojawia się kolejna, subtelna ale krytyczna kwestia: benchmarking speculative decoding na różnych silnikach wnioskowania. Różne silniki mogą stosować różne szablony chatu, obsługiwać tokeny BOS inaczej, czy tokenizować wejścia niekonsekwentnie. Te różnice mogą dyskretnie zmienić spekulowaną sekwencję, czyniąc porównania między silnikami zawodne.

SPEED-Bench wprowadza lekki framework pomiarowy, który obsługuje tokenizację i formatowanie promptu zewnętrznie. Silniki wnioskowania otrzymują wstępnie tokenizowane sekwencje, zapewniając, że wszystkie systemy przetwarzają identyczne wejścia. To izoluje efekty algorytmów speculative decoding i optymalizacji systemowych od artefaktów przetwarzania wstępnego.

Framework integruje się z produkcyjnymi silnikami: TensorRT-LLM, vLLM i SGLang. Przechwytuje szczegółowe informacje czasowe ze strumieniowych odpowiedzi, aby obliczyć: zachowanie akceptacji, latencję kroku, tokeny na sekundę na poziomie użytkownika i całkowity throughput. Przykład z rzeczywistego uruchomienia pokazuje, jak to wygląda w praktyce — uruchamiając Llama 3.3 70B Instruct jako model docelowy z EAGLE3 jako modelem pomocniczym na Qualitative split, używając TensorRT-LLM z batch size 32 na 8 GPU H100.

Output pokazuje dokładnie to, czego potrzebują praktykownicy: histogram długości akceptacji, warunkowe wskaźniki akceptacji dla każdego kroku, wyniki podzielone na kategorie, Output TPS, czasy end-to-end, TTFT (Time To First Token) i szczegółowe statystyki latencji. To jest informacja, którą można faktycznie wykorzystać do podejmowania decyzji inżynierskich.

Zachowanie zależne od domeny — gdzie speculative decoding błyska i gdzie się zawiesza

Wyniki z SPEED-Bench ujawniają fascynujący wzorzec: długość akceptacji w speculative decoding jest wysoce zależna od domeny. Domeny nisko-entropijne takie jak Coding i Math konsekwentnie osiągają wyższe wskaźniki akceptacji — model pomocniczy potrafi przewidywać przyszłe tokeny z większą pewnością. Domeny wysoko-entropijne takie jak Roleplay czy Writing pokazują niższe wskaźniki akceptacji.

To ma ogromne praktyczne znaczenie. Jeśli budujesz system obsługujący głównie kod, speculative decoding będzie dla ciebie grą zmieniającą zasady. Jeśli obsługujesz głównie twórcze pisanie, przyspieszenie będzie znacznie skromniejsze. Żaden z poprzednich benchmarków nie pokazywał tego tak jasno, ponieważ albo testowały zbyt mało danych, albo miały zbyt niską różnorodność semantyczną w obrębie kategorii.

Dodatkowo wyniki pokazują, że przyspieszenia zmieniają się drastycznie w zależności od batch size i długości sekwencji wejściowej. Przy małych batch size'ach i krótkich sekwencjach speculative decoding może oferować przyspieszenie 2-3x. Przy dużych batch size'ach i długich sekwencjach w reżimie memory-bound przyspieszenie może być znacznie skromniejsze — czasami zbliżające się do 1x. To znowu coś, co poprzednie benchmarki całkowicie pomieszały.

Implikacje dla polskich twórców i zespołów AI

Dla polskich zespołów pracujących nad modelami, optymalizacją wnioskowania czy systemami serwowania LLM SPEED-Bench ma konkretne znaczenie. Po pierwsze, daje standardowy punkt odniesienia do porównywania algorytmów speculative decoding. Jeśli publikujesz badania, możesz teraz używać SPEED-Bench zamiast tworzyć własny benchmark — to czyni pracę porównywalną z wysiłkami zespołów z całego świata.

Po drugie, benchmark ujawnia, że przyspieszenia są wysoce sytuacyjne. Jeśli budujesz system dla konkretnego przypadku użycia — coding assistant, system RAG, chatbot — musisz testować na danych reprezentatywnych dla tej domeny. SPEED-Bench to umożliwia. Zamiast polegać na ogólnych liczbach, możesz uruchomić SPEED-Bench na swoim sprzęcie, ze swoimi modelami, i zobaczyć dokładnie, jak speculative decoding wpływa na twoją konkretną aplikację.

Po trzecie, framework pomiarowy jest otwarty i zintegrowany z popularnymi silnikami. Jeśli używasz vLLM lub SGLang — a wiele polskich zespołów to robi — możesz natychmiast zacząć korzystać z SPEED-Bench bez dodatkowych prac integracyjnych.

Dlaczego to ma znaczenie dla przyszłości wnioskowania LLM

Speculative decoding to nie jest przejściowa optymalizacja. To fundamentalna technika, która będzie się pogłębiać w systemach obsługujących LLM w najbliższych latach. Ale jak każda technika, jej wartość zależy od tego, czy rzeczywiście wiemy, jak działa w praktyce. SPEED-Bench to pierwszy benchmark, który odpowiada na to pytanie w systematyczny, produkcyjny sposób.

Ustandaryzowanie benchmarkingu speculative decoding ma konsekwencje dla całej branży. Badacze będą mogli szybciej iterować, wiedząc, że ich wyniki są porównywalne. Inżynierowie będą mogli podejmować lepsze decyzje o wdrażaniu. Dostawcy sprzętu będą mogli optymalizować swoje silniki pod kątem speculative decoding, wiedząc dokładnie, jakie scenariusze są najważniejsze w produkcji.

W praktyce SPEED-Bench to zmiana w sposobie, w jaki branża myśli o przyspieszaniu wnioskowania. Zamiast ogólnych liczb i teoretycznych analizy, mamy teraz narzędzie do mierzenia rzeczywistych scenariuszy. To dokładnie to, czego branża potrzebowała, i to dokładnie to, co NVIDIA dostarczyła.