厂商在合成负载上把 124B MoE 的解码从 36 提到 103 tok/s：DGX Spark 三招拆解，以及那个会静默让服务变慢的回退（NVIDIA 官方报告解读） - 技术文章

除另行标注外，本文引用的事实与页面核验时点为 2026-10-30（北京时间）。文中凡出自 NVIDIA 官方博客、产品规格页、模型 config.json 或官方 cookbook 的数字，一律用 [n] 标注编号；凡本文按公开常量自己算出来的数字，一律标「本文自行推导」，并在第五节与末尾的推导清单里写清假设、中间值与不适用边界。本文没有任何端到端实测：既没有 DGX Spark，也没有下载权重跑过；所有吞吐、延迟、字节数，都是官方报告数值的转述，或按公开常量复算的估算。

一、结论先行：它是什么、为什么值得现在读、对写代码的人意味着什么

一句话版本：在这台机器上，单请求解码的瓶颈主要不在算力，而在「每生成一个 token 要把多少字节的权重从内存搬进计算单元」；官方报告做的三件事，分别是让同样的字节搬得更满、少搬一部分字节、以及一次搬运换回更多 token。

它是什么：NVIDIA 开发者博客在 2026-10-27 发布《3 Ways to Boost MoE Inference on NVIDIA DGX Spark》，作者 Yang Liu（下称「官方博客」）[1]。评测对象是 Inclusion AI 的 Ling-3.0-flash，1240 亿总参数、每 token 激活 51 亿参数的稀疏 MoE 模型 [1]。硬件是单台 DGX Spark：GB10 超级芯片、128 GB LPDDR5X 统一内存、标称内存带宽 273 GB/s、支持 FP4 的第五代 Tensor Core 标称 1 petaFLOP [2]。执行批大小（batch size）为 1，即一次前向只处理一个位置；这不等于「覆盖所有单人聊天负载」——真实服务里还有请求并发、排队、变长输出与多轮上下文，本文只在 batch=1 这个工作点上讨论。

为什么值得现在读，用可核验的事实说，不用「很热门」这类判断：官方博客的发布日期是 2026-10-27 [1]；配套的 ling-cookbook 仓库当前 README 里，Ling-3.0-flash 在单台 DGX Spark 上的配方同时给了 SGLang（MXFP4 基线、MXFP4 + Humming、INT4）与 vLLM（FP4、INT4）两组入口 [5]（这是本文核验时点的仓库状态，没有对应到具体 commit，版本范围见末节）；同一评测对应的量化产物 inclusionAI/Ling-3.0-flash-fp4 在 Hugging Face 上可访问 [8]。也就是说，「厂商宣布一个数字」与「有公开配方可对照」之间的距离，这一档被压得比较短——这才是它值得写的理由，而不是转述一个漂亮的倍数。

先分清三个指标，后文不会再用别的定义：**TPOT（time per output token）**是解码阶段每产出一个 token 的耗时；**解码吞吐（tok/s）**在单请求小批下约等于 TPOT 的倒数；端到端延迟还要加上首 token 之前的 prefill 与排队、以及输出 token 数的累加。三者不能互相替代，每个比较都会注明用的是哪一个。

三招在厂商合成负载上的结果（32K 输入、2K 输出、batch=1、贪心解码，全部为厂商口径）[1]：

配置	TPOT（每输出 token 耗时）	解码吞吐	相对基线
基线：W4A8 + FlashInfer MXFP4 MoE + `--enable-fp32-lm-head`	27.71 ms	36.09 tok/s	—
+ Humming MXFP4 MoE 内核	25.35 ms	39.45 tok/s	+9.3%
+ 在线 FP8 输出层（LM head）	22.76 ms	43.94 tok/s	+21.7%
+ MTP（NEXTN，steps=3 / topk=1 / draft_tokens=4）	9.72 ms	102.88 tok/s	+185.1%

同一套配置换到真实负载（GSM8K 数学应用题测试集（Cobbe 等，2021）的全部 1319 题 [7]，五样本提示、temperature 0.6 / top_p 0.95 / top_k 29、开启思维链）[1]：

指标	基线	三招全开	差额
TPOT	26.45 ms	18.56 ms	−29.8%
解码吞吐	37.81 tok/s	53.89 tok/s	+42.5%
GSM8K 测试集准确率	96.89%	96.82%	−0.08 个百分点
MTP 接受长度	—	2.68 token/轮	—
平均端到端延迟	15.21 s	11.49 s	−24.5%
延迟 P50 / P95	8.36 / 50.20 s	6.11 / 38.60 s	−27% / −23%
首 token 延迟（TTFT）	0.207 s	0.214 s	本次结果未见改善

两张表之间再补一句口径提醒：权重存储位宽（BF16 / FP8 / MXFP4）与 logits 的计算精度（FP32 / FP8）不是同一件事。基线的「FP32 LM head」指的是它用 FP32 输出 logits、并走一条更慢的词表 GEMM，不是说权重以 FP32 存储。

对写代码的人意味着什么，可以压成三句。第一，单请求解码的速度上限主要由「每 token 要读多少字节」与「这台机器的内存带宽」共同决定，峰值算力往往不是这里的约束；换一块算力翻倍而带宽不变的芯片，这类工作点的速度基本不动。第二，要压的不只是权重：这个案例里输出层一个人就占每 token 读取量的约 24%（本文自行推导），把它从 BF16 压到 FP8 换来 10% 量级的提速。第三，多层优化叠加最贵的故障形态是静默回退：官方博客专门警告，两招同时打开时若接口没接对，框架会悄悄退化到比不做任何优化还慢的配置 [1]——它不报错，只让你变慢。

二、把三个口径分开：厂商报告、规格与配置、本文估算

本文只用三类材料，且不混用它们的可信度：

第一类是厂商报告值：TPOT、吞吐、接受长度、GSM8K 准确率、以及「验证成本比约 2.26」这类内部测量值 [1]。它们的证据强度是「厂商报告」，不是第三方复测；本文一律转述并标编号。

第二类是规格与配置：DGX Spark 的 273 GB/s 与 128 GB [2]、模型的 config.json 结构 [4]、cookbook 的配方清单 [5]、SGLang 文档对 MTP 参数的描述 [6]。这类数字可以直接核读，但要注意 273 GB/s 是标称值，不是任何内核的实测值。

第三类是本文换算：每 token 字节数、等效带宽、达成率、专家期望数、回退形态的时间估算。这类只作量级判断，全部标「本文自行推导」，并写明假设与不适用条件。

跨层比较是这类文章最常见的错误来源：拿第一层的厂商百分比，乘第二层的标称规格，再宣称得到第三层的「实测结论」——三步里每一步都在放大误差。本文会在每个换算处明确说明它依赖的是哪一层。

三、机器、模型与基线配置

硬件的关键规格（产品页 [2]）：GB10 Grace Blackwell 超级芯片；系统内存 128 GB LPDDR5X，CPU 与 GPU 共享的一致性统一内存；内存带宽 273 GB/s；支持 FP4 的第五代 Tensor Core 标称 1 petaFLOP。

模型的关键结构（config.json [4]，本文逐项核读）：architectures 为 BailingMoeV3ForCausalLM；hidden_size 2560； num_hidden_layers 42；vocab_size 157184；num_attention_heads 与 num_key_value_heads 均为 32； MLA 的 kv_lora_rank 512、qk_nope_head_dim 128、qk_rope_head_dim 64； moe_intermediate_size 768、num_experts 512、num_experts_per_tok 8；num_nextn_predict_layers 1； max_position_embeddings 262144；torch_dtype bfloat16；first_k_dense_replace 2。官方博客补充层构成：42 层里 35 层采用 KDA（Kimi Delta Attention，一种线性注意力机制，出自 MoonshotAI 的 Kimi-Linear 工作，本模型是「采用该机制」而非提出者）[1]，7 层是多头潜在注意力（MLA）[1]；每个 MoE 层把每个 token 路由到 512 个路由专家中的 8 个，另加 1 个共享专家 [1]。

有一处口径必须点出：公开的 config.json 里没有 quantization_config 之类字段（本文核读），它描述的是 bf16 母体结构；评测用的是 W4A8 量化产物，inclusionAI/Ling-3.0-flash-fp4 是它的公开入口 [8]，但其中的量化器、校准集、分组大小与排除层清单，本文没有逐项核读。所以「权重 4 bit」是评测配置的属性，不是模型卡的结构属性——后面所有字节账都建立在这个前提上。

基线配置：cookbook 的 W4A8 形态，MoE 用 FlashInfer 的 MXFP4 内核，稠密部分用 NVIDIA CUTLASS GEMM，并开启 --enable-fp32-lm-head（输出层 logits 用 FP32 计算，走一条更慢的词表 GEMM）[1]。 注意这里已经出现两个不同层面的「精度」：权重存储位宽（BF16 / FP8 / MXFP4）与 logits 的计算精度（FP32 / FP8）。第二招动的是后者的实现路径与前者的存储，两者不可互换说法。

四、第一性原理：一次普通解码步要搬多少字节

先给直觉。解码阶段的形状是：每一步只处理一个位置，但这一步要用到的权重必须整块从内存读进寄存器。像一家餐厅每来一位客人，厨房都要把食材从仓库搬到操作台——batch 就是「这批食材能摊给几位客人」，只有一位客人时，搬运量就是实打实的全部。

形式化。设每 token 激活参数为 $P_{\text{act}}$ ，激活权重平均位宽为 $b_w$ ，词表大小为 $V$ ，隐藏维度为 $d$ ，输出层位宽为 $b_{lm}$ 。一次普通解码步需要读过的字节数，本文用一个简化估计：

B_{\text{step}} \;\approx\; \underbrace{\frac{P_{\text{act}}\,b_w}{8}}_{\text{激活权重}}\;+\;\underbrace{\frac{V\,d\,b_{lm}}{8}}_{\text{输出层}}

这个估计的边界必须一次说清，否则后面的数会被误用：它假设全部激活参数都按同一个位宽（这里是 4 bit）读取，因此（一）不含量化元数据——微缩放格式的共享缩放因子、分块填充会额外占少量字节；（二）不含量化精度不一致的部分——实际模型里注意力与共享专家未必都是 4 bit；（三）不含 KV 读取（见第十三节，它是上下文长度的函数）；（四）不含激活值、临时缓冲与内核工作区；（五）输出层单列，因为它在 checkpoint 里被排除在量化之外。换了模型或换了精度配方，这个式子要重算。

代进本案例： $P_{\text{act}} = 5.1\times10^{9}$ 、 $b_w = 4$ ，激活权重项约 $2.55\times10^{9}$ 字节 = 2.55 GB；输出层 $157184\times2560 = 4.02\times10^{8}$ 个参数（本文自行推导），BF16 下 0.805 GB、FP8 下 0.402 GB；两项合计，基线约 3.36 GB、FP8 输出层后约 2.95 GB（本文自行推导）。这些数都是「跨全模型的估算载荷」，不是某一层的读取量。

下面这张图画的是这一估算的对象，以及两笔主要字节量落在哪里：

flowchart LR
  A["一次普通解码步<br/>batch = 1"] --> B["MoE 路由：512 选 8 + 1 个共享专家"]
  B --> C["跨全部 MoE 层读取被激活的专家权重<br/>全模型合计约 2.55 GB（估算）"]
  C --> D["累加回 hidden = 2560"]
  D --> E["输出层词表 GEMM<br/>2560 x 157184"]
  E --> F["采样得到 1 个 token"]
  C -.->|"跨层合计，不是单层读量"| G["内存总线：标称 273 GB/s"]
  E -.->|"BF16 0.805 GB / FP8 0.402 GB"| G

这张图说明了什么：**一次解码步的字节量主要落在两处——被激活的专家权重（跨层合计）与整个输出层矩阵；其余项在这个模型、这个上下文长度下是零头。 ** 因此可能的手段只有三类：让同样字节搬得更满（内核形状）、压缩这两处的字节（量化）、让一次搬运换回多个 token（投机解码）。三招正好各占一类。

五、等效带宽与达成率：44% 这个数说明什么、又不说明什么

把第四节的估算除以厂商报告的 TPOT，会得到一个「按估算读量反推的等效带宽」：

B_{\text{eff}} \;=\; \frac{B_{\text{step}}}{\text{TPOT}} \;\approx\; \frac{3.36\times10^{9}\ \text{B}}{27.71\times10^{-3}\ \text{s}} \;\approx\; 121\ \text{GB/s},\qquad U \;=\; \frac{B_{\text{eff}}}{B_{\text{spec}}} \;\approx\; \frac{121}{273} \;\approx\; 0.44

必须立刻说清它是什么、不是什么。**它是「估算读量 ÷ 厂商报告的 TPOT」得到的等效指标，不是任何硬件计数器测到的总线利用率。 ** 它把内核启动、同步、调度、取样、Python 与框架开销全部折算进了「带宽」这一个数里。因此：

它能说明的是（下面两条均为本文自行推导）：在这台机器、这个工作点上，时间并没有被标称带宽所限，存在约一半以上的余量被别的东西吃掉；
它不能说明的是：总线在某一时刻是否饱和、余量具体分给哪些开销。要回答后者，需要硬件的带宽计数器与逐内核分时，这些材料本文没有。

在这个前提下可以说的判断是：这个工作点更像是活在被「字节搬运 + 相关执行开销」共同限制的区间里，而不是被峰值算力限制。 用一个可算的量支撑这句话：算术强度约 $2P_{\text{act}}/B_{\text{step}} = 3.0$ FLOP/byte（本文自行推导），而这张卡的「里奇点」（算力与带宽的平衡点）是 $1\times10^{15}/273\times10^{9} \approx 3663$ FLOP/byte（本文自行推导），两者差三个数量级。工作点离算力墙很远，这个结论是稳的；但「离算力墙远」不等于「带宽已经打满」。

还要提醒方向性： $U$ 随 batch 上升而上升（权重读取被摊薄），所以本文所有比例只在 batch=1 或极小批下成立。批到 8、16 之后，瓶颈会从搬权重逐步转向算矩阵，那时「减少步数」类手段的相对收益会下降。

六、第一招 Humming：为「窄形状」现场编译内核

官方博客的第一招是把 MoE 执行后端从 flashinfer_mxfp4 换成 Humming [1]。 Humming 是一个独立内核库（humming-kernels），机制是用 CUDA 运行时编译（NVRTC）在运行时按真实 M/N/K 维度、数据类型与 GPU 架构生成并编译 CUBIN，缓存在 ~/.humming/cache [1]。

在这个模型上有效的理由，官方给的是「针对 Ling-3.0-flash 的形状特化，包括较窄的 moe_intermediate_size（768）」[1]。翻译成工程语言：预编译内核库要覆盖大量形状，官方提到 CUTLASS 路径用 ninja 编 97 个目标、耗时以十分钟计；运行时编译可以只为你这一种形状生成最贴合的代码 [1]。代价是首次启动要多花编译时间——具体几秒，本文没有测量，也没有公开数字。

效果是合成负载上的 TPOT 27.71 → 25.35 ms（+9.3%，厂商报告值）[1]。这一步没有减少要读的字节（按第四节估算仍是 3.36 GB），收益来自「让同样的字节搬得更满」。用同一套估算可反推这一档的等效带宽约 132 GB/s（本文自行推导）：

B_{\text{eff}}' \;=\; \frac{3.36\times10^{9}}{25.35\times10^{-3}} \;\approx\; 132\ \text{GB/s}

这个量级说明：只换内核不动数据，能拿到的属于「利用率」这一档的收益，天花板有限；要再往上，得动字节数或动步数。官方没有给逐内核的分时拆解，所以这 2.36 ms 里有多少来自形状贴合、多少来自启动次数减少，本文无法判定（见第十五节空白项二）。

七、第二招 FP8 输出层：被忽略的 4 亿参数

第二招是给输出层（LM head）做在线 FP8 量化 [1]。官方说明：checkpoint 里输出层以 BF16 存储并被列在 modules_to_not_convert 中，加载时不会被量化；它的词表 GEMM 是 $157184\times2560$ ，每生成一个 token 都要把整块权重读一遍 [1]。

账（本文自行推导，参数取自 config.json [4]）：402.39 M 参数，BF16 下 0.805 GB，占基线估算读量的 24.0%；压到 FP8 后 0.402 GB，占 13.6%。写成本式：

B_{lm} \;=\; \frac{V\,d\,b_{lm}}{8},\qquad \Delta B \;=\; B_{lm}^{\text{BF16}} - B_{lm}^{\text{FP8}} \;=\; \frac{V\,d}{8}\;\approx\; 0.402\ \text{GB}

对照要说清是「哪一段」的对照。反事实估计：若把 0.402 GB 放进第一节那套基线（TPOT 27.71 ms、等效带宽 121 GB/s），应省约 3.32 ms（本文自行推导）； 实测增量是合成负载上这一步相对 Humming 中间档（25.35 → 22.76 ms）省 2.59 ms [1]。两者不是同一个对照：前者用基线的等效带宽去预测「从零加这一招」，后者是「在已经有 Humming 的基础上再加」。若改用紧邻的上一档做基准（Humming 档、等效带宽 132.3 GB/s），这一档的 TPOT 预估是 22.31 ms，厂商报告值是 22.76 ms（本文自行推导），差约 2%——在这个阶段，只用读量模型得到的预估值与厂商报告值相差约 2%——这个量级的吻合说明读量口径是这一段的主要解释变量；单点吻合不足以排除其它因素，本文不据此宣布机制已确定。上面提到的 24.38 ms 只属于「从原始基线起算」的反事实口径，不能读成「实测比模型更快」。

实现上是一个环境变量 SGLANG_ENABLE_FP8_LM_HEAD=1，与基线的 --enable-fp32-lm-head 互斥 [1]。这里再强调一次本节开头的区分：输出层量化、MoE 权重量化、KV 缓存量化是三件不同的事。本文这一招动的是输出层（权重存储从 BF16 到 FP8，同时把 logits 路径从 FP32 换掉）；它不省 KV 字节，也不改变注意力计算，只影响最后那次词表投影——但因为它每 token 必读，占比足以让整条链路快 10% 量级。

八、第三招 MTP：减少的是「步数」，不是「字节」

前两招压缩「每步成本」。第三招换方向：减少步数。 Ling-3.0-flash 自带一层 NEXTN 预测层（num_nextn_predict_layers: 1），可直接当草稿模型用，不需要另外训练或下载 [1]； SGLang 文档把这类做法归在投机解码的 MTP 选项下，用 speculative_num_steps、speculative_eagle_topk、num_draft_tokens 这组参数控制 [6]。因此要区分「模型内置的预测层」与「框架启用它的算法选项」，两者不是一回事。

配置是三个草稿步、四 token 的验证窗口：一轮里草稿按序生成 3 个 token，目标模型一次验证 4 个位置，接受最长的正确前缀 [1]。

收益由两个量共同决定，官方点名了这两个 [1]，本文只在这一处定义、后文不换口径：

$a$ ：接受长度，一轮里最终被接受并提交的 token 数。官方合成负载是 3.90、GSM8K 是 2.68 [1]。注意 3.90 大于「草稿 3 步」，说明它包含了目标模型在验证中额外给出的那个 token，而不是只数被接受的草稿 token。
$c$ ：验证成本比，官方给的定义是「一次验证步相对一次普通解码步的成本」[1]，取约 2.26。本文按时间口径使用它，即一轮「草稿 + 验证」相对一次普通单 token 解码步的时间比。官方没有说明这个数是在哪种输出层配置下测的、是否已含草稿三步的开销，所以它是「条件未知的厂商测量值」；本文不把 $c$ 当作字节倍率；第十节把 $c$ 折算进「每 token 等效字节」时，用的是同一时间口径下的等价换算（一轮时间 ÷ 每轮 token 数），而不是把 $c$ 改定义成字节比。

在上述时间口径下：

S \;=\; \frac{\text{TPOT}_{0}}{\text{TPOT}_{1}} \;\approx\; \frac{a}{c}

代入 $a = 3.90$ 、 $c \approx 2.26$ 得 1.73 倍，即 TPOT 应降到 $22.76\times2.26/3.90 \approx 13.19$ ms；厂商报告值是 9.72 ms（本文据此推算，差额不归因）。这个差额不解释成「某条机制已被证明」：它只能说明三件事里至少有一件与假定不同—— $c$ 的实际值更小、验证步的时间并不与字节线性同增、或者 $a$ 与 $c$ 的测量负载不一致。本文把它列为未解项（第十五节）。若改用「字节倍率」口径反推， $c_B$ 需约 1.55 才能对上 9.72 ms，与官方 2.26 相差明显，这本身就是「两个口径不能混用」的证据。

再补一个能算的机制：专家数。每 token 从 512 个专家里选 8 个，4 个 token 各自独立选，期望的不同专家数是

\#E_{4} \;=\; 512\times\left[1-\left(1-\frac{8}{512}\right)^{4}\right] \;\approx\; 31.3

即接近上限 32（本文自行推导）。官方把验证成本的主要来源归给 MoE 专家激活（一次普通解码为 1 个 token 激活 8 个专家，验证要处理 4 个 token、可能激活最多 32 个），并指出 batch=1 下 KV 读取相对权重读取较小 [1]。这与上面的专家数一致：验证步的代价主要在专家权重的激活面变宽，而不是注意力。

下图画出这一轮流程，以及那条容易被忽略的回退分支：

flowchart TD
  S["上一轮已接受的 token"] --> D1["NEXTN 草稿第 1 步"]
  D1 --> D2["草稿第 2 步"]
  D2 --> D3["草稿第 3 步"]
  D3 --> V["目标模型一次验证 4 个位置"]
  V --> ACC["接受最长正确前缀<br/>合成 3.90 / GSM8K 2.68（含额外 token）"]
  ACC --> OUT["本轮提交若干 token"]
  V --> FB["回退分支：草稿只拿到 weight tensor<br/>FP8 权重被按 BF16 解释"]
  FB --> BAD["接受长度掉到 1.00<br/>厂商称比不做优化还慢"]

这张图说明了什么：MTP 的净收益由「接受长度」与「验证成本」两个量共同决定，接受长度只是其中一半；而它的失败形态不是报错，是「这轮没有拿到额外收益，但仍然输出 token」——代价是多付一次验证成本。第十一节会把这个形态的代价算成假设性估计。

九、三个成本口径：每步、每请求、每端到端

这一节单独拆口径，因为后面解释两条负载路径的收益差异时最容易在这里出错。

每步成本：一个解码步的 TPOT。前两招降的就是它（少读字节、搬得更满）。它与「输出多长」基本无关——每一步都要读一遍激活权重。

每请求固定开销：首 token 之前的一次性部分，包括 prefill（对整段 prompt 做前向）与调度、初始化。它按请求计，不按 token 计。官方数据里 TTFT 从 0.207 s 到 0.214 s，本次结果未显示改善 [1]。

端到端延迟：TTFT + TPOT × 输出 token 数 + 排队。平均延迟从 15.21 s 降到 11.49 s [1]，这一项里既有每步收益也有输出长度分布的影响。

于是「输出长度」的作用要分开说：如果输出很短，那么每请求固定开销（TTFT、初始化）在端到端里的占比上升，而前两招降的是每步成本，摊到少量 token 上，端到端改善就变小； 如果输出很长，每步成本被乘以更多 token，端到端改善变大，但同时 KV 读取会开始显著（第十三节）。官方给的分布是：GSM8K 平均输出 567 / 607 token、中位数约 310、P95 约 1900–2060 [1]——中位数与均值差两倍，这正是「用均值讲端到端、用中位讲体验」会打架的地方。

十、累计收益与局部增量：185.1% 与 42.5% 不是同一种「总」

先明确比较口径，再谈差额。第一节的表里，合成负载的 185.1% 是「基线 → 三招全开」的累计收益； GSM8K 的 42.5% 也是「基线 → 三招全开」的累计收益 [1]。两者起点和终点相同、负载不同，可以比；但不能把合成路径里「前两招之后的 22.76 ms」当成 GSM8K 路径的起点，那会算出一个混合口径的加速比。

第三招（MTP）在 GSM8K 上的单独增量，公开材料没有给——官方只给了基线（26.45 ms）与三招全开（18.56 ms）两端，没有给「只开前两招」的 GSM8K 中间档。因此本文不给 GSM8K 的 MTP 增量数字；任何这样的数字都会是推算出来的，不是厂商报告的。

能算的是把总加速比拆成两个因子的乘积（本文自行推导）：每接受一个 token 的等效读取字节（含 FP8 输出层与 MTP 摊薄），与反推的等效带宽。合成路径：等效字节从 3.355 GB 降到 $2.26\times2.952/3.90 = 1.711$ GB，因子 1.96；等效带宽从 121.1 GB/s 升到 176.0 GB/s，因子 1.45；乘积 2.85，与实测 $102.88/36.09 = 2.85$ 吻合。GSM8K 路径：等效字节降到 $2.26\times2.952/2.68 = 2.489$ GB，因子 1.35；等效带宽从 126.8 GB/s（3.355 GB ÷ 26.45 ms）升到 134.1 GB/s，因子 1.06；乘积 1.43，与实测 $53.89/37.81 = 1.43$ 吻合。

这个分解算术上能闭合，但它不唯一：两个因子都依赖 $c = 2.26$ 的换算，若 $c$ 实际更小，字节项会变大、带宽项会按同样比例变小（乘积不变）。因此它能说明的是「两条路径的差别主要落在每 token 等效字节这一项（1.96 对 1.35），而等效带宽的提升在真实负载上小得多（1.45 对 1.06）」；它不能说明 $c$ 的真实取值，也不能替代逐项分时——这两点仍是本文的未解项（第十五节）。

差异来源	合成负载	GSM8K 测试集	对加速比的影响方向
输出可预测性（决定接受长度）	高度重复， $a=3.90$	真实推理， $a=2.68$	每 token 等效字节因子从 1.96 降到 1.35
采样参数	贪心解码	temperature 0.6 / top_p 0.95 / top_k 29	采样越随机，草稿越难对上
输出长度分布	固定 2K 输出	中位约 310、均值 567→607 token	每步收益被摊到不同的 token 数上

准确率那一行要按证据说话：官方报告的是 96.89% → 96.82%，并把它描述为「无统计上可检出的精度变化」[1]。 本文没有逐题结果，也没有拿到检验方法，因此既不能独立判断显著性，也不能把它写成「无损」。对上线决策来说，正确做法是在自己的目标分布上重跑并给区间。

十一、那个会静默让服务变慢的回退（假设性估计）

官方博客用一段专门的警告讲这件事 [1]：当「在线 FP8 输出层量化」与「MTP」同时开启时，草稿模型必须与目标模型共享整个输出层模块，而不只是共享它的权重张量；原来的 Ling NEXTN 实现没有暴露这个接口。缺了它，框架会静默回退：草稿拿到 FP8 权重却按 BF16 解释，接受长度掉到 1.00，吞吐变得比不做任何优化还低。

「比不做优化还低」是厂商的描述 [1]；具体低多少，本文只能给假设性估计。在第八节的时间口径下，令 $a = 1.00$ ：

\text{TPOT}_{a=1} \;\approx\; c\times\text{TPOT}_{\text{中间档}} \;=\; 2.26\times22.76\ \text{ms} \;\approx\; 51\ \text{ms}\ \Rightarrow\ \approx 20\ \text{tok/s}

也就是基线 36.09 tok/s 的约 55%（本文自行推导，用的是验证成本比 2.26 与中间档 TPOT，不是厂商给出的回退实测值）。这个估算的意义不是精确，而是量级：接受长度掉到 1 时，每轮付的验证成本照付，却只拿回 1 个 token——于是「开了投机解码反而更慢」的一部分病例，根源不在模型不适配，而在草稿与目标的接口没对齐。

可以固化的做法分两层，不要混成一件事：

启动配置检查（能查到什么就查什么）：MoE 后端名是否为 humming、输出层是否走了 FP8 路径、MTP 是否被框架真正启用、草稿与目标是否共享了完整的输出层模块。这些是配置项，不依赖负载。

运行收益验收（必须用负载测）：同负载下比较「只开前两招」与「三招全开」的 TPOT 与整轮成本；接受长度要跑起来才知道，官方给的 3.90（合成）/ 2.68（GSM8K）[1] 可作参考区间，但不是达标线——接受长度大于 1 并不保证净收益，还要看 $c$ 。如果「三招全开」不优于「只开前两招」，候选原因不止一个：接口没对齐、草稿成本过高、负载不匹配、或测量噪声；不能直接断定是接口问题。

十二、边界：这套配方什么时候不成立

边界一：批大小。 本文所有比例都在 batch=1 下成立。批增大后权重读取被摊薄、算术强度上升，瓶颈从搬权重转向算矩阵，此时「搬得更满」的收益变窄，算力侧优化（内核效率、张量核心利用率、通信重叠）权重上升。把这三个倍数直接搬到大 batch 在线服务，会得出错误结论。

边界二：输出长度。 前两招降每步成本，第三招降步数，两者都与输出长度交互（第九节）。输出极短时每请求固定开销占比上升；输出极长时 KV 读取从零头长成正经账，KV 侧优化（前缀缓存、分层缓存、KV 量化）才轮到主角。

边界三：精度口径。 −0.08 个百分点是这一套评测下的报告值，本文没有逐题结果与检验方法，既不能说「无损」，也不能独立判断显著性。要上线到精度敏感的链路，必须自己跑并给区间。

边界四：容量预算。 124B 参数全按 4 bit 存约 62 GB、128 GB 减掉它是约 66 GB（本文自行推导）——这两个都是理想载荷与理想余额：不含量化元数据、不含未被量化的部分、不含系统与运行时占用、不含峰值缓冲，不等于实际可用内存。模型规格支持 262144 位置（max_position_embeddings [4]，官方博客说可扩到 1M [1]），但「在某种具体配置里能开多长、开多长还能稳跑」，属于部署验证，不是本文能下的结论。

边界六：算力结构差异。 本文把「字节」当成唯一主变量，前提是带宽受限。若换到算力/带宽比更低的加速器（例如高带宽 HBM 的数据中心卡）、或换到批更大的工作点，同样这套字节账算出来的「理论下限」会远低于实际可达，因为那时限制来自算力、通信或调度。用同一套式子跨硬件比较，必须先确认两边都还在带宽受限区。

边界七：模型结构差异。 本文的数值都绑定了这个模型的具体形状：moe_intermediate_size 768（窄）、512 专家选 8、35 层线性注意力 + 7 层 MLA。换成中间维更宽、专家更少、或全注意力的模型，三类收益的相对大小会变——窄形状是 Humming 那 9.3% 的前提，MLA 是把 KV 压到 7.9 KiB/token 的前提，缺任一条都要重算。

边界五：证据等级。 全部吞吐、延迟、精度数字都是厂商报告值，本文没有独立复测，也没有第三方在同一台机器上交叉验证过全部三档配置。官方自己也写明：合成负载的结果「不能确立其它负载上的增益」[1]。

十三、KV 读取是不是可以忽略：把 32K 与 256K 分别算出来

第四节把 KV 排除在估算之外，这个近似的有效期取决于上下文长度。先算这个模型每 token 的 KV 体积：42 层里 35 层是 KDA 线性注意力，维持与长度无关的递推状态；只有 7 层 MLA 需要缓存每个位置的压缩表示，MLA 把 KV 压到 kv_lora_rank + qk_rope_head_dim = 512 + 64 = 576 维 [4]。于是每 token 每层 576 个值，BF16 下 2 字节：

\text{KV}_{\text{tok}} \;=\; 7 \times 576 \times 2\ \text{B} \;=\; 8064\ \text{B} \;\approx\; 7.9\ \text{KiB}

一次解码步要算注意力，需要把当前上下文里所有位置的这份缓存读一遍（假设对全长做一次完整读取；分块实现改变常数不改变量级），所以这一步的流量是 $N_{\text{ctx}} \times 7.9\ \text{KiB}$ （本文自行推导）。把它与两项量并列，注意一个是缓存驻留容量、一个是单步流量，长度相同时数值接近但不是同一指标：

上下文长度	KV 驻留容量	一次解码步的 KV 读取（假设全长读取）	占第四节权重估算 3.36 GB 的比例
2K	约 16 MB	约 16 MB	0.5%
32K	约 258 MB	约 258 MB	7.7%
256K	约 2.06 GB	约 2.06 GB	61.5%

这张表说明两件事。第一，「batch=1 时 KV 读取相对权重读取很小」在短上下文成立、在长上下文不成立：32K 只占 7.7%，可忽略； 256K 能占六成，此时必须把 KV 当一等公民优化（稀疏读取、分层缓存、KV 量化都是这个方向）。第二，这也说明合成负载（32K 输入）与长上下文生产负载的结论不能互推——上下文一长，每步固定成本里 KV 那块在变大，而投机解码一次验证多个位置能把这部分读取摊在更多 token 上。

十四、六个常见误解

误解一：开了投机解码一定更快。 由 $S \approx a/c$ 可知，只有接受长度大于验证成本比才有净收益；本案例里 $a$ 从 3.90 掉到 2.68（换负载），步数因子就从 1.73 降到 1.19。接口没接对、 $a$ 掉到 1.00 时，会付两倍多的验证成本却只换回 1 个 token。

误解二：规格页的带宽就是能用的带宽。 本案例按估算读量反推的等效带宽只有标称的 44%（本文自行推导）。这个数把启动、同步、调度等开销都折进去了，它不是总线计数器读数，也不能直接当「硬件只能跑这么快」的结论。

误解三：−0.08 个百分点等于精度无损。 这是厂商在该评测下的报告值，本文没有逐题结果与检验方法。要上线到精度敏感的链路，得自己跑并给置信区间。

误解四：输出层量化只影响「词表投影」，与生成质量无关。 输出层决定 logits，logits 决定采样分布；把它从 BF16 压到 FP8 会引入量化噪声，官方报告的准确率变化是这一套评测下的结论，不能外推到其它任务。

误解五：上下文再长，权重搬运也永远占主导。 不对。这个模型在 256K 上下文时，一次解码步的 KV 读取估算约 2.06 GB，占权重估算的 61.5%（本文自行推导，见第十三节）；此时瓶颈结构变了，KV 侧优化的性价比高于继续压权重。

误解六：TPOT 降下来，单位 token 的电费就同比例下来。 官方报告没有给功耗口径 [1]，而 MTP 的验证步同时提高了算力与带宽占用；同一段墙上时间里，「更快」与「更省电」并不等价，尤其在桌面机上。

十五、这份报告没说的五件事，以及证据分层

读厂商报告最有效的姿势是先找「它没说的部分」。以下五处空白直接决定这套数字能不能搬到你的场景。

第一，验证成本比 2.26 的测量条件。 是在哪种输出层配置下测的、是否含草稿三步，都没写 [1]。这不是挑刺：由 $S \approx a/c$ 可知，在 $a=3.90$ 时， $c$ 从 2.56 变到 1.96 就能让步数因子在 1.52 与 1.99 之间摆动；第十节那两个因子的分配会随之改变——这就是本文把它标为未解、而不给「差额归因」的原因。

第二，没有按内核或按层的分时。 只知道总 TPOT 27.71 → 25.35 ms，不知道 2.36 ms 里多少来自形状贴合、多少来自启动次数减少。没有这个拆解，无法判断同类收益在别的模型上能拿多少：若你的模型 moe_intermediate_size 本来就宽，+9.3% 这档大概率缩水。

第三，没有功耗与能耗口径。 桌面机做本地推理，电费与散热是真实成本项；报告只给吞吐与延迟，任何「这台机器更省钱」的结论都不能从 TPOT 推出来。

第四，没有 batch > 1 与多流并发的数据。 三档全是 batch=1，而服务化真正要回答的是「并发 16 个用户时 P99 是多少」。把 batch=1 的加速比写进容量规划，是这类报告最常见的误用。

第五，量化配方没有逐项核对。 评测对应 Ling-3.0-flash-fp4 仓库 [8]，但量化器、校准集、分组大小、排除层清单，本文没有逐项核读。同名同一位宽、不同配方可以给出不同精度，复现时这是最大的不确定项。

顺带把证据分层写清，这是本文一直遵守的规则：

层级	内容	本文如何使用	能否直接用于决策
第一层：厂商报告值	TPOT、吞吐、接受长度、准确率、 $c$	直接转述并标 `[n]`	只能作为报告值，需自测确认
第二层：规格与配置	273 GB/s、128 GB、`config.json`、文档参数	作为推导输入	可以，但要记住 273 GB/s 是标称值
第三层：本文估算	3.36 GB/token、121 GB/s、44%、回退 51 ms	全部标注假设与不适用条件	只能作量级判断，不是实测

十六、想自己对照复现：入口、顺序与已知缺口

不需要照抄厂商的机器，但下面八步的顺序有讲究，因为每一步都在为下一步制造对照。

先确认容量。 4 bit 的 124B 权重理想载荷约 62 GB（本文自行推导），加上 KV、运行时与缓冲，128 GB 量级的统一内存是这一档的常见配置（实际能否稳定运行仍以部署验证为准）；容量不足时先降位宽，不要先叠加别的优化。
拿公开配方，而不是自己拼配置。 ling-cookbook 当前给的是 SGLang（MXFP4 基线、MXFP4 + Humming、INT4）与 vLLM（FP4、INT4）两类入口 [5]（本文只列举其中五条 SGLang / vLLM 配方）；本文没有固定到具体 commit，仓库仍在演进（README 另有 llama.cpp 等其它框架条目），版本范围见末节。
把基线跑一遍并记四个量： TPOT、TTFT、GSM8K 准确率、以及（此时为空的）接受长度。这四个量是全流程的对照系。
一次只开一项，顺序建议 Humming → FP8 输出层 → MTP。 每开一项重记 TPOT；任何一项让 TPOT 变长就停在那一步查配置，不要继续叠加。
把「配置检查」与「收益验收」分开做。 前者在启动时断言后端名、输出层路径、MTP 是否启用、草稿是否共享完整输出层模块；后者必须用同负载的 TPOT 与整轮成本验证（第十一节）。
用目标分布验收，而不是只用合成负载。 合成负载只能验证机制是否接通；官方自己在真实负载上做了全量 1319 题 [1]，可以作为参考形态。
长上下文单独记一档。 32K 以上 KV 读取从 0.5% 涨到 7% 以上（第十三节），与短上下文结论不能混用。
跨机器比较要加条件。 只比 tok/s 会把带宽差异当成优化差异；比「等效达成率 $U$ 」也只有在读量模型、模型版本、精度配方与负载一致时才成立，否则它比的是四件事的混合体。

十七、术语与符号表

记号 / 术语	含义	本案例取值
$P_{\text{act}}$	每 token 激活参数数	5.1×10^9
$b_w$	激活权重平均位宽（估算用）	4 bit（MXFP4，评测配置）
$V$ , $d$	词表大小、隐藏维度	157184、2560
$b_{lm}$	输出层权重位宽	BF16（基线）/ FP8（优化后）
$B_{\text{step}}$	一次普通解码步的估算读取字节数	约 3.36 GB（基线，含输出层，不含 KV）
$B_{\text{eff}}$	等效带宽 = 估算读量 ÷ 厂商报告 TPOT（非总线计数器实测）	约 121 GB/s
$U$	等效达成率 = 等效带宽 ÷ 标称带宽	约 44%
$I$	算术强度（FLOP/byte）	约 3.0
TPOT	每输出 token 耗时（解码阶段）	27.71 → 9.72 ms（合成）
TTFT	首 token 延迟，含 prefill 与排队	0.207 → 0.214 s
batch size	一次前向并行处理的位置/请求数，不等于并发用户数	1
MoE	混合专家：按 token 路由到少数专家子网	512 选 8 + 1 共享
MLA	多头潜在注意力，把 KV 压到低秩潜在空间	576 维/token/层
KDA	Kimi Delta Attention，线性注意力变体（本模型采用该机制）	35 层，状态与长度无关
LM head	输出层，把 hidden 投影到词表维	402.39 M 参数
MXFP4	4 bit 微缩放浮点，按小块共享缩放因子	MoE 权重格式
MTP	多 token 预测，一轮草稿多个 token 再验证	NEXTN 1 层
$a$	接受长度：每轮被接受并提交的 token 数（含额外 token）	3.90（合成）/ 2.68（GSM8K）
$c$	验证成本比：一轮「草稿 + 验证」相对一次普通解码步的时间比	约 2.26（厂商值，条件未公开）
GSM8K	数学应用题数据集（Cobbe 等，2021），测试集 1319 题	本案例的真实负载

十八、小结：回扣开头那句直觉

把三招放回「餐厅搬食材」的比喻：**Humming 是让搬运工走得更快（同样食材搬得更满）； FP8 输出层是把一份每桌必上、体积占近四分之一但常被忽略的配菜换成浓缩版（少搬）；MTP 是一次搬运端上多桌（摊薄）。 ** 三者机制不重叠，官方正是这么总结的：前两招降低每一步的成本，第三招减少步数 [1]。

可迁移的结论有四条。第一，先算字节账再谈优化：每 token 读多少 GB、除以机器带宽得到什么下限、实测差多少，这三个数一算就知道该往哪使劲。第二，把等效达成率当独立指标看，但要记住它是估算读量除以实测时间得来的，不是总线计数器读数。第三，多层优化必须有 per-feature 的配置断言 + 同负载收益验收，因为最贵的故障形态是静默回退——它不报错，只让你慢。第四，厂商的百分比永远要问「在什么负载、什么起点、什么口径上」：同一套优化，重复输出的合成负载 +185.1%，真实数学题 +42.5%，差 4 倍以上，而两者都是真的。

最后留一个自检问题：你能说出自己服务里「每 token 要搬多少 GB、机器带宽是多少、等效达成率是几成」这三个数吗？ 说不出来时，任何「要不要上投机解码」「要不要换量化」的决策都还停在猜的阶段；这三个数用不了半小时，却能省掉几周的盲目调优。

📋 来源与核验记录

以下链接均为本文写作当日（2026-10-30，北京时间）实际打开并核读：

[1] NVIDIA Technical Blog，《3 Ways to Boost MoE Inference on NVIDIA DGX Spark》，Yang Liu，2026-10-27。三档配置的 TPOT/吞吐、GSM8K 测试集 1319 题结果、接受长度 3.90 / 2.68、验证成本比约 2.26、512 选 8 专家、35 层 KDA + 7 层 MLA、moe_intermediate_size 768、词表 157184 × hidden 2560、--enable-fp32-lm-head 与 SGLANG_ENABLE_FP8_LM_HEAD=1 互斥、静默回退警告、输出长度分布、TTFT 0.207/0.214 s，均出自此文。https://developer.nvidia.com/blog/3-ways-to-boost-moe-inference-on-nvidia-dgx-spark/
[2] NVIDIA DGX Spark 产品页：GB10 Grace Blackwell 超级芯片、64/128 GB LPDDR5X 一致性统一内存、内存带宽 273 GB/s、支持 FP4 的第五代 Tensor Core 标称 1 petaFLOP。https://www.nvidia.com/en-us/products/workstations/dgx-spark/
[3] Hugging Face inclusionAI/Ling-3.0-flash 模型卡（bf16 母体权重与文档公开可下）。https://huggingface.co/inclusionAI/Ling-3.0-flash
[4] 该模型 config.json（本文逐项核读：BailingMoeV3ForCausalLM、hidden 2560、42 层、vocab 157184、512 专家 / top-8、moe_intermediate_size 768、num_nextn_predict_layers 1、max_position_embeddings 262144、kv_lora_rank 512、qk_rope_head_dim 64；文件内无 quantization_config）。https://huggingface.co/inclusionAI/Ling-3.0-flash/raw/main/config.json
[5] inclusionAI/ling-cookbook 仓库 README（本文核验时点：Ling-3.0-flash 在单台 DGX Spark 上给出 SGLang 的 MXFP4 / MXFP4 + Humming / INT4 与 vLLM 的 FP4 / INT4 配方；仓库仍在演进，本文未固定 commit）。https://github.com/inclusionAI/ling-cookbook
[6] SGLang 官方文档《Speculative Decoding》：MTP 通过投机解码启用，参数为 speculative_num_steps / speculative_eagle_topk / num_draft_tokens，并有 NEXTN 的块验证开关。https://docs.sglang.ai/advanced_features/speculative_decoding.html
[7] Cobbe 等，《Training Verifiers to Solve Math Word Problems》（GSM8K，2021，arXiv:2110.14168）：本文只用来说明该数据集的题型与测试集规模（1319 题），未使用其分数。https://arxiv.org/abs/2110.14168
[8] Hugging Face inclusionAI/Ling-3.0-flash-fp4（评测对应的量化产物入口；其量化器、校准集、分组大小与排除层清单本文未逐项核读）。https://huggingface.co/inclusionAI/Ling-3.0-flash-fp4

本文自行推导清单（假设与中间值全部列出，可与上面 8 条一手材料逐项复核）：

输出层参数量 $157184\times2560 = 402.39$ M；BF16 = 805 MB；FP8 = 402 MB；占基线估算读量 24.0% / 13.6%。
每 token 激活权重 5.1×10^9 × 4 bit ÷ 8 = 2.55 GB；加 BF16 输出层共 3.355 GB；换 FP8 后 2.952 GB（不含 KV、量化元数据、未被量化的混合精度部分与运行时缓冲）。
基线等效带宽 3.355 GB ÷ 27.71 ms = 121.1 GB/s，为标称 273 GB/s 的 44%；Humming 后 3.355 GB ÷ 25.35 ms = 132.4 GB/s。
输出层两段对照：反事实（从原始基线加这一招）0.402 GB ÷ 121.1 GB/s = 3.32 ms、按读量预测 24.38 ms；紧邻基准（Humming 档 132.3 GB/s）预测 22.31 ms，与报告值 22.76 ms 差约 −2.0%；实测增量 2.59 ms（25.35 → 22.76）。
双因子分解（相对原始基线）：合成路径每 token 等效字节 2.26 × 2.952 ÷ 3.90 = 1.711 GB（因子 1.96）× 等效带宽 176.0 ÷ 121.1 = 1.45 → 2.85（实测 102.88 ÷ 36.09 = 2.85）；GSM8K 路径 2.26 × 2.952 ÷ 2.68 = 2.489 GB（因子 1.35）× 等效带宽 134.1 ÷ 126.8 = 1.06 → 1.43（实测 53.89 ÷ 37.81 = 1.43）；其中 GSM8K 基线等效带宽 = 3.355 GB ÷ 26.45 ms = 126.8 GB/s。
算术强度 2 × 5.1×10^9 ÷ 3.355×10^9 = 3.04 FLOP/byte；里奇点 1×10^15 ÷ 273×10^9 = 3663 FLOP/byte。
每 token 激活 8/512 = 1.56% 专家；4 个 token 期望不同专家数 512 × [1 − (1 − 8/512)^4] = 31.3。
MTP 步数口径（第八节）：3.90/2.26 = 1.73 倍 → 对中间档预测 TPOT 13.19 ms（厂商报告值 9.72 ms），该差额不归因；若改用字节倍率口径， $c_B$ 需约 1.55 才对得上 9.72 ms。
假设性回退估计（ $a=1.00$ ）：2.26 × 22.76 ms ≈ 51 ms ≈ 20 tok/s，为基线 36.09 tok/s 的约 55%。
容量与 KV：124B 参数 @4 bit 理想载荷约 62 GB，128 GB 减去它约 66 GB（均为理想值，非实际可用内存）；7 层 MLA 每 token 每层 576 维 × 2 字节 = 1152 B，合计 7.88 KiB/token；2K / 32K / 256K 上下文分别约 16 MB（0.5%）/ 258 MB（7.7%）/ 2.06 GB（61.5%）。
关键百分比核对（正文出现的百分比逐一对应上面材料或本文推导）：+9.3%、+21.7%、+185.1%、10%、24%、96.89%、96.82%、−29.8%、+42.5%、−0.08 个百分点、−24.5%、−27%、−23%、−2.0%、100%、44%、55%、24.0%、13.6%、1.56%、7.7%、61.5%、0.5%、185%、42%，以及 TPOT 26.45 / 18.56 ms 与吞吐 37.81 / 53.89 tok/s。

未核实与未解项（本文不做推断）：

验证成本比 $c \approx 2.26$ 的测量条件（输出层配置、是否含草稿三步）未公开；因此第十节的两个残余（×1.36、×1.20）无法唯一归因，第十一节的回退数值是按该口径做的假设性估计。
逐内核 / 逐层分时缺失：Humming 的 +9.3% 里形状贴合与启动次数减少各占多少，无法判定。
功耗与能耗口径缺失：不能用 TPOT 推断单位 token 电费。
模型与配方版本范围未知：本文未固定 Ling-3.0-flash 的 revision、ling-cookbook 的 commit、SGLang 与 Humming 的版本，也未逐项核读 Ling-3.0-flash-fp4 的量化配方；「原来的 NEXTN 实现缺接口」对应的版本范围同样未知，不能据此判断当前版本是否仍受影响。
全部吞吐、延迟、准确率均为 NVIDIA 报告值转述，本文没有独立实测，也没有第三方对三档配置的全量交叉复测。