NVIDIA 悄然为 Meta 的 816B 旗舰模型发布了一款草稿模型

NVIDIA 发布了nvidia/Muse-Spark-Open-816B-A42B-DFlash2 到 Hugging Face，时间是 2026 年 10 月 16 日，却没有告诉任何人。该仓库是一个草稿检查点——一个 43.8 亿参数的推测解码模型，其全部工作就是猜测Muse-Spark-Open-816B-A42B 的后续若干个 token，它是 Meta 的 8160 亿参数开放权重旗舰模型，因此大模型可以在一次前向传播中验证整块猜测，而不是一次只输出一个 token。没有 NVIDIA 博客文章，没有公告帖，没有新闻稿，而且截至撰写本文时，该仓库显示零下载量和零点赞。它确实拥有的是一个带有接受长度表的模型卡、一个可用的 vLLM 调用示例，以及一份它明显拒绝宣称的事项的简短清单。这就是该产物声称了什么，以及没有声称什么。 这些数字无法告诉你的是，其中任何部分是否在实际应用中出了问题：围绕此类模型的已记录 AI 事件和智能体故障都收集在OrcaRouter AI Incident Archive 中，其中每条记录都带有自己的来源、严重程度、置信度等级和争议标记。

已交付的内容，按可检查的顺序排列

以下所有内容均来自该仓库，或来自 Hugging Face 为其提供的自有 API。其中没有任何内容需要你信任厂商基准测试。

• 时间点——该仓库创建于 2026 年 10 月 16 日 04:40 UTC，其权重在大约四十分钟后提交；模型卡自身的发布说明写着“Huggingface: 10/16/2026”。NVIDIA 开发者博客上没有任何配套的发布文章，模型卡也只引用了 DFlash 论文和 Model Optimizer 项目。

• 该产物——一个 BF16 格式的 safetensors 文件，参数量为 4,384,162,432，存储占用约 8.8 GB。其架构类为DFlash2DraftModel，包含五个稠密解码器层，采用窗口大小为 2,048 的非因果滑动窗口注意力，隐藏层大小为 8,192，128 个查询头对应 16 个键值头，每个头 64 维，词表大小为 202,048。块大小为 8；草稿模型从目标的 62 层中抽取五层——第 3、19、31、47 和 59 层。

• 它没有门控限制——Hugging Face 报告该仓库为公开且不受限制。你现在就可以下载这个 drafter，而 Meta 的目标仓库仍处于需要接受条款才能登录访问的状态。

• 许可协议栈 — 该草案检查点受 NVIDIA 开放模型协议约束，而模型卡又在其之上叠加了 Meta 的 Muse 模型许可证，并要求任何基于它构建的内容都标注如下署名字符串："Built with Muse Spark Open"。

• 来源说明，由 NVIDIA 声明——该卡片自带的第三方声明明确指出，Muse-Spark-Open-816B-A42B“并非由 NVIDIA 拥有或开发”，且该起草者“由 NVIDIA 训练，以配合该目标模型使用”。训练提示来自 NVIDIA 的 Nemotron-Post-Training-Dataset-v2，约 348 万个多语言样本，涵盖数学、代码和 STEM，其回复由目标模型在五个推理强度级别上合成生成。

• 工具链——卡片上写着，该模型是用“NVIDIA Model Optimizer 0.47 的预发布版本”训练出来的。Model Optimizer 0.47.0 已于 2026 年 9 月 23 日公开发布，0.48.0rc0 也紧随其后于 10 月 8 日发布，因此这个 drafter 所依据的配方，如今第三方已经可以重新运行了。

这不是该模型的首个草稿模型，也不是 NVIDIA 的首个草稿模型。

这两个事实对于判断这里真正新在何处都很重要，因为单凭其中任何一个，都会让这次发布显得像是另一种东西。

NVIDIA 自入夏以来一直在悄悄为其他人的开放权重发布 DFlash 系列起草器：6 月中旬的 MiniMax-M2.7-DFlash，6 月至 7 月间先后推出的 Kimi-K2.6-DFlash 和 Kimi-K2.7-Code-DFlash，以及 8 月初的一款 Nemotron 3.5 Lightning 30B 起草器。NVIDIA 的 Muse Spark Open 起草器是该系列中的下一款产品，而非首次亮相。

Muse Spark Open 在这一个之前就已经有草稿模型了。一个隶属第三方组织的 DFlash2 检查点于 10 月 13 日发布到了 Hugging Face，而面向同一目标的 DSpark 检查点最近一次更新是在 10 月 15 日——两者都比 Meta 自家那套首日方案晚了大约一个月，后者为其中一个运行时命名为 DFlash V2，为另一个命名为 DSpark。所以，“Muse Spark Open 存在草稿模型”并不是重点所在。

这个故事的范围更窄，也更有用：NVIDIA 自己的、经 Model Optimizer 训练的 BF16 DFlash2 检查点现在已为该模型提供，面向 Blackwell 硬件发布，并以 vLLM 作为其经过测试的引擎。如果你正在选择要运行哪个草稿模型，这实际上是在选择服务栈，而两条路径正是在这里分道扬镳。

数字，以及与之相关的确切条件

NVIDIA 在三个测试集上报告了一个量：接受长度，即每个生成步骤发出的令牌平均数，在草稿长度为 7 时测量。

• MT-Bench，80 个两轮问题——在贪心解码下每个接受步为 3.73 个 token，采样下为 3.01。数学是最强的类别，达 4.47；人文学科最弱，为 2.92。

• SPEED-Bench 定性评测，涵盖 11 个类别的 880 条提示词 —— 贪心解码 3.72，采样 3.01。多语言达到 4.27，编程为 4.15，而写作仅为 3.05。

• SPEED-Bench 吞吐量，32,000-token 输入 — 3.30 贪心和 2.78 采样，而这里情况开始变糟：高熵桶骤降至 2.51 贪心和 2.16 采样，而低熵文本为 3.71。

• 条件 — 推理强度 xhigh、4,096 个输出 token、并发 32，在单台 GB300 节点上以 TP4 和 EP4 运行，通过 vLLM 提供服务，目标模型采用 NVFP4。贪婪解码的数据为温度 0；采样数据为温度 1.0，不使用 top-p 或 top-k 截断，采用概率式草稿采样方法。

这三条告诫应当放在那些数字旁边，而不是放在它们下面。第一，它们都是厂商自报的，我们尚未复现其中任何一项，也没有其他人发表过对这个检查点的独立测量结果。第二，接受长度并不是加速比——它只是计算加速比时所依据的上限。每一个被接受的 token 仍然必须由这个 8160 亿参数的模型进行验证，而草稿模型自身的前向传播也有开销；NVIDIA 既没有公布每秒 token 数之比，也没有公布延迟对比，而这正是读者在决定是否部署它时想要看到的数字。第三，所有这些都是在并发数为 32 的条件下测得的，而这并不是投机解码通常收益最好的场景——收益主要集中在受延迟约束、低批次的单条流上，而繁忙的服务器获得的收益会更少。

这些表格完全没有衡量的是输出质量。贪心解码下的验证旨在返回目标模型自身的 token，因此贪心那一列基本上只是一个纯粹的速度声明。采样那一列才应该在你自己的流量上测试，因为概率式草稿模型改变的是分布被遍历的方式，而不只是速度。

你实际上会如何开启它？

该卡给出了一种受支持的调用方式，即在 vLLM 服务器上使用单个标志。你为 target 提供服务，并通过 speculative-config 参数传入 drafter：方法为 "dflash"，模型为 NVIDIA checkpoint，推测 token 数为 7，草稿采样方法为概率采样，且该命令需要信任远程代码。TensorRT-LLM 是该卡列出的第二个引擎；vLLM 是它指定为加速引擎的那个，也是它在 Blackwell 上测试过的那个。

有两个缺口值得点明。这张卡的受支持硬件一栏是 NVIDIA Blackwell 配 Linux，所以这是一条数据中心 GPU 路线，而不是能并入 Apple-silicon 或消费级配置的方案。而 SGLang——Meta 自己的发布材料让 DFlash V2 所经由的那个运行时——在 NVIDIA 为这个检查点列出的引擎中完全没有出现。这两个草稿模型不可互换；如果你的服务栈是 SGLang，这个仓库就不是为你写的。

起草者会为读者改变什么，以及不会改变什么

推测解码是大模型推理中触及那些永远不会下载权重的人的部分，因为它是决定超大型开放模型能以多低成本被提供服务的主要杠杆。更好的草稿模型意味着每步有更多被接受的 token，也就意味着每 GPU 有更高吞吐量，而这最终会体现为 API 上更低的价格和更快的首 token 时间。这就是为什么一个 4.38B 模型会成为新闻，尽管读到它的人几乎没人会真正运行它。

话虽如此，这一个并不会把 816B 模型摆到你的桌面上。它是某个目标模型的 8.8 GB 附属件；该目标模型的最小实用检查点也以数百 GB 计，运行在 Blackwell 芯片上，并且受两个相互叠加的许可证约束。它不是那种供你聊天的模型，它自身不产生任何文本，而且如果没有那个它被训练来为之起草的目标模型，它根本无法运行。

如果你想要 Muse Spark 的能力，又不想沾上上面这些麻烦，那么正式提供服务的产品线才是它的所在：Muse Spark 1.2 和 Muse Spark 1.1就是 OrcaRouter 路由的那两个检查点，两者都按 Meta 的标价、0% 加价原样透传，因为供应商的价格是原样透传而非加价。Muse Spark Open 和这个 DFlash2 草稿检查点不在我们的目录中，我们也不会暗示相反的情况——为自托管权重服务的草稿模型，本身就是自托管基础设施。我们在这一点上仍然有用的地方是那些无聊的部分：一套 API 覆盖 200+ 模型、供应商性能下降时自动故障转移，以及通过配置而非改代码来在模型之间调度流量的路由 DSL，这是一种低成本的方式，能在不拿生产路径下注的前提下，摸清一个未经验证的检查点在真实流量上的表现。

什么能解决这些悬而未决的问题

有四件事会改变本文，而它们都不是关于 NVIDIA 意图的谜团。

• 端到端的加速数据——在同一硬件上，与对应的非推测解码基线相比的每秒 token 数或延迟，且由 NVIDIA 以外的任何人测量。接受长度只说明草稿经常被命中，并不能说明服务器变快了。

• BF16 与 NVFP4 目标的对比——所有已发布的表格都是针对 NVFP4 目标测得的，而大多数人实际部署的正是这一目标，但该卡并未报告任何目标以更高精度运行的情况。

• 在 vLLM 和 TensorRT-LLM 之外的支持——如果该检查点出现在 SGLang 中，Muse Spark Open 的两个 DFlash2 草稿器就变得可以互换，而不再与特定技术栈绑定，此时在两者之间做选择就变得简单了。

• 基于已发布工具链的重新训练 —— 这个草稿模型出自 Model Optimizer 0.47 的一个预发布版本。0.47.0 自 9 月 23 日起已公开发布，0.48.0rc0 自 10 月 8 日起也已发布，因此这套配方可供审查，而在其上训练出的检查点很可能会报告略好一些的结果。

至少在其中第一项落地之前，诚实的总结是：NVIDIA 为别人的旗舰模型发布了一个文档完备、无需申请、针对特定硬件的草稿模型，公布了接受长度，却没有发布公告——而值得关注的原因不在于 Muse Spark Open 变快了，而在于让 8160 亿参数开放权重在大规模下变得可负担的基础设施，正以如此悄无声息的方式不断到来。