DeepSeek V4 Flash 基准与架构核验

DeepSeek-V4-Flash-0731 现已成为 V4 Flash 的正式版本，取代此前的预览版。Model card 显示，在列出的全部九项 Agent 基准测试中，Flash-0731 均优于 V4-Pro（Preview）——“尽管其激活参数量要小得多”。这是一个相当有分量的说法，因此我从两个方面进行了核查：一是表格中的数值计算，二是 config.json 中的架构配置。

逐行核验：9/9

与 V4-Pro（Preview）相比，Flash-0731 在 9 项测试中全部获胜；在 GLM-5.2 有成绩的 8 个项目中也全部胜出；但在与 Opus-4.8 的 9 项对比中全部落败——其中差距最小的是 Agents' Last Exam（25.2 对 25.7）和 AutomationBench（25.1 对 27.2）。“整体上具有竞争力”这个表述是准确的：很接近，但并未领先。

Model card 本身也注明了若干限制：所有数据均来自 DeepSeek 自己的评测，采用 DeepSeek Harness minimal mode，并将 reasoning effort 设为最大值；两个 DSBench 数据集还以 † 标记，表示它们是 DeepSeek 的内部测试集。这些结果均未得到独立复现。

config.json 透露了什么

根据公开配置，该模型的 model_type 为 deepseek_v4，共有 43 层，hidden_size 为 4096，包含 64 个 attention head 和 1 个 KV head，词表大小为 129,280，max_position_embeddings 为 1,048,576——也就是 2^20。因此，论文标题中的“百万 token 上下文”是字面意义上的百万级。

其 MoE 架构在每层包含 256 个 routed expert 和 1 个 shared expert；每个 token 会激活 6 个 routed expert，而 expert 的 intermediate size 仅为 2048。Dense 权重使用 FP8（E4M3，动态 activation）；expert_dtype 则是 fp4——expert 在设计上就是以 4 bit 形式发布的。

如何解释 284B 与 304B

一个 expert 的参数量为：up（4096×2048）+ gate（4096×2048）+ down（2048×4096）= 25,165,824 个参数。43 层 × 256 个 expert，共计 11,008 个 routed expert，仅这一部分就约有 277.0B 参数。再加上 shared expert、dense attention，以及未共享的 embedding 和 head，总参数量约为 284B——与 unsloth 给出的 284B 数据一致。

Model card 所说的“safetensors 中为 304B”，还包含 checkpoint 内置的 DSpark speculative decoding 模块（以 BF16 存储时为 11.3 GB），以及量化 scale tensor。两者只是统计口径不同，并不矛盾。

每个 token 激活的参数量为：每层 7 个 expert（6 个 routed expert + 1 个 shared expert）× 43 层，约为 7.6B；再加上 dense attention 和 embedding，总计约为 10B——大约相当于整个模型的 3.5%。因此，“激活参数量要小得多”这一说法与其架构配置一致。

工程层面的新消息：Speculation 已内置于 Checkpoint

DSpark 直接包含在主 checkpoint 中：支持 7 个 speculative token，采用 greedy draft sampling，无须单独部署 draft model。

vLLM：--speculative-config '{"method":"dspark","num_speculative_tokens":7}'；SGLang：--speculative-algorithm DSPARK；llama.cpp 用户则可以将其作为模块添加（Q8_0，10.9 GB）。

此次发布还新增了三级 reasoning_effort（low、high、max；在 high 和 max 下最多可输出 384K token），并用包含 Python helper 的 encoding/ 目录取代了 Jinja chat template——直接使用 transformers 的团队需要进行迁移。

本地部署：如实评估资源需求

unsloth 提供的 GGUF 中，UD-Q4_K_XL 为 155 GB，UD-Q8_K_XL 为 162 GB——根据 unsloth 的说明，所谓“无损”的 Q8 仅比 Q4 大 7 GB。

Ollama：ollama run hf.co/unsloth/DeepSeek-V4-Flash-0731-GGUF:UD-Q4_K_XL。

llama.cpp：llama serve -hf unsloth/DeepSeek-V4-Flash-0731-GGUF:UD-Q4_K_XL。

一个 155 GB 的 Q4 文件意味着你需要配备大容量内存的工作站或多 GPU 服务器；对大多数产品团队而言，托管的 flash tier 才是更经济的选择。

如今，flash tier 的经济性已经有厂商自己的基准测试作为支撑——但请记住，这些数据仍然来自厂商自身。

FP8 dense + FP4 expert + checkpoint 内置 speculation，是一套值得借鉴的部署方案，尤其适合对延迟和成本敏感的 Agent 工作负载。

1M token 的上下文，加上 384K token 的输出预算，改变了单次 Agent 调用所能容纳的任务规模。

Model card：https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731（MIT）· config.json：https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731/resolve/main/config.json · GGUF：https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF · 论文：https://arxiv.org/abs/2606.19348

未测试、未运行——本文没有执行 inference，也没有复现 benchmark。基准测试数据来自厂商；数值计算和配置解读由我完成。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。