不是人人都有「鈔能力」，我們的故事，
從用單節點方案部署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：為了這口醋，包了這頓餃子，為了數據，我造了模型》
-
-
-
-
-
-
-
-
-
-