DeepSeek围绕内存扩展逻辑，优化架构开源DeepInfer及同行难复制的原因

最近某开源项目引发热议，大家纷纷称其为“印钞机”，这是因为它能实现80%的毛利，仅17个月就能回本。很多人催着拆解背后的技术，本文就梳理整个事件的逻辑，解释为何会做这样的选择，以及为何其他团队难以复制。

这个项目的核心逻辑非常简单：从一开始就明确，计算能力的扩展相对容易，而内存容量的扩展则困难得多。因此，整个模型和基础设施的迭代都围绕这个原则展开。

在商业层面，该项目始终坚持普惠路线，没有过度追求功利化的变现，因此保持了纯粹性。这种“印钞机”开源的思路正是普惠理念的体现，让更多普通人用得起。

过去几年，作者的工作重心一直放在普惠硬件算力和基础设施构建上，在某厂工作满四年，参与研发了两款芯片：2.0发布时间稍晚于BF3，但性能全面超越；3.0则直接超越BF4/CX8/CX9，将DPU和AI-NIC做到全球第一。在互联领域也达到全球领先水平，接下来将转向算力芯片研发。当前海外大模型参数规模向50T甚至100T扩展，国内若直接采购相关硬件需花费约2000亿美金，还未必能买到足够的设备，因此需要用1000-2000亿人民币解决这个问题。

从内存扩展的角度看技术演进

第一代模型采用标准的Dense Transformer架构，第二代逐渐开启MoE迭代，到V3版本基本定型。这部分解决了Dense FFN的算力消耗和Decode阶段的内存扩展问题，也推动了国内外大规模的相关演进。

解决FFN模块后，重心逐渐转向Attention模块：先用MLA压缩KVCache，再通过NSA和V3.2开启稀疏注意力路径，进一步降低Attention模块的内存访问和外部存储需求。

到V4版本，引入CSA和HCA在token块级别压缩内存，但实验发现过度压缩效果不佳，因此V4.1 Flash转向跨层KVCache共享，再引入YOCO技术优化。

推理基础设施的优化思路

常规推理场景中，KVCache存储分为多层结构：GPU HBM、主机CPU内存、结合RDMA的池化主机内存、本地SSD、分布式存储集群、对象存储集群。这种架构虽能充分利用资源，但带来复杂的通信和网络压力，存在流量争抢、网络混跑拥塞等问题，且PCIe缺乏QoS控制，各类流量互相干扰。

更关键的是调度算法问题：由于多层缓存存在，请求需做缓存感知调度，避免大量KVCache搬运，但这会导致Prefill节点负载均衡问题，引发大量请求排队的长尾效应。同时，GPU缓存的KVCache在实际服务时需要换入换出，还会限制请求batch size，根本原因是KVCache过大，数据搬运受带宽瓶颈约束。

该项目的解决方案是简化缓存层次，仅保留核心存储层，数据路径更干净，调度无需考虑复杂的本地命中策略。整个计算节点是无状态的，存算分离便于弹性扩缩容和调度，Prefill节点计算完成传输到Decode节点后，可释放GPU显存，KVCache由Decode节点写入存储。

这种架构虽简洁，但GPU服务器与存储间的网络带宽需求极高，V3.2阶段曾受限于机头400Gbps带宽，无法充分利用Prefill服务器算力，因此通过DualPath用Decode节点中继解决问题。而在V4和V4.1版本中，模型架构进一步优化了KVCache，现在可能无需DualPath，直接通过400Gbps网卡读取即可。

80%的毛利并非依赖单一技巧，而是长期演进中对细节的打磨。开源推理引擎的每个算子都做到极致，相关技术细节的优化是核心竞争力。

为何其他模型厂商难以复制

从团队协作角度看，若在其他厂商，推理团队遇到KVCache过大时，会找网络团队优化通信、存储团队搭建多层缓存、设计复杂调度策略，看似每一步都正确，但大型组织内各团队的KPI导向会导致问题：算法和训练团队的KPI是模型质量，可能拒绝压缩KVCache的尝试，推理团队只能转向量化加速，还会被算法团队质疑模型性能下降。

此外，算法细节上，很多算法工程师不了解GPU微架构，导致部分shape的计算无法充分利用算力，甚至有些激活参数更小的模型推理吞吐赶不上该项目激活更大的模型。围绕自身算力资源池设计模型并调整KPI难度极高。

组织结构的风险容忍度也很关键：算法团队尝试新Attention架构压缩KVCache时，可能面临巨大失败风险，比如V4中的HCA，发布时模型能力弱于同期竞品，但为后续版本优化奠定基础。这种长期主义的组织文化、算法与基础设施的充分协同，是核心前提。正如相关访谈中提到：“创新缺的不是资本，而是信心和组织高密度人才实现有效创新的能力。”

与该项目团队交流时，能感受到更全面的视角，从算法到算子、基础设施再到GPU微架构，各环节充分协同。而其他团队往往局限于局部领域的优化，难以推动整体变革。

好了，到这里为止。