A.X-K2-DSpark：SK Telecom 的推测解码草稿模型已悄然到来

A.X-K2-DSpark 是一个你很可能永远不会直接调用的模型——而这正是它值得一读的原因。SK Telecom 悄悄将它发布到了 Hugging Face 上，没有发布帖，也没有新闻稿；模型卡的开头只是写着，该检查点「目前正处于最终验证阶段，计划在未来几天内公开发布」。它是一个仅用于草拟（drafter）的检查点，专为推测解码（speculative decoding）而构建，只承担一项任务：通过提出 token 供 A.X K2 验证，让 SK Telecom 的 688B 参数旗舰模型 A.X K2 的推理服务更快、更便宜。接下来看看这个仓库实际上告诉了我们什么、哪些信息仍未得到证实，以及为什么这样一个小型辅助模型正是下一轮 LLM 服务成本削减的突破口所在。

A.X-K2-DSpark 实际上是什么

A.X-K2-DSpark 在任何有意义的层面上都不是一个独立模型。其模型卡在预期用途说明中已明确指出：它是一个“仅草稿检查点”，具有“无独立用途”，由 vLLM 与目标模型 A.X K2 一起加载，在投机解码循环中运行。它是两阶段生成器的草稿阶段——一个小模型快速提议候选 token，而目标模型在任何 token 被提交到输出之前对其进行验证。

作为背景说明，该目标模型是{{1}}现存最大的开放权重模型之一{{/1}}。A.X K2 是 SK Telecom 的 688B 总参数、33B 激活参数的混合专家（MoE）模型，{{2}}于 2026 年 7 月下旬以 Apache 2.0 许可证发布在 Hugging Face 上{{/2}}，{{3}}其基础架构将多头潜在注意力（MLA）与 DeepSeek 稀疏注意力相结合{{/3}}，并{{4}}加入了 SK Telecom 自研的稀疏门控注意力长上下文改进{{/4}}。A.X-K2-DSpark {{5}}以 A.X K2 的隐状态为条件{{/5}}，{{6}}在候选位置之间加入轻量级局部依赖建模{{/6}}，{{7}}从而能够并行提出多个 token，而不是严格自回归式地草拟{{/7}}。每个候选 token 随后都会{{8}}由 A.X K2 验证后提交{{/8}}——这就是模型卡将结果称为{{9}}"构造上无损"{{/9}}的原因：{{10}}输出分布不会因草拟模型而改变，改变的只是推理速度{{/10}}。

推测解码的工作原理，以及为什么 688B 的 MoE 需要它

推测解码之所以存在，是因为自回归生成是串行且受内存限制的。生成每个token都需要从内存中读取模型权重，而对于688B的模型来说，每生成一个token都要移动海量字节——即使在每次前向传播中只有33B参数处于激活状态。其技巧在于，将少量额外计算投入到一个小的草稿模型上，让它一次性猜出接下来的几个token，然后让大模型在单次前向传播中验证所有猜测，并保留与其自身分布匹配的最长前缀。当草稿模型表现良好时，每次大模型前向传播能获得两三个token，而非一个，且最终输出不变。

整场游戏的关键在于接受率。草稿模型如果猜得不准，它提出的token序列就会被拒绝，而验证过程依然消耗同等内存带宽，加速效果也就化为乌有。正因如此，草稿模型本身已成为一个严肃的研究课题：以A.X K2这样的模型规模来说，1.5倍加速与3倍加速之差，就是十块GPU的服务集群与五块GPU的服务集群之差。托管LLM API的下一轮降价正将来自诸如此类的效率层——不是来自基础模型的质量数字，而是来自围绕它们构建的推理服务栈。

DSpark 就是方法——它来自 DeepSeek 团队

模型名称中的“DSpark”是一项特定技术，并非SK Telecom的发明。模型卡引用了论文“DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation”（arXiv 2607.05147），该论文是2026年7月6日发布的预印本，由DeepSeek的33位作者团队撰写，该方法已在作者自有的V4时代服务系统中于真实流量下部署。SK Telecom已将同一技术适配到其自己的目标模型中。

论文的两项贡献直接对应A.X-K2-DSpark卡所描述的内容。首先，半自回归草拟：并行主干网络在一个窗口内提出token，而轻量级顺序模块对候选位置之间的依赖关系进行建模，解决了并行草拟者提出的序列中接受率急剧下降这一经典问题。其次，置信度调度验证：系统并非总是验证固定数量的草拟token，而是估计每个前缀存活的概率，并根据每次请求设置验证长度，同时针对引擎的吞吐量特征进行调优——因此验证工作量是感知负载的，而非统一的。

就论文自身的数据而言——这些数字是作者团队的测量结果，未经独立验证——在吞吐量匹配的前提下，DSpark 的每用户生成速度比生产级 MTP-1 基线快 60–85%，并且在严格的交互性约束下避免了严重的吞吐量退化。阅读这份发布内容时，有两个注意事项值得关注。这些结果是在作者自己的技术栈和目标平台上测得的，并非在 A.X K2 上；同时，A.X-K2-DSpark 模型卡明确说明其自身的评估仍在进行中。论文证明了该方法在生产环境中行之有效，但并未证明 SK Telecom 的检查点能复现这些增益——而这恰恰是尚未确认的部分。

仓库说明了什么——以及它没有说明什么

以下是目前从仓库中能了解到的全部信息，均来自模型卡：

• 角色 — 仅限起草者使用的 A.X K2 检查点；不可单独使用；未与任何其他目标进行验证，且“与无关模型不兼容”。

• 目标 — A.X K2，总计688B / 33B活跃参数的专家混合模型。

• 上下文长度 — 262,144 个 token（256K），与 A.X K2 的原生配置一致。

• 许可证 — Apache 2.0.

• 机制 — DSpark 半自回归草拟；每个候选在提交前均由 A.X K2 验证（无损）。

• 状态——"目前处于最终验证阶段"；计划"在未来几天内发布。"

而以下是尚未明确确认的内容：

• 检查点精度和大小 —— 两者在模型卡上都列为待定。

• 吞吐量、TPOT 和平均接受长度 ——这三个能判断起草者是否真的在干活的数字，目前全部待定（TBD），注明“评估正在进行中”。

• 各领域结果 — 该卡片承诺提供韩语、数学、科学和代码的细分内容，“稍后”提供，但没有具体日期。

• 正式公告——我们找不到SK Telecom在任何地方宣布过A.X-K2-DSpark；该仓库即是公告。

• 独立评分 — 并不存在。卡片上的所有内容都是SK Telecom自己的说法，而且其中大部分仍是承诺。

最关键的未确认数字是平均接受长度（mean accepted length）——即 A.X K2 每次验证通过时接受的草稿令牌（draft token）平均数量。这一个数字决定了该草稿器是 1.2 倍的锦上添花，还是 2.5 倍的服务升级；它也是最有可能在版本上线后无出处流传的数字。当它出现时，请保持怀疑：DSpark 论文中 60–85% 的数值是在不同模型的推理服务栈上测得的，而 A.X K2 有着自己的草稿接受特征。

你实际会怎么运行它。

运行草稿模型意味着通过 SK Telecom 的 vLLM 分支来部署 A.X K2。模型卡片上的示例，稍作删减，如下：

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

使用从 axk2-v0.23.0 分支的 SKT-AI vLLM 代码库中安装的 fork。该卡片直言不讳地指出了几点注意事项：该方案针对的是 A.X K2 的原生 256K 上下文配置，且加速效果取决于工作负载——并发度、输出长度、接受率，以及草拟与验证的相对成本都会影响最终结果。换句话说，这是服务基础设施，而非下载即可运行的脚本。你需要 A.X K2 的权重、一个足以支撑 tensor-parallel 8 的集群，以及耐心去调整 num_speculative_tokens 以适应你自己的流量。对于已经在提供 A.X K2 服务的团队来说，这是一个有意义的项目；但并不足以成为新部署一套的理由。

经济学：效率层胜过质量承诺

对于一个688B模型的草稿模型之所以值得关注，是因为基础模型的基准测试竞赛已基本饱和，而服务成本的竞赛尚未结束。SK Telecom自己的发布已经主打效率——其宣称Sparse Gate Attention这一改动相比上一代在120K token输入下将总token吞吐量提升了67.7%——而草稿模型则是同一思路在解码阶段的应用。每一个被接受的草稿token，都是一次你无需付费的大模型前向传播。

对于通过 API 而非自行托管来使用这些模型的人来说，草稿模型是不可见的——而这正是关键所在。当提供商在其服务栈中加入推测解码时，你看到的并不是一个新模型，而是同一个模型在每 token 上变得更快、更便宜。定价层之所以重要，原因相同：在 OrcaRouter，我们以 0% 加价直接传递提供商的标价，因此当供应商的服务效率提升以降价形式体现时，我们这边当天就会生效——无需重新谈判，无需更改合同。而对于一个尚未证明、未必能成功的模型，使用带有自动故障转移的路由是一种尝试方式，不必把生产路径押在它上面：一个 API 密钥，如果第一个提供商出现性能下降，请求就会自动转移到另一个提供商。

关于此版本的一条坦诚说明：A.X-K2-DSpark 只是一个仅供草稿器（drafter）使用的检查点，因此任何托管模型 API 都无法路由到它——包括我们自己的。草稿器是服务端组件，不是可调用的产品。当草稿器上线且评估数据公布后，出现在价目表上的将是更快、更便宜的 A.X K2，而不是名为“DSpark”的新端点。

几个值得回答的问题

我可以单独使用 A.X-K2-DSpark 吗？不——这正是该版本的决定性事实。它是一个仅用于草稿的检查点，没有独立用途，也没有公共 API；它只作为 vLLM 推测解码循环中的辅助组件存在，为 A.X K2 提供服务，而且模型卡注明它尚未与其他任何目标进行过验证。

A.X-K2-DSpark 是 A.X K2 的竞品吗？恰好相反。它是 A.X K2 的加速器——同一模型运行更快，且输出分布保持不变。可以把它视为一个附加的效率组件，而非产品线中的新成员。

它到底什么时候发布？模型卡显示它正处于最终验证阶段，并计划在“未来几天内”公开发布。目前确认的信息仅此而已。值得关注的日期是那些TBD数据——吞吐量、TPOT和平均接受长度——被填上的那天，因为那时发布就不再是承诺，而是你可以评估的实际成果了。

如果我通过 API 使用 A.X K2，我需要考虑这一点吗？可能不直接需要。API 背后的服务栈决定了是否有草稿模型参与其中；你看到的结果只是价格和延迟，而不是某个标志。这对自行托管 A.X K2 的团队最为重要，因为选择加入是他们可以控制的 vLLM 配置更改。

The story here is not the drafter itself — it is what the drafter signals. 效率工作正在悄然成为独立的发布类别，今年最有趣的新模型越来越多是让大模型变便宜的工具，而不是更大的模型。{{1}}A.X-K2-DSpark是最清晰的例子：一个没有独立用途的检查点，在公告之前发布，其大部分证据标注为TBD。{{/1}}等落地的接受长度数字公布时再关注它，将DSpark论文的收益视为该方法的来源证据，而非这个检查点的承诺；{{2}}如果你自己部署A.X K2，为基准测试留出预算——这是唯一能知道这个悄然发布的草稿模型是1.2倍的锦上添花还是真材实料的方法。{{/2}}