国金证券在《DeepSeek算力效率提升≠算力通缩》报告中深入分析了DeepSeek的底层架构优化与算力效率表现。DeepSeek仅用1814片H800支持了约2500万DAU，H800单卡利用率高达77%，decode任务平均每台H800输出吞吐14.8k tokens/s，超出经过优化的英伟达H200。国金证券认为，高算力效率不等于算力通缩，“参数量×效率×数据规模”才是新的Scaling Law方向。
大规模专家并行（EP）+计算通信重叠（DP）的架构革命
DeepSeek-V3/R1采用高度稀疏的MoE架构，每层256个专家但每次前向传播仅激活8个。为提升吞吐能力，DeepSeek采用大规模跨节点专家并行（EP），将专家参数分布式存储在多个GPU中，被激活的专家分散到不同GPU处理。预填充阶段部署48节点（EP32），解码阶段部署188节点（EP144）。
EP带来较大通信开销，DeepSeek采用计算通信重叠（DP）缓解这一问题。预填充阶段将一批请求分成两个微批次，当一个微批次计算时，另一个微批次的数据正在传输或准备，实现计算与通信重叠。通过双批次交替处理，有效减少了通信耗时，大幅提升吞吐能力。
算力效率实测——H800吞吐14.8k tokens/s超H200
根据DeepSeek披露，decode任务平均每台H800输出吞吐约14.8k tokens/s。作为对比，2025年2月优化后的英伟达H200节点峰值输出吞吐仅5.9k tokens/s，B200节点峰值输出吞吐21k tokens/s。DeepSeek在使用性能低于H200的H800前提下，吞吐能力仍然高于H200，算力效率极高。
DeepSeek用于推理服务的H800数量仅1814个，支持约2500万日活用户。测算得到H800单卡利用率高达77%，接近峰值算力580TFLOPs。高算力效率源于两个方面：单次推理仅激活370亿参数（而非671B总参数量），以及大规模集群架构优化带来的吞吐率提升。
大规模集群的规模效应——批量增大，边际时间下降
吞吐率取决于批量大小（batchsize）与延时（latency）。起初增加batchsize能快速提升吞吐率，但也会增加延时。随着batchsize继续增加，延时增长会逐渐抵消吞吐量收益。
DeepSeek通过EP与DP架构优化，实现在增加batchsize的同时，计算时间和通信时间边际下降，吞吐率得到提升。这体现了大模型的规模效应——大规模集群能提高算力利用率。低峰值倍数（仅1.23倍）虽然降低了算力需求，但一定程度上牺牲了用户体验，用户常遇到服务器繁忙的情况。
算力效率≠算力通缩——新的Scaling Law方向
市场担心DeepSeek仅用1814个H800支持2500万DAU会证伪算力需求。但DeepSeek低算力的原因在于超高算力效率（单次推理仅激活370亿参数、77%单卡利用率）和低峰值倍数（1.23倍，牺牲用户体验）。
算力需求=模型参数量×数据规模×峰值倍数×（1/算力效率）。DeepSeek的案例凸显了算力效率的重要性，但高算力效率不等于算力通缩。“参数量×效率×数据规模”才是新的Scaling Law方向。伴随峰值倍数的提高、数据规模的扩大，算力需求有望持续提升。当前单DAU搜索请求次数仅1.55次，未来用户数、使用频次的提升均有望带来数据规模进一步增加。
表：DeepSeek推理服务算力利用率测算| 指标 | 数值 | 单位 |
|---|
| 日均tokens调用数量 | 7760 | 亿 |
| 日均总时长 | 86400 | 秒 |
| 数据规模 | 0.09 | 亿tokens/秒 |
| 峰值算力倍数 | 1.23 | 倍 |
| 模型参数量（激活） | 370 | 亿 |
| 算力需求 | 0.8 | EFLOPS |
| H800使用量 | 1814 | 片 |
| H800单卡利用率 | 77 | % |
