AntLing 发布了用于 Ling-3.0-flash 的 dspark 草稿模型

今日我们开源了 Ling-3.0-flash-dspark，这是专为 Ling-3.0-flash 构建的 DSpark 草稿模型。
在4块 NVIDIA Blackwell GPU 上以批大小为1运行时，它实现了1,120 tok/s 的吞吐量，0.78 ms 的平均 TPOT（每输出token时间），以及9.95的接受长度，共处理了1,000个请求。

Ling-3.0-flash 拥有42层结构：35层 KDA 线性注意力层与7层 MLA 全注意力层。其混合专家（MoE）系统包含512个路由专家和1个共享专家，每个token激活前8个专家加1个共享专家。
这种混合设计即使在8K上下文长度下也能保持较低的注意力计算成本。

批大小为1的设置将每一微秒都暴露无遗——没有更大的批次来吸收启动成本或填补流水线空隙。
在 NEXTN 路径上，我们的系统工程优化将平均输出吞吐量从288 tok/s 提升至606 tok/s，并将平均 TPOT 从3.33 ms 降低至1.53 ms。

在批大小为1时，平均 TPOT 大致等于单步耗时除以接受长度。我们对这两个指标都进行了优化：
SGLang 缩短了每个目标步的时间；DSpark 采用了并行草稿骨干网络、轻量级马尔可夫头用于局部依赖建模，以及用于验证调度的置信头。

我们将公开的 DSpark 方案适配到 Ling 模型，采用了分布对齐数据、架构消融实验和接受感知损失函数。
SplitServe Trainer 在单个8 GPU 节点上同时进行草稿训练和 SGLang 目标推理，使长上下文在线训练保持本地化。

首个 DSpark 追踪显示47%的空闲时间：10.62 ms 的步骤中有4.99 ms 处于空闲状态。
FlashInfer 的 plan() 函数因对 CPU 已知的元数据执行了阻塞式设备到主机读取而成为瓶颈。改为从主机数据构建计划后消除了同步需求，使 CPU 能够在 GPU 需要之前就队列化草稿生成和验证操作。

其他优化包括：移除每步序列长度同步、捕获元数据粘合图、在 MoE、路由器和 KDA 之间添加 PDL 链、将 SwiGLU 融合进上投影 GEMM、重新调优 KDA 链验证、以 bf16 精度运行路由器和 lm_head 层。

相同命令与机器配置下，处理1,000个请求的结果：
调优后的 NEXTN：606 tok/s，1.53 ms 平均 TPOT，3.25 接受长度
DSpark：1,120 tok/s，0.78 ms 平均 TPOT，9.95 接受长度
DSpark 将平均 TPOT 降低了1.9倍。9.95这一数值取决于具体工作负载。

该配置最适合对单用户延迟敏感的交互式智能体、编程助手和推理任务。
主要测试运行采用静态 DSpark 验证、贪心解码、8,192个输入token、1,024个输出token以及合成随机数据。

检查点文件与服务方案现已开放获取。

感谢 @sgl_project 和 @lmsysorg 社区的支持。
完整工程细节：
https://lmsys.org/blog/2026-08-21-ling3-flash-spec-decode-blackwell…

Hugging Face 地址：
https://huggingface.co/inclusionAI/Ling-3.0-flash-dspark…

ModelScope 地址：
https://modelscope.cn/models/inclusionAI/Ling-3.0-flash-dspark…

加入蚂蚁 Ling Discord 频道：
https://discord.com/invite/GNaQc8WC5T…