DeepSeek开源推理引擎：日处理155万亿token的秘密

DeepSeek 近日开源了其 API 背后的推理引擎 DeepInfra，并附上一份详细的技术报告，解释了那些未开源部分的实现方式。据 DeepSeek 披露，单个集群运行这套技术栈，每天可服务 155 万亿个 token——这个数字足以让任何关注 AI 基础设施的人重新审视推理效率的天花板。

从单机推理到百万级并发：两个截然不同的硬件任务

在本地运行模型时，一切都很简单：一个用户、一个提示、一块 GPU 完成全部工作。但要把同一个模型同时服务给数百万人，这个设定会彻底崩溃。每个请求背后都隐藏着两个方向相反的硬件任务。

第一个是 pre-fill（预填充），模型一次性并行读取整个提示，构建对话的工作记忆——这也是 KV 缓存发挥作用的地方。第二个是 decode（解码），模型逐 token 写出回复，每个 token 都必须等待前一个 token 完成。用视频中的话说：「pre-fill 是一次性完成的大量数学计算，而 decode 是重复数千次的一小片数学计算。」

如果让每块 GPU 同时做这两件事，它们会互相干扰——一个大提示返回时，其他人的回答就会卡住。DeepSeek^广告 的解法是将两者分离到不同的机器上：pre-fill 是计算密集型任务，跑在常规的八卡 GPU 机器上；decode 是内存密集型任务，每个 token 都要读取模型权重和对话记忆，因此跑在数百块 GPU 组成的超级节点上。生产环境中，大约每块 decode GPU 对应一块 pre-fill GPU。

KV 缓存（Key-Value Cache）是 Transformer 推理中的核心机制。在自回归生成时，模型每产生一个新 token，都需要对之前所有 token 的 Key 和 Value 向量做注意力计算。如果每次都重新计算，代价会随上下文长度平方增长。KV 缓存的做法是把每一层已经算好的 Key/Value 向量存下来，后续生成时直接复用，只需为新 token 计算一份。因此缓存命中意味着省去大量重复计算。但这份缓存占用显存可观，上下文越长、并发越高，占用越大——这也正是 decode 阶段被归为“内存密集型”的根本原因：瓶颈不在算力，而在反复读取模型权重和这份不断增长的对话记忆。

KV 缓存保留数天与 96% 的缓存命中率

大多数公司只把提示缓存保留五分钟，而 DeepSeek 将这一时间拉长到了数天——面向 agent 流量保留三天，面向聊天保留七天。支撑这一策略的是一个专用数据集群，配备约 100 PB 的 SSD 存储。

效果惊人：据 DeepSeek 数据，所有输入 token 中有 96% 命中缓存，意味着模型只需要重新读取每 100 个 token 中的 4 个。这正是 API 对缓存输入收费低得多的原因。对于构建 agent 的开发者来说，保持提示前缀稳定是最便宜的优化手段——每次对话轮次都重发相同长上下文的场景下，这一点尤其关键。

预填充的巧思：分桶调度与滑动窗口重放

新提示部分进入 pre-fill 后，负载均衡器按长度将请求分成四个桶，避免短提示被 25 万 token 的巨型请求堵住。每块 GPU 的每一步都有时间预算，调度器预测在预算内能读取多少提示。

pre-fill 中最有趣的技术是「SWA 有界重放」。模型部分层使用滑动窗口注意力，只关注最近的 128 个 token。与其从头计算整个窗口，系统只重放提示末尾的短窗口——据 DeepSeek 称，这几乎消除了总预填充工作量。

滑动窗口注意力（Sliding Window Attention, SWA）是一种稀疏注意力变体：每个 token 只关注它前面固定长度（这里是 128 个 token）的局部窗口，而不是整个上下文，从而把注意力的计算和缓存开销从随长度增长降为常数级。代价是超出窗口的远距离信息不再被直接看到，通常通过多层堆叠让信息逐层间接传递。文中“SWA 有界重放”的关键在于：既然每层只关心末尾那个短窗口，那么重算时就不必从头处理整段提示，只重放提示末尾的窗口即可恢复所需状态，这解释了它为何能几乎消除总预填充工作量。

解码端的 MoE 专家调度与推测解码

decode 阶段使用混合专家（MoE）架构，每个 token 只激活一小群专用子网络。DeepSeek 将这些专家分散到 64 块以上的 GPU 上，每块 GPU 只持有少量专家，从而同时服务非常大的用户批次。问题在于某些专家远比其他的热门，最慢的 GPU 会拖慢整组速度。解决方案是每块 GPU 保留一个热门专家副本的备用槽位，系统每隔几千步根据流量情况移动这些副本。

最后一个加速手段是推测解码：一个小型草稿头猜测接下来的五个 token，大模型在单步中验证全部五个。DeepSeek 在此基础上增加了置信头，预测每个猜测被接受的概率，系统只花算力检查那些可能存活的猜测。据其数据，置信调度在检查五个 token 的基础上带来约 6% 的吞吐提升——在这个规模下，6% 意味着大量 GPU。

推测解码（Speculative Decoding）利用了 decode 阶段“逐 token 串行、GPU 大量闲置”的特点。它让一个更小更快的草稿模型先连续猜出若干候选 token，再由大模型一次性并行验证这些候选——验证的计算量接近只生成一个 token。若猜测被接受，就相当于一步产出多个 token；若被拒绝，则回退到第一个不一致处继续。其正确性由拒绝采样保证，输出分布与大模型单独生成一致，因此是“无损加速”。DeepSeek 额外加入的置信头则用于预判每个猜测的存活概率，把验证算力集中在更可能被接受的候选上。

批次不变模式：温度为零也未必可复现

一个容易被忽视的细节：即使 temperature 设为 0，同一提示在繁忙服务器上也可能得到不同答案。原因是 GPU 根据批次中请求数量选择不同的求和方式，微小的舍入差异可能翻转哪个 token 胜出。

DeepInfra 提供了批次不变模式（batch invariant mode），强制数学结果每次都相同。该模式默认关闭，因为每次用相同方式计算会更慢。如果需要为评估或调试 agent 获得可复现输出，应该开启这个设置。视频作者的本地实验也验证了这一点：同一个提示单独发送和放入批次后，答案在第 14 个 token 处发生改变，且每次运行都精确重复——说明这不是随机采样，而是批次构成确实影响了输出。

开源边界与硬件门槛

需要清楚 DeepInfra 的局限。开源版本只支持离线推理，可以在自己的电脑上运行。KV 缓存系统和负载均衡器与 DeepSeek 内部基础设施绑定，目前只提供了描述，代码尚未开放。

硬件方面，这些内核是为 NVIDIA 数据中心 Blackwell 芯片（如 B200）编写的，无法直接在 DGX Spark 等使用不同 Blackwell 芯片的设备上开箱即用。视频作者查看源码后发现，注意力库只为数据中心芯片构建，矩阵乘法库在其他架构上会抛出「不支持的架构」错误。建议在租用硬件前先确认项目的内核目标架构，重新编译无法解决这个问题。

如果想自己运行 DeepSeek v4.1 Flash，该模型已可在 vLLM 等常规引擎上运行——DeepInfra 最初也正是构建在 vLLM 之上。这种「基于开源、回馈开源」的路径，或许比任何单一技术细节都更值得关注。

安全细节：特殊标记永远保持纯文本

DeepSeekRecipe 组件负责将 OpenAI 或 Anthropic 格式的请求转换为模型期望的 token，并将输出转换回响应。看似无聊的转换层藏着一个安全问题：模型用特殊 token 标记用户消息结束和自己的回答开始。如果用户输入这些特殊标记，朴素的服务器可能将其转为真实控制 token，模型会误以为自己的回合已开始——这是 prompt 注入的常见手法之一。

DeepSeek 的实现确保用户输入的任何内容始终保持纯文本。视频作者的测试显示，当用户输入助手回合的起始标记时，朴素分词会产生两个助手回合，而经过 DeepSeekRecipe 处理后只剩一个，输入的标记变成了五个普通 token。

特殊 token（special token）是分词器中预留给模型控制结构、不对应普通文本的标记，例如标识用户消息开始/结束、助手回合开始的符号。它们在训练时被赋予明确的角色语义，模型会据此判断“现在轮到谁说话”。Prompt 注入的一种手法，就是诱导服务端把用户输入的字符串误当作这些控制 token 处理，从而伪造出“助手回合已开始”或“系统指令已结束”的假象，绕过原本的对话边界。防御原则很直接：用户内容在分词时必须走纯文本通道，任何形似特殊标记的字符串都只能被拆成普通 token，绝不能映射为真实控制 token。

规模背后的经济学

据 DeepSeek 数据，每块 decode GPU 每秒为其所有用户产生约 14000 个 token，同时每个用户仍能看到每秒数百 token 的流式输出速度。平均每块 GPU 每小时带来约 38 美元收入——这还是非高峰价格。需要警惕的是，网络上有人将这个数字换算成每吉瓦收入，但该数字基于非高峰价格、假设 GPU 全年满载，且依赖尚未开源的 KV 缓存系统。

这套系统的核心哲学可以归结为一句话：在规模上服务模型，主要是关于不重复做工作，以及永远不让 GPU 空闲。