你好，我是《Redis 高手心法》畅销书作者码哥，可以叫我靓仔。

• "2026了，你的应用上下文还卡在128K？DeepSeek-V4来了"

• "三次延期终于来了，DeepSeek-V4我测完了，说几句真实感受"

• "DeepSeek-V4发布：上下文扩到百万，KV缓存省了90%"

• "大多数人以为V4靠堆参数，其实DeepSeek真正赢在这个架构创新上"

---

DeepSeek 官方公众号的推送，脑子里第一个念头不是"终于来了"，而是"这次是真的吗？"

去年年底就传 V4 要出了。农历新年前后，又传了一波。三月份，有媒体说"数周内发布"。然后就没了声音，直到今天。

不是出了什么意外。是芯片的问题——V4 要在华为昇腾上跑，而且要跑好，不是迁移测试，是真正的生产部署。这件事比任何人预期的都难，也比任何人预期的都值。

现在它来了，正式名字是 DeepSeek-V4 预览版，官方口号是"迈入百万上下文普惠时代"。

我把技术报告看了一遍，有一个数字让我停了很久：在百万 Token 上下文下，V4-Pro 需要的推理计算量只有 V3.2 的 27%，KV 缓存只需要 10%。上下文窗口扩大了 8 倍，成本反而降了 90%。

这不是工程优化，这是架构设计上的一次真正跳跃。

等了半年，今天终于来了

DeepSeek 去年一月发布了 R1，把硅谷吓了一跳。然后大家开始等 V4。

官方一直没有明确时间线，但从各种信息源拼凑出来的情况大概是这样：V4 的核心训练早就完成了，但他们选择了一件很难的事——在正式发布前，先把模型在华为昇腾 910B 和寒武纪 MLU 芯片上跑通，而且要达到生产可用的性能水平。

这事麻烦在哪儿？主流的大模型训练和推理框架几乎都是围绕 CUDA 生态构建的，FlashAttention、Triton kernel、cuDNN 融合算子——每一块优化都是 NVIDIA GPU 专属的。把一个万亿参数的 MoE 模型迁移到非 CUDA 平台，不是换个驱动那么简单，是整个底层计算调度、内存管理和算子库都要从头适配。

中间有过至少一次上线后回滚，有过芯片适配验证阶段的延期。这些反复不是 DeepSeek 的失败，是他们选了一条真正难走的路。

结果是：在昇腾 910B 上，V4 的算力利用率达到约 85%，部署成本约为英伟达方案的三分之一。做个参照：CUDA 上高度优化的大模型推理工作负载，稳定跑到 70-75% 利用率已经算不错了。昇腾达到 85%，说明底层内核融合和调度做得相当扎实，不是凑合能跑，是真的优化过了。

这是中国 AI 体系第一次在生产规模、旗舰模型级别上，系统性地验证了国产芯片承载核心推理能力的可行性。等了半年，值。

两个型号，一个划时代的数字

V4 发布了两个版本，架构相同但规模不同：

DeepSeek-V4-Pro：总参数 1.6 万亿，每个 Token 激活约 490 亿参数，MoE 层包含 384 个专家，每次激活其中 6 个。注意力头维度 512，使用 Sparse MQA + SWA 组合。这是旗舰版，目标是把推理能力拉满。

DeepSeek-V4-Flash：总参数 2840 亿，每 Token 激活约 130 亿参数。定位高速低成本场景，API 定价预计维持 DeepSeek 一贯的低价路线，约 $0.30/MTok。

两个版本共享同一个关键规格：上下文窗口 100 万 Token。

做个参照：DeepSeek-V3 的上下文是 128K Token，GPT-4o 是 128K，Claude 的 200K 在现在的标准下已经算"长上下文"了。100 万 Token，约等于可以一次性放进去一部百万字中文小说、数十万行代码库、或者数百份会议记录。不需要分块，不需要摘要预处理，整个放进去直接问。

License 是 Apache 2.0，意味着可以商用、可以私有化部署、可以基于它做二次开发。开源这件事在 V4 这个规模上仍然不是理所当然，DeepSeek 继续做了。

最反直觉的设计：上下文扩 8 倍，成本降 90%

传统 Transformer 的注意力机制有一个众所周知的问题：KV 缓存随上下文长度线性增长，计算量甚至平方增长。128K 已经很贵了，扩到 1M，按原来的设计成本要增加接近 8 倍。这不是工程问题，是基础架构的限制。

DeepSeek-V4 没有接受这个前提，而是从根源换了打法。他们使用了一套混合注意力机制，V4 的注意力层分为两种类型交替排布：

CSA（Compressed Sparse Attention，压缩稀疏注意力）：负责处理局部信息。使用滑动窗口机制，每个 Token 只关注固定窗口内的邻近 Token，计算开销接近线性而非平方。大多数语言任务中，局部连贯性（相邻句子之间的关系）是最密集的信息来源，CSA 以极低的成本把这部分覆盖好。

HCA（Heavily Compressed Attention，重度压缩注意力）：负责全局信息。它不回避对全序列的覆盖，但通过极度压缩的 KV 头来实现，把每个 Token 的键值对压缩到远小于原始维度的表示空间里，再做全局注意力计算。损失一定精度，换来 KV 缓存的大幅收缩。

两者配合的结果，在 1M Token 的上下文设置下：**V4-Pro 单 Token 推理的 FLOPs 只需要 V3.2 的 27%，KV 缓存只需要 10%**。

图：同等比例尺下，V3（蓝色）KV缓存随上下文线性增长，V4（绿色)始终贴近基线。橙色虚线为 V3 的 100% 高度参考线。

另外还有一个机制叫 mHC（Manifold-Constrained Hyper-Connections，流形约束超连接）。传统残差连接在极深层的 MoE 网络里容易出现信号退化——梯度消失、表示坍塌这类问题。mHC 通过在流形约束下增强残差连接，解决的是让 V4 在超大规模下能稳定训练和推理的基础问题。它不是那种让 benchmark 好看的创新，是让整个系统能运转起来的基础件。

Engram：为什么叫"普惠"

如果说 CSA+HCA 解决了注意力层的效率问题，Engram 系统解决的是另一个更底层的问题：1M Token 里，如何快速找到你真正需要的信息？

标准 Transformer 注意力的检索复杂度是 O(n)——Token 越多，查找越慢。对于 1M Token 这个规模，线性扫描的代价是决定性的，这是上下文扩展成本居高不下的根本原因之一。

Engram 用了一个完全不同的方案：基于哈希的 DRAM 存储。它把上下文信息按内容相关性哈希存储在 DRAM 里，检索时通过哈希索引直接定位目标信息，不需要全量扫描。

检索复杂度：**O(1)**。不管上下文有多长，查找时间是恒定的。

实测效果：在 Needle-in-a-Haystack（大海捞针）测试中，1M Token 上下文下，Engram 的准确率是 **97%**，标准注意力机制是 **84.2%**。更长的上下文里，Engram 不只是更便宜，而且更准。

这个设计的代价是什么？哈希检索对精确内容匹配依赖度高，对模糊语义的连续关联可能不如全量注意力精确。DeepSeek 的测试表明在主流任务上影响有限，但这仍然是一个需要在实际使用中持续观察的权衡点，特别是在需要极精细长程依赖推理的场景下。

理解了这两个机制，"普惠"这个词就不只是宣传语了——百万 Token 上下文的成本，真的被压到了之前 128K 场景下接近的水平。这是定价层面的破局。

跑分放出来了，说几句实话

官方公布的性能数字：

基准测试	DeepSeek-V4-Pro	DeepSeek-V3.2	Claude Opus 4.5
HumanEval（代码生成）	90%	~79%	~88%
SWE-bench Verified（真实工程任务）	80%+	67.8%	80.9%
MMLU（综合知识）	90%	~88.5%	~88%
Needle-in-a-Haystack（1M Token）	97%	—	—

SWE-bench 这个数字是关键。80.9% 是 Claude Opus 4.5 的官方成绩，是目前最好的成绩之一。V4-Pro 的 80%+ 意味着开源模型首次触及这个级别——这不是"接近"，这是"并排"。

但我要说一句不那么好听的话：这些是 DeepSeek 内部测试或泄露来源的数字，还没经过大规模独立验证。历史上，R1 发布时，社区在 48 小时内就独立验证了主要 benchmark，V4 大概率会走同样的路径。我倾向于相信这些数字大体准确，但在独立测试出来之前，适当保持观望是合理的。

代码生成能力的提升最容易感知：从 DeepSeek-V3 的 79% 到 V4 的 90% HumanEval，提升了 11 个百分点。SWE-bench 的提升更大——从 67.8% 到 80%+，跨越了 12 个百分点以上。对于开发者工具来说，这个差距在实际使用中是可以感受到的。

国产芯片的这一步，比你想的重要

V4 在华为昇腾 910B 和寒武纪 MLU 上完成训练和推理部署，算力利用率约 85%，部署成本约为英伟达方案的 1/3。

这不是"我们也能跑 LLaMA"那种意义上的适配，也不是学术界的验证性实验。这是一个万亿参数的旗舰模型，选择了在非 CUDA 平台上首发生产环境。

过去几年，中国 AI 芯片适配的进展大多停留在中小模型或研究级别。核心大模型——无论是 GPT 系列、Claude 还是各家开源旗舰——全都跑在 NVIDIA A100/H100 上。这不只是技术偏好，是整个生态链的路径依赖：框架、库、调优工具全都向 CUDA 收敛。

DeepSeek-V4 的这次发布改变了一件事：百亿甚至万亿参数的核心推理，在非 CUDA 硬件上达到了可接受的生产水平。

85% 的利用率意味着底层内核融合和内存调度做到了相当深度。而 1/3 的成本意味着对于高并发推理场景，国产硬件路径的成本结构开始具备竞争力了。这个"开始"，会影响后续很多基础设施决策。

对开发者来说，百万上下文意味着什么

直接说应用场景，不绕弯子。

代码库理解：把一个中等规模项目（比如 50 万行 Python）一次性塞进上下文，让模型理解整个代码库的结构和依赖关系，然后帮你重构、排查 bug 或者写迁移脚本。以前这类任务要靠向量检索来分块处理，丢失了大量跨文件的依赖上下文，现在可以端到端。

长文档分析：整份合同、整本技术规范、整季财报——不需要分页，不需要摘要预处理，直接扔进去问问题。Engram 的 97% 准确率比手动分块再聚合的方案往往更可靠，而且不需要设计复杂的 chunking 策略。

多轮对话历史：对话类应用可以保留极长的历史上下文，不再需要强行 session 截断或摘要压缩。对于需要强一致性的顾问类、客服类场景，这是实质性的质量提升。

一个简单的调用示意（等 API 正式上线后可以直接用）：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.deepseek.com/v1",
    api_key="your-api-key"
)

# 直接传入整个代码库内容，不需要分块
with open("entire_codebase.txt") as f:
    codebase_content = f.read()  # 可达数十万 token

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {
            "role": "user",
            "content": f"以下是完整代码库：\n\n{codebase_content}\n\n请帮我找出所有潜在的内存泄漏位置并给出修复建议。"
        }
    ],
    max_tokens=4096
)

print(response.choices[0].message.content)

注意：这里不再需要设计 RAG 的 chunk 策略、embedding 检索、结果重排序这一套，单次调用搞定。对于上下文总量在 1M Token 以内的场景，这往往是更简单、更准的方案。

关于 RAG 的补充：百万上下文不是 RAG 的终结者。对于超大规模知识库（亿级 token、实时更新的数据），RAG 仍然有不可替代的意义。但对于"中等规模、需要精确理解上下文关系"的场景，直接放进去确实是更简单、更准的方案。两者会共存，但使用边界会移动。

常见问题

Q: DeepSeek-V4 和 R1 有什么关系，R2 还会有吗？

A: R1 是 DeepSeek 的推理增强模型，核心在于强化学习驱动的思维链能力。V4 是基础大语言模型的架构升级，主要提升上下文长度、多模态能力和推理效率。两条线是独立的但相互依赖的——可以理解为 V4 是下一代底座，如果后续有 R2，大概率会是在 V4 上做推理增强训练。

Q: 开源了，我能本地部署吗？

A: V4 预览版同步开源，License 是 Apache 2.0，可以商用、私有化部署。但参数量决定了门槛：V4-Pro（1.6T 参数）INT8 量化需要至少 2 张 RTX 4090（48GB 显存），INT4 量化最低需要 1 张 RTX 5090（32GB 显存）。个人用户跑完整 Pro 版比较困难。V4-Flash（2840 亿参数）门槛低得多，INT4 量化在单张高端消费级显卡上可以跑起来。

Q: KV 缓存降到 10% 会有信息损失吗？

A: 从原理上说，是的。CSA+HCA 混合注意力设计是以部分精确度换效率，哈希检索也不是无损的全量注意力覆盖。DeepSeek 的测试表明在主流 benchmark 上影响有限（97% Needle-in-a-Haystack 就是证明），但在需要极精细长程依赖推理的任务上，理论上存在权衡。实际影响还需要等社区大规模独立测试。

Q: V4-Flash 和 V4-Pro 实际使用怎么选？

A: 绝大多数日常应用选 Flash。它速度更快、成本更低，在常规编码、问答、摘要任务上与 Pro 的差距在实用上不显著。Pro 适合以下场景：超长上下文下的复杂推理（比如分析整个代码库的架构问题）、需要最高精度的数学/逻辑任务、以及多模态输入场景里需要深度理解的任务。如果你的应用不在这几类里，从 Flash 开始。

Q: 多模态能力现在能用了吗？

A: V4 的多模态是原生集成在预训练阶段，不是额外插件，支持图片、视频和文本的混合输入与生成。但预览版的多模态具体能力还在社区测试阶段，官方的多模态 benchmark 数字尚未全面公布。我的建议：文本和代码能力现在就可以测起来，多模态等第一批独立评测出来再做判断。

我的判断

坦白讲，百万上下文这个 spec 在一年前我会认为是 PPT 里的未来规划，不是今天能落地的东西。但 V4 把 KV 缓存降到 10%、Engram 做到 O(1) 检索——每一件事单独看都不算奇迹，组合在一起的结论是：长上下文这件事的推理成本，从今天起真的变成了产品层面可接受的数字。

那些依赖分块+RAG 勉强绕过上下文限制的架构，值得认真想想哪些部分可以简化了。不是说 RAG 过时了，是说之前很多"不得不用 RAG"的场景，现在有了另一个选项。

至于国产芯片这条线——它的意义不在于今天替代了什么，而在于第一次在生产规模上证明了"可以"。这个证明本身，会影响后续很多基础设施的决策方向。

下一篇打算深入拆 Engram 在视频长序列理解里的工作机制，以及多模态场景下 1M Token 上下文的实际表现。感兴趣的话关注一下，有新内容会第一时间推送。

如果你的团队正在做长文档分析、代码理解或者多轮对话类的应用，这篇的几个技术细节直接影响架构选型，可以转给做技术决策的同学参考。

参考资料

• DeepSeek 官方公众号发布公告（2026-04-24）

• DeepSeek-V4-Pro on Hugging Face

• DeepSeek-V4 自主还是兼容——延期背后的芯片选择题（钛媒体）

• Bloomberg：DeepSeek Unveils Newest Flagship AI Model