大模型开源，通常先看到的是权重和模型代码。
这次DeepSeek又把开源往推理服务这一层推进了一步。
10月20日，DeepSeek将 DeepInfer 放上GitHub。它是支撑DeepSeek-V4.1-Flash大规模推理服务的框架，官方同时开放了用于协议转换和Token编解码的组件 deepseek-recipe。
这件事的看点，不是又多了一款模型，而是模型“上线之后怎么跑”的一部分实现细节也能被开发者看到了。对于大模型服务来说，推理速度和成本不只由模型本身决定，还和计算内核、GPU间通信、请求调度、缓存复用等环节有关。用户看到的是模型在回答，服务端处理的却是一整套流水线。
推理服务的“后半场”，开始进入开源范围
DeepSeek把DeepInfer定位为面向大规模云服务的推理框架。当前仓库列出的支持模型是DeepSeek-V4.1-Flash，示例默认使用的模型权重为DeepSeek-V4.1-Flash-1017；框架支持NVIDIA SM100 GPU和华为昇腾950 NPU，采用Apache 2.0许可证。
框架里包含优化内核、分布式并行、异步调度、结构化输出等能力，也支持DSpark推测解码和SWA bounded replay。用更直白的话说，DeepInfer不只是把模型“加载起来”，还试图减少生成过程里的等待和重复计算，让多个计算设备能更有效地一起工作。
模型推理通常可以粗略看成两个阶段：先处理用户输入的提示词和上下文，再逐步生成回答。DeepSeek的生产系统把视觉编码、Prefill和Decode分开部署，让各阶段可以按自身负载配置资源；对MoE部分，则使用专家并行等方式分配计算。这样做的目标是提升吞吐，同时控制用户等待时间。
▲DeepSeek-V4.1-Flash推理系统架构图
缓存也是这套系统的重要部分。长对话、Agent任务会反复带入大量上下文，如果每次都从头处理，计算资源就会被重复消耗。DeepSeek在部署说明中提到，其系统会保存并复用KV Cache；SWA bounded replay则在部分缓存缺失时，只重算最近的一段内容，而非重新处理全部上下文。
另一个伴随开源的组件deepseek-recipe，处理的是请求进出模型时的协议和Token转换。它可以在Chat Completions、Responses、Messages等接口格式与模型实际输入输出之间做转换。对想把DeepSeek模型接进不同工具链的开发者来说，这类“连接层”往往不如模型本身显眼，却会影响接入工作量和请求处理效率。
官方披露的吞吐数据，先看清它的口径
DeepSeek在部署问答中披露，单个集群目前每天服务约155万亿Token，并称按谷价口径计算，每GPU小时整体收入约38美元。这个数字容易成为讨论焦点，但它属于DeepSeek披露的生产数据，不是第三方在统一硬件、统一模型和统一流量下复现的基准。公开材料也没有提供足以让外部完整还原该集群成本和收入的全部信息，因此不能直接拿它与其他公司的单卡效率或营收做横向比较。
这次开源也有明确边界。DeepSeek公开的仓库目前主要提供离线推理所需的核心能力；官方说明，完整在线服务依赖的KV Cache管理、Prefill与Decode分离部署、跨副本负载均衡等部分，仍与内部基础设施紧密耦合，尚未全部开源。
换句话说，拿到DeepInfer，并不等于立即拥有一套可以支撑大规模线上服务的完整方案。仓库列出的硬件要求也不低：NVIDIA路径需要CUDA 13，昇腾路径需要CANN 9.2；官方部署说明对Prefill和Decode的推荐资源配置也涉及多卡集群。对个人开发者，它更像是学习推理系统设计、尝试离线部署的入口；对有集群和工程团队的机构，才更接近可评估的基础组件。
从这个角度看，DeepInfer的价值不在于“所有人今天就能照搬DeepSeek的服务”，而在于它把一部分工程实现和技术选择放到了公开仓库里。开发者可以看到官方如何组织推理、如何处理缓存和并行，也能据此做适配或提出改进。只是，真正决定线上服务表现的系统组件并未全部开放，落地时仍要补齐自己的缓存、调度和运维能力。
