DeepSeek 悄悄把上下文窗口拉到了百万级

2026年2月，社区用户在测试DeepSeek APP时发现一个异常细节：端模型在对话中自称知识库截止到2025年5月，甚至知道OpenAI还没发布的”o4 mini”。同时，系统显示最高支持100万token上下文——远超官方公布的128K标准。

这不是bug。这是DeepSeek V4的灰度测试。

十倍扩容

从128K到1M，上下文窗口扩容了近十倍。

换算成实际阅读量，1M token大概能容纳200-300万汉字，或者几十万行代码。这意味着什么？

单次对话能读完一整套技术文档，或者直接把整个中型代码仓库塞进上下文。开发者不再需要”分批投喂”代码，不用因为token不够而反复复制粘贴。

代码场景的变化

假设你要让AI帮你重构一个项目。

128K时代：你得先投架构文档，再投主要模块，每次提醒它”记住前面的上下文”，还得祈祷别把关键信息挤出去。

1M时代：直接把整个repo扔进去，让AI自己理清模块关系，然后开始干活。

这不是量的提升，是工作流质的改变。

V4的技术铺垫

这次灰度测试不是凭空出现的。过去两个月，DeepSeek以罕见的高密度连续发了两篇重磅论文。

一篇是mHC（流形约束超连接），解决大规模模型训练的稳定性问题。一篇是Engram，提出”条件记忆”机制——用O(1)复杂度的哈希查找取代昂贵的神经网络计算。

这两个技术点都指向同一件事：让模型更高效地处理超大上下文。

mHC让模型在百万级上下文下依然训练稳定；Engram让模型学会”选择性回忆”，不是把所有信息一股脑塞进来，而是按需从记忆库里提取。

这为V4打好了地基。

硬件要求意外友好

根据社区挖掘的信息，V4在硬件需求上没有变得更夸张。

甚至有用户报告，双RTX 4090或者单张RTX 5090就能跑。这和那些需要H100集群才能用的模型形成鲜明对比。

DeepSeek这次走的是”让更多人用上”路线，而不是堆硬件换性能。

知识库的时间戳

模型自称知识库截止到2025年5月，这个细节很有意思。

它说明两件事：一是模型确实在用新数据训练，而不是简单换皮；二是DeepSeek可能在准备持续更新机制，而不是像某些厂商那样”冻结”知识库后放任不管。

为什么悄悄上线

大厂发布新模型通常要搞发布会、发博客、买广告。DeepSeek这次连个公告都没有，直接在APP端灰度。

这可能和公司文化有关。DeepSeek一直是工程师文化，重技术轻营销。也可能是因为V4还没完全ready，先放出来核心能力（长上下文），多模态和其他功能还在路上。

对标

百万级上下文之前是Google Gemini的专属领域。现在DeepSeek也进了这个俱乐部。

从成本结构看，长上下文一直是AI厂商的军备竞赛赛道。谁能以更低成本提供更长上下文，谁就能在代码生成、长文档分析这些场景建立护城河。

DeepSeek这次的动作，说明开源模型在长上下文这个维度上已经不输给闭源对手。

还缺什么

当前灰度版不支持视觉输入，依然是纯文本模型。如果你想让它看图、看视频，还得等。

另外，1M上下文虽然惊人，但如何用好它是另一回事。简单的问答场景根本用不到这么长token，真正的价值在于复杂任务：多文件推理、长文档总结、大规模代码重构。

小结

DeepSeek这次悄悄上线百万级上下文，是V4发布的前奏。

技术上看，mHC和Engram论文铺垫了架构基础；产品上看，1M上下文+2025年5月知识库证明新模型已经在工作；硬件上看，消费级显卡就能跑说明部署门槛没被拉高。

对于开发者来说，这是个利好。长上下文不是噱头，是生产力的基础——你终于可以扔掉那些”分批投喂”的工作流，让AI真正理解和操作整个项目。

延伸思考：当上下文大到能装下整个世界时，模型还需要检索增强吗？还是说检索会被融合进长上下文记忆里？这个问题可能比V4的发布时间更值得关注。

原文信息来自Linux.do社区反馈，技术背景来自公开论文资料