1M上下文不是越大越好：DeepSeek V4炸出了一个行业集体盲区

2026年4月24日，DeepSeek V4发布，1M token上下文成为标配。

然后，开发者社区开始做两件事：

第一，激动地测试90万token代码库全局重构能力，测试各种"大海捞针"场景；第二，做完之后开始冷静地问同一个问题——"它真的记得住吗？"

MRCR 1M大海捞针测试的结果，揭开了这场狂欢里最不体面的那块遮羞布：V4-Pro得分83.5，Claude Opus 4.7得分92.9。同样的上下文窗口，差了将近10个百分点。

这意味着什么？意味着1M token的竞争，可能从一开始就打偏了。

先说清楚什么是大海捞针测试。

你把一根"针"（一段特定的、几乎不可能自然出现的信息，比如"在第84237个token处有一个香蕉"）埋进大海（一段100万token的随机文本）中，然后问模型：你找到那根针了吗？

这个测试衡量的是模型在超长上下文中精准定位关键信息的能力，而不是"读了多长的文字"。

大海捞针测试之所以重要，是因为它直接反映了Agent场景里的核心需求：当你让AI在50万行代码里找一个Bug，它能不能真的找到，而不是在"假装找"？

V4在编程Benchmark上碾压Opus：LiveCodeBench 93.5 vs 88.8，Codeforces 3206 vs 3168，IMO数学89.8% vs 75.3%（反超14.5分）。但同样的V4，在MRCR 1M大海捞针上输了9.4分。

代码能力、数学推理、Agent工具调用——这些V4全面逼近或者超越了Opus。但在最核心的长上下文任务上，它还差一口气。

这是一个被大多数讨论忽略的关键信息。

行业有一个默认假设：上下文窗口越长，模型能力越强。

这个假设在2019-2022年是成立的——那时候128K就是极限，能处理128K的模型确实比64K的强。但2026年的今天，主流旗舰模型的上下文窗口都在1M以上，这个假设开始变得可疑。

真正的问题不是"能读多长"，而是"读进去之后能用多准"。

这是一个根本不同的能力维度，却被大多数横向对比和选购指南给忽略了。大家还在比"支持多少token"，但真正应该比的是"100万token里，你能不能找到那根针"。

就像买硬盘：容量2TB不代表读写速度快。上下文窗口是"容量"，精准召回率才是"速度"。

DeepSeek V4用CSA+HCA混合稀疏注意力，把1M token的KV缓存压缩到了V3.2的10%，推理算力降至27%。这是工程上的重大突破——不是靠硬件堆，是靠算法效率。

但这个突破解决的是"能读多长"的问题，不是"读了之后能记住多少"的问题。

CSA+HCA的核心逻辑是：近处token用完整的注意力（看得清楚），远处token用压缩后的稀疏注意力（看得全面）。这在大多数任务上工作得很好——比如总结一篇长文、回答一个需要跨越全文的问题。

但大海捞针场景里，那根"针"可能出现在1M token中的任何一个位置，概率均等。在远处的token上，V4用的是高度压缩的稀疏注意力——这意味着远端信息在注意力计算中的权重，被系统性地压低了。

这就是为什么在精准定位任务上，V4与Opus存在差距。Opus没有用V4那种激进的稀疏压缩策略，它靠的是更大的KV缓存和更稠密的注意力计算，换来了更高的召回精度。

效率与精度，是长上下文设计中一对不可调和的矛盾。

V4选择了效率，Opus选择了精度。两者都是合理的技术路线，只是适合的场景不同。

这里出现了一个很有意思的行业悖论：

大部分用户在选购模型时，根本用不到1M token的精准召回能力。

普通用户的使用场景——写邮件、做摘要、代码补全——需要的上下文长度通常在10万token以内，128K的窗口已经绑绑有余。V4的1M token能力，对这类用户来说几乎是冗余的。

真正需要1M token精准召回的场景，是代码库级重构、大型法律文档分析、科研文献综述、多文件代码审查——这类任务的用户群体，在整个大模型用户中的占比，可能不超过5%。

也就是说，95%的用户在为那5%的能力支付溢价——无论这个溢价是价格上的，还是技术路线选择上的。

这个悖论不只是DeepSeek的问题。Claude Opus 4.7的1M token正式版、Gemini 2.0 Pro的2M token——所有这些都在强调"我能读多长"。但没人在说"我在这么长的文本里，能多准确地找到你需要的那句话"。

那么，1M上下文的实际价值在哪里？

对于那5%的深度用户，1M上下文确实有意义，但意义不在于"读得多"，而在于能够进行全局推理。

当你把整个50万行的代码库喂给V4，它能够理解全局架构、追踪跨文件的依赖关系、在多步骤重构中保持一致性——这是128K窗口做不到的事情，因为它不够同时容纳足够多的上下文来理解全局结构。

MRCR大海捞针只是评估模型能力的一个维度，不是全部。V4在编程和数学上的碾压性优势，本身就建立在它能处理超长代码上下文的基础上。

问题是：这个优势能持续多久？

Claude Opus 4.7的1M正式版发布于2026年4月16日——比V4早8天。Anthropic正在快速缩短与DeepSeek在长上下文能力上的差距。V4先发，不代表V4能一直领先。

DeepSeek V4发布后的社区反应很有意思：很多人做了大海捞针测试，发现V4在远端召回上不如Opus，然后开始怀疑V4是否真的值得用。

这个怀疑有合理性，但也有盲区。

合理性在于：如果你需要的正是精准召回能力，Opus确实更可靠。

盲区在于：大多数用户根本不知道自己的使用场景到底需要"读得多"还是"记得准"——他们只是被"1M上下文"这个数字吸引，然后假设这代表"最强"。

这种认知偏差，恰恰是行业在向用户兜售"上下文窗口军备竞赛"时造成的——把一个技术指标包装成了能力证明，却不告诉你这个指标在什么场景下有用、在什么场景下是冗余的。

DeepSeek V4是一台优秀的机器，但不是万能的。它把1M token的门槛降到了1元/百万token，让更多人用得起超长上下文。但它也用这个发布，无意中让整个行业暴露了一个事实：上下文窗口的长度，从来就不等于上下文能力的深度。

能读100万字，不等于读完了还记得住。

记住了，不等于需要的时候还能找出来。

找出来了，不等于找的是对的。

三个问题，三个不同的能力维度。而行业目前还在只回答第一个问题。