K-EXAONE-2.0-750B-A37B-DSpark：LGの750B韓国語MoEがvLLMに登場

2026年8月9日、vLLMリポジトリにK-EXAONE-2.0-750B-A37B-DSparkを追加するプルリクエストが開かれた。これはLG AI Researchの7500億パラメータの韓国語フラッグシップの投機的デコーディング変種である。4日後の8月13日、2つ目でより基礎的なPRがリークを具体的にした。vLLMは現在、汎用のDSparkDraftModel設定パスを持つようになり、architectures=DSparkDraftModelを宣言しmodel_type=qw​en​3を持つ任意のHugging Faceチェックポイントを、認識済みのQw​en3DSparkModelにマッピングする。さらに、実際にRadixArk Qw​en​3.8-2.4T-A95B-DSparkドラフターをdsparkスペック方式で提供するテスト計画も含まれている。基本モデルK-EXAONE-2.0-750B-A37Bは7月31日にApache 2.0でリリースされ、vLLMはリリース時にはMTPドラフト方式では提供できたが、DSparkには対応していなかった。DSparkはLGが併せて提供し、3〜5倍のデコード高速化が見込めると主張するドラフターである。DSpark自体はDeep​Seekの手法で、Deep​Seek-V4-Pro-DSparkとDeep​Seek-V4-Flash-DSparkで動作するのと同じ半自己回帰的ドラフターである。したがって、この2つのPRは、Deep​Seekの投機的デコーディングスタックがオープンウェイトのデフォルトになりつつあることを示す最も明確な兆候である。

これは現時点で判明していることをまとめた記事であり、発表記事ではありません。両方のプルリクエストはオープンかつ未マージであり、DSparkチェックポイントには独立したベンチマークがなく、LGの高速化数値はベンダーによる主張です。以下のすべては、それに応じてラベル付けされています。今日確かなことは、ウェイトがHugging Faceにあり、ベースモデルがリリースされ、vLLMのDSparkスペックデコーダーがすでにDeep​SeekとKim​iのチェックポイントを処理していること、そしてサードパーティのDSparkドラフターを読み込めるようにする汎用設定パス——このリークが待ち望んでいた部分——が、現在公開プルリクエストにあり、テスト済みだがまだリリースされていないことです。

短いバージョン

• 2026年8月9日にオープンした PR #51558 は、K-EXAONE-2.0-750B-A37B-DSpark を vLLM に追加するものです。まだ承認はなく、オープン状態です。

- PR #52197は2026年8月13日にオープンし、汎用DSparkDraftModel設定サポートを導入します — architectures=DSparkDraftModel、model_type=qw​en​3、そしてQw​en3DSparkModelに正規化されます — そのテスト計画は、dspark specメソッドと7つのspecトークンを用いてRadixArk Qw​en​3.8-2.4T-A95B-DSparkドラフターを実行します。こちらもオープン中で、まだマージされていません。

DSparkは、DeepSeekがオープンソース化したEAGLEファミリーのドラフターであり、DeepSeek-V4-Pro-DSparkおよびDeepSeek-V4-Flash-DSparkに搭載されています。LGはこれまでに他ラボによる最も注目度の高い採用例であり、RadixArkのQwen3.8ドラフターは2番目の独立した採用例です。

• {{1}}DSparkバリアントは、78層の750B MoEに加えて、追加のドラフト層を5層備えたものです。{{2}}LGは、DSparkとMTPがそれぞれ約3〜5倍のデコード高速化をもたらすと主張しており、{{3}}長時間にわたるエージェント型ワークロードを対象としています。{{4}}

• ローンチ時点では、vLLMはMTPをK-EXAONE 2.0ではサポートしていましたが、DSparkではサポートしていませんでした。DSparkサポートは、モデル固有のPRと汎用設定パスを通じて導入されます。

• 現在、どのプロバイダーもK-EXAONE 2.0のチェックポイントをホストしておらず、カード上のすべてのベンチマークはLG独自のものです。

プルリクエストとは何か（そして何でないか）

vLLM PR #51558、「[Model] Add K-EXAONE-2.0-750B-A37B-DSpark」は lkm2835 によってオープンされました。同じ貢献者は、以前の vLLM（ベースモデル向け #50524）および SGLang（#33648）での K-EXAONE サポートにも関わっています。これは new-model ラベルが付いたフォーク PR で、vLLM コードオーナーへのレビューが依頼されていますが、まだ承認はありません。説明は3行から成ります：LG AI Research が開発した DSpark チェックポイントのサポートを追加し、Hugging Face モデルカードと K-EXAONE 2.0 テクニカルレポート（arXiv 2608.04505）へのリンクを提供し、以前の vLLM 作業（#50524）を参照しています。

8月13日のPRは種類が異なります。#52197「Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3」は、汎用の正規化レイヤーを追加します。qw​en​3モデルタイプ上でDSparkDraftModelとして宣言されているHugging Faceのドラフトチェックポイントは、vLLMの既存のspecデコーダーが読み込めるQw​en3DSparkModelに再マッピングされます。そのテスト計画の参照モデルは、RadixArk/Qw​en​3.8-2.4T-A95B-DSparkです。これは、最大クラスのQw​en​3.8-2.4T-A95Bターゲット向けのDSparkスペキュレーターであり、dspark spec方式と7トークンのスペックウィンドウで提供されます。コミットメッセージが全体のアイデアを表しています：「architectures=DSparkDraftModel+model_type=qw​en​3」。この変更の要点は、サードパーティのDSparkドラフターが、現在サポートされているすべてのDSparkチェックポイントがそうであるようなモデル別のコードを必要とするのではなく、設定だけで読み込めるようにすることです。これは#51558と同様、オープンで未マージです。

そのステータスを文字通りに読んでください。{{1}}「サポートが追加中」は「サポートが利用可能」ではありません。どちらかのPRがマージされ、リリースに含まれるまで、標準のvLLMビルドは依然としてDSparkバリアントを読み込めません。{{/1}}モデルカード自体にも、DSparkを使用したK-EXAONE 2.0のサービングは、代わりにMTPを使用するvLLMでは現在サポートされていないと記載されています。{{2}}これら2つのPRは、その記述を変えるステップです——実際にマージされればの話ですが。{{/2}}

DSparkがここでの本当のストーリーである理由

モデル名は多くの情報を担っています。「A37B」は、トークンあたり370億のアクティブパラメータを意味します。「DSpark」は、Deep​Seekが今年導入した投機的デコーディング用ドラフターです。半自己回帰型でEAGLEファミリーに属するドラフトモデルであり、1回のパスでトークンのブロックを提案し、対象モデルがそれを検証できるようにします。これにより、生成は高速化される一方、出力品質は変わりません。Deep​Seekはこれをオープンソース化し、ドラフターを自社のDeep​Seek-V4-Pro-DSparkおよびDeep​Seek-V4-Flash-DSparkチェックポイントに同梱しています。コミュニティの報告では、単一トークンMTPベースラインと比較して、Flashで60〜85%、Proで57〜78%の高速化が達成されています。

新しいPRが明らかにしているのは、vLLMにおけるDSparkサポートがそもそも未解決の問題ではなかったということだ。vLLM自身のドキュメントにはすでにDeep​Seek-V4、Kimi K3、Gem​ma​4チェックポイント用のDSparkモジュールが記載されており、チームは7月のエンジニアリング記事でその設計について詳述している。ただし、それらの統合はすべて手作業で組み込まれている。つまり、承認されたチェックポイントのリストに過ぎず、誰もが使える経路ではない。K-EXAONEチェックポイントは単純にそのリストに載っていないのだ。#52197は、その経路を汎用化する試みである。つまり、また別の特注モデルクラスではなく、1つの設定マッピング（DSparkDraftModelとqw​en​3）を用い、リファレンステストケースとしてDeep​Seekモデルではなくサードパーティのドラフターを使う。だからこそ、漏洩したドラフトチェックポイントの話は、実際にはインフラストラクチャーの話なのである。

K-EXAONE-2.0-750B-A37B-DSparkは、ベースモデルの78層を維持しつつ、5つのDSparkドラフト層を追加しています。LGのモデルカードによれば、DSparkとMTPの両方が生成速度をおよそ3〜5倍高速化すると主張されています。これは同社自身の数値であり、「エージェント型タスクのような長期的ワークロード」、つまりデコードレイテンシがボトルネックとなる状況を想定したものです。ここから2つのことが導かれます。第一に、投機的デコードは、後付けで適用するサーバリングのテクニックではなく、オープンフロンティアモデルの第一級の機能になりつつあるということです。第二に、Deep​Seekのドラフトスタックが標準になりつつあるということです。だからこそ、韓国政府支援のソブリン旗艦モデルがこれを採用していることは、単なる「新モデル登場」のニュース以上の意味を持つのです。

PRの背後にあるモデル

K-EXAONE-2.0-750B-A37B-DSparkは、LGの236B K-EXAONEシリーズの続編であるK-EXAONE 2.0のバリアントであり、政府の主権AIプログラムのもとで構築された韓国最大の国産基盤モデルです。ベースモデル（総パラメータ750B、アクティブ37B、256エキスパートとトークンあたり8つのアクティブエキスパートを備えたMixture-of-Experts、262,144トークンのコンテキストウィンドウ、10言語、Apache 2.0）は、2026年7月31日にHugging Faceで公開され、ゼロから学習するのではなく、236Bの前身モデルからアップサイクルされました。

LG独自のベンチマーク平均（24のベンチマーク、総合70.1）は、韓国国産モデルに期待される形を示している：長文コンテキスト検索、韓国社会の安全性、エージェント的コーディングで強い報告結果を示す一方、一般的な推論ではAlibabaのQwen3.5に及ばない数値（例えばMMLU-Proで83.5対89.8）となっている。これらのいずれもまだ独立に検証されていない。DSparkバリアントはこれらのスコアを何も変えない——それはサービングアーティファクトであり、同じモデルをより速く実行する方法である——だからこそ、発表ではなく推論フレームワークのプルリクエストに登場しているのだ。

750B MoEの背後にあるサービングの現実

ここで実際に重要になるのがDSparkサポートです。K-EXAONE-2.0-750B-A37B-DSparkは、BF16/F32形式の7510億パラメータのチェックポイントであり、LGのガイダンスではNVIDIA H200 GPUを8基搭載したノードが最低2台（16 GPU、テンソル並列16）必要とされています。この規模では、デコードスループットがすべてを左右します。つまり、1秒あたりのトークン数と、長いエージェント的ターンのコストであり、まさにそこを投機的デコーディングが攻めるのです。3〜5倍のデコード高速化が、LGのテスト環境の外でも実現できれば、H200クラスターが経済的に成立するかどうかの分かれ目になります。LGはまた、B200 GPUで発生する生成崩壊（generation-collapse）の問題を文書化しており、修正されるまでは--disable-prefill-cuda-graphによる回避策が必要です。これは、これがターンキーなものではなく、最先端のサーバー運用であることを思い出させてくれます。

その費用と、実際に試す方法

現在、K-EXAONE 2.0 を提供する API は存在しません。DSpark バリアントの Hugging Face カードにはまだ「このモデルはどの推論プロバイダーにもデプロイされていません」と記載されており、16×H200 というフットプリントの大きさから、そのハードウェアを持つ誰かがホストすると決めない限り、ホスト型 API には到達しません。それが本当の摩擦点です。オープンウェイトの最前線は、ますます可用性の問題ではなく、サービングの問題になりつつあります。

プロバイダーがそれを採用した場合、投機的デコーディングによる高速化はトークンあたりの価格に反映され、アプリケーションがすでにモデル非依存であれば、それを試すための切り替えコストはほぼゼロになるはずです。OrcaRouterは、200以上のモデルに対応するOpenAI互換エンドポイントであり、プロバイダーのリスト価格を0%マークアップでそのまま通すため、任意のアップストリームプロバイダーに載ったモデルは再統合ではなくルーティング変更になります。また、自動フェイルオーバーにより、速度が遅い、または不安定な真新しい750B MoEは、インシデントなしに既知の正常なモデルへフォールバックされます。明確に言うと、OrcaRouterは現在K-EXAONE-2.0-750B-A37B-DSparkをホストしておらず、私たちが見つけた他のAPIも同様です。ルーティング層の要点は、それらのいずれかがホストする日に備えて配線されていることです。

私たちが注目しているもの

• マージする2つのPR。#51558（モデル固有）と#52197（汎用設定）はどちらもオープンで、承認はありません。「DSparkサポート」をプルリクエストから実際に渡せるフラグに変えるのは、マージとリリースです。

ジェネリックパスのスコープ。#52197がマージされれば、Hugging Face上の任意のqwen3型DSparkDraftModelが設定によってロード可能になる——DSparkが公認チェックポイントのリストであることと、DSparkがオープンスタンダードであることの違いだ。

• 最初の独立したスコア。カード上のすべてのベンチマークはLGが実施したものだ。750Bの韓国製MoEに関するArtificial Analysisまたはアリーナでの最初のデータポイントは、ベンダーが公表していない最初の数字になるだろう。

DSparkはDeep​Seekを超える。LGとRadixArkは現在、Deep​Seekのドラフト方式を製品化する2つの独立したプレイヤーであり、汎用vLLMパスはスタックが統合されつつあることを示す3番目のシグナルである。

• 量子化サービング。LGはベースモデルのFP8およびNVFP4チェックポイントを提供している。より少ないGPUで動作する量子化DSparkバリアントがあれば、どのベンチマークよりも速く経済性を変えるだろう。

よくある質問

K-EXAONE-2.0-750B-A37B-DSparkはリリースされましたか？

ウェイトはApache 2.0ライセンスでHugging Faceにアップロードされているが、これはローンチの話ではない。vLLMサポートは未マージの2つのオープンなプルリクエスト（#51558および#52197）であり、高速化の数値はLG独自のもので、モデルをホストしているプロバイダーも存在しない。ここで「確認済み」が意味するのはサービング経路のことだ。つまり、汎用のDSparkDraftModel設定サポートが、実行可能なテスト計画を備えた公開PRに存在するということであって、リリース済みのvLLMビルドがすでにこのモデルを提供できるという意味ではない。

K-EXAONE-2.0-750B-A37B と DSpark バリアントの違いは何ですか？

ベースモデルの78層に加えて、投機的デコード用のDSparkドラフト層が5層あります。基盤となる重みもベンチマークも同じであり、異なるモデルではなく、デコードがより高速なサービス提供用アーティファクトです。

I'm not familiar with any product or project called "DSpark" being associated with either LG or DeepSeek. Could you provide more context about what "DSpark" refers to? That way I can give you a more accurate answer.

DSpark は Deep​Seek のオープンソース化された投機的デコーディング手法であり、Deep​Seek-V4-Pro-DSpark と Deep​Seek-V4-Flash-DSpark にも搭載されています。LG はこれまでで最も注目度の高い採用事例であり、RadixArk の Qw​en​3.8-2.4T-A95B-DSpark は、同じ手法に基づいて構築された2番目の独立したドラフターです。LG のモデルカードには、同じ3〜5倍の高速化範囲が記載されています。

K-EXAONE-2.0-750B-A37B-DSparkは、現在自分のハードウェアで実行できますか？

セルフホスティングのみで対応可能：LGのガイドラインでは最低16基のNVIDIA H200 GPUが必要であり、vLLM、SGLang、Transformersの標準リリースでは、アーキテクチャを認識するためにマージされていないフォークや保留中の汎用設定パスが依然として必要です。#52197のDSparkDraftModelサポートは共有ルートに最も近いものですが、それでもまだオープンなプルリクエストです。

この動向が注目に値するのは、プルリクエストそのものではなく、それが示す意味だ。7,500億パラメータ・Apache-2.0の韓国国産フラッグシップモデルがDeep​Seekの投機的デコーディングスタックを採用し、独立系推論企業が最大クラスのQw​en​3.8向けにDSparkドラフターを構築し、vLLMはモデルごとのパッチではなく汎用設定パスで応えている。フロンティアのオープンモデルが本物になるのは、ウェイトが公開された瞬間ではなく、ドラフターがマージされた瞬間なのである。