突破 DeepSeek-V4-Pro 服务极限：H20 上的多场景优化方法

1. 引言

DeepSeek-V4-Pro 是一个 1.6 万亿参数的混合专家（MoE）模型，同时发布了 FP8 和 FP4 权重。这一规模的模型天然受益于 NVIDIA Blackwell GPU 等加速器，它们提供更大的 HBM、更高的计算吞吐量以及原生 FP4 Tensor Core。然而，尽管 H20 GPU 不具备这些优势，它们仍被广泛部署。

硬件限制并不会放宽服务要求。长上下文预填充仍必须控制首 token 时间（TTFT）。交互式解码必须满足各服务层级的每输出 token 时间（TPOT）目标。持续流量必须在总吞吐量与 KV cache 容量之间取得平衡。短输入、长上下文、延迟敏感请求和高并发会以不同方式对系统施加压力；没有一种通用配置能同时很好地服务所有场景。

一个模型需要多种服务配置档案。 工作负载特征、服务级别目标（SLO）以及实测硬件行为，共同决定了部署拓扑与执行路径：

• 将服务配置档案与工作负载相匹配。 在此处评估的配置中，prefill 根据实测的上下文长度范围在 PP2 与 PP4 之间选择，而 decode 则使用针对不同延迟、吞吐量和 KV 容量目标优化的配置档案。
• 优化 prefill 路径。 我们优化了 Attention-CP8 → MoE-TP8 以及上下文并行通信，然后针对长上下文和短上下文工作负载所产生的真实路由形态进行调优。
• 优化解码路径。我们针对不同的解码 SLO 优化了 DSpark 投机解码路径，改进了执行、专家路由以及通信与计算的重叠。

推动延迟极限。在 batch size 为 1 时，单节点 H20-141GB 参考配置达到271 output tokens/s，相比之下383.7 tokens/s 是在 B300 上报告的。尽管存在显著的硬件差距，针对特定工作负载的系统优化将观测到的解码性能比缩小至1.42×。详细的基准测试设置以及基于日志的吞吐量提取方法见附录 B.3.

覆盖服务范围。该延迟结果仅代表系统的一个边缘场景。在更广泛的配置系列中，优化后的 prefill 达到每节点 8.45k 输入 tokens/s，并在43.7 秒内处理 1M-token 提示词。对于面向吞吐量的 decode，DP16-EP16 效率参考达到每节点 4.67k 输出 tokens/s，对应平均 TPOT 为27.4 ms。这些结果有意来自不同的配置，每个配置都针对上下文长度、延迟、吞吐量和容量约束的不同组合进行了选择和优化。

这项贡献是一套方法论，而非单一基准测试。 针对具体场景的服务方式，使每种工作负载都能在可用硬件上所评估的配置中，朝着更优的实测运行点靠拢。我们希望这里呈现的部署选择、优化方法和测量结果，能为在算力、内存、带宽或互连受限条件下服务前沿模型的团队提供实用参考。

2. 从硬件约束到服务配置

2.1 硬件约束与服务角色

图 1. 硬件差距：H20 对比 B300。

Blackwell 提供原始性能；H20 提供可部署的规模。 B300 提供原生 FP4 Tensor Core、高得多的 FP8 吞吐量，以及显著更大的 HBM。H20 无法匹敌其算力，但它仍可大规模获取，并提供高内存带宽和 900 GB/s 的 NVLink。本研究中的每个节点包含八块通过 NVLink 连接的 GPU。Prefill 不保留长期存在的每请求状态，因此其硬件选择主要受 TTFT、算力和通信效率支配。Decode 必须在整个生成过程中保留每个活跃请求的 KV cache，使 HBM 容量成为上下文长度和并发的直接限制。对于这里研究的部署，这促使我们将 H20-141GB 用于 decode，而将容量足以满足我们 prefill 工作负载的 H20-96GB 用于 prefill。

图 2. 按服务角色进行的硬件分配。

2.2 容量选择

服务容量最终来自共享的 HBM 预算：模型权重和每请求的 KV 状态争夺同一块内存。我们将 全 token 容量 定义为在分配模型权重和运行时缓冲区之后，每个 rank 能够容纳的全注意力 KV token 的最大数量。它是一个内存上限，而非可允许批大小的直接保证。

使用 Humming MXFP4AFP8 减少权重占用

首先减少权重占用。 Humming MXFP4AFP8 使用 MXFP4 专家权重和在线 FP8 激活，以减少 H20 GPU 上的权重占用和内存流量，因为 H20 GPU 缺乏原生 FP4 Tensor Core。SGLang 集成已在 sglang#23754 中提供。我们将在专门的后续文章中介绍 Humming/SGLang 集成。模型级准确率结果和公开参考测量数据见 附录 D.2。

使用 Online C128 扩展 KV 容量

给 KV cache 留出增长空间。 Offline C128 基线为每个压缩页保留逐索引状态。Online C128 则维护一个紧凑的聚合状态，将更多 HBM 释放给 KV-cache 池。它引入了额外的状态维护和推测验证工作，但我们在测试中未观察到 TPOT 退化。

综合容量增益

图 3. 使用 Humming MXFP4AFP8 与 Online C128 的容量扩展。

容量增益在权重和 KV 状态上叠加累积。通过缩减权重占用，Humming MXFP4AFP8 将全 token 容量扩展至 Baseline FP8 + Offline C128 配置的 1.71×（DP32-EP32）和 4.47×（PP2-TP8）。随后 Online C128 缩减了 C128 辅助状态占用，在 Humming 的基础上再提供 2.268× 的提升。两项技术结合后，容量提升至基线的 3.88×（DP32-EP32）和 10.14×（PP2-TP8）。附录 D.1 提供了完整数据。

2.3 场景特定服务配置

Prefill 配置

图 4. Prefill 配置：相同执行路径，不同流水线深度。

合适的流水线深度取决于有多少工作可供流水线化。PP2-CP8-TP8 和 PP4-CP8-TP8 共享相同的 Attention-CP8 → MoE-TP8 执行路径。在拓扑层面，它们的主要区别在于流水线深度：PP2 将模型分布在两个阶段上，而 PP4 使用四个阶段。

短上下文有利于降低流水线开销；长上下文则能暴露更多并行性。短输入产生的 chunk 更少，导致较深的流水线填充不足，使填充、排空以及跨阶段传输的成本更加突出。长上下文则提供足够的 chunk 让四个阶段保持忙碌；由于每个阶段的层数更少，额外的节点转化为更多的 prefill 并行性。在我们的部署中，这些特性促使我们对较短上下文采用 PP2-CP8-TP8，对长上下文工作负载采用 PP4-CP8-TP8。

低延迟 Decode 配置

图 5. 低延迟 Decode：TP8 参考配置与 PP2-TP8 服务配置。

低延迟始于最短的执行路径。单节点 TP8 和 PP2-TP8 共享相同的 Attention-TP8 → MoE-TP8 执行路径；区别在于模型是否跨节点分区。单节点 TP8 将所有层放在一个 H20-141GB 节点上，避免了跨阶段通信和同步。PP2-TP8 则将模型划分到两个流水线阶段。

最快的拓扑并不总是最实用的那一个。单节点 TP8 的执行路径更短，但模型权重和服务状态共享同一个节点的 HBM，留给 KV cache 的空间有限。它无法同时支持长上下文和更大的 batch size。PP2-TP8 需要付出额外的流水线开销，但将模型权重分散到两个节点上，从而释放出更多 HBM 用于 KV 状态。针对我们的延迟和容量目标，我们使用单节点 TP8 作为 batch-size-1 的延迟基准，并使用PP2-TP8 作为低延迟服务配置。

高吞吐解码配置

图 6. 高吞吐解码：DP16-EP16 参考配置与 DP32-EP32 容量配置。

高吞吐解码将数据并行与专家并行一同扩展。两种配置都使用 Attention-DP → MoE-EP 执行路径。DP16-EP16 是最小的部署单元；DP32-EP32 在同一拓扑内同时扩展 DP 和 EP。

横向扩展优先考虑请求容量，而非每 GPU 吞吐量。更大的 EP 组将专家权重分散到更多 GPU 上，从而释放 HBM 用于 KV cache，并接纳更多并发请求。与此同时，MoE 流量中留在每个节点内的比例变小，跨节点的比例变大，这可能会降低每 GPU 效率。在此处评估的配置中，我们使用 DP16-EP16 作为最小部署单元和效率基准，并使用 DP32-EP32 来扩展请求容量。

3. 预填充：平衡计算与通信

预填充性能是一个系统性问题。 专家不均衡、上下文并行通信以及生产路由形态共同决定了 TTFT；仅优化单个内核是不够的。

3.1 为什么选择 MoE-TP 而非 MoE-EP

图 7. 用 MoE-TP 替换 MoE-EP。

流量更少，耗时却可能更长。 MoE-EP 只交换被路由的 token，但真实的预填充流量呈现出显著的专家偏斜。拥有热门专家的 rank 会执行更多计算并成为掉队者；所有其他 rank 在 combine 步骤都要等待最慢的路径。更低的通信量并不会转化为更低的 TTFT。

先平衡计算，再最小化流量。 对于此处评估的 H20 预填充工作负载，PP2 和 PP4 都使用 MoE-TP。全序列 all-gather 和 reduce-scatter 引入了更多通信，但流量仍运行在高带宽 NVLink 上，且开销稳定、可预测。所有 TP rank 都对相同的被路由 token 执行张量并行计算，从而防止专家偏斜演变为 rank 级的长尾。对于这一工作负载，可预测的通信比不可预测的不均衡更廉价。该实现已在 sglang#24947 中提供。

3.2 加速并融合预填充集合通信

图 8. 对称内存集合通信与 Prefill 融合。

构建可复用的集合通信快速路径。 MoE-TP 将不可预测的专家负载不均衡替换为可预测的集合通信流量，使通信效率成为下一个瓶颈。我们让对称内存在 TP 和 CP 之间可复用，使 AllReduce、AllGather 和 ReduceScatter 能够共享注册缓冲区快速路径以及适用的 Hopper 加速。相关的上游工作涵盖 内存池所有权、通信器注册、MoE-TP 集合通信缓冲区，以及 CP Attention 和 KV-cache 缓冲区路径。

然后缩短 Prefill 关键路径。 仅靠更快的集合通信并不能消除通信与计算之间的边界。对于 32K 单 chunk 场景，我们构建了一条融合路径，将 copy-engine 驱动的 AllGather 与融合 FP8 量化和共享专家 GEMM 重叠执行，然后在第二个 Triton kernel 中合并 TopK 归约、共享专家加法和 ReduceScatter。这将七个算子重组为三个执行组，并在匹配的 PP4 A/B 测试中将 TTFT 降低约 3.5%。

3.3 针对真实路由形态调优 Humming

图 9. 针对真实路由形态调优 Humming。

通用调优会错过真正重要的形状。 Prefill 路由会在 384 个专家之间不均匀地分配 token，因此有效的 M 维度会聚集成一小组离散值。W13 和 W2 也作用于不同的形状，因此单一的通用启发式无法同时优化这两条路径。

从生产路由中进行调优。 我们从真实的路由直方图中提取高频形状，为 W13 和 W2 构建各自独立的精确形状配置，并在 kernel、流水线阶段以及匹配的 A/B 层面进行验证。优化目标不是合成的 M 范围，而是 我们实际服务的路由分布。在 32K 下进行的匹配 PP4 A/B 测试中，选定的 MoE kernel 延迟下降约 21%，转化为 11.35% 的端到端 TTFT 降低。

4. Decode：优化推测与 MoE 执行

在我们的实现中，Decode 优化是针对具体 profile 的。 PP2-TP8 需要跨推测流水线阶段进行协调，而 DP32-EP32 则专注于在高并发下优化 refinement 步骤和专家路由。Humming 融合与重叠改善了这些服务拓扑之下共享的 MoE 热路径。

4.1 低延迟 PP2-TP8：将 DSpark 扩展到跨流水线阶段

图 10. 跨 PP2 阶段协调 DSpark。

流水线并行将投机循环拆分。在 PP2-TP8 中，目标模型的执行跨越两个流水线阶段，而 DSpark 草稿模型仅位于最后一个阶段。阶段 0 将目标隐藏状态发送至阶段 1，由阶段 1 执行验证、接受 token，并为下一轮生成候选。

让两个阶段如同一体般推进。每一轮投机都会跨越流水线边界。我们在同一套执行协议下协调两个阶段及所需的中间传输，防止各阶段进入不同的轮次，同时避免冗余同步。针对 PP 的 DSpark 集成正在 sglang#32281 中向上游合并。

4.2 高吞吐 DP32-EP32：消除高并发瓶颈

图 11. DP32-EP32 瓶颈消除。

本小节中的匹配 A/B 结果使用 DP32-EP32、4K 配置，每个 DP rank 32 个并发请求。

为精炼选择正确的执行形态。精炼步骤对 DSpark 的候选集应用全词表投影以重新打分。在高并发下，逐行点积归约会对每个活跃行反复读取词表权重，从而在每个解码步中形成持续的长尾。我们将活跃行合并为一次转置 GEMM，减少冗余内存访问并缩短精炼路径。单 GPU 吞吐提升 22.8%。

将专家从实测路由中放置。 DSpark 流量同样表现出显著的专家偏斜。我们记录代表性请求的路由亲和度，并据此配置专家并行负载均衡（EPLB）和冗余专家，防止少数热点专家反复延长关键路径。每 GPU 吞吐量提升 13.5%。

4.3 Humming 解码热路径：融合与重叠

图 12. Humming 解码热路径优化。

这些优化位于服务拓扑之下，可被基于 Humming 的解码配置复用。下方匹配结果使用 DP32-EP32、4K，每个 DP rank 32 个并发请求。

移除额外的量化处理。 我们将 SwiGLU 激活与量化融合，使融合后的 kernel 直接产出 W2 所需的数据和 scale。这消除了对中间缓冲区的重复访问，并移除了独立的量化处理，使 W2 能更早启动。在匹配的 DSpark A/B 测试中，每 GPU 吞吐量提升 44.0%。

与 W2 重叠通信。我们采用了单批次重叠（Single-Batch Overlap，SBO）机制，来自我们之前的工作（sglang#9660），将其融入Humming-Aware SBO。逐 tile 信号让 DeepEP 能够在某个 W2 输出 tile 完成的瞬间就开始对应的 combine 发送，而无需等待整个 GEMM 完成。在此前同一工作点上进行的一次匹配的非投机 A/B 测试中，SBO 相对于 FP8 传输层级恢复了4.12%吞吐量。

5. 评估：系统增益与配置权衡

5.1 预填充：累积增益与上下文长度的权衡

图 13. 累计预填充吞吐量增益。

PP2 增强了短上下文场景的表现。 PP2 在全部九种输入长度上均有提升，几何平均吞吐量增益为 36.5%，峰值总输入吞吐量达到 16,900 tokens/s。其更浅的流水线减少了短请求的填充与排空开销，使 PP2 能够以更少的资源维持更低的 TTFT。

PP4 将收益延续到长上下文场景。 PP4 在相同的九个测试点上实现了 31.8% 的几何平均吞吐量增益。随着上下文长度增长，更深的流水线有足够的工作量来摊薄其固定开销：总输入吞吐量在 512K 时达到 25,860 tokens/s，在 1M 时仍保持 23,970 tokens/s。

图 14. PP2 与 PP4 之间的 TTFT 权衡。

上下文长度改变了 PP2/PP4 的权衡关系。 相对于 PP4，PP2 在 4K 时将 TTFT 降低了 16.7%，在 32K 时降低了 19.5%。两种配置在 8K、16K 和 64K 时的差距保持在 2% 以内。PP4 从 128K 开始建立起决定性优势，在 128K、256K、512K 和 1M 时分别将 TTFT 相对于 PP2 降低了 26.2%、33.3%、42.1% 和 44.8%。因此，我们将路由边界视为一种基于实测上下文长度范围推导出的运营策略，而非通用的交叉点。

附录 A.1–A.2 提供了完整的 TTFT 和总输入吞吐量结果。

5.2 低延迟解码：性能与容量的权衡

图 15. 优化后的 DSpark 带来的峰值 TPOT 增益。

优化后的 DSpark 重置了延迟基线。 在图 15 所示的四种输入长度下，优化后的 DSpark 在 batch size 为 1 时将峰值 TPOT 降低了 74.8%–78.0%。在每组测量所共有的最大 batch size 下，降幅仍保持在 52.2%–60.0%。这一增益从 8K 一直保持到 1M，而非仅限于短上下文或单请求执行场景。

图 16. Batch-Size-1 解码吞吐量：H20-141GB 与 B300 参考对比。

实际观测到的服务性能远比仅凭峰值算力比值所暗示的要接近得多。 在图 16 所示的四种输入长度下，PP2-TP8 上优化后的 DSpark 在 batch size 为 1 时达到 150–174 tokens/s。单节点 TP8 参考达到 183–271 tokens/s。对于实际执行路径所使用的精度，B300 的峰值 Tensor Core 算力约为 H20-141GB 的 45.6×（B300 FP4 对比 H20 FP8），内存带宽为其 1.67×。然而观测到的最高生成速率分别为 383.7 tokens/s 在 B300 上和 271 tokens/s 在 H20-141GB 上——比值仅为 1.42×。即便面对如此强大得多的硬件参考，针对特定工作负载的优化仍使 H20-141GB 参考在实际观测的服务性能上大幅拉近了差距。

就我们的生产目标而言，容量上 PP2-TP8 更具优势。单节点 TP8 速度更快，但在 1M 上下文下，其 KV-cache 容量仅够支持 batch size 1。它无法接纳更大的 batch 或更多并发请求。通过将模型权重分布到两个流水线阶段，PP2-TP8 在 1M、512K 和 256K 下分别支持 batch size 4、8 和 16。在 Online C128 下，其全 token 容量达到 11.04M tokens/rank。对于与我们相似的上下文长度和并发目标，我们建议保留单节点 TP8 作为延迟基准，并使用 PP2-TP8 作为低延迟服务配置。附录 B 和附录 D.1 提供了完整的性能和容量数据。

5.3 高吞吐解码：前沿收益与配置权衡

图 17. 吞吐量–交互性帕累托前沿。

图 17 展示了吞吐量–交互性前沿如何随系统演进。横轴是交互性，单位为 tokens/s/user，纵轴是吞吐量，单位为 tokens/s/GPU。在这些 DP/EP 配置中，每个 DP rank 映射到一个 GPU；交互性等于每 GPU 吞吐量除以每个 DP rank 的并发请求数。越靠右上方的点，用户可见的生成速度与 GPU 效率的组合越好。这四条曲线代表系统的累积演进，而非第 4 节中任何单项优化的孤立收益。

MTP 表示多 token 预测；(3, 1, 4) 配置使用三个投机步骤、top-k 1 和四个 draft token。

系统优化推动了整个前沿的扩展。在 4K 上下文、每个 DP rank 32 个并发请求的条件下，每 GPU 吞吐量从 319.92 tokens/s/GPU 提升至 703.15 tokens/s/GPU，增幅达 2.20×。在 1M 上下文、每个 DP rank 一个请求的条件下，每 GPU 吞吐量从 27.05 tokens/s/GPU 提升至 66.82 tokens/s/GPU。前三个系统里程碑在 1M 上下文下每个 DP rank 只能处理一个请求；最终系统支持四个请求，并达到 177.48 tokens/s/GPU。运行范围的扩展既来自更快的执行速度，也来自更大的容量。

图 18. 每 GPU 吞吐量：DP16-EP16 对比 DP32-EP32。

更小的部署单元在选定的高并发运行点上保持了效率。在我们此前于 H20 上部署 DeepSeek-V3/R1 的工作中，我们发现更小的 EP 部署单元可以将更大比例的 MoE 流量保留在每个节点内。DeepSeek-V4-Pro 在图 18 所绘制的运行点上展现了同样的优势：在每个 DP rank 16 和 32 个并发请求时，DP16-EP16 的每 GPU 吞吐量比 DP32-EP32 高出约 3.6%–20%。完整扫描并非在每个并发级别上都单调，因此我们将 DP16-EP16 作为效率参考，而非 DP32-EP32 的通用替代方案。

图 19. 每个 DP rank 的长上下文请求容量。

容量会改变首选的高吞吐配置。DP16-EP16 的每 GPU 效率更高，但 DP32-EP32 将专家权重分散到更多 rank 上，并为 KV cache 释放出额外的 HBM。在 256K、512K 和 1M 下，每个 DP rank 的最大并发请求数分别从 8、4 和 2 提升到 16、8 和 4——始终是 2× 的扩展。对于长上下文并发目标与我们相似的部署，这一额外容量使得 DP32-EP32 成为面向容量的高吞吐配置，而 DP16-EP16 仍可作为效率参考。附录 C 和附录 D.1 提供了完整数据。

6. 结论

一个模型并不需要一种妥协配置。我们为 H20 上的 DeepSeek-V4-Pro 构建了一套针对特定场景的 serving 栈。Prefill 根据上下文长度在 PP2 和 PP4 之间切换。Decode 使用 PP2-TP8 实现低延迟，使用 DP32-EP32 实现高吞吐。通过协同设计容量、部署拓扑和执行路径，尽管算力有限且没有原生 FP4 Tensor Core，H20 仍能支撑 1M token 上下文并满足多种 serving SLO。

可迁移的成果是一套场景驱动的方法论。 服务配置不应仅凭硬件规格或孤立的基准测试来选择。我们建议从工作负载、SLO、上下文长度和并发量出发，然后通过性能剖析来识别瓶颈资源，并将其转化为具体的拓扑结构和执行路径决策。我们希望这套方法论能帮助 AI 基础设施团队在多样化的资源约束下——无论瓶颈是算力、内存容量、内存带宽还是互连——构建实用的前沿模型服务系统，并与更广泛的开源生态分享这些经验。

致谢

我们感谢 SGLang 团队与社区 在 SGLang 框架上的杰出工作。我们也感谢以下团队和合作者的支持与贡献：

• 蚂蚁集团 SCT 团队： Yongfei Xu、Qianyu Zhang、Zekai Gu、ZhiLin Huang、Fakang Wang、Jianhao Fu、Zhuoxuan Du、Xia Zhan、Chun Huang、Qi Liu、Xi Chen、Yuhan Mao、Peipeng Cheng、Hanlin Gao、Jinghua Yao
• 蚂蚁集团 Venus 团队： Jinzhen Lin
• SGLang 社区： Peng Zhang

附录 A. Prefill 结果

A.1 Humming PP2 Prefill：基线配置与最终配置对比

A.2 Humming PP4 预填充：基线 vs. 最终性能剖析

附录 B. 低延迟解码结果

B.1 不同输入长度与批大小下的峰值 TPOT

B.1.1 无投机采样 PP2-TP8

B.1.2 优化后的 DSpark PP2-TP8

B.2 批大小为 1 时的输出吞吐量

B.3 基准测试设置

硬件：一个 8× H20-141GB 解码节点。

解码服务器

--tp-size 8 \
--mem-fraction-static 0.91 \
--max-running-requests 1 \
--cuda-graph-max-bs 1 \
--cuda-graph-bs 1 \
--moe-runner-backend humming \
--moe-a2a-backend none \
--speculative-algorithm DSPARK \
--speculative-num-draft-tokens 7 \
--speculative-dspark-block-size 7 \
--speculative-moe-runner-backend triton \
--speculative-moe-a2a-backend none

客户端基准测试

python3 -m sglang.bench_serving \
  --backend sglang-oai-chat \
  --host 127.0.0.1 \
  --port 8000 \
  --model <MODEL_PATH> \
  --dataset-name random \
  --dataset-path <DATASET_PATH> \
  --random-input-len 262144 \
  --random-output-len 4096 \
  --random-range-ratio 1.0 \
  --num-prompts 10 \
  --max-concurrency 1 \
  --warmup-requests 0 \
  --seed 1

输出吞吐量从服务器 TP0 的 Decode batch 日志行中提取；我们丢弃最高和最低的 20% 样本，对剩余样本取平均值。B300 的数值遵循所链接来源中报告的设置。

附录 C. 高吞吐解码结果

C.1 DP32-EP32 搭配 FP8 + MTP（3, 1, 4）

C.2 DP32-EP32 搭配 FP8 + 优化版 MTP（3, 1, 4）

C.3 DP32-EP32 搭配 FP8 + DSpark

C.4 DP32-EP32，采用 Humming MXFP4AFP8 + Online C128 + DSpark

C.5 DP16-EP16 搭配 Humming MXFP4AFP8 + Online C128 + DSpark

附录 D. 容量结果

D.1 解码容量扩展

D.2 Humming 精度验证

我们在 GSM8K1000 上评估了 DP16-EP16 Humming MXFP4AFP8 + Online C128 + DSpark 配置。该配置达到了 95.5% 的精确匹配准确率，其中有一个无效响应、零系统错误，通过了我们 95.0% 的验收阈值。

作为公开参考，上游 SGLang Humming 集成 在 DeepSeek-V4-Flash 的 200 例 GSM8K 评估中报告了以下结果：

在这一公开对比中，Humming MXFP4AFP8 未见明显的精度下降。由于它使用的是 DeepSeek-V4-Flash 而非 DeepSeek-V4-Pro，我们将其视为外部参考，而非针对我们服务配置的匹配精度损失测量。