先看证据

V4.1-Flash当前支持 1 个模型
模型卡上下文 1M；性能图测试上下文 131,072关键事实
Prefill 4 张、Decode 64 张 SM100测试配置
特定配置下声称超过 25,000 输出 token/s/GPU关键事实
DSpark 每轮提议 5 token，验证量约少 30%关键事实
SWA 命中时重算末尾 128 token关键事实

把机制串起来

输入先把素材压到可处理的规模

推理分为 Prefill（处理输入上下文）和 Decode（逐 token 生成），两者的计算特征不同，所以常会采用不同并行策略或分开部署。MoE 模型每层只激活部分专家，EP（专家并行）把专家分布到多张卡上；Attention DP 则让不同数据副本各自处理注意力计算。推测解码让小草稿模型先提议 token，再由目标模型验证，关键在于减少验证开销，而不改变目标模型的输出分布。

机制再把计算集中到关键步骤

底层由 FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect 和 TileLang 内核组成，上层负责模型运行时、采样及并行调度；这样做是为了让算子优化与整机执行策略协同，而不只是提供一组孤立内核。注意力采用 DP，MoE 层采用 EP 与 EPLB；部署问答称 Decode 可在超节点内使用 EP64–EP128，而 Prefill 通常选满足显存要求的较小 EP2–EP8，以适应两阶段的资源特征。DSpark 让草稿模型每轮提出

结果最后落到可验证的工作结果

['先按 README 的 SM100 或 Ascend 950 环境验证构建', '按 Prefill 与 Decode 分开测量，勿把两阶段吞吐混为一谈', '适合研究 V4.1-Flash 离线推理；不适合直接替代完整线上服务', '跨批次确定性与批次不变能力目前仅支持 NVIDIA']

开源的是生产引擎的一层

DeepSeek开源了DeepInfer，这是支撑其DeepSeek-V4.1-Flash生产服务的推理框架，采用Apache 2.0许可，当前发布范围面向离线推理。它把模型运行时、采样器、推理内核和并行调度放在同一套框架中，面向的是如何在特定硬件上高效执行模型，而不是一套开箱即用的在线服务平台。

这一区别决定了该如何理解“生产推理框架”这几个字。DeepSeek称DeepInfer用于大规模生产服务，但发布版没有包含KV缓存系统、Prefill与Decode阶段的分离部署，也没有跨数据并行副本的负载均衡。换句话说，外界看到的是线上系统里重要的执行层，而不是请求进入、排队、路由到最终生成的完整服务链路。

性能来自一整套协同，而非单个内核

DeepInfer的底层由FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect和自定义TileLang内核等组件构成，上面再接模型与采样运行时。DeepSeek称框架最初主要基于vLLM构建，也借鉴了SGLang和TensorRT-LLM。它的工程价值因此不只是公开若干算子，而是展示这些内核如何接入运行时，并与并行和调度策略配合。

在并行设计上，注意力部分使用数据并行，MoE部分使用专家并行，并由专家并行负载均衡器处理专家侧分配。DeepSeek描述的生产架构还会按阶段选择不同配置：Decode可在超节点内使用EP64到EP128，Prefill则通常选内存允许的较小专家并行规模，约为EP2到EP8。仓库性能测试中，Prefill使用4张SM100 GPU，Decode使用64张；这是报告结果的测试条件，不是所有部署都必须照搬的硬性配置。

两种优化都在减少“白算”

DeepInfer的DSpark推测解码不是简单地让草稿模型多写几个token。草稿模型每轮提出5个候选token，Confidence Head估计它们被接受的可能性，调度器再决定验证多长的前缀。其目标是把验证算力留给更可能有用的候选，而不是对每个草稿都做同等投入。

DeepSeek报告称，动态验证把平均验证长度从5个token降到约3.2至4.4个，平均接受长度则是3.29对3.20，变化很小。在每个rank约60条序列的测试点，DeepSeek给出的吞吐提升约为4%至7%。这组数字说明节省验证工作可能转化为收益，但提升幅度与负载条件有关，不能直接当作任意批量和模型配置下的固定加速比。

另一种减少重复工作的设计是SWA bounded replay。缓存命中时，系统只重算最近一段token以恢复滑动窗口注意力状态，而不是重新计算完整上下文；部署问答描述的后缀长度为128个token，README默认保留长度为140个token。DeepSeek称，这让重算成本不再随上下文长度增长，并能显著降低相关层的Prefill计算量。两处长度来自不同材料中的描述，应视为配置或说明口径差异，而非一个必须统一的常数。

高吞吐数字有明确的测试边界

现有性能数字主要来自DeepSeek发布的曲线，再由报道按图读取，并非独立第三方基准。在131,072上下文、EP64等条件下，曲线显示Decode在每rank 256个请求时超过每GPU每秒25,000个输出token；每用户速度接近每秒100个token。每rank请求降至8个时，每用户速度则超过每秒300个token，反映的是吞吐与单用户响应速度之间的不同取舍。

Prefill曲线使用4张SM100 GPU。每rank输入4,096个token时，非缓存吞吐约为每GPU每秒60,000个token；输入长度达到65,536时，吞吐接近每GPU每秒90,000个token，但单步延迟约为730毫秒。数字不能脱离输入长度、请求批量、并行配置和硬件型号比较。DeepSeek还称单个集群每天服务155万亿token，但这是公司对自家生产规模的陈述，不等于第三方验证过的性能或成本数据。

复用这套框架，先看缺失的服务层

对技术负责人来说，DeepInfer最直接的参考价值，是把性能问题拆成可检查的工程选择：内核如何组合，Prefill与Decode如何分配并行度，推测解码如何控制验证量，以及CPU调度怎样与GPU执行异步重叠。框架还支持正则表达式、JSON Schema和EBNF约束的结构化输出。批次不变推理和确定性采样则注明仅支持NVIDIA，这提醒团队不要把跨硬件能力默认视为一致。

但把它用于线上服务，仍要自行补齐发布范围之外的部分，包括KV缓存管理、阶段分离、请求路由与负载均衡。当前公开支持也集中于DeepSeek-V4.1-Flash，硬件范围是NVIDIA SM100和Huawei Ascend 950，不能据此推断其他模型或设备上的性能。实际评估时，应先用自己的上下文长度、并发形态和硬件复现端到端指标，再判断内核优化能否抵消额外系统工程成本。DeepInfer开放的是一扇通往推理执行层的窗口，窗口之外的服务复杂度仍然需要团队自己承担。