开源的是一套离线推理框架，不是完整的线上服务
10月20日，DeepSeek将其内部推理框架DeepInfer全面开源，采用Apache 2.0许可，同步放出了Token编解码组件deepseek-recipe（MIT许可）。目前开源的版本只支持DeepSeek-V4.1-Flash，定位是离线推理，包含在生产环境中验证过的核心调度与算子能力。
DeepSeek在README里用一行标题明确列出了“本版本不含”的内容：KV缓存系统、Prefill与Decode的分离调度，以及跨数据并行副本的负载均衡。官方给出的解释是，这三部分与内部基础设施耦合过深，尚未完整开源。换句话说，开源的是算法层的骨架，让这套系统在DeepSeek自家集群上日处理155万亿Token的缓存与调度基础设施，并没有随代码一起交出来。
155万亿Token/天：一组自报的生产数据
DeepSeek公布的数据集中在一条时间线上：单集群日吞吐155万亿Token，平均每请求输入77K Token，首字延迟（TTFT）平均400ms、P99为1000ms，Decode阶段生成速度230 Token/s，代码场景可达300 Token/s。Prefill侧在不计缓存命中时每卡吞吐60K Token/s，计入缓存命中后升至1.5M Token/s，提升25倍；平均输入缓存命中率96%。
这些数字需要带一个限定条件：它们来自DeepSeek自己的线上统计，目前没有第三方独立复现。GitHub仓库的性能部分只放了吞吐与延迟的Pareto曲线图，测试配置为4张SM100 GPU做Prefill、64张做Decode，没有给出可直接对比的数值表格。复现脚本是公开的，但外部验证的结果尚未出现。
架构的核心：把两件不同的事拆开，再让缓存替掉重复计算
DeepInfer在架构上最值得注意的一点，是它把推理的两个阶段当作两种不同的工作负载来处理。Prefill阶段要一次读完系统提示、对话历史和上传文件，计算强度高，拼的是算力；Decode阶段逐个Token生成，大部分时间花在从显存读取参数和缓存上，拼的是带宽。DeepSeek的部署方式是：Prefill放在常见的8卡服务器上，Decode放在64至128卡的超节点上，最小部署单元为64卡Prefill加64卡Decode。视觉编码器也被独立部署，不与文本推理混在同一组资源里。
缓存是另一条主线。在Agent场景中，每一轮工具调用都会把系统提示、工具说明和历史结果重新发一遍，其中绝大部分在上一轮已经计算过。DeepInfer的做法是将KV缓存保留在约100PiB的3FS全闪集群中，不活跃缓存的保存时间为72小时；下一轮请求只要前缀从第一个Token起完全一致，新增部分才需要重新计算。96%的输入命中率，就是这套机制在真实流量下的结果。
推测解码与有界重放：两个省计算的细节
DSpark推测解码用草稿Token加速生成，并根据置信度估计动态调度验证时机，最大草稿长度默认为5。SWA Bounded Replay则针对滑动窗口注意力做了一处很具体的优化：Decode阶段不再重放整个窗口，只重放一个有界后缀，V4.1的默认配置保留140个Token，保留长度需要覆盖SWA窗口加最大回溯长度。这两项优化的共同逻辑是，把计算集中在真正新增的信息上，而不是反复处理已经算过的内容。
谁现在能用，支持什么硬件
开源版本要求Linux环境、GCC 13.0及以上、Python 3.12，GPU侧需要CUDA 13，昇腾侧需要CANN 9.2。支持的硬件为NVIDIA SM100（Blackwell）和华为昇腾950两种平台。
对于已经在用vLLM部署DeepSeek模型的团队，DeepInfer的定位更像一个“官方调优参考”：它最初基于vLLM搭建，也借鉴了SGLang和TensorRT-LLM的思路，但只支持DeepSeek-V4.1-Flash这一款模型，与通用推理引擎覆盖数百个模型的路线不同。
（素材来自：DeepSeek 智算芯能前沿网综合）
本文由智算芯能前沿网编辑整理，转载请注明出处。