DeepSeek 第 6 天发布会中的一条 “成本利润率545%” 震惊 AI 圈

因此，我把官方的在 Github 上的全文，让 Deep Research 进行了解读，方便感兴趣的朋友详细了解。但是请注意：AI 有幻觉，虽然 Deep Research 幻觉率很低，但依然可能会存在错误。

引言：高吞吐和低延迟为何对AI推理至关重要？

试想一下，你向一个AI模型提了一个问题，却要等上好几秒甚至几十秒才能得到回答，那感觉是不是很抓狂？在这个讲求效率的年代，没人愿意和一个“慢吞吞”的模型对话。同样地，如果同时有成千上万的用户在发问，AI系统却只能慢悠悠地一个个处理，那它很快就会被用户抛弃。所以高吞吐量（一次处理尽可能多的请求或数据）和低延迟（每个请求尽快得到响应）对于AI推理服务来说就是生命线。如果把AI比作一家餐厅，高吞吐就像这家店能同时招待大量顾客，低延迟则意味着每位顾客都能快速上菜。想象一下，如果你的菜上得慢了，你会不会毫不犹豫地给差评然后转身走人？AI服务的用户也是一样挑剔。

对于像DeepSeek-V3和R1这样的大型语言模型来说，这个问题更为突出。模型越大，计算量越恐怖，稍不注意响应就变慢。但用户偏偏还希望它既聪明又快速，这听起来是不是有点矛盾？那么，DeepSeek的工程师们是如何让一个庞然大物般的AI模型既“跑得快”又“撑得住”呢？接下来，我们就一起揭开DeepSeek-V3/R1推理系统幕后那些神奇设计的面纱。

DeepSeek推理优化目标：让大模型跑得又快又稳

要让一个大模型跑得又快又稳，我们首先得明确目标，也就是前面提到的高吞吐和低延迟。DeepSeek团队深谙此道，将这两点作为推理服务优化的重中之重。那么，说到提高吞吐量和降低延迟，你会想到什么办法？增加服务器数量？用更快的GPU？这些当然有用，但DeepSeek的“秘诀”远不止于此。

DeepSeek-V3/R1的推理服务背后用了不少巧妙的设计来榨干硬件的潜力。简单来说，他们希望每一块GPU每一秒都被压榨出最大的价值，同时让每个用户都尽可能快地收到回复。听起来很理想，是吧？可要达到这个目标，可不像给汽车换个更大马达那么简单。

在设计之初，DeepSeek团队就定下了几条核心原则：其一，大模型要用上跨节点的专家并行（Expert Parallelism，EP）来扩展规模；其二，要想办法将不可避免的通信开销隐藏在计算时间里，也就是让计算和通信重叠进行；其三，系统由众多GPU协同工作，必须做好负载均衡，不能让有的GPU忙成狗、有的GPU闲得发霉。这三招就是DeepSeek加速大模型的法宝。当然，说起来简单，真做起来可没那么轻松，每一项都是块难啃的硬骨头。下面我们就一一拆解，看看DeepSeek具体用了哪些妙计来达成这些目标。

专家并行（Expert Parallelism）解析：为什么要跨节点并行？

DeepSeek-V3/R1采用了**Mixture-of-Experts（混合专家）**架构。简单来说，每一层有256个“专家”（子模型），但每次推理只激活其中8个为你服务。这种设计让模型既大又高效——不会每次都让256个专家全员上阵浪费算力，而是有选择地调用少数专家参与计算。但问题来了：要伺候256位专家中的8位，你得准备多少“板凳”？

你知道为什么DeepSeek要做跨节点的专家并行吗？原因很简单：专家实在太多，一个机器根本放不下！想象一下，你有一支256名专家组成的咨询团队，每次项目只需要派8个人出马。如果把256人都关在一间办公室里，那办公室不仅要够大（内存够），而且一旦8个人忙活，剩下248个人就在旁边喝茶闲聊（算力被浪费）。更聪明的做法是把专家们分散在多栋楼（多个节点）里，每栋楼里安排一部分专家。项目来了，就根据需要把问题派给不同楼里的对应专家。这样做的好处显而易见：你可以同时服务更多的项目（因为多栋楼并行开工），也避免了一栋楼里专家扎堆闲着。

具体到DeepSeek的推理系统，他们把这些专家模型拆散到不同的GPU乃至不同机器上执行，也就是所谓跨节点的专家并行。EP的第一个好处是可以把批处理规模（batch size）做得非常大。批处理可以理解为一次性能处理很多请求或很多token，就像批发进货比零卖更高效。批越大，GPU这个“数学怪兽”就越忙得起劲，吞吐量自然蹭蹭往上涨。第二个好处，EP让每块GPU只需处理全部专家中很小的一部分，每块GPU各司其职照看少数几个专家，这样每次计算需要访问的内存更少，单个请求的处理也更快，延迟也就降下来了。

当然，跨节点并行不是免费的午餐，它也带来了新的挑战。首先，跨节点意味着不同GPU（甚至不同机器）之间必须频繁通信，数据得在网络上飞来飞去。这通信可是个拖后腿的家伙，如果处理不当，GPU再多也可能被通信延迟拖慢。所以DeepSeek必须设计一种巧妙的工作流，让计算和通信无缝重叠起来，尽量避免GPU傻等数据。其次，多节点合作也意味着我们在做数据并行（Data Parallelism，DP）——同一个模型的副本跑在多组GPU上，每组服务一部分请求。这样一来，不同组之间工作量可能此消彼长，如果不平衡，就会出现某些GPU组忙成陀螺、另一些组闲着吹风的情况。针对这一点，就需要精心设计负载均衡策略，保证大家都忙而不乱。

总结一下：DeepSeek采用跨节点专家并行，是为了让大模型拥有更大的批处理、更高的并行度，进而实现高吞吐和低延迟。但同时也引入了通信开销和负载分配的难题。接下来，我们看看他们是如何见招拆招，逐一化解这些难题的。

Prefill-Decode分离架构：这是什么“黑科技”？

在DeepSeek的方案中，有一个很有意思的架构设计，叫做Prefill-Decode分离。初听这个名词，你可能会一头雾水：这是要填什么？解什么码？别急，我们来拆解一下。简单来说，Prefill阶段就是将输入的提示或问题一次性喂给模型，让模型把所有“底子”都打好（相当于把问题读懂）；Decode阶段则是模型根据已经获取的“底子”开始逐字逐句地生成回答，相当于真正把答案写出来。这有点像考试时你先花时间审题、在脑子里组织思路（Prefill），然后才开始正式提笔答题（Decode）。把推理过程拆成这两步，各自优化，就是Prefill-Decode分离架构的奥秘。

你可能会问：不就是正常的输入输出过程吗，干嘛要特意分成两段？这里可是有“黑科技”的。因为在实际优化中，处理输入和生成输出的计算特点差别很大。Prefill阶段通常需要处理大量的输入token（用户给模型的大段上下文），这个过程可以高度并行化。而且由于只需经过模型一次就拿到结果表示，我们可以用很大的批处理来提升效率。Decode阶段则不同，模型要一边参考已有的输出一边继续生成下文，有点像边走边铺路，没法像Prefill那样把所有输入同时丢进去算，只能一段段地来。但Decode阶段每生成一个token都要经过模型所有层的计算，而且往往要生成很多token，延迟非常敏感。

DeepSeek选择将两阶段分离处理，好处是可以针对性地采用不同的并行和优化策略。Prefill阶段可以尽量堆并行、批处理开大，让模型一次“读”更多的输入；而Decode阶段则调整并行方式，利用更加精细的流水线和分布式计算保证生成过程也高效。打个比方，这就像赛车手在直线路段全力加速追求极限，在过弯时稳住油门确保安全快速通过——不同阶段用不同策略，各取所长。

计算-通信重叠策略：如何让通信时间被计算“吃掉”？

跨节点并行引入大量通信，如果GPU每算完一部分就干等数据在网上慢吞吞传输，那效率就太低了——GPU可是性能怪兽，闲着就是浪费。那么DeepSeek是怎么让GPU不白白等数据，把通信的开销“吃掉”的呢？

秘诀就是让两批任务交替进行，用一批的计算来掩盖另一批的通信时间。在Prefill阶段，DeepSeek把一个大批请求拆成两个小批（microbatch），然后交替执行。你可以想象两组接力队员在跑步：A组跑一段，稍作停顿的同时B组开始跑，然后再轮到A组继续，如此往复。这样，当A组在“换气”（等待通信）的时候，B组已经在“冲刺”（计算），反之亦然。通过这种交叉并行，通信过程被藏在了另一批次的计算过程中，几乎等于隐藏了传输延迟。如果你是工程师，你会如何优化这样的计算过程？ DeepSeek的工程师就想到了这一点：用双批次交替执行来最大化GPU利用率。可以看到，这需要非常精巧的调度安排，就像两位厨师配合默契，一个翻炒的空当另一位刚好下锅，节奏拿捏得恰到好处。

Decode阶段因为需要序列一步步生成，情况更复杂一些。DeepSeek的做法是把耗时较长的自注意力层细分成两步，弄出了一个5级的流水线。可以将其比喻为工厂里的5个工作站，生成的多个token在不同阶段同时加工：当第1个token在站3处理时，第2个token可能在站2处理，第3个token还在站1……如此流水线式的并行让通信和计算几乎无缝衔接。虽然Decode阶段每个序列仍然要按部就班地生成，但借助流水线，系统就像同时在处理多个序列的不同行程，整体效率大大提高。对于用户来说，这意味着生成答案时也几乎感觉不到模型在“卡壳”等数据，全程行云流水。

看到这里，我们体会到DeepSeek工程师在“抠”性能细节上真是下了苦功。计算-通信重叠策略有点像魔术，把网络传输这只“拦路虎”变得几乎隐形了。对于追求极致性能的AI服务来说，这一招实在非常关键。

负载均衡的挑战和解决方案：GPU们如何“打配合”？

有了大量GPU协同工作的系统，一个老生常谈的问题就出现了：负载均衡。就像团队里如果有人特别忙有人特别闲，整体效率就上不去。在DeepSeek的推理服务中，负载不均衡可是性能的大敌：如果某个GPU拖后腿，其他GPU就只能干等，它们再快也没用。而造成负载不均衡的原因可能有很多，我们来看看DeepSeek面临的“三座大山”，以及他们各自的对策。

首先是Prefill阶段的负载均衡。Prefill阶段各个数据并行（DP）实例负责不同的请求集合，但是用户请求的数量和每个请求的输入长度（token数）往往参差不齐。有的DP组可能分到了很多长请求，要处理的token巨多；而另一些组可能全是短平快的请求。结果就导致前者的GPU在辛苦做“大段阅读理解”，后者的GPU已经读完在发呆等待。为了解决这个问题，DeepSeek实现了Prefill负载均衡器。它的目标有两点：一是平衡核心算力的使用，也就是让每个GPU执行核心计算（例如注意力和MLP部分）的时间尽量接近；二是均衡每个GPU处理的输入token数量（dispatch发送负载），避免某些GPU因为输入特别长而一直忙个不停。你可以把它想象成工厂里动态调度生产线：如果发现第一条线订单爆满、人手不够，而第二条线相对清闲，就想办法把一些订单转移到第二条线，或者调整任务分配顺序，让每条线都保持适当负荷。

接下来是Decode阶段的负载均衡。Decode阶段的问题类似，但还有自己的特殊麻烦。生成回复时，不同请求之间的输出长度可能差别很大：有的回答三言两语就完事，有的则滔滔不绝长篇大论。而且Decode阶段涉及KV缓存（key-value cache）的查找和维护——模型需要不断查阅先前生成的“记忆”，这对显存和计算带来额外负担。如果不同DP实例之间请求数量和长度悬殊，就会出现某些GPU因为要处理超长上下文和大量生成而压力山大，而别的GPU可能早早完成任务在一旁干等。DeepSeek为此部署了Decode负载均衡器，目标同样有两点：一是平衡KV缓存相关的计算负荷（核心算力负载），尽量让每个GPU承担的“历史记忆”查询开销相近；二是均衡每个GPU分配的请求数量（dispatch发送负载），不让某个GPU独自扛下过多长对话生成任务。这有点像客服热线的调度：当一些坐席被长时间占用，新进来电话就会转给空闲坐席，避免有人过劳有人闲。Decode负载均衡器也是类似的道理，动态调配生成任务在GPU间均匀分布，不让某几张卡成为瓶颈。

最后是专家并行阶段的负载均衡。由于DeepSeek的MoE模型里存在大量专家，一般来说总有那么几个专家特别“抢手”。某些类型的问题总会集中调用那几个专家，导致这些专家所在的GPU老是满负荷运转，而别的专家可能闲得发霉。DeepSeek为此引入了专家并行负载均衡方案，其核心目标是平衡每个GPU上专家的计算负载。通俗点说，就是要尽量避免出现某张卡因为上面挂了个“大忙人”专家而每次都累惨了。具体做法包括增加“热门”专家的冗余副本，分散到不同GPU上，从架构上分摊热门专家的请求负荷。如果发现某专家出奇地忙，就多布置几份一模一样的该专家模型到不同GPU上，就像发现餐厅里做牛排的厨师太忙了，就多安排几位厨师专职做牛排，顾客一多可以同时开炒。与此同时，在调度上也尽量聪明地避开最拥挤的那一位：当某GPU上的专家A已经在处理很多请求时，新来的相同专家请求就尽量交给其他GPU上备用的A去处理。通过这些办法，整个系统各GPU上的专家工作量更均衡，不会因为某个专家过热而拖慢整体响应。

经过以上这些负载均衡策略的加持，DeepSeek的GPU集群俨然变成了一支配合默契的团队。无论是Prefill阶段、Decode阶段，还是专家计算阶段，每个GPU都被尽可能均匀地投入工作。没有哪个队友偷懒，也没有哪个被压垮拖后腿。对于整个系统来说，这意味着资源利用率最大化和性能的一致稳定。也正是这些幕后功臣在兢兢业业地调度安排，我们才能在高峰期和午夜时分都享受到DeepSeek几乎同样流畅的问答服务。

DeepSeek推理服务的运行统计：GPU消耗、吞吐量、成本解析

聊了这么多优化策略，你可能好奇：DeepSeek的推理服务到底跑出了什么样的成绩单？官方公布的一些24小时运行统计数据可以让我们一窥究竟，然后感受一下什么叫“大模型流水线，日进斗金”。

首先是硬件投入和成本。DeepSeek-V3和R1推理服务全部跑在NVIDIA H800 GPU上（这是一种高性能数据中心卡，类似于H100的定制版）。在一个统计周期内（北京时间2025年2月27日中午12点到28日中午12点的24小时），DeepSeek高峰时段动用了278个节点来提供服务——每个节点有8张H800 GPU，相当于高峰同时运行着278×8 = 2224张GPU！平均下来，这24小时里节点占用为226.75个（约相当于1814张GPU持续工作）。真是不算不知道，一算吓一跳：上千张顶级GPU日夜不眠地回答用户的问题，想想都有点疯狂。而按每张H800每小时租用成本2美元估算，这一天光GPU的使用费用就接近87,072美元（折合人民币约60万元）。砸下这么多真金白银，只为了让AI陪大家聊聊天问问题，这投入够豪气吧？

当然，更重要的是看看这些投入换来了多少“产出”。在这24小时里，DeepSeek一共处理了6080亿个输入token，产出了1680亿个输出token。这个量有多夸张呢？打个比方，这相当于AI读了几十万本小说，又写出了上万本小说的内容！平均下来，DeepSeek在输出阶段每秒钟生成20~22个token的内容给用户。而更惊人的是，每个生成的token背后模型参考的上下文长度平均竟达4989个token。

另外值得一提的是DeepSeek利用了KV缓存技术。简单理解，模型会记忆已经处理过的内容，避免重复计算。在上述统计周期内，输入的6080亿token里有3420亿命中了磁盘上的KV缓存（约占56.3%），意味着超过一半的输入token无需再次通过完整模型计算，因为系统已经“见过”相似内容或上下文，可以直接利用缓存结果。这就好比你问了AI一个之前有人问过的问题，它早把答案写在小本本上了，直接翻开念给你听，省去了重新推理的时间。这对提升吞吐量帮助很大。

那么，在这样的计算规模下，DeepSeek每个节点的处理能力有多强？数据显示，每个H800节点平均吞吐约7.37万 token/s的输入（包括那些利用缓存的token），以及约1.48万 token/s的输出生成速度。看到这儿，你可能会为DeepSeek鼓掌——这效率实在惊人！要知道，我们平常打字每秒可能打不出5个字，而这AI模型分布在成百上千GPU上，一秒钟能吐出上万字的回答，实在让人叹为观止。

最后我们聊聊经济账。如果把DeepSeek当天处理的所有token都按照DeepSeek-R1官方定价收费（假设V3服务按R1同价），那么一天的理论收入约为56.2万美元；扣除成本8.7万，净赚约47.5万美元。换句话说，投入1块钱成本，产出约6.5块，利润率相当可观。当然，别以为DeepSeek真有这么挣钱，因为实际运营中有不少让利：DeepSeek-V3模型的定价远低于R1；只有一部分服务是收费的（网页和App等面向个人的访问基本免费）；夜间非高峰时段还有自动折扣等等。所以实际每天收入肯定低于这个理论值。但即便如此，有了如此高效的推理系统支撑，DeepSeek才敢大方提供大量免费服务而依然保持运营可持续。高吞吐低延迟带来的低成本和好体验，使他们在用户口碑和盈利能力上实现了一举两得。

总结与展望：未来优化方向和可能的挑战

通过以上探秘，我们看到DeepSeek-V3/R1的推理系统为了追求“又快又稳”，在系统架构上用了许多巧思。从跨节点专家并行、Prefill-Decode分离，到计算-通信重叠，以及多层次的负载均衡，每一招都直击大模型推理的痛点。这些设计共同编织成一张滴水不漏的高效网络，让一个超大型AI模型得以在分布式环境中运转自如，服务海量用户而游刃有余。

然而，任何工程方案都有两面性。DeepSeek这套系统复杂度非常高，实现起来绝非易事。跨节点通信带来了大量同步问题，如果网络延迟波动或者通信出错，调试起来会让人头大。负载均衡算法再智能，也需要大量参数调优和场景适配，一旦实际流量模式变化，可能还得调整策略。这还没算上硬件层面的限制，比如网络带宽就是客观上限，万一哪天用户量暴增到网络撑不住，再巧妙的重叠也无法突破物理瓶颈。另外，模型本身也在不断演进——假如下一代DeepSeek-R2模型规模更大、结构更复杂，现有的优化策略是否还能Hold住也是个未知数。

在我看来，未来还有不少优化方向值得探索。首先，可以进一步提升调度的智能化，让系统能够根据实时负载情况自动优化资源分配，例如引入更智能的调度器，实时监控每张GPU状态，动态调整任务划分，比人为设定的规则更灵活高效。其次，模型架构本身的改进也可能带来推理效率提升，比如在设计时就考虑分布式友好性，让模型更容易拆分到多卡并行，或者引入更新颖的专家调度机制，使负载天生更均衡。再次，硬件升级永远是提升性能的重要手段，更快的芯片、更大的显存、更高速的互连网络（乃至光通信）都可能显著降低节点间通信成本，让并行计算如虎添翼。还有，模型压缩和高效推理技术也大有潜力，例如更高级的量化（现在已经用了FP8，未来是否可能进一步降低精度？）、模型蒸馏出小而快的版本来应对简单请求等，这些办法都可能在保持模型效果的同时极大降低资源开销。

DeepSeek的实践案例也给整个行业提了个醒：要成功部署大模型，光有优秀的模型算法还不够，高效强大的推理后端同样不可或缺。高吞吐和低延迟直接决定了用户体验和运营成本，而DeepSeek通过工程上的创新，在保证大部分用户免费使用的同时仍维持了良好的成本效益，这本身就是一种平衡艺术。展望未来，随着AI模型的能力不断提升，竞争对手也会纷纷祭出各自的独门绝技，DeepSeek必须持续优化，才能保持领先。那么，下一个问题来了：未来的AI推理系统还会出现哪些令人意想不到的新点子？ 我们拭目以待。可以确定的是，对于我们这些AI爱好者和从业者而言，这是一个充满惊喜和挑战的时代，不是吗？