DeepInfer：开源的是执行引擎，不是服务 对 deepseek-ai/DeepInfer 的源码实证、生产架构还原与可落地性判断

00摘要：九条核心论断

只读这一页也能用。以下每条论断都可在正文中找到代码路径、命令或一手来源；标注「观点」的是本报告判断，不是业界共识。

读者地图

01范式判定：它到底算什么

把 DeepInfer 叫「推理框架」容易造成误判。更准确的说法是：面向单一模型结构、面向离线批执行、面向特定加速器拓扑深度优化的执行引擎（engine core），外部包着一层薄薄的 Python API。

时间轴：从模型开源到服务栈开源

来源：GitHub REST API /repos/deepseek-ai/DeepInfer、本地 git log --oneline、知乎《DeepSeek V4.1 Flash 大规模推理部署实践》（2026-10-20）、arXiv:2607.05147。

三条判别式

概念分野：和谁比，比什么

02代码盘点：61,664 行的形状

先把「它有多大、哪部分最重」量出来。这个分布本身就是 C1（模型专用）最硬的证据：57.3% 的代码集中在模型执行层，而通用调度、服务、协议加起来不到一成。

分层栈：Python 编排 + C++ 调度 + 双后端 kernel

体量由本地 wc -l 汇总；路径均可在 HEAD a679bb8 定位。一手源码

构建门槛与依赖锁定

验证强度：仓库自带的可证伪机制

这不是只有 README 的代码包。17 个测试文件里包含三类高价值验证：

• 数值等价性：tests/models/offline_decode_ppl.json 按平台/工作负载存 PPL 基线，逐样本精确比对；长上下文（16,389 输入 / 4,096 输出 / nextn=5）单独覆盖。
• 结构等价性：examples/yoco/yoco_equiv.py 提供 L1（单卡、秒级、不加载权重，比对 SWA pivot / 可见 key / store slot）与 L2（8 卡、teacher-forcing 逐元素比对 logprob 与 top-K，--mtp 5 时还逐位比对 confidence）。
• 确定性与同步纪律：test_batch_invariant.py、test_ve_batch_invariant.py、test_cuda_sync_guards.py——后者在前向/采样 launch 期禁止 CPU-GPU 同步，直接守护 ZOS 的流水线性。

03理论根基：为什么必须是这个形状

好的理论章要能推出具体工程动作。DeepInfer 的每一个主要设计，都能从两条一阶关系推出来：算术强度决定 decode 的并行规模，边际期望收益决定验证长度。

推导一：decode 的吞吐–延迟前沿

MoE 模型 decode 每步必须把被激活专家的权重从显存读入，这部分流量近似与 batch 无关；增大 batch 提高算术强度、摊薄单 token 的权重读取成本。于是：

由此推出的工程动作是「让每步的 T₀ 变小，而不是把 B 调小」：Wide-EP 把专家分散到更多卡，降低单卡每步的 MoE 权重流量；EPLB 让最慢 rank 靠近均值，避免同步空转。官方给出的边界同样自洽：EP 超过 32 后收益停滞，因为显存带宽不再是瓶颈，通信与同步开销开始主导。

推导二：推测解码的验证长度是可优化的，不是超参数

固定验证 5 个 draft token 时，第 i 个 token 被用上的概率是前 i 个都接受的前缀存活概率，取累计乘积 P_i = ∏_{j≤i} p_j。期望产出 τ(B) = Σ_{i≤B} P_i 随 B 增速递减，而 T(B) 仍在线性增长。最优验证量应最大化：

这条推导能直接解释官方表格里最反直觉的一格：并发 16 时动态验证反而 −1.5%。低并发下固定开销占比大、验证长度调整的可用预算小，调度决策的估计误差与 kernel 开销可能吃掉收益；并发升到 60–96 时，节省下来的验证 token 才转化为 +5.4% ~ +11.0% 吞吐。换句话说，DSpark 是一个高并发优化，不是通用加速器。

理论 → 工程动作对照表

04模型约束：V4.1-Flash 决定了引擎的形状

不理解模型结构，就无法理解 DeepInfer 为什么这么写。本节所有配置数字来自 HuggingFace 仓库的 config.json 原文，权重体积来自文件索引与 safetensors header 的实测解析。

config.json 关键字段（一手）

来源：huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017/raw/main/config.json；模型卡标注 763B params、MIT 权重许可。一手配置

权重构成：510 GB 里有两个 94.5 GiB 的「巨无霸」

V4.1-Flash-1017 共 48 个 safetensors shard、510,311,045,295 B（510.31 GB / 475.26 GiB）、96,085 个张量。索引里最反常的是最后两个 shard 各约 94.5 GiB，却各自只装 6 个张量——都是 layers.1.engram.* 与 layers.14.engram.*。这两张 Engram 表合计 203.07 GB，占整个 checkpoint 的 39.8%，也解释了 V4.1 权重为何远大于 V4 时代的 160 GB。

解开「7GB 之谜」：draft 不是独立模型

这是本研究最值得单独回答的一个历史问题。把三条证据链拼起来，结论很明确：

05部署架构：E/P/D 分离与 Wide-EP

生产架构不是仓库代码，而是部署 Q&A 与知乎技术文章描述的系统。三条设计目标决定了整套拓扑：多厂商芯片、用普通 8 卡机做 Prefill / 64–128 卡超节点做 Decode、KV 缓存保留 72 小时以上。

并行策略：两侧的取值方向相反

EPLB：把「热点专家复制几份」写成了可复跑的贪心算法

官方描述的「冗余专家 + 周期重排」在仓库里有完整实现：model_executor/eplb/policy.py 的 rebalance_experts_global() 先按 tokens_per_expert / logical_count 逐个贪心复制热点 logical expert，再用 _batch_greedy_indices() 把物理副本逐层排布到各 rank，目标是最小化 Σ_step max_rank(负载)；shuffle.py 负责跨卡 P2P / 机内 IPC 权重搬运。

证据强度说明：中英两版文档的 prefill moe_lb 数值不一致（差异约 0.01–0.03），且都未说明测量窗口与流量构成。这属于官方自报、口径未披露，不应作为容量规划依据；整体「达到完美均衡离线 benchmark 的约 80%」同样如此。口径存疑

存储、网络与容错数字

最小可部署单元是 1P + 1D，但 Decode 推荐 EP≥64，故最小高效单元为 64 张 prefill 卡 + 64 张 decode 卡（约 1:1，合计 128 GPU）。这条数字是判断「我的团队能不能照搬」的第一道门槛。

06DSpark：置信度调度的推测解码

这是 DeepInfer 里理论最完整、源码最漂亮、也最值得移植的一块。核心命题不是「猜得更准」，而是「把有限的验证算力花在边际回报最高的 draft token 上」。

论文与代码的分工

调度器逐行还原：一个在线的吞吐最大化搜索

MTPVarlen::schedule()（mtp_varlen.hpp:150-267）做的事，可以逐步复述：

1. 时间估计：用两个滑动中位数估计器消化实测值——SamplerRuntimeEstimator 取最近 9 个采样耗时的中位数（至少 5 个样本才生效）；ForwardRuntimeEstimator 维护 5,000 步窗口，先按 graph size 分组取中位数、再对组中位数取中位数，用两个 multiset 做 O(log n) 动态维护。步耗时 = baseline(graph_size) + slope·graph_size + sampler_ms。
2. 置信度入队：把每个请求每个 draft 位置的接受率估计 p 压进两个优先队列。为避免「后面的 confidence 影响前面 token 是否被验证」，算总预算用 N−2 轮的值、分配每请求长度用 N−1 轮的值，靠 schedule_cnt / process_cnt 配对判断数据滞后几轮——源码注释把这件事讲得非常清楚。
3. 搜索最优批大小：按接受率降序排序，从「只验证 golden token」开始逐个加入 draft，每加一个就重算 cur_expected / time_ms，取最大值得到 best_bsz。
4. 分配：每请求基础长度 1，把 best_bsz − num_seqs 个额外验证位按第二个队列的顺序分给期望收益最高的请求，得到 seqlens_q。
5. ZOS 下再修正：CPU 排 schedule(N+1) 时第 N 步的 confidence 还没回，因此 CPU 只定总预算；GPU 上由 TileLang kernel 做 cumprod → 稳定降序 argsort → rank < extra_budget 的 top-k → 按 remap scatter，把每请求长度写回 pinned buffer（zos.cpp:279）。

收益全景（官方表格原值）

来源：doc/inference_deployment_qa.md「Speculative decoding」节。估值为「基于 EP64/DP64 benchmark 数据计算」，属于建模值而非独立实测，报告未给出方差或重复次数。建模值

开箱配置与可复跑实验

# README 给出的启用方式
DEEPINFER_ENABLE_MTP_VARLEN=1            # 开启动态长度验证
DEEPINFER_USE_NEXTN_DECODE=5             # 最大 draft 长度，默认 5，设 0 完全关闭投机解码
DEEPINFER_DFLASH_CONFIDENCE_HEAD_TEMPERATURE=1.0   # 也可给逗号分隔的 5 个 per-step 温度

# 关闭动态验证、走确定性路径（仅 NVIDIA）
DEEPINFER_BATCH_INVARIANT=1 DEEPINFER_ENABLE_MTP_VARLEN=0

# 复跑 Pareto 曲线
bash examples/sweep/run_sweep.sh decode ep64-128k 131072 3 0.75

源码里还有一层易被忽略的自由度：DEEPINFER_DFLASH_CONFIDENCE_HEAD_TEMPERATURE 支持按 draft step 给不同温度（长度必须等于 USE_NEXTN_DECODE，否则 environ.py:148 直接报错）。这说明 confidence head 的校准是分位置做的——因为后缀位置的接受率天然衰减，单一温度无法拟合。

07SWA Bounded Replay 与 KV 缓存经济

如果说 DSpark 优化 decode，这一节优化的就是 prefill 与缓存成本。它同时是 V4 → V4.1 架构演进中最有信息量的一处取舍：放弃精确，换取常数代价。

三代策略的取舍

命中策略：三层缓存，两套生命周期

SWA 状态槽位的物理布局是精算过的：StateBlock 分成「需保存区（SWA）」与「丢弃区（YOCO consumer SWA + C2 压缩边界累加器）」，V4.1 保存前 20 层，每层 134 token（128 窗口 + 6 投机回退）、MXFP8 格式 528 B/token，合计 20 × 134 × 528 = 1,415,040 B / 序列。只在 128 token 整数倍位置存储；decode 阶段在显存另开副本区，每跨一个 128 边界就拷一次窗口，最多越过边界 5 个 token，由 ring 多出的 6 个位置吸收。

命中长度的规则同样精确到 token：输入长度 L 的最大命中 ≤ L − 134；先查 Block KV 得 L1（128 的倍数），若 L1−128 .. L1 区间存在 SWA KV 则命中 L1，否则退一块命中 L1−128 并重算 128 token。

关键路径上只剩「匹配」藏不掉

官方把命中开销拆成三段，并说明哪段能被重叠掉：匹配（Entrypoint 本机 CHECK 角色做哈希链前缀匹配，只查元数据，但命中长度必须在路由前算出，无法隐藏）→ 取 KV（独立进程异步把 KV 从 3FS 搬进宿主机 shm）→ 换入（engine 内线程做 shm→HBM，目标是把逐层 H2D 与前向计算重叠；因 CUDA copy engine 对细粒度块拷贝表现差，换入用 GDR，让 RDMA 网卡打满 PCIe 且不占 SM）。

08零开销调度、确定性与结构化输出

这一组能力不改变算法，只改变「GPU 有没有在等 CPU」。它们对生产稳定性的价值，往往比多几个 kernel 点更高。

确定性与批不变：稀缺，但有平台门槛

注意确定性路径要求关掉动态长度验证——这是一个隐含的取舍：要可复现，就得放弃 DSpark 的自适应调度。对做回归测试、A/B 评测、离线数据生成的团队是合理交换；对在线服务则相反。

结构化输出：编译与推理解耦

支持 regex / JSON Schema / EBNF，入口是 SamplingParams(so_args={"schema_type": ..., "schema": ...})。约束在专用 SO 机器上异步编译成语法自动机（基于 xgrammar==0.2.2），请求进引擎前取编译结果；runtime 每步推进自动机、算出合法 token 集合并生成 mask 作用于采样。

09证据全景：性能、口径与反证据

这一章回答「这些数字能不能信」。原则是：区分实测 / 建模 / 自报 / 二手转述，把方向相反的证据与口径缺陷同列，并做数量级自洽性反推。

证据强度分级（本报告口径）

Pareto 读数表

三个必须打折的地方

生产账本的溯源与数量级反推

方向相反的证据

• DSpark 在低并发是负收益（−1.5%，官方自己的表格）——抵消了「推测解码总是加速」的叙事。
• CP 实测比 DP 端到端慢最多 5%（官方 Q&A）——抵消了「长上下文一定要上上下文并行」的直觉。
• EP 超过 32 后 Mega MoE 收益停滞（官方 Q&A）——抵消了「EP 越大越好」；Q&A 把原因归为通信/同步开销与同 supernode 内 NVLink 干扰。
• V4 技术报告的 Zero SWA Caching 生产未采用（知乎官方）——抵消了「论文方案即生产方案」。
• HN 讨论情绪约 40% 正面 / 35% 混合 / 25% 怀疑（daily.dev 转述，二手）——争论集中在地缘与经济学，而非技术细节；截至快照无正式分析师评论与第三方复现。

10缺口清单与风险

把「不能做什么」写清楚，比多列十条特性更有用。以下缺口均可回溯到官方 README、部署 Q&A、GitHub issue 列表或源码配置。

三件套缺口（README 明示）

社区的真实诉求：恰恰是「服务层」和「更多硬件」

按评论数排序拉取开放 issue（2026-11-08 快照，共 247 个），高频主题高度集中，反过来印证了交付边界：

来源：GitHub REST API /issues?state=open&sort=comments 前 40 条。一手实测

风险清单

许可与合规建议（具体动作）

反模式清单

11落地：决策树、成熟度阶梯与检查清单

把前面的判断变成动作。先做三选一，再按阶梯推进，任何一级不达标就停在当前级，不要越级采购硬件。

决策树

动手前检查清单

• 确认硬件型号在支持列表（SM100 / Ascend 950），并记录 compute_capability 探测结果。
• 用干净的 Python 3.12 环境，全程保持 DEEPINFER_ACCELERATOR 导出；注意 build.sh 会强制重装 NCCL 2.32.3。
• 先跑 python examples/offline_inference.py --ep 8 与 --check_structured_output，验证 PPL 基线逐样本通过。
• 跑 python examples/yoco/yoco_equiv.py mask-compact（L1，秒级、不加载权重）验证构建产物与仓库一致。
• 用 bash examples/sweep/run_sweep.sh prefill ... 与 decode ... 各出一条曲线，与官方 Pareto 对比读数。
• 记录自己测到的真实 draft 接受长度；不要直接引用官方的 full-acceptance 吞吐数字。
• 若走昇腾路径，单独核对 DeepEP-Ascend 许可文件，并做精度与性能验收（批不变 / 确定性不可用）。
• 若启用结构化输出，保持 DEEPINFER_XGRAMMAR_CACHE_LIMIT_BYTES 为正值并监控缓存占用。
• 锁定上游 commit（本快照 a679bb8），把 PPL 基线、YoCo L1/L2 结果纳入自己的 CI。
• 立项文档里明确写出：本次目标是 L0/L1/L2/L3 哪一级，以及不做什么。

90 天路线（建议节奏，非工期承诺）

12结论与判断

以下为本报告观点，不是业界共识，也不是官方立场。

最后一个观察：仓库只有 6 次提交，却包含中文注释的 C++ 调度器、双硬件后端的 TileLang kernel、逐样本 PPL 基线、YoCo 等价性 L1/L2 验证、以及一份仍在修订（v0.2）的部署 Q&A。这不像一个为发布而拼凑的开源项目，更像把一份成熟内部代码树做了一次脱敏后的快照。因此它的价值密度远高于 commit 数所暗示的水平，而它的可维护性风险也恰好来自同一件事。

13参考来源与复跑命令

结构化项目档案

一手来源（A / B / C 级）

二手来源（D 级，仅作线索与反证据）

中新经纬 / 光明网 / 证券时报 / 中国基金报 / 北京日报（2026-10-20 ~ 10-21，官宣与产业解读）；is4.ai、techrounder.com、toolworthy.ai、zendot.org、mlllm.io、technologypulse.app、n1n.ai、aiguide.cc（2026-10，缺口与门槛分析、第三方复现缺失声明）；微信公众号「DeepSeek 开源 DeepInfer」长文（2026-10-28，HN 讨论、第三方集成 PR、issue 统计）；HuggingFace 社区 GGUF 卡片 sakamakismile/DeepSeek-V4-Flash-DSpark-support-ds4-GGUF（drafter 张量来源说明）。所有引用数据均已回溯到一手；无法回溯者已标注为二手或存疑。

复跑命令（本报告全部 A 级数字的出处）

# 仓库与元数据
git clone https://github.com/deepseek-ai/DeepInfer.git && cd DeepInfer
git log --oneline --date=short --pretty='%h %ad %s'          # 6 次提交
curl -s https://api.github.com/repos/deepseek-ai/DeepInfer     # stars / license / created_at

# 代码体量：只数 .py/.cpp/.hpp/.pyi，排除 .git 与 vendor
python3 - <<'PY'
import os, collections
c = collections.Counter()
for dp, dns, fns in os.walk('.'):
    dns[:] = [d for d in dns if d not in {'.git', 'vendor'}]
    for f in fns:
        if f.endswith(('.py','.cpp','.hpp','.pyi')):
            p = os.path.join(dp, f)
            c[p.split(os.sep)[1] if len(p.split(os.sep)) > 2 else '(root)'] += sum(1 for _ in open(p, errors='ignore'))
print(sum(c.values()), c.most_common(8))
PY

# 权重差值：HF API 文件清单
curl -s 'https://huggingface.co/api/models/deepseek-ai/DeepSeek-V4-Flash?blobs=true'
curl -s 'https://huggingface.co/api/models/deepseek-ai/DeepSeek-V4-Flash-DSpark?blobs=true'
# 用 siblings[].size 求和（仅 .safetensors）得 159,617,149,040 与 166,886,535,336 B

# 内置 drafter 体积：解析 index.json + 各 shard 的 safetensors header（HTTP Range）
curl -sL .../model.safetensors.index.json | python3 -c "import json,sys; d=json.load(sys.stdin); ..."
# 按 weight_map 找 mtp.* 所在 shard，再按 data_offsets 累加 → 7,932,874,632 B

# 官方曲线（需要 SM100）
bash examples/sweep/run_sweep.sh prefill pe-128k 131072
bash examples/sweep/run_sweep.sh decode ce-128k 131072 3 0.75
python examples/yoco/yoco_equiv.py mask-compact