DeepSeek MODEL1曝光：FlashMLA代码更新暗示新一代AI模型，”无限记忆”技术将如何改变我们使用AI的方式？
摘要
DeepSeek在GitHub的FlashMLA代码库中更新了114个文件，其中28处提及全新的MODEL1模型，该模型与现有的V3.2系列并行开发。MODEL1在KV缓存布局、稀疏注意力机制和FP8解码方面进行了多项优化，可能采用Engram条件记忆技术实现长上下文处理能力的突破，预计在2月中旬发布的V4旗舰模型中应用这些技术创新。
DeepSeek在GitHub上究竟更新了什么？
2025年1月，恰逢DeepSeek-R1发布一周年之际，DeepSeek团队在GitHub上对FlashMLA代码库进行了一次引人注目的更新。这次更新横跨114个文件，但真正让技术社区兴奋的是代码中反复出现的一个新名称——MODEL1。
FlashMLA是DeepSeek专门为优化注意力机制而开发的核心库，它为DeepSeek-V3和DeepSeek-V3.2-Exp模型提供底层算力支持。在这次更新中，MODEL1作为一个独立的模型标识出现了28次，并且与V32（即DeepSeek-V3.2的内部代号）明确区分开来。这种代码层面的分离意味着MODEL1不是简单的版本迭代，而是一个全新的模型架构。
FlashMLA的技术基础是什么？
要理解MODEL1的意义，我们先要了解FlashMLA这个技术基础设施。FlashMLA是DeepSeek开发的高效多头潜在注意力内核（Multi-head Latent Attention Kernels），它包含四种核心的注意力计算内核：
稀疏注意力内核支持两种工作模式。在预填充阶段，它采用token级别的稀疏注意力机制；在解码阶段，它同样使用token级别稀疏注意力，但会配合FP8格式的KV缓存来提升效率。
密集注意力内核则分别为预填充和解码两个阶段提供支持。这些内核在NVIDIA H800 SXM5 GPU上的表现极为出色——密集MLA解码内核在内存受限配置下可达到3000 GB/s的带宽，在计算密集型配置下能够达到660 TFLOPS的算力。
MODEL1在代码中透露了哪些技术细节？
从FlashMLA的代码变更来看，MODEL1引入了几个关键的技术改进：
KV缓存布局优化是最显著的变化之一。在现有的FP8 KV缓存格式中，每个token的缓存占用656字节，其中前512字节存储量化后的NoPE部分（包含512个float8_e4m3值），接下来16字节存储4个float32类型的缩放因子，最后128字节保留给未量化的RoPE部分（64个bfloat16值）。MODEL1可能对这个布局进行了进一步优化。
稀疏性处理机制也有所升级。当前的稀疏注意力通过indices张量来指定计算范围，这个张量的形状为(batch_size, seq_len_q, topk)，其中每个索引值的计算公式是：页块索引×页块大小+页内偏移量。MODEL1似乎在这个基础上引入了更灵活的稀疏模式。
FP8解码能力得到了强化。现有的token级稀疏MLA解码内核在H800 SXM5上能够达到410 TFLOPS，在B200上达到350 TFLOPS。MODEL1的优化可能进一步提升这些性能指标。
“无限记忆”背后的Engram技术到底是什么？
网络上流传的”无限记忆”概念，实际上指向DeepSeek在最新研究论文中提出的Engram条件记忆技术。这项技术的核心创新在于将计算与存储解耦，让AI模型能够更高效地查找和利用基础信息。
Engram如何突破传统记忆限制？
传统的大语言模型在处理长上下文时面临一个根本性矛盾：模型参数固定，但需要记忆的信息量随着对话长度线性增长。当上下文长度超过模型设计容量时，模型要么遗忘早期信息，要么因显存不足而无法继续运行。
Engram采用了一种创新的架构设计，将”记什么”与”怎么记”分离开来。具体来说，它通过条件记忆机制，让模型能够将大量信息存储在外部记忆单元中，而不是全部塞进模型参数里。当需要某个信息时，模型会基于当前上下文生成查询，从外部记忆中精确检索相关内容。
这种设计带来了三个关键优势：首先，存储容量不再受限于GPU显存，理论上可以无限扩展；其次，检索效率大幅提升，因为模型不需要遍历所有历史信息；第三，模型可以更激进地扩展参数规模，因为参数增长不再直接增加显存压力。
实验数据显示了怎样的效果？
DeepSeek研究团队在一个拥有270亿参数的模型中验证了Engram技术。实验结果显示，在主要行业基准测试中，应用Engram的模型性能提升了几个百分点。虽然百分点的提升看似不大，但在大模型领域，这种程度的改进往往意味着质的飞跃，尤其是在长上下文任务上。
研究人员特别测试了模型处理超长文档的能力。结果表明，配备Engram的模型在处理几十万字的文本时，仍能准确引用前文细节、保持逻辑一致性，这是传统架构难以做到的。
MODEL1与即将发布的V4有什么关系？
从时间线来看，MODEL1的曝光恰好与DeepSeek计划在2月中旬（农历新年前后）发布新一代旗舰模型V4的消息吻合。业界普遍认为MODEL1很可能就是V4的内部代号或核心技术组件。
V4的定位是什么？
根据公开信息，DeepSeek V4的主攻方向是代码生成能力。这个定位非常明确——在当前AI辅助编程快速发展的背景下，一个专注于代码理解和生成的旗舰模型有着巨大的市场需求。
代码生成任务对模型的长上下文能力要求极高。一个完整的软件项目可能包含数百个文件、数万行代码，模型需要理解整个项目的架构、各个模块之间的依赖关系、命名规范和编码风格。这恰好是Engram技术的用武之地——它能让模型”记住”整个代码库，在生成新代码时保持与现有代码的一致性。
FlashMLA的性能提升如何支撑V4？
FlashMLA在2025年4月22日发布的新版本带来了5%到15%的性能提升，在计算密集型工作负载下能够达到660 TFLOPS的峰值性能。这个提升看似温和，但对于需要处理超长上下文的应用场景，累积效果相当可观。
更重要的是，新版本的FlashMLA引入了针对SM90和SM100架构的优化。SM90支持的稀疏解码内核在H800上达到410 TFLOPS，在B200上达到350 TFLOPS；SM100的稀疏预填充内核在H800上能跑到640 TFLOPS，在B200上更是达到1450 TFLOPS。这些性能数据为V4处理超大规模代码库提供了坚实的算力基础。
长上下文能力会如何改变我们使用AI的方式？
如果MODEL1真的将Engram技术落地到产品中，那么我们与AI交互的模式将发生根本性改变。让我们看看几个具体的应用场景。
写作长篇小说时会有什么不同？
传统AI在协助写作时最大的痛点是”健忘症”——写到第五十章时，它可能已经忘记第一章里主角的性格设定，导致前后矛盾。作者不得不反复提醒AI人物的背景、情节线索和已发生的事件，这严重打断创作流程。
配备长上下文能力的AI可以一次性读入整部小说的草稿，即使有几十万字也不在话下。它会记住每个角色的性格特征、成长轨迹、人物关系网；记住每条情节线的铺垫和伏笔；记住你设定的世界观规则和背景设定。当你请它续写某个章节时，它能自然地引用前面章节的细节，让情节发展合情合理，风格始终如一。
更进一步，AI可以帮你进行全局性的编辑工作。比如你想修改主角的某个关键决定，AI能够自动检查这个修改会影响哪些后续情节，提醒你需要调整哪些章节以保持逻辑自洽。这种全局视角的编辑能力，是短上下文模型完全无法做到的。
分析财报时能做到什么程度？
财务分析是另一个对长上下文能力要求极高的场景。一份完整的上市公司年报通常有两三百页，包含财务报表、管理层讨论、风险披露、附注说明等大量信息。传统AI只能处理其中的片段，分析师不得不手动拆分、多次提问、再自己整合结论。
具备长上下文能力的AI可以一次性读入完整财报，建立起各个财务指标之间的关联。它能够对比多年的数据趋势，发现收入增长背后的驱动因素是新产品贡献还是价格上涨；能够交叉验证不同报表之间的数据一致性，发现潜在的会计调整；能够结合附注说明理解特殊会计处理的影响。
当你问”这家公司的盈利质量如何”时，AI不仅会分析净利润率，还会深入现金流量表查看经营活动现金流，检查应收账款和存货的变化趋势，审视非经常性损益的占比，最终给出一个全面的、有依据的判断。所有这些分析都基于对完整财报的深入理解，而不是碎片化的信息拼凑。
项目管理和代码开发会发生什么变化？
对于软件开发者来说，长上下文能力的价值更加直观。现代软件项目动辄包含数百个源代码文件、数万行代码。当你需要添加新功能或修复bug时，往往需要理解多个模块之间的交互逻辑、数据流动路径和依赖关系。
传统AI助手只能”看到”你当前打开的几个文件，对整个项目架构一无所知。它给出的建议可能在局部看起来合理，但放在整个项目中就会与现有设计冲突。开发者必须花大量时间向AI解释项目结构，这个过程本身就很低效。
具备长上下文能力的AI可以”读取”整个代码库，理解项目的分层架构、模块划分、接口定义和编码规范。当你请它实现一个新功能时，它会考虑这个功能应该放在哪个模块、需要调用哪些现有接口、是否符合项目的设计模式。它生成的代码会自动遵循项目的命名约定、错误处理方式和注释风格，就像一个熟悉项目历史的资深开发者一样。
更强大的是，AI可以进行跨文件的代码重构。比如你想提取一个公共函数供多个模块使用，AI能够识别所有需要修改的地方，生成一致的重构方案，甚至更新相关的单元测试。这种全局性的代码操作能力，能够显著提升开发效率和代码质量。
长期对话和个性化学习如何实现？
长上下文能力还会改变我们与AI交互的时间尺度。现在的AI对话通常局限在单次会话中，每次打开新对话都要重新介绍背景。而具备长期记忆的AI可以跨越数天、数周甚至数月保持对话连续性。
想象你正在学习一门新的编程语言，每天向AI请教几个问题。具备长期记忆的AI会记住你已经掌握的概念、你的薄弱点在哪里、你习惯的学习方式。第十天时，它不会重复讲解你第二天就理解了的基础知识，而是会根据你的进度推荐下一步该学什么，并用你容易理解的方式来解释新概念。
这种个性化的、有延续性的辅导体验，与传统的”一问一答”模式有着本质区别。AI不再是一个无状态的工具，而是一个真正了解你、能够持续陪伴你成长的助手。
技术实现上还有哪些挑战？
虽然Engram技术在实验室环境中显示出巨大潜力，但要将其应用到生产环境中还面临几个关键挑战。
检索准确性如何保证？
外部记忆机制的核心是检索——模型需要根据当前问题，准确找到记忆中的相关信息。这个过程类似于人类回忆往事，但比人类回忆要复杂得多。模型需要理解问题的真实意图，将其转化为有效的查询，从可能包含数百万条信息的记忆库中找出最相关的几条。
如果检索不准确，模型可能会”记混”信息，把A项目的代码规范应用到B项目上，或者在分析财报时引用了错误年份的数据。这种错误比完全不记得更危险，因为它们隐蔽性强、不易被用户发现。
DeepSeek在FlashMLA中实现的稀疏注意力机制部分解决了这个问题。通过indices张量，模型可以精确指定需要关注哪些token，避免在无关信息上浪费计算资源。但这只是基础设施层面的优化，上层的检索策略设计仍然需要大量工程实践来验证和改进。
推理成本会增加多少？
长上下文能力不是免费的午餐，它必然会增加推理成本。即使采用了稀疏注意力和外部记忆等优化技术，处理超长上下文仍然需要更多的计算资源。
从FlashMLA的性能数据可以看出一些端倪。稀疏解码内核的算力（410 TFLOPS）明显低于密集解码内核的峰值性能（660 TFLOPS），这是因为稀疏计算引入了额外的索引开销和内存访问模式的复杂性。对于需要处理数十万token的应用，这些开销累积起来会相当可观。
DeepSeek需要在性能和成本之间找到平衡点。一种可能的策略是根据任务类型动态调整上下文长度——简单对话使用短上下文快速响应，复杂分析任务才启用完整的长上下文能力。另一种可能是采用分级记忆架构，将热点信息保存在快速缓存中，冷门信息存储到较慢但容量更大的外部存储。
实时响应速度如何保障？
对于普通用户来说，AI的响应速度直接影响使用体验。如果为了处理长上下文而让每个回复都慢上几秒甚至几十秒，那么这项技术的实用性就会大打折扣。
FlashMLA的最新优化在这方面做了很多工作。通过tile scheduler元数据的预计算，解码阶段可以在不重复计算的情况下利用KV缓存。FP8量化将缓存大小压缩到原来的一半，减少了内存带宽压力。这些优化使得单token的生成延迟控制在可接受范围内。
但当上下文长度从几千token扩展到几十万token时，即使单token延迟不变，整体的首token延迟（TTFT）也会显著增加。这需要更激进的并行化策略和缓存预加载机制。MODEL1在代码中对KV缓存布局的优化，可能就是为了支持更高效的预加载和并行处理。
从技术曝光到产品落地还有多远？
虽然GitHub上的代码更新和研究论文展示了令人兴奋的技术前景，但我们也要理性看待技术成熟度和落地时间表。
当前的技术成熟度如何？
Engram技术目前仍处于研究阶段。虽然在270亿参数的模型上验证了有效性，但这个规模远小于DeepSeek-V3的6710亿参数。将技术从小模型扩展到超大规模模型，往往会遇到新的技术挑战。
FlashMLA的代码更新反映了工程化的进展。从支持密集注意力到支持稀疏注意力，从仅支持SM90架构到同时支持SM90和SM100，每一步都伴随着大量的性能调优和稳定性测试。MODEL1的出现说明团队正在积极推进产品化工作，但距离最终发布可能还需要几个月的打磨。
按照DeepSeek的发布节奏，V4计划在2月中旬推出。如果MODEL1确实是V4的核心技术，那么我们很快就能看到长上下文能力在实际产品中的表现。但也有可能MODEL1只是V4的一个技术预研分支，真正大规模应用还要等到更后续的版本。
普通用户什么时候能用上？
即使V4按时发布，长上下文功能的开放策略也是一个问题。考虑到推理成本和服务器负载，DeepSeek可能会采取分阶段开放的策略：
初期可能只对API付费用户开放，并设置较严格的速率限制和使用配额。这样既能收集真实用户反馈，又能控制服务器压力。
中期可能会推出分级服务，普通用户有基础的长上下文配额（比如每天处理几个长文档），付费用户享有更高的配额和优先级。
长期来看，随着技术优化和硬件成本下降，长上下文能力可能会逐步成为标配功能，就像现在的多模态能力一样。
竞争对手的进展如何影响DeepSeek的策略？
AI领域的竞争正在从模型规模转向应用能力。OpenAI的GPT-4、Anthropic的Claude、Google的Gemini都在不断扩展上下文窗口。OpenAI的GPT-4 Turbo支持128K token上下文，Anthropic的Claude 2.1更是达到200K token。
DeepSeek的优势在于开源生态和本地化部署能力。如果V4真的能够实现”无限记忆”级别的长上下文能力，这将是一个显著的差异化优势。但这个优势能保持多久，取决于实现的技术细节和竞争对手的跟进速度。
从FlashMLA的开源策略可以看出，DeepSeek愿意分享底层技术，这有利于建立开发者社区和生态系统。但核心算法和模型权重是否完全开源，还需要观察后续的发布公告。
我们应该如何准备迎接长上下文时代？
作为AI的使用者和受益者，我们可以从几个方面为即将到来的长上下文时代做准备。
重新思考工作流程
长上下文AI不只是现有工具的增强版，它会改变我们组织信息和设计工作流程的方式。比如在文档管理上，我们可能不再需要精心维护分类目录和标签体系，因为AI能够在海量文档中精确定位所需信息。
在团队协作上，会议记录、项目文档、代码注释可以更加自然和详细，因为AI能够自动提取关键信息，无需人工总结压缩。这意味着我们可以把更多精力放在创造性工作上，而把信息管理的负担交给AI。
培养新的技能
与长上下文AI有效协作需要一些新技能。首先是学会提供结构化的背景信息——虽然AI能记住所有内容，但合理的信息组织仍能提升交互效率。
其次是学会验证AI的输出。长上下文能力越强，AI犯错时的”自信度”也可能越高。我们需要培养批判性思维，对AI提供的信息进行合理性检验，特别是在专业领域。
最后是学会利用AI的长期记忆特性设计渐进式任务。比如在学习新知识时，可以通过多轮对话逐步深入，让AI根据你的理解进度调整讲解方式，而不是期望一次对话就解决所有问题。
关注隐私和数据安全
长上下文能力意味着AI会记住更多个人信息和工作细节。虽然这带来了便利，但也引发了隐私担忧。我们需要了解服务提供商的数据处理政策：
记忆数据存储在哪里？是在用户的本地设备、私有云还是公有云？不同的存储位置意味着不同的安全级别和隐私保护程度。
记忆数据会保留多久？是仅在会话期间有效，还是会永久保存？用户是否有权删除或导出自己的记忆数据？
记忆数据是否会被用于模型训练？如果会，是否有退出机制？这些问题在使用长上下文AI服务前都需要弄清楚。
对于企业用户，还需要评估长上下文AI对数据合规的影响。如果AI会记住客户的敏感信息，那么这些记忆数据的处理需要符合GDPR、CCPA等数据保护法规的要求。
常见问题解答
MODEL1和DeepSeek-V3.2是什么关系？
MODEL1和V3.2（代号V32）在代码中被明确区分为不同的模型。从FlashMLA的更新来看，它们在KV缓存布局、稀疏注意力处理方式等方面有差异。MODEL1很可能是下一代旗舰模型V4的内部代号或核心技术组件，预计在2月中旬发布。
Engram技术的”无限记忆”是真的无限吗？
“无限记忆”更多是一个形象的说法，而不是字面意义上的无限。Engram通过将计算与存储解耦，理论上可以支持远超传统架构的上下文长度，但实际应用中仍然受到硬件资源、推理成本和响应速度的制约。目前的实验数据显示该技术在270亿参数模型上有效，但具体能支持多长的上下文还需要看产品化后的表现。
FlashMLA的性能提升对普通用户有什么意义？
FlashMLA的性能优化直接影响AI的响应速度和使用成本。5%到15%的性能提升意味着相同的硬件配置可以支持更多并发用户，或者在相同成本下提供更快的响应速度。对于需要处理长文档的用户，这些性能提升会累积成更显著的体验改善。
长上下文AI会比现在的AI贵很多吗？
长上下文处理确实会增加计算成本，但具体增加多少取决于技术实现。通过稀疏注意力、分级缓存等优化手段，成本增加可以被控制在合理范围内。服务商也可能采用分级定价策略，基础的长上下文功能包含在标准订阅中，超大规模的上下文处理需要额外付费。
我现在就想试用长上下文功能，有什么方案？
目前DeepSeek的MODEL1尚未正式发布，但市面上已有一些支持较长上下文的AI模型可供选择。Anthropic的Claude 2.1支持200K token上下文，OpenAI的GPT-4 Turbo支持128K token。虽然这些还不是”无限记忆”级别，但对于大多数实际应用已经足够。可以先用这些工具熟悉长上下文的使用方式，为DeepSeek新模型的发布做准备。
开源社区能用上这些技术吗？
DeepSeek一直保持着对开源社区的友好态度，FlashMLA本身就是在MIT协议下开源的。虽然完整的模型权重是否开源尚不确定，但核心的注意力机制实现代码已经公开，技术社区可以基于这些代码进行研究和改进。此外，多家国内外硬件厂商已经适配了FlashMLA，包括MetaX、Moore Threads、Hygon DCU、Intellifusion、Iluvatar Corex和AMD Instinct，这为开源部署提供了多样化的硬件选择。
