A.X K2 DSpark vs A.X K2: ドラフター専用モデルが実際にもたらすもの

A.X K2 DSparkとA.X K2を比較するという話で最も奇妙なのは、それが実際には比較にならないことだ。A.X K2 DSparkはA.X K2の代わりには使えない——そもそも単体ではまったく使えないのだ。これは「ドラフター専用チェックポイント」であり、SK Telecomが8月初旬に何の発表もなくHugging Faceにひっそりと公開したものだ。投機的デコード用のドラフトモデルであり、その役割はただ一つ、同社の6880億パラメータを擁するオープンウェイトのMixture-of-ExpertsフラッグシップであるA.X K2が、回答内容を変えずにより速くトークンを生成できるようにすることだ。つまり、この対決の本質的な問いは「どちらが優れているか」ではなく、「A.X K2をDSparkありで動かすべきか、なしで動かすべきか」である。この記事の内容はすべて出典を明記している。なぜなら、リポジトリが示すことと実際に測定されたことの隔たりこそが、すべての本質だからだ。

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

SK Telecomのモデルカードは、このモデルの用途について異例なほど率直だ。A.X K2 DSparkは「A.X K2向けのDSpark投機的デコード用ドラフトモデル」であり、「ドラフター専用チェックポイント: 単独での用途はなく、A.X K2と一緒に投機的デコードを通じてvLLMにロードされることを意図している」とされる。実際には、それをダウンロードし、互換性のあるvLLMをそれとA.X K2の両方に向けると、この2つがチームとして機能する: DSparkが候補トークンを提案し、A.X K2がそれらを検証し、検証されたトークンだけが出力される。

ドラフトメカニズムに関する2つの詳細がリポジトリからわかる。第一に、DSparkはドラフトシーケンスを1トークンずつ書くのではなく、複数の候補トークンを並列に提案する。これはA.X K2自身の隠れ表現と軽量な局所依存関係モデリングを利用している。第二に、この全体はロスレスになるように構築されている。つまり、すべての候補はコミットされる前にターゲットモデルによって検証されるため、A.X K2の出力分布は構造上変化しない。

このリリース自体は事前告知である。カードには、モデルは「現在最終検証中であり、数日以内に一般公開される予定」と記載され、評価は「現在進行中」であるとされている。カード上のスループット、TPOT、平均受理長のすべての指標は、まだTBD（未定）と記載されている。

なぜこの"versus"は本当は"with versus without"なのか

A.X K2 DSparkには単独での使用がないため、A.X K2の代わりにそれを選ぶシナリオは存在しない。選択肢は、A.X K2単体と、ドラフトモデルを組み合わせたA.X K2との間にある。出力品質に関しては、2つの構成は設計上同一であり、変動し得る唯一の軸はデコード速度である。

念のため、A.X K2が何であるかを述べておきます。A.X K2は、合計688B・アクティブ33BのMixture-of-Expertsデコーダーで、256のエキスパートに加えて1つの共有エキスパート（フォワードパスごとに8つがアクティブ）、61層、64のアテンションヘッド、163,840トークンの語彙を備え、7月29日にApache 2.0の下でオープンウェイトとして公開されました。約8.2兆トークンでMXFP8ネイティブに事前学習され、長いコンテキストを効率的に処理するためにSK TelecomのSparse Gated Attentionを採用し、262,144トークンのコンテキスト（ネイティブ128KをYaRNで256Kに拡張）に対応します。SK Telecomは、14のベンチマーク全体でA.X K1を平均+32.2ポイント上回り、長文コンテキストとエージェント評価では約83.9ポイントの向上を報告しています。これらはすべてベンダー報告によるものであり、独立した複合スコアはまだ公表されていません。

DSparkはそのアーキテクチャ専用に設計されています。カードには、A.X K2のMoE構造、アテンションレイアウト、およびネイティブ256K構成に適合しており、他のいかなるターゲットに対しても検証されていないと記載されています。同じ262,144トークンのコンテキストを継承しているため、ウィンドウサイズに関してはコストはかかりません。

モデルカードを読む：知ることはできるが、まだ確認されていない

このリポジトリは、モデルが何であるかを明確に示し、それではわからないことの短いリストも提供します。

今日知り得ること：

• これは、単独では使用されないドラフター専用チェックポイントであり、vLLMによって投機的デコードでA.X K2とともにロードされます。

• ライセンスはApache 2.0です。重みは自由にダウンロードして使用できます。

• コンテキスト長はA.X K2と同じ262,144トークンです。

• これは、SK TelecomのvLLMフォーク（SKT-AI/vllmリポジトリ、axk2-v0.23.0ブランチ）を介して、--speculative-configフラグを使用して実行されます。

この手法は、論文「DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation」(arXiv:2607.05147、2026年7月6日投稿)に記載されています。この論文は、後ほど引用される高速化の数値の出典でもあります。

• 現在、それをデプロイする推論プロバイダーは存在しないため、呼び出すためのホスト型APIはありません。

未確認：

• 公式発表 — カードは「数日以内に」公開リリースすると約束している。

• A.X K2固有の高速化数値。評価は進行中であり、すべてのパフォーマンス指標はTBDです。

• 負荷がかかった状態で実際にどれだけ効果があるか。カードはこれを「ワークロード依存」としている。

ドラフトモデルの独立した第三者による測定

DSparkが通常の投機的デコーディングと異なる点

投機的デコーディングは定番の手法だ。小型で高速なドラフトモデルが次の数トークンの推測を書き出し、大きなモデルがその推測全体を一度のフォワードパスで検証する。検証を通過したプレフィックス（接頭辞）を受け入れてから、1回の修正ステップを踏む。うまく使えば、品質を落とさずにレイテンシを劇的に削減できる。

DSpark論文が指摘する問題点は、最近の並列ドラフター（1回のパスで長いシーケンスを提案する方式）が「急速な受容率低下」（rapid acceptance decay）を起こすことだ。ドラフト内の後半のトークンが前半のトークンに依存していないため、拒否される頻度がはるかに高くなる。さらに、長いブロックを盲目的に検証すると、拒否される可能性が高いトークンにバッチ容量を浪費することになり、その結果、まさに高並行処理のサービス提供システムにおいてスループットが損なわれる。

DSparkは両方の問題に取り組む：

• 半自己回帰的なドラフティング。これは並列バックボーンと軽量な逐次モジュールを組み合わせ、ブロック内の依存関係モデリングを追加することで、後続のドラフトトークンが先行トークンに依存するようにします。これがサフィックス劣化を軽減する仕組みです。

• 信頼度スケジュール検証。固定ブロック長を検証する代わりに、推定されたプレフィックス生存確率とエンジンのスループット特性に基づいて、リクエストごとに検証長を調整する。これにより、検証は負荷を考慮したものになる。

論文の数字 — そして、数字が語らないこと

ここに引用される数字をご紹介します。DSparkは、MTP-1本番ベースラインと比較して、一致したスループットレベルで「ユーザーあたりの生成速度を60〜85%高速化します」。論文はまた、オフラインベンチマークにおいて、最先端の自己回帰型および並列ドラフターと比較して、受理長が大幅に改善されたと報告しており、厳格な対話性制約下での深刻なスループット低下を防ぐと述べています。

この特定の対戦カードにとって重要なので、注意書きをよく読んでほしい：その60〜85%という数字は、DeepSeek-V4のサービングシステム上で、実際のユーザートラフィック下で測定されたものであり——A.X K2上での測定ではない。これは、別のモデルのスタックに展開されたDSparkメソッドに関する主張である。対照的に、A.X K2のDSparkカードには、まだ高速化の数値が一切存在しない。したがって、この組み合わせにおける正直なスコアボードは次の通りである：構造上同一の出力、そして、メソッドの論文が妥当だと示唆しているものの、SK Telecom自身が、このドラフトチェックポイントの構築対象となったモデルではまだ測定していない高速化。

実際に実行するために必要なもの

前提条件の部分は、ほとんどの人が最初に挫折するところです。A.X K2 をセルフホストする必要があります。対象モデルにはホスト型APIが存在せず、オープンウェイトであり、688B/33BアクティブMoEを提供することは、重大なインフラ投資を意味します。DSparkが意味を持つのは、すでにその投資を行っているチームだけです。

もし持っているなら、ドラフトモデルを追加する限界費用は小さい：

Apache 2.0ドラフトチェックポイントをダウンロードし、SK TelecomのvLLMフォーク（axk2-v0.23.0ブランチ）を実行してください。

--speculative-config フラグを使用して投機的デコードを有効にし、DSpark チェックポイントを指定します。

• ドラフト重み用に余分なメモリを確保し、現在は標準のvLLMではなくベンダーフォークを使用していることを受け入れてください — これはメンテナンス上の考慮事項です。

• 検証にはコストがかかるという論文自身の注意書きを忘れてはならない。高並行性の下では、不注意な検証がバッチ容量を食いつぶす。これはまさに、confidence-scheduled verification（信頼度スケジュール検証）が対処すべく設計された障害モードである。

もう一つ知っておく価値のあること：Hugging Faceによると、このモデルのダウンロード数は「追跡されていない」ため、実際に試したチームの数について公に分かる情報はありません。

誰がどれを選ぶべきか

以下のいずれかに該当する場合は、プレーンなA.X K2を実行してください：

標準のvLLMを実行しており、パス上に別のチェックポイントやベンダーフォークを必要としない場合。

お使いのワークロードはスループットが律速ですがレイテンシは律速ではなく、ユーザーは長い生成を待つことを許容します。

• 公式リリースと最初の独立した計測を待つほうがよいでしょう。

あなたに当てはまる場合: A.X K2 と DSpark を実行してください。

• A.X K2をセルフホストしていて、生成レイテンシーやトークンスループットがボトルネックになっている。

• 長いコンテキストとエージェント型ワークロードは、ユーザーに長い出力を待たせる — 投機的デコードが想定している領域である。

事前発表コンポーネントを実行することに抵抗がない。そのデメリットは限定的で、最悪の場合でも役に立たないだけで、出力品質を変えることはない。

688B MoEをまったくセルフホストしないのであれば、どちらも選ばないのが正解だ。A.X K2の主権性と韓国語の強みは、自分で実行して初めて得られるものであり、多くのチームはその代わりに、ホステッドカタログを通じてフロンティアのオープンモデルに到達するだろう。そこで、統合をモデル非依存に保つことが効いてくる。OrcaRouterの単一のOpenAI互換エンドポイントは、プロバイダーの定価・マークアップ0%で200以上のモデルをカバーし、自動フェイルオーバーと、複数のモデルを1回の呼び出しに合成するためのルーティングDSLを備えている。（A.X K2もA.X K2 DSparkも、現時点ではどこにもホストされていない——OrcaRouterにもだ——つまりこれは、この2つのルーティングではなく、それ以外のスタックに関する話だ。）この姿勢はやはり適用できる。未検証のモデルをトラフィックの一部で試し、自動的にフェイルオーバーするのであって、本番パスをそのモデルに賭けるのではない。

次に見るもの

現状は単純だ。リポジトリは実在し、手法は文書化されているが、計測結果は存在しない。注目すべきは次の3点だ。約束された公開リリース（カードには「数日以内」とある）、SKテレコムの評価が終了し次第出てくる最初のA.X K2固有のスループットまたはレイテンシ数値、そして推論プロバイダーがこのペアを採用するかどうか——これこそが、セルフホストしないチームにとってDSparkを意味のあるものにする点だ。

よくある質問

A.X K2 DSparkはA.X K2を置き換えられますか？

いいえ。これはドラフター専用のチェックポイントであり、単独での使用用途はありません。A.X K2のデコードを高速化するために存在するのであって、その代替となるものではありません。A.X K2なしでA.X K2 DSparkを実行することはできません。

DSparkはA.X K2の出力品質を変えますか？

いいえ、構造上そうなっています。すべての候補トークンはコミットされる前に A.X K2 によって検証されるため、出力分布は変わりません。カードではこのアプローチをロスレスと説明しています。

DSparkを使うには、A.X K2をセルフホストする必要がありますか？

はい。DSparkはvLLMによってA.X K2と一緒にロードされるため、688Bターゲットを実行していない限り、ドラフトする対象はありません。現在、どちらのモデルにもホスト型APIはありません。

DSpark は他のモデルでも動作しますか？

SK Telecomは、A.X K2のMoEアーキテクチャ、アテンション構造、および256Kコンテキスト向けにこれを設計しており、他のターゲットに対する検証は行っていません。

評決

A.X K2 DSpark と A.X K2 の「対決」に対する正直な答えは「両方」です。すでに A.X K2 を運用していて、ユーザーが長い生成時間を待つ状況にあるなら、ドラフトモデルは無料で低リスクな実験です。Apache 2.0 のウェイトで、最悪の場合でも高速化は見込めず、設計上、品質が低下する可能性もありません。レイテンシーがボトルネックではない場合、あるいはそもそも 688B MoE をセルフホスティングしていない場合は、SK Telecom の評価数値が出て、約束された公開リリースによってモデルが正式になるまで、この話題は無視して問題ありません。やってはいけないのは、論文の 60〜85% という数字をこのモデルの実測値と勘違いすることです。現時点では、A.X K2 における DSpark 固有のすべては、まだ TBD です。