一天155万亿Token、每卡每小时38美元：DeepSeek把推理引擎DeepInfer也开源了，大模型的"毛利底牌"被摊开
一天155万亿Token、每卡每小时38美元：DeepSeek 把推理引擎 DeepInfer 也开源了
Part One：当"开源模型"变成"开源整条流水线"
2026 年 10 月 20 日下午，DeepSeek 做了一件在过去看来"不可能"的事：它把自己内部大规模生产环境真正在用的推理框架 DeepInfer，以 Apache 2.0 许可证完整开源，同步放出的还有生产级 Token 编解码组件 deepseek-recipe。
如果说过去两年大模型公司的"开源"还停留在模型权重这一层——你能拿到一个训练好的大脑，但怎么把这个大脑高效地接到几千万并发用户面前，各家都藏着掖着——那么 DeepInfer 的开源，等于把"大脑如何高效接活"的整套工程流水线也摊开了。开源地址分别是 github.com/deepseek-ai/DeepInfer 与 github.com/deepseek-ai/deepseek-recipe。
更狠的是，DeepSeek 同时公布了一组冷冰冰的线上生产数据，第一次让外界看清了"高效推理"到底值多少钱：
- 基于 DeepInfer，DeepSeek V4.1 Flash 单集群日吞吐量达到 155 万亿 Token；
- 线上平均每个请求输入 77K Token，首字延迟（TTFT）平均只要 400 毫秒；
- 生成阶段每秒输出 230 个 Token，写代码场景能冲到 300 个；
- 平均 96% 的输入能直接命中缓存，根本不用重算；
- 按 API 谷价（最便宜时段价格）计算，平均每张卡每小时收入 38 美元（约合人民币 254 元）。
最后一个数字在 Hacker News 上被形容为"一枚核弹"。有人据此算出毛利率高达 82%：假设你以每小时 7 美元的价格租一张 B300 显卡，只要 API 使用率足够高，扣掉租金后仍有可观余量。它用一种近乎赤裸的方式告诉市场——大模型推理不是赔本赚吆喝，只要算力不闲着、调度足够高效，低价 API 和可观毛利可以同时成立。
这篇文章我们不聊商业故事，只拆工程。DeepInfer 究竟用了哪些手段，把 GPU 的空转压到最低、把重复计算降到最低、把延迟拆开分别优化？这些技术里，哪些是通用方法论、值得每个做推理部署的工程师抄作业，哪些又带着 DeepSeek 深深的内部基础设施烙印、开源版本里其实没有？
先给一张全局架构图，后面逐块拆解。
用户请求 (Chat / Responses / Messages API)
|
v
+--------------------------------------+
| deepseek-recipe 编解码层 |
| 特殊Token边界识别 / 普通文本分段并行 |
| 流式UTF-8状态机 / JSON片段直出 |
+--------------------------------------+
|
+-----------------+------------------+
| |
v v
+------------------+ +---------------------+
| Prefill 集群 | | Decode 超节点 |
| 8卡机 EP2~8/DP2~8| | 64~128卡 EP64~128 |
| 优化 TTFT | | Wide-EP 优化 TBT |
+------------------+ +---------------------+
| |
| 专家并行 / 动态负载均衡 / 自动扩缩容 |
+-----------------+-------------------+
|
v
+--------------------------------------+
| 共享 KVCache 存储 (3FS 集群 ~100PiB)|
| 128Token切块 / 4层mainKV / TTL 3~7天 |
| 读10TiB/s 写850GiB/s 任意前缀命中 |
+--------------------------------------+
|
+-----------------+------------------+
| DSpark投机解码 SWA Bounded Replay |
| Confidence变长验证 (+4~7%吞吐) |
+--------------------------------------+
|
英伟达 SM100 GPU / 华为昇腾950 NPU
Part Two：推理系统的三条主线——吞吐线、成本线、延迟线
读懂 DeepInfer，先要理解大模型推理在工程上其实是三个相互拉扯的目标。DeepSeek 知乎技术报告（《DeepSeek-V4.1-Flash-1017 推理系统》）把它们拆成了三条独立优化的"线"：
- 吞吐线：怎么让 GPU 尽量不空转，单位时间吐出尽可能多的有效 Token；
- 成本线：怎么让重复的 prefill 计算尽量少做，能复用就复用；
- 延迟线：首字等待（TTFT）和后续 Token 间隔（TBT）分别是两种负载，要分开优化。
普通用户对推理的认知是"发请求→等回答"，但服务端要同时处理：成千上万请求共享一批芯片、从显存读取巨大的模型参数、跨多台设备调度计算与通信、管理 KV Cache、控制排队和生成延迟。同一个模型，用不同的推理实现，每张卡能同时服务多少用户、用户要等多久，可以差出几倍甚至一个数量级。 推理框架就是来抹平这个差距的。
DeepInfer 本身基于 Python 构建，最初主要建立在 vLLM 之上，并借鉴了 SGLang 与 TensorRT-LLM 的思路。它并不是从零造轮子，而是把业界最优实践和 DeepSeek 自研算子深度缝合：集成了 FlashMLA（注意力）、DeepGEMM（矩阵乘）、DeepEP（专家并行通信）、TileKernels、DeepSelect，以及自研的 TileLang 编译内核，覆盖注意力、矩阵乘与通信这些最关键的计算路径。
我们先从最能体现"硬件组织哲学"的 Prefill/Decode 分离看起。
2.1 为什么 Prefill 和 Decode 必须分家
大模型处理一个请求分两个性质完全不同的阶段：
- Prefill（预填充）：一次性把整段输入提示词（平均 77K Token）读完、算完，这是一个**计算密集（compute-bound）**的大活，像"批量吞进一本书"；
- Decode（解码）：之后一个 Token 一个 Token 地往外蹦答案，每一步都要把全部模型权重从显存读一遍却只算出一个 Token，这是一个**访存密集（memory-bound）**的细活，像"一个字一个字往外吐"。
把这两种负载混在同一批卡上，结果就是互相拖累：Prefill 的大块计算会卡住 Decode 的节拍，让正在吐字的用户感觉到卡顿；Decode 的低算力利用率又浪费了 Prefill 本可以用满的算力。
DeepSeek 的做法是物理分离部署，并且针对两个阶段配置了完全相反的并行度：
阶段 硬件组织 并行度取值 优化目标
-----------------------------------------------------------------
Prefill 8卡机 EP2~8 / DP2~8 TTFT（首字延迟）
（显存够就取小） 小并行，单机算完 大batch、高矩阵乘效率
Decode 64~128卡超节点 EP64~128 / DP64~128 TBT（吐字间隔）
（卡够就取大） Wide-EP 大并行 单卡参数少、接更多请求
这个"Prefill 取小、Decode 取大"的反直觉配置，核心逻辑在于 V4.1 Flash 是一个有 384 个路由专家的 MoE 模型。在 Decode 阶段，DeepSeek 把这 384 个专家摊到 64 张卡上，每张卡只放 6 个专家，再额外放 1 个热门专家的副本，一共 7 个。每张卡上常驻的专家越少，每生成一个 Token 要从显存读取的参数量就越小，同样一批卡就能同时接住更多并发请求。官方离线测试里，64 卡一组跑 Decode，每张卡每秒最多能输出 2.6 万多个 Token。
Part Three：MoE 专家并行与四类负载均衡器
MoE 模型推理最大的工程难题是负载不均：虽然每个 Token 理论上只激活少数几个专家，但真实流量下"热门专家"会被打爆、“冷门专家"闲得发慌。如果不做处理，几张热点卡会成为整个超节点的瓶颈。
DeepInfer 用了四类负载均衡器，分别对应四种负载，且 Prefill 侧的四级调度共用一张"代价模型”，所有调度决策最终都落到统一的 compute-quota（计算配额）上：
负载类型 均衡策略 moe_lb 均衡度
-----------------------------------------------------------------------
Prefill 四级调度共用代价模型 EP2/DP2: 1.0320
EP4/DP4: 1.0618
Decode 两维均衡（专家 + 流水） 1.090
Vision Encoder 按 patch 粒度分配（通常单卡） --
EP（专家并行） 冗余专家参数 + 动态重排 --
moe_lb 是负载均衡度指标，越接近 1 说明各卡负载越均匀。可以看到 Prefill 在小并行度下能压到 1.03，Decode 因为超节点规模大、路由更随机，松弛到 1.09，但都保持在很窄的失衡带内。其中 EP 均衡用的是"冗余专家参数 + 动态重排"：提前给热门专家准备副本（就是前面说的每张卡那第 7 个专家），运行时再根据实时负载动态调整专家放置。
我们用一段简化 Python 模拟"专家热度不均 + 冗余副本"的基本思想，帮助理解为什么复制热门专家能压住长尾延迟：
import numpy as np
class ExpertPlacement:
"""简化模拟 MoE Decode 阶段的专家放置与负载均衡"""
def __init__(self, n_experts=384, n_cards=64, replica_budget=64):
self.n_experts = n_experts
self.n_cards = n_cards
# 384 个专家均匀铺到 64 张卡，每卡 6 个
self.placement = {e: e % n_cards for e in range(n_experts)}
self.replica_budget = replica_budget # 额外副本配额（每卡 1 个）
self.replicas = {} # 专家 -> 副本所在卡
def add_hot_replicas(self, hotness):
"""按热度排序，给最热的专家各加一个副本，摊薄热点"""
ranked = np.argsort(hotness)[::-1]
for i, expert in enumerate(ranked[:self.replica_budget]):
self.replicas[int(expert)] = i % self.n_cards # 副本轮询放置
def card_load(self, token_experts, hotness):
"""统计每个 Token 路由后各卡承担的负载（含副本分流）"""
load = np.zeros(self.n_cards)
for e in token_experts:
primary = self.placement[e]
if e in self.replicas:
# 有副本时按主/副当前负载选更空闲的卡（最小连接思想）
rep = self.replicas[e]
card = rep if load[rep] < load[primary] else primary
else:
card = primary
load[card] += hotness[e]
return load
# 构造 Zipf 式偏斜热度：少数专家承接绝大多数 Token
rng = np.random.default_rng(0)
hotness = rng.zipf(1.3, size=384).astype(float)
tokens = rng.choice(384, size=100000, p=hotness / hotness.sum())
pl = ExpertPlacement()
before = pl.card_load(tokens, hotness)
pl.add_hot_replicas(hotness)
after = pl.card_load(tokens, hotness)
def imbalance(load):
return load.max() / load.mean()
print(f"无副本时 max/mean 失衡度: {imbalance(before):.3f}")
print(f"加热门副本后失衡度: {imbalance(after):.3f}")
print(f"热点卡峰值负载下降: {(1-after.max()/before.max())*100:.1f}%")
跑这段代码会看到，仅给最热门的 64 个专家各加一个副本、并把请求动态分流到更空闲的卡，热点卡的峰值负载就能显著下降。这正是 DeepSeek 用"冗余专家 + 动态重排"保护 Decode 尾部延迟的微观原理。注意这只是教学模型，真实系统里专家放置还要考虑跨卡通信代价（DeepEP 做的全到全通信）和超节点拓扑。
Part Four：成本线——把重复 Prefill 压到极致
如果说吞吐线靠"组织硬件"，那成本线靠的就是"绝不重复计算"。这是 DeepInfer 工程含量最高、也最能解释 96% 缓存命中率的部分。
4.1 KVCache 长期留存：3 天、7 天，而不是 5 分钟
长对话和 Agent 场景有个鲜明特征：调用一次工具后，下一轮请求往往会再次带上前面的系统提示、工具说明和历史记录。如果每次都从头算这些重复前缀的 KV，浪费惊人。
主流厂商（Anthropic、OpenAI、Google）的 KVCache 保留时间大多在 5 分钟到 24 小时之间，而 DeepSeek 直接把目标设到 72 小时以上，线上 TTL 策略是：
- Agent 流量保留 3 天；
- Chatbot 流量保留 7 天。
它做过消融：把 chatbot 的 TTL 从 7 天砍到 3 天，命中率会下降 0.5%~1%。在每天百万亿 Token 量级下，这零点几个百分点就是巨额算力。
4.2 Block KVCache 不落本机内存：100PiB 的 3FS 共享集群
长期留存最大的工程障碍是：KVCache 体量巨大，单机显存/内存根本放不下，而且如果缓存在某台 Prefill 机上，只有路由到那台机器的请求能命中，这叫"前缀亲和路由"，会严重束缚调度。
DeepSeek 的解法非常激进：Block KVCache 根本不进本机内存，而是按 128 Token 切块、组织成 4 层 mainKV，落到一个独立的 3FS 分布式存储集群：
+-------------------------------------------------------------+
| 3FS 共享 KVCache 集群（约 100 PiB SSD） |
| |
| 读取带宽 ~10 TiB/s 写入带宽 ~850 GiB/s |
| 面向 ~112 KiB block 粒度的随机读写 |
| |
| 任意一台 Prefill 机器 -> 可命中任意前缀的缓存 |
| （代价：放弃前缀亲和路由，换来全局命中率最大化） |
+-------------------------------------------------------------+
^ ^ ^ ^
| | | |
Prefill机A Prefill机B Prefill机C Prefill机D
把缓存放到一个读带宽 10TiB/s 的共享 SSD 集群上，换来的是"任意 prefill 机器可命中任意前缀“的全局共享能力，调度器再也不用为了命中缓存而把请求绑死在固定机器上。这是用分布式存储的随机读能力，换调度自由度和命中率。
4.3 SWA 与 Bounded Replay：只重算最近 128 个 Token
V4.1 架构里还有一类特殊的稀疏注意力 SWA（Sliding Window Attention，滑动窗口注意力），对应 20 层 × 134 的 ring 结构。它的特点决定了不同的缓存策略：只留在本机内存、不持久化，TTL 约 180 秒，命中率 98% 以上；一旦没命中，就由 Bounded Replay 机制重算。
这里有个版本演进的关键教训：V4 时代曾尝试把 SWA 也落盘，结果占掉了持久化 VCache 近一半的容量，却换不到相应的命中收益——因为滑动窗口注意力本来就只关注最近一小段上下文，长期缓存意义不大。V4.1 改成了 Bounded Replay：未命中时只重算最近的 128 个 Token，让 Decoder 侧总的 prefill 计算量近乎减半。
这是一个很典型的工程判断：不是所有 KV 都值得持久化，对"只看最近"的注意力，重算一小段比长期存一大片更划算。
Part Five：延迟线——TTFT 与 TBT 分开打，外加投机解码
5.1 编码器/Prefill/Decode 三段解耦
前面的硬件分离已经为延迟优化铺好路：Prefill 侧资源专门优化 TTFT（用户等首字的时间），Decode 侧资源专门优化 TBT（字与字之间的间隔）。此外还有几个容易被忽略、却直接影响体感的细节：
- chunk size 按时间预算反解：不是拍脑袋定每个微批处理多少 Token，而是由目标时延倒推每个 chunk 的大小；
- 分词不拖 TTFT：分词从线性处理改为分段并行——特殊 Token 之间的普通文本独立编码再按序拼接，核心路径用 Rust 实现；
- 边生成边返回：用跨 chunk 状态机缓冲不完整的 UTF-8 码点，按思考/正文/工具参数分阶段维护状态，用 KMP 算法增量匹配分隔标记，不回溯已确定文本；
- 工具参数不整体构造：按 DSML 边界直接输出 JSON 片段、字符串逐段转义，缩短第一个参数片段的等待时间。
这些"抠门"到字节级的优化，共同把平均首字压到了 400 毫秒。
5.2 DSpark 投机解码：置信度决定验证长度
投机解码（speculative decoding）的思路是用一个小"草稿模型"先快速猜一串候选 Token，再交给大模型一次性并行验证，猜对的部分直接采纳，从而加速解码。传统做法是固定验证 5 个候选 Token。
DeepSeek 的 DSpark 框架更进一步：用一个 Confidence Head（置信度头）估计每个候选 Token 的接受概率，动态决定这一批验证多长——草稿模型很有把握时就多验证几个，没把握时就少验证，避免把验证算力浪费在注定被拒绝的候选上。它还用低秩 logit bias 校正草稿模型与主模型之间的系统性偏差。
线上数据：相比固定验证 5 个 Token，变长验证在生产工作点带来约 4%~7%（官方一处口径为 6%）的吞吐提升。我们用一段代码说明"固定验证"为什么浪费、“按置信度分配"为什么更优：
def fixed_verify_accept(accept_probs, k=5):
"""固定验证 k 个候选：不管把握多大都花 k 份验证算力"""
accepted, cost = 0, 0
i = 0
while i < len(accept_probs):
window = accept_probs[i:i+k]
cost += k # 固定付出 k 个候选的验证成本
run = 0
for p in window:
if p >= 0.5: # 简化：概率≥0.5 视为被接受
run += 1
else:
break
accepted += run
i += max(run, 1)
return accepted, cost
def adaptive_verify_accept(accept_probs):
"""变长验证：置信度高多验证、低则少验证，省下的验证算力可服务更多请求"""
accepted, cost = 0, 0
i = 0
while i < len(accept_probs):
# 置信度头预测：用累计置信度决定本批验证窗口长度
window = accept_probs[i:]
v = 0
cum = 1.0
for p in window:
v += 1
cum *= p
if cum < 0.25 or v >= 8: # 联合置信度过低或达到上限即停
break
v = max(v, 1)
cost += v
run = 0
for p in accept_probs[i:i+v]:
if p >= 0.5:
run += 1
else:
break
accepted += run
i += max(run, 1)
return accepted, cost
rng = np.random.default_rng(42)
probs = rng.beta(2, 2, size=2000) # 模拟候选 Token 接受概率
a1, c1 = fixed_verify_accept(probs.tolist(), k=5)
a2, c2 = adaptive_verify_accept(probs.tolist())
print(f"固定验证: 采纳 {a1:5d}, 验证算力 {c1:6d}, 单位算力产出 {a1/c1:.3f}")
print(f"变长验证: 采纳 {a2:5d}, 验证算力 {c2:6d}, 单位算力产出 {a2/c2:.3f}")
print(f"单位验证算力吞吐提升: {(a2/c2/(a1/c1)-1)*100:.1f}%")
核心直觉是：验证一个注定被拒的候选，纯粹是烧钱。 让验证长度跟随草稿置信度伸缩，就能把同样的验证算力花在刀刃上。此外 DeepInfer 还用 CPU 与 GPU 的异步协作，让请求调度、前向计算、采样尽量重叠，把 Decode 各步之间的 GPU 空档用 CPU 侧逻辑填满（流水线重叠）；容错上也不依赖"快速重启”，而是靠多留机器、请求重路由、降级重启来保证可用性。
Part Six：双硬件平台与 deepseek-recipe，以及"没开源的那部分”
6.1 英伟达 + 华为昇腾双平台
DeepInfer 明确支持两套硬件：
- 英伟达平台：需要 CUDA 13 与 SM100 架构 GPU（Blackwell 一代）；
- 华为昇腾平台：需要 CANN 9.2 与 Ascend 950 NPU。
从源码构建时按平台选择对应的加速器环境变量即可。这延续了 DeepSeek 一贯的"多厂商芯片"路线——它自己就是国内从训练到推理深度绑定国产算力的代表，推理框架层面的双平台兼容，等于把"国产 NPU 也能跑出极致推理效率"的方法论一并公开。
6.2 deepseek-recipe：让第三方部署"行为一致"
同一个模型，官方 API 和第三方部署用起来常常"手感不同"，很多差异其实来自请求编解码、流式解析、工具调用格式处理这些琐碎但关键的细节。deepseek-recipe 就是来解决这个问题的生产级编解码组件：
- 支持 Chat Completions API、Responses API、Messages API 三大主流接口；
- 通过特殊 Token 边界识别、普通文本分段并行编码、流式输出解析等机制提升长文本处理效率；
- 确保第三方部署的 API 处理逻辑与官方服务保持一致，覆盖思考内容、工具调用、流式输出。
对要把 DeepSeek 模型接进已有 Agent 工作流的企业来说，这一层的价值不亚于推理引擎本身——它直接决定"换个服务端，应用会不会行为漂移"。
6.3 必须诚实：开源版本缺了什么
DeepSeek 没有把整套线上系统一股脑全开源。官方明确说明，KV Cache 管理和负载均衡这两部分因为与内部基础设施（3FS 集群、超节点组网、统一配额系统）耦合过深，代码并未完整开源。 开源仓库提供的是：
- 离线推理与规模化服务所需的核心引擎能力（优化算子、并行策略、投机解码、结构化输出、异步调度）；
- 但要搭出和官方同等的完整线上服务，你仍需自己补齐 KVCache 系统、视觉编码、Prefill/Decode 分离部署、跨副本负载均衡。
换句话说，DeepSeek 把"发动机图纸"开源了，但"整车的传动系统和路谱数据库"还得自己造。这是务实的边界——既兑现了开放承诺，又不至于把和自家数据中心血肉相连的那部分硬剥出来（剥出来别人也跑不起来）。
Part Seven：这门"推理生意"的经济学，以及对行业的意味
最后回到那个刷屏的数字。每卡每小时 38 美元收入，按一张 B300 每小时约 7 美元的租用成本，市场据此推算出 80% 上下的毛利率。另有对照：The Information 上月披露 DeepSeek 年化收入约 10 亿美元（约每天 274 万美元），如果按每卡每小时 38 美元倒推，等效只需要约 3000 张卡就能产生这个收入量级。
当然，这两个数字都应谨慎看待：38 美元是按谷价且假设高利用率的理想口径，82% 毛利也只扣了 GPU 租金、没有计入模型全生命周期的训练投入、数据成本、研发人力和数据中心建设。Hacker News 上的争论也集中于此——一派认为这证明"AI 没有泡沫、推理是门好生意"，另一派提醒必须算上整个生命周期成本。
但无论口径如何，DeepInfer 的开源传递了三个确定的行业信号：
- 推理效率本身就是核心竞争力，而非模型能力的附属品。 模型架构逐渐趋同后，决定单位算力能服务多少用户、卖多低价还能赚钱的，正是这套系统工程。
- 开源的边界正在从"权重"推进到"全栈"。 模型、算子库（TileLang）、推理引擎（DeepInfer）、编解码组件（recipe）逐层开放，第三方搭建私有化/公有云 AI 服务的门槛被系统性拉低。
- 极致效率同时支撑低价与盈利，这会重塑整个 API 市场的价格曲线。 当全世界都能看到 DeepSeek 如何让一张卡"多快好省"地接活，推理侧的竞争只会更卷，最终受益的是每一个调用 API 的开发者。
研究员 Deli Chen 在开源时说了一句被广泛转发的话，大意是开源与闭源是两种未来的较量。对工程师而言，更实在的好消息是：从此你不只是能用上一个便宜的模型，还能看清它背后那台"一天吞掉 155 万亿 Token"的机器是怎么造的，并把其中的 Prefill/Decode 分离、KVCache 分层复用、置信度投机解码，搬进自己的系统里。
这，或许才是 DeepInfer 开源最有分量的地方。
参考资料：DeepSeek 知乎技术报告《DeepSeek-V4.1-Flash-1017 推理系统》、GitHub
deepseek-ai/DeepInfer与deepseek-ai/deepseek-recipe、36氪、智东西、机器之心、MarkTechPost 等公开报道（2026-10-20）。文中代码为原理演示，非官方实现。