DeepSeek V4 深度解析:架构与性能

摘要:2026 年 8 月初,DeepSeek-V4-Flash-0731 官方权重与 unsloth GGUF 量化版在 Hugging Face 合计下载突破 125 万,官方仓库单仓破百万。本文基于技术报告与官方模型卡,拆解 V4 系列 284B/13B 的 MoE 架构、CSAHCA 混合注意力、FP4FP8 混合精度与 DSpark 投机解码,并给出 GGUF 量化选型与 llama.cpp/vLLM/SGLang 的部署要点。一、事件背景:十天破百万下载的 Flash 快照2026 年 8 月 1 日,DeepSeek 在 Hugging Face 发布DeepSeek-V4-Flash-0731,这是 V4-Flash 的正式版本,取代此前的 preview 快照,官方口径是agentic 能力大幅增强。截至 8 月 12 日,官方仓库下载已达1,048,685 次、likes 3,118;unsloth 的 GGUF 量化仓库下载207,990 次,两者合计约125.7 万——从 8 月 9 日的 96 万到突破百万,只用了 3 天。对一个 284B 参数级别的模型来说,这个数字说明社区已经把本地跑 V4当成一件现实可行的事,GGUF 版本需求旺盛正是信号。V4 系列的技术报告(arXiv:2606.19348)给出两个成员:V4-Pro 为 1.6T 总参数 / 49B 激活,V4-Flash 为284B 总参数 / 13B 激活,两者都支持 100 万 token 上下文。Flash 档的定位很明确——用远小于 Pro 的激活参数,在长上下文与 Agent 任务上追平乃至超过上一代旗舰:官方评测表里,0731 快照在多数 Agent 基准上超过了 V4-Pro(Preview),只用了约四分之一的激活参数。二、架构解析:稀疏、压缩与混合精度从 config.json 看,V4-Flash 是一个 43 层、hidden size 4096 的 MoE:256 个路由专家 1 个共享专家,每 token 激活 6 个;按官方口径,总参数 284B、激活参数 13B,激活占比约 4.6%。词表 129,280,注意力头 64 个、head_dim 512,key-value 仅 1 头——典型的宽注意力、窄 KV设计,专门为长上下文服务。三个架构升级值得展开:CSA HCA 混合注意力。V4 用 Compressed Sparse Attention(CSA)与 Heavily Compressed Attention(HCA)替代了 V3 系列的 MLA 路线。CSA 负责对长上下文做稀疏压缩,只保留值得看的 token;HCA 把更远的历史压进极小的表征,避免远端信息直接蒸发。技术报告的核心数字:在 1M token 上下文下,V4-Pro 的单 token 推理 FLOPs 只有 V3.2 的27%,KV cache 只有10%——长上下文从能跑变成便宜地跑。这也是 V4 敢把上下文拉到 1M 的底气:配置里 max_position_embeddings 正是 1,048,576,配合 YaRN 缩放(factor 16)与滑动窗口(128)实现。mHC 超连接。Manifold-Constrained Hyper-Connections(流形约束超连接)改进传统残差连接,让信息在 43 层之间传递更稳。这是 V4 敢把稀疏度做高——每 token 只路由 6/256 个专家——的关键工程配套:MoE 越稀疏,路由与残差结构的稳定性越重要。FP4 专家 FP8 其余 DSpark 投机解码。官方权重中,MoE 专家以 FP4 存储,注意力/归一化/路由保持 FP8,这是从预训练起就按此混合精度设计,而非事后量化。0731 快照自带 DSpark 投机解码头:从 config 看它是一个Markov 头(dspark_markov_rank 256、block size 5、挂在第 40-42 层),DeepSeek 官方称其优于传统 MTP(多 token 预测);unsloth 文档给出实测参考:同一 B200 上解码速度约从 60 tokens/s 提升到 120 tokens/s,接近 2 倍。llama.cpp 社区在 PR #25784(2026-08-02 合并)中同时实现了 MTP 与 DSpark,并特别提示 0731 新权重只带 DSpark 头、不带 MTP 头,使用老 MTP 流程会失效。NVIDIA 还提供了 NVFP4 变体(注意力等保持 FP8),面向 Blackwell 的 FP4 索引缓存优化,但该变体不支持 deep_gemm_mega_moe 的 FP8 专属内核,生产选型时需要在两种 MoE 后端之间权衡。另外两个细节:配置里的compress_ratios数组(每层 4 或 128)对应 CSA/HCA 的逐层压缩率;num_nextn_predict_layers: 1表明模型保留了 nextn 预测层。训练侧,技术报告显示 V4 系列在 32T token 上预训练,后训练采用两阶段管线——先做领域专属专家培养,再做基于 on-policy 蒸馏的统一整合。这与总参数大、激活参数小的 MoE 设计一脉相承:先让各领域专家各司其职,再用蒸馏把能力收拢,是 Flash 档能以 13B 激活对标 49B 激活 Pro 的后训练基础。三、性能画像:Agent 任务与长上下文官方评测表中,0731 快照相对 preview 的提升集中在 Agent 任务,完整对比如下(官方自测,harness 口径为 DeepSeek Harness 的最小模式 max 推理档):基准V4-Flash-0731V4-Flash PreviewV4-Pro PreviewGLM-5.2Opus-4.8Terminal Bench 2.182.761.872.181.085.0NL2Repo54.239.438.548.969.7Cybergym76.738.752.7-83.1DeepSWE54.47.312.846.258.0Toolathlon-Verified70.349.755.959.976.2Agents’ Last Exam25.215.816.523.825.7AutomationBench Public25.110.812.812.927.2DSBench-FullStack †68.737.041.861.871.6DSBench-Hard †59.625.831.154.571.7几个读表要点:其一,0731 快照在所有公开 Agent 基准上全面反超 V4-Pro(Preview),而后者的激活参数是它的近 4 倍,这是小激活 强后训练路线的直接证据;其二,DeepSWE 从 7.3 跳到 54.4,是提升幅度最大的单项,说明正式版把长程软件工程能力补上了;其三,与闭源第一梯队的差距仍在,Terminal Bench 2.1 上距 Opus-4.8 的 85.0 还差 2.3 分。需要提醒:官方数字用自家尚未发布的 DeepSeek Harness 评测,与各家 harness 存在口径差异,横向对比仅供参考(† 为内部测试集)。在同档对比上,社区主要拿 Flash 与 Kimi K3、Qwen 3.8 系列比较,但目前缺少同一 harness 下的三方 benchmark,以下数字只能作为参照系:Kimi K3 是 2.78T 总参数 / 104B 激活(激活率约 1.8%),Qwen3.8-Max 在 Artificial Analysis 的 Agentic Index 上以 55.4 分登顶(K3 为 50.1)。三者架构取向不同——K3 走超大总量 极稀疏,V4-Flash 走小激活 强压缩注意力,Qwen3.8 走均衡稠密化 Agent 对齐,直接比分数意义有限;比每 token 激活成本 × 长上下文内存更贴近实际部署决策。V4-Flash 在这条轴上的优势是 1M 上下文下 KV cache 只有 V3.2 的 10%,意味着同样显存能支撑更长的 Agent 轨迹。四、本地部署:GGUF 量化选型与推理框架unsloth 提供了从 UD-IQ1_M 到 UD-Q8_K_XL 的完整量化梯度,并给出各档位所需的总内存(RAMVRAM,含 KV cache 与上下文分配)参考表:档位文件大小所需总内存(标准)开 DSpark 后UD-IQ1_M(1-bit)—92 GB102 GBUD-IQ2_M(2-bit)—102 GB112 GBUD-IQ3_XXS(3-bit)103 GB110–135 GB120–145 GBUD-Q4_K_XL(4-bit,近无损)约 155 GB162 GB172 GBUD-Q8_K_XL(8-bit,无损)162 GB169 GB179 GB几个关键点:Q8_K_XL 是唯一无损档位,与 BF16 位级一致;UD-Q4_K_XL 只把非专家张量(约占 4%)降到 Q8_0,专家保持位级一致,所以 4-bit 档与 Q8 在质量和体积上几乎没差别(约 155GB vs 162GB);预算敏感用户推荐UD-IQ3_XXS(103GB),110GB RAM 的机器即可跑;内存下限参考:1-bit 92GB / 2-bit 102GB / 3-bit 110–135GB / 4-bit 162GB / Q8 169GB,开 DSpark 再预留约 10GB。推理框架方面,llama.cpp 原生支持 deepseek4 架构与专用 KV cache 实现,llama-cli/llama-server可直接加载 GGUF。生产路径推荐 vLLM 或 SGLang:vLLM 在 2026-08-11 发布的 v0.27.1 中新增了 quantized DSpark Markov heads 支持(官方 README 的 vLLM 命令也带上了--attention-config {use_fp4_indexer_cache: true});SGLang 用--speculative-algorithm DSPARK,不需要单独草稿模型——DSpark 头就在同一个 checkpoint 里,比传统投机解码省一次权重加载:# vLLM(单节点 4×GB300,开启 DSpark 投机解码)vllm serve deepseek-ai/DeepSeek-V4-Flash-0731\--trust-remote-code --kv-cache-dtype fp8 --block-size256\--data-parallel-size4--enable-expert-parallel\--moe-backend deep_gemm_mega_moe\--attention-config{use_fp4_indexer_cache: true}\--speculative-config{method:dspark,num_speculative_tokens:7,draft_sample_method:greedy}# llama.cpp unsloth GGUF(3-bit 档,110GB RAM 预算)llama-cli\-hfunsloth/DeepSeek-V4-Flash-0731-GGUF:UD-IQ3_XXS\--temp1.0--chat-template-kwargs{reasoning_effort:max}# SGLang(4×GPU,DSpark 投机解码,权重自带草稿头)sglang serve\--trust-remote-code\--model-path deepseek-ai/DeepSeek-V4-Flash-0731\--tp4--moe-runner-backend flashinfer_mxfp4\--speculative-algorithm DSPARK\--mem-fraction-static0.90--chunked-prefill-size4096两个易踩的坑:其一,0731 权重不附带 Jinja 对话模板,官方提供encoding/目录的 Python 脚本做 OpenAI 兼容消息编码,llama.cpp 侧已内置 V4-Flash-0731 模板,但自建服务时别漏掉;其二,reasoning_effort支持 low/high/max 三档,官方建议 high/max 档把最大输出长度留到 384K token,否则长推理会被截断。模型与权重均为 MIT 协议,商用门槛低。五、总结DeepSeek-V4-Flash-0731 代表了 2026 年开源模型的一条明确路线:用强压缩注意力把长上下文成本打下来,用 FP4 混合精度把部署门槛降下来,用 DSpark 投机解码把解码速度提上去。对开发者而言,284B/13B 的激活规模意味着单机(哪怕 110GB 内存跑 3-bit)就有机会承载 1M 上下文的 Agent 任务——这正是百万下载背后的真实需求。选型建议:要无损质量选 UD-Q8_K_XL,要性价比选 UD-IQ3_XXS,生产服务优先 vLLM/SGLang 的 DSpark 路线。参考链接DeepSeek-V4 技术报告:https://arxiv.org/abs/2606.19348官方模型卡:https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731unsloth GGUF:https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUFunsloth 部署指南:https://unsloth.ai/docs/models/deepseek-v4vLLM recipe:https://recipes.vllm.ai/deepseek-ai/DeepSeek-V4-FlashSGLang cookbook:https://docs.sglang.io/cookbook/autoregressive/DeepSeek/DeepSeek-V4llama.cpp DSpark PR:https://github.com/ggml-org/llama.cpp/pull/25784