从模型开源到推理框架开源：DeepSeek 正在改变什么？

昨天，《模安局》刚刚解读了一项针对 62 个大模型的研究，讨论模型的开放程度与安全性之间是否存在帕累托前沿。研究试图回答一个长期困扰 AI 行业的问题：模型能否同时实现高度开放与高度安全？

安全与开放能否兼得？62 个大模型的帕累托前沿研究

有意思的是，仅仅一天之后，DeepSeek 就公布了新一轮开源计划。这次，它开放的不是新的模型权重，而是一套支撑自身大规模模型服务的推理框架 DeepInfer。

10 月 20 日，DeepSeek 宣布正式开源内部推理框架 DeepInfer，以及与之配套的 Token 编解码组件 deepseek-recipe。按照官方介绍，DeepInfer 已经用于 DeepSeek-V4.1-Flash 的大规模推理服务，集成了分布式推理、推测解码、高性能算子、异步调度和结构化输出等一系列优化技术，支持英伟达与华为昇腾的特定硬件平台。

在发布公告中，DeepSeek 用一句话表达了自己的初衷：“为善与众行之，为巧与众能之。”

如果说此前开放模型权重，是让更多人有机会拥有先进模型的能力，那么今天开放推理框架，则是在帮助更多人以更高的效率使用这些能力。

不过，当前的开源推理生态已经相当成熟，vLLM、SGLang、TensorRT-LLM 等框架都有广泛应用，个人开发者也能通过 llama.cpp、MLX 等工具在本地运行模型。DeepInfer 的出现究竟有什么独特价值？它会改变现有的推理框架格局吗？当模型的获取与使用成本不断降低，又会给 AI 安全带来哪些值得研究的问题？

这些问题，可能比一次开源发布本身更值得讨论。

一、DeepInfer 究竟开源了什么？

要理解 DeepInfer 的价值，首先需要区分模型和推理框架。

模型训练完成后，我们得到的是一套能够完成语言理解、推理、生成等任务的模型参数。但拥有模型参数，并不意味着就能高效地为大量用户提供服务。

特别是对于参数规模达到数千亿的大模型，即使采用混合专家（MoE）架构，推理过程依然涉及大量计算、显存访问和跨设备通信。当用户请求不断增加时，还要解决模型加载、任务调度、计算资源分配、长上下文缓存等一系列工程问题。

推理框架承担的正是这些工作。

同一个模型，使用不同的推理框架，或者采用不同的并行与调度策略，最终的吞吐量、响应延迟和算力成本可能存在明显差异。因此，模型的能力上限主要由模型本身决定，但先进模型能否以合理成本大规模服务用户，很大程度上取决于背后的推理基础设施。

DeepInfer 就是 DeepSeek 围绕自身模型架构和生产服务需求构建的一套高性能推理系统。从本次公开的代码来看，它的技术价值主要体现在几个方面。

首先是针对大规模 MoE 模型的分布式推理优化。

MoE 模型通常包含大量专家网络，每次推理只会激活其中一部分专家。虽然这降低了单次计算量，却带来了新的问题：不同专家的调用频率可能差异很大，有些 GPU 非常繁忙，另一些 GPU 则处于等待状态。与此同时，专家分布在不同计算设备上，数据还需要频繁跨设备传输。

我们可以把它想象成一个拥有大量专业医生的医院。虽然每个医生都负责不同类型的诊疗，但如果大量患者集中挂某几个专家的号，就会出现部分诊室排长队、其他诊室相对空闲的情况。

对于 MoE 模型来说，这种负载不均衡意味着部分 GPU 的计算能力没有得到充分利用，整个系统的推理速度可能被最繁忙的计算节点限制。

DeepInfer 支持专家并行（EP）、专家负载均衡（EPLB）、注意力数据并行（DP）和上下文并行（CP），并整合 DeepSeek 此前开源的 DeepEP、DeepGEMM、FlashMLA 等高性能组件，尽可能减少推理过程中因通信、计算和负载不均造成的性能损失。

其中，专家负载均衡可以结合专家调用统计和冗余副本等机制，让热门专家的计算负载得到更合理的分配，而不是简单改变模型原有的专家选择逻辑。

第二个值得关注的能力是 DSpark 推测解码。

传统自回归模型通常需要逐个生成 Token。假设模型要输出一句包含 100 个 Token 的回答，它通常需要进行多轮连续解码，每次生成一个新的 Token，再将其作为后续生成的输入。

推测解码尝试改变这一过程：先由相对轻量的预测模块一次生成多个候选 Token，再交给目标模型批量验证。如果预测足够准确，就有机会减少昂贵的模型执行次数。

但这里存在一个问题：一次预测的 Token 越多，并不代表效率一定越高。随着预测距离增加，后续 Token 可能越来越不准确，而验证这些最终被拒绝的预测同样需要计算资源。

DSpark 引入置信度感知的验证调度，根据候选 Token 被接受的可能性动态安排验证工作。

例如，假设预测模块一次生成了 5 个候选 Token，前 3 个具有较高的预测置信度，后 2 个则相对较低。那么系统就可以结合置信度和当前负载，动态决定哪些候选需要进入验证过程，避免不必要的计算。

需要注意，预测置信度是调度依据，并不直接等同于最终验证结果；能否接受候选 Token，仍取决于目标模型的验证过程。

DSpark 的目标并不是让模型生成更聪明的答案，而是在尽可能保持目标模型输出分布正确的前提下，降低生成过程中浪费的计算资源。

这项技术并非今天才首次公开。DeepSeek 已经在今年 7 月发布了相关研究论文，相关思路也已进入 vLLM 生态。此次开源的意义，在于进一步公开其在 DeepSeek 生产推理系统中的具体实现。

此外，DeepInfer 还支持 SWA Bounded Replay、异步调度、批次不变推理和确定性采样。

其中，SWA Bounded Replay 针对特定模型结构，限制部分执行路径中需要重新计算的 Token 范围，减少不必要的重复计算。这里并不是简单丢弃长上下文，而是在保留必要历史状态的前提下，优化特定计算过程。

异步调度则尽可能让 CPU 侧的请求调度与设备侧的模型计算重叠，降低串行等待时间。

批次不变推理和确定性采样也值得关注。它们可以减少不同批次组成和采样随机性带来的输出差异，对于模型行为复现、回归测试以及部分安全评测实验都有实际价值。当然，这不意味着任何硬件和运行环境下都能够得到完全一致的结果。

与 DeepInfer 同步开源的 deepseek-recipe，则解决另一类问题。

企业自主部署模型时，经常会发现一个现象：虽然运行的是同一套模型权重，但本地服务与官方 API 在 Prompt 编码、特殊 Token、思考内容解析、工具调用格式等方面可能存在差异。

deepseek-recipe 提供了统一的协议转换、Prompt 编码与输出解析能力，支持 Chat Completions、Responses、Messages 等接口格式，帮助开发者减少自行适配协议的工作量。需要注意，它本身不负责模型推理和工具执行，也不能单独保证自建服务与官方服务的所有行为完全一致。

从这些能力可以看出，DeepInfer 的价值并不在于提出一个完全不同的大模型推理范式，而在于将 DeepSeek 针对自身模型长期积累的算子、并行计算、推理调度和协议处理经验整合成一套可以公开复用的工程实现。

不过，有一个非常重要的事实容易被“全面开源推理框架”的表述掩盖。

目前公开的 DeepInfer，还不是一套开箱即用的完整在线推理服务系统。

根据官方 GitHub 仓库，截至 10 月 20 日，DeepInfer 主要提供具备大规模服务核心能力的离线推理版本。完整的在线服务还需要 KV Cache 系统、完整的推理阶段分离部署和跨数据并行副本的负载均衡等组件。

它目前正式支持的模型是 DeepSeek-V4.1-Flash，硬件则主要限定于 NVIDIA SM100 GPU 和华为昇腾 950 NPU。

也就是说，普通企业并不能简单下载 DeepInfer，就在现有 GPU 服务器上获得与 DeepSeek 官方相同的推理服务能力。对于具备较强 AI Infra 工程能力的团队，它是一套很有价值的技术实现；但对于普通开发者而言，距离开箱即用仍有一定距离。

二、已经有了 vLLM 和 SGLang，为什么还需要 DeepInfer？

这是评价此次开源价值时，一个无法回避的问题。

如今，大模型推理框架早已不是什么稀缺技术。vLLM 凭借 PagedAttention 等技术建立了广泛的推理服务生态，SGLang 则在推理调度、缓存优化和复杂模型服务方面持续发展，TensorRT-LLM 更是长期围绕 NVIDIA GPU 进行深度性能优化。

在个人与端侧场景，llama.cpp 和 MLX 等工具也已经十分成熟。

这些框架面对的需求不完全相同。vLLM、SGLang 主要服务于 GPU/NPU 服务器及集群推理，llama.cpp 更强调跨硬件兼容和低资源部署，MLX 生态则针对 Apple Silicon 进行优化。

DeepInfer 当前的定位更加明确：为 DeepSeek 自身的大规模模型提供高度定制的推理能力。

更值得注意的是，DeepSeek 在官方 README 中明确表示，DeepInfer 最初主要基于 vLLM 构建，同时借鉴了 SGLang 和 TensorRT-LLM 的设计。

这一点很有意思。

DeepInfer 并不是 DeepSeek 抛开现有开源生态、从零开发的一套竞争性技术体系。相反，它本身就是在已有开源框架基础上不断优化的产物。

这也决定了我们不应该简单地把它理解为“DeepSeek 发布了一个 vLLM 的替代品”。

对于通用推理框架而言，核心挑战之一是兼容性。它需要适配不同厂商的模型架构、硬件平台、量化方案和业务场景，同时持续维护稳定的 API、缓存管理、调度和集群服务能力。

而专用框架可以做出不同的工程取舍。

如果只需要支持特定模型，就可以围绕模型的 Attention 结构、专家分布、计算精度和推测解码方式进行深度优化，不必为大量其他模型的兼容性承担额外复杂度。

这种专用优化在理论上有机会获得更好的性能，但能否形成优势仍然需要实际测试。

DeepSeek 已经在仓库中提供了 Prefill 和 Decode 阶段的性能基准，分别使用 4 张和 64 张 NVIDIA SM100 GPU 进行测试。不过，目前还缺少足够完整的同条件比较，无法据此判断 DeepInfer 相较于 vLLM、SGLang 究竟降低了多少推理成本。

与此同时，vLLM-Ascend 已经提供了 DeepSeek-V4.1-Flash 的部署文档，说明其他框架也正在适配相同模型及相关优化技术。使用 DeepSeek 模型，并不意味着必须使用 DeepInfer。

因此，就现阶段而言，DeepInfer 对现有推理框架的直接竞争冲击可能比较有限。

但它还有另一种潜在影响：技术反哺。

DeepInfer 公开的部分算子优化、调度机制和模型适配实现，可以被其他推理框架研究、移植或重新实现。对于 vLLM、SGLang 这类成熟项目来说，吸收有效的工程优化，往往比让用户整体迁移框架更现实。

这也是开源生态中经常出现的现象。一家公司基于已有开源技术构建自己的生产系统，再将内部优化公开，最终受益的可能不只是这家公司的产品，还包括整个技术社区。

DeepInfer 最终对行业最大的贡献，未必是成为下一个 vLLM，而可能是推动现有推理框架进一步提高性能。

当然，这种影响需要通过后续代码贡献、框架适配和独立性能测试来验证，而不能仅凭开源公告就认定已经发生。

三、从模型权重到推理框架，DeepSeek 正在逐步开放完整技术栈

如果将 DeepInfer 放进 DeepSeek 过去两年的开源历程中观察，会发现它并不是一次孤立的发布。

此前，DeepSeek 已经相继公开了多代模型权重，以及围绕模型训练和推理所需的多种基础组件。

例如，DeepGEMM 面向高性能矩阵计算，DeepEP 主要解决 MoE 模型中的专家并行通信问题，FlashMLA 则针对 MLA 等注意力计算进行优化。TileLang 提供了面向 GPU 等加速器的高性能算子编程能力。

这些组件分别解决大模型计算系统中的不同问题，而 DeepInfer 则进一步将其中的部分能力组织到完整的推理引擎中。

可以把这条技术路线理解为几个逐渐开放的层次。

最初，开放的是模型权重，让开发者能够自主获取和运行模型。

随后，开放的是高性能算子及相关编程工具，让开发者有机会理解模型为何能够高效计算，以及如何在不同硬件上实现这些计算。

如今，进一步开放的是推理引擎，使开发者能够研究模型如何在大规模计算集群中完成并行计算、调度与生成。

再加上 deepseek-recipe 提供的协议处理能力，DeepSeek 正在将更多原本隐藏在模型服务背后的工程实现公开出来。

这意味着，开源的对象正在从模型本身，延伸到支撑模型运行的技术基础设施。

不过，完整技术栈的逐步开放，并不等于 DeepSeek 已经公开了全部模型研发过程和生产系统。

例如，此次发布并不包含完整的在线服务组件。模型的训练数据、训练流程、内部运营系统等，也需要根据各自实际公开情况分别判断。不能因为推理框架开源，就认为模型开发和服务过程的所有环节都已经透明。

即便如此，这种开放仍然具有重要意义。

对于云厂商和大型企业而言，它降低了研究高性能推理架构的技术门槛。对于研究人员而言，它提供了观察真实大规模模型推理工程的机会。对于其他推理框架而言，它增加了能够借鉴和复现的实现方案。

从产业竞争角度看，这可能促进开源模型生态与商业闭源服务之间的进一步竞争。

过去，先进模型服务的竞争优势既来自模型本身，也来自隐藏在背后的推理工程能力。随着越来越多高性能推理技术公开，部分原本由少数厂商掌握的工程知识会逐渐扩散。

当然，掌握实现方案不等于具备相同的部署能力。硬件资源、运维经验、系统集成和服务规模仍然是重要门槛。

但至少有一点正在变得清晰：大模型开源的竞争，已经不再局限于模型参数和能力表现，而是逐渐延伸到整个计算与服务体系。

四、从模型开放到能力普惠，AI 安全需要关注什么？

回到文章开头提到的那个巧合。

昨天，我们还在讨论一项针对 62 个大模型的研究。论文尝试通过开放性与安全性两个维度，寻找模型之间的帕累托前沿，并讨论更加开放的模型能否同时维持较高的安全水平。

其中一个重要争议在于，开放权重模型允许使用者直接修改模型参数，也更容易移除或改变原有的安全对齐机制。因此，模型的开放程度不仅是一项技术属性，也可能影响其发布后的滥用与扩散风险。

但今天的 DeepInfer 提醒我们，模型开放所带来的安全问题，或许不能只从模型本身来理解。

假设存在两个能力和安全表现完全相同的开放权重模型。一个拥有成熟的推理生态，能够以较低成本在多种硬件上部署；另一个则缺少高效的推理实现，需要复杂且昂贵的计算基础设施。

即便两者在模型开放性指数和模型安全评测中获得相似的分数，它们在现实世界中的可获得性与扩散规模，也可能存在明显差异。

换句话说，模型本身的开放程度，与模型能力在现实世界中的可获得程度，并不是完全相同的概念。

而且，模型开放通常是一次明确的发布行为，能力可获得性却可能随着时间持续变化。

一个模型在发布时可能因为部署成本过高，只能被少数机构使用。即便其权重和安全对齐完全没有变化，随着硬件性能提升、量化技术发展、推理框架优化，其部署成本也可能逐渐下降。

这意味着，模型在某个时间点的安全评价，不一定能够完整描述其未来在整个生态系统中的风险。

不过，需要对 DeepInfer 本次开源的安全影响保持克制。

目前，vLLM、SGLang 等开源推理框架已经非常成熟，企业和个人早就可以自主部署开放权重模型。DeepInfer 并没有首次创造私有化部署的能力，也没有直接提升模型的危险能力。

同时，它当前支持的模型和硬件范围有限，完整在线服务组件尚未全部公开，也缺乏与其他框架在相同条件下的完整成本对比。

因此，现阶段并没有充分证据表明，DeepInfer 的发布已经显著降低了恶意使用者的模型部署成本，或者导致 AI 滥用风险明显增加。

这里还需要区分一个经常被混在一起讨论的问题：推理框架作为软件基础设施，自然也会面临第三方依赖漏洞、恶意代码、组件更新和供应链完整性等安全风险。但这些属于已经相当成熟的软件供应链安全范畴，在 AI 系统中同样需要通过依赖管理、组件审计、漏洞扫描和软件物料清单等方法治理，并不是 DeepInfer 开源所创造的新风险类型。

因此，如果要研究此次开源对 AI 安全的新增影响，重点不应是再次证明开源组件可能存在漏洞，而应当关注推理技术进步是否改变了先进模型能力的部署成本、可获得性与使用规模。

如果把整个开源推理生态长期发展所产生的潜在风险，直接归因于 DeepInfer 的这一次发布，反而容易高估它的实际影响。

但从长期研究角度看，推理效率与 AI 安全之间的关系仍然值得关注。

过去，大模型安全评测往往聚焦模型能否生成危险内容、是否容易被越狱、是否能够完成特定高风险任务。这些指标主要反映模型的行为倾向和能力水平。

而在实际应用中，风险还受到另一个因素影响：这些能力能够以什么样的成本、频率和规模被使用。

对于普通问答服务，推理成本下降意味着用户可以用更低的价格获得模型服务。对于具备自主规划和工具执行能力的 Agent，成本下降则可能支持更多轮次的推理、更长时间的运行以及更多自动化任务。

这些变化既可能提高正常业务的生产效率，也可能增加恶意使用者能够组织的自动化活动。

不过，推理效率提升并不意味着现实危害一定同比增加。模型本身是否具有相关能力、实际任务是否存在其他瓶颈、使用者是否具备必要资源，以及是否部署了有效的安全控制，都会影响最终结果。

而且，推理成本下降同样能够帮助防御者。

更廉价的模型推理可以支持更大规模的安全测试、更多红蓝对抗实验，以及更低成本的内容审核与行为监测。部分可复现性优化，也有利于研究人员比较不同模型版本和安全策略的效果。

因此，真正需要研究的不是“推理框架开源是否必然增加风险”，而是：

在模型能力基本不变的情况下，推理技术进步究竟会怎样改变先进 AI 能力的扩散速度、使用规模，以及相应的安全治理效果？

这个问题，目前还缺乏充分的系统性研究。

五、当推理生态不断成熟，AI 安全评测可能需要增加新的维度

如果进一步思考这个问题，会发现传统模型安全评测存在一个值得补充的视角。

同样一个模型，在官方 API、云厂商托管服务以及企业自行部署的环境中，可能具有不同的安全表现。

虽然它们使用相同的基础模型权重，但不同服务可能采用不同的安全对齐版本、外部护栏、内容审核策略、工具权限与访问控制机制。

更重要的是，各个部署者的安全治理能力并不相同。

部分企业可能拥有完善的日志审计、内容安全检测、访问控制和异常行为监测体系；也有一些部署者可能只关注模型能否正常运行，缺乏必要的安全防护。

这意味着，评估一个模型是否安全，与评估一个实际部署的 AI 服务是否安全，是两个相关但不同的问题。

从这个角度看，未来的 AI 安全评测至少需要进一步考虑三个方面。

首先是模型能力风险，即模型是否具有某种危险能力，以及现有安全对齐能否有效约束这些能力。

其次是能力扩散条件，即模型部署需要多少算力、工程能力和运行成本，有多少主体能够实际获得并规模化使用这些能力。

最后是部署后的治理能力，包括模型服务是否具有必要的安全控制、异常行为监测、调用审计以及风险干预手段。

这并不意味着需要抛弃现有的模型安全基准，而是应当明确它们的适用边界。

昨天那篇关于安全与开放帕累托前沿的论文，主要帮助我们观察模型开放性与模型安全属性之间的关系。但如果要进一步讨论开放模型的国际治理与现实滥用风险，就可能还需要结合部署成本、使用规模和治理条件进行分析。

DeepInfer 为这种思考提供了一个很好的切入点，但它并不是已经证明某种安全风险发生变化的实验证据。

未来，或许可以在固定模型能力和评测任务的条件下，研究推理基础设施优化前后的单位任务成本、有效吞吐、风险任务成功率及安全控制效果，进一步判断推理效率变化如何影响实际风险。

特别值得关注的是，安全护栏自身也会产生额外的推理与检测开销。当底层推理技术变得更加高效时，这些优化究竟会更多地促进模型使用，还是同样降低安全防护成本，也是一个值得研究的问题。

换个角度说，推理性能的提升可能同时改变攻击者和防御者的成本结构。最终表现为风险增加还是安全改善，并不取决于推理效率本身，而取决于双方如何利用这些能力，以及整个系统是否具备有效的安全治理机制。

六、DeepInfer 的真正意义，可能需要更长时间才能显现

回到今天的发布，我认为对 DeepInfer 最合理的评价，既不是“推理框架领域即将重新洗牌”，也不是“开放 AI 的安全风险将因此大幅增加”。

它首先是一次具有实际工程价值的开源。

DeepSeek 把支撑自身大规模模型服务的部分核心推理技术公开，为研究者和开发者提供了一套经过生产实践的实现方案。虽然当前公开范围仍然有限，但对于研究超大规模 MoE 模型的推理优化，具有明确的参考价值。

至于它能否改变现有推理框架格局，还需要观察几个关键问题。

未来 DeepSeek 是否会持续把新模型的推理优化优先发布到 DeepInfer？它是否会逐步支持更多硬件和模型架构？vLLM、SGLang 等成熟框架又会在多大程度上吸收这些技术？

这些问题的答案，将决定 DeepInfer 最终成为一个主要服务 DeepSeek 自身的高性能参考实现，还是逐步发展为具有广泛适用性的推理框架。

而从更长期的视角看，这次发布所反映的行业变化或许更加重要。

模型权重、计算算子、编译工具、推理引擎正在逐渐形成更加完整的开放技术生态。先进 AI 能力的普及，不仅取决于模型研发取得多大突破，也取决于围绕模型的计算基础设施能够以多快的速度降低技术与经济门槛。

这会促进更多创新，也会让 AI 安全治理面对更加复杂的部署环境。

昨天，我们讨论的是模型的开放性与安全性之间是否存在帕累托前沿。今天，DeepSeek 又向开源社区开放了一部分支撑先进模型大规模运行的工程能力。

这两件事之间的巧合，恰好揭示了一个容易被忽略的事实：

模型的安全能力可以保持不变，但随着推理技术和部署生态持续进步，这些能力在现实世界中的可获得性、使用规模和治理条件仍然可能不断变化。

因此，模型开放与安全之间的关系，可能并不是一张静态的二维图就能完整描述的。

DeepInfer 本身并没有给出这个问题的答案。但随着大模型技术从模型开放逐渐走向基础设施开放，这个问题或许会变得越来越重要。

参考资料

DeepSeek，DeepInfer 官方开源仓库：https://github.com/deepseek-ai/DeepInfer

DeepSeek，deepseek-recipe 官方开源仓库：https://github.com/deepseek-ai/deepseek-recipe

DeepSeek，DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation：https://arxiv.org/abs/2607.05147

vLLM-Ascend，DeepSeek-V4.1-Flash 部署文档：https://docs.vllm.ai/projects/ascend/en/latest/tutorials/models/DeepSeek-V4.1-Flash.html

DeepSeek，开源项目列表：https://github.com/deepseek-ai

本文基于截至 2026 年 10 月 20 日公开的技术资料撰写。文中对行业格局及 AI 安全影响的判断属于分析与展望，不代表相关影响已经得到实证验证。