突发,DeepSeek重磅开源核心推理引擎 - 爱游戏体育
源神归来!
就在不久前,DeepSeek再次发布重大举措,完全开放其自主研发的推理框架DeepInfer。
一个集群每日可处理155万亿Token,DeepSeek V4.1 Flash实现高吞吐、低延迟的大规模推理,正是依赖于此。
开源地址:https://github.com/deepseek-ai/DeepInfer 开源地址:https://github.com/deepseek-ai/deepseek-recipe
一同发布的,还有生产级Token编解码组件deepseek-recipe。
英伟达SM100 GPU、华为昇腾950 NPU,均在其支持范围之内。
DeepSeek还在知乎发布了技术详解文章,并在GitHub上提供了一份部署问答,从架构设计到部署细节,全面公开了这一系统。
根据官方公布的线上数据,平均每个请求输入77K Token,首个字的平均响应时间仅为400毫秒。生成阶段每秒可输出230个Token,编写代码时可达300个。
平均96%的输入能够直接命中缓存,无需重新计算。
按谷价计算,平均每张卡每小时的收入为38美元。
如今,全世界都能看到DeepSeek是如何实现大模型高效运作的。
DeepSeek研究员Deli Chen更是发出豪言。
开源与闭源。光明与黑暗。两种未来、人类两种命运之间的对决。他们想打多久,我们就打多久。直到取得完全胜利。
评论区中,满是开发者的热烈反响。
正如网友所言,模型开源已是“常规操作”,如今连推理引擎也开源,格局直接拉满。
此前,DeepSeek已开源了一系列大模型、用于开发高性能算子的TileLang以及多个推理算子库。
这一次,从请求进入系统到生成答案的每一个环节,DeepSeek都毫无保留地公开了如何节省算力。
一个请求,兵分两路
模型处理一个请求分为两步。第一步是Prefill,模型一次性读取系统提示、聊天记录、文件和问题,每个Token在每一层都会计算出一组中间结果,即KV缓存。
第二步是Decode,模型逐个Token生成答案,每生成一个,都需要利用之前所有的KV缓存。
这两步消耗的资源截然不同。Prefill一次处理数万个Token,考验的是算力。
Decode一次只生成一个Token,大部分时间用于从显存中读取参数和缓存。
因此,DeepSeek将这两步分配到不同的机器上。Prefill使用常见的8卡机器,Decode使用64到128卡的超节点。
请求中若包含图片,会先交由独立部署的图像编码服务处理。
实践中,两边所需的卡数大致为1比1。根据官方建议,要实现高效运行,最小部署单元是64卡Prefill加64卡Decode。
官方API那套逻辑,也开源了
请求进入系统后,首先经过deepseek-recipe处理。
目前主流的API格式有三种:OpenAI的Chat Completions和Responses,以及Anthropic的Messages。
deepseek-recipe将它们统一转换为同一种对话格式,然后根据模型版本拼接prompt并编码成Token。模型输出的Token,也由它转换回各自格式,以流式方式返回。
它还顺手堵住了一个漏洞。DeepSeek的模型依靠一批特殊Token来标记对话结构,比如用户发言的起始位置、思考的结束点、以及何时调用工具。
96%的输入,不用再算第二遍
Agent每次调用工具时,都需要将系统提示、工具说明,连同之前每一轮的回复和工具结果,全部重新发送给模型。
其中绝大部分内容,上一轮已经计算过。
DeepSeek的做法是,将计算过的KV缓存保存下来,下一轮只计算新增的部分。前提是前缀必须从第一个Token开始完全一致,中间重复的内容无法复用。
效果有多显著呢?同一张卡运行Prefill,不考虑缓存命中时,每秒处理6万个Token。
考虑缓存命中后,每秒处理150万个,相差整整25倍。
这些缓存全部存放在DeepSeek自家的3FS存储集群中,容量约100PiB,全部使用固态硬盘。Agent流量的缓存保留3天,聊天流量保留7天。
聊天流量保留时间更长,是因为少数缓存会被频繁读取多次,一旦丢失,整体命中率会大幅下降。根据DeepSeek的经验,若聊天流量只保留3天,命中率会下降0.5%到1%。
缓存单独放入存储集群后,任何一台Prefill机器都能读取到任意一段缓存,用户无需绑定到之前使用的机器上。而且,计算机器的故障率比存储高出至少一个数量级,机器损坏后,缓存依然存在。
没命中?只补算128个Token
V4.1 Flash的部分层采用了滑动窗口注意力机制(SWA),每个Token只关注离自己最近的128个Token。
注意力计算也仅在这128个Token内进行,得到一份近似的窗口缓存。重算成本因此变为常数,无论上下文多长、模型多少层,都不受影响。
同样的方法还应用于模型的其他20层。这20层每次Prefill都需要重建窗口缓存,原本需要计算最后2560个Token,现在只计算128个,Prefill的总计算量因此减少了近一半。
一步吐出好几个Token
进入Decode阶段,模型每计算一步,原本只能生成一个Token。
DeepSeek自研的DSpark又向前迈进了一步。它先估计每个猜测被接受的概率,概率低的直接跳过不验证,将验证算力分配给其他请求。
与固定验证5个相比,线上吞吐量提升了6%。
在两步计算之间,CPU需要安排下一步的请求、处理上一步的结果,GPU原本只能闲置等待。DeepInfer让两边同时工作,GPU计算第N步时,CPU已经在安排第N+1步。
这一系列组合下来,线上Decode阶段每张卡每秒能生成1.4万个Token。
384个专家,摊到64张卡上
V4.1 Flash是MoE模型,内部包含多组“专家”参数,每个Token只会用到其中几组,仅路由专家就有384个。
在Decode阶段,DeepSeek将这些专家分配到64张卡上,每张卡放置6个,外加1个热门专家的副本,共7个。每张卡上的专家越少,每一步需要从显存中读取的参数就越少,同等数量的卡就能处理更多请求。
官方离线测试中,64卡一组运行Decode,每张卡每秒最多可输出2.6万多个Token。
热门专家的副本也会动态调整,每1000步统计一次负载,每10000步重新分配。线上实测表明,负载最高的那张卡仅比平均水平高9%。
请求也需要均匀分配。Prefill根据输入长度分为4档,每档分配多少机器,根据上一轮的需求动态调整。
Decode同时考虑每张卡上的请求数和缓存总长度,短请求分配给请求少、缓存长的卡,长请求分配给缓存短的卡。
通过这一调度,系统整体性能可达到离线测试中完全均衡状态的80%左右。
即使是跨机房部署,DeepSeek也在问答中给出了答案。V4.1 Flash大幅压缩了KV缓存,跨机房在技术上可行,每8张卡配备约400Gbps的互联带宽即可,但可能牺牲可靠性,因为“跨机房的光纤容易被挖断”。
DeepSeek自己的推理节点,就部署在位置不同但相邻的机房中。
把智能的价格,打下来
此次开源的DeepInfer采用Apache 2.0协议,deepseek-recipe采用MIT协议。DeepInfer目前支持V4.1 Flash,最初主要基于vLLM搭建,也参考了SGLang和TensorRT-LLM。
开源版本目前提供的是离线推理。KV缓存管理和负载均衡由于与内部基础设施绑定较深,代码暂时未完整开源,但设计细节已写入长文和问答。
DeepSeek此次分享的内部部署经验,主要目的是降低算力成本、减少能源消耗,让更广泛的人群用得起智能。
接下来,DeepSeek新模型的推理代码和性能优化,都将在DeepInfer中持续开源。
从模型、TileLang、算子库,到推理框架和API编解码,DeepSeek的开源,已从模型本身一路延伸至每日155万亿Token的线上服务。
这次官宣,DeepSeek起的标题是“走向真正普惠的未来”。
本文来自微信公众号“新智元”,作者:ASI启示录,36氪经授权发布。