▲DeepSeek代码库出现MODEL1相关（图源：X）

这一名称不仅出现在SM90架构相关的.cu内核实例化文件中，还贯穿在多个针对FP8稀疏解码路径的模板定义与内存布局注释里。

更关键的是，据海外开发者推测，MODEL1的背后将是一整套新的推理机制、算子结构与底层内存配置，会与DeepSeek现有V3.2模型呈现出完全不同的技术路径。

在相关代码文件中可以看到，MODEL1被用于核心解码函数的多个实例中，显式适配了头维度为64和128的场景，并专门部署在SM90和SM100架构上。

▲DeepSeek FlashMLA源码截图（图源：GItHub）

代码中多处调用了“ModelType::MODEL1”，与其对应的还有一套独立的持久化内核。这些文件与V32版本的持久化内核文件并行存在，这显示出DeepSeek或许已为该模型设计了与V3系列完全不同的编译路径与执行逻辑。

▲DeepSeek FlashMLA源码文件树（图源：GItHub）

更值得注意的是，在代码中，有一条特别注释写道：对于F3架构（即SM90平台）下的MODEL1模型，其KV缓存的内存stride必须是576B的整数倍。

▲海外网友推文截图（目前该条注释已于代码库内删除）

这一配置区别于V3.2的656B，暗示着MODEL1对底层内存对齐和调度有更为严格的要求，可能与其更复杂的运行时行为与动态缓存机制有关。

一位海外网友也对这部分代码进行了深入解读，他认为，MODEL1在整体结构上展现出更强的实验性特征，支持动态Top-K稀疏推理逻辑，还引入了额外的KV缓存区。

▲海外开发者的分析（图源：X）

前者通过引入一个可变的topk_length指针，允许模型在推理时根据token或请求动态决定参与计算的key数量，提升了计算***的精细调度能力；后者则通过extra_kv缓冲区，提供了将系统提示与用户上下文分离存储的可能，为Agent架构或多段上下文场景提供支持。

据社区开发者分析，MODEL1在同步逻辑与边界控制上可能比V3.2更加复杂。其中RoPE与NoPE维度在双GEMM运算中耦合更紧，可能意味着其在位置编码与张量路径调度上做出了显著调整。

分析还提到，MODEL1引入了运行时边界检查机制，旨在规避动态Top-K推理中潜在的非法内存访问。

此外，尽管官方注释中标明MODEL1的stride应为576B，但据社区开发者基于代码结构估算，其实际内存分配逻辑可能接近584B。这种细微差异被认为反映出该分支仍处于调试或快速迭代阶段。

在更早的1月9日，外媒援引知情人士称，DeepSeek将于2月中旬，也就是春节前后发布其下一代模型，主打编程能力，并在内部测试中已经在多个基准上超越了Claude与GPT系列。

结合目前模型文件结构已覆盖64和128两个头维度、FP8稀疏解码路径已完成适配、内存规范已强制定义等迹象来看，MODEL1很可能已接近训练完成或推理部署阶段，正等待最终的权重冻结和测试验证。

在海外社交平台上，不少用户对MODEL1的曝光反应热烈。一位用户调侃道：“我已经能听见‘新模型将带来99.***%成本下降’了。”

而另一位开发者则认为，如果DeepSeek再次开放权重，势必将对闭源巨头形成压力，推动前沿模型进一步走向开放。

恰逢DeepSeek R1发布一周年，Hugging Face官方博客也发布了特别文章《One Year Since the “DeepSeek Moment”》，系统回顾了过去一年中国开源社区的集体爆发，明确提及DeepSeek的开源策略已从一次***演化为生态策略。

▲Hugging Face官方博客：One Year Since the “DeepSeek Moment”

文章称，R1模型的开源不仅降低了推理技术、生产部署与心理三个门槛，更推动了国内公司在开源方向上形成非协同但高度一致的战略走向。返回搜狐，查看更多