企业官网建设流程全解析

📋 目录

• 一、先把这次开源的日期和版本号钉死
• 二、最值钱的三样东西，这次没给
• 三、三个数字，和它们的真实边界
• 四、vLLM 和 SGLang 的追平，口径对不上
• 五、昇腾 950 那一行，验收到什么程度
• 六、这件事到底改变了什么
• 七、结语

一、先把这次开源的日期和版本号钉死

2026 年 10 月 20 日，DeepSeek 在 GitHub 上放出两个仓库：DeepInfer 和 deepseek-recipe。

中文互联网对这个事件的转述从第一天就乱了。仓库的实际创建时间是 10 月 16 日，官方公告是 10 月 20 日，The New Stack 报道说代码落地发生在 10 月 19 日。有一篇流传颇广的技术博客把开源日期写成 10 月 16 日、把 star 数写成"上线四天 598"，还有一篇直接把 SM100 举例成"H200/B200"——H200 属于上一代 Hopper 架构，而 DeepInfer 明确不支持 Hopper。

这些都不是大问题，但它们叠加起来会让人对这次开源的"分量"产生错判。所以先把一手事实列清楚：

仓库里只有 3 次提交这件事值得单独说一句。它说明放出来的是一份整理过的发布件，不是开发史。外部开发者已经在提 PR，但回灌节奏、review 责任、版本策略目前都没有公开答案。半年之后如果还是这个形态，它就只是个发布件；如果 PR 被系统性合并、出现 release 和版本号，才说明 DeepSeek 打算真的养一个开源项目。

再说三个最容易被跳过的事实。

第一，这不是"第一个开源推理框架"。DeepInfer 自己就写着，仓库最初主要基于 vLLM 构建，同时借鉴了 SGLang 和 TensorRT-LLM 的思路。文件头里还留着 “Derived from vLLM; modified by DeepSeek” 的注释。它的准确定位是：第一个由头部前沿实验室公开的、自己线上生产环境在跑的那一份推理引擎。这跟"第一个开源推理框架"是两回事。

第二，它只服务一个模型。首版只支持 DeepSeek-V4.1-Flash，而 vLLM 支持数百种模型架构、SGLang 覆盖主流开源模型基本齐全。对只想跑一个模型且追求官方级调优的团队，这是优势；对模型会频繁切换的团队，这是硬约束。

第三，它没有 HTTP 服务端。唯一的入口是python examples/offline_inference.py，一个 Python 脚本。它不是 OpenAI 兼容的 API 端点。

二、最值钱的三样东西，这次没给

DeepInfer 的 README 里有一节，标题叫 “Required for a complete inference service (not included in this release)”。这一节列了三项：

• KV cache 系统
• VE / Prefill / Decode 分离部署（README 括注：所需引擎功能大部分已实现）
• Prefill 和 Decode 两侧跨数据并行副本的负载均衡

这三项不是边角料。缺了 KV 缓存系统，前缀缓存命中率那个数字就落不了地，重复 prefill 会直接吃掉 DSpark 省下来的算力。缺了 Prefill/Decode 分离，输入长度突增时 decode 的尾延迟会被 prefill 拖垮，运维也没法按流量结构分别扩容。缺了跨副本负载均衡，副本一多就排队不均。

SemiAnalysis 在 10 月 21 日发帖质疑的正是这一点：代码缺少对推理服务至关重要的组件，而自行补齐会引入过多假设。线程后续点名了 prefill 与 decode 之间的 KV-cache 传输、专家路由等承重件，并说 deepseek-recipe 虽然提供了 API 基础设施，承重组件仍然缺失。

用开车打比方：DeepInfer 是引擎，油箱、变速箱和方向盘没给。你可以把引擎点着火听个响，但开不上路。

反过来看，这三样没给也有它自洽的逻辑。2025 年 4 月 14 日，DeepSeek 在 open-infra-index 仓库里专门发过一份说明，解释为什么当时不打算开源内部推理引擎，理由有三条：

三条理由里，第一条被"公开分叉"绕过去了，第三条被"先放发布件"推迟了。第二条没有绕过去——DeepSeek 选择把耦合最深的组件留在内部，而不是花力气做解耦。

这三条理由在十八个月后分道扬镳：代码分歧用"公开一个分叉"绕过去了，内部耦合用"把最难的留在内部"绕过去了，人手不足则用"先放发布件"推迟了。三个问题一个都没被真正解决，只是被挪了位置。

这才是这次开源最值得读懂的一层：DeepSeek 没有假装"耦合问题不存在"，而是把它挪到了开源范围之外。

三、三个数字，和它们的真实边界

官方技术报告和 README 里最常被引用的三个数字是：单集群每天 155 万亿 token、单卡每小时 38 美元、前缀缓存命中率 96%。这三个数字都有明确的限定词，而限定词在传播中丢得很快。

关于 38 美元这个数字，官方原文写的是 revenue，并且明确限定在低谷电价时段。这个限定词在二次传播中几乎全部丢失。

后果是同一串数字在 24 小时内被读成了三种东西：收入、利润、回本周期。Hacker News 上一部分人直接按 4 卡集群 10 个月回本 100 万美元来推演，另一部分人拿 SemiAnalysis 的利润估算器反驳，指出按 OpenRouter 的实际售价，连两年前上市的 B200 在某些模型上都已经是负毛利。

有个中文媒体给的算式值得单独拎出来：单卡每小时 38 美元，折算一天 6090.48 元、一个月约 18.27 万元。这个算术本身没错，但它把一张卡当作满负荷、持续在线、永不空转的理想状态。真实的 GPU 利用率长期在 25% 到 27% 这个区间——这是行业里流传的数字，同样没有一手审计，但方向上没有争议。

还有一个被广泛引用的数字值得核对：《财经》的测算给出单集群日收入约 1535 万元（全部按谷价）、月均约 4.67 亿元、年化约 56 亿元；全部按高峰价则分别是 3069 万元、9.34 亿元和 112 亿元。这篇报道自己写得很清楚：这个计算未考虑 DeepSeek 的整体集群规模，也未考虑算力、电力等成本，不代表 DeepSeek 实际实现的营收。

而据《财经》报道，DeepSeek 投前估值仍约 5000 亿元，融资规模从此前计划的 500 亿元增至约 1000 亿元，同时正在乌兰察布规划建设吉瓦（GW）级算力集群。把这两组数字放在一起看，"年化 56 亿"和"估值 5000 亿"之间的落差，比任何单个性能数字都更能说明 DeepSeek 现在的位置：它不是在靠 API 收入活着。

四、vLLM 和 SGLang 的追平，口径对不上

开源之后第三天，vLLM 项目官方账号发帖宣布：通过集成 DeepSeek 开源的 kernel 并深度优化 prefill 与 decode，vLLM 已在 DeepSeek 官方 decode 配置、batch size 8 到 256 的全区间上匹配 DeepInfer 的性能曲线，工程博客把差距量化为 6% 以内。

10 月 24 日，LMSYS/SGLang 也发了对照结论：在对齐 DeepInfer 的 128K 基准上，4×GB300/B300 的 prefill 最高约 1.04×，64×GB300 的 decode 步进时间短约 1.1%–7.4%。

这两个结论看起来是"追平"，但三方的测量条件并不一致：

关键的差异有三层。第一，vLLM 用的是一半的专家并行度（DEP32 对 EP64DP64）拿到接近的结果。第二，硬件跨代了——DeepInfer 的官方跑分在 SM100 上，两家的对照在 GB200/GB300 上。第三，也是最容易被忽略的一条：vLLM 没有重跑 DeepInfer。它是用自己实测的曲线去对照 DeepInfer 公布的图表数字，而 DeepInfer 的 README 里只有两张 PNG，没有给出单卡吞吐的绝对数值，也没有给 vLLM 基线。

所以"vLLM 已追平 DeepInfer"这个说法，在离线引擎这一半上是有依据的；在线服务那一半仍然悬着——DeepInfer 本体依旧只能离线推理，README 的"不包含"清单原样未动。SemiAnalysis 提出的"为什么 DeepInfer 不在 InferenceX 上"，到今天也没有标准答案。

vLLM 那篇工程博客里有两个数字更值得单独看：Wide-EP 配合 EPLB 把目标模型的负载均衡度从 0.35 提到 0.94；规模化之后仅 NIXL push（KV 数据推送式传输）一项修复，就把单 GPU 吞吐从 141K 提到 440K tokens/s。这说明 DeepInfer 开源出来的调度思路价值确实高——高到竞争对手在四天内就把它吃进去了。

五、昇腾 950 那一行，验收到什么程度

DeepInfer 的硬件支持列表里，除了 NVIDIA SM100，还赫然写着华为昇腾 950 NPU。构建时切换一个环境变量即可：NVIDIA 侧DEEPINFER_ACCELERATOR=nvidia（配 CUDA 13），昇腾侧DEEPINFER_ACCELERATOR=ascend（配 CANN 9.2）。

这个信号的份量被大多数解读轻描淡写了。DeepSeek 的线上服务真跑在国产卡上，不是 PPT 兼容——这对做国产卡方案的人，是"旗舰模型 + 国产卡"能跑通生产负载的一手证据。

但"支持"和"验证"之间有几道必须钉死的边界。

第一，两个关键特性只对英伟达开放。README 里 batch-invariant inference 和 deterministic sampling 两项都明确标注 NVIDIA only。昇腾路径拿到的是功能子集。

这一点有实际后果。如果你的场景既要结果可复现（Agent 工具调用、代码生成、离线评测都算），又要用国产卡，这两件事目前不能同时成立。

第二，官方跑分全在英伟达硬件上完成。prefill 用 4 张 SM100、decode 用 64 张，且各自在一个 scale-up 域内。截至发稿，公开材料里找不到第三方在昇腾 950 上复现 DeepInfer 的数据，DeepSeek 也没说明验证规模。

第三，"兼容昇腾"只写到厂商名称这一层。具体支持哪些芯片型号、覆盖哪些部署环境，官方说明没有列出，不能从"兼容英伟达与华为昇腾"推出对单卡或特定集群的适配结论。

那 99.8% 的硬件利用率数字是哪来的？那是另一个项目——9 月 30 日开源的 DeepGEMM-Ascend。官方基准在 Ascend 950DT 上测得 BF16 稠密 GEMM 达 431 TFLOPS，对应 432 TFLOPS 的理论上限的 99.8%（矩阵尺寸 M=4096、N=7168、K=16384，CANN 9.20，L2 冷）。

这个数字很硬，但它的边界同样要说清楚。它测的是矩阵乘这一个算子的一种精度一种形状，不是整模型性能。同样这批数据里，FP8 是 99.5%，FP4 是 98.3%；FlashMLA 的稀疏注意力在 prefill 阶段达 410 TFLOPS（理论值的 95%），decode 阶段只有 360 TFLOPS（83%）；DeepEP-Ascend 的 dispatch 带宽从 EP8 的 373–375 GB/s 掉到 EP128 的 313–320 GB/s。

用一个算子的峰值占用率去推断"昇腾跑 DeepSeek 没问题"，和用一个灯塔的亮度去推断整座港口的吞吐量，是同一类错误。

六、这件事到底改变了什么

DeepSeek 把支持放进 GitHub 之后，行业里出现两种反应，泾渭分明。

开源社区这边是振奋的。HN 讨论帖短时间内拿到 2100 多分、两千余条评论，Reddit r/LocalLLaMA 上最高赞的一条直接贴了构建脚本，配文就三个字。业内则有完全不同的看法，有从业者说得很直接：开放模型权重是完全合理的，但开源基础设施意味着让行业进入更激烈的价格战，“廉价客户是不存在的忠诚”。

这两种反应其实是同一件事的两面：推理工程能力第一次成为可复制的商品。

在此之前，模型厂商把内部降本转化为自己的报价优势，其他人要拿到同等成本，只能去买同样的硬件加同样的团队去调优。现在 DeepSeek 把自家那份调优方案放了出来，行业人士古源的判断是：DeepSeek 存在一个让云厂商为难的问题——权重虽然开放，第三方可以自行部署，但缺少原厂的推理工程积累，服务成本很难压到官方 API 那么便宜的价格，客户就直接向 DeepSeek 采购了。

从买方看，账是明的：模型权重早已公开，卡也买得到，真正拉开成本差距的是每秒能塞进多少 batch、prefill 要不要重算、专家并行时热专家怎么摊平。这些经验过去只存在于各家推理团队的内部文档里。

这张图是 DeepSeek 生产系统的一个简化剖面。KV 缓存、Prefill/Decode 分离、跨副本负载均衡这三条，正是这次开源明确没有给出的部分。开源的是中间那段"引擎"路径：Prefill 到 Decode 的算子与调度。它是这台机器的曲轴，但装它的那辆车还得自己造。

对做企业 AI 平台的团队，这件事给了一条更具体的判断标准。别问"要不要自建推理"，要问"我的负载形态能不能被 DeepInfer 的优化路径覆盖"。

具体说三层判断：

第一层，你的业务形态是什么。离线批量任务（数据标注、合成数据生成、批量评测）能直接吃到 DeepInfer 的调度收益，因为它的价值全在吞吐上；在线多租户 API 服务则不然——你缺的正是它没开源的那三样。

第二层，硬件对不对得上。手上是 H100/H800 的团队暂时只能看着，因为 Hopper 明确不在支持列表里。消费级显卡（如 RTX 5090，虽然同为 Blackwell 但是 SM120 架构）也不行。而且 V4.1-Flash 是 763B 参数、48 个 safetensors 分片约 510 GB，1-bit 量化仍需超过 128 GB 系统内存——本机这条路在物理上就不通。

第三层，收益从哪来。DeepInfer 官方跑分是 96% 前缀缓存命中下的结果，而 96% 命中意味着每 100 个请求里 96 个的前缀是"算过一次、后面全拿缓存"。这不是调优，是直接把成本曲线往下砍了一截。如果你的业务是大量不重复的长 prompt，前缀缓存命中不了，这个引擎的核心优势对你基本失效。

顺带说一个容易被漏掉的成本项。DeepInfer 把前向计算与调度优化开源了，但 3FS 存储层、KV 缓存分层（Block KV Cache 按 128 Token 切块存入 3FS，Agent 流量保留 3 天、聊天流量保留 7 天）、跨副本负载均衡这些仍然是自建成本。DeepSeek 自己的集群里这一层跑在约 100 PiB 的 SSD 上，聚合读取带宽约 10 TiB/s。

这件事对领码 SPARK 融合平台意味着什么

先说清楚立场：平台不能替企业决定要不要自建推理，也不该把某个具体引擎当成默认选项。平台能做的是让这个判断可执行、可追溯。

对应到这次开源暴露出的三个真实痛点：

其一，数据接入的边界要提前划清。推理层开源了，意味着一部分企业会把模型侧的敏感数据放到自己的卡上跑。这时候 iPaaS 那一层要做的不是"把所有数据都接进来"，而是把数据分级和流向约束前置——哪些数据允许进入推理侧、哪些必须在原地处理、哪些出了域就不可逆。治理中心前置到接入环节，而不是等到出事了再补权限。

其二，权限必须跟着数据走，不能长在系统边界上。DeepInfer 自己就是例子：权重开源了，模型可以随便部署，但"谁能看什么"这件事不会因为框架开源而自动解决。传统权限长在应用系统边界上，一旦数据被抽出来送到推理侧，权限就在抽取那一步丢了。领码的全域守卫要解决的是同一个问题：把"谁在什么域能看什么"做成一张可查询的表，让推理侧部署在哪个域、调用哪份数据、产出流向哪里，都能被记下来。

其三，和 Dify 这类应用编排层要分工。Dify 那一层解决的是"怎么把业务逻辑编排成 Agent 的调用链"，SPARK 关注的是"这些 Agent 拿到的是不是被授权的、干净的、能追溯的数据"。这次开源恰好说明这两层不会合流——DeepInfer 开源的是引擎层，编排层仍然要各家用各的。

一句话：DeepSeek 把引擎开源了，把编排和治理留在了各自手里。引擎可以换，标准和授权不能靠换一个引擎来顺带解决。

七、结语

这次开源的真实分量，比"全球首次"这个说法要小一些，但也更实在一些。

它不是"DeepSeek 把 AI 印钞机送给你了"。它是一件更具体的事：一个前沿实验室把自己线上跑的那份推理引擎公开了，同时诚实地列出了三样没给的东西，并且把最难解耦的三块留在了内部。

真正值得记住的有三件事：

第一，看开源别只看给了什么，看它承认没给什么。README 里那三行 “not included” 的价值，高过一百行性能宣传。

第二，任何"每卡每小时赚 38 美元"的说法，先问是收入还是利润、是谷价还是全天、是单集群还是全公司。这串数字在 24 小时里被读成收入、利润、回本周期三种东西，本身就是一个值得记住的传播样本。

第三，"支持昇腾 950"和"昇腾 950 跑出 99.8%"是两句话。前者是仓库里的一行字，后者是另一个项目里一个算子的一种精度一种形状。而官方基准全跑在英伟达硬件上，昇腾 950 的实机吞吐至今没有第三方复现数据。

对接下来想动手的团队，最该盯的不是 star 数，是三件套的开源节奏。README 已经写明 Prefill/Decode 分离"引擎侧大部分功能已实现"，留出了补齐空间。如果 KV 缓存与负载均衡在下一个模型版本前落地，DeepInfer 会从"参考实现"变成"可部署方案"；昇腾侧何时出现第三方实测，则决定"双平台"到底是能力还是姿态。

你现在手上的推理服务，是打算继续调 API，还是考虑自建？如果考虑自建，你的负载是"大量不重复的长 prompt"还是"高前缀复用的短对话"？这个问题的答案，会直接决定 DeepInfer 对你是引擎还是废纸。评论区说说你的场景，我按形态给你拆一下该看哪几个数。