DeepSeek 开源 DeepInfer：推理框架核心解密，开发者如何受益？

2026 年 10 月 20 日，DeepSeek 宣布开源内部推理框架 DeepInfer，并同步开放 Token 编解码组件 deepseek-recipe。与此前开放模型权重和底层计算算子不同，这次更新进一步深入大模型服务的运行环节，公开了用于支撑 DeepSeek-V4.1-Flash 大规模推理的部分核心工程实现。

这项更新值得关注的原因，不只是 DeepSeek 新增两个开源项目，而是它把大模型规模化部署中的一部分关键技术带到了开发者面前。模型权重决定开发者能够使用什么能力，推理框架则影响这些能力如何在硬件上运行，以及在给定算力条件下能够承载的请求规模。

DeepSeek 官方在部署问答中披露，其单个集群目前每天处理约 155 万亿 Token，按谷电价格计算，每 GPU 小时的整体收入约为 38 美元。这里的 38 美元是收入，不是利润，也不能直接理解为单张 GPU 的净收益。这个数字反映大规模推理服务的运营体量，也说明推理效率已经成为影响 AI 服务经济性的关键因素。

不过，开源并不等于完整生产系统可以直接复制。DeepInfer 当前公开版本主要支持离线推理，线上服务依赖的部分缓存管理、分离部署和负载均衡组件仍未包含在内。理解这一边界，才能准确判断这次开源对开发者、企业和 AI 应用生态的实际价值。

一、DeepInfer 是什么？为什么推理框架开始受到关注

DeepInfer 是 DeepSeek 面向自身模型打造的高性能推理框架，用于支撑大规模生产推理服务，当前开源版本适配 DeepSeek-V4.1-Flash，内置模型运行时、优化算子、并行计算、投机解码、异步调度和结构化输出等功能。

项目采用 Apache License 2.0 开源许可，遵守协议条款即可开展商业使用。需要注意，商业许可不代表硬件要求、部署成本和工程工作量可以忽略。

理解 DeepInfer 的价值，需要区分模型推理的两个层次。

模型负责根据输入生成结果，推理框架负责组织模型计算。一条请求到达服务端后，系统要处理输入 Token、执行注意力计算、调度 GPU 任务、管理批次，并持续输出 Token。请求量上涨时，GPU 利用率、显存占用、通信开销和调度效率都会直接限制服务上限。

因此即便两套部署方案使用完全相同的模型权重，吞吐量、响应延迟、单位 Token 成本也会存在明显差距。优化推理框架，本质就是解决模型能力如何更高效转化为可用服务的问题。

此前 DeepSeek 已经陆续开放 FlashMLA、DeepGEMM、DeepEP 和 TileLang 等底层技术。本次 DeepInfer 将这些优化能力整合进一套更完整的推理执行环境，方便开发者研究从算子执行到并行调度的整套实现逻辑。

官方也明确说明，DeepInfer 最初主要基于 vLLM 构建，同时参考了 SGLang 和 TensorRT-LLM 的设计。它并非从零开发的全新系统，而是针对 DeepSeek 模型结构深度定制优化的推理实现。

二、DeepInfer 的核心技术：四个值得关注的优化方向

1. Prefill 与 Decode：把读题和生成答案分开优化

大模型推理分为 Prefill、Decode 两个阶段。

Prefill 阶段处理用户提示词，计算后续生成 Token 需要的中间状态，长输入场景下计算负载较高；Decode 阶段逐一生成输出 Token，对生成速度、显存访问、调度效率十分敏感。

两个阶段计算特征差异很大：Prefill 适合大规模并行计算，Decode 更容易受逐 Token 串行生成、访存开销制约。如果用同一套调度逻辑承载两类负载，GPU 资源利用率很难拉满。

大规模部署里的 Prefill 与 Decode 分离（Prefill-Decode Disaggregation，简称 PD 分离），可以独立分配输入处理、输出生成资源，根据实时负载动态调配。

需要强调：DeepInfer 开源版本只包含支撑推理执行的基础引擎能力，完整的 VE/Prefill/Decode 线上分离调度系统，并不在本次开源范围内。

对开发者来说，这项技术提供了清晰的性能优化思路：瓶颈来自输入处理压力就重点优化 Prefill；瓶颈是持续生成速度，就优化 Decode 的吞吐与延迟，而不是单纯堆叠 GPU。

2. KV Cache：减少重复计算，降低长上下文服务开销

KV Cache 是推理核心缓存机制。模型处理上下文时生成注意力计算所需的 Key、Value 状态，后续生成过程可以直接复用有效历史状态，避免反复全量处理上下文。

在多轮对话、代码分析、Agent 工作流场景下，这个机制收益显著。例如编程 Agent 依次读取项目结构、检查文件、修改报错代码，如果每一步都重复处理相同上下文，算力会被大量无效消耗。

DeepSeek 线上架构采用独立 3FS 存储集群存放持久化块级 KV Cache，配合主机共享内存、GPU 显存完成缓存调入，异步读取和数据传输可以与模型计算重叠，削弱缓存加载带来的推理阻塞。

这套方案的核心不只是缓存本身，而是缓存、调度、存储、计算之间的协同设计：缓存存储位置、跨机复用策略、显存加载时机，都会最终影响性能。

同样需要注意：完整线上 KV Cache 管理系统没有随本次 DeepInfer 一同开源。开发者可以参考公开的推理实现，但直接部署开源版本无法获得官方线上服务同级别的缓存能力。

3. DSpark 投机解码：减少逐 Token 生成的等待

传统自回归解码串行生成 Token，上一个 Token 输出完成后才能计算下一步，串行依赖让 Decode 延迟很难进一步压低。

投机解码（Speculative Decoding）思路不同：先批量生成候选草稿 Token，再由主模型校验。校验通过即可一次性确认多个 Token，降低串行生成开销。

DeepInfer 支持 DSpark 和置信度调度验证（Confidence-Scheduled Verification），仓库提供配套配置项：DEEPINFER_ENABLE_MTP_VARLEN=1 开启变长投机解码路径，DEEPINFER_USE_NEXTN_DECODE 控制最大草稿长度，默认值为 5。

投机解码的加速收益受模型、硬件、请求长度、任务分布影响，草稿 Token 存在校验失败的情况，不能直接把草稿长度等同于固定加速倍数。

长文本写作、代码补全、多步骤 Agent 任务比较适合这项优化：减少主模型串行等待时间，要么提升整体吞吐，要么在延迟约束下承载更多请求。

4. 异步调度、批次不变推理与结构化输出

除以上三点，还有几项容易被忽略、对工程落地至关重要的能力：
异步调度：CPU 侧批次编排和 GPU 计算重叠执行，减少调度逻辑阻塞 GPU，默认开启。
批次不变推理（Batch-Invariant Inference）：降低批次组成变化对模型输出结果的干扰，方便回归测试、结果复现、稳定性验证，当前仅支持 NVIDIA 平台。
确定性采样：固定输入与采样参数时，输出保持一致，适合推理行为复现验证；但该效果受硬件、运行配置约束，不保证全环境生效。

同时 DeepInfer 支持正则表达式、JSON Schema、EBNF 语法约束的结构化输出。面向程序消费的应用可以直接锁定输出格式，减少后续解析、校验成本。比如代码审查 Agent 固定返回问题位置、原因、修改方案；业务自动化应用直接输出标准化结构化数据。在这类场景中，输出格式稳定性和回答质量同等重要。

三、deepseek-recipe 同步开源：解决 API 协议与 Token 编解码问题

DeepInfer 聚焦推理执行，deepseek-recipe 负责请求格式、提示词渲染、Token 编解码、模型输出转换链路。

组件核心逻辑使用 Rust 开发，附带 Python 绑定，采用 MIT 许可证。它可以把 Messages、Chat Completions、Responses 等各类请求格式统一转为内部 Conversation 结构，按照 DeepSeek V4/V4.1 规范渲染提示词，并把模型输出转换为标准响应结构。

这一层看似只是数据转换，却直接影响模型接入兼容性。不同 API 协议在消息结构、工具调用、思考内容、流式响应、返回字段上存在差异。开发者自行实现协议转换，很容易出现工具参数解析异常、特殊 Token 处理错误、流式边界错乱等隐性问题，造成同模型在不同接入环境表现不一致。

deepseek-recipe 提供贴近官方实现的参考方案，支持文本、图像、思考模式、客户端工具调用等能力，但功能并未全部补齐。官方 README 标注了暂未支持项：服务端工具执行、通过 previous_response_id 恢复 Responses 会话上下文，以及部分高级输出约束。并且该组件本身不承担推理、工具执行、HTTP 传输能力，需要上层应用或服务层补齐。

API 协议适配、模型推理、业务工具执行是三个相互关联但独立的层级。deepseek-recipe 解决接口适配问题，它不是开箱即用的完整大模型服务。

四、硬件要求与部署门槛：开源不等于所有设备都能运行

DeepInfer 降低了研究 DeepSeek 推理技术的门槛，但普通电脑无法直接运行完整框架。这类推理框架强绑定模型架构、底层算子与计算硬件，专用算子、分布式并行场景下，硬件环境优先级高于安装流程。

当前公开版本支持平台汇总：

表格

SM100 属于 NVIDIA Blackwell 架构特定计算平台，不能等同于全部 NVIDIA 显卡。H200、B200 等型号兼容性，需要以官方支持清单为准，不能仅凭产品名称判断。

对开发者的影响十分明确：已有合规集群可以编译部署、研究算子调用、并行策略；仅有消费级显卡的开发者，不建议直接照搬官方部署方案，优先选择适配更广的推理后端或者量化模型。

运行 DeepInfer 不只是下载模型权重，模型文件、算子编译、驱动版本、设备运行时、分布式通信环境必须全部匹配。硬件达标，但底层软件版本不一致，依然会编译失败、算子加载异常、推理结果出错。

五、如何开始使用 DeepInfer：从环境检查到离线推理

想要上手研究 DeepInfer，建议先核验软硬件环境，再编译部署。框架内置硬件专属优化算子，不能直接套用其他推理项目的安装命令。

1. 拉取代码，核验环境

DeepInfer、deepseek-recipe 两个仓库分开维护。部署前通读 README，确认平台支持范围、依赖版本、模型要求、示例逻辑。环境确认无误后拉取源码：

git clone https://github.com/deepseek-ai/DeepInfer.git
cd DeepInfer

NVIDIA 环境重点核对 CUDA、GCC、Python、驱动；昇腾环境校验 CANN 与运行时配置。推荐新建独立 Python 虚拟环境，避免和现有推理项目依赖冲突。

1. 编译推理框架

仓库自带构建脚本，以官方文档为准，基础流程示意：

# NVIDIA 平台
export DEEPINFER_ACCELERATOR=nvidia
./build.sh

昇腾平台需要配置对应设备类型，提前完成 CANN 环境初始化。编译结束后检查自定义算子加载、设备识别状态；分布式场景额外验证设备拓扑、通信配置、进程启动方式。

1. 执行离线推理

开源包自带离线推理示例，可以加载模型提交请求，观测生成结果、日志、硬件资源占用。默认会自动拉取 deepseek-ai/DeepSeek-V4.1-Flash-1017 权重，也可以通过 DEEPINFER_HF_MODEL_DIR 指定本地模型目录。

离线推理适合验证模型加载、生成逻辑、结构化输出、算子运行行为。单次请求跑通不代表满足生产稳定性要求，企业上线还需要做长时间压测、并发测试、异常恢复、资源利用率观测。

1. 测试投机解码与确定性推理

重点对比 DSpark 投机解码开关开启 / 关闭状态下的吞吐、首包延迟、生成速度，在相同模型、输入、硬件条件下采集数据，不要只依靠理论预判加速效果。
批次不变推理、确定性采样适合实验复现、版本对比，输出一致性受硬件与运行参数约束，不能默认所有环境都稳定复现。

六、DeepInfer 与 vLLM、SGLang 有什么区别？

DeepInfer 开源之后，很多开发者会疑惑：已有成熟的 vLLM、SGLang，为什么还需要这套推理框架？

核心差异在于定位：通用推理框架，和面向特定模型深度打磨的推理系统，解决的痛点不一样。

vLLM、SGLang 面向广泛模型生态，提供模型加载、批调度、KV Cache、在线服务能力，优势是模型兼容强、配套服务完善，开发者可以统一接口管理多模型。

DeepInfer 定位 DeepSeek 模型专属优化引擎，继承 vLLM 等项目设计思路，深度集成适配 DeepSeek 模型的算子、并行、解码逻辑。它的价值更多是给社区提供官方视角的实现范本，而不是通用替代方案。

表格

两者不存在替代关系。如果业务需要混跑多款大模型，通用框架更适合统一管控；如果目标是深挖 DeepSeek 模型底层优化思路、复现官方推理性能，DeepInfer 更合适。

同时要区分两个概念：离线推理性能 ≠ 线上生产服务能力。离线测试吞吐优秀，不代表自带请求排队、流量调度、故障转移、长上下文缓存治理能力。迁移方案必须在自有硬件上搭建测试集，实测首 Token 延迟、生成速度、并发吞吐、显存占用、长时间稳定性之后再决策。

七、开源版本与完整线上服务之间，还差哪些环节

本次开源交付的是推理引擎核心层，不等于一套开箱即用的云端生产服务。线上完整系统由大量配套组件共同支撑，开源版本缺失三块核心生产能力：

1. 完整 KV Cache 存储与复用系统

线上长上下文服务高度依赖多级缓存策略提升命中率、降低成本。开源版本只提供基础缓存推理链路，缓存持久化、跨实例共享、淘汰策略、资源调度逻辑需要团队自行开发。

1. Prefill 与 Decode 分离编排系统

PD 分离可以拆分算力池，分别适配两类负载，但会增加跨机调度、数据传输复杂度。开源版本只支持两类负载独立推理执行，没有配套的流量拆分、资源弹性编排组件。是否采用分离部署，需要结合自身请求长度分布、并发规模、硬件拓扑测算经济性。

1. 多副本负载均衡与全链路服务治理

线上服务需要处理流量波动、实例宕机、显存资源不均衡，长上下文请求还要单独考量缓存亲和性。这部分和基础设施深度绑定，不在开源交付范围，企业使用 DeepInfer 搭建线上服务，需要对接自研或者第三方服务底座。

简言之，DeepInfer 开放了推理栈里高度专业化的核心执行层，适合有底层研发能力的团队二次定制；想快速上线业务应用的团队，需要审慎评估额外开发和运维成本。

八、DeepInfer 对开发者和 AI 行业意味着什么

DeepInfer 开源的意义，不止新增一个开源仓库，而是把大模型推理工程的核心实现向社区开放。

过去开源模型讨论大多聚焦参数量、评测榜单、权重文件。真实落地场景里，模型能不能低成本、稳定规模化对外服务，取决于推理效率、硬件利用率、调度系统。模型能力定义应用边界，推理基础设施决定交付成本与上限。

开放这套专用推理实现，方便开发者研究算子、并行策略、解码优化；企业也可以借鉴工程经验改造自有推理底座。

对应用开发者分两种路径看待：

自建推理集群的团队，可以把 DeepInfer 作为优化参考；但如果核心业务是开发应用、智能助手、Agent，不一定需要维护 GPU 集群。自建集群有硬件投入，还要持续承担模型升级、监控告警、调度排障、容量规划等运维负担。

这类场景优先选择 API 调用会更轻量化。开发者可以基于 DeepSeek 完成代码分析、文本处理、任务规划，搭配其他模型处理差异化任务。多模型混合开发会遇到多套地址、密钥、异常逻辑管理的麻烦，统一 API 网关可以简化接入流程。星链 API 是面向多模型调用的 API 中转服务，适合开发者整合模型接口，选型前验证模型可用性、兼容性、稳定性。

统一 API 接入和自建推理框架属于不同层级方案：前者简化应用侧调用管理，后者优化模型底层运行效率。即使使用统一接口，底层推理引擎的性能、缓存策略依然会影响最终服务效果。

九、开发者应该如何选择：自部署还是 API 调用？

DeepInfer 的开源把一个经典问题摆到台前：什么时候自建模型，什么时候走 API 调用？

选型核心看业务目标，而不是框架是否开源。

拥有匹配硬件、需要自主掌控运行环境、研究推理优化、离线批量处理的团队，可以评估 DeepInfer；正式落地前，核验硬件兼容、模型加载、性能指标，补齐缺失的服务组件，测算长期算力与人力成本。

开发网站、智能客服、编程工具、Agent 应用的团队，核心诉求是快速落地、调用稳定、灵活切换模型，API 接入可以省去集群运维，重心放在业务逻辑上。

即便多款模型兼容相近接口规范，工具调用格式、结构化输出、上下文上限、异常行为依然存在差异，不能直接无差别互换。

通用选型思路：调用量小、需求迭代快优先 API；调用规模稳定、有专业运维团队、有数据隔离或者私有化硬性要求，再深度评估自部署方案。

结语：大模型普惠，需要把推理工程也纳入开源体系

DeepInfer 的开源，让 DeepSeek 推理体系的核心工程实现走向透明。对比单纯开放模型权重，推理引擎开源给社区提供了算子优化、分布式执行、投机解码、结构化输出的一手研究样本，行业也得以更具象地讨论大模型服务的成本构成。

但技术开放不等于部署门槛消失。当前版本硬件限制严格，仅提供离线推理基础能力，完整的 KV Cache 治理、Prefill/Decode 分离编排、负载均衡都需要额外搭建。评估时既要看到框架本身的技术亮点，也要核算硬件投入、二次开发、长期维护成本。

行业竞争已经从模型本身延伸到完整交付链路：模型架构、推理引擎、算力调度、服务治理、应用接入共同决定模型能不能规模化落地。DeepInfer 开放底层推理能力，星链 API 这类统一接入方案服务不想自建集群的开发者，两套方案互补，分别解决模型运行、应用集成两类问题。

对开发者来说，判断一项推理技术的价值，不在于它是否开源，而在于它在自身硬件、业务负载下，能否带来可复现、可验证的收益。随着 DeepSeek 持续迭代推理代码，围绕推理成本、部署效率、多模型协同的工程实践还会持续演进。