Jak DFlash2 przyspiesza Qwen3.8 i skraca kontekst

Spekulatywne dekodowanie pozwala przygotować kilka kolejnych tokenów i sprawdzić je wspólnie przez model docelowy. Gdy propozycje pasują, jedna iteracja może dopisać ich więcej. Gdy pierwsza propozycja się nie zgadza, model docelowy przejmuje dalszy ciąg.

W domowym eksperymencie profil bazowy 150k z MTP-3 osiągnął 93,3 tok./s dekodowania. Opcjonalny profil DFlash2-7 z limitem 65 536 tokenów osiągnął medianę 120,9 tok./s w trzech powtórzeniach, czyli o 29,6% więcej. Mniejszy limit oznacza utratę 84 464 tokenów dostępnej historii. Zestawienie i ograniczenia są w publicznym zestawieniu pomiarów.

Co oznacza każdy element

Model autoregresyjny generuje token po tokenie. Token jest fragmentem tekstu. Po każdym kroku wynik trafia do kontekstu i model wykonuje kolejną iterację. Przy jednym użytkowniku koszt przenoszenia wag z pamięci może dominować nad samymi obliczeniami.

W dekodowaniu spekulatywnym mechanizm pomocniczy tworzy krótką propozycję. Model docelowy, czyli pełny Qwen3.8-27B, sprawdza ją w jednym przebiegu. Zaakceptowane tokeny zostają w odpowiedzi, a odrzucony fragment jest generowany ponownie przez model docelowy. Weryfikacja zachowuje kontrolę jakości po stronie głównego modelu, a szybkość zależy od liczby zaakceptowanych propozycji i kosztu ich sprawdzenia.

Dokumentacja vLLM opisuje tę technikę jako sposób zmniejszania opóźnienia między tokenami, szczególnie przy małym lub średnim obciążeniu. Tok./s oznacza liczbę wygenerowanych tokenów na sekundę. Pełny czas odpowiedzi obejmuje także przyjęcie i przygotowanie wejścia.

MTP jest częścią modelu

MTP to Multi-Token Prediction, mechanizm przewidywania kolejnych tokenów. Serwer może użyć takiego mechanizmu jako wbudowanego źródła propozycji, bez dokładania osobnego małego modelu. Publiczny zapis oznacza profil jako MTP-3; źródło nie definiuje, czy liczba odnosi się do głów, kroków czy innego parametru implementacji.

Profil bazowy z MTP-3 miał limit 150 000 tokenów i pozostał punktem odniesienia dla dłuższych prac. To ważne, bo wyższe tempo dekodowania ma znaczenie tylko wtedy, gdy sesja mieści potrzebną historię.

Co zmierzyliśmy dla DFlash2-7

W profilu fast wykonaliśmy trzy powtórzenia:

Mediana to środkowa wartość po uporządkowaniu wyników. Tutaj wynosi 120,9 tok./s. Publiczny zapis podaje te trzy tempa dekodowania i medianę. Nie zawiera osobnego pomiaru czasu od przyjęcia wejścia do końca odpowiedzi, dlatego decyzję opieramy na tempie dekodowania.

Profil DFlash2 miał kontekst 65 536 tokenów. Pamięć KV przechowuje wartości pośrednie dla tokenów już obecnych w sesji. Publiczny zapis nie podaje formatu tej pamięci, więc nie przypisujemy wynikowi konkretnej precyzji KV. Każdy profil łączy limit kontekstu, mechanizm propozycji i ustawienia serwera, dlatego tempo dekodowania trzeba oceniać razem z długością sesji oraz wynikiem zadania.

Szybciej dla krótkiej sesji, mniej historii dla długiej

DFlash2 może pasować do krótkich zmian w kodzie i wielu małych pytań, przy których użytkownik często czeka na kolejną odpowiedź. Sesja nad dużym repozytorium może szybciej zapełnić okno 65 536 tokenów, uruchomić kompresję historii i stracić część korzyści z szybszego dekodowania.

Wybór powinien wynikać z rozkładu zadań. Dla każdego typu pracy zmierz:

1. czas przygotowania wejścia;
2. tempo dekodowania;
3. czas do pełnej odpowiedzi;
4. zużycie VRAM;
5. liczbę zaakceptowanych tokenów;
6. moment kompresji historii;
7. poprawność wyniku i działanie narzędzi.

W zestawieniu pomiarów każda konfiguracja otrzymała jeden przebieg dla danego testu, a DFlash2-7 miał trzy powtórzenia opisane wyżej. Taki materiał pokazuje kierunek strojenia. Powtarzalność trzeba sprawdzić na własnych zestawach wejść.

Prosty model kosztu

Można myśleć o zysku jako o różnicy między zaoszczędzonymi krokami a kosztem dodatkowej pracy:

zysk = zaakceptowane tokeny × pominięte kroki modelu docelowego
  - koszt tworzenia propozycji
  - koszt ich wspólnej weryfikacji
  - koszt odrzuconych propozycji

Kod, polska proza i dane strukturalne mają różne wzorce przewidywalności. Ustawienie dobre dla jednego wejścia może więc pogorszyć wynik na innym.

Jak przeprowadzić uczciwy test

1. Użyj tej samej wersji modelu docelowego i tych samych ustawień losowania.
2. Zamroź zestaw wejść, długość odpowiedzi i temperaturę.
3. Oznacz zimny start albo rozgrzej pamięć podręczną wspólnego prefiksu.
4. Zapisuj osobno wczytanie wejścia, dekodowanie i czas całej odpowiedzi.
5. Mierz akceptację propozycji dla każdej klasy zadania.
6. Sprawdzaj poprawność kodu, testy i wywołania narzędzi obok tok./s.
7. Dodaj długą sesję, aby zmierzyć kompresję historii.

Weryfikacja przez model docelowy ogranicza ryzyko przyjęcia błędnych tokenów. Zmieniony serwer może jednak wprowadzić problemy z modułem odczytu, pamięcią podręczną albo protokołem. Dlatego szybkość i poprawność sprawdzamy jako dwa osobne wymiary.

Wniosek dla wdrożenia

Profil 150k MTP-3 jest punktem odniesienia dla cięższej pracy. Profil DFlash2-7 dał wyższą medianę dekodowania w krótkim pomiarze, a jednocześnie ograniczył historię do 65 536 tokenów. To kompromis praktyczny. Wybór dotyczy czasu pojedynczej odpowiedzi i długości sesji. Przy wyborze profilu trzeba zestawić tempo generowania z długością historii, pamięcią GPU, zachowaniem narzędzi oraz czasem potrzebnym na pełne wykonanie rzeczywistego zadania w środowisku, które ma później korzystać z usługi.

Syntalith może przygotować skrypt pomiarowy, kryteria jakości, ustawienia wybranego profilu i wariant powrotu. Bezpłatny skan procesu pomaga najpierw ustalić, czy wąskim gardłem jest dekodowanie, długość kontekstu, serwer czy sposób pracy.