DeepSeek 最新论文DSpark:让大模型说得更快
解决核心问题:
大模型生成文字像一个人写作文,必须一个字一个字地写,速度很慢。推测解码的思路是:先让一个小助理快速写一段草稿,再让主角(大模型)一次性检查整段,对的保留、错的纠正。
但现有方案有两个毛病:
1、小助理写的后半段经常跑偏。比如它想写of course,但of和course是各猜各的,结果可能拼出of problem,越往后越离谱。
2、检查浪费严重。明知道后半段大概率不对,还一个个去验证,白白浪费算力。
DSpark 的两个妙招
妙招一:边写边看前面写了什么
小助理写草稿时,前面的部分用并行快速生成(像打字机一次出一片),但从第二个字开始,用一个极轻量的模块看看前一个字是什么再写下一个。比如看到前面写了of,就自动偏向course而抑制problem。
这个看一眼的代价极低,只多了约 1% 的时间,但草稿质量大幅提升。
妙招二:不靠谱的就不查了
给草稿每个位置打个信心分。比如写代码,前几个字信心很高(0.95),可以放心验证;写闲聊时后几个字信心很低(0.3),就直接砍掉不查。
论文里有个直观数据:闲聊场景下,原来只有 45.7% 的草稿被接受,用了信心调度后跳到 95.7%,少做了一半多的无用功。
效果如何?
在 DeepSeek-V4 真实生产环境中:
- 用户感知的生成速度提升了 60%-85%
- 高并发时不再卡死,此前达不到的服务等级现在可以做到了
- 额外延迟开销仅 1%-2%
打个比方:原来一个 GPU 能同时服务 100 个用户且体验流畅,现在同样的硬件可以服务 160-185 个用户。
为什么重要?
这篇论文不只是一个算法技巧,是把草稿质量和系统调度打通了。就像餐厅不光要菜做得好(草稿质量高),还要会排号(智能调度验证顺序),两者结合才能让翻台率最大化。
DeepSeek 还开源了代码和模型,其他团队可以直接拿来用或改进,这对整个大模型推理加速领域是实打实的推动。
显示更多