DeepSeek开源了支撑DeepSeek‑V4.1‑Flash线上服务的推理框架DeepInfer。它不是新模型，而是负责把模型高效运行在GPU／NPU集群上的核心软件，包含专家并行、推测解码、异步调度、结构化输出和多项定制算子，同时支持NVIDIA SM100与华为昇腾950。DeepSeek称，使用这套体系的单个集群每天可处理155万亿Token；不过，目前公开的是可离线运行的核心引擎，并非完整云服务，跨请求KV缓存、预填充／解码服务化拆分和集群负载均衡等组件尚未全部开放。
文章作者、来源：DeepSeek
开源的不是模型，而是模型背后的“发动机”
模型权重决定一个模型能够做什么，推理框架则决定它能以多高速度、多低延迟和多低成本向用户提供能力。
此前，DeepSeek已经陆续开放FlashMLA、DeepGEMM、DeepEP、TileLang等底层算子和通信库。DeepInfer把这些组件组织成一套完整程度更高的运行引擎，负责模型加载、批次调度、并行计算、采样和结构化输出。当前正式支持的模型只有DeepSeek‑V4.1‑Flash，许可证为Apache 2.0。
在混合专家模型中，一次推理只激活部分专家，但不同请求选择的专家并不均匀。如果大量Token同时涌向少数热门专家，一部分芯片会过载，另一部分则处于空闲状态。DeepInfer会收集近期专家负载，保存热门专家的冗余副本，并定期重新分配专家位置，以缩小最忙设备与平均负载之间的差距。
它还支持Attention数据并行、上下文并行和MoE专家并行，并通过异步调度，让CPU在GPU计算当前批次时提前准备下一批任务，减少GPU等待调度器的空档。
推测解码不是固定“猜五个”，而是把算力给最有希望的候选
DeepInfer采用名为DSpark的推测解码机制。一个较轻的预测模块会先生成最多五个候选Token，主模型再负责验证。如果所有请求都固定验证五个候选，大量算力会浪费在置信度很低、注定无法通过的Token上。
DeepSeek的方法会估计每个候选Token被接受的概率，再依据硬件吞吐曲线，优先验证预期收益最高的候选。官方数据称，动态验证将每一步平均验证长度由固定的5个Token降至约3.2至4.4个，同时平均接受长度基本维持在3.2左右。
在每个并行Rank约有60条并发序列的生产工作点，官方估计这一机制可比固定验证五个Token提高约5.4%的吞吐量；在72条并发序列时，增幅约6.7%。这些数字来自DeepSeek自己的EP64／DP64离线测试，尚不能直接外推到其他硬件和流量形态。
另一个优化是“SWA有限回放”。当滑动窗口注意力的缓存缺失时，系统不再重新计算整段上下文，而只回放最近128个Token，用近似方式重建所需状态。DeepSeek称，这使重算成本不再随上下文长度增长，并可将部分预填充计算量降低近一半。
真正的生产优势，大量来自模型之外的缓存系统
DeepSeek为V4.1 Flash设置的目标之一，是把KV缓存保留超过72小时。用户继续长对话或Agent重复读取同一代码库时，系统可以复用此前计算结果，避免从第一个Token开始重新执行预填充。
技术问答披露，其生产系统使用约100 PiB的SSD存储KV缓存，Agent流量的缓存保留约3天，聊天流量保留约7天；按逻辑容量计算，每块在线GPU对应约14.4TB缓存。聊天流量保留时间更长，是因为少量热门对话前缀可能被重复命中许多次。
DeepSeek称，当前一个集群每天能够处理155万亿Token，并在低谷价格下产生每GPU小时38美元的总体收入。这个数字是厂商披露的收入归一化指标，并非利润，也没有同时给出GPU数量、折旧、电力、网络和存储成本，因此不能据此直接推算DeepSeek的盈利水平。
同时支持英伟达和昇腾，但不是普通电脑上的本地框架
DeepInfer目前支持NVIDIA SM100 GPU和华为昇腾950 NPU。英伟达环境要求CUDA 13，昇腾环境要求CANN 9.2；两者都需要Linux、Python 3.12和较新的编译工具链。
官方性能曲线的预填充测试使用4块SM100，解码测试使用64块SM100，而且设备必须位于同一个高速互联域。技术说明进一步建议：预填充使用普通8卡服务器，解码使用64至128卡超级节点；考虑实际效率后，一套较小的推荐部署也可能需要64块预填充GPU加64块解码GPU。
因此，这次开放主要服务于云厂商、大型企业和专业模型托管平台，不意味着个人用户可以在一块消费级显卡上复现DeepSeek的线上成本。官方README也没有列出H100、H200、B200、RTX系列或较早昇腾芯片的正式支持。
（GitHub原文此处有两张吞吐量—延迟曲线，分别展示4块SM100上的预填充性能和64块SM100上的解码性能；图中数据均为DeepSeek自测。）
“生产框架开源”不等于整套线上服务全部开源
DeepInfer的README明确将当前版本称为“离线推理”，并列出了构建完整线上服务仍需补充的三部分：跨请求KV缓存系统，视觉编码／预填充／解码的服务化拆分，以及不同数据并行副本间的负载均衡。
DeepSeek表示，这些组件与其内部基础设施耦合紧密，因此代码尚未完全开放。技术问答公开了部分架构、缓存策略和调度方法，但设计说明并不能替代可直接部署的源代码。
同步开放的deepseek-recipe解决的是另一层问题：它用Rust及Python绑定，把Chat Completions、Responses和Messages等API请求转换成统一会话格式，再将模型输出还原成流式文字、推理内容和工具调用。
但该组件也不负责HTTP服务、模型推理或实际执行工具。部署者仍需自行建设网关、身份验证、限流、监控和多租户隔离。
更深远的影响，是开放模型开始竞争“怎么运行”
DeepInfer最值得关注之处，不是又多了一个推理项目，而是开放模型竞争正在从权重和排行榜扩展到生产基础设施。
一家云服务商即使获得了相同模型权重，如果使用通用推理引擎、缺少长周期KV缓存、专家负载均衡和针对模型结构优化的算子，最终成本与响应速度仍可能显著落后于模型开发者。DeepSeek现在把部分生产经验交给外部托管商，使第三方更有机会提供接近官方API行为和效率的V4.1 Flash服务。
DeepInfer本身最初建立在vLLM之上，也明确致谢了SGLang和TensorRT‑LLM。它并不必然取代这些支持多种模型的通用框架；更可能的作用，是让社区研究DeepSeek针对单一模型做到极致优化的方法，并将其中部分技术反向整合进更广泛的开源生态。