不是人人都有“钞能力”，我们的故事，
从用单节点方案部署DeepSeek-R1开始。
为什么是单节点呢？
因为H200单卡有140GB显存，可用单节点（8卡）方案部署。
而H800和HI00显存80GB，需要双节点方案。
有卡了，就可以来玩DeepSeek。
世界是场游戏，是游戏就有作弊的玩家。
怎么作弊呢？等下说，
先看看芯片厂商AMD的官网技术博客。
网址在此：https://rocm.blogs.amd.com/artificial-intelligence/DeepSeekR1_Perf/README.html
时间是25年2月21日。
我相信哪怕是这几天的时间，AMD的性能指标也还在增长。
没办法，AI就是这么卷。
换个角度，这篇可以说是，
从AMD官网博客中学习大模型推理性能知识点。
下图是两种芯片，英伟达H200和AMD MI300X，
用一个节点（8卡）跑出来的性能。
为什么要学这些知识点呢？
答案很简单，以防被忽悠。
话说，性能指标是一个非常关键的数值，
背后都是技术实力，
甚至可以说性能是技术实力的终极体现。
是骡子是马，你拉出来溜溜。
不过，现在是技术向上震荡期，
很多人对大模型性能指标不熟悉，
会有人借机在这个指标上面作弊。
别着急知道作弊手法，
在看懂作弊之前我们先了解如何公平，
对，公平比较两种芯片性能。
我们先看懂图上的“已知条件”
图上都有什么信息呢？
我们都知道，
大模型推理分为两个关键任务，
有各自的生成时间：
一个是输入（Prefill任务）所用时间，
另一个是输出（decode任务）所用时间。
其实所有的性能几乎都可以分这两个阶段来观察。
大模型推理中有两个关键指标，
两个关键指标是：
吞吐量（Throughput）和延迟（Latency）
吞吐量通常指每秒生成的token数量，
而延迟是从输入到输出的时间。
时间非常关键，
每秒吞吐量越高，意味着计算机系统能在单位时间内处理更多的请求。
就是单位时间干的活越多越好。
当然，牛马也一样。
这张图告诉我们：
图中有两种芯片，
英伟达H200型号和AMD的MI300X型号，
为了公平比较两种芯片的性能，要统一测试，
为什么要统一测试？
这样才能看出处理相同工作量时，
哪个芯片速度更快、效果更好。
我们要用相同的“题目量”和“回答量”来进行测试，
也就是，统一处理4000个token（题目和回答加在一起）。
图中原话是：输入3200个token和输出800个token。
这样，两个系统都各自处理4000个token的信息量，
而且图中已知，每个推理请求中，平均向系统问出500个问题。
这样，测试“系统处理token数量”统一了。
这张图还想告诉我们几个技术概念，
吞吐量（单位：token/秒）
延迟（单位：毫秒）
下面，我们会把毫秒换算成秒。
而最大并发数（Max Concurrency）是什么呢？
就是衡量系统在同一时刻能同时服务多少个请求，
能让我们了解AI 系统在真实环境下对大量请求的抗压能力，
就像考场里同一时间安排多少考生一起考试的道理一样。
最大并发数，用Batch Size表示：
我们要根据不同的请求数量，观察系统性能分别是多少。
因为是测试，所以非常细致，
能让我们了解 AI 系统在真实环境下对大量请求的适应能力，
就像考场里同一时间安排多少考生一起考试的道理一样。
当推理请求数量（Batch Size），
分别是是1，2，4……128，
Batch Size1是只有1个请求，
Batch Size2，同时处理2个请求，
Batch Size4，同时处理4个请求，
以此类推，直到Batch Size128，
就是同时处理128个请求。
打个比方，当我们说Batch Size1，
代表只有1个人在考试，1个人用考试系统；
Batch Size2，代表有2个人一起考试；
以此类推，Batch Size128 ，
就意味着128个人同时在考试。
如果只有1 个人在考试（Batch Size1），
系统专心为一个考生服务，一般来说，速度慢不了；
如果有128 个考生一起考试（Batch Size128），
系统就要同时对128 个人的题目进行阅读、思考、回答，负担变大，
可能会增加等待时间。
我们再来看图，
在图上左下方读到的第一个数字是170，
单位tokens/s。
意味着：
已知总共4000个token的信息量，
当BatchSize1的时候，每秒处理170个token，
以这种速度来处理，
那需要的时间就是4000除以170等于23.5秒。
就是用23.5秒就能把这4000个token算完。
23.5秒在时间轴横轴上处于2万毫秒右边一点的位置。
没有明确写出来，但我们读图能读出来。
图片试图说明AMD芯片性能很好，
然而，我对AMD的这种广告没有什么兴趣。
我感兴趣的是：AMD这个厂商很良心，
他们的性能数据很清楚地告诉我们，
输入和输出的字数是多少（输入3200个token和输出800个token），
3200+800就是系统总处理的token数，
4000除以170等于23.5秒，
也就是说，decode任务时间是23秒，
也是恒定的塞进去的信息量就这么多。
好比，东西放进大模型里面多长时间能“出锅”，
需要测量一个客观的时间，
也就是，系统跑出来是几秒就是几秒。
生成速度，也就是多少秒生成多少token是一个硬指标，
是用总吞吐量除以测量出得时间得出来的。
这里要稍微计算一下了：
用图上的已知信息倒着推理两个信息。
当我们跑8张卡的H200的系统（单节点），
在Batch Size1的时候，情况如下：
情况一：输入3200，输出800，4000=3200+800
4000tokens除以170tokens/s等于23.53秒
估计decode时间大约为23秒，
再看decode的信息处理量是800token，
decode800tokens除以23秒等于35tokens/s。
看好了，这时候我要来“作弊”了，把输入和输出的数据互换一下。
情况二：输入800，输出3200，4000=800+3200
3200tokens除以34.78tokens/s，
就是每秒跑出来34.78个token，
虽然同样还是处理总共4000个token，
但是，用3200除以35okens/s等于91秒，
decode时间就会变得很长，91秒。
都是处理同样的信息量，调整输入和输出，
decode的时间从23秒变成了91秒。
这个技术细节非常重要。
有时候，厂商提供的测试数据是prefill和decode加在一起的，
当然，也可以说混在一起。
既然“混了”，“摸鱼”的机会就来了，
好比两个长跑运动员，
一个叫prefill，一个叫decode，
prefill跑得快，decode跑得慢，
至于为什么decode慢，
这个你的去问“注意力机制”这个家伙了，
都是它干的好事，这里不展开。
同样的一段长跑运动，
prefill和decode的速度应该分别记录，
假如想作弊，就把尽量长的路程给prefill跑，
它速度快，时间肯定就缩短了。
要是不懂，猛一看性能，觉得还挺快嘞。
还是那句话，性能是和采购决策相关的关键指标。
厂商AMD很客观，告诉你比例了（输入3200，输出800），
有人会把prefill的比例调高点，数值就更好看了，
因为decode跑得慢，让decode少跑，也就是少干点活。
请注意，有些性能指标旁边标着“仅输出”（decode only）
这不是不可以，而是，拿“仅输出”的指标和整个推理的吞吐指标对比，
不讲武德。
总结一下：写性能，请把prefill和decode处理的工作量标清楚，谢谢。
最后预告下，过几天发的文章，
我会把图上所有的指标都算出来，会有新结论。
上一篇回顾：
《DeepSeek：为了这口醋，包了这顿饺子，为了数据，我造了模型》
