你已经训练好一个模型，却不等于它能顺畅接待用户。就像餐厅有了菜谱和厨师，还得安排灶台、分配订单、控制出菜节奏。推理框架做的正是这层工作：把训练好的模型高效跑起来，管理并行计算、请求调度和文本生成，直接影响上线后的速度、成本与稳定性。
DeepSeek此次开源的DeepInfer，就是面向自家模型的这层“生产底座”。官方称，它支撑DeepSeek的大规模生产服务。不过，公开版本目前主要提供离线推理，并不是下载后便能搭起完整在线服务。本文涉及的功能与性能定位均来自DeepSeek的GitHub仓库，尚无独立测评交叉验证。
打开的不是整座机房，而是一扇观察窗
DeepInfer当前列出的支持模型是DeepSeek-V4.1-Flash，首次运行默认下载的checkpoint——也就是保存模型参数的文件——则是deepseek-ai/DeepSeek-V4.1-Flash-1017。这两个名称的粒度并不完全相同：前者是支持的模型系列，后者是默认使用的具体版本。
故事的时间线也值得注意。据DeepSeek官网和DeepInfer GitHub的部署问答，DeepSeek在2026年9月发布V4.1-Flash时，只表示会与开源社区合作适配推理，并探索更多部署方式。一个多月后，DeepInfer才作为这项承诺的兑现出现。
但它没有把内部服务系统原样搬出来。完整在线推理仍需要三块公开版本未包含的能力：KV cache系统、Prefill与Decode解耦，以及数据并行副本之间的负载均衡。
KV cache可以理解为模型生成文字时留下的“计算草稿”，有了它，模型不必反复重算前文。Prefill是先读完输入并建立这些中间结果，Decode则是随后逐步生成新词；把两者拆开，可以分别安排资源。负载均衡则像给多个窗口分流，避免一个窗口排长队，另一个却闲着。官方解释，这些部分与内部基础设施绑定较深，因此此次没有完整开放。
它把哪些“秘方”放了出来？
DeepInfer公开的重点，是模型如何在多张加速卡上协同运行，以及如何减少生成过程中的浪费。
它支持Attention DP与balanced CP两类并行方式，也支持MoE EP与EPLB。MoE是“混合专家”模型：每次计算只调用一部分专家子网络；专家并行则把这些专家分散到不同加速卡上。EPLB负责平衡专家负载，避免少数卡过忙。对外行来说，关键不在缩写本身，而在于DeepInfer公开了DeepSeek如何编排这类复杂模型的部分工程路径。
另一组能力围绕推测解码展开。推测解码会先用较便宜的草稿机制猜出多个token——模型处理文本时使用的基本片段——再交给主模型批量验收。猜得准，就能减少主模型逐词生成的次数。DeepInfer提供DSpark与confidence-scheduled verification：利用置信度决定何时验证草稿，默认最大草稿长度为5。它还提供SWA bounded replay，只重放一个长度受限的后缀，以减少解码器在Prefill阶段的工作；默认V4.1设置保留140个token，但保留范围必须覆盖SWA窗口与最大回溯长度。SWA可理解为滑动窗口注意力，即模型只重点查看附近一段上下文。
调度方面，异步调度默认开启，让CPU准备下一批任务时，加速卡继续执行当前计算。仓库把它称为“zero-overhead batch scheduler”，但这属于官方自我评价，目前没有第三方数据证明其开销为零。
不只求快，也在管“输出是否听话”
DeepInfer还提供batch-invariant inference与确定性采样。前者要求同一个输入不因被分到不同批次、或与不同请求同行而改变结果；后者要求相同输入token、采样参数和固定随机种子产生相同输出。这两项目前都标注仅支持NVIDIA，其中确定性采样还要求关闭可变长度的多token草稿机制。
这对复现、评测和排查问题很有价值。否则，同一个请求只是换了一批“同行者”，答案就可能变化，很难判断差异究竟来自模型、参数还是运行系统。
结构化输出则解决另一类现实问题：它能约束模型严格按照正则表达式、JSON schema或EBNF grammar生成内容。JSON schema规定字段与类型，EBNF是一套描述语法规则的形式。这样一来，Agent或业务程序可以直接读取结果，不必再从一段自由文本里猜哪个字段是日期、金额或操作指令。
底层计算部分，DeepInfer集成FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect和自定义TileLang kernels。kernel是直接在加速设备上执行的计算单元。这份名单说明公开项目组合了多套针对注意力、矩阵计算、专家通信与选择等环节的优化组件，但现有材料不足以判断每一项分别贡献了多少性能。
为什么值得关注？
DeepInfer的意义，不只是又多了一个推理项目。它处在模型权重与对外服务之间：社区过去拿到模型后，还要自行推断怎样才能把它高效跑起来；现在则能直接观察DeepSeek为自家模型选择了哪些并行、调度、推测解码和输出约束方案。
它也明确承认自己的技术来源：项目最初主要建立在vLLM之上，同时借鉴SGLang与TensorRT-LLM，并采用Apache License 2.0发布。换句话说，DeepInfer既可能把DeepSeek内部积累带回开源生态，也延续了开源推理引擎彼此吸收的路线。
局限与未知
- 公开版本主要面向离线推理，缺少完整在线服务所需的KV cache、Prefill/Decode解耦和跨数据并行副本负载均衡，不能把“生产底座”误读成开箱即用的完整服务。
- 硬件范围很窄：目前列出的支持对象是NVIDIA SM100 GPU和Huawei Ascend 950 NPU；环境要求包括Linux、GCC 13或更高版本、Python 3.12，以及对应平台的CUDA 13或CANN 9.2。
- 仓库称基准测试的Prefill使用4张SM100 GPU，Decode使用64张SM100 GPU，且分别位于一个scale-up domain内；但供稿没有给出吞吐、延迟或加速比，因此无法据此判断它是否领先其他框架。