K-EXAONE-2.0-750B-A37B-DSpark: Koreańskie MoE LG o parametrach 750B trafia do vLLM

9 sierpnia 2026 roku w repozytorium vLLM otwarto pull requesta mającego dodać K-EXAONE-2.0-750B-A37B-DSpark — wariant ze spekulacyjnym dekodowaniem flagowego, 750-miliardowego modelu koreańskiego LG AI Research. Cztery dni później, 13 sierpnia, drugi, bardziej fundamentalny PR potwierdził przeciek: vLLM ma teraz ogólną ścieżkę konfiguracyjną DSparkDraftModel, która mapuje dowolny checkpoint Hugging Face deklarujący architectures=DSparkDraftModel z model_type=qw​en​3 na rozpoznawany Qw​en3DSparkModel, wraz z planem testów faktycznie obsługującym drafter RadixArk Qw​en​3.8-2.4T-A95B-DSpark metodą dspark spec. Podstawowy K-EXAONE-2.0-750B-A37B wydano 31 lipca na licencji Apache 2.0, a na starcie vLLM potrafił go obsługiwać metodą draftu MTP, ale nie DSpark — draftera, który LG również dostarcza i który według LG zapewnia 3–5× przyspieszenie dekodowania. Sam DSpark to metoda Deep​Seeka, ten sam semi-autoregresywny drafter, który działa w Deep​Seek-V4-Pro-DSpark i Deep​Seek-V4-Flash-DSpark, więc te dwa PR-y razem są jak dotąd najwyraźniejszym sygnałem, że stack spekulacyjnego dekodowania Deep​Seeka staje się domyślnym wyborem dla modeli o otwartych wagach.

{{1}}To jest materiał typu „co wiemy do tej pory”, a nie zapowiedź premiery.{{/1}} {{2}}Oba pull requesty są otwarte i niescalone{{/2}}, {{3}}checkpoint DSpark nie ma niezależnego benchmarku{{/3}}, a {{4}}wartość przyspieszenia podana przez LG to deklaracja producenta{{/4}}. {{5}}Wszystko poniżej jest odpowiednio oznaczone.{{/5}} {{6}}Co jest dziś faktem:{{/6}} {{7}}wagi są na Hugging Face{{/7}}, {{8}}model bazowy został wydany{{/8}}, {{9}}dekoder spekulacyjny DSpark w vLLM już obsługuje checkpointy DeepSeek i Kimi{{/9}}, a {{10}}generyczna ścieżka konfiguracyjna, która pozwoliłaby na wczytanie zewnętrznego draftora DSpark{{/10}} — {{11}}element, na który czekał ten przeciek{{/11}} — {{12}}znajduje się teraz w publicznym pull requeście, przetestowany, ale niewydany.{{/12}}

Krótka wersja

• PR #51558, otwarty 9 sierpnia 2026 r., dodaje K-EXAONE-2.0-750B-A37B-DSpark do vLLM; pozostaje otwarty i nie ma jeszcze żadnych zatwierdzeń.

• PR #52197, otwarty 13 sierpnia 2026 roku, wprowadza ogólną obsługę konfiguracji DSparkDraftModel — architektury=DSparkDraftModel z model_type=qwen3, znormalizowane do Qwen3DSparkModel — a jego plan testów uruchamia drafter RadixArk Qwen3.8-2.4T-A95B-DSpark z metodą dspark spec i siedmioma tokenami spec. Również otwarty, również niescalony.

• DSpark to drafter z rodziny EAGLE, który Deep​Seek udostępnił jako open-source i który jest dostarczany z Deep​Seek-V4-Pro-DSpark oraz Deep​Seek-V4-Flash-DSpark; LG to jak dotąd najbardziej znaczące wdrożenie przez inne laboratorium, a drafter Qw​en​3.8 od RadixArk to drugie niezależne wdrożenie.

Wariant DSpark to 78‑warstwowy MoE o 750 mld parametrów plus pięć dodatkowych warstw draft; LG twierdzi, że DSpark i MTP zapewniają około 3–5‑krotne przyspieszenie dekodowania, ukierunkowane na obciążenia agentowe o długim horyzoncie.

• W momencie premiery vLLM obsługiwał MTP dla K-EXAONE 2.0, ale nie dla DSpark; PR specyficzny dla modelu oraz ogólna ścieżka konfiguracji to wprowadzenie wsparcia dla DSpark.

• Żaden dostawca nie udostępnia obecnie żadnego checkpointu K-EXAONE 2.0, a każdy benchmark na karcie jest własnością LG.

Czym są pull requesty (a czym nie są)

PR #51558 w vLLM, „[Model] Add K-EXAONE-2.0-750B-A37B-DSpark”, został otwarty przez lkm2835 — tego samego współtwórcę, który odpowiadał za wcześniejsze wsparcie K-EXAONE w vLLM (#50524 dla modelu bazowego) oraz w SGLang (#33648). Jest to fork PR z etykietą new-model; poproszono o przegląd właścicieli kodu vLLM, ale nie ma jeszcze żadnych zatwierdzeń. Opis składa się z trzech linii: dodaje wsparcie dla checkpointu DSpark „opracowanego przez LG AI Research”, zamieszcza linki do karty modelu Hugging Face oraz raportu technicznego K-EXAONE 2.0 (arXiv 2608.04505), a także odwołuje się do wcześniejszej pracy w vLLM (#50524).

PR z 13 sierpnia jest innego rodzaju. #52197, „Support DSpark configs with architectures=DSparkDraftModel + model_type=qwen3", dodaje generyczną warstwę normalizacji: punkt kontrolny Hugging Face, który deklaruje się jako DSparkDraftModel dla typu modelu qwen3, jest mapowany na Qwen3DSparkModel, który może wczytać istniejący w vLLM dekoder spekulatywny. Model referencyjny w jego planie testów to RadixArk/Qwen3.8-2.4T-A95B-DSpark — spekulator DSpark dla docelowego modelu klasy max Qwen3.8-2.4T-A95B — serwowany metodą spekulacji dspark z oknem spekulacji o długości siedmiu tokenów. Treść commita zawiera całą ideę: „architectures=DSparkDraftModel+model_type=qwen3". Celem zmiany jest to, aby zewnętrzny drafter DSpark można było ładować przez konfigurację, zamiast wymagać kodu dla każdego modelu — co jest obecnie sposobem, w jaki podpięty jest każdy obsługiwany checkpoint DSpark. Jest otwarty i niescalony, podobnie jak #51558.

Przeczytaj ten status dosłownie. „Wsparcie jest dodawane" to nie to samo co „wsparcie jest dostępne": dopóki którykolwiek z PR-ów nie zostanie zmergowany i nie trafi do wydania, standardowa kompilacja vLLM nadal nie załaduje wariantu DSpark. Sama karta modelu mówi, że serwowanie K-EXAONE 2.0 z DSpark nie jest obecnie wspierane na vLLM, które zamiast tego używa MTP. Te dwa PR-y to kroki, które zmieniają to zdanie — jeśli i kiedy zostaną wdrożone.

Dlaczego DSpark to prawdziwa historia

{{1}}Nazwa modelu wiele mówi.{{/1}} {{2}}"A37B" oznacza 37 miliardów aktywnych parametrów na token.{{/2}} {{3}}"DSpark" to drafter do spekulatywnego dekodowania, wprowadzony przez DeepSeek w tym roku: półautoregresyjny model szkicujący z rodziny EAGLE, który w jednym przebiegu proponuje blok tokenów i pozwala modelowi docelowemu je zweryfikować, dzięki czemu jakość wyników pozostaje niezmieniona, a generowanie jest szybsze.{{/3}} {{4}}DeepSeek udostępniło go jako open source i dostarcza draftera wraz z własnymi punktami kontrolnymi DeepSeek-V4-Pro-DSpark oraz DeepSeek-V4-Flash-DSpark, przy czym społeczność raportuje przyspieszenie rzędu 60–85% dla Flash i 57–78% dla Pro w porównaniu z bazowym modelem MTP generującym token po tokenie.{{/4}} {{5}}Wyjaśnię teraz, jak drafter DSpark współdziała z modelem docelowym.{{/5}}

Nowy PR jasno pokazuje, że wsparcie DSpark w vLLM nigdy nie było otwartym pytaniem. Dokumentacja samego vLLM już wymienia moduły DSpark dla checkpointów Deep​Seek-V4, Kimi K3 i Gem​ma​4, a zespół opisał ten projekt w lipcowym wpisie inżynierskim. Każda z tych integracji jest jednak ręcznie podpięta — błogosławiona lista checkpointów, a nie trasa, z której każdy może skorzystać. Checkpoint K-EXAONE po prostu nie znajduje się na tej liście. #52197 to próba uczynienia tej trasy uniwersalną: jedno mapowanie konfiguracji (DSparkDraftModel plus qw​en​3) zamiast kolejnej dedykowanej klasy modelu, a także drafter trzeciej strony jako referencyjny przypadek testowy zamiast modelu Deep​Seek. Dlatego historia o wyciekłym draft-checkpoincie to tak naprawdę historia o infrastrukturze.

K-EXAONE-2.0-750B-A37B-DSpark zachowuje 78 warstw modelu bazowego i dodaje pięć warstw draftujących DSpark, a karta modelu LG twierdzi, że zarówno DSpark, jak i MTP przyspieszają generowanie o około 3–5× — to jej własne liczby, mające zastosowanie do „obciążeń o długim horyzoncie, takich jak zadania agentowe”, gdzie opóźnienie dekodowania jest wąskim gardłem. Wynikają z tego dwie rzeczy. Po pierwsze, dekodowanie spekulatywne staje się funkcją pierwszej klasy otwartych modeli granicznych, a nie serwerowym trikiem, który doczepia się później. Po drugie, to właśnie pakiet draftów Deep​Seeka staje się standardem — i właśnie dlatego wspierany przez koreański rząd suwerenny model flagowy, który go zawiera, ma znaczenie wykraczające poza zwykłe wieści o „nowym modelu”.

Model stojący za PR

K-EXAONE-2.0-750B-A37B-DSpark jest wariantem K-EXAONE 2.0, kontynuacji linii K-EXAONE 236B firmy LG i największego rodzimego modelu fundamentowego Korei Południowej, zbudowanego w ramach rządowego programu suwerennej AI. Model bazowy — 750B parametrów łącznie, 37B aktywnych, Mixture-of-Experts z 256 ekspertami i 8 aktywnymi na token, okno kontekstowe o długości 262 144 tokenów, dziesięć języków, Apache 2.0 — trafił na Hugging Face 31 lipca 2026 r., utworzony z poprzednika 236B w procesie upcyklingu, a nie wytrenowany od zera.

Średnie wyników benchmarków LG (24 benchmarki, 70,1 ogółem) pokazują oczekiwany profil koreańskiego modelu suwerennego: wysokie deklarowane wyniki w wyszukiwaniu w długim kontekście, bezpieczeństwie społecznym w kontekście koreańskim i kodowaniu agentowym, a także wyniki, które ustępują Qwen3.5 od Alibaby w rozumowaniu ogólnym (83,5 vs 89,8 w MMLU-Pro, na przykład). Żaden z tych wyników nie został jeszcze niezależnie zweryfikowany. Wariant DSpark nie zmienia żadnego z tych wyników — to artefakt serwowania, szybszy sposób uruchomienia tego samego modelu — co jest dokładnie powodem, dla którego pojawia się w pull requestach frameworków inferencyjnych, a nie w ogłoszeniu.

Rzeczywistość serwowania modelu MoE o parametrach 750B

Tutaj wsparcie DSpark ma realne znaczenie. K-EXAONE-2.0-750B-A37B-DSpark to punkt kontrolny o 751 miliardach parametrów w formatach BF16/F32, a zalecenia LG mówią o minimum dwóch węzłach po osiem GPU NVIDIA H200 (16 GPU, tensor-parallel 16). W tej skali liczy się przede wszystkim przepustowość dekodowania — tokeny na sekundę i koszt długiej tury agentowej — a właśnie na to wpływa dekodowanie spekulatywne. Przyspieszenie dekodowania o 3–5×, jeśli utrzyma się poza środowiskiem testowym LG, przesądza o tym, czy klaster H200 jest ekonomiczny, czy nie. LG dokumentuje też problem z kolapsem generacji na GPU B200, który wymaga tymczasowego obejścia --disable-prefill-cuda-graph — przypomnienie, że to serwowanie na styku najnowszych technologii, a nie rozwiązanie pod klucz.

Ile to kosztuje i jak faktycznie można tego spróbować.

Żadne API nie obsługuje obecnie K-EXAONE 2.0. Karta Hugging Face dla wariantu DSpark nadal informuje: „ten model nie jest wdrożony przez żadnego dostawcę wnioskowania”, a wymaganie 16×H200 oznacza, że trafia on do hostowanego API tylko wtedy, gdy ktoś z takim sprzętem zdecyduje się go hostować. To jest prawdziwy punkt tarcia: granica otwartych wag staje się coraz bardziej problemem serwowania, a nie dostępności.

Kiedy dostawca w końcu to wdroży, przyspieszenie dzięki dekodowaniu spekulatywnemu przełoży się na cenę za token, a koszt przełączenia się, aby to wypróbować, powinien być bliski zeru, jeśli Twoja aplikacja jest już model-agnostyczna. W OrcaRouter — jednym punkcie końcowym zgodnym z Open​AI obejmującym ponad 200 modeli, z ceną katalogową dostawcy przekazywaną z 0% narzutem — model, który trafia na dowolnego dostawcę upstream, staje się zmianą routingu, a nie ponowną integracją, a automatyczne przełączanie awaryjne oznacza, że zupełnie nowy model MoE 750B, który okazuje się wolny lub niestabilny, wraca do znanego, sprawdzonego modelu bez incydentu. Żeby była jasność: OrcaRouter nie hostuje dziś K-EXAONE-2.0-750B-A37B-DSpark i nie hostuje go także żadne inne API, które udało nam się znaleźć. Sednem warstwy routingu jest gotowość na dzień, w którym któryś z nich to zrobi.

Co oglądamy

• Scalenie dwóch PR-ów. #51558 (specyficzny dla modelu) i #52197 (konfiguracja ogólna) — oba są otwarte, bez zatwierdzeń. Scalenie i wydanie to właśnie to, co zamienia „wsparcie DSpark” z pull requestów w flagi, które faktycznie można przekazać.

• Zakres generycznej ścieżki. Jeśli #52197 zostanie scalony, każdy DSparkDraftModel typu qw​en​3 na Hugging Face będzie można załadować przez konfigurację — różnica między DSpark jako listą zatwierdzonych checkpointów a DSpark jako otwartym standardem.

• Pierwszy niezależny wynik. Każdy benchmark na karcie jest przeprowadzany przez LG. Pierwszy punkt danych Artificial Analysis lub arena dla koreańskiego MoE 750B będzie pierwszą liczbą, która nie została opublikowana przez producenta.

• DSpark poza Deep​Seek. LG i RadixArk to obecnie dwa niezależne podmioty produktyzujące metodę draftowania Deep​Seek, a ogólna ścieżka vLLM to trzeci sygnał, że stos technologiczny się konsoliduje.

• Skwantowane serwowanie. LG udostępnia checkpointy FP8 i NVFP4 modelu bazowego; skwantowany wariant DSpark, który mieści się na mniejszej liczbie GPU, zmieniłby ekonomikę szybciej niż jakikolwiek benchmark.

Najczęściej zadawane pytania

Czy K-EXAONE-2.0-750B-A37B-DSpark został wydany?

Wagi są na Hugging Face na licencji Apache 2.0, ale to nie jest historia premiery: wsparcie vLLM to dwa otwarte, niescalone pull requesty (#51558 i #52197), wartość przyspieszenia jest własnym wynikiem LG, a żaden dostawca nie hostuje modelu. To, co oznacza „potwierdzone” w tym kontekście, to ścieżka serwowania — ogólne wsparcie konfiguracji DSparkDraftModel istnieje już w publicznym PR z wykonywalnym planem testów — a nie to, że jakakolwiek wydana wersja vLLM może już go serwować.

Czym różni się K-EXAONE-2.0-750B-A37B od wariantu DSpark?

78 warstw modelu bazowego plus pięć warstw szkicowych DSpark do spekulacyjnego dekodowania — te same wagi pod spodem, te same benchmarki i szybszy w dekodowaniu artefakt serwowania, a nie inny model.

Czy DSpark należy do LG czy do Deep​Seek?

DSpark to otwartoźródłowa metoda dekodowania spekulatywnego firmy Deep​Seek, dostępna także w Deep​Seek-V4-Pro-DSpark i Deep​Seek-V4-Flash-DSpark; LG jest jak dotąd najbardziej znanym adoptującym, a Qw​en​3.8-2.4T-A95B-DSpark od RadixArk to drugi niezależny model proponujący oparty na tej samej metodzie. Karta modelu LG deklaruje ten sam zakres przyspieszenia 3–5×.

Czy mogę uruchomić K-EXAONE-2.0-750B-A37B-DSpark na własnym sprzęcie dzisiaj?

Tylko przez self-hosting: zgodnie z wytycznymi LG potrzebne jest minimum szesnaście GPU NVIDIA H200, a standardowe wydania vLLM, SGLang i Transformers wciąż wymagają niescalonych forków lub oczekującej ogólnej ścieżki konfiguracji, aby rozpoznać tę architekturę. Obsługa DSparkDraftModel w #52197 jest tym, co najbardziej przypomina wspólną ścieżkę, ale wciąż pozostaje otwartym pull requestem.

To, co sprawia, że warto to śledzić, to nie same pull requesty — lecz to, co sygnalizują. Flagowy koreański suwerenny model z 750 miliardami parametrów, na licencji Apache-2.0, zdecydował się wdrożyć stos spekulatywnego dekodowania Deep​Seek, niezależna firma inferencyjna zbudowała drafter DSpark dla modelu klasy max Qw​en​3.8, a vLLM odpowiada generyczną ścieżką konfiguracji zamiast łaty per-model. Tak właśnie przełomowe otwarte modele stają się realne — nie w momencie publikacji wag, ale w momencie, gdy draftery zostają zmergowane.