DeepInfer 深度解析——DeepSeek 生产推理引擎开源了什么

DeepSeek 把自家线上推理栈的核心引擎开源了，仓库叫 DeepInfer。README 第一句写得很克制：它 powers DeepSeek’s large-scale production services，而这次 release 提供的是 offline inference，外加一套大规模服务真正用得上的核心能力。

对基础设施工程师来说，这比“又一个开源引擎”更值得读。原因不是 README 里的 Pareto 曲线有多漂亮，而是：你终于能对着生产同源的引擎代码，看清 DeepSeek 怎么把混合专家（MoE）、多头潜在注意力（MLA）/ 滑动窗口注意力（SWA）、推测解码、异步调度和双后端（NVIDIA SM100 / 昇腾 Ascend 950）拧成一条可跑通的离线路径——同时也能看清，哪些东西他们没有开源。

本文基于公开仓库 commit 5537415（README、examples/、doc/inference_deployment_qa.md、deepinfer/、csrc/）与社区源码导读站点 DeepInfer Explained（对照 commit 9bd9cf2）写成。命令与路径来自仓库；本文未在 SM100 / Ascend 950 上实跑 ./build.sh 或 offline。官方吞吐数字一律标明出处，不当独立复现。

下图是开源 release 的运行时分层——从 offline_inference.py 到 kernels / Platform；灰色边框外的 KV、E/P/D 入口与 DP Load Balancer 不在本包。

〇、30 秒版

1. DeepInfer = DeepSeek 生产推理引擎的开源切片：主模型目前是 DeepSeek-V4.1-Flash；硬件是 NVIDIA SM100（CUDA 13）和华为 Ascend 950（CANN 9.2）；入口是 examples/offline_inference.py。
2. 增量不在“再包一层 vLLM”，而在 kernels、注意力数据并行（DP）+ 上下文并行（CP）、专家并行（EP）+ 专家并行负载均衡（EPLB）、DSpark 置信度调度、SWA bounded replay、零开销异步调度（ZOS），以及 batch-invariant / structured outputs。
3. 诚实边界：README 列了三项 not included——跨请求 KV、VE/Prefill/Decode 分离编排、Prefill/Decode 的 DP 负载均衡；Q&A 还列了 VE Load Balancer（同样未开源）。引擎里已有部分 hook，但服务周边不在这个包里。
4. 怎么用：空 Python 3.12 环境 → export DEEPINFER_ACCELERATOR=nvidia|ascend → ./build.sh → python examples/offline_inference.py。没有 SM100 / Ascend 950，很难当真跑通；这时它的价值是源码教材，不是替换你现网的 vLLM/SGLang。
5. 和系列的关系：机制看 11 / 12；引擎选型看 13；多 token 预测（MTP）看 15；V4 架构与成本看 26 / 27。本篇回答：DeepSeek 自己线上那套引擎，开出来长什么样——以及它相对 vLLM / SGLang / TensorRT-LLM 的优势、劣势与多条采用路径（§7）。

一、开篇：为什么值得基础设施工程师读

过去几年，社区推理引擎（vLLM、SGLang、TensorRT-LLM）和模型厂自研栈是两条平行线。模型厂的东西往往只以论文、技术报告、知乎长文出现；你能学到设计意图，却很难把 schedule()、forward()、sample() 在真实仓库里对上号。

DeepInfer 把这条平行线往社区扳了一截。Acknowledgments 写得很坦率：它 was originally built primarily on vLLM，并吸收了 SGLang、TensorRT-LLM 的思路。不少核心文件头仍留着 Derived from vLLM; modified by DeepSeek. 这意味着：

• 你熟悉 vLLM 的 LLMEngine / Worker / Sampler 分层，读起来不会完全陌生；
• 真正的增量在 V4.1 模型特化路径（MLA、MoE、MTP/DFlash、YOCO/SWA）和 DeepSeek 自研 kernel / 调度；
• 它不是“通用多模型引擎”的完整替代品——当前公开支持模型名单只有 DeepSeek-V4.1-Flash。

部署 Q&A（doc/inference_deployment_qa.md）还给出了生产语境（均为 DeepSeek 自述）：单集群约 155 trillion tokens/day，按官方口径折合整体营收约 US$38 / GPU-hour（谷价口径）。这些数字用来理解量级即可，不要直接写进你的容量规划表。

二、定位与边界：开了什么，没开什么

2.1 开源包边界一览

代码体量（本机浅克隆统计，量级与 Explain 站点一致）：Python 包 deepinfer/ 约 4.6 万行，C++ csrc/ 约 0.6 万行；kernels 多在 vendor/ 子模块（FlashMLA、DeepGEMM、DeepEP、DeepSelect 及 Ascend 变体）。更细的“解决什么 / 落点”见第五节与第六节，这里不重复罗列。

2.2 完整在线服务还缺什么

README 列了三项 Required for a complete inference service (not included)：

1. A KV cache system——跨请求复用、落盘、命中匹配；Q&A 写明与内部设施耦合，生产侧挂在 3FS 一类存储集群上。
2. VE / Prefill / Decode disaggregation——视觉编码、prefill、decode 分服务部署；README 说引擎侧“most required engine functionality is already implemented”，但服务编排与入口不在本包。
3. Load balancing across data-parallel replicas for both prefill and decode——README 明文写的是 Prefill / Decode 的 DP 级负载均衡。VE Load Balancer 见 Q&A（同样未开源）。注意：专家并行的 EPLB 已在引擎内；缺的是跨 replica 的请求级 LB。

另外，协议层的 deepseek-recipe 是并列开源的 tokenization / API 对齐组件，也不在 DeepInfer 仓库内。

下图对照“开源引擎切片”与“生产还缺什么”；右侧的 US$38 是 Q&A 的整体营收口径，不是 GPU 成本。

读法建议：把 DeepInfer 当成“引擎内核 + V4.1 特化运行时”；把知乎/Q&A 里的架构图当成“完整生产系统说明书”。两者叠在一起，才是 DeepSeek 线上推理的全貌。

三、如何使用：可跑通路径与现实门槛

3.1 环境前提

官方 Prerequisites：

• Linux
• GCC ≥ 13
• Python 3.12（空环境）
• NVIDIA：CUDA 13；Ascend：CANN 9.2

这不是“笔记本也能玩”的门槛。SM100 / Ascend 950 决定了：多数读者第一天的收获是读代码和跟 examples，而不是在自家 H100 上对拍 README Pareto。

硬件与并行能力见下图：双后端共用 Platform 抽象；生产 Q&A 说当前 TP/CP 暂不用，CP 能力主要在引擎 / examples 侧。

3.2 Build

# 必须先 export；ascend 平台改成 ascend
export DEEPINFER_ACCELERATOR=nvidia
./build.sh

build.sh 会：按 accelerator 装 requirements-*.txt；NVIDIA 路径强制重装 nvidia-nccl-cu13==2.32.3；跑 scripts/build_vendor.sh 编子模块；再 scripts/build.sh build 编 DeepInfer 本体。DEEPINFER_ACCELERATOR 需要在后续运行环境里保持一致（deepinfer/environ.py / platform.py 靠它选后端）。

3.3 Offline inference

python examples/offline_inference.py
python examples/offline_inference.py --ep 8
python examples/offline_inference.py --ep 2 --dp 8
python examples/offline_inference.py --ep 2 --cp 8

要点（来自 examples/README.md 与 _config.py）：

• 默认模型 id：deepseek-ai/DeepSeek-V4.1-Flash-1017；首次会进 HF cache。本地目录可用 --model_name；DEEPINFER_HF_MODEL_DIR 只对默认模型生效，不会覆盖显式 --model_name。
• 并行整除关系分两条口径：
  • offline_inference.py：world_size = dp_size * cp_size，且 world_size % ep_size == 0（所以 --ep 2 --cp 8 合法：dp=1, world=8）。
  • benchmark.py：先由 WORLD_SIZE × visible_devices 推导 ep_size，再要求 ep_size % cp_size == 0。
• --disable_eplb 可关专家负载均衡；默认会 setdefault DEEPINFER_OVERRIDE_NUM_EXTRA_EXPERTS=32。
• NVIDIA 路径上 offline 示例会 setdefault("DEEPINFER_BATCH_INVARIANT", "1")，方便和 PPL baseline 对齐。
• --check_structured_output 会在同一次 LLM 生命周期里跑 regex / JSON / EBNF 检查。

Benchmark / Pareto 复现走 examples/benchmark.py 与 examples/sweep/run_sweep.sh。官方 README 图：prefill 在 4×SM100、decode 在 64×SM100（同一 scale-up domain）测得——这是 vendor 测量条件，不是你的集群保证。

下图是一条 offline 请求从 prompt 到 RequestOutput 的路径；开启 ZOS 时，CPU 在 GPU 跑 forward(N)/sample(N) 的同时预排下一拍。

3.4 关键环境变量速查

集中定义在 deepinfer/environ.py（布尔值接受 0/1/true/false，空串按 false；大小写不敏感；非法值直接报错——近期 commit 还收紧了解析）。

Deterministic sampling（README）：DEEPINFER_BATCH_INVARIANT=1 DEEPINFER_ENABLE_MTP_VARLEN=0，并向 SamplingParams 传固定 seq_seed（NVIDIA only）。

Structured outputs：SamplingParams(..., so_args={"schema_type": ..., "schema": ...})，见 examples/_structured_output.py；运行时走 structure_output/（xgrammar 相关 env：DEEPINFER_XGRAMMAR_*）。

四、亮点地图（问题 → 机制 → 落点）

这一节不再重复〇/2.1 的功能清单，只按“选型时会问的问题”给落点；机制细节进第六节。

生产 Q&A 还描述了 Prefill/Decode LB、3FS KV、Mega MoE、Recipe 等——那是完整系统故事，开源包只覆盖其中引擎内核一段。

五、实现解剖：从 vLLM 血统到 DeepSeek 特化

5.1 和 vLLM / SGLang / TRT-LLM 的关系

一句话：骨架像 vLLM，调度 overlap 吸收了 SGLang/NanoFlow 一类思路，极致 kernel 与模型路径则是 DeepSeek 自己的。

• 像 vLLM 的部分：LLM 入口、LLMEngine 步进、Worker + ModelRunner、paged KV block、Sampler 模块化。读过 13：引擎横评 的人，进入 deepinfer/engine/llm_engine.py 不会迷路。
• 不像通用引擎的部分：模型注册几乎围着 DeepSeek-V4.1（DeepseekVLForCausalLM / DeepseekForCausalLM，Explain 站点指出 draft 是模型内 MTP_module）；并行默认叙事是 Attention DP + MoE EP，而不是“任意模型的 TP 为主”。
• 和 SGLang：异步调度、结构化输出都是重叠兴趣区；DeepInfer 的 structured output 编译与推理解耦；运行时仍在 decode step 里推进 automaton、在 sampler 应用 mask。
• 和 TRT-LLM：都追求极致 kernel，但 DeepInfer 开源路径是 PyTorch + 自研/子模块 CUDA/TileLang，而不是 TensorRT 编译栈。

5.2 目录与运行时分层

自上而下可以记成：

examples/offline_inference.py
  → deepinfer/entrypoints/llm.py          # 用户 API
  → deepinfer/engine/llm_engine.py        # 引擎循环、请求生命周期
  → csrc/engine/scheduler.*               # 选 batch、KV block
  → deepinfer/worker/{worker,model_runner}.py
  → model_executor/models/* + layers/*    # 前向
  → layers/sampler.py + structure_output/ # 采样与约束
  → vendor/* + tilelang_ops/              # 设备内核

EngineType（engine/engine_type.py）已区分 NORMAL / PROMPT / COMPLETION，对应未来 E/P/D 分角色；当前 offline 默认 NORMAL（同进程做 prefill+decode）。EngineArgs.__post_init__ 会按引擎类型 setdefault ZOS 与 multimodal pool。

5.3 推测解码路径（DSpark）

Draft 不是外挂小模型进程，而是主模型上的 MTP_module（DFlash 实现：model_executor/models/mtp/dflash.py）。流程概览：

1. Draft 侧生成最多 DEEPINFER_USE_NEXTN_DECODE 个 token，并走 ConfidenceHead 得到 per-draft accept rate（MTPPredictInfo.confidence_rates）。
2. Target 前向一次验证；DEEPINFER_ENABLE_MTP_VARLEN=1 时，验证长度不再固定为 nextn，而是按置信度与吞吐曲线挑“边际回报最高的前缀集合”。
3. 与 ZOS 叠加时：CPU 调度下一拍时置信度可能尚未返回，于是 CPU 只定总预算，GPU 上 TileLang kernel 再算 per-request seqlens_q（Q&A 原话）。

这和系列 15：推测解码与 MTP 里的“固定 K 验证”叙事相比，关键增量是 把验证算力当成稀缺资源来调度，而不是只追平均接受长度。

下图对照“固定验证 5 个 draft”与“按置信度只验高边际回报前缀”；条上的 0.92 / 0.81…是示意值，底部吞吐增益才是 Q&A 表。

5.4 并行切分数据流

生产 Q&A 的推荐形状（注意：这是完整服务部署建议，不是 offline 脚本默认；且 Q&A 明确说当前生产 TP/CP 都不用）：

• Prefill：在 HBM 装得下的前提下取最小 EP/DP（2–8）；
• Decode：Wide-EP（64–128），用更大 EP 换专家侧更少的 per-step 访存；
• Attention：#DP = #EP；
• VE：单卡实例往往够用。

开源 examples 用 --ep / --dp / --cp 表达引擎能力。CP 是 mirror CP：每个 rank 取 prompt 的前段+后段来平衡 causal 负载，只加速 prefill；每个 rank 仍持有全量 KV，decode 不会更快。README 的 balanced CP 与 examples 的 --cp 是引擎能力/其他场景，别把它当成当前生产配方。整除约束见 §3.3（offline 与 benchmark 不同）。EPLB 则在 EP 组内复制热专家并周期性重排，避免 Wide-EP 被少数热专家拖成短板——见下图。

六、几处硬核细节

下面四条都尽量落到文件路径 + 机制，不编造第三方 benchmark。

6.1 DSpark 变长验证：前缀约束与双队列

csrc/engine/mtp_varlen.hpp 里的调度注释几乎是一篇微型设计文档：

• 必须保证 confidence_{i+1,…} 不影响 draft_token_i 是否被验证`——否则变长选择会破坏因果前缀。
• 维护两套 accept-rate 队列：一套用更旧的 rate 估 best_bsz（total_q），一套用较新的 rate 分配 每条请求的 seqlen_q。
• 用 schedule_cnt / process_cnt 判断当前 rate 到底是 N-1 还是 N-2（ZOS 下 forward 与 post-process 可能错开一拍）。
• 有 draft 但还没 rate 时 pad 1.0，无 draft pad 0.0，避免调度饿死或虚胖。

Q&A 给出的厂商表（EP64/DP64）：动态长度把平均验证 draft 数从 5.00 降到约 3.2–4.4，接受长度几乎不动；16 seqs/rank 时约 −1.5%，约 60 时 +5.4%，96 时可到约 +11%——收益随并发上升，不是所有并发都赚。请把它读成“DeepSeek 在自己曲线上的增益”，而不是你的 SLA 承诺。

6.2 EPLB：logical → physical，再周期性 shuffle

model_executor/eplb/__init__.py 的 ExpertLoadBalancer 把状态摊开得很干净：

• expert_count：每层每个 local physical expert 的 token 计数；
• physical_to_logical_map / logical_to_physical_map：放置关系；
• resolve_num_extra_experts()：在下限之上向上取整，使 num_routed + extra 能被 ep_size 整除；
• 重排后搬权重：_intranode_shuffle = PG.is_within_nvl_domain(ep_group) and PLATFORM.is_gpu——NVIDIA 单机 NVLink 域内走 symm_mem/IPC；NPU 或更大 EP 组走 batch_isend_irecv（P2P）。
• 重排间隔：DEEPINFER_EXPERT_REARRANGEMENT_STEP_INTERVAL 引擎默认 0（关闭）；examples 开 EPLB 时设为 30，并把 window 设为 3（省显存）。

生产 Q&A 补充了 Prefill/Decode 不同的冗余与重排周期（Decode 起步 1/GPU，EP64 取整后约 7/GPU，不含 shared expert），以及测得的 moe_lb（最慢 rank / 均值）。开源包给了机制；线上那组超参是运维经验。

6.3 SWA bounded replay 与 YOCO compact

长上下文命中后，如果 SWA（滑动窗口注意力）状态缺失，朴素做法是重放整段前缀——成本随长度线性涨。DeepSeek 的做法是：命中长度由 block KV 决定；SWA 只在最近一个有界窗口上重建。

开源侧你能直接操作的旋钮：

export DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact
export DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140

KEEP_TOKENS 在 environ.py 默认是 0；docstring 写明启用截断时必须显式设置。只开 TRUNCATION_MODE=compact 而不设 KEEP_TOKENS，会撞上 model_runner.py 的 assert：KEEP_TOKENS >= window_size + DEEPINFER_MAX_BACKTRACKING_TOKENS。cache_engine.py 把 StateBlock 切成 stored / dropped 区：该持久的 SWA 留存，YOCO consumer SWA 与部分 compression state 可丢、靠有界重算恢复。

下图概括 Encoder / Decoder 两条 replay 路径，以及“重算成本近似常数”的效果边界。

Q&A 还写了“最多命中到 L - 134”（128 窗口 + 6 的投机回退余量）这类硬约束。跨机 SWA 目录与 3FS block KV 则仍在未开源的 KV 系统里。

6.4 ZOS：把 schedule/post-process 塞进 GPU 气泡

同步路径的经典浪费是：

schedule(N) → forward(N) → sample(N) → 等 D2H → post-process(N) → schedule(N+1)

GPU 在最后两段经常空转。ZOS（DEEPINFER_ZERO_OVERHEAD_SCHEDULING）把流水改成：GPU 跑 forward(N)/sample(N) 时，CPU 并行做 schedule(N+1)、launch_sample(N+1)、以及更早一步的 post-process。

代码落点：

• csrc/engine/zos.cpp / zos.hpp：准备下一拍 token 输入、remap、与上一拍 GPU 输出做 overlap；
• worker/worker.py：prepare_zos_inputs、MetadataZOS、在非 prompt 且开启 ZOS 时走 correction 路径；
• arg_utils.py：NORMAL/COMPLETION 默认把该 env setdefault 为 1。

因此 ZOS 下 step(N) 返回的是 N−1 的 token；最后一次结果由 flush_inflight_reqs() 收尾（llm.py 在无未完成请求时走 flush）。看到日志里 step 与 token 错一拍，不是 bug，是设计。也因此，6.1 里那套 N-1/N-2 rate 会计才变得必要。

下图对照同步路径的 GPU 空等与 ZOS 流水重叠。

6.5（加餐）Batch-invariant 与 structured output 的工程味道

• Batch-invariant（DEEPINFER_BATCH_INVARIANT=1，NVIDIA）：让不同 batch 拼法下数值一致，服务于 offline PPL 回归（tests/models/offline_decode_ppl.json）。runtime_config.py 里对 NPU 还有“防 CI 数值不稳”的特殊分支——双后端现实立刻露出来。
• Structured output：编译与推理解耦（structure_output/so_matcher_builder.py）；请求进引擎前拿编译结果；decode 步进里推进 grammar automaton，再在 sampler 应用 mask。这和“把 JSON mode 塞进 prompt 里求好运”不在同一个工程等级。

七、优势 / 劣势与多路径选型

本节是架构对比，不是同硬件吞吐排行榜。DeepSeek Q&A 的 155T / $38 营收、DSpark 表、EPLB 的 moe_lb 都是厂商自述；本文未在 SM100 / Ascend 950 上对拍 vLLM / SGLang / TensorRT-LLM。通用引擎横评仍以系列 13 为主，这里只叠加「DeepSeek 生产引擎切片」这一维。

7.0 先看三条决策路径

下图按「主约束」分四条路：要对齐 DeepSeek-V4.1-Flash 生产配方且有 SM100 / Ascend 950 → DeepInfer；多模型通用 serving → vLLM；前缀缓存 / 结构化 / 异步优先 → SGLang；接受 TensorRT 编译栈做 NVIDIA 极致优化 → TensorRT-LLM。昇腾完整 serving 旁路可看 MindIE；轻量部署还可对照 TGI / LMDeploy（本篇不展开实测）。

现实里多数团队会走重叠路径：现网继续 vLLM / SGLang，DeepInfer 当源码与配方对照——不是二选一替换。

7.1 DeepInfer 的优势（相对社区引擎）

一句话：DeepInfer 强在「DeepSeek 自己怎么跑 V4.1-Flash」的可审计实现，不强在「替你接管所有模型的生产 serving」。

7.2 DeepInfer 的劣势与诚实边界

骨架仍像 vLLM、调度 overlap 吸收了 SGLang 一类思路（§5.1），所以「读得懂」不等于「能替换」。

7.3 和其他方案怎么放一起看

下图是能力矩阵的示意（● / ◐ / ○），不是分数、不是 tokens/s。

对照读法（与 13 互补）：

• vs vLLM：vLLM 赢在模型面、社区、开箱 serving 与前缀缓存生态；DeepInfer 赢在 DeepSeek 生产特化（EPLB、DSpark、YOCO、ZOS、双后端）与可审计配方。现网默认盘通常仍是 vLLM。
• vs SGLang：SGLang 在 RadixAttention 一类前缀复用、结构化输出与异步 serving 上很强；DeepInfer 的 structured output 是「编译与推理解耦」，兴趣重叠但产品形态不同。要快速迭代通用 API 服务，SGLang 往往更顺。
• vs TensorRT-LLM：都追极致 kernel，但栈不同——TRT-LLM 走 TensorRT 编译，DeepInfer 走 PyTorch + 自研/子模块 CUDA/TileLang。锁定 NVIDIA、可接受编译复杂度时 TRT-LLM 仍是强候选；要读 DeepSeek 生产路径或 Ascend 双后端，DeepInfer 更直接。
• 轻量旁路：MindIE（昇腾侧完整 serving）、TGI、LMDeploy 等可按团队栈选用；本篇不做无硬件条件下的吞吐断言。

机制层背景可回 11 / 12；推测解码对照 15。

7.4 适用场景与「还不如继续用 vLLM / SGLang」

更适合认真跟进 DeepInfer 的人：

• DeepSeek-V4.1-Flash 的私有化 / 专有云部署（叠加 Recipe 才谈 API 行为一致）；
• 做 MoE + Wide-EP + 推测解码的引擎研发（EPLB / MTP varlen / ZOS 当参考实现）；
• 国产加速器团队（Ascend 950 与 NVIDIA 共用抽象）；
• 写评测与对齐的人（batch-invariant + 固定 seed）。

什么时候还不如继续用 vLLM / SGLang（或 TRT-LLM）：

• 多模型、多 LoRA、通用 HuggingFace 生态；
• 只有 A100/H100/消费卡——硬件门槛不匹配；
• 要开箱 OpenAI Server / K8s 全家桶——回 21 与 13；
• 需要跨请求 prefix cache 立刻打满命中率——KV 系统未开源。

7.5 四条采用路径（可并行）

「多花途径」这里按字面落实成多条可采用路径：读源码、学生产配方、等硬件/模型面、现网继续社区引擎——默认建议 A+B+D 并行，只有约束匹配才评估 C→上线。

务实顺序：

1. 路径 A：Explain 站 “life of a request” → llm_engine → scheduler → worker → dflash → sampler。
2. 路径 B：打开 DEEPINFER_ENABLE_MTP_VARLEN / YOCO compact（显式设 KEEP_TOKENS），把 EPLB / varlen / bounded replay 做成对照实验。
3. 路径 C：有 SM100 或 Ascend 950 再 ./build.sh + offline_inference.py；无卡不要硬移植 kernels。
4. 路径 D：在线服务的 KV、E/P/D、LB、网关仍单独规划；不要假设能复制官方集群。
5. 成本与架构不够时先补 27 与 15。

八、小结

DeepInfer 的价值，不是在引擎排行榜上再插一根柱子，而是把 DeepSeek 生产推理里能分享的那一层摊开：双后端 Platform、MoE Wide-EP 与 EPLB、带置信度调度的 speculative decoding、为 SWA/YOCO 服务的有界重算、以及把 CPU 调度气泡挤掉的 ZOS。和 vLLM / SGLang / TensorRT-LLM 比，它赢在配方可审计，不赢在通用 serving 完整度——选型应走 §7 的多路径，而不是单一替换。

它同时用 README 三项 not included 画清了边界——引擎 ≠ 完整推理服务。对读者，最健康的预期是：

• 学设计、对源码、在匹配硬件上跑 offline；
• 不要幻想今天 clone 明天就复现官方在线集群；
• 把学到的 EPLB / varlen verify / ZOS / bounded replay，带回你正在维护的 vLLM、SGLang 或自研栈里，一项一项做对照实验。

交叉阅读：

• 11：推理基础
• 12：PagedAttention 与 Continuous Batching
• 13：vLLM / SGLang / TRT-LLM 对比
• 15：推测解码与 MTP
• 26：DeepSeek-V4 与国产芯片
• 27：DeepSeek-V4 的极致性价比从哪来
• 系列目录

参考

• DeepInfer 仓库：https://github.com/deepseek-ai/DeepInfer（本文源码对照 commit 5537415）
• README（功能、硬件、未开源项、Pareto 测量条件）
• doc/inference_deployment_qa.md（生产架构、EPLB/LB/KV/DSpark/ZOS 问答）
• DeepInfer Explained：https://explaindeepinfer.projects.thomaspaul.dev/index.html（对照 commit 9bd9cf2）
• deepseek-recipe：https://github.com/deepseek-ai/deepseek-recipe