K-EXAONE-2.0-750B-A37B-DSpark：LG的750B韩国MoE模型即将登陆vLLM

2026年8月9日，vLLM 仓库中开了一个拉取请求（PR），旨在加入 K-EXAONE-2.0-750B-A37B-DSpark——LG AI Research 的 7500 亿参数韩语旗舰模型的投机解码变体。四天后的 8 月 13 日，第二个更具基础性的 PR 让这次泄露成为实锤：vLLM 如今拥有一个通用的 DSparkDraftModel 配置路径，可将任何声明 architectures=DSparkDraftModel 且 model_type=qw​en​3 的 Hugging Face 检查点映射到已识别的 Qw​en3DSparkModel，并包含一个测试计划，实际通过 dspark spec 方法为 RadixArk Qw​en3.8-2.4T-A95B-DSpark 草稿模型提供服务。基础版 K-EXAONE-2.0-750B-A37B 于 7 月 31 日以 Apache 2.0 许可发布，发布之初 vLLM 可以用 MTP 草稿方法为其提供服务，但无法使用 DSpark——LG 也发布了 DSpark 草稿模型，并声称它能带来 3–5 倍的解码加速。DSpark 本身就是 Deep​Seek 的方法，也就是运行在 Deep​Seek-V4-Pro-DSpark 和 Deep​Seek-V4-Flash-DSpark 上的那个半自回归草稿模型。因此，这两个 PR 合在一起，是迄今最清晰的信号：Deep​Seek 的投机解码技术栈正在成为开放权重模型的默认选择。

这是一篇“目前已知情况”的报道，不是发布新闻。两个拉取请求都处于开放状态，尚未合并；DSpark 检查点没有独立的基准测试结果；LG 的加速数据只是厂商单方面宣称。下文所有内容均已相应标注。目前确定的事实是：权重已上传到 Hugging Face，基础模型已发布，vLLM 的 DSpark 推测解码器已经能为 DeepSeek 和 Kimi 检查点提供服务，而允许第三方 DSpark 草稿模型加载的通用配置路径——也就是这次泄露所等待的关键部分——现在已经出现在一个公开的拉取请求中，已通过测试但尚未发布。

简短版本

• PR #51558，于2026年8月9日提出，将K-EXAONE-2.0-750B-A37B-DSpark添加到vLLM；目前处于开放状态，尚未获得任何批准。

• PR #52197，于2026年8月13日开启，引入了通用的DSparkDraftModel配置支持——architectures=DSparkDraftModel且model_type=qw​en​3，归一化为Qw​en​3DSparkModel——其测试计划使用dspark spec方法和七个spec tokens运行RadixArk Qw​en​3.8-2.4T-A95B-DSpark drafter。同样处于打开状态，同样尚未合并。

• DSpark 是 Deep​Seek 开源并搭载于 Deep​Seek-V4-Pro-DSpark 与 Deep​Seek-V4-Flash-DSpark 的 EAGLE 系列草稿模型；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 自己的。

拉取请求是什么（以及不是什么）

vLLM PR #51558，题为“[Model] Add K-EXAONE-2.0-750B-A37B-DSpark”，由 lkm2835 开启——他也是此前在 vLLM（#50524，基础模型）和 SGLang（#33648）中支持 K-EXAONE 的同一贡献者。这是一个打了 new-model 标签的分叉 PR，已请求 vLLM 代码所有者进行审查，目前尚无批准。描述共三行：它增加了对“由 LG AI Research 开发”的 DSpark 检查点的支持，附上了 Hugging Face 模型卡和 K-EXAONE 2.0 技术报告（arXiv 2608.04505）的链接，并引用了之前 #50524 中的 vLLM 工作。

8月13日的PR在性质上有所不同。#52197「Support DSpark configs with architectures=DSparkDraftModel + model_type=qwen3」增加了一个通用归一化层：一个声明自己是DSparkDraftModel且model_type为qwen3的Hugging Face草稿检查点，会被重新映射为Qwen3DSparkModel，从而可由vLLM现有的spec解码器加载。其测试计划中的参考模型是RadixArk/Qwen3.8-2.4T-A95B-DSpark——它是面向最大规模Qwen3.8-2.4T-A95B目标的DSpark投机器，使用dspark投机方法和七token的投机窗口对外服务。提交信息本身就是全部思路：「architectures=DSparkDraftModel+model_type=qwen3」。该变更的意义在于，第三方DSpark草稿模型应能通过配置加载，而不必像目前所有受支持的DSpark检查点那样需要逐模型代码。它目前处于开放且未合并状态，与#51558相同。

请按字面意思理解这个状态。“正在添加支持”并不等于“支持已可用”：在任一 PR 合并并随版本发布之前，标准 vLLM 构建仍然无法加载 DSpark 变体。模型卡本身也说明，目前 vLLM 不支持使用 DSpark 服务 K-EXAONE 2.0，vLLM 使用的是 MTP。这两个 PR 正是改变这一说法的步骤——但前提是它们最终落地。

为什么DSpark才是这里真正的关键

模型名称本身承载了大量信息。"A37B" 表示每个 token 有 370 亿个激活参数。"DSpark" 是 Deep​Seek 今年推出的投机解码草稿模型：一个半自回归的 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检查点对应的DSpark模块，团队还在7月的一篇工程博文中阐述了这一设计。不过，这些集成每一个都是手工接入的——一份获得认可的检查点清单，而不是任何人都能使用的路径。K-EXAONE检查点恰恰不在那份清单上。#52197正是为了让这条路径变得通用：用一个配置映射（DSparkDraftModel加上qw​en​3）取代又一个特制的模型类，并以第三方草稿模型作为参考测试用例，而不是Deep​Seek模型。这就是为什么一个关于泄漏草稿检查点的消息，本质上是一个基础设施问题。

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 的一个变体，后者是 LG 236B K-EXAONE 系列的后继产品，也是韩国最大的本土基础模型，在政府的主权AI计划下构建。该基础模型——总参数750B、激活参数37B，采用混合专家架构，拥有256个专家、每令牌激活8个，上下文窗口为262,144个令牌，支持十种语言，Apache 2.0 许可——于2026年7月31日发布于 Hugging Face，由236B前身升级而来，而非从头训练。

LG自身的基准测试平均值（24项基准测试，总体得分70.1）展现出韩国主权模型的预期形态：在长上下文检索、韩国社会安全性和智能体编程方面报告了强劲的结果，而在通用推理方面则落后于阿里巴巴的Qwen3.5（例如MMLU-Pro得分83.5对比89.8）。这些数据均未经独立验证。DSpark变体并未改变其中任何分数——它是一种服务工件，一种运行同一模型的更快方式——这正是它出现在推理框架拉取请求中而非公告中的原因。

750B MoE 背后的服务现实

这就是 DSpark 支持真正重要的地方。K-EXAONE-2.0-750B-A37B-DSpark 是一个 7510 亿参数的检查点，采用 BF16/F32 格式；LG 的指导是最少两个节点，每个节点八块 NVIDIA H200 GPU（共 16 块 GPU，张量并行度 16）。在这种规模下，解码吞吐量就是一切——每秒 token 数，以及一次长智能体回合的成本——而这正是投机解码所攻克的痛点。如果 3–5 倍的解码加速在 LG 的测试环境之外仍然成立，那它就决定了 H200 集群是否经济划算。LG 还记录了一个在 B200 GPU 上出现的生成崩溃问题，在修复前需要使用 --disable-prefill-cuda-graph 这一变通方案——这提醒我们，这是前沿的模型服务，而非开箱即用的方案。

它要花多少钱，以及你实际上会如何尝试它

目前没有任何 API 提供 K-EXAONE 2.0 服务。DSpark 变体的 Hugging Face 卡片上仍写着“该模型尚未由任何推理提供商部署”，而 16×H200 的硬件规模意味着，只有当拥有该硬件的人决定托管它时，它才能接入托管 API。这才是真正的症结所在：开放权重的前沿越来越是一个服务问题，而非可用性问题。

当某个提供商真的接入该模型时，推测解码带来的加速会体现在每 token 价格上，而如果你的应用已经是模型无关的，尝试它的切换成本应该接近于零。在 OrcaRouter 上——一个兼容 Open​AI 的端点，覆盖 200 多个模型，按提供商列表价格原价传递、零加价——凡是落到任何上游提供商的模型，都只是路由变更而非重新集成；自动故障转移意味着，一个全新的 750B MoE 模型如果被证明速度慢或不稳定，会自动回退到已知良好的模型，而不会引发事故。明确地说：OrcaRouter 目前并未托管 K-EXAONE-2.0-750B-A37B-DSpark，我们找到的任何其他 API 也没有。路由层的意义就在于，为其中某一个真正接入的那一天做好准备。

我们正在关注的

合并这两个 PR。#51558（特定于模型）和 #52197（通用配置）均处于开放状态，且尚未获得批准。合并并发布，才能将“DSpark 支持”从拉取请求转变为你可以实际传递的标志。

• 通用路径的范围。如果 #52197 合并，Hugging Face 上任何 qw​en​3 类型的 DSparkDraftModel 都可以通过配置加载——区别在于 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 是否已发布？

这些权重以Apache 2.0许可证发布在Hugging Face上，但这并非发布故事：vLLM的支持只是两个开放、未合并的拉取请求（#51558和#52197），加速数据是LG自己的，也没有任何服务商托管该模型。这里的“已确认”指的是服务路径——通用的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 支持最接近共享路线，但它仍然是一个开放的拉取请求。

这件事值得关注的原因不在于拉取请求本身，而在于它们所传递的信号。一个拥有7500亿参数、采用 Apache-2.0 许可的韩国主权旗舰模型选择集成 Deep​Seek 的投机解码技术栈，一家独立推理公司为 max 级 Qw​en​3.8 构建了 DSpark 草稿模型，而 vLLM 的回应则是一个通用配置路径，而不是针对单个模型的补丁。这就是前沿开源模型真正落地的方式——不是在权重发布的那一刻，而是在草稿模型合并的那一刻。