10月20日，DeepSeek公开了推理框架DeepInfer。按照项目介绍，它是DeepSeek大规模生产服务使用的高性能推理框架；本次开放了离线推理核心，采用Apache-2.0许可证，并支持DeepSeek-V4.1-Flash模型。
如果说模型权重决定了AI具备什么能力，那么推理引擎就在很大程度上影响这些能力怎样运行、怎样分配计算资源，以及一套设备能同时服务多少请求。
更引人注意的是，DeepInfer将英伟达SM100 GPU和华为昇腾950 NPU列入支持范围。除了模型执行，它还公开了MoE专家并行、推测解码、异步调度等一系列底层优化。
但开源推理引擎，距离直接搭出一个完整的DeepSeek在线服务，还有多远？这次真正值得看的，不只是代码开放了多少，还有它明确留下了哪些边界。
01｜DeepSeek开源了什么？不只是让模型“跑起来”
大模型开源时，大家往往首先关心权重有没有开放。但获得权重，只是运行模型的起点。
当一个用户提问时，系统需要处理输入、安排显卡计算、保存中间状态，再逐步生成回答。当同时有成千上万条请求进入，如何分配设备、减少空等、控制显存与通信开销，就变成了另一套工程问题。
DeepInfer公开的，正是其中的核心执行部分：模型和采样器运行时、优化算子、并行计算策略，以及解码和调度方面的实现。
目前官方列出的支持模型是DeepSeek-V4.1-Flash，离线示例默认使用Flash-1017检查点。它不是一套已经声明支持所有DeepSeek模型的通用部署工具。
官方也很明确：这次开放的是离线推理能力及规模化服务需要的部分核心功能，并不是一套现成的完整在线API服务。
还缺什么？主要有三块：负责大规模状态管理的KV缓存系统，将视觉编码、输入预填充和输出解码拆开调度的服务编排，以及不同计算副本之间的负载均衡。
举个例子，离线运行可以提前准备好一批问题，让模型依次处理；但真实在线服务里，有人发来长文档，有人只问一句话，有人中途取消请求，还有人不断追问。系统不仅要算得快，还要随时决定谁先运行、缓存放在哪里、哪个节点接手新请求。
DeepInfer让外部开发者能够研究和改造这台“发动机”，但还没有把围绕它的整套服务系统一起交出来。
02｜同时支持英伟达和昇腾，底层做了哪些优化？
DeepInfer最值得关注的一部分，是它如何组织多张加速卡共同运行大型MoE模型。
MoE可以理解为把模型内部的一部分计算分给不同“专家”。每次处理Token时，通常只激活其中一部分专家，而不是让所有专家一起工作。
问题是，专家可能分布在不同设备上。数据要先送到对应专家，算完再收集回来；如果某些专家特别忙、其他专家却闲着，整体速度仍然会被拖慢。
因此，DeepInfer不仅提供专家并行，还包含专家负载均衡。配合注意力数据并行、上下文并行，以及DeepEP等通信组件，让不同计算工作尽量合理地分散到设备上。
它还整合了FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect及自定义TileLang内核。这些优化针对的并不完全是同一个瓶颈：有的处理计算效率，有的处理数据搬运，有的处理专家间通信。
这也解释了为什么大模型部署不能只看单张显卡的算力。一套多卡系统到底快不快，既取决于每张卡算得多快，也取决于卡与卡之间能否高效配合。
硬件支持范围同样要看清。官方列出英伟达SM100与华为昇腾950，对应软件环境分别涉及CUDA 13和CANN 9.2，并要求Linux、Python 3.12等环境。
这并不意味着所有英伟达显卡、所有昇腾型号或个人电脑都能直接运行。尤其需要注意，官方本次公布的主要性能曲线使用的是SM100，并没有同时给出昇腾950在同等条件下的对照成绩。
03｜性能到底怎么样？一组数据说明吞吐与体验的区别
DeepSeek公开了两张性能曲线，一张测预填充（Prefill），一张测解码（Decode）。
预填充，可以粗略理解为模型先读取和处理输入材料；解码则是继续生成回答。两者的计算特点不同，适合的设备配置也可能不同。
本次官方测试中，预填充使用4张SM100 GPU，解码使用64张SM100 GPU，两组测试都采用131072 Token上下文，并分别在各自的单一高速互联域内运行。
因此，不能把两张图理解为“同一套4卡机器前后两阶段的性能”，也不能把两张曲线的峰值简单相加，得到完整服务的吞吐。
更有意思的是解码曲线展示的取舍。
按照第三方对官方图表坐标的近似读取：当每个数据并行副本承接约8个并发请求时，单GPU输出吞吐约为每秒2600 Token，单用户速度约为每秒325 Token；并发提高到约256个请求时，单GPU总吞吐可接近每秒26000 Token，但单用户速度降至约每秒103 Token。
这些是从官方图表读取的约数，不是仓库逐点列出的精确成绩。该曲线还采用了固定的推测解码配置，并按75%的草稿接受率作了换算。
不过，这组数据揭示了一个很现实的问题：让一张卡同时服务更多用户，可以明显提高总体产出，却不一定让每位用户得到更快的回答。
对于云服务商，这可能意味着更高的设备利用率；对于强调即时响应的产品，还需要在并发量和单用户速度之间找平衡。
测试条件还有一处容易混淆：示例基准脚本默认上下文长度为32768 Token，未缓存后缀为4096 Token；而上述主要性能曲线使用的是131072 Token上下文。前者属于脚本默认配置，后者是公开曲线的运行条件，不能混成一组数据。
同样，基准测试里构造了大量可复用的共享前缀，不代表真实用户的请求天然就有相同的缓存命中率。
所以，这次性能图可以说明DeepInfer在特定硬件、上下文和并发配置下的运行表现，还不足以证明它相对vLLM、SGLang等框架快多少，更不能直接推算出实际API成本降低了多少。
04｜推测解码、缓存和调度，究竟怎样让推理更快？
除了并行计算，DeepInfer还公开了几项针对生成过程的优化。它们的共同目标，是减少等待和重复工作。
先说推测解码。
传统生成过程往往需要一次次推进，而推测解码会先提出一小段候选Token，再由验证过程决定哪些可以接受。假设系统提前准备了5个候选Token，如果验证后大部分都能使用，一轮计算就有机会推进更多内容；如果频繁被拒绝，提前准备候选本身反而会消耗资源。
DeepInfer提供DSpark及基于置信度的验证调度，默认最大草稿长度为5。但“最多准备5个草稿Token”不等于“速度提高5倍”，实际收益取决于接受率和验证成本。
官方性能脚本在默认64个请求、最大5个草稿Token的情况下，会按“全部接受”的理想口径计算出每步384个Token。这个数字是统计假设，不是实际每轮都成功输出384个有效Token。公开的主要解码曲线另采用3个草稿Token和75%接受率的设置。
第二项是减少重复计算。
模型处理长上下文时，有些中间状态可以复用。DeepInfer提供针对滑动窗口注意力的有限回放优化，在特定配置下只重新处理必要的一小段后缀，V4.1默认相关保留配置为140 Token。
这里的140 Token不是模型上下文上限，而是某条执行路径中的局部回放范围。它减少的是特定场景下的重复工作，不能直接理解成模型只需要看140个Token。
第三项是异步调度。
设备执行当前批次时，CPU可以提前准备下一批任务，尽量让准备工作和计算重叠，减少设备闲置。DeepInfer还支持批次不变推理和确定性采样，方便开发者在请求批次变化时复现模型行为；这些确定性相关能力，官方目前限定在NVIDIA路径。
这些技术名称听起来各不相同，但背后其实是同一个思路：让计算设备少等待、少做重复计算，把更多时间用在有效生成上。
05｜核心引擎开源之后，离真正落地还有多远？
推理框架能跑得快，还需要证明优化没有破坏模型输出质量。
DeepInfer因此也提供了AIME 2026、GPQA Diamond和HLE等评估脚本。官方评估文档给出的DeepSeek-V4.1模型参考Pass@1结果分别为：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
这里的Pass@1衡量单次作答的正确表现。AIME每题默认采样32次，是为了汇总多次单次作答的结果，而不是32次里答对一次就算成功。上述成绩也属于指定模型与评估配置下的参考值，不能据此说DeepInfer比其他推理框架准确率更高。
对于准备自部署的开发团队，DeepInfer的实际价值有两个层次。
第一，能够直接检查DeepSeek公开的模型执行、并行策略与解码优化实现，而不是仅凭外部宣传猜测其推理工程怎么做。
第二，可以在适配的硬件上复现实验、调整配置，研究吞吐、延迟、结果一致性之间的取舍。DeepInfer采用Apache-2.0许可证，也为后续工程整合提供了较为宽松的代码使用条件。
不过，它目前仍然更适合具备多卡计算环境和推理工程能力的团队，而不是一个下载后即可运行的普通用户应用。完整上线还要解决KV缓存管理、分离式服务编排和副本负载均衡，并继续评估长期运行的稳定性、成本和故障恢复能力。
DeepInfer项目也并非凭空从零开始。DeepSeek在仓库中说明，它最初主要基于vLLM构建，并借鉴了SGLang、TensorRT-LLM的设计。这次开源更像是把DeepSeek自己的模型适配和工程优化，进一步公开给社区研究与使用。
过去谈大模型开源，我们更多关注模型权重是否开放。但真正让一个大型模型长期、稳定、低成本地服务大量用户，执行引擎和外围系统同样重要。
一个模型“能运行”，和一个模型“能高效、稳定、大规模地提供服务”，始终是两回事。
DeepInfer这次开放的，正是连接两者的关键一环。它没有交出完整的在线服务，却让更多开发者有机会看清：大型模型在真实计算设备上，究竟是怎样被组织起来、怎样减少浪费，又怎样在性能与成本之间做出取舍。
这可能比单独公布一个更高的推理速度数字，更值得长期关注。