K-EXAONE-2.0-750B-A37B-DSpark：LG的750B韓語MoE即將登陸vLLM

2026年8月9日，vLLM 儲存庫中開啟了一個 pull request，欲新增 K-EXAONE-2.0-750B-A37B-DSpark——這是 LG AI Research 7500 億參數韓文旗艦模型的推測解碼變體。四天後的 8 月 13 日，第二個更具根本性的 PR 坐實了這項洩漏：vLLM 現在有一條通用的 DSparkDraftModel 設定路徑，可將任何宣告 architectures=DSparkDraftModel 且 model_type=qwen3 的 Hugging Face checkpoint 對應到已獲認可的 Qwen3DSparkModel，並包含一項測試計畫，實際透過 dspark spec 方法為 RadixArk Qwen3.8-2.4T-A95B-DSpark 草稿模型提供服務。基礎版 K-EXAONE-2.0-750B-A37B 於 7 月 31 日以 Apache 2.0 授權釋出，但上線時 vLLM 僅能以 MTP 草稿方法服務該模型，而無法使用 DSpark——也就是 LG 一併釋出、宣稱可帶來 3–5 倍解碼加速的草稿器。DSpark 本身是 DeepSeek 的方法，與運行在 DeepSeek-V4-Pro-DSpark 和 DeepSeek-V4-Flash-DSpark 上的半自迴歸草稿器相同，因此這兩個 PR 合在一起，是迄今最明確的訊號：DeepSeek 的推測解碼技術棧正成為開放權重模型的預設選項。

這是一篇彙整目前已知資訊的報導，而非產品發布新聞。兩個 pull request 都仍開啟、尚未合併；DSpark 的 checkpoint 沒有獨立的基準測試數據；LG 的加速數字則屬廠商宣稱。以下內容皆依此標註。現在真實確定的部分是：權重已上架 Hugging Face、基礎模型已發布、vLLM 的 DSpark 推測解碼器已能服務 Deep​Seek 與 Kim​i 的 checkpoint，而能讓第三方 DSpark 草稿模型載入的通用設定路徑——也就是這則洩漏消息一直在等待的關鍵——如今已出現在一個公開的 pull request 中，測試過但尚未正式發布。

簡短版本

• PR #51558 於 2026 年 8 月 9 日開啟，將 K-EXAONE-2.0-750B-A37B-DSpark 加入 vLLM；目前該 PR 仍為開啟狀態，尚未獲得任何批准。

• PR #52197 於 2026 年 8 月 13 日開啟，引入了通用的 DSparkDraftModel 設定支援 — architectures=DSparkDraftModel 搭配 model_type=qw​en​3，並正規化為 Qw​en3DSparkModel — 其測試計畫會以 dspark spec 方法與七個 spec token 執行 RadixArk Qw​en​3.8-2.4T-A95B-DSpark 草稿模型。同樣仍開放中，同樣尚未合併。

• DSpark 是 Deep​Seek 開源的 EAGLE 系列草稿模型，搭載於 Deep​Seek-V4-Pro-DSpark 與 Deep​Seek-V4-Flash-DSpark 上；LG 是目前為止另一實驗室最高調的採用案例，而 RadixArk 的 Qw​en​3.8 草稿模型則是第二個獨立實現。

• DSpark 變體是 78 層 750B MoE 加上五個額外的草稿層；LG 聲稱 DSpark 和 MTP 各自能提供約 3–5× 的解碼加速，目標是長時程的代理型工作負載。

在發佈之初，vLLM 支援 K-EXAONE 2.0 的 MTP，但不支援 DSpark；DSpark 的支援將透過模型特定的 PR 和通用配置路徑落地。

• 目前沒有任何供應商託管任何 K-EXAONE 2.0 檢查點，且規格表上的所有基準測試都是 LG 自家的。

Pull requests 是什麼（以及不是什麼）

vLLM PR #51558，標題為「[Model] Add K-EXAONE-2.0-750B-A37B-DSpark」，由 lkm2835 開啟——就是先前在 vLLM（#50524，針對基礎模型）與 SGLang（#33648）中支援 K-EXAONE 的同一貢獻者。這是一個帶有 new-model 標籤的分支 PR，已請求 vLLM 程式碼擁有者審查，但目前尚未有任何批准。描述有三行：它增加了對 DSpark 檢查點（由 LG AI Research 開發）的支援，連結了 Hugging Face 模型卡與 K-EXAONE 2.0 技術報告（arXiv 2608.04505），並引用了先前在 #50524 中的 vLLM 工作。

8 月 13 日的 PR 在性質上有所不同。#52197「Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3」新增了一個通用的正規化層：一個自我宣告為 DSparkDraftModel、且 model_type 為 qw​en​3 的 Hugging Face 草稿 checkpoint，會被重新對應為 vLLM 現有 spec-decoder 可以載入的 Qw​en3DSparkModel。其測試計畫中的參考模型是 RadixArk/Qw​en​3.8-2.4T-A95B-DSpark——一個用於 max-class Qw​en​3.8-2.4T-A95B 目標的 DSpark 推測模型——以 dspark spec 方法與七個 token 的 spec 視窗提供服務。commit message 就是整個想法：「architectures=DSparkDraftModel+model_type=qw​en​3」。此變更的重點在於，第三方 DSpark 草稿模型應該要能透過設定即可載入，而不需要像目前所有受支援的 DSpark checkpoint 那樣，為每個模型撰寫專屬程式碼來接入。它目前是開放且未合併的，與 #51558 相同。

請照字面解讀那個狀態。「支援正在加入」不等於「支援已可用」：在任一個 PR 合併並隨版本發布之前，標準的 vLLM 建置仍然無法載入 DSpark 變體。模型卡本身也說明了，vLLM 目前不支援以 DSpark 提供 K-EXAONE 2.0 服務，而是使用 MTP。這兩個 PR 就是改變那句話的步驟——如果且當它們被合併時。

為何 DSpark 才是這裡真正的主角

模型名稱本身就承載了大量資訊。「A37B」代表每個 token 有 370 億個活躍參數。「DSpark」是 Deep​Seek 今年推出的投機解碼（speculative decoding）起草模型：這是一個半自迴歸、屬於 EAGLE 家族的草稿模型，能一次性提出一整個 token 區塊，再讓目標模型進行驗證，因此輸出品質不變，但生成速度更快。Deep​Seek 將它開源，並在自家的 Deep​Seek-V4-Pro-DSpark 與 Deep​Seek-V4-Flash-DSpark 檢查點中隨附這個起草模型；根據社群回報，相較於單一 token 的 MTP 基線，Flash 的加速幅度約為 60–85%，Pro 則約為 57–78%。

新 PR 所揭示的重點在於，vLLM 對 DSpark 的支援從來就不是懸而未決的問題。vLLM 自身的文件早已列出 Deep​Seek-V4、Kimi K3 與 Gem​ma​4 checkpoint 的 DSpark 模組，團隊也在七月的工程文章中寫下了這項設計。不過，這些整合每一項都是手工接線——是一份核定通過的 checkpoint 清單，而不是任何人都能使用的途徑。K-EXAONE checkpoint 根本不在那份清單上。#52197 就是試圖讓這條途徑通用化的做法：用一個設定對映（DSparkDraftModel 加上 qw​en​3），取代又一個特製的模型類別，並以第三方 drafter 作為參考測試案例，而非 Deep​Seek 模型。這就是為什麼一則外洩的 draft-checkpoint 消息，實際上是一則基礎設施消息。

K-EXAONE-2.0-750B-A37B-DSpark 保留了基礎模型的 78 層，並新增了五層 DSpark 草稿層。LG 的模型卡宣稱，DSpark 與 MTP 都能將生成速度提升約 3–5 倍——這是它自己的數據，目標是「諸如代理型任務等長時程工作負載」，而這類場景的瓶頸正是解碼延遲。由此可得出兩點結論。第一，推測解碼正從事後外掛的部署技巧，轉變為開放前沿模型的一級功能。第二，正在成為預設選項的是 Deep​Seek 的草稿技術棧——這正是韓國政府支持的主權旗艦模型搭載它之所以重要的原因，其意義遠不止常見的「新模型」新聞熱點。

PR 背後的模型

K-EXAONE-2.0-750B-A37B-DSpark 是 K-EXAONE 2.0 的一個變體；K-EXAONE 2.0 是 LG 236B K-EXAONE 系列的后繼版本，也是韓國最大的自主開發基礎模型，是在政府主權AI計畫下建構而成。基礎模型——總參數 750B、活躍參數 37B、混合專家架構（256 個專家，每個 token 啟動 8 個）、262,144 token 的上下文窗口、支援十種語言、Apache 2.0 授權——於 2026 年 7 月 31 日在 Hugging Face 上發布，是從 236B 前代模型升級改造而來，而非從零開始訓練。

LG 自家的基準測試平均值（24 項基準測試，總分 70.1）呈現出韓國主權模型應有的樣貌：在長上下文檢索、韓國社會安全與智能體編程方面有亮眼的報告成績，但在一般推理上則落後於阿里巴巴的 Qw​en​3.5（例如 MMLU-Pro 上為 83.5 對 89.8）。這些數據皆尚未經過獨立驗證。DSpark 變體並未改變任何這些分數——它是服務工件，是以更快方式運行同一模型的手段——這正是它出現在推論框架 pull request 而非公告中的原因。

750B MoE 背後的服務現實

這裡才是 DSpark 支援真正重要的地方。K-EXAONE-2.0-750B-A37B-DSpark 是一個採用 BF16/F32 格式、擁有 7510 億參數的檢查點，而 LG 的建議是最少兩個節點、每個節點八張 NVIDIA H200 GPU（16 張 GPU，張量並行度 16）。在那種規模下，解碼吞吐量就是一切——每秒 token 數，以及一次長時間 agentic 回合的成本——而這正是投機解碼（speculative decoding）所攻擊的痛點。若能實現 3–5 倍解碼加速，且不只是在 LG 的測試框架內成立，這就決定了 H200 叢集是否經濟可行。LG 也記錄了 B200 GPU 上的一個生成崩潰（generation-collapse）問題，在修復之前需要使用 --disable-prefill-cuda-graph 這個繞過方案——這提醒我們，這是尖端前沿的服務，而非隨插即用的解決方案。

它的成本是多少，以及你實際上會如何嘗試

目前沒有任何 API 提供 K-EXAONE 2.0 服務。DSpark 版本的 Hugging Face 卡片仍顯示「此模型尚未由任何推論供應商部署」，而其 16×H200 的硬體需求意味著，只有當擁有該硬體的人決定託管時，它才能透過託管 API 提供服務。這才是真正的瓶頸所在：開放權重的前沿日益成為一個部署服務的問題，而非可用性的問題。

當某個供應商真的開始提供該模型時，推測解碼的加速就會反映在每個 token 的價格上；而如果你的應用程式已經是模型無關的，嘗試它的切換成本應該接近於零。在 OrcaRouter 上——一個涵蓋 200+ 個模型、與 Open​AI 相容的端點，供應商原始價格以 0% 加價直接轉傳——任何模型只要落至任一上游供應商，就只是路由變更，而非重新整合；自動故障轉移則意味著，一個全新的 750B MoE 若最終發現速度過慢或不穩定，就會回退到已知良好的模型，而不會造成任何事故。明確地說：OrcaRouter 目前並未託管 K-EXAONE-2.0-750B-A37B-DSpark，我們所能找到的任何其他 API 也同樣沒有。路由層的意義，就是為了它們之中某一個真的提供該模型的那一天而做好準備。

我們正在觀看的內容

• 合併這兩個 PR。#51558（模型特定）與 #52197（通用設定）都仍在開啟狀態，且未獲得任何核准。必須合併並發行，才能把「DSpark 支援」從 pull request 變成你真的能傳入的旗標。

• 通用路徑的範圍。如果 #52197 合併，任何 Hugging Face 上 qwen3 型別的 DSparkDraftModel 都能透過設定載入——這正是 DSpark 作為受認可檢查點清單與 DSpark 作為開放標準之間的差異。

• 第一個獨立評分。規格卡上的每項基準測試皆由 LG 執行。750B 韓國 MoE 的第一個 Artificial Analysis 或競技場數據點，將是第一個非由廠商公布的數字。

• DSpark 超越 Deep​Seek。LG 和 RadixArk 現在是 Deep​Seek 草稿方法的兩個獨立產品化者，而通用的 vLLM 路徑則是第三個信號，顯示這套技術棧正在整合。

• 量化推論服務。LG 提供基礎模型的 FP8 與 NVFP4 檢查點；若推出能於更少 GPU 上運行的量化 DSpark 變體，將比任何基準測試都更快地改變其成本效益。

常見問題

K-EXAONE-2.0-750B-A37B-DSpark 是否已發布？

模型權重放在 Hugging Face 上，採用 Apache 2.0 授權，但這不是一篇發表故事：vLLM 支援僅來自兩個開放但尚未合併的 pull request（#51558 和 #52197），速度提升數據是 LG 自己提出的，而且目前沒有供應商託管該模型。這裡所謂的「已確認」，指的是服務（serving）路徑——通用的 DSparkDraftModel 設定支援現在已存在於一個公開 PR 中，並附有可執行的測試計畫——而不是說任何已釋出的 vLLM 版本就能直接伺服該模型。

K-EXAONE-2.0-750B-A37B 和 DSpark 變體有什麼不同？

基礎模型的 78 層加上五個用於推測解碼的 DSpark 草稿層——底層權重相同、基準測試相同，是一個解碼更快的服務產物，而非不同的模型。

DSpark 是 LG 的還是 DeepSeek 的？

DSpark 是 Deep​Seek 的開源推測解碼方法，也搭載於 Deep​Seek-V4-Pro-DSpark 和 Deep​Seek-V4-Flash-DSpark；LG 是目前最受矚目的採用者，而 RadixArk 的 Qw​en​3.8-2.4T-A95B-DSpark 是基於同一方法的第二個獨立草稿模型。LG 的模型卡聲稱同樣具有 3–5× 的加速範圍。

我今天可以在自己的硬體上運行 K-EXAONE-2.0-750B-A37B-DSpark 嗎？

唯有透過自行託管：LG 的指引是最少十六張 NVIDIA H200 GPU，而 vLLM、SGLang 和 Transformers 的標準發行版仍需未合併的分支，或等待待定的通用配置路徑才能識別此架構。#52197 中的 DSparkDraftModel 支援是最接近共享路線的方案，但它仍是一個未合併的拉取請求。

這件事值得關注的原因不在於那些 pull request 本身，而在於它們所傳達的訊號。一個具有 7500 億參數、採用 Apache-2.0 授權的韓國主權旗艦模型選擇採用 DeepSeek 的投機解碼堆疊，一家獨立推論公司為 max-class 的 Qwen3.8 打造了 DSpark drafter，而 vLLM 則以通用的設定路徑回應，而非逐模型修補。這正是前沿開放模型成為現實的方式——不是權重釋出的那一刻，而是 drafter 合併的那一刻。