Speculative Decoding: o 20–50% szybsza inferencja LLM

Model o pojemności 70B generuje jeden token w jednym przepływie w przód (forward pass), a każdy przepływ ponownie ładuje wagi z pamięci VRAM, oblicza uwagę (attention) w całym kontekście i synchronizuje pamięć. W czasie między tokenami GPU pozostaje bezczynny, czekając na rozstrzygnięcie sekwencyjnych zależności.

Na procesorze H100 model 70B generuje jeden token co 30–50 ms. GPU posiada wystarczającą moc obliczeniową do przetwarzania wielu tokenów równolegle, ale sekwencyjna zależność temu przeszkadza – każdy token zależy od poprzedniego, co powoduje zatrzymanie potoku.

Dekodowanie spekulacyjne (speculative decoding) łamie to wąskie gardło, pozwalając na generowanie wielu tokenów w czasie, który normalnie zajmuje wygenerowanie jednego, bez zmiany rozkładu wyjściowego. Otrzymane tokeny są statystycznie identyczne z tymi, które uzyskałbyś przy standardowym dekodowaniu autoregresyjnym; jedyną różnicą jest szybkość ich uzyskania.

Ten przewodnik omawia mechanikę, dostępne warianty w roku 2026, kompromisy związane ze stopniem akceptacji oraz praktyczną konfigurację w llama.cpp, vLLM, SGLang i TensorRT-LLM.

Jak działa dekodowanie autoregresyjne (i dlaczego jest wolne)

Zanim zrozumiesz dekodowanie spekulacyjne, musisz zrozumieć ograniczenie autoregresyjne, które ono obejmuje. Standardowa generacja autoregresyjna przetwarza tokeny sekwencyjnie:

1. Uruchom przepływ w przód przez model z bieżącym kontekstem.
2. Wylosuj następny token z rozkładu wyjściowego.
3. Dodaj token do kontekstu.
4. Powtórz.

Każdy krok wymaga pełnego przepływu w przód – ładowania wag z VRAM, obliczania uwagi przez cały kontekst i wyprodukowania pojedynczego tokena. Dla modelu o 70 miliardach parametrów trwa to około 30–50 ms na token na procesorze H100. GPU ma zapas mocy obliczeniowej – mógłby przetwarzać więcej zadań równolegle – ale sekwencyjna zależność temu przeszkadza.

Luka między mocą obliczeniową a pamięcią VRAM

Nowoczesne GPU mają więcej FLOPów, niż potrzebują do generowania pojedynczego tokena, więc prawdziwą butelkową szyjką jest przepustowość pamięci – wagi muszą być przesyłane z VRAM do jednostek obliczeniowych przy każdym przepływie w przód. Generując jeden token na raz, GPU spędza większość czasu czekając na transfery pamięci, zamiast wykonywać przydatne obliczenia.

Dekodowanie spekulacyjne rozwiązuje to problem, dając GPU więcej pracy na jeden transfer pamięci. Zamiast jednego tokena na przepływ w przód, generuje ono K tokenów na przepływ w przód, rozkładając koszt pamięci na wiele wyjść.

Mechanizm Draft-Verify (Szkic-Weryfikacja)

Dekodowanie spekulacyjne działa w powtarzających się cyklach szkic-weryfikacja. Szybki mechanizm szkicu proponuje K kandydujących tokenów – z małego modelu szkicującego, wyszukiwania n-gramów lub głowicy predykcji dołączonej do modelu docelowego – a model docelowy weryfikuje wszystkie K w jednym przepływie w przód. Faza szkicowania jest tania, zazwyczaj stanowiąc 5–20% czasu przepływu w przód modelu docelowego, podczas gdy weryfikacja porównuje każdy zaszczycowany token z tym, co model docelowy wygenerowałby, akceptując najdłuższy pasujący prefiks i ponownie losując od pierwszego odrzucenia.

Weryfikacja K tokenów kosztuje mniej więcej tyle samo co generowanie jednego tokena autoregresyjnie, więc gdy szkic jest poprawny, otrzymujesz K tokenów za cenę jednego kroku weryfikacji.

Konkretne przykłady

Załóżmy, że model szkicowy proponuje 5 tokenów: ["I", " like", " cooking", " and", " traveling"]. Model docelowy weryfikuje je w jednym przepływie w przód:

Model docelowy akceptuje tokeny 1 i 2, a następnie generuje " playing" dla tokena 3, produkując trzy tokeny w jednym cyklu zamiast trzech osobnych przepływów w przód. Gdyby szkic był poprawny aż do tokena 5, otrzymałbyś pięć tokenów za koszt jednej weryfikacji – 5-krotne przyspieszenie w samym tym cyklu.

Wąskie gardło weryfikacji

W praktyce weryfikacja dominuje czas wykonania – 42–95% cyklu, w zależności od metody i rozmiaru modelu. Przepływ w przód modelu docelowego jest butelkową szyjką, a odrzucone tokeny reprezentują zmarnowane obliczenia.

Dlatego stopień akceptacji ma tak duże znaczenie. Każdy odrzucony token po pierwszym to zmarnowana praca weryfikacyjna. Najlepsze metody dekodowania spekulacyjnego maksymalizują oczekiwane liczby zaakceptowanych tokenów na cykl, a nie tylko surowy stopień akceptacji.

Matematyczne gwarancje

Jedną z najważniejszych właściwości dekodowania spekulacyjnego jest to, że generuje tokeny z dokładnie tego samego rozkładu co standardowe próbkowanie autoregresyjne z modelu docelowego. Krok weryfikacji używa próbkowania odrzuceniowego – gdy szkic proponuje token x, model docelowy oblicza swoją własną prawdopodobieństwo p(x), a szkic oblicza p_draft(x). Prawdopodobieństwo akceptacji to:

min(1, p(x) / p_draft(x))

Gdy model docelowy się zgadza (p(x) ≥ p_draft(x)), token jest zawsze akceptowany. Gdy model docelowy się nie zgadza, token jest akceptowany z prawdopodobieństwem proporcjonalnym do stosunku, a odrzucone tokeny są ponownie losowane z rozkładu residualnego:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

Ta procedura gwarantuje, że sekwencja wyjściowa śledzi dokładnie rozkład modelu docelowego, dlatego dekodowanie spekulacyjne jest bezstratne. Model szkicowy wpływa na szybkość, nie na jakość – tokeny, które otrzymujesz, są statystycznie nierozróżnialne od standardowego dekodowania, z tym samym perplexity i rozkładem. Jedyną różnicą jest opóźnienie.

Strategie modeli szkicowych

Mechanizm szkicujący jest zmienną, która ma największe znaczenie. Różne podejścia mają różne kompromisy między złożonością konfiguracji, stopniem akceptacji a przyspieszeniem.

Samodzielne modele szkicowe

Najprostszym podejściem jest załadowanie mniejszego modelu obok modelu docelowego – zazwyczaj modelu 1B-3B szkicującego dla modelu docelowego 7B-70B.

Zalety:

• Prosta koncepcja
• Działa z dowolnym modelem docelowym
• Model szkicowy może być dostosowany do dopasowania rozkładu docelowego

Wady:

• Wymaga załadowania drugiego modelu do VRAM (1-4 GB w zależności od rozmiaru)
• Jakość modelu szkicowego bezpośrednio determinuje stopień akceptacji
• Szkice międzyrodzinne (np. Qwen szkicujący dla Llama) zazwyczaj działają słabo

Kciukowa zasada: Używaj modeli z tej samej rodziny. Gemma 2 2B dobrze szkicuje dla Gemmy 2 27B. Llama 3.2 1B dobrze szkicuje dla Llama 3.1 70B. Szkice międzyrodzinne mają tendencję do niskich stopni akceptacji, ponieważ rozkłady tokenów odbiegają od siebie.

Znajdowanie kompatybilnych modeli szkicowych

Nie wszystkie małe modele działają jako modele szkicowe dla danego celu. Kluczowym czynnikiem jest wyrównanie rozkładu – jak blisko prawdopodobieństwa wyjściowe modelu szkicowego pasują do modelu docelowego.

Złota zasada: jeśli stopień akceptacji modelu szkicowego spadnie poniżej 50%, dekodowanie spekulacyjne może w rzeczywistości Cię spowolnić. Nadmiar uruchamiania modelu szkicowego plus weryfikacji przewyższa korzyść, gdy większość propozycji jest odrzucana.

EAGLE i EAGLE-3: Głowice predykcji

EAGLE (Efektowna Architektura Przewodząca Szacowaniu Modelu Językowego) eliminuje potrzebę osobnego modelu szkicowego. Zamiast tego dołącza lekkie autoregresyjne głowice predykcji do wewnętrznych warstw modelu docelowego.

Jak działa EAGLE

EAGLE trenuje głowice predykcji, które pobierają ukryte stany z pośrednich warstw modelu docelowego i przewidują przyszłe tokeny. Podczas wnioskowania:

1. Model docelowy uruchamia przepływ w przód przez swoje warstwy.
2. Na każdej warstwie głowica EAGLE odczytuje ukryty stan i proponuje tokeny dla przyszłych pozycji.
3. Wiele głowic działa równolegle, każda przewidująca inny czas krokowy.
4. Model docelowy weryfikuje wszystkie propozycje w jednym przepływie.

Zaleta: Głowice EAGLE są trenowane specjalnie pod kątem dopasowania rozkładu modelu docelowego. Widzą one bezpośrednio wewnętrzne reprezentacje docelu, co daje im znacznie lepsze wyrównanie niż samodzielny model szkicowy.

Usprawnienia EAGLE-3

EAGLE-3 (2025) udoskonala podejście o trzy kluczowe zmiany:

1. Wybór warstw: Zamiast dołączać głowice do każdej warstwy, EAGLE-3 używa optymalizacji bayesowskiej do wybrania optymalnej warstwy wyjściowej, zmniejszając nadmiarowość.
2. Predykcja wielotokenowa: Każda głowica przewiduje wiele tokenów jednocześnie, zwiększając głębokość szkicu bez proporcjonalnego kosztu obliczeniowego.
3. Efektywność trenowania: EAGLE-3 trenuje się na własnych danych generacyjnych modelu docelowego, poprawiając stopnie akceptacji w obciążeniach w rozkładzie.

Stopnie akceptacji: EAGLE-3 zazwyczaj osiąga 60–80% stopni akceptacji w obciążeniach w rozkładzie, w porównaniu do 40–60% dla samodzielnych modeli szkicowych. W obciążeniach generowania kodu z wysoką powtarzalnością akceptacja może przekraczać 85%.

Konfiguracja: EAGLE-3 wymaga wstępnie wytrenowanych głowic dla Twojego modelu docelowego. NVIDIA dostarcza głowice EAGLE-3 dla kilku popularnych modeli przez TensorRT-LLM i kolekcję Modułów Dekodowania Spekulacyjnego na HuggingFace. Istnieją implementacje stron trzecich dla vLLM i SGLang.

P-EAGLE: Równoległe szkicowanie (Marzec 2026)

Głównym ograniczeniem EAGLE-3 jest autoregresyjne szkicowanie – każdy token szkicowy zależy od poprzedniego, więc generowanie K tokenów szkicowych wymaga K sekwencyjnych przepływów w przód przez głowicę szkicującą, a nadmiarowość szkicu rośnie liniowo z K. P-EAGLE usuwa ten limit, generując wszystkie K tokenów szkicowych w jednym przepływie w przód przez lekką 4-warstwową drafterkę trenowaną do przewidywania do 10 tokenów równolegle.

Efekt: P-EAGLE dostarcza do 1,69-krotnego przyspieszenia w stosunku do waniliowego EAGLE-3 w rzeczywistych obciążeniach na NVIDIA B200. Zaleta poszerza się przy wyższych wartościach K – tam gdzie sekwencyjne szkicowanie EAGLE-3 staje się butelkową szyjką, równoległe szkicowanie P-EAGLE nie incuruje dodatkowego kosztu.

Konfiguracja w vLLM: Pobierz wstępnie wytrenowaną głowicę P-EAGLE z HuggingFace, ustaw "parallel_drafting": true w konfiguracji vLLM i użyj tej samej flagi --speculative-model – vLLM zajmie się resztą. P-EAGLE jest obecnie stanem sztaty dla dekodowania spekulacyjnego opartego na EAGLE, i jeśli wdrażasz EAGLE w 2026 roku, P-EAGLE to wariant do użycia.

Dekodowanie spekulacyjne n-gramów

Dekodowanie spekulacyjne n-gramów zastępuje neuronowy szkic dopasowaniem wzorców do historii promptu. Algorytm szuka powtarzających się sekwencji n-gramów w kontekście, a gdy bieżąca sekwencja tokenów pasuje do wcześniej widzianego wzorca, proponuje tokeny, które wcześniej nastąpiły po tym wzorcu – na przykład, jeśli model już wygenerował def calculate_total(items): i ponownie napotka def calculate_total(, wie, że następne tokeny prawdopodobnie będą items): na podstawie poprzedniego wystąpienia.

Warianty mapy n-gram (ngram-map-k, ngram-map-k4v) używają tablic hashowych do szybszego wyszukiwania zamiast liniowego skanowania, z kluczem hash jako bieżącym n-gramem rozmiaru N i wartością jako sekwencją tokenów, która nastąpiła.

Zalety:

• Zero nadmiarowości VRAM – brak dodatkowego modelu do załadowania (~16 MB dla tablicy hashowej)
• Ekstremalnie szybkie dla powtarzalnych obciążeń (edycja kodu, refaktoryzacja, generowanie szablonów)
• Stopnie akceptacji mogą osiągnąć 90%+ w obciążeniach z wysoką samopodobieństwem

Wady:

• Bezprzydatne dla nowej generacji – jeśli wzorzec nie pojawił się wcześniej, n-gram nie ma nic do zaproponowania
• Stopień akceptacji spada do blisko zera w kreatywnych lub zróżnicowanych obciążeniach
• Ograniczona głębokość szkicu (zazwyczaj 2-4 tokeny na dopasowanie)

Najlepsze dla: Refaktoryzacji kodu, wypełniania szablonów, powtarzalnej dokumentacji i każdego obciążenia, gdzie model odwiedza podobne wzorce. Najgorsze dla: pisania kreatywnego, otwartego czatu i zadań rozumowania.

Dostrojanie parametrów

Parametry n-gramów mają większe znaczenie, niż by się mogło wydawać. Domyślne wartości działają dla kodu, ale obciążenia tekstowe wymagają dostosowania:

Dla obciążeń tekstowych zmniejsz size-n do 8–10 i zwiększ min-hits do 2. To zamienia częstotliwość dopasowań na wyższe stopnie akceptacji na dopasowanie.

Samodekodowanie spekulacyjne

Samodekodowanie spekulacyjne (nazywane również LayerSkip lub sam-spekulacją) używa własnych częściowych obliczeń modelu jako szkicu, więc nie jest potrzebny osobny model.

Jak to działa

Zamiast uruchamiać pełny model dla każdego tokena, samodekodowanie spekulacyjne uruchamia skróconą wersję – pomijając niektóre warstwy transformerów – aby tanio generować tokeny szkicowe, a pełny model następnie weryfikuje propozycje.

Na przykład, model 32-warstwowy może uruchamiać się tylko z 16 warstwami do szkicowania, a następnie weryfikować z wszystkimi 32 warstwami. Skrócony przepływ w przód jest szybszy, ponieważ przetwarza mniej warstw, a tokeny szkicowe korzystają z widzenia tych samych początkowych warstw co docelowe.

Zalety:

• Brak dodatkowych wag modelu do załadowania
• Naturalnie wyrównane z rozkładem docelowym (ta sama architektura, częściowe warstwy)
• Działa dobrze dla modeli z znaczną redundancją w głębszych warstwach

Wady:

• Wymaga modyfikacji silnika wnioskowania w celu wsparcia częściowych przepływów w przód
• Kompilacje pamięci KV – szkic używa częściowej pamięci KV, która musi zostać pogodzona z pamięcią pełnego modelu
• Stopnie akceptacji są zazwyczaj niższe niż EAGLE lub dobrze dostrojone modele szkicowe

Implementacja llama.cpp: PR #18471 wprowadził samodekodowanie spekulacyjne używając historii kontekstu jako szkicu. Model ponownie używa tokenów ze swojej własnej historii generowania do proponowania kontynuacji, szczególnie skuteczne dla obciążeń kodowania, gdzie wzorce powtarzają się w tym samym oknie kontekstu.

MTP (Predykcja wielotokenowa)

MTP jest specjalizowaną formą dekodowania spekulacyjnego wbudowaną bezpośrednio w określone punkty kontrolne modeli. Qwen 3.6 dostarcza zarówno standardowe, jak i warianty GGUF z włączonym MTP.

Jak się różni: Głowice MTP są wbudowane w architekturę modelu podczas trenowania. Model niesie dodatkowe głowice predykcji, które proponują wiele przyszłych tokenów w jednym przepływie w przód. Nie ma osobnego modelu szkicowego – głowice MTP są częścią samego modelu docelowego.

Kompromisy:

• Brak modelu szkicowego do zarządzania – MTP jest aktywowany przez --spec-type draft-mtp --spec-draft-n-max N
• Głowice MTP dodają ~1-2 GB nadmiarowości VRAM
• Działa najlepiej w architekturach MoE (Qwen 3.6 35B-A3B), gdzie rozproszone routowanie utrzymuje głowice MTP tanimi

Szczegółowe benchmarki MTP vs standardowego dekodowania dla Qwen 3.6 27B i 35B, zobacz Qwen 3.6 MTP vs Standard na GPU 16GB.

Stopnie akceptacji: Co oznaczają w praktyce

Stopień akceptacji (α) jest jedynym najważniejszym metryką wydajności dekodowania spekulacyjnego. Określa, czy uzyskujesz przyspieszenie, czy płacisz nadmiarowość.

Wzór na przyspieszenie

Oczekiwana liczba zaakceptowanych tokenów na przepływ weryfikacji:

E[accepted] = α × K

Gdzie K to liczba tokenów szkicowych proponowanych na cykl. Jeśli α = 0,7 i K = 5, akceptujesz 3,5 tokena na przepływ – 3,5-krotne przyspieszenie w stosunku do standardowego dekodowania (które produkuje 1 token na przepływ).

Stopień akceptacji według metody

Gdy stopień akceptacji spada

Stopień akceptacji nie jest stały przez całą generację. Zmienia się w zależności od:

• Pozycji tokena: Wczesne tokeny mają tendencję do wyższej akceptacji (więcej kontekstu, mniej niepewności). Późniejsze tokeny spadają, gdy model eksploruje bardziej zróżnicowane kontynuacje.
• Typu obciążenia: Edycja kodu z powtarzanymi wzorcami widzi α > 80%. Otwarte pisanie kreatywne widzi α < 40%.
• Temperatury: Wyższa temperatura zwiększa rozbieżność między szkicem a celem, obniżając akceptację. Dekodowanie spekulacyjne działa najlepiej przy niskiej temperaturze (0,0–0,7).

Krytyczny próg: Jeśli Twój efektywny stopień akceptacji (α × K) spadnie poniżej 1,0, dekodowanie spekulacyjne jest wolniejsze niż standardowe dekodowanie. Nadmiarowość szkicu plus czas weryfikacji przewyższa koszt pojedynczego kroku autoregresyjnego.

Dekodowanie spekulacyjne w produkcji: Co naprawdę się dzieje

Artykuły badawcze raportują 2–4-krotne przyspieszenie, ale benchmarki produkcyjne opowiadają bardziej odcienioną historię – przyspieszenia kurczą się wraz z rozmiarem partii, weryfikacja dominuje czas cyklu, a żadna pojedyncza metoda nie wygrywa w każdym obciążeniu.

Wyniki SpecDecode-Bench (2026)

Systematyczna ocena pięciu wariantów SD (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) w vLLM przez cztery modele i sześć obciążeń ujawniła:

1. SD działa, ale przyspieszenia kurczą się wraz z rozmiarem partii. Przy rozmiarze partii 1, EAGLE osiąga do 1,96x na Llama-3-70B. Przy rozmiarze partii 128 spada to do 1,21x. System staje się ograniczony mocą obliczeniową przy wysokiej konkurencji, a GPU ma mniej bezczynnej pojemności do udzielenia spekulacji.

2. Weryfikacja dominuje czas wykonania (42–95%). Przepływ w przód modelu docelowego jest butelkową szyjką. Redukcja zmarnowanej weryfikacji na odrzuconych tokenach jest najbardziej obiecującą ścieżką poprawy.

3. Żadna pojedyncza metoda nie wygrywa wszędzie. EAGLE-3 jest najlepszym wyborem ogólnym. Metody modelu szkicowego exczelują, gdy model docelowy jest duży (70B+). n-gram jest optymalny do edycji kodu i zadań o wysokim nakładzie.

4. Analiza Oracle ujawnia lukę. Teoretyczna górna granica dla kombinowanych strategii n-gram + EAGLE osiąga ~4,9x w obciążeniach edycji kodu, ale obecne implementacje osiągają 2–3x. Jest miejsce na optymalizację.

Praktyczne oczekiwania dotyczące przyspieszenia

Efekt rozmiaru partii jest krytyczny. Przy małych partiach GPU ma bezczynną moc obliczeniową do udzielenia spekulacji. Przy dużych partiach system jest już nasycony, a dekodowanie spekulacyjne dodaje nadmiarowość bez proporcjonalnej korzyści.

Monitorowanie w produkcji

Powinieneś śledzić stopień akceptacji w produkcji. Spadający stopień akceptacji sygnalizuje, że Twój model szkicowy odbiega od docelowego – albo dlatego, że obciążenie się zmieniło, albo dlatego, że model szkicowy potrzebuje ponownego trenowania.

Kluczowe metryki do monitorowania:

• Stopień akceptacji na żądanie (powinien być stabilny wokół Twojej linii bazowej)
• Tokeny na sekundę z i bez dekodowania spekulacyjnego (rzeczywiste przyspieszenie)
• Czas weryfikacji jako procent czasu cyklu (powinien wynosić 42–95%)
• Czas przepływu w przód modelu szkicowego (powinien być < 20% czasu modelu docelowego)

Jeśli Twój stopień akceptacji spadnie poniżej 40%, wyłącz dekodowanie spekulacyjne dla tego żądania. Nadmiarowość nie jest warta tego.

Praktyczna konfiguracja

Wybór silnika ma tak samo duże znaczenie jak strategia szkicu – zobacz Ollama vs vLLM vs LM Studio i inne środowiska lokalne jak każde środowisko obsługuje partycjonowanie, kompatybilność API i przepustowość, zanim wybrałeś ścieżkę dekodowania spekulacyjnego.

llama.cpp

Dla ogólnego setupu serwera i ładowania GGUF, zacznij od szybkiego startu llama.cpp; poniższe flagi dodają dekodowanie spekulacyjne na wierzch.

llama.cpp obsługuje wiele metod dekodowania spekulacyjnego przez flagę --spec-type:

# Model szkicowy (samodzielny)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Obowiązkowe: --parallel 1 dla dekodowania spekulacyjnego

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (dostrojenie obciążeń tekstowych)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Sam-spekulacja (obciążenia kodowania)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Kluczowe flagi:

• --parallel 1 – Dekodowanie spekulacyjne w llama.cpp wymaga trybu pojedynczej partii. To jest obecne ograniczenie.
• --spec-draft-n-max – Liczba tokenów szkicowych na cykl. Zacznij od 3–5; wyższe wartości zwiększają presję VRAM.
• --spec-ngram-simple-size-n – Długość wyszukiwania n-gram. Domyślne 12 działa dobrze dla kodu; zmniejsz do 8 dla tekstu.

Typowe pułapki:

• Zapominanie --parallel 1 – serwer cicho zignoruje dekodowanie spekulacyjne.
• Używanie modeli szkicowych międzyrodzinnych – stopnie akceptacji się załamują, negując każde przyspieszenie.
• Ustawianie --spec-draft-n-max zbyt wysoko – każdy dodatkowy token szkicowy kosztuje VRAM dla bufora szkicu. Opadające zyski zaczynają się około 5–8.

vLLM

Szybki start vLLM pokrywa podstawowe wdrożenie; poniższe flagi włączają dekodowanie spekulacyjne na istniejącym serwerze vLLM.

vLLM obsługuje dekodowanie spekulacyjne przez flagi --speculative-model i --speculative-num-steps:

# Model szkicowy
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (równoległe szkicowanie)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

Dekodowanie spekulacyjne vLLM jest zintegrowane z ciągłym partycjonowaniem, więc działa w obciążeniach konkurencyjnych. Kierownik obsługuje wiele slotów tokenów w jednym przepływie w przód, a menedżer pamięci obsługuje pamięć KV dla obu modeli szkicowych i docelowych.

SGLang

SGLang obsługuje dekodowanie spekulacyjne przez flagę --speculative-algorithm:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

Architektura RadixAttention SGLang dobrze komponuje się z dekodowaniem spekulacyjnym, ponieważ cache prefiksów redukuje koszt weryfikacji – model docelowy ponownie używa zcache’owanej uwagi dla wspólnych prefiksów, czyniąc każdy przepływ weryfikacji tańszym niż zimny przepływ w przód.

TensorRT-LLM

TensorRT-LLM dostarcza produkcyjnego dekodowania spekulacyjnego z Triton Inference Server. Konfiguracja jest bardziej zaangażowana, ale oferuje najlepszą wydajność na sprzęcie NVIDIA:

1. Zbuduj silnik TensorRT dla obu modeli docelowych i szkicowych.
2. Skonfiguruj repozytorium modeli z model.yaml określającym konfigurację dekodowania spekulacyjnego.
3. Uruchom Triton z backendem API LLM / PyTorch.

TensorRT-LLM obsługuje zarówno warianty modelu szkicowego, jak i EAGLE-3. Dla obciążeń generowania kodu, TensorRT-LLM z dekodowaniem spekulacyjnym n-gramów zademonstrował 2–3-krotną redukcję opóźnienia w wdrożeniach produkcyjnych.

Kiedy używać dekodowania spekulacyjnego

Używaj, gdy

• Duże modele docelowe (7B+): Nadmiarowość mechanizmu szkicowego jest rozłożona na obliczenia docelu. Dekodowanie spekulacyjne błyszczy, gdy model docelowy jest wolny – im większy docel, tym cenniejsze przyspieszenie.
• Obciążenia niskiej temperatury: Dekodowanie spekulacyjne działa najlepiej przy temperaturze 0,0–0,7, gdzie rozkład modelu docelowego jest skonsolidowany, a szkic ma lepszą szansę na dopasowanie.
• Aplikacje interaktywne: Obciążenia wrażliwe na opóźnienia (chat, uzupełnianie kodu, wywołania narzędzi agenta) korzystają najbardziej. Przetwarzanie partii, gdzie już nasycajesz GPU, widzi mniejszą korzyść.
• Generowanie i edycja kodu: Wysoka powtarzalność wzorców kodu czyni dekodowanie spekulacyjne n-gramów i sam-spekulacyjne szczególnie skutecznym.

Pomiń, gdy

• Małe modele docelowe (< 3B): Nadmiarowość modelu szkicowego zbliża się do czasu przepływu w przód docelu. Przyspieszenie jest marginalne lub ujemne.
• Próbkowanie wysokiej temperatury: Przy temperaturze > 0,7 rozkład modelu docelowego jest zbyt szeroki, aby szkic mógł niezawodnie dopasować.
• Pisanie kreatywne i otwarta generacja: Niskie stopnie akceptacji na nowej zawartości czynią nadmiarowość nie warta tego.
• Duże rozmiary partii (> 32): System staje się ograniczony mocą obliczeniową, a dekodowanie spekulacyjne dodaje nadmiarowość bez proporcjonalnej korzyści. SpecDecode-Bench pokazuje, jak przyspieszenie spada z 1,96x do 1,21x wraz ze wzrostem rozmiaru partii z 1 do 128.

Łączenie metod

Zaawansowane konfiguracje łączą wiele strategii dekodowania spekulacyjnego. Analiza Oracle SpecDecode-Bench pokazała, że adaptacyjne łączenie n-gramów i EAGLE może pchnąć przyspieszenie do 4,9x w obciążeniach edycji kodu.

Pomysł polega na używaniu n-gramów dla wzorców, które już się pojawiły, gdzie akceptacja jest wysoka, a nadmiarowość bliska zera, i cofaniu się do EAGLE dla nowych tokenów. W praktyce wymaga to wsparcia silnika dla wielometodowej spekulacji – vLLM i TensorRT-LLM mają eksperymentalne wsparcie, ale implementacje produkcyjne nadal dojrzewają.

Na razie, najbardziej praktyczną kombinacją jest MTP + n-gram w llama.cpp. MTP obsługuje neuronową spekulację, podczas gdy n-gram łapie powtarzalne wzorce, które MTP przegapi. Na Qwen 3 27B ta kombinacja osiąga 120 tokenów/sek w porównaniu do 67 tokenów/sek standardowo – 1,8-krotne przyspieszenie.

Rozważania kosztowe

Dekodowanie spekulacyjne zamienia obliczenia na opóźnienie. Całkowite obliczenia na token są mniej więcej takie same – po prostu robisz więcej pracy równolegle zamiast sekwencyjnie.

Wpływ na koszt GPU:

• Opóźnienie pojedynczego żądania poprawia się o 20–50%, co ma znaczenie dla aplikacji interaktywnych.
• Przepustowość (tokeny/sek przez wiele żądań) poprawia się mniej – GPU jest już nasycone przy dużych rozmiarach partii.
• Użycie VRAM zwiększa się o ślad modelu szkicowego (1–4 GB dla samodzielnych szkiców, minimalne dla n-gram/EAGLE).

Wnioskowanie w chmurze: Przy $2–4/godzinę za H100, dekodowanie spekulacyjne redukuje opóźnienie na żądanie bez zwiększania kosztu na token. Dla przetwarzania partii, gdzie już nasycajesz GPU, korzyść kosztowa jest minimalna – płacisz za ten sam czas GPU w każdym przypadku.

Gdy dekodowanie spekulacyjne oszczędza pieniądze: Aplikacje interaktywne, gdzie ładujesz za żądanie i chcesz zredukować czas do pierwszego tokena. 2-krotne przyspieszenie oznacza, że Twoi użytkownicy czekają o połowę krócej, a możesz obsługiwać więcej żądań na sekundę na tym samym sprzęcie.

Gdy nie: Przetwarzanie partii, gdzie już maksymalizujesz wykorzystanie GPU. Dodatkowe obliczenia z dekodowania spekulacyjnego nie zwiększają przepustowości – tylko zmieniają profil opóźnienia.

Co dalej

Dekodowanie spekulacyjne dojrzewa z nowości badawczej do standardu produkcyjnego. Przód popycha poza obecne ograniczenia:

• Spekulacja Spekulacyjna (SSD): Równolegli etapy szkicowania i weryfikacji przez oddzielny sprzęt. Model szkicowy działa asynchronicznie, wstępnie spekulując dla wielu prawdopodobnych wyników weryfikacji. Wczesne wyniki pokazują do 2-krotnego przyspieszenia w stosunku do zoptymalizowanego dekodowania spekulacyjnego i 5-krotnego w stosunku do dekodowania autoregresyjnego. Jeszcze nie gotowe do produkcji, ale kierunek jest jasny.

• SpecSA (Rzadka Spekulacyjna Weryfikacja): Łączy dekodowanie spekulacyjne z dynamiczną rzadką uwagą. Przekształca rzadką uwagę w obciążenie zorientowane na weryfikację, osiągając do 3,49-krotnego przepływu końcowego w stosunku do rzadkiego dekodowania autoregresyjnego. Istotne dla modeli długiego kontekstu, gdzie rzadka uwaga jest już w użyciu.

• Adaptacyjna spekulacja: Automatyczne przełączanie między metodami n-gram, EAGLE i modelu szkicowego w zależności od charakterystyki obciążenia. Analiza Oracle pokazuje значny niewykorzystany potencjał – obecne implementacje osiągają 2–3x, ale teoretyczna granica to 4,9x.

• Wielomodalne dekodowanie spekulacyjne: Rozszerzanie szkic-weryfikacja na modele językowe wizyjne i generowanie wideo. Wczesne przeglądy pokazują, że te same zasady obowiązują, ale strategie weryfikacji potrzebują adaptacji dla modalności nietekstowych.

Rama decyzyjna