Spekulacyjne dekodowanie: 20–50% szybsza inferencja modeli LLM

Model o 70 mld parametrów generuje jeden token w jednym przebiegu przodowym (forward pass), przy czym każda taka operacja powoduje ponowne wczytywanie wag z pamięci VRAM, obliczanie mechanizmu uwagi na całym kontekście oraz synchronizację pamięci. W odstępach między tokenami GPU pozostaje nieczynne, czekając na wyznaczenie zależności sekwencyjnych.

Na procesorze graficznym H100 model o 70 mld parametrów produkuje jeden token co 30–50 ms. GPU ma wystarczającą moc obliczeniową, aby przetwarzać wiele tokenów równolegle, ale sekwencyjna zależność na to nie pozwala — każdy token zależy od poprzedniego, co powoduje zatrzymanie pipeline’u.

Dekodowanie spekulacyjne przełamuje tę barierę, pozwalając wygenerować wiele tokenów w czasie, w którym normalnie generowany jest tylko jeden, bez zmiany rozkładu wyjściowego. Uzyskane tokeny są statystycznie identyczne z tymi, które dałoby standardowe dekodowanie autoregresywne; jedyną różnicą jest szybkość ich otrzymania.

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

Jak działa dekodowanie autoregresywne (i dlaczego jest powolne)

Przed zrozumieniem dekodowania spekulacyjnego należy zrozumieć ograniczenie autoregresywne, które ono omija. Standardowe generowanie autoregresywne przetwarza tokeny sekwencyjnie:

1. Uruchomienie przebiegu przodowego przez model z bieżącym kontekstem.
2. Dobór kolejnego tokena z rozkładu wyjściowego.
3. Dodanie tokena do kontekstu.
4. Powtórzenie procesu.

Każdy krok wymaga pełnego przebiegu przodowego — wczytania wag z VRAM, obliczenia uwagi na całym kontekście i wygenerowania pojedynczego tokena. Dla modelu o 70 mld parametrów zajmuje to około 30–50 ms na token na karcie H100. GPU ma zapas mocy obliczeniowej — mogłoby przetwarzać więcej zadań równolegle — ale sekwencyjna zależność na to nie pozwala.

Różnica między mocą obliczeniową a pamięcią VRAM

Nowoczesne GPU mają więcej FLOPSów (operacji na liczbach zmiennoprzecinkowych na sekundę), niż potrzebują do generowania pojedynczego tokena, dlatego rzeczywistą wąskim gardłem jest przepustowość pamięci — wagi muszą być transmitowane z VRAM do jednostek obliczeniowych przy każdym przebiegu przodowym. Przy generowaniu po jednym tokenie na raz GPU spędza większość czasu na czekaniu na transfery pamięci, zamiast wykonywać użyteczne obliczenia.

Dekodowanie spekulacyjne rozwiązuje ten problem, dając GPU więcej pracy na każdy transfer pamięci. Zamiast jednego tokena na przebieg przodowy, generuje K tokenów na przebieg, rozkładając koszt pamięci na wiele wyjść.

Mechanizm draft-verify (szkic-wniosek)

Dekodowanie spekulacyjne działa w powtarzających się cyklach typu szkic-wniosek (draft-verify). Szybki mechanizm szkicujący proponuje K kandydackich tokenów — z małego modelu szkicującego, z wyszukiwania n-gramów lub z głowicy predykcyjnej przyłączonej do modelu docelowego — a model docelowy weryfikuje je wszystkie w jednym przebiegu przodowym. Faza szkicu jest tania, zwykle stanowiąc 5–20% czasu przebiegu przodowego modelu docelowego, podczas gdy weryfikacja porównuje każdy zaszczycowany token z tym, co wygenerowałby model docelowy, akceptując najdłuższy pasujący prefiks i pobierając nowe próbki od pierwszego odrzucenia.

Weryfikacja K tokenów kosztuje mniej więcej tyle co wygenerowanie jednego tokena autoregresywnie, więc gdy szkic jest poprawny, uzyskujemy K tokenów za cenę jednej kroku weryfikacji.

Konkretny przykład

Załóżmy, że model szkicujący proponuje 5 tokenów: ["I", " like", " cooking", " and", " traveling"]. Model docelowy weryfikuje je w jednym przebiegu przodowym:

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 przebiegów przodowych. Gdyby szkic był poprawny do tokena 5, uzyskalibyśmy pięć tokenów za cenę jednej weryfikacji — przyspieszenie 5-krotne w samym tylko tym cyklu.

Butelkowa szyja weryfikacji

W praktyce weryfikacja dominuje czas wykonania — od 42 do 95% cyklu, w zależności od metody i rozmiaru modelu. Przebieg przodowy modelu docelowego jest wąskim gardłem, a odrzucone tokeny oznaczają zmarnowane obliczenia.

Dlatego stopień akceptacji ma tak duże znaczenie. Każdy odrzucony token po pierwszym to marnotrawstwo pracy weryfikacyjnej. Najlepsze metody dekodowania spekulacyjnego maksymalizują oczekiwaną liczbę zaakceptowanych tokenów na cykl, a nie tylko surowy stopień akceptacji.

Gwarancja matematyczna

Jedną z najważniejszych właściwości dekodowania spekulacyjnego jest to, że generuje on tokeny z dokładnie tego samego rozkładu co standardowe próbkowanie autoregresywne z modelu docelowego. Krok weryfikacji wykorzystuje próbkowanie odrzuceniowe (rejection sampling) — gdy szkic proponuje token x, model docelowy wylicza swoją własną prawdopodobieństwo p(x), a szkic wylicza p_draft(x). Prawdopodobieństwo akceptacji wynosi:

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

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

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 bestratne (lossless). Model szkicujący wpływa na prędkość, a nie na jakość — otrzymane tokeny są statystycznie nierozróżnialne od standardowego dekodowania, z tym samym perypleksem i rozkładem. Jedyną różnicą jest latencja.

Strategie modeli szkicujących (Draft Model Strategies)

Mechanizm szkicujący to zmienna o największym znaczeniu. Różne podejścia mają różne kompromisy między złożonością konfiguracji, stopniem akceptacji a przyspieszeniem.

Autonomiczne modele szkicujące

Najprostsze podejście ładuje mniejszy model obok modelu docelowego — typowo model 1B–3B szkicujący dla modelu docelowego 7B–70B.

Zalety:

• Intuicyjnie proste koncepcyjnie
• Działa z dowolnym modelem docelowym
• Model szkicujący można dostroić, aby dopasować się do rozkładu modelu docelowego

Wady:

• Wymaga załadowania drugiego modelu do pamięci VRAM (1–4 GB w zależności od rozmiaru)
• Jakość modelu szkicującego bezpośrednio determinuje stopień akceptacji
• Szkicowanie międzyrodzinne (np. Qwen szkicujący dla Llama) zwykle daje słabe wyniki

Zasada kciukowa: Używaj modeli z tej samej rodziny. Gemma 2 2B dobrze szkicuje dla Gemma 2 27B. Llama 3.2 1B dobrze szkicuje dla Llama 3.1 70B. Szkicowanie międzyrodzinne tenduje do niskiego stopnia akceptacji, ponieważ rozkłady tokenów się rozchodzą.

Wyszukiwanie kompatybilnych modeli szkicujących

Nie każdy mały model nadaje się jako model szkicujący dla danego modelu docelowego. Kluczowym czynnikiem jest zgodność rozkładów — jak blisko prawdopodobieństwa wyjściowe modelu szkicującego pokrywają się z tymi modelu docelowego.

Złota zasada: jeśli stopień akceptacji modelu szkicującego spada poniżej 50%, dekodowanie spekulacyjne może w rzeczywistości spowolnić proces. Nadmiar obliczeń związany z uruchamianiem modelu szkicującego oraz weryfikacją przewyższa korzyści, gdy większość propozycji jest odrzucanych.

EAGLE i EAGLE-3: Głowice predykcyjne

EAGLE (Efficient Architecture Guided Language Model Estimation) eliminuje potrzebę osobnego modelu szkicującego. Zamiast tego przyłącza lekkie autoregresywne głowice predykcyjne do warstw wewnętrznych modelu docelowego.

Jak działa EAGLE

EAGLE trenuje głowice predykcyjne, które przyjmują stany ukryte (hidden states) z pośrednich warstw modelu docelowego i przewidują przyszłe tokeny. Podczas inferencji:

1. Model docelowy uruchamia przebieg przodowy przez swoje warstwy.
2. W każdej warstwie głowica EAGLE odczytuje stan ukryty i proponuje tokeny dla przyszłych pozycji.
3. Wiele głowic działa równolegle, każda przewidująca inny przyszły krok czasowy.
4. Model docelowy weryfikuje wszystkie propozycje w jednym przebiegu.

Zaleta: Głowice EAGLE są trenowane specjalnie, aby dopasować się do rozkładu modelu docelowego. Bezpośrednio widzą reprezentacje wewnętrzne modelu docelowego, co daje im znacznie lepsze dopasowanie niż autonomiczny model szkicujący.

Ulepszenia w EAGLE-3

EAGLE-3 (2025) udoskonala podejście dzięki trzem kluczowym zmianom:

1. Wybór warstwy: Zamiast przyłączać głowice do każdej warstwy, EAGLE-3 używa optymalizacji bayesowskiej do wybrania optymalnej warstwy wyjściowej, co zmniejsza nadmiar obliczeń (overhead).
2. Predykcja wielu tokenów: Każda głowica przewiduje wiele tokenów jednocześnie, zwiększając głębokość szkicu bez proporcjonalnego wzrostu kosztu obliczeniowego.
3. Skuteczność treningu: EAGLE-3 trenuje na danych generowanych przez sam model docelowy, co poprawia stopień akceptacji przy obciążeniach wewnątrz-rozkładu (in-distribution).

Stopnie akceptacji: EAGLE-3 typowo osiąga stopień akceptacji 60–80% przy obciążeniach wewnątrz-rozkładu, w porównaniu z 40–60% dla autonomicznych modeli szkicujących. Przy obciążeniach generowania kodu o wysokiej powtarzalności stopień akceptacji może przekraczać 85%.

Konfiguracja: EAGLE-3 wymaga wstępnie wytrenowanych głowic dla modelu docelowego. NVIDIA udostępnia głowice EAGLE-3 dla kilku popularnych modeli przez TensorRT-LLM oraz kolekcję Speculative Decoding Modules na HuggingFace. Istnieją implementacje zewnętrzne dla vLLM i SGLang.

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

Głównym ograniczeniem EAGLE-3 jest autoregresywne szkicowanie — każdy token szkicu zależy od poprzedniego, więc wygenerowanie K tokenów szkicu wymaga K sekwencyjnych przebiegów przodowych przez głowicę szkicującą, a nadmiar obliczeń rośnie liniowo z K. P-EAGLE usuwa ten limit, generując wszystkie K tokenów szkicu w jednym przebiegu przodowym przez lekką 4-warstwową jednostkę szkicującą, wytrenowaną do przewidywania do 10 tokenów równolegle.

Wynik: P-EAGLE zapewnia do 1.69x przyspieszenia w porównaniu z bazowym EAGLE-3 w rzeczywistych obciążeniach na NVIDIA B200. Zaleta rośnie przy wyższych wartościach K — tam, gdzie sekwencyjne szkicowanie EAGLE-3 staje się wąskim gardłem, równoległe szkicowanie P-EAGLE nie ponosi dodatkowych kosztów.

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 to aktualny stan techniki (state-of-the-art) dla dekodowania spekulacyjnego opartego o EAGLE, a jeśli wdrażasz EAGLE w 2026 roku, P-EAGLE to wariant, którego powinieneś użyć.

Dekodowanie spekulacyjne oparte na n-gramach

Dekodowanie spekulacyjne oparte na n-gramach zastępuje neuronalny 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 nastąpiły po tym wzorcu wcześniej — na przykład, jeśli model już wygenerował def calculate_total(items): i ponownie spotyka def calculate_total(, wie, że następne tokeny prawdopodobnie będą items): na podstawie wcześniejszego wystąpienia.

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

Zalety:

• Zero dodatkowego zużycia VRAM — brak dodatkowego modelu do załadowania (~16 MB dla tablicy hash)
• Ekstremalnie szybkie przy obciążeniach powtarzalnych (edytowanie kodu, refactorowanie, generowanie szablonów)
• Stopnie akceptacji mogą osiągać 90%+ przy obciążeniach o wysokiej samo-podobieństwie

Wady:

• Bezużyteczne przy nowatorskim generowaniu — jeśli wzorzec nie pojawił się wcześniej, n-gram nie ma nic do zaproponowania
• Stopień akceptacji spada do zera przy obciążeniach kreatywnych lub różnorodnych
• Ograniczona głębokość szkicu (typowo 2–4 tokeny na dopasowanie)

Najlepsze zastosowania: Refactorowanie kodu, wypełnianie szablonów, powtarzalne dokumentacje oraz każde obciążenie, w którym model ponownie odwiedza podobne wzorce. Najgorsze zastosowania: pisarstwo kreatywne, otwarty czat i zadania rozumowania.

Dostrojenie 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. Płaci się za to mniejszą częstotliwością dopasowań, ale zyskuje wyższy stopień akceptacji na każde dopasowanie.

Samo-spekulacyjne dekodowanie (Self-Speculative Decoding)

Samo-spekulacyjne dekodowanie (nazywane też LayerSkip lub self-speculation) wykorzystuje częściowe obliczenia samego modelu jako szkic, więc nie jest potrzebny osobny model.

Jak to działa

Zamiast uruchamiać pełny model dla każdego tokena, samo-spekulacyjne dekodowanie uruchamia wersję przyciętą — pomijając niektóre warstwy transformera — aby tanią generować tokeny szkicu, a następnie pełny model weryfikuje te propozycje.

Na przykład, model 32-warstwowy mógłby działać z tylko 16 warstwami dla fazy szkicu, a następnie weryfikować z użyciem wszystkich 32 warstw. Przycięty przebieg przodowy jest szybszy, ponieważ przetwarza mniej warstw, a tokeny szkicu korzystają z widoku tych samych początkowych warstw co model docelowy.

Zalety:

• Brak dodatkowych wag modelu do załadowania
• Naturalne dopasowanie do rozkładu docelowego (ta sama architektura, częściowe warstwy)
• Działa dobrze dla modeli ze znaczną redundancją w głębszych warstwach

Wady:

• Wymaga modyfikacji silnika inferencji, aby obsłużył częściowe przebiegi przodowe
• Złożoności cache KV — szkic używa częściowego cache KV, który musi być pogodzonym z cache modelu pełnego
• Stopnie akceptacji są typowo niższe niż w EAGLE lub dobrze dostrojonych modelach szkicujących

Implementacja w llama.cpp: PR #18471 wprowadził samo-spekulacyjne dekodowanie z użyciem historii kontekstu jako szkicu. Model ponownie wykorzystuje tokeny z własnej historii generacji, aby proponować kontynuacje, co jest szczególnie skuteczne przy obciążeniach kodujących, gdzie wzorce powtarzają się w tym samym oknie kontekstu.

MTP (Multi-Token Prediction)

MTP jest specjalną formą dekodowania spekulacyjnego wbudowaną bezpośrednio w niektóre checkpointi modeli. Qwen 3.6 jest dostarczany zarówno w wariantach GGUF standardowych, jak i z włączonym MTP.

Jak się różni: Głowice MTP są „wpiekane” w architekturę modelu podczas treningu. Model niesie dodatkowe głowice predykcyjne, które proponują wiele przyszłych tokenów w jednym przebiegu przodowym. Nie ma osobnego modelu szkicującego — głowice MTP są częścią samego modelu docelowego.

Kompromisy:

• Brak modelu szkicującego do zarządzania — MTP jest aktywne flagą --spec-type draft-mtp --spec-draft-n-max N
• Głowice MTP dodają ~1–2 GB nadmiaru VRAM
• Działa najlepiej na architekturach MoE (Qwen 3.6 35B-A3B), gdzie rzadka routingu (sparse routing) utrzymuje koszty głowic MTP na niskim poziomie

Szczegółowe benchmarki MTP vs dekodowanie standardowe dla Qwen 3.6 27B i 35B można znaleźć tutaj: Qwen 3.6 MTP vs Standard na GPU 16GB.

Stopnie akceptacji: Co oznaczają w praktyce

Stopień akceptacji (α) to pojedynczy najważniejszy wskaźnik wydajności dekodowania spekulacyjnego. Określa, czy uzyskujesz przyspieszenie, czy płacisz nadmiar kosztów.

Wzór na przyspieszenie

Oczekiwana liczba zaakceptowanych tokenów na przebieg weryfikacji:

E[accepted] = α × K

Gdzie K to liczba tokenów szkicu proponowanych na cykl. Jeśli α = 0,7 i K = 5, akceptujesz 3,5 tokena na przebieg — przyspieszenie 3,5x w porównaniu ze standardowym dekodowaniem (które produkuje 1 token na przebieg).

Stopień akceptacji według metody

Kiedy stopień akceptacji spada

Stopień akceptacji nie jest stały w trakcie generowania. Zmienia się w zależności od:

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

Krytyczny próg: Jeśli efektywny stopień akceptacji (α × K) spada poniżej 1,0, dekodowanie spekulacyjne jest wolniejsze niż dekodowanie standardowe. Nadmiar obliczeń szkicu oraz czas weryfikacji przekraczają koszt pojedynczego kroku autoregresywnego.

Dekodowanie spekulacyjne w środowisku produkcyjnym: Co faktycznie się dzieje

Artykuły naukowe raportują przyspieszenia 2–4x, ale benchmarki produkcyjne opowiadają bardziej niuansowaną historię — przyspieszenia maleją wraz z rozmiarem partii (batch size), weryfikacja dominuje czas cyklu, a żadna pojedyncza metoda nie wygrywa przy każdym obciążeniu.

Wnioski z SpecDecode-Bench (2026)

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

1. SD działa, ale przyspieszenia maleją 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 współbieżności, a GPU ma mniej niedostępnej mocy, aby poświęcić na spekulację.

2. Weryfikacja dominuje czas wykonania (42–95%). Przebieg przodowy modelu docelowego jest wąskim gardłem. Zmniejszenie marnotrawstwa weryfikacji przy odrzuconych tokenach jest najbardziej obiecującą drogą do poprawy.

3. Żadna pojedyncza metoda nie wygryza wszędzie. EAGLE-3 jest najlepszym wyborem wszechstronnym. Metody oparte na modelu szkicującym świetlują, gdy model docelowy jest duży (70B+). N-gram jest optymalny dla edytowania kodu i zadań o dużym nakładzie wspólnym.

4. Analiza orakularna ujawnia lukę. Teoretyczny górny limit dla łączonych strategii n-gram + EAGLE sięga ~4.9x przy obciążeniach edytowania kodu, ale obecne implementacje osiągają 2–3x. Jest pole do optymalizacji.

Praktyczne oczekiwania co do przyspieszenia

Efekt rozmiaru partii jest krytyczny. Przy małych partiach GPU ma niedostępną moc obliczeniową do poświęcenia na spekulację. Przy dużych partiach system jest już nasycony, a dekodowanie spekulacyjne dodaje nadmiar bez proporcjonalnej korzyści.

Monitorowanie w środowisku produkcyjnym

Powinieneś śledzić stopień akceptacji w produkcji. Spadający stopień akceptacji sygnalizuje, że Twój model szkicujący odchodzi od modelu docelowego — entweder dlatego, że obciążenie się zmieniło, albo dlatego, że model szkicujący wymaga ponownego treningu.

Kluczowe metryki do monitorowania:

• Stopień akceptacji na request (powinien być stabilny w okolicach Twojego punktu odniesienia)
• Tokeny na sekundę z dekodowaniem spekulacyjnym vs bez niego (faktyczne przyspieszenie)
• Czas weryfikacji jako procent czasu cyklu (powinien wynosić 42–95%)
• Czas przebiegu przodowego modelu szkicującego (powinien być < 20% czasu modelu docelowego)

Jeśli Twój stopień akceptacji spada poniżej 40%, wyłącz dekodowanie spekulacyjne dla tego requestu. Nadmiar nie jest tego wart.

Praktyczna konfiguracja

Wybór silnika ma tak duże znaczenie jak strategia szkicowania — zobacz Ollama vs vLLM vs LM Studio i inne lokalne runtime’y aby zobaczyć, jak każdy runtime obsługuje batchowanie, kompatybilność API i przepustowość, zanim wybierzesz ścieżkę dekodowania spekulacyjnego.

llama.cpp

Dla ogólnej konfiguracji 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 szkicujący (autonomiczny)
llama-server \
  --model model-docelowy.gguf \
  --draft-model model-szkicujacy.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Wymagane: --parallel 1 dla dekodowania spekulacyjnego

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

# n-gram (dostrojenie dla obciążeń tekstowych)
llama-server \
  --model model-docelowy.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

# Samo-spekulacyjne (obciążenia kodowe)
llama-server \
  --model model-docelowy.gguf \
  --spec-type draft-self

Krytyczne flagi:

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

Częste błędy:

• Zapomnienie --parallel 1 — serwer będzie milcząco ignorował dekodowanie spekulacyjne.
• Używanie modeli szkicujących międzyrodzinnych — stopnie akceptacji się zawalają, niwelując jakiekolwiek przyspieszenie.
• Ustawienie --spec-draft-n-max zbyt wysoko — każdy dodatkowy token szkicu kosztuje VRAM dla bufora szkicu. Opadające korzyści pojawiają 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 szkicujący
vllm serve model-docelowy \
  --speculative-model model-szkicujacy \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

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

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

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

Dekodowanie spekulacyjne w vLLM jest zintegrowane z ciągłym batchowaniem (continuous batching), więc działa pod obciążeniami współbieżnymi. Planista (scheduler) obsługuje wiele slotów tokenów w jednym przebiegu przodowym, a menedżer pamięci obsługuje cache KV dla obu modeli: szkicującego i docelowego.

SGLang

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

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

Architektura RadixAttention w SGLang dobrze łączy się z dekodowaniem spekulacyjnym, ponieważ cache prefiksów (prefix caching) zmniejsza koszt weryfikacji — model docelowy ponownie wykorzystuje zbuforowaną uwagę dla wspólnych prefiksów, czyniąc każdy przebieg weryfikacji tańszym niż nowy przebieg przodowy.

TensorRT-LLM

TensorRT-LLM oferuje dekodowanie spekulacyjne klasy produkcyjnej z Triton Inference Server. Konfiguracja jest bardziej skomplikowana, ale oferuje najlepsze osiągi na sprzęcie NVIDIA:

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

TensorRT-LLM obsługuje warianty draft-model oraz EAGLE-3. Przy obciążeniach generowania kodu, TensorRT-LLM z dekodowaniem spekulacyjnym opartym na n-gramach wykazał redukcję latencji o 2–3x w wdrożeniach produkcyjnych.

Kiedy używać dekodowania spekulacyjnego

Użyj, gdy

• Duże modele docelowe (7B+): Nadmiar mechanizmu szkicującego jest rozłożony na obliczenia modelu docelowego. Dekodowanie spekulacyjne błyszczy, gdy model docelowy jest wolny — im większy model docelowy, tym cenniejsze przyspieszenie.
• Obciążenia o niskiej temperaturze: Dekodowanie spekulacyjne działa najlepiej przy temperaturze 0,0–0,7, gdzie rozkład modelu docelowego jest skoncentrowany, a szkic ma większą szansę dopasowania.
• Aplikacje interaktywne: Obciążenia wrażliwe na latencję (czat, dopełnianie kodu, wywołania narzędzi agentów) zyskują najwięcej. Przetwarzanie partii, w którym już nasywasz GPU, widzi mniejszą korzyść.
• Generowanie i edycja kodu: Wysoka powtarzalność w wzorcach kodowych czyni dekodowanie oparte na n-gramach i samo-spekulacyjne szczególnie skutecznym.

Pomiń, gdy

• Małe modele docelowe (< 3B): Nadmiar modelu szkicującego zbliża się do czasu przebiegu przodowego modelu docelowego. Przyspieszenie jest marginalne lub ujemne.
• Próbkowanie o wysokiej temperaturze: Przy temperaturze > 0,7 rozkład modelu docelowego jest zbyt szeroki, aby szkic mógł się wiarygodnie dopasować.
• Pisanie kreatywne i otwarte generowanie: Niskie stopnie akceptacji przy nowatorskiej treści czynią nadmiar nieopłacalnym.
• Duże rozmiary partii (> 32): System staje się ograniczony mocą obliczeniową, a dekodowanie spekulacyjne dodaje nadmiar bez proporcjonalnej korzyści. SpecDecode-Bench pokazuje spadek przyspieszenia z 1.96x do 1.21x, gdy rozmiar partii rośnie z 1 do 128.

Łączenie metod

Zaawansowane konfiguracje łączą wiele strategii dekodowania spekulacyjnego. Analiza orakularna SpecDecode-Bench wykazała, że adaptacyjne łączenie n-gram i EAGLE może popchnąć przyspieszenie do 4.9x przy obciążeniach edytowania kodu.

Idea polega na użyciu n-gram dla wzorców, które pojawiły się wcześniej (gdzie akceptacja jest wysoka, a nadmiar bliski zeru), a przełączaniu na EAGLE dla nowatorskich tokenów. W praktyce wymaga to wsparcia silnika dla spekulacji wielometodowej — vLLM i TensorRT-LLM mają eksperymentalne wsparcie, ale implementacje klasy produkcyjnej są wciąż dojrzewające.

Na razie, najbardziej praktyczną kombinacją jest MTP + n-gram w llama.cpp. MTP obsługuje spekulację neuronalną, podczas gdy n-gram łapie powtarzalne wzorce, których MTP przegapia. Na Qwen 3 27B, ta kombinacja osiąga 120 tokenów/sek w porównaniu ze standardowymi 67 tokenów/sek — przyspieszenie 1.8x.

Rozważania kosztowe

Dekodowanie spekulacyjne wymienia obliczenia na latencję. 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:

• Latencja pojedynczego requestu poprawia się o 20–50%, co ma znaczenie dla aplikacji interaktywnych.
• Przepustowość (tokeny/sek dla wielu requestów) poprawia się w mniejszym stopniu — GPU jest już nasycone przy dużych partiach.
• Zużycie VRAM wzrasta o footprint modelu szkicującego (1–4 GB dla autonomicznych szkiców, minimalne dla n-gram/EAGLE).

Inferencja w chmurze: Przy $2–4/hod za H100, dekodowanie spekulacyjne redukuje latencję per request bez zwiększania kosztu per token. Dla przetwarzania partii, w którym już nasywasz GPU, korzyść kosztowa jest minimalna — płacisz za ten sam czas GPU w każdym przypadku.

Kiedy dekodowanie spekulacyjne oszczędza pieniądze: Aplikacje interaktywne, w których naliczasz opłatę per request i chcesz zmniejszyć czas do pierwszego tokena. Przyspieszenie 2x oznacza, że Twoi użytkownicy czekają dwa razy krócej, a Ty możesz obsłużyć więcej requestów na sekundę na tym samym sprzęcie.

Kiedy nie: Przetwarzanie partii, w którym już maksymalizujesz wykorzystanie GPU. Dodatkowe obliczenia z dekodowania spekulacyjnego nie zwiększają przepustowości — po prostu zmieniają profil latencji.

Co dalej

Dekodowanie spekulacyjne dojrzewa od nowinki badawczej do standardu produkcyjnego. Fronter pcha się poza obecne ograniczenia:

• Równoległe generowanie na poziomie modelu: Dekodowanie spekulacyjne pcha wiele tokenów na przebieg przodowy na poziomie inferencji, nie dotykając rozkładu wyjściowego. Modele językowe dyfuzyjne (diffusion language models) stawiają strukturalnie inną sprawę, generując wiele tokenów na przebieg przodowy jako część samej architektury modelu. Zobacz co następuje po LLM, aby porównać to z podejściem draft-verify powyżej oraz z modelami stanu przestrzennego i modelami świata JEPA po drugiej stronie krajobrazu post-transformerowego.

• Spekulacyjne dekodowanie spekulacyjne (SSD): Równolegli etapy szkicowania i weryfikacji na osobnym sprzęcie. Model szkicujący działa asynchronicznie, przespekulując na wiele prawdopodobnych wyników weryfikacji. Wczesne wyniki pokazują do 2x przyspieszenie w porównaniu z zoptymalizowanym dekodowaniem spekulacyjnym, oraz 5x w porównaniu z dekodowaniem autoregresywnym. Jeszcze nie gotowe do produkcji, ale kierunek jest jasny.

• SpecSA (Sparse Speculative Verification): Łączy dekodowanie spekulacyjne z dynamiczną rzadką uwagą (sparse attention). Zamienia rzadką uwagę na obciążenie zorientowane na weryfikację, osiągając do 3.49x przepustowości end-to-end w porównaniu z autoregresywnym rzadkim dekodowaniem. Istotne dla modeli o długim kontekście, gdzie rzadka uwaga jest już stosowana.

• Adaptacyjna spekulacja: Automatyczne przełączanie między metodami n-gram, EAGLE i draft-model w oparciu o charakterystyki obciążenia. Analiza orakularna pokazuje znaczący niedostatecznie wykorzystany potencjał — obecne implementacje osiągają 2–3x, ale teoretyczna granica to 4.9x.

• Wielomodalne dekodowanie spekulacyjne: Rozszerzenie draft-verify na modele językowo-wizualne i generowanie wideo. Wczesne przeglądy pokazują, że te same zasady się stosują, ale strategie weryfikacji wymagają adaptacji dla modalności innych niż tekst.

Rama decyzyjna