2025年通信行业专题研究：DeepSeek算力效率提升≠算力通缩，国产算力需求方兴未艾

1、DeepSeek 通过大规模专家并行（EP）与计算通信重叠（DP），大幅提升 算力效率

DeepSeek-V3/R1 模型采用高度稀疏的 MoE 架构，每层专家数量众多，包含 256 个专家， 但每次前向传播仅激活其中的 8 个，导致大量其他专家处于闲置状态。如果批量大小 （batch size）不够大，每个专家处理的数据量会非常有限，带来计算资源利用不足、吞 吐量低的问题。 为解决以上问题，DeepSeek 采用大规模跨节点专家并行（EP）。EP 通过显存资源解耦、计 算负载重构等，将专家参数分布式存储在多个 GPU 中，使得被激活的专家能够分散到不同 的 GPU 进行处理，由此提升了吞吐能力、GPU 算力资源利用率也得到了提高。同时由于每 个 GPU 仅处理一小部分专家，延迟也得到了降低。

大规模跨节点专家并行（EP）带来较大通信开销，因此还采用计算通信重叠（DP）以缓解 这一问题。在 EP 模式下，跨节点数据传输会引入额外耗时、提高通信开销。为缓解这一 问题，DeepSeek 采用双批次重叠策略，通过交替处理两个批次以减少通信成本。例如在 预填充阶段，DeepSeek 将一批请求分成两个微批次（micro-batch），当一个微批次正在 进行计算时，另一个微批次的数据正在被传输或准备。

通过大规模专家并行（EP）与计算通信重叠（DP），公司吞吐能力大幅提升，算力效率提 高。根据 DeepSeek，对于 decode 任务，其平均每台 H800 输出吞吐约 14.8ktokens/s。作 为对比，2025 年 2 月，优化后的英伟达 H200 的节点峰值输出吞吐仅 5.9ktokens/s；B200 的节点峰值输出吞吐仅 21ktokens/s。吞吐率是衡量 NLP 模型性能的核心指标，表示在单 位时间内能处理的文本标记（Token）数量。DeepSeek 在使用性能低于 H200 的 H800 的前 提下，吞吐能力仍然高于 H200，算力效率极高。

吞吐率取决于批量大小（batch size）与延时（latency）。批量大小和延时是互为权衡的 两个性能指标。起初，增加 batch size 能够带来吞吐率的快速提升，但增加批量大小的 同时，也会增加延时。随着 batch size 继续增加到一定程度，总延时的增长会逐渐抵消 batch size 增长带来的吞吐量收益，吞吐率会增长放缓并接近某个极限。 DeepSeek 通过 EP 与 DP 实现架构优化，实现了在增加批量大小的同时，延时（计算时间、 通信时间）边际下降，由此吞吐率得到提升，体现出大模型的规模效应。因此大规模集群 能提高算力利用率。

2、参考 DeepSeek，MaaS 厂商具有盈利潜力，率先实现规模效应的云厂商 将脱颖而出

2.1. DeepSeek 口径下，545%高利润率的计算详解

成本端：DeepSeek 在计算时仅考虑了 GPU 的租赁成本，约为$87,072/天。根据 DeepSeek 在知乎发布的文章《DeepSeek-V3/R1 推理系统概览》，我们可以得到以下条件：A）GPU 租赁价格：GPU 租赁成本为 2 美金/小时；B）总耗费 GPU 资源：在最近的 24 小时里，DeepSeek V3和R1推理服务平均占用226.75个节点（每个节点为 8个H800），即，用到226.75*8=1814 个 H800。GPU 运行时间即为 24 小时。由 GPU 租赁成本=单个 GPU 租赁价格*总耗费 GPU 资 源，则可得到总 GPU 租赁成本。

收入端：所有 tokens 均根据 DeepSeek R1 的 API 定价，大模型收入约为$562,100/天。大 模型带来的收入主要是指用户接入 DeepSeek 大模型的 API 而进行的费用支付，可通过模 型调用 API 定价与 Tokens 消耗量相乘而得。为简化计算，DeepSeek 假设所有 tokens 全 部按照 DeepSeek R1 的 API 定价计算，即，每一百万输出 tokens 定价为$2.19；每一百万 输入 token（缓存命中）定价为$0.14，每一百万输入 token（缓存未命中）定价为$0.55。 在 tokens 消耗量方面，DeepSeek 披露了三个情境下的 Token 使用量：输入 token 总数为 608B，其中 342B（56.3%）为缓存命中；266B（43.7%）为缓存未命中。输出 token 总数 为 168B。量价相乘，即可得到大模型收入为$562,100/天。

利润端：公司计算得到 545%的成本利润率，对应 84.5%的收入利润率。DeepSeek 根据 “AI 大模型产生的利润/GPU 租赁成本”计算得到大模型的理论成本利润率约为 545%。按照“利 润率=利润/总收入”的一般财务会计口径计算，则对应 84.5%的利润率。

2.2. 根据实际情况调整后，DeepSeek 利润率有所降低，我们认为付费率为关键影响因素

我们根据实际情况对 DeepSeek 的收入和成本端进行了调整，以进一步分析利润率的影响 因素。具体过程如下：

1）成本端调整：需考虑运维成本、带宽成本等其他经营性成本

为计算简便，DeepSeek 在成本端只计算了 GPU 的租赁价格，但未考虑到其他成本（如运 维成本、带宽成本、人力成本、数据版权成本等经营性开支），由此可能会造成成本端的 低估、利润率的高估。我们假设 GPU 租赁成本约占总成本的 70%，其他成本占 30%，则对 应实际总成本约为$124,388.6/天。

2）收入端调整：需考虑 R1 定价区别、优惠定价折扣、实际付费率

为计算简便，DeepSeek 在进行利润率估算时简化了以下三个因素，因此实际大模型收入 及其利润率水平或被高估。 A）R1 和 V3 的定价区别：DeepSeek 假设所有 tokens 全部按照 DeepSeek R1 的定价计算， 但用于计算的 token 总数，却是 DeepSeek V3 和 R1 共同输入、输出的 token 总数。而根 据 DeepSeek 官网，在标准时段内，同样情形下（缓存命中/缓存未命中/输出价格）， DeepSeek V3 的价格仅为 R1 的 1/2。 B）标准时段与优惠时段的定价区别：根据 DeepSeek 官网，DeepSeek API 实行错峰优惠 定价，每日优惠时段为北京时间 00:30-08:30，其余时间按照标准价格计费。而优惠时段 中，DeepSeek V1 的价格仅为标准时段的 1/2，DeepSeek R1 的价格仅为标准时段的 1/4。 C）Token 调用过程中付费率：公司的统计口径包括了网页、APP 和 API 的所有负载，但 DeepSeek 的网页端和 APP 端入口均为免费，仅接入 API 的时候需要付费，因此用户付费 率仅为 API 使用占比。

我们分别对其进行假设，并纳入实际总收入的测算：

A）假设 DeepSeek V3/R1 调用需求占比分别为 35%/65%

根据 IDC 与浪潮信息发布的《2025 年中国人工智能计算力发展评估报告》，2024 年中国训 练算力：推理算力约为 35%：65%。由于 DeepSeek V3 为训练大模型、R1 为推理大模型， 我们假设 DeepSeek V3/R1 的需求占比与全国平均类似。由此，在原先 DeepSeek 官网对不 同时段、不同模型、不同情形的定价基础上，我们根据“V3 调用单价*V3 调用需求占比+ R1 调用单价*R1 调用需求占比”计算各时段、各情形的均价。

B）假设每小时输入、输出 token 数量均匀分布

根据公司官网，每日优惠时段为北京时间 00:30-08:30，即为 8 小时，剩余 16 小时为标 准时段。我们假设每小时输入、输出 token 数量均匀分布，则标准时段输入 tokens 总数 为单日输入 tokens 总数的 16/24，优惠时段输入 tokens 总数为单日输入 tokens 总数的 8/24。假设输入命中率为 56.3%不变，则可得到标准时段、优惠时段的输入命中、输入未 命中的 tokens 总数。同理，根据公司披露，单日输出 tokens 数量为 168B，则标准时段 输出 tokens 数量为 112B，优惠时段输出 token 数量为 56B。

在不考虑付费率的情况下，我们依据各时段、各情形下的 tokens 调用情况与定价相乘， 得到大模型的总收入约为 37 万美金/天，对应收入利润率高达 66%。相比未调整收入、成 本之前的 84.5%略有下降，但仍然体现出非常可观的利润率水平。

C）假设付费率约为 35%

参考 ChatGPT 的收入结构，API 接口与企业端收入合计占比约 44%。根据 FutureSearch， API 收入占 OpenAI 总收入的 15%左右，针对大型企业客户的 ChatGPT Enterprise/面向中 小企业的 ChatGPT Team 则分别贡献收入的 21%/8%；个人订阅用户收入占比约为 55%。因 此，API 与企业端收入合计占比 44%。 由于 DeepSeek 仅 API 端口付费，网页端、APP 端均免费，而日均调用 tokens 数量是基于 所有端口统计的，因此需考虑付费率对收入的影响。我们认为调用 DeepSeek API 的多为 企业用户以及付费意愿较强的个人用户，参考 ChatGPT 的 API 接口与企业端口合计占比约 44%，考虑到国内付费意愿相对较低，我们假设 DeepSeek 整体付费率在 35%左右。 基于 35%的付费率，得到大模型收入约$13 万/天。 敏感性分析：我们对 GPU 租赁成本占比、API 付费率进行了敏感性分析，付费率与 GPU 租 赁成本占比对公司利润率影响较大。若能将付费率提升至 40%+，则公司的利润率水平有 望达 20%+。

2.3. MaaS 模式具有盈利潜力，看好能形成规模效应的公有云厂商

我们认为上述针对 DeepSeek 利润率的计算能够部分证伪市场此前认为大模型厂商商业模 式无法盈利、不可持续的观点，MaaS 模式具有盈利潜力。 我们看好能实现大集群、形成高用户并发的公有云厂商，具体理由如下： 1）在第一章对 DeepSeek 底层架构优化的分析中，我们阐明了大规模集群能显著提高算力 的利用率，产生规模效应。 2）规模效应能带来成本的摊薄，公有云厂商才有意愿降低定价，并吸引更多客户使用大模型，这进而会提升客户的付费率。而伴随客户付费率的提高，公司的盈利水平也将不断 提升，形成正向循环。 因此，我们看好拥有大规模集群、能形成高用户并发的公有云厂商，MaaS 盈利模式能够 跑通。

3、算力需求之争：算力效率是新的 Scaling Law 方向，多模态与 AI Agent 将打开算力的成长空间

根据 DeepSeek 发布的文章，其用于单日推理服务的 H800 数量仅 1814 个，而其日活 DAU 约有 2500 万。此文引发了市场对算力通缩的担忧。 我们就 DeepSeek 的模型参数量、数据规模、峰值倍数、单卡算力、单卡利用率等关键指 标进行了详细的拆解，发现 DeepSeek 低算力的原因在于：1）超高的算力效率，具体体现 在单次推理激活的模型参数量、高单卡利用率；2）低峰值倍数：未设置较大的算力冗余。 针对市场对算力通缩的担忧，我们认为：1）DeepSeek 的案例凸显了算力效率的重要性， 厂商需要通过底层架构设计等提升算力效率，参数量*效率*数据规模（而非过去“参数量 *数据数据规模”）才是新的 scaling law 方向。2）而从远期看，AI 落地的场景不止于聊 天机器人，多品类 APP 接入 AI 大模型、多模态、AI Agent 等的出现，都将带动算力需求 的提升，我们持续看好算力链。

3.1. DeepSeek 的 1814 个 GPU：算力效率的提升、算力冗余和用户使用频次的不足

DeepSeek 公布了 24 小时内用于推理服务的 H800 节点数量。根据 DeepSeek 的官方文章， 在过去的 24 小时内，DeepSeek V3 和 R1 推理服务平均占用 226.75 个节点，根据单节点 对应 8 个 GPU 计算，可得到总共用于推理服务的 H800 数量为 1814 个。 根据量子位披露的数据，DeepSeek 的平均日活 DAU 约为 2500 万。DeepSeek 仅用 1814 个 H800 支持了 2500 万日活用户的推理需求，引发了市场对算力需求通缩的担忧。

我们基于大模型推理的算力需求、单卡算力等指标，对 DeepSeek 的算力利用情况进行了 详细拆解。 1）算力需求：结合 OpenAI 的论文《Scaling Laws for Neural Language Models》，我们 得到大模型推理算力需求的一般公式：推理算力需求≈2×模型参数量×数据规模×峰值 倍数。 其中：A）模型参数量：参考 DeepSeek 发布的论文《DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning》，R1 每次推理仅激活 37B 参数；B） 数据规模：参考 DeepSeek 披露的日均处理 token 数，换算得到 0.09 亿 tokens/秒；C） 峰值倍数：我们按峰值占用节点数/平均节点数估算，得到 1.23 倍。 2）H800 单卡算力：参考 DeepSeek 开源周公布数据，H800 峰值算力达 580TFLOPS。 因此，我们可以求得 DeepSeek 对 H800 的单卡利用率高达 77%。

基于上述拆解，我们提炼出影响算力需求的三个要素：

A）算力效率：具体体现在模型参数量、单卡利用率

DeepSeek 通过混合专家模型（MoE, Mixture of Experts），每次前向传播过程中，只有 少数专家参与计算，而其他专家则处于闲置状态，因此，尽管 DeepSeek R1 大模型的总参 数量有 671B，但单次推理激活的参数数量仅 37B，进行推理服务时仅需考虑被激活的参数 数量，带动算力需求下降。 从单卡算力利用率看，DeepSeek 对 H800 的利用率高达 77%，接近峰值算力。

B）算力冗余需求：具体体现在峰值倍数

根据 DeepSeek 的文章进行测算，其用于推理服务的 1814 张 H800 的峰值倍数仅 1.23 倍左 右。而若要应对流量突发、硬件故障或负载波动等，一般会预留更多的冗余资源比例。因 此，用户在使用 DeepSeek 的过程中，常常会碰到服务器繁忙、无法使用的情况。

C）用户使用强度：具体体现在数据规模

数据规模即大模型每秒处理的 token 数目，根据 DeepSeek 披露，其日均 token 调用数约 为 7760 亿，对应数据规模约为 900 万 tokens/秒。

我们对日均 token 调用数量进行进一步拆解，即，DAU*单 DAU 搜索请求次数*单次请求调 用 tokens 数量。我们假设单次请求调用 tokens 数量约为 2 万，基于 DeepSeek2500 万的 DAU，则可以测算得到，DeepSeek 单 DAU 搜索请求次数（即，用户使用频次）仅 1.55 次。 说明未来用户数、使用频次的提升均有望带来数据规模的进一步增加。

基于以上拆解，我们发现 DeepSeek 低算力的原因在于：1）超高的算力效率，具体体现在 单次推理激活的模型参数量、高单卡利用率；2）低峰值倍数：未设置较大的算力冗余。 但 DeepSeek 高算力效率不等于算力通缩。我们认为算力卡的数量仍然重要，但也更考验厂 商通过底层架构设计等提升算力效率的能力，参数量*效率*数据规模（而非过去“参数量* 数据规模”）是新的 scaling law 方向。同时，伴随用户数、使用频次的提升，数据规模有 望进一步扩大，带动算力需求提升。在下文中我们将就此展开分析。

3.2. AI Chatbot 的算力需求量估算：我们预计约 60-70 万片

DeepSeek 的大模型推理服务是 AI Chatbot 聊天机器人的典型应用，基于前文 DeepSeek 相关假设，我们估算 AI Chatbot 应用的芯片需求量约为 60-70 万片。 具体新增假设如下： 1）使用 AI 芯片假设：考虑到 H800 已经禁售，当前国内主流 AI 芯片采用的是英伟达提供 的 H20，而 H20 的 FP16 峰值算力仅为 148TFLOPS。 2）单卡利用率：参考 DeepSeek 的单卡利用率，我们给予行业平均约 70%的利用率水平。 3）用户数：2025 年 1 月，ChatGPT 的日活约为 5323 万，我们假设 AI Chatbot 应用的远 期用户数能达 5000 万人左右。 4）峰值倍数：为保证服务，我们设置了一定的算力冗余，假设峰值倍数为 4。

3.3. 多品类 APP 接入 AI 大模型、多模态、AI Agent 原生产品带动算力需求扩容

市场担心 DeepSeek 算力效率的提高大幅降低了算力需求，当前算力芯片存量已经冗余。 我们认为基于 DeepSeek 测算出的主要是 AI Chatbot 应用的 AI 芯片需求量，多品类 APP 接入 AI 大模型、多模态、AI Agent 等 AI 原生产品将带来算力需求的进一步扩容。

1）多品类 APP 接入 AI 大模型：现有 APP 接入 AI 大模型，带来用户数的增长

各 APP 可接入 AI 大模型（如 DeepSeek）实现应用的 AI 化；对应各 APP 的用户将在 APP 内与 AI 进行交互。因此，我们认为远期 AI 大模型的用户数也不应仅仅局限于 DeepSeek 单个 APP 的日活 DAU 数量进行估算，甚至也不应局限于单个 APP 的 DAU。从某种程度上而 言，其他 APP 接入大模型本质是给大模型引流，远期用户数或可展望亿级。

2）多模态、AI Agent 带来单次请求调用 tokens 数量的大幅增加

DeepSeek 中的对话主要基于纯文字，并没有考虑到多模态大模型（除了纯文字以外，还 包括图片、音频、视频等内容载体）带来的算力需求增量。而图片、音频、视频等内容将 带来单次请求调用 tokens 数量的大幅增长。参考 DeepSeek 官网给出的 Token 用量计算方 法，一般模型中 1 个英文字符约等于 0.3 个 token，而 1 个中文字符约等于 0.6 个 token。 而根据谷歌，在 Gemini 2.0 多模态大模型中，单个图片对应 258 个 tokens，单个视频对 应 263 个 tokens，单个音频则对应 32 个 tokens。最强 Gemini2.0 Pro 版本最多可支持 2M 的上下文长度，而对比 DeepSeek R1 的上下文长度最多仅支持约 64K。

Manus 的发布引发全网关于 AI Agent 的热烈讨论，AI Agent 将带来单次请求调用 tokens 数量的大幅增加。根据智东西公众号，一个任务交给 Manus 执行后，耗费了约 24 万 tokens、 3 小时，Manus 执行了 txt 文件的下载、保存、生成等；而同样的问题通过 DeepSeek 则可 以秒出答案，但仅有文字回复。AI Agent 所耗费的 tokens 数量大幅增加。

我们估算多模态、AI Agent 的发展将带来用户单次请求调用 tokens 数量增加至 1M。如前 文所述，根据 Gemini2.0 Pro，其最多可支持 2M tokens 的上下文长度；同时，AI Agent 所耗费的 tokens 数量可能是 AI Chatbot 的百倍。综合以上因素考虑，我们假设多模态、 AI Agent 的发展将带来用户单次请求调用 tokens 数量增加至 1M。 基于前文的测算框架，若同样假设多模态大模型的用户数为 5000 万，单用户每天请求次 数为 5 次，单次请求调用 tokens 数量提升至 1M，则对应的 H20 需求量约 800 万。

编辑：火腿肠