最近几周发了两篇关于Deepseek推理成本的文章，获得了很大的关注以及争议。第一篇是2月16号，其实业内老师都知道，这篇文章是全网最早、也是最准确的推理吞吐量估计，2000t/s当时代表了国内一线云厂家能够优化实现的水平。
第二篇文章是在3月1日deepseek官方公布实际成本后，对deepseek公开的数据做了一个快速解读。这个结果不光是震撼了投资界、甚至整个AI业界，技术实在是太超前了。
然而昨天和今天却出现不少反驳的声音，认为其中很多deepseek的数据是哗众取宠，没有实际意义。所以我觉得有必要再写一篇：从商业的角度，全面地拆解deepseek的真实利润率，省流版：至少能做到60%。最后我会再测算一下我们到底需要多少算力卡，这里先卖个关子。
目录：
（一）分析框架
（二）吞吐决定成败
（三）哪里来了怎么多输入？
（四）负载率多少是合理的？
（五）真实毛利的估计
（六）最后聊一聊算力卡的需求
（一）分析框架
老师们指出的问题五花八门，总结起来就是有一些现实因素没有考虑，一方面了分析框架需要简洁明了，同时又包括关键因素。因此我提出了如下的分析框架中：
其中：
其他成本占比：其他经营性成本（比如运维、带宽、人工等）/计算成本，这里做了一个比较粗略的假设，认为这些成本没有规模效应，随着计算规模等比例增加的
满载计算收入=输入吞吐*输入算力占比*输入定价+输出吞吐*输出算力占比*输出定价，这个是衡量一个平均节点产生收入的能力
这样我们可以首先考虑在满载情况下，比较理想的利润率应该是怎么样的。同时也可以独立地讨论负载率、折扣率、其他成本等因素的影响。
为了讨论方便，计算成本的单位我们统一用单卡的时租价格美金/小时/卡，吞吐单位统一为token/秒/节点（1节点=8卡），算力单位为节点*小时，定价单位为美元/百万token。这些都是业界常用的单位，有助于读者有更直观的商业理解，繁琐的单位换算过程我会在计算过程中加入。
Deepseek昨天的文章已经告诉我们几乎满载下的理论毛利率=1-计算成本/满载计算收入=85%。下面我们将讨论几个重要的参数，并合理估计真实的利润率。
（二）吞吐决定成败
大家都知道V3/R1是prefill、decode分离的（PD分离），也就是说prefill用一个集群，decode用另一个集群。官方详细地介绍了两个集群的具体设置。对于大模型技术不熟悉的朋友，我们可以把prefill可以简单理解为输入计算，可以简单理解decode为输出计算。
根据官方公布的PD分离的平均吞吐，prefill是73.7kt/s，decoding是14.8kt/s。我的上一篇文章对于吞吐的计算是有错误的， 分子只有输出的总量，分母确实全量算力（还包含输入），相当于严重低估了实际吞吐。
那么我们可以直接计算出输入、输出分别的计算收入：1）输入部分需要考虑缓存命中率的差异，输入计算节点每小时收入=（0.14*56.3%+0.55*43.7%）* 73.7*3600/1000=84.7$/h；2）输出则是=2.19*14.8*3600/1000=116.7$/h。
这两个数字非常接近！这就是我昨天提到的。deepseek对API定价考虑非常科学，几乎是严格按照计算性能来定价，其结果就是输入、输出计算的节点挣钱能力是差不多的。
然后我们还可以倒算用于输出的算力有多少，168B/14.8k/3600=3153（节点*小时）。那么5442-3153=2289（节点*小时）是用于输入的算力，检查一下是否正确，2289*73.7*3600=608B，完美对上。
输入的计算竟然占用了42%的算力，输出用了58%的算力。那我们带入公式就可以知道一个节点的满载计算收入=103美元/小时。要知道一个H800节点的时租成本也就是2*8=16美元/小时。1-16/103=84.5%毛利，这就是理论满载上限值。
熟悉财务分析的朋友一眼就看明白了，决定毛利最根本因素就是吞吐量。Deepseek能够实现极高利润率的根本原因就是吞吐量非常非常高。
作为一个对比，Nvdia官方有两个可以参考的数据。1）1月30日，在官方blog中透露，在H200节点上可以实现3,872t/s的峰值输出吞吐，这里我估计应该是FP8精度；2）2月25在x上公布FP4精度优化性能，H200节点峰值输出吞吐优化到5,899t/s，B200节点峰值输出吞吐则高达21,088t/s。
要知道Deepseek是FP8原生精度，Deepseek用阉割版的H800实现了14.8kt/s的输出吞吐（相比于H200大约砍了20-25%的性能），是Nvdia H200 FP8性能的整整3.8x！我估计老黄做梦也想不到有人比他们更懂GPU。
这就很好理解为什么尤某的潞晨科技为什么会关停deepseek服务，因为他真的在亏钱。我在两周前的文章中就给大家推算过了，他只能实现185t/s的吞吐，纯粹就是因为自己菜。
（三）哪里来了怎么多输入？
常规的大模型测试中常用的输出和输出假设为1:1或者1:3，如果是R1这种推理大模型可能会用1:5的假设。但是deepseek的真实运营数据告诉我们，日输入token：输出token是608B：168B，输入：输出比高达3.6比1。
这就太有意思了！大推理模型跟我们想象中完全不一样。实际情况完全颠倒过来了，输入比输出还多！
这就是为什么有人认为ds这个数据严重不可靠，似乎是客户给了大量输入，但服务器忙不过来，输出严重不足。这实在是有点滑之大稽了。从技术上讲，如果ds的服务器暂时无法服务，根本就不会产生第一个token，整个prefill计算都不会发生。
假设DAU 2400万（这是2月9日的数据，我只有这个参考数据，如果有朋友近期最新的DAU请留言告知），我们可以计算出来，日均DAU的输入/输出长度为25k/7k token！
我认为是基于两个原因：
1）搜索等RAG应用：因为搜索需要把检索到十几个都统统给deepseek阅读一遍。这说明大量C端用户是使用了“联网搜索功能”。如果调用API的客户也是用于个人知识库、企业知识库等场景，RAG同样会给模型输入大量的资料。
这个就几乎能严格对上了，一个搜索请求平均会调用2万个token，而日均DAU的输入总长度就是25k，相当于人均1.25个搜索请求。
2）多轮对话导致上下文累积：不知道你们是如何使用的，我反正是每次使用一个对话用到底，很少会单独新开对话。如果说第一次输入1k，第一次输出5k，那么第二次输入就是6k了，第二次输出还是5k，第三次输入则会增加到17k（1+5+6+5）。导致前面很多轮请求的内容都会作为输入扔给模型，导致上下文越来越长。
（四）负载率多少是合理的？
因为春节期间deepseek确实爆单了，很多人会有固有印象认为Deepseek的API服务根本不可用，实际情况需要至少5-10倍冗余。
让我们来看看一个非常打脸的数据，根据Grafana监测的Deepseek R1 API可用性指标，在官方选取的时间段内（2月27日12点到28日12点），API几乎是100%可用！
也就是几乎不存在服务不可用的情况，只是服务的速度是否令人满意！
我们可以观察到，deepseek官方最大的问题是输入问题后的等待时间很长。我们叫TTFT（Time to First Token），负责这一部分的就是prefill。一旦开始回答问题后，推理的速度其实并不慢（20-22t/s左右的速度并不会让人觉得很卡），我们叫TPOT（Time per Output Token）。
现实跟很多人想象的完全不同。Deepseek服务器真正的瓶颈不是输出推理，而是输入！大多数用户都是在排队等待输入。
要保证TTFT并不容易、因为输入请求取决于用户enter的时间点，随机性更高，更难将服务器负载填满。
而要保证输出则简单很多：平均输出长度5k token，按照21t/s的输出速度，输出需要整整4分钟！在4分钟的窗口内，就有很大的空间来分配不同用户的任务，保证负载均衡。
有大量相关研究工作，一般认为负载率70%-90%时，可以比较好地平衡TTFT和吞吐。感兴趣的老师可以去阅读无问芯穹的漫谈大模型推理优化技术系列文章。
很多老师认为需要2-3x的冗余才能服务好B端客户。Deepseek的服务集群只有276个节点，现阶段又不怎么收钱，需求峰值的时候肯定不会去扩容的，大家只能老老实实等着。但实际MaaS API服务中完全可以在需求峰值的时候做弹性扩容，这样保证单位算力经济性不变的情况满足峰值的波动。
（五）真实毛利的估计
作为一个假设性的推演，我们不妨做一些敏感性计算：
1）假设负载率为80%，折扣率不妨取为80%（考虑到大客户折扣，offpeak折扣），其他成本占20%。真实毛利率=1-14.5%*120%/80%/80%=73%
2）负载率为70%，折扣率70%，其他成本占30%。真实毛利率=62%
3）负载率为60%，折扣率60%，其他成本占40%。真实毛利率=44%
个人认为60%的真实毛利率是完全可以达到的。事实上欧美CSP的PaaS毛利率也都在50-60%水平，MaaS至少应该和PaaS服务持平。
（六）最后聊一聊算力卡的需求
昨天对大家冲击最大的事实是，Deepseek只用了1814张卡就服务了2400万的DAU，那服务全中国14亿人岂不是只需要14/0.24*1814=~10万张卡？再加上30%冗余也就是10/70%=14万卡。
这是事实没错了。但未来最大的变量是单用户的使用强度。
Deepseek文章也透露了KVcache的长度就是4989，其实这就是平均输出的长度。前面我们算过人均DAU的输出总长度是7k，相当于每个DAU只有1.4个对话，属实是有点少了。
就目前我个人的使用强度，每天至少问30多个问题吧，元宝已经成为我打开强度最高的app和网页了。当然我们知识工作者的使用强度肯定是偏高的。
未来假设人均每天14次请求并不过分吧，那么这就需要140万张卡了。
随着企业内部流程，各种AI应用的落地，人均日均请求甚至可以达到几十甚至几百。长期算力的需求还是难以估计。
文章来源：老罗的暗中观察，原文标题：《回应争议：Deepseek真实利润率是多少？到底需要多少算力？》
