梁文锋署名!DeepSeek发表重磅论文:如何让大模型跑得更快

倚天百科 百科资讯 4

6月28日消息,当行业在讨论谁的模型更聪明时,DeepSeek仍然把目光投向更现实的问题:如何让大模型跑得更快。

昨日,DeepSeek官方在Github低调发表了一篇最新论文,介绍其推理加速框架DSpark,试图解决大语言模型在高并发场景下的推理效率瓶颈。

从作者署名来看,这篇论文由DeepSeek与北京大学联合发布,值得注意的是,DeepSeek创始人梁文锋也位列作者名单。

在论文中,团队开源了DSpark模型权重,并同步发布了面向推测解码、由算法驱动的训练代码仓库DeepSpec。

DeepSeek首先解释了需要解决的问题。大语言模型采用自回归方式生成文本:每一个新词元的生成,都需要基于全部前置词元完成一次完整前向传播,结果是输出越长,等待越久。

由此带来GPU利用率低下、用户等待时间过长的问题,这是大语言模型线上服务的核心性能瓶颈,在实时对话助手、多轮智能体工作流等低时延敏感场景中尤为突出。

目前的主流方案分为自回归草稿模型(Eagle3)、并行草稿模型(DFlash)两条路线,二者各有缺陷,包括生成质量瓶颈和系统效率瓶颈等,且现有方案均缺乏负载自适应校验机制。

基于此,DeepSeek提出DSpark推测解码框架,采用半自回归生成架构:保留并行主干的高吞吐优势,同时加入轻量级串行模块,逐词元注入前缀依赖信息。

该模块提供两种实现——仅依赖前一个词元的马尔可夫头,以及通过循环状态累积完整前缀信息的RNN头。

实验表明,两层Transformer深度的DSpark即可在所有测试领域超过五层DFlash的接受长度。

目前,DeepSeek已经将DSpark部署到DeepSeek-V4在线服务系统中,并基于真实用户流量评估其实际性能。

结果显示,相较于现有生产环境基线系统MTP-1,在相同吞吐量条件下,DSpark将用户端生成速度提升了60%-85%。

此外,DeepSeek也将这一框架部署在其他模型上,以阿里旗下的Qwen3-4B、8B、14B三个模型为例,相较于自回归草稿模型,DSpark平均单轮可接受词元长度分别提升了30.9%、26.7%、30%;相较于并行草稿模型,DSpark分别提升了16.3%、18.4%、18.3%。