A.X-K2-DSpark: SK Telecom の投機的デコーディング用ドラフトモデルがひっそりと登場

A.X-K2-DSparkは、おそらく直接呼び出すことはないだろうモデルだ。そして、まさにその理由から、読む価値がある。SK TelecomがHugging Faceにひっそりと公開したもので、その背後には発表記事もプレスリリースもない。モデルカードはただ、このチェックポイントが「現在最終検証中であり、数日以内に一般公開が予定されている」と述べるところから始まる。これは投機的デコーディング（speculative decoding）用のドラフター専用チェックポイントであり、その仕事はただ一つ、SK Telecomの688BパラメータのフラッグシップモデルであるA.X K2が後で検証するトークンを提案することで、同モデルをより高速かつ低コストで提供できるようにすることだ。以下では、リポジトリが実際に示していること、まだ確認されていないこと、そしてなぜこのような小さなヘルパーモデルに、LLMサービス提供コスト削減の次の一手が潜んでいるのかを説明する。

A.X-K2-DSpark とは実際には何か

A.X-K2-DSparkは、意味のある意味での単体モデルではありません。モデルカードの想定用途に関する注記には、それが「ドラフター専用チェックポイント」であり「単体での使用はできない」と明記されています。このモデルはvLLMによって、対象モデルであるA.X K2とともに、投機的デコードループの中で読み込まれます。つまり、2段階生成器のドラフト段階です。小さなモデルが候補トークンを高速に提案し、対象モデルがそれらを検証してから、出力にトークンが確定されます。

文脈として、このターゲットは現存する最大級のオープンウェイトモデルの一つである。A.X K2は、SK Telecomの総パラメータ688B・アクティブパラメータ33BのMixture-of-Expertsモデルであり、2026年7月下旬にApache 2.0ライセンスのもとでHugging Faceに公開された。基本アーキテクチャは、Multi-head Latent AttentionとDeepSeek Sparse Attentionを組み合わせ、SK Telecom独自のSparse Gate Attentionによる長文脈対応の改良を加えたものだ。A.X-K2-DSparkは、A.X K2の隠れ状態に条件付けし、候補位置間の軽量な局所的依存関係のモデリングを追加することで、厳密に自己回帰的にドラフトを生成する代わりに、複数のトークンを並列に提案できる。そして各候補はコミット前にA.X K2によって検証される。これこそが、モデルカードがその結果を「構造上ロスレス（lossless by construction）」と呼ぶ理由であり、出力分布はドラフターによって変化せず、変化するのはサービング速度だけなのである。

投機的デコーディングの仕組みと、688B MoEにそれが不可欠な理由

投機的デコード（スペキュラティブデコーディング）が必要なのは、自己回帰生成が逐次的であり、メモリ律速であるためです。トークンを1つ生成するたびにモデルの重みをメモリから読み出す必要があり、688B（6880億）パラメータのモデルでは、1トークンごとに転送すべきバイト数が膨大になります。たとえ1回のフォワードパスで活性化するのが33B（330億）パラメータだけでも同様です。この工夫は、小さなドラフタに少しだけ余分な計算をかけ、次の複数トークンを一気に推測させ、そのうえで大きなモデルがすべての推測を1回のフォワードパスで検証し、自身の分布と一致する最長のプレフィックスを保持する、というものです。ドラフタが優れていれば、大きなモデルの1回のパスにつき1トークンではなく2〜3トークンを得られ、最終出力は変わりません。

勝負のすべては受理率です。推測が下手なドラフターは提案を拒否され、検証パスは依然として同じメモリ帯域幅を消費するため、高速化の効果は消え去ります。だからこそドラフターは、それ自体が真剣な研究テーマになりつつあります。A.X K2規模のモデルの場合、1.5倍と3倍の高速化の差は、GPU 10基からなるサービング環境と、5基からなるサービング環境の差に相当します。ホステッドLLM APIの次の値下げラウンドは、このような効率化レイヤーからもたらされるでしょう。ベースモデルの品質指標からではなく、その周りに積み上げられたサービングスタックからです。

DSparkはその手法です——それはDeepSeekチームから生まれたものです

モデル名の「DSpark」は特定の技術であり、SKテレコムの発明ではありません。モデルカードは論文「DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation」（arXiv 2607.05147）を引用しています。これは2026年7月6日のプレプリントで、DeepSeekの33名の著者チームによるもので、著者らは本手法を自分たちのV4世代のサービングシステムに本番トラフィック下で導入しました。SKテレコムは同じ技術を自社のターゲットモデルに適用しています。

この論文の2つの貢献は、A.X-K2-DSparkカードが説明する内容に直接対応している。第一に、半自己回帰的ドラフティング：並列バックボーンがウィンドウ全体にわたってトークンを提案し、軽量な逐次モジュールが候補位置間の依存関係をモデル化することで、並列ドラフターの受理率が提案シーケンス全体で急激に低下するという古典的な問題を解決する。第二に、信頼度スケジュール検証：常に固定数のドラフトトークンを検証する代わりに、システムは各プレフィックスが生き残る確率を推定し、エンジンのスループットプロファイルに合わせてリクエストごとの検証長を設定する。これにより、検証の労力は均一ではなく負荷に応じたものになる。

論文自身の数値（著者による測定値であり、独立に検証されたものではない）によれば、{{1}}DSparkは、同等のスループット条件下で、本番環境のMTP-1ベースラインと比較してユーザーあたりの生成速度が60〜85%高速化され、厳格な対話性制約の下での深刻なスループット低下を防ぎました。{{/1}} このリリースを読む際には、2つの注意点があります。{{2}}これらの結果は、A.X K2ではなく著者自身のスタックとターゲット上で測定されたものであり、A.X-K2-DSparkモデルカードには、その評価がまだ進行中であると明記されています。{{/2}} {{3}}この論文は、この手法が本番環境で機能することを証明しています。しかし、SK Telecomのチェックポイントがその改善を再現することを証明しているわけではありません。そこがまさに未確認の部分です。{{/3}}

リポジトリが語ること — そして語らないこと

現在リポジトリから分かることは、すべてモデルカードからのものです：

• 役割 — A.X K2 用のドラフター専用チェックポイント。単独使用は不可。他のターゲットでは検証されておらず、「無関係なモデルとは非互換」。

• ターゲット — A.X K2、合計688B / アクティブ33BのMixture-of-Experts。

• コンテキスト長 — 262,144トークン（256K）、A.X K2のネイティブ構成に一致。

• ライセンス — Apache 2.0.

• メカニズム — DSparkの半自己回帰ドラフト方式。コミット前にA.X K2がすべての候補を検証（ロスレス）。

• ステータス —「現在最終検証中」；リリースは「数日以内」を予定。

そして、以下はまだ明示的に確認されていないものです：

• チェックポイントの精度とサイズ — どちらもモデルカードではTBDと記載されています。

• スループット、TPOT、平均受理長 — ドラフターが実際に機能するかどうかを示す3つの数値はすべて未定で、「評価は現在進行中です」と記載されている。

• 分野別の結果 — このカードは韓国語、数学、理科、コードの内訳を「後日」約束しているが、日付はない。

• 公式発表 — SK Telecomは、私たちが確認できる限り、A.X-K2-DSparkをどこにも発表していません。リポジトリが発表そのものです。

• 独立したスコア — 存在しない。カードに記載されているのはすべてSK Telecom自身の主張であり、その大半はまだ約束にすぎない。

最も重要な未確認の数値は、平均受理長（mean accepted length）、つまりA.X K2が検証パスごとに受理するドラフトトークンの平均数です。このひとつの数値によって、このドラフターが1.2倍のちょっとした改善なのか、2.5倍のサービスアップグレードなのかが決まります。また、リリースが公開された後、その数値は出所が不明のまま流通する可能性が最も高い数値でもあります。この数値が登場した際は懐疑的に扱ってください。DSparkの論文の60〜85%という数値は、別のモデルのサービングスタックで測定されたものであり、A.X K2には独自のドラフト受理特性があります。

実際にどうやって実行するか

{{1}}ドラフターを実行することは、SK Telecom の vLLM フォークから A.X K2 を提供することを意味します。{{/1}} {{2}}モデルカードの例を少し簡略化したものは、次のとおりです。{{/2}}

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}'

SKT-AI vLLMリポジトリのaxk2-v0.23.0ブランチからインストールされたフォークを使用します。このカードが明示している注意点がいくつかあります：このセットアップはA.X K2のネイティブな256Kコンテキスト構成を対象としており、高速化はワークロード依存です — 並行性、出力長、受容率、そしてドラフト生成と検証の相対的なコストがすべて結果に影響します。言い換えれば、これはダウンロードして実行するスクリプトではなく、推論サーバー基盤です。必要なのは、A.X K2の重みと、テンソル並列度8に対応できる十分な規模のクラスタ、そしてnum_speculative_tokensを自社のトラフィックに合わせてチューニングする忍耐力です。これはすでにA.X K2を運用しているチームにとって有意義なプロジェクトです。A.X K2を新たに立ち上げる理由にはなりません。

経済学：効率性のレイヤーは品質の主張に勝る

688Bモデル用のドラフトモデルが注目に値する理由は、ベースモデルのベンチマーク競争がほぼ頭打ちになっている一方で、推論コスト競争はまだ続いているからだ。SKテレコム自身の発表もすでに効率性を重視しており、スパースゲートアテンションの変更により、120Kトークンの入力で前世代と比較して総トークンスループットが67.7%向上したとされている。ドラフターも同じ考え方をデコードに適用したものであり、受け入れられたドラフトトークンはそれぞれ、支払いを回避できた大規模モデルのフォワードパスを意味する。

APIを通じてこれらのモデルを利用し、自前でホストしない人にとって、ドラフトモデルは見えない存在です。そして、それが重要なポイントです。プロバイダーがサービングスタックに投機的デコーディングを追加すると、新しいモデルが見えるわけではなく、同じモデルがトークンあたりにより速く、より安くなるだけです。価格設定レイヤーが重要なのも同じ理由からです。OrcaRouterでは、プロバイダーの定価をマークアップ0%でそのまま通しています。そのため、ベンダーのサービング効率の改善が価格引き下げとして現れた場合、再交渉も契約変更もなしに、同じ日に当社側で反映されます。また、実証されておらず成功するかどうかわからないモデルについても、自動フェイルオーバー付きルーティングを使えば、本番パスを賭けずに試すことができます。APIキー一つで、最初のプロバイダーの性能が低下した場合、リクエストは別のプロバイダーにフォールオーバーします。

今回のリリースに固有の正直な注意点をひとつ述べます。A.X-K2-DSpark はドラフター専用チェックポイントであり、ホスト型モデル API がルーティングできるものではありません（当社の API も含めて）。ドラフターはサービング側のコンポーネントであり、呼び出し可能な製品ではありません。ドラフターがリリースされ、評価数値が出揃ったとき、価格表に載るのは、より高速で低コストな A.X K2 であって、「DSpark」という新しいエンドポイントではありません。

答える価値のあるいくつかの質問

A.X-K2-DSpark は単独で使用できますか？いいえ — それがこのリリースの定義的な事実です。これはドラフター専用のチェックポイントであり、単独での使用も公開APIもありません。A.X K2 を提供する vLLM 投機的デコードループ内のヘルパーとしてのみ存在し、カードには他のターゲットでの検証は行われていないと記載されています。

A.X-K2-DSpark は A.X K2 の競合製品ですか？ その逆です。これは A.X K2 のアクセラレーターです。同じモデルがより高速になり、出力分布は変わりません。ラインナップへの新規追加ではなく、後付けの効率向上パーツとお考えください。

実際にはいつリリースされるのですか？ モデルカードによると、最終検証中であり、公開リリースは「数日以内」に予定されているとのことです。確認されているのはそれだけです。注目すべき日は、TBD（未定）の数値——スループット、TPOT、平均受理長——が埋められる日です。なぜなら、その時点でリリースは約束ではなくなり、評価できるものになるからです。

A.X K2をAPI経由で使用する場合、それについて考慮する必要がありますか？おそらく直接は必要ありません。APIの背後にあるサービングスタックが、ドラフターがループ内にいるかどうかを決定します。結果は価格とレイテンシーとして見え、フラグとしては見えません。これはA.X K2をセルフホスティングするチームに最も重要なことです。そこでは、オプトインが彼らが管理するvLLM設定変更となるからです。

ここでの本題はドラフター自体ではなく、ドラフターが示唆するものだ。効率化の仕事は静かに独自のリリースカテゴリとなりつつあり、今年の最も興味深い新モデルは、より大きなモデルではなく、大きなモデルを安価にするヘルパーが増えている。A.X-K2-DSparkはこれまでで最も明確な例だ。単独では用途のないチェックポイントであり、発表前に投稿され、その傍証のほとんどをTBDのまま抱えている。数値が明らかになったら許容長の数字に注目し、DSpark論文の成果はこのチェックポイントへの約束ではなく手法の由来として捉えること。そして自らA.X K2を運用するなら、ベンチマークの予算を組んでおくべきだ。それこそが、ひっそりと投稿されたドラフターが1.2倍のささやかな改善なのか、本物なのかを知る唯一の方法だからだ。