W artykule opublikowanym 27 października 2026 r. NVIDIA podała, że trzy optymalizacje zwiększyły przepustowość dekodowania modelu Ling-3.0-flash-fp4 na DGX Spark z 37,81 do 53,89 tokena na sekundę, czyli o 42,5%, w ewaluacji obejmującej 1 319 pytań GSM8K przy rozmiarze partii równym 1. Wynik dotyczy generowania tokenów; średni czas do pierwszego tokena nie skrócił się w tym pomiarze.
Co NVIDIA zmierzyła na DGX Spark
Ling-3.0-flash-fp4 to model typu Mixture of Experts (MoE), czyli taki, który dla kolejnych tokenów aktywuje część spośród wielu ekspertów. NVIDIA podała, że model ma 124 mld parametrów, z czego aktywnych przy generowaniu jednego tokena jest 5,1 mld. W każdej warstwie MoE token jest kierowany do 8 z 512 ekspertów routowanych oraz do jednego eksperta współdzielonego.
W teście GSM8K NVIDIA porównała konfigurację bazową z konfiguracją używającą wszystkich trzech optymalizacji. Przepustowość dekodowania wzrosła z 37,81 do 53,89 tokena/s, a średnie opóźnienie odpowiedzi spadło z 15,21 do 11,49 s. Średni czas do pierwszego tokena wyniósł odpowiednio 0,207 i 0,214 s. Ewaluacja wykorzystywała podpowiedzi z pięcioma przykładami, temperaturę 0,6, top-p 0,95, top-k 29 i włączone chain-of-thought.
Trzy optymalizacje dotyczą różnych etapów dekodowania
NVIDIA połączyła trzy zmiany. Humming zastępuje bazowy backend FlashInfer dla kerneli MoE MXFP4. Kwantyzacja FP8 stosowana na bieżąco zmniejsza o połowę ilość wag głowicy modelu językowego (LM head) odczytywanych względem BF16. Trzecia zmiana wykorzystuje warstwę NEXTN do spekulacyjnego dekodowania MTP: model draft proponuje tokeny, które model docelowy weryfikuje. W opisanej konfiguracji użyto trzech kroków draftu i czterotokenowego okna weryfikacji.
Konfiguracja bazowa korzystała z W4A8, kerneli MoE MXFP4 FlashInfer, NVIDIA CUTLASS dla gęstych operacji GEMM oraz opcji --enable-fp32-lm-head. Kwantyzację FP8 włączano ustawieniem SGLANG_ENABLE_FP8_LM_HEAD=1, które jest wzajemnie wykluczające z --enable-fp32-lm-head.
Wynik syntetyczny nie opisuje testu GSM8K
NVIDIA uzyskała 185,1% wzrostu przepustowości w osobnym teście syntetycznym: przy partii równej 1, wejściu o długości 32 tys. tokenów i wyjściu 2 tys. tokenów wynik wzrósł z 36,09 do 102,88 tokena/s. Ten test używał dekodowania zachłannego, a średnia długość akceptacji MTP wyniosła 3,90 tokena na rundę. W GSM8K, które korzystało z próbkowania, akceptacja wyniosła 2,68 tokena na rundę, a wzrost przepustowości 42,5%.
| Ewaluacja i warunki | Przepustowość bazowa | Wszystkie trzy optymalizacje | Zmiana raportowana przez NVIDIA |
| Test syntetyczny: partia 1, wejście 32 tys. tokenów, wyjście 2 tys. tokenów, dekodowanie zachłanne | 36,09 tok/s | 102,88 tok/s | +185,1% |
| GSM8K: 1 319 pytań, partia 1, prompting z pięcioma przykładami i próbkowanie | 37,81 tok/s | 53,89 tok/s | +42,5% |
Te wartości dotyczą różnych obciążeń. NVIDIA zaznacza, że powtarzalne wyjście i dekodowanie zachłanne w teście syntetycznym zawyżają korzyści z dekodowania spekulacyjnego dla innych zadań.
Warto też oddzielić przetwarzanie promptu od generowania tokenów. Hiszpańskojęzyczny materiał Codigo gris wyjaśnia, że przetwarzanie promptu może być ograniczone mocą obliczeniową, a dekodowanie tokenów przepustowością pamięci, ponieważ wagi trzeba wielokrotnie odczytywać. Z tego powodu przepustowość dekodowania nie opisuje sama w sobie szybkości przetwarzania promptu.
Użytkownik u/Purple_Dream6414 zwracał w dyskusji o lokalnych modelach uwagę, że sama liczba tokenów na sekundę nie mówi, ile użytecznej pracy system wykona w danym czasie. To istotne rozróżnienie przy interpretacji wyniku: przepustowość dekodowania i czas do pierwszego tokena opisują różne części odpowiedzi.
Współdzielenie pełnego LM head jest warunkiem połączenia FP8 z MTP
NVIDIA opisuje konkretny błąd integracji: model draft musi współdzielić z modelem docelowym cały moduł LM head, nie tylko jego wagi. Jeśli draft otrzyma wagi FP8, ale zinterpretuje je jako BF16, długość akceptacji może spaść do 1,00 tokena na rundę, a przepustowość poniżej wyniku bazowego. W konfiguracji łączącej FP8 z MTP zgodność pełnego modułu ma więc bezpośrednie znaczenie dla uzyskanego przyspieszenia.
