DeepSeek在10月20日发布了DeepInfer，这是它自研的推理框架。发布的是引擎，不是一整套服务。当前代码仓库标注的支持模型是DeepSeek-V4.1-Flash，与早前的Flash检查点更新是两回事。

打开网易新闻 查看精彩图片

判断它能不能拿来做私有部署，先别急着看性能图表。发布说明里真正有用的一句话很容易被略过：公开代码提供的是离线推理，一套完整的服务还需要引擎之外的东西。

引擎之外缺了什么

README列出的能力包括优化内核、分布式执行、投机解码、异步调度和结构化输出，支持NVIDIA SM100 GPU和华为昇腾950 NPU。

紧接着它点名了缺失的服务组件：KV缓存系统；视觉编码器、预填充与解码的分离部署；以及数据并行副本之间的负载均衡。

这几个词值得拆开看。KV缓存保存注意力状态，让生成过程复用前面的计算；预填充处理提示词，解码生成后续内容；分离部署则是把这两个阶段放到各自管理的资源上。一个跑得快的执行引擎，仍然需要一个系统把请求和状态送进送出。

所以做部署决策时，该问的是：缓存状态归谁管，请求被路由到哪里，两个阶段之间的容量怎么分配。这些架构问题，发布说明明确留给了外围服务。

“同一个种子”不是完整的复现说明

固定随机种子是常见的调试习惯。DeepInfer文档里的确定性采样配方要求更多：开启批不变推理、关闭变长投机解码、传入固定的seq_seed。README标注这条路径仅限NVIDIA。

为什么要关心批次？同一个请求在不同次运行中，可能和不同的邻居共享执行。如果要对比两次回答，除了采样设置，还得记录批处理行为。只写一个种子，对运行条件的描述是不完整的。

离线示例把区别摆得很具体：它在NVIDIA路径上开启了批不变性，但这只是源码层面的检查，并不等于一次经过验证的确定性运行。

容易踩的坑就在这里：把一个种子抄进报告，然后默认运行时其余部分都是固定的。

吞吐数字下面看单位

基准测试文档把预填充吞吐、每秒解码步数和解码吞吐分开列出，它们回答的是不同问题。

其中解码吞吐的核算假设草稿token被全部接受。报告里的计算用到步率、请求数、草稿长度和上下文并行规模，文档明确说明这套核算与真实接受率无关。

因此这个字段不能直接读成“任意应用请求多快跑完”。把吞吐数字带进容量估算之前，先看草稿接受率和对应的配置。

文档还有一条提醒：性能分析器的步耗时用于检查内核构成，稳态测量则在另一个窗口进行；扫描时关闭性能分析，因为它会干扰计时。一张色彩丰富的追踪图很适合用来找活干，用来估速度可能是错的输入。

怎么读这次发布

对引擎贡献者来说，价值在于可检视的运行时代码和示例。对服务负责人来说，价值是一个具体的起点，以及一条看得见的集成边界。

实际动手的顺序：先核对支持的加速器和检查点，再跑通离线示例及其校验检查。示例在显式请求时可以检查结构化输出和正常终止，也会保留回归基线，而不是把看起来合理的回答当成验证通过。

这是有用的工程材料。它不替代外围服务的搭建，也不替代针对自己负载的实测。

以上是基于所检视版本号的源码分析。没有下载权重，没有运行推理，也没有复现性能图表。那张示意图解释的是公开范围，不是部署结果。