A.X K2 DSpark 对比 A.X K2：仅起草模型究竟能带来什么

关于 A.X K2 DSpark 与 A.X K2 对比，最奇怪的一点在于，这其实算不上真正的对比。A.X K2 DSpark 不能替代 A.X K2——它本身根本无法独立使用。它是 SK Telecom 在八月初悄然上传到 Hugging Face、未作任何宣布的“仅草稿检查点”：一个推测解码草稿模型，其全部任务就是让该公司的旗舰产品 A.X K2——一个拥有 6880 亿参数、开放权重的混合专家模型——在保持答案不变的前提下更快地生成 token。因此，这场对决真正的问题不是“哪个更好”，而是“你运行 A.X K2 时应该用 DSpark，还是不用？”本文所有内容均按来源标注，因为仓库告诉我们的与实际测量到的之间的差距，正是问题的全部关键。

A.X K2 DSpark 实际上是什么

SK Telecom的模型卡对于该模型的用途出奇地直白。A.X K2 DSpark“是面向A.X K2的DSpark推测解码草稿模型”，并且“是一个仅用于起草的检查点：它没有独立用途，旨在由vLLM与A.X K2一起通过推测解码加载”。实际上，这意味着你下载它，将兼容的vLLM同时指向它和A.X K2，两者便协同工作：DSpark提出候选词元，A.X K2进行验证，只有经过验证的词元才会被输出。

从该仓库中可以了解到草稿机制的两个细节。首先，{{1}}DSpark 并行提出多个候选 token，而不是一次一个 token 地编写草稿序列；它利用 A.X K2 自身的隐藏表示，并结合轻量级的局部依赖建模{{/1}}。其次，整个机制被构建为无损的：{{2}}每个候选在提交前都会由目标模型进行验证，因此 A.X K2 的输出分布在构造上保持不变{{/2}}。

该发布本身是一则预发布公告。模型卡片显示，该模型“目前正处于最终验证阶段，计划在未来几天内公开发布”，并注明评估“正在进行中”——卡片上的所有吞吐量、TPOT 和平均接受长度指标仍标注为 TBD。

为什么这个“versus”实际上是“有与没有”的对比

由于 A.X K2 DSpark 没有独立用途，因此不存在选择它来代替 A.X K2 的场景。选择实际上是在单独的 A.X K2 与附带草稿模型的 A.X K2 之间。就输出质量而言，这两种配置在构造上完全相同；唯一可能变化的维度是解码速度。

郑重说明，A.X K2 的情况如下：这是一款总参数 688B、激活参数 33B 的混合专家（MoE）解码器，拥有 256 个专家和 1 个共享专家（每次前向传播激活 8 个），共 61 层、64 个注意力头，词表规模 163,840 token，于 7 月 29 日以 Apache 2.0 许可证开放权重发布。该模型使用约 8.2 万亿 token 以 MXFP8 格式原生预训练，采用 SK Telecom 的 Sparse Gated Attention（稀疏门控注意力）以实现长上下文高效处理，支持 262,144 token 的上下文长度（原生 128K 通过 YaRN 扩展至 256K）。SK Telecom 报告称，其在 14 项基准测试中平均领先 A.X K1 32.2 个百分点，长上下文和智能体（agent）评估提升约 83.9 分——以上均为厂商自报数据，目前尚无独立的综合评分发布。

DSpark 是专门为该架构设计的。规格说明显示它与 A.X K2 的 MoE 结构、注意力布局和原生 256K 配置相匹配，并且未针对任何其他目标进行验证。它继承了相同的 262,144 token 上下文，因此在窗口大小方面不会让您付出任何代价。

阅读模型卡片：可知，但尚未确认

该仓库让你清楚地了解模型是什么，并简要列出了它没有告诉你的内容。

今日可知：

• 这是一个仅限草稿（drafter）的检查点，不能独立使用，由 vLLM 通过投机解码与 A.X K2 一同加载。

• 许可证是 Apache 2.0；权重可免费下载和使用。

• 上下文长度与 A.X K2 一致，为 262,144 个 token。

{{1}}它通过SK Telecom的vLLM分支运行{{/1}}{{2}}（即SKT-AI/vllm仓库的axk2-v0.23.0分支）{{/2}}{{3}}，并使用{{/3}}{{4}}--speculative-config标志。{{/4}}

• 该方法在一篇论文中有详细描述，题为《DSpark：基于置信度调度的推测解码与半自回归生成》（arXiv:2607.05147，2026年7月6日提交）——该论文也是你将会看到的加速数据的来源。

• 目前没有任何推理提供商部署它，因此没有可调用的托管 API。

尚未确认：

• 官方公告——该卡片承诺“在接下来的几天内”公开发布。

• 任何 A.X K2 专属的加速数据。评估正在进行中，所有性能指标均待定。

• 它在负载下实际帮助有多大，规格卡将其标记为“取决于工作负载”。

• 对草稿模型的任何独立第三方测量。

DSpark与普通推测解码有何不同

推测解码是一种屡试不爽的技巧：一个小而快的草稿模型写出对接下来几个词元的猜测，大模型在单次前向传播中检查整个猜测，接受通过验证的前缀，再采取一步修正。运用得当可大幅降低延迟，且质量不受损失。

正如DSpark论文所概括的，症结在于：最近的并行草拟器——一次性提出长序列——会遭遇“快速接受衰减”，因为草稿中靠后的token不依赖前面的token，所以被拒绝的频率要高得多。而盲目验证长块会把批处理容量浪费在很可能被拒绝的token上，这恰恰会损害高并发服务系统的吞吐量。

DSpark 直击这两个问题：

• 半自回归草稿生成。它将并行主干网络与轻量级顺序模块相结合，引入块内依赖建模，使后续草稿token依赖于前面的token——这正是缓解后缀衰减的关键。

• 基于置信度调度的验证。它不是验证固定的块长度，而是根据估计的前缀存活概率和引擎的吞吐量特征，为每个请求定制验证长度。验证变得具有负载感知能力。

论文中的数字——以及它们不会告诉你的那些事

以下是你将看到的引用数字：在匹配的吞吐量水平下，DSpark“将每位用户的生成速度提高60%到85%”，相比MTP-1生产基线。论文还报告称，在离线基准测试中，与最先进的自回归和并行草稿模型相比，接受长度显著提高，并称它能防止在严格交互性约束下出现严重的吞吐量下降。

请仔细阅读细则，因为这对这一特定对比至关重要：那个 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的供应商分支而非标准版本——这是一个维护方面的考量。

• 请记住论文自身的告诫：验证并非没有代价——在高并发下，粗心的验证会吞噬批量容量，而这正是置信度调度式验证旨在应对的失效模式。

还有一点值得了解：Hugging Face 报告称，下载量"未对此模型进行跟踪"，因此没有公开信号表明实际有多少团队尝试过它。

谁应该选择哪个

如果您符合以下任一情况，请运行普通版 A.X K2：

• 您运行的是原版 vLLM，不希望路径中出现第二个检查点或供应商分支。

您的工作负载受吞吐量限制而非延迟限制，并且用户能够容忍长时间生成的等待。

你宁愿等待官方发布和首次独立测量结果。

运行 A.X K2 加上 DSpark，如果这是你：

• 您自行托管 A.X K2，生成延迟或 token 吞吐量正是痛点。

• 长上下文和智能体工作负载使用户等待长输出——投机解码正是为这一场景而设计。

• 你可以放心运行一个预发布组件，其风险是有限的：最坏情况下它没有帮助，且不会改变输出质量。

如果你完全不自行托管 688B MoE，那就两个都别选。A.X K2 的主权属性和韩语优势只有在你运行它时才能为你所用；许多团队则会转而通过托管目录触达前沿开放模型。这正是让集成保持与模型无关的价值所在：OrcaRouter 的单一 OpenAI 兼容端点覆盖 200 多个模型，按提供商列表价格零加价计费，支持自动故障转移，并提供路由 DSL 将多个模型组合到一次调用中。（目前 A.X K2 和 A.X K2 DSpark 都没有在任何地方托管——包括 OrcaRouter 上——所以这关乎你技术栈的其余部分，而不是这对模型的路由问题。）这种策略依然适用：先在少量流量上试用未经证实的模型并自动故障转移，而不是把生产路径押注在它上面。

接下来看什么

现状很简单：代码库是真实的，方法有文档说明，但测量数据却没有。值得关注的有三件事：承诺的公开版本发布（卡片上写着“未来几天内”），SK Telecom 评估结束后首批针对 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。