
A.X-K2-DSpark: Model draftowy do spekulatywnego dekodowania od SK Telecom zadebiutował bez zapowiedzi
- metaNOWOŚĆMeta: Muse Spark 1.22026-08-0557Inteligencja72Kod
- qwenNOWOŚĆQwen: Qwen3.8 Max2026-08-0358Inteligencja72Kod
- deepseekNOWOŚĆDeepSeek: DeepSeek V4 Flash 07312026-07-3152Inteligencja69Kod
- minimaxNOWOŚĆMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 za 1 mln tokenów · 2100 tok/s
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463Inteligencja78Kod
- googleGoogle: Gemini 3.6 Flash2026-07-2152Inteligencja69Kod
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137Inteligencja49Kod
- metaMeta: Muse Spark 1.12026-07-1653Inteligencja71Kod
- kimiMoonshotAI: Kimi K32026-07-1560Inteligencja76Kod
- openaiOpenAI: GPT-5.6 Luna2026-07-0952Inteligencja71Kod
- openaiOpenAI: GPT-5.6 Terra2026-07-0957Inteligencja77Kod
- openaiOpenAI: GPT-5.6 Sol2026-07-0961Inteligencja77Kod
- grokxAI: Grok 4.52026-07-0856Inteligencja72Kod
- tencentTencent: Hy32026-07-0642Inteligencja59Kod
- obsidianQwen3.6 35B A3B Uncensored (Aggressive)2026-07-0232Inteligencja42Kod
- obsidianGemma4 26B A4B Uncensored (Balanced)2026-07-0226Inteligencja39Kod
- anthropicAnthropic: Claude Sonnet 52026-06-3055Inteligencja72Kod
- klingKling: Kling 3.0 Turbo2026-06-1757Inteligencja52Kod57Matematyka
{{KEEP}}A.X-K2-DSpark{{/KEEP}} to model, którego prawdopodobnie nigdy nie wywołasz bezpośrednio — i właśnie dlatego warto o nim przeczytać. SK Telecom opublikował go po cichu na Hugging Face, bez posta o premierze i bez komunikatu prasowego; karta modelu zaczyna się po prostu od stwierdzenia, że checkpoint {{1}}„obecnie znajduje się w końcowej walidacji, a jego publiczne udostępnienie planowane jest w ciągu najbliższych kilku dni"{{/1}}. To checkpoint pełniący wyłącznie rolę draftora w spekulatywnym dekodowaniu, zbudowany do jednego zadania: sprawienia, by serwowanie {{2}}flagowego modelu A.X K2 o 688 mld parametrów{{/2}} od SK Telecom było szybsze i tańsze dzięki proponowaniu tokenów, które następnie weryfikuje A.X K2. Oto, co repozytorium faktycznie nam mówi, co wciąż pozostaje niepotwierdzone i dlaczego taki mały model pomocniczy to miejsce, gdzie kryją się kolejne obniżki kosztów serwowania LLM-ów.
Czym tak naprawdę jest A.X-K2-DSpark
A.X-K2-DSpark nie jest samodzielnym modelem w żadnym istotnym sensie. Karta modelu stwierdza to w notatkach o zamierzonym użyciu: jest to „punkt kontrolny tylko do szkicowania” z „brakiem samodzielnego zastosowania”, ładowany przez vLLM wraz z modelem docelowym, A.X K2, w pętli dekodowania spekulacyjnego. Jest to etap szkicowania w dwustopniowym generatorze — mały model szybko proponuje tokeny-kandydatów, a model docelowy weryfikuje je, zanim którykolwiek token zostanie ostatecznie zatwierdzony na wyjściu.
Dla kontekstu: chodzi tu o jeden z największych modeli o otwartych wagach, jakie istnieją. A.X K2 to model Mixture-of-Experts firmy SK Telecom z łączną liczbą 688B parametrów, z czego 33B aktywnych, udostępniony na Hugging Face pod koniec lipca 2026 r. na licencji Apache 2.0, zbudowany na bazowej architekturze, która łączy Multi-head Latent Attention z DeepSeek Sparse Attention i dodaje autorską modyfikację SK Telecom do obsługi długiego kontekstu — Sparse Gate Attention. A.X-K2-DSpark jest warunkowany stanami ukrytymi A.X K2 i dodaje lekkie modelowanie lokalnych zależności między pozycjami kandydatów, dzięki czemu może proponować kilka tokenów równolegle, zamiast generować je w sposób ściśle autoregresyjny. Każdy kandydat jest następnie weryfikowany przez A.X K2, zanim zostanie zatwierdzony — dlatego karta modelu nazywa wynik „bezstratnym ze swej konstrukcji”: rozkład wyjściowy pozostaje niezmieniony pod wpływem modelu proponującego; zmienia się tylko prędkość serwowania.

Jak działa dekodowanie spekulatywne i dlaczego 688B MoE tego potrzebuje
Dekodowanie spekulacyjne istnieje, ponieważ generowanie autoregresyjne jest szeregowe i ograniczone pamięcią. Wygenerowanie każdego tokenu oznacza odczytanie wag modelu z pamięci, a dla modelu 688B to ogromna liczba bajtów, które trzeba przenieść dla każdego pojedynczego tokenu — nawet gdy w każdym przejściu w przód aktywnych jest tylko 33B parametrów. Sztuczka polega na poświęceniu odrobiny dodatkowej mocy obliczeniowej na mały drafter, który zgaduje kilka kolejnych tokenów naraz, a następnie na tym, by duży model zweryfikował wszystkie zgadywania w jednym przejściu w przód i zachował najdłuższy prefiks zgodny z jego własnym rozkładem. Gdy drafter jest dobry, z jednego przejścia dużego modelu uzyskujesz dwa lub trzy tokeny zamiast jednego, bez zmiany końcowego wyniku.
Cała gra opiera się na wskaźniku akceptacji. Model szkicujący, który źle zgaduje, ma odrzucane propozycje, a etap weryfikacji nadal kosztuje tyle samo przepustowości pamięci, więc przyspieszenie ulatnia się. Dlatego modele szkicujące stały się same w sobie poważnym tematem badań: dla modelu wielkości A.X K2 różnica między przyspieszeniem 1.5x a 3x to różnica między flotą serwerową z dziesięciu GPU a taką z pięciu. Warstwy wydajnościowe tego typu to źródło kolejnej rundy obniżek cen w hostowanych API LLM — nie z liczb dotyczących jakości modelu bazowego, ale ze stosu serwerowego, który jest wokół nich zbudowany.
DSpark to metoda — i pochodzi od zespołu DeepSeek
„DSpark” w nazwie modelu to konkretna technika i nie jest wynalazkiem SK Telecom. Karta modelu cytuje pracę „DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation” (arXiv 2607.05147) — preprint z 6 lipca 2026 roku, przygotowany przez 33-osobowy zespół z DeepSeek, który wdrożył tę metodę we własnym systemie serwującym z epoki V4 przy rzeczywistym ruchu. SK Telecom zaadaptował tę samą technikę do własnego modelu docelowego.
Dwa wkłady artykułu odpowiadają bezpośrednio temu, co opisuje karta A.X-K2-DSpark. Po pierwsze, półautoregresyjne draftowanie: równoległy backbone proponuje tokeny w obrębie okna, podczas gdy lekki moduł sekwencyjny modeluje zależności między pozycjami kandydatów, rozwiązując klasyczny problem polegający na tym, że wskaźniki akceptacji równoległych drafterów gwałtownie spadają wzdłuż proponowanej sekwencji. Po drugie, weryfikacja z planowaniem opartym na ufności: zamiast zawsze weryfikować stałą liczbę tokenów szkicu, system szacuje prawdopodobieństwo, że każdy prefiks przetrwa weryfikację, i ustala długość weryfikacji dla każdego żądania, dopasowaną do profilu przepustowości silnika — dzięki czemu nakład pracy weryfikacyjnej zależy od obciążenia, a nie jest jednolity.
Na podstawie własnych liczb z artykułu — które są pomiarami autorów, niezweryfikowanymi niezależnie — DSpark osiągnął o 60–85% szybszą generację na użytkownika niż produkcyjna linia bazowa MTP-1 przy dopasowanej przepustowości, a także zapobiegł poważnej degradacji przepustowości w warunkach rygorystycznych ograniczeń interaktywności. Przy czytaniu tej informacji należy pamiętać o dwóch zastrzeżeniach. Te wyniki zmierzono na własnym stosie i celu autorów, a nie na A.X K2; a karta modelu A.X-K2-DSpark wprost stwierdza, że jego własna ocena wciąż trwa. Artykuł dowodzi, że metoda działa w produkcji. Nie dowodzi natomiast, że punkt kontrolny SK Telecom odtwarza te zyski — to właśnie ta niepotwierdzona część.

Co mówi repo — a czego nie mówi
Oto, co można obecnie ustalić na podstawie repozytorium — wszystko z karty modelu:
• Rola — punkt kontrolny wyłącznie dla draftera A.X K2; nie do samodzielnego użytku; niezwalidowany z żadnym innym modelem docelowym i „niezgodny z niepowiązanymi modelami.”
• Cel — A.X K2, 688B łącznie / 33B aktywne Mixture-of-Experts.
• Długość kontekstu — 262 144 tokeny (256K), zgodnie z natywną konfiguracją A.X K2.
• Licencja — Apache 2.0.
• Mechanizm — Półautoregresyjne draftowanie DSpark; każdy kandydat weryfikowany przez A.X K2 przed zatwierdzeniem (bezstratnie).
• Status — „obecnie trwa końcowa walidacja"; premiera planowana „w ciągu najbliższych kilku dni".
A oto, czego wyraźnie jeszcze nie potwierdzono:
• Precyzja i rozmiar punktu kontrolnego — oba wymienione jako TBD na karcie modelu.
• Przepustowość, TPOT i średnia akceptowana długość — trzy liczby, które powiedziałyby ci, czy moduł szkicujący faktycznie działa, wszystkie TBD, z adnotacją „ocena jest obecnie w toku".
• Wyniki według dziedzin — karta obiecuje rozbicie na koreański, matematykę, nauki ścisłe i programowanie „później", bez podania daty.
• Oficjalne ogłoszenie — SK Telecom nie ogłosiło A.X-K2-DSpark nigdzie, gdzie moglibyśmy to znaleźć; repozytorium jest ogłoszeniem.
• Niezależne oceny — nie istnieją. Wszystko na karcie to własne deklaracje SK Telecom, a większość z nich to wciąż obietnice.

Najważniejszą niepotwierdzoną liczbą jest średnia długość akceptacji — średnia liczba tokenów szkicu akceptowanych przez A.X K2 w jednym przebiegu weryfikacji. Ta jedna liczba decyduje, czy ten model szkicujący to 1.2x miły dodatek, czy 2.5x poważne ulepszenie serwowania; to również liczba, która najprawdopodobniej zacznie krążyć bez podania źródła, gdy wydanie trafi na produkcję. Traktuj ją sceptycznie, gdy się pojawi: wartość 60–85% z artykułu DSpark zmierzono na stosie serwowania innego modelu, a A.X K2 ma własne charakterystyki akceptacji szkiców.
Jak faktycznie to uruchomić
Uruchomienie draftera oznacza serwowanie A.X K2 z forka vLLM należącego do SK Telecom. Przykład z karty modelu, lekko skrócony, to:
vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'
z zainstalowanym forkiem z repozytorium SKT-AI vLLM w gałęzi axk2-v0.23.0. Karta otwarcie mówi o kilku zastrzeżeniach: konfiguracja ta celuje w natywną konfigurację kontekstu 256K A.X K2, a przyspieszenie zależy od obciążenia — na wynik wpływają współbieżność, długość odpowiedzi, wskaźnik akceptacji oraz względny koszt generowania propozycji w porównaniu z weryfikacją. Innymi słowy, to infrastruktura serwująca, a nie skrypt do pobrania i od razu uruchomienia. Potrzebujesz wag A.X K2, klastra wystarczająco dużego do tensor-parallel 8 oraz cierpliwości, aby dostroić num_speculative_tokens do własnego ruchu. To wartościowy projekt dla zespołu, który już obsługuje A.X K2; nie jest to jednak powód, aby taką infrastrukturę stawiać od zera.
Ekonomia: warstwy efektywności biją deklaracje jakości.
Powodem, dla którego warto śledzić model draftujący dla modelu 688B, jest to, że wyścig benchmarków modeli bazowych w dużej mierze się nasycił, a wyścig kosztów serwowania — nie. Własna premiera SK Telecom już stawiała na wydajność — zmiana Sparse Gate Attention miała zwiększyć całkowitą przepustowość tokenów o 67,7% w porównaniu z poprzednią generacją przy wejściach 120K tokenów — a model draftujący to ta sama teza zastosowana do dekodowania. Każdy zaakceptowany token draftu to przejście dużego modelu w przód, za które nie płacisz.
Dla każdego, kto korzysta z tych modeli przez API, a nie hostuje ich samodzielnie, drafter jest niewidoczny — i o to właśnie chodzi. Gdy dostawca dodaje dekodowanie spekulatywne do swojego stacku serwującego, nie widzisz nowego modelu; widzisz ten sam model, który staje się szybszy i tańszy w przeliczeniu na token. Warstwa cenowa ma znaczenie z tego samego powodu: w OrcaRouter przekazujemy cenę katalogową dostawcy w całości, z zerową marżą, więc gdy praca dostawcy nad wydajnością serwowania przełoży się na obniżkę ceny, u nas obowiązuje ona tego samego dnia — bez renegocjacji, bez zmian w umowie. A w przypadku niezweryfikowanego modelu, który może się sprawdzić lub nie, routing z automatycznym failoverem to sposób, by go wypróbować bez stawiania na niego ścieżki produkcyjnej: jeden klucz API — jeśli pierwszy dostawca zacznie zawodzić, żądanie automatycznie przechodzi do innego.
Jedna szczera uwaga dotycząca tej wersji: A.X-K2-DSpark to checkpoint wyłącznie dla draftera, więc nie jest to coś, co API hostowanego modelu może routować — w tym nasze. Draftery są komponentem po stronie serwowania, a nie wywoływalnym produktem. Gdy drafter zostanie wydany i pojawią się wyniki ewaluacji, w cenniku pojawi się szybszy, tańszy A.X K2 — a nie nowy endpoint o nazwie „DSpark".
Kilka pytań, na które warto odpowiedzieć
Czy mogę używać A.X-K2-DSpark samodzielnie?Nie — to jest fakt definiujący tę wersję. To checkpoint przeznaczony wyłącznie dla draftera, bez samodzielnego zastosowania i bez publicznego API; istnieje wyłącznie jako pomocnik w pętli spekulatywnego dekodowania vLLM obsługującej A.X K2, a karta modelu informuje, że nie został zwalidowany z żadnym innym modelem docelowym.
Czy A.X-K2-DSpark jest konkurentem dla A.X K2? Wręcz przeciwnie. Jest akceleratorem dla A.X K2 — ten sam model działa szybciej, a rozkład wyjść pozostaje niezmieniony. Można to traktować jako dołączaną część zwiększającą wydajność, a nie nową pozycję w ofercie.
Kiedy tak naprawdę zostanie wydany? Karta modelu mówi, że jest w końcowej walidacji i planowane jest publiczne wydanie „w ciągu najbliższych kilku dni”. To wszystko, co zostało potwierdzone. Datą, na którą warto uważać, jest dzień, w którym wartości TBD — przepustowość, TPOT i średnia akceptowana długość — zostaną uzupełnione, ponieważ wtedy wydanie przestaje być obietnicą, a staje się czymś, co można ocenić.
Czy muszę o tym myśleć, jeśli używam A.X K2 przez API?Prawdopodobnie nie bezpośrednio. Stos serwujący stojący za API decyduje, czy w pętli znajduje się drafter; wynik widzisz jako cenę i opóźnienie, a nie jako flagę. Ma to największe znaczenie dla zespołów samodzielnie hostujących A.X K2, gdzie włączenie tej opcji to zmiana konfiguracji vLLM, którą kontrolują.
Sedno sprawy to nie sam model szkicujący — ale to, co on sygnalizuje. Praca nad wydajnością po cichu staje się odrębną kategorią wydawniczą, a najciekawsze nowe modele w tym roku to coraz częściej pomocnicy, którzy sprawiają, że duże modele są tanie, a nie większe modele. A.X-K2-DSpark jest dotąd najwyraźniejszym przykładem: punkt kontrolny bez samodzielnego zastosowania, opublikowany przed ogłoszeniem, niosący większość swoich dowodów jako TBD. Zwróć uwagę na wskaźnik akceptowanej długości, gdy się pojawi, traktuj osiągnięcia z pracy DSpark jako pochodzenie metody, a nie obietnicę dla tego punktu kontrolnego, a jeśli sam serwujesz A.X K2, zaplanuj budżet na benchmark — to jedyny sposób, aby dowiedzieć się, czy cicho opublikowany model szkicujący to 1.2x'owy drobiazg, czy prawdziwa sprawa.
