★ FEATURED ARTICLE 有人把过去这一年称为大模型的“算力军备竞赛年”各家拼命囤卡、堆集群、刷新训练规模。但DeepSeek这次爆火直接把话题从“你有多少卡”拽到了“你有多会省卡”。如果你去看它的技术报告和开源内容会发现一个非常反直觉的事实它并没有用史无前例的算力去碾压对手反而在“注意力机制”这个最底层的计算环节做了一整套效率革命。参数更大、成本更低、推理更快这几个原本互相冲突的目标居然被同时实现了。这篇文章我想从技术角度把这件事拆开聊一聊。核心就一条线注意力机制在数学上到底有多“烧算力”DeepSeek又是怎么从架构到工程把这笔账算明白的。无论你是做AI应用开发的还是在做技术选型决策或者只是好奇为什么这家公司的API价格能压到那么低这篇内容应该都能给你一些可以直接用的思路。1. 先说结论DeepSeek的火爆不是偶然是注意力机制的一次算力翻身仗1.1 一场不被看好的“逆袭”我最早注意到DeepSeek是很早之前在某个技术群里看到有人分享它的开源模型权重。当时大家的普遍反应是“又一个开源大模型先观望”。因为那段时间开源阵营虽然热闹但大多还是处在“追平GPT-3.5”的阶段真正让人眼前一亮的产品级表现并不多。转折点发生在它发布新一代模型之后。很多人第一次用DeepSeek第一反应不是“它比某某模型强多少”而是“怎么这么便宜”“怎么这么快”。这里就隐藏着关键信息对于普通用户来说使用体验的“快”和“便宜”本质上是算力效率的外在表现。一个模型如果在推理时能省掉一大半的显存占用和计算量那么在相同的硬件条件下它能服务的用户数就是别人的好几倍单次请求成本自然能压到很低。我后来专门去翻了它的技术资料才发现真正厉害的地方不在某个单一技巧而是围绕注意力机制做了一整套组合拳。整套方案下来的结果就是在保持模型能力的同时把训练和推理阶段对算力的需求都大幅降低了。这跟单纯堆参数、堆数据量的传统路线是有本质区别的。1.2 注意力这个词和大众理解的“注意力”不是一回事聊技术之前得先把“注意力”这个概念说清楚。很多人听到注意力会天然联想到“模型学会了关注重要内容”这在直觉上没错但从数学层面看它就是一种加权求和的运算。Transformer模型里每个词技术上叫token都会被转换成三个向量Query、Key、Value。Query可以理解成“我在找什么”Key是“我身上带什么标签”Value是“我实际提供的信息”。模型计算一个词和其他所有词之间的匹配程度也就是用Query去点乘所有的Key得到一堆分数再用这些分数对Value做加权求和。这个过程就是一次注意力计算。这个机制妙就妙在它让模型有了全局关联能力——句子再长任意两个位置的词都能直接建立联系。但也正是因为这种“任意位置两两之间都要算一遍”的设计带来了一个让人头疼的复杂度问题。这个复杂度问题才是DeepSeek真正去挑战的核心。2. 注意力机制大模型最烧钱的数学引擎2.1 从课堂笔记到加权求和注意力到底在算什么为了把注意力机制讲得更好理解我经常举一个课堂笔记的例子。假设你在一间教室里听课班级里有几十个同学每个人都在说话。你要写一份笔记记录当前最有价值的信息。你不可能把所有人的话都同等对待——你会重点关注正在讲课的老师、写在黑板上的公式可能还会偶尔听到旁边同学小声补充的一个知识点。这种对不同信息源的重要性分配就是注意力的直觉理解。在大模型里这个过程被形式化成了一套计算公式。模型在读取一串文本时每个token都会生成三个向量然后通过点积运算去计算“每个token相对于其他token的重要性分数”。分数高的在后面的加权求和里占比就大分数低的基本就被忽略了。最终形成的输出就是带着上下文信息的表示。这个过程有一个很关键的特性它是并行计算的。所有token之间的注意力分数是可以同时算的不需要像循环神经网络那样一步一步串行。这一点是Transformer能撑起大模型时代的根基。但并行也带来一个副作用——每一次计算都需要把两两组合都算一遍于是复杂度不可避免地成为算力成本的主要来源。2.2 O(n²)的诅咒为什么长文本这么贵这里就要说到计算机科学里的复杂度了。标准注意力机制的时间复杂度是O(n²)n是输入序列的长度。你输入1000个token模型要计算100万次注意力分数输入10000个token就是1亿次输入10万个token那就是100亿次。这个增长速度有多恐怖你可以想象一个聚会5个人的时候两两打招呼只需要10次50个人的时候就需要1225次500个人的时候就变成12万次了。人数是线性增长的但社交互动次数是平方级增长的。注意力机制就是这样一个“全员社交”的机制序列稍微变长一点计算量立刻爆表。很多在推理侧跑大模型的人应该都有体会模型处理短文本时速度飞快但一旦上下文长度拉长到几万token每一轮的响应时间会明显变慢卡顿感也随之而来。这就是O(n²)在现实中的直观表现。更麻烦的是这个问题不仅影响计算速度还直接影响显存占用——因为中间过程需要存储大量的注意力矩阵。2.3 KV Cache被忽略的隐性成本聊到显存就绕不开KV Cache这个概念。对于生成式模型来说在生成下一个token时要反复读取之前所有token的Key和Value向量。如果每次都从头重新计算一遍计算量会翻好几倍所以常规做法是把之前算好的Key和Value缓存起来直接放在显存里复用。KV Cache很像学生的草稿本——把推演到一半的中间结果先记下来免得后面每一步都从头再推。但这个草稿本非常吃空间。它的大小和模型层数、隐藏维度、序列长度都成正比。一个70B左右的稠密模型如果上下文长度开到几万tokenKV Cache占用几十GB显存是很正常的。这就是为什么超大上下文在实际部署中那么困难的原因——不是模型算不动而是显存放不下缓存的Key和Value。DeepSeek在技术资料里花了很大篇幅来优化这部分因为一旦能把KV Cache的体积压缩下来就能在同一块显卡上塞进更长的上下文、更大的并发推理成本自然随之下降。3. DeepSeek的算力突围那些被复盘的硬核操作前面把问题铺开了注意力机制很强但很贵KV Cache很实用但很占空间。那么DeepSeek是怎么解决这些问题的我把它最核心的几个技术创新拆开来看。3.1 MLA把KV Cache压缩掉一个数量级第一个值得重点聊的创新叫多头潜在注意力英文缩写是MLA。这个方法的目标非常直接压缩KV Cache的体积。传统多头注意力里每个注意力头都有自己的Key、Value需要独立缓存。假设有128个头每个头都要存一份全量的Key和Value那缓存总量就非常可观。不同头之间其实存在大量冗余信息——它们从不同角度观察同一个token但底层的内容是共享的。DeepSeek的MLA思路是先不直接用高维的Key和Value做缓存而是把它们先压缩到一个低维的“潜在向量”里缓存这个低维向量然后再在做注意力计算的时候把它解压出来用。说的直白一点就是不再为每个头单独存一份完整副本而是存一个共享的压缩表示用的时候再展开。这个压缩带来的效果非常显著。从DeepSeek给出的数据看KV Cache体积被压缩到了一个相当小的比例意味着同样一块显卡上推理并发可以翻好几倍。这个改进对推理成本的影响是直接而且巨大的——别人一个请求要占10GB显存的地方你可能只需要不到零头。这里我说一个实操层面的体会对于做服务部署的团队来说KV Cache的占用很多时候比模型权重本身更容易成为瓶颈。模型权重是固定的多少显存就摆在那里但KV Cache随着并发数和上下文长度动态增长一旦用户输入变长OOM就在眼前。所以优化KV Cache不是一个“锦上添花”的事而是直接决定了服务能不能规模化跑起来。3.2 MoE架构671B参数每次只用37B第二个关键架构叫混合专家模型英文是MoE。这个架构其实不算DeepSeek首创但它在DeepSeek上的应用方式很有代表性。普通Transformer模型是稠密的——每一次计算模型的所有参数都要参与。就像一个公司不管项目是大是小全体员工都得上。这当然很稳但效率不高因为不是每个项目都需要调动所有部门。MoE的思路是把模型拆分成很多个“专家模块”每次输入一个token不是让所有专家都工作而是通过一个路由机制只挑选其中最相关的少数几个专家来算。DeepSeek的总参数是671B——这是一个相当大的数字甚至比很多知名开源模型都要大。但是它的激活参数只有37B也就是说处理每一个token时真正参与计算的参数只有37B剩下的专家都处于休眠状态。这样做的好处非常直接训练和推理的计算量由激活参数决定而不是由总参数决定。所以DeepSeek虽然名义上是一个超千亿级的大模型实际跑起来的单次计算成本却并不高。这也是它能在有限算力下完成大规模训练的关键原因之一——总参数大模型的容量和表达能力有保障激活参数小训练和推理的算力开销可控。我印象比较深的是它还特意做了一个负载均衡的设计避免路由机制总是“偏心”地选某几个热门专家导致部分专家被过度训练、另一部分长期闲置。这个细节虽然不起眼但在长时间大规模训练里非常关键否则训练会很不稳定。3.3 FP8与抠门工程学训练成本如何被压下来架构层面的创新之外训练过程中的“抠门”也很值得聊。大模型训练传统上用的是混合精度常见的是FP16和BF16这样能兼顾精度和性能。DeepSeek往前走了一步大量使用了FP8精度来做训练。FP8是一种更低的数值精度每个数字只占8位相比FP16占用降低了一半。好处很直观同样的显存能装下更大的模型或者更大的批处理量同样的带宽能传输更多的数据。但用FP8也有风险——精度降低可能导致训练不稳定甚至出现梯度溢出、损失函数发散等问题。DeepSeek的做法不是直接一键换成FP8而是精心设计了一套混合精度策略哪些部分可以用FP8哪些部分必须保留更高精度这些都有细致的安排。从它的技术报告看这套策略保证了FP8训练的效果能和传统精度对齐但成本大幅下降。这就有点像装修时精确采购建材——不想全屋都用顶级材料那样太贵也不想用次品材料那样会出质量问题。最好的方式是承重墙用好材料装饰面用普通材料把钱花在刀刃上。FP8调度做的就是这件事。3.4 推理侧的成本革命API价格为什么敢这么低上面这些优化加在一起最终在推理侧产生了肉眼可见的效果。我可以算一笔很粗的账。假设你部署一个传统稠密大模型显存开销很大单张显卡只能支撑极少并发。而DeepSeek因为KV Cache压缩了单位显存能承载的并发请求数上升因为MoE结构单次推理的实际计算量远小于同规模稠密模型。这两个因素叠加单次请求的边际成本就变得非常低。所以它敢把API定价打到很低并且还能保持服务稳定因为成本结构确实撑得住。这背后并不是在做亏本买卖而是从模型设计之初就把成本控制作为核心目标。过去我们默认“模型越大越贵”DeepSeek用一套架构组合告诉行业模型可以大但用起来可以不贵。这一点对技术选型尤其重要。如果你是做应用开发的接入API时底层的成本结构直接决定你这个应用能不能盈利。我记得有不少开发者拿到DeepSeek的API价格之后做的第一件事就是重新测算自己的业务成本。同样的模型能力成本降到原来的几分之一很多原本需要OCR、配音等外围能力辅助的场景现在直接用语言模型就能搞定。4. 这场算力革命对普通人意味着什么4.1 大模型“平民化”的分水岭如果说ChatGPT的出现让大众第一次知道了大模型那么DeepSeek这轮爆火的意义在于让更多人意识到了算力成本是可以被技术大幅压缩的。过去两年行业里弥漫着一种焦虑大模型是巨头的游戏普通人很难参与。动辄上万张显卡的训练集群对任何创业团队都是天文数字。但DeepSeek用一套开源权重加上低成本的推理优化展示了一条不同的路径与其在算力数量上硬刚不如在算法效率上做文章。这个信号对中小团队极具激励意义——你不需要复刻一个顶尖实验室的硬件规模也能基于开源权重搭建自己的产品。我身边已经有越来越多人在做这样的尝试用DeepSeek的模型做垂直领域的知识库问答做代码辅助工具做长文档分析。过去这些场景受限于接口成本和响应速度很难商业化落地现在瓶颈一下子被放宽了很多。4.2 给技术从业者的三条经验复盘DeepSeek的这次突围我觉得有三条经验是值得所有技术人记住的。第一条优化要从底层结构入手而不是在表层打补丁。很多人想到降本增效第一反应是换更便宜的硬件或者砍掉不必要的功能。但DeepSeek选择的是改变模型本身的计算结构。这是一个更困难但更根本的路径一旦走通收益是成倍的。第二条成本控制是一个系统工程而不是单点优化。MLA压缩KV Cache、MoE降低激活参数、FP8降低存储带宽需求这三件事单独拿出来任何一件都是不错的成绩但真正厉害的是它们组合在一起在训练、推理、部署的每一个环节都实现了节流。单一技术容易被模仿系统级的成本优势才是真正的护城河。第三条开源和社区生态会加速技术迭代。DeepSeek把关键技术细节公开之后整个社区都能去学习、讨论、做二次创新。这种开放的姿态让它的影响力远远超出了单一产品本身变成了一个技术范式的推动者。对开发者来说与其闭门造车不如尽早拥抱开源生态借力社区的力量放大自己的成果。4.3 注意力革命的后半场还能往哪儿卷回到注意力机制本身——它的优化其实还远没有到天花板。当前标准注意力的O(n²)复杂度的瓶颈已经有了很多破解思路稀疏注意力只让部分重要token参与全局交互线性注意力用核方法把复杂度压到O(n)等等。DeepSeek的MLA主要解决了KV Cache的存储问题但注意力计算的复杂度问题后续还有更大的优化空间。我比较关注的下一个方向是推理阶段的动态计算。现在的模型不管输入内容简不简单都会用相同的算力去处理。未来有可能根据输入的复杂度动态调整计算量——简单问题快速跳过复杂问题深入推理。这种动态的路由和计算方式会把算力效率再往上提一个量级。另一个值得关注的方向是硬件与算法的协同优化。DeepSeek的FP8训练已经展示了这种协同的价值未来会有更多专门为注意力机制定制的硬件加速方案出现。当算法和芯片一起为注意力机制做优化算力革命的下半场会更加精彩。我在实际跟进这些技术的过程中最大的体会是注意力机制这套数学框架虽然已经提出了好几年但围绕它的优化空间依然极其广阔。它就像一栋主体结构已经建好的大楼设计图纸已经锁定了但内部怎么做隔断、管线怎么走、家具怎么摆还有太多可以反复优化的细节。DeepSeek这次让“注意力”和“算力”两个词重新被放到了一起审视让更多人意识到两者的关系不是单向的需求关系而是可以互相成就的注意力机制提出高难度的计算需求反过来也逼着人们去发明更聪明的算力使用方式。这种循环推动的进化比单纯堆叠资源要健康得多也持久得多。最后说一个非常实用的小建议如果你正在做技术规划不妨把“算力效率”纳入核心指标从模型选型阶段就开始测算训练和推理的成本而不是等部署上线之后才发现成本不可控。提前用上和DeepSeek类似的思路——压缩缓存、减少激活参数、调度数值精度——你会发现大模型的成本远没有想象中那么吓人。
阅读完成 · 觉得有帮助？
