灶台搬出来了，冷库还在屋里：DeepSeek 开源 DeepInfer 的一份清单
DeepSeek 开源生产推理框架 DeepInfer：Apache-2.0，支持 NVIDIA SM100 与昇腾 950，目前只做离线推理、只支持 DeepSeek-V4.1-Flash，KV cache 系统等在线服务组件不在这次发布里。
看一家馆子的真本事，我向来不太看菜单，而是想看后厨。菜单谁都能抄，灶台怎么摆，火候怎么分，客人多的时候怎么出菜，这些才是一家店的底子。所以每当听说哪家馆子要把后厨开放给大家参观，我的第一反应不是激动，而是想先问清楚：开放的是哪一间屋子，哪几口灶，冷库和传菜口在不在里面。这不是挑刺，看热闹和看门道之间，差的往往就是这么一份清单。
10 月 20 日，DeepSeek 在 GitHub 上放出了一个叫 DeepInfer 的项目，许可证是 Apache-2.0。据项目 README，官方称这是支撑其大规模生产服务的推理框架。换句话说，平时大家调用 DeepSeek 服务时，背后转动的那一套机器，这次露出了一部分真身。消息出来，自然有很多人兴奋，觉得这是把看家本领拿出来了。我也觉得这是好事，只是好事更值得慢慢看，看清楚到底拿出来了什么，又有什么还留在屋里没动。
先说拿出来的。README 写得很明白，本次开源提供的是离线推理，目前只支持 DeepSeek-V4.1-Flash 这一个模型，默认 checkpoint 是 DeepSeek-V4.1-Flash-1017。也就是说，它不是一个什么模型都能往里接的通用框架，而是为自家一款模型量身打造的那口灶。这一点最好先放在心上，免得有人兴冲冲拉下代码，想把手头别家的模型塞进去，最后才发现锅和灶根本对不上号。
灶里的东西倒是实打实的。README 列出的组件有 FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect，还有自定义的 TileLang 内核。这一串名字，对外行来说像中药铺抽屉上的标签，对做推理的人来说，却是一门门具体的手艺。照我的粗浅理解，大致是注意力怎么算得省、矩阵乘法怎么算得快、混合专家模型里数据怎么在专家之间搬运，这一层解释是我从名字和常识出发的理解，细节以各项目自己的文档为准。
并行的部分，README 写的是 Attention DP 与 balanced CP，以及 MoE 的 EP 加 EPLB。这些缩写读起来拗口，意思不外乎是把一个大模型的活儿拆给很多张卡去干，还要拆得均匀，别让有的卡忙死、有的卡闲死。干过活的人都知道，分工这件事比干活本身还难，一个班组里最累的往往不是出力最多的人，而是那个排班的人。
接下来是投机解码。DeepInfer 用的是 DSpark 草稿 token 加置信度调度验证，默认最大草稿长度是 5。打个比方，就像后厨里先让一个手快的帮工把几道配菜预先备好，主厨看一眼，对的直接用，不对的退回重做。帮工备多少、主厨什么时候放心收下，就是所谓的调度。这个比方是我自己打的，不是 DeepSeek 的说法，但道理大概不差：让快的先跑，让准的把关。
还有几样，名字听着更冷门。一样是 SWA bounded replay，我在这里只记下名字，不替它多做解释。一样是异步调度，CPU 的调度和设备上的执行彼此重叠，默认就是打开的，相当于切菜和炒菜同时进行，不必等上一道出锅才开始切下一道。另一样是 batch-invariant 推理与确定性采样，README 注明仅限 NVIDIA。照我的理解，大意是同样的输入不会因为和谁拼在同一个批次里而得出不同的结果，这对需要复现实验的人很要紧。最后是结构化输出，支持 regex、JSON schema 和 EBNF 这几种约束方式。
硬件方面，README 列的是 NVIDIA SM100 GPU 和华为昇腾 950 NPU。环境要求是 Linux、GCC 13 及以上、Python 3.12，以及 CUDA 13 或 CANN 9.2。这份清单本身就说明了门槛，这不是一个在家用电脑上随手装来玩的东西。我更在意的是另一层意思：英伟达和昇腾并排出现在同一份 README 的第一屏，作为自家生产框架的支持对象，这本身就是一个信号。至于信号指向哪里，各人有各人的读法，我只当它是一个事实摆在那里。
说完拿出来的，再说没拿出来的，这一部分其实更值得细看。README 坦白交代，要组成一套完整的推理服务，还需要三样东西，而这次都没有包含：一套 KV cache 系统；VE、Prefill、Decode 的分离；以及 prefill 和 decode 两侧在数据并行副本之间的负载均衡。其中第二样，README 加了一句括注，说所需的大部分引擎功能其实已经实现，只是没有放进这次发布。所以，它不是一个开箱即用的在线服务。这句话我愿意多重复一遍，因为这正是兴奋的人最容易略过的那一行小字。
回到馆子的比方。DeepInfer 这次搬出来的，是灶台和刀工，冷库没有搬出来，分区出餐的流水线没有搬出来，几家分店之间怎么调配客流也没有搬出来。离线推理好比提前接好一大批订单，关起门来慢慢做，做完一起交货。在线服务就完全不同了，客人随时推门进来，有人点得多，有人点得少，有人要等，有人等不了，这时候冷库存什么、哪个窗口先出菜、哪家分店接单，才是真正见功夫的地方。这一层对照是我的理解，并非 DeepSeek 的原话。
说到这里，也许有人会觉得扫兴，好像这次开源打了折扣。我倒不这么看。一家公司愿意把生产框架放出来，并且老老实实写明哪些有、哪些没有，这种坦白本身就比含糊其辞的「全面开源」要体面得多。手艺人之间最怕的不是对方藏一手，而是对方说自己什么都没藏，你照着做了半天，才发现差了最关键的一步。
还有一处细节，我读的时候觉得很有意思。README 的致谢里写着，这个框架最初主要基于 vLLM 构建，同时借鉴了 SGLang 和 TensorRT-LLM。在更早的 open-infra-index 仓库里，DeepSeek 说过内部引擎是基于早期 vLLM 的分叉，不便直接开源。如今这件事算是兑现了。从别人的院子里移来一棵树，自己浇水剪枝养了很久，长得已经和原来不太一样，现在再把它的样子拿出来给大家看，同时说清楚这棵树最早是从哪里来的，这是老派手艺人的规矩，也是开源世界里的礼数。
和 DeepInfer 一起发布的，还有一个叫 deepseek-recipe 的东西，作用是对齐官方 API 的分词与反分词行为。这个听上去不起眼，其实很实用。自己部署模型的人常常会遇到一种别扭：同样一句话，自家跑出来的结果和官方接口的结果在切词上有细微差别，日积月累就成了说不清的偏差。把这一层对齐，相当于把调味的配方一并交给你，免得你照着菜谱做，味道却总是差那么一点。这一段的解释同样是我的理解。
那么，这件事到底和谁有关？照我的理解，眼下最直接受益的，大概是这么几类人：手里恰好有 SM100 或者昇腾 950 的团队，需要离线批量跑 DeepSeek-V4.1-Flash 的团队，以及想要研究一套生产级推理框架究竟怎么拼起来的人。对于只想在自己服务器上搭一个对外服务的人来说，它目前更像是一套好零件，而不是一台整车，缺的那几样还得自己补，或者等官方后续再放。
我见过太多人，一听说什么东西开源了，第一句话就是问「链接呢」，好像拉下代码就等于拥有了别人的整套生产能力。事情当真那么简单么？代码能拉下来，卡未必有，环境未必配得齐，缺的那几块更不会自己长出来。开源给的是一个起点，而不是一个终点，看清楚清单再动手，才不会在半路上对着一堆零件发愣。
灶台是灶台，馆子是馆子，句号。
来源：DeepInfer GitHub 仓库 README（2026-10-20）；DeepSeek open-infra-index；The Next Web；Data Phoenix。功能、硬件与缺失项均据 README 原文（Required for a complete inference service (not included in this release)）；README 附有 DeepSeek 自测的性能曲线，暂无第三方复测，本文未引用速度数字；组件的通俗解释与馆子比方为作者理解。