ChatGPT 的火熱持續(xù)到了今天，圍繞它的爆點新聞和技術解讀不斷涌現(xiàn)。關于其參數(shù)量，有一種普遍的假設認為，ChatGPT 的參數(shù)量與 GPT-3 論文中介紹的 1750 億參數(shù)模型相同。但是，深耕于大語言模型領域工作的人很清楚這不是真的。通過對 A100 GPU 的內存帶寬分析，就會發(fā)現(xiàn) ChatGPT API 的實際推理速度要比 1750 億 Dense equivalent 模型的最大理論推理速度快很多。

本文將使用反證法來證明并支持上面的論點，只需要使用大學里學到的一些理論知識。另外需要注意，還存在相反的問題，即有人聲稱 ChatGPT 只有 X 億個參數(shù)（X 遠遠低于 1750 ）。但是，這些說法無法得到驗證，因為說這些話的人通常是道聽途說。

接下來是詳細的論證過程。

反證法

先假設 ChatGPT 模型有 1750 億個參數(shù)，通常用 INT8 格式來存儲 LLM 權重，以便進行更低延遲的推理、更高的吞吐量和更低的內存需求（比用 float16 格式來存儲要少兩倍的內存）。每個 INT8 參數(shù)需要 1 個字節(jié)進行存儲。簡單的計算就知道，模型需要 175GB 的存儲空間。

圖片出自 INT8 SmoothQuant 論文，地址：https://arxiv.org/abs/2211.10438

就推理而言，GPT 風格的語言模型在每次前向傳遞時都是「自回歸」的，它預測下一個最可能的 token（對于類似 ChatGPT 的 RLHF 模型，它會預測其人類標注者更偏好的下一個 token）。這意味著要生成 200 個 token，因此需要執(zhí)行 200 個前向傳遞。對于每個前向傳遞，我們需要將模型的所有權重從高帶寬（HBM）內存加載到矩陣計算單元（GPU 的張量計算核）中， 也就是說需要為每個前向傳遞加載 175GB 的權重。

在微軟 Azure 平臺上，一個節(jié)點上可以分配 A100 的最大數(shù)量是 8。這意味著每個模型實例的最大張量并行度是 8。因此，其實不需要為每個前向傳遞加載 175GB 的權重，而只需要為每個前向傳遞的每個 GPU 加載 21.87GB，因為張量并行性可以在所有 GPU 上并行化權重和計算。

圖片出自 Megatron-LM 論文，地址：https://arxiv.org/abs/1909.08053

在 A100 80GB SXM 版本上，最大內存帶寬是 2TB/s。這意味著在 batchsize=1 的情況下（受內存帶寬限制），前向傳遞最大的理論速度將達到 91 次 / 秒。同時，大部分時間都花在加載權重上，而不是計算矩陣乘法。

注意：對于 fp16/bfloat16，當受內存帶寬限制時，最大的理論前向傳遞速度達到 45.5 次 / 秒。

ChatGPT 的實際延遲是多少？

在夜間運行 Python 編寫的腳本（夜間運行的開銷更低），來測試通過 OpenAI API 使用 ChatGPT 的延遲，前向傳遞能夠獲得的最大實證速度是 101 次 / 秒。本文使用了實驗的最大實證結果，這是因為需要從 OpenAI 的后端和動態(tài)批處理系統(tǒng)獲得最低開銷。

結論

根據(jù)前面假設和論證，我們可以發(fā)現(xiàn)存在矛盾的地方，因為基于實證的結果比基于 A100 平臺內存帶寬的最大理論結果要快得多。因此可以得出結論，OpenAI 用于推理的 ChatGPT 模型絕對不是等價于 1750 億參數(shù)的稠密模型。

常見問題問答

1、為什么預測 ChatGPT 推理模型的參數(shù)量而不是訓練模型的參數(shù)量？

使用內存帶寬方法來估計模型參數(shù)數(shù)量，這只適用于推理模型。我們無法確切地知道 OpenAI 是否應用了蒸餾等技術，使其推理模型比訓練模型更小。

許多昆蟲都有一種幼蟲形態(tài)，其在從環(huán)境中提取能量和營養(yǎng)方面進行了優(yōu)化，而完全不同的成體形態(tài)則在旅行和繁殖的非常不同的要求方面進行了優(yōu)化?！?出自 Geoffrey Hinton、Oriol Vinyals、Jeff Dean，2015 年。

2、是否有做其它的假設？

證明中其實還包括 3 個假設：

• 假設計算巨大矩陣乘法所需的時間相對于每個前向傳遞加載參數(shù)的時間為 0；
• 假設進行 GPU 之間的通信所需的時間也為 0。如果不假設 GPU 之間的通信和矩陣乘法所需的時間為 0，則 1750 億參數(shù)模型的每秒最大理論 token 將會減少；
• 假設 ChatGPT 是基于 Transformer 架構的變種。

3、Dense Equivalent 是什么意思？

過去幾年中，研究人員已經進行關于稀疏混合專家 LLM（如 Switch Transformer）的研究。Dense equivalent 表示每次前向傳遞使用多少參數(shù)。使用本文所述的方法，無法證明 ChatGPT 不是一個 1750 億參數(shù)的稀疏 MoE 模型。

4、是否考慮過 KV 緩存 Transformer 推理優(yōu)化？

就算使用 KV 緩存優(yōu)化，每次前向傳遞仍需要加載整個模型，KV 緩存僅在 FLOPs 上節(jié)省，但不會減少內存帶寬消耗（實際上它會增加，因為需要每次前向傳遞都加載 KV 緩存）。

5、是否考慮過 Flash Attention？

雖然 Flash Attention 在內存帶寬效率和實際時間速度方面表現(xiàn)更好，但每次前向傳遞仍需要加載整個模型，因此前面的論證仍然成立。

6、是否考慮過管道并行 / 更細粒度的并行策略？

利用 pipeline 并行會導致相同的最大前向傳遞次數(shù)。但是，通過使用 micro-batch 和更大的 batch 大小，吞吐量（總 token 數(shù) / 秒）可以增加。

7、考慮過將張量并行性增加到 8 以上嗎？

A100 平臺支持每個節(jié)點 16 個 A100，但 Azure 不支持此功能。只有 Google Cloud 支持此功能，但幾乎沒有人使用。Azure 不太可能為 OpenAI 定制一個帶有 16 個 A100 的節(jié)點，并且不將其發(fā)布為公共 GA 版本，以分攤設計或維護新節(jié)點的成本。關于節(jié)點間的張量并行性，這只是一個可能性，但這是一種不太具成本效益的在 A100 上進行推理的方式。就連英偉達也不建議對節(jié)點間的張量并行處理。

8、有沒有考慮使用 INT4 存儲權重？

盡管使用 INT4 被證明有效，但是 OpenAI 的 GPU Kernel Compiler 不支持 INT4 的加載、存儲或矩陣乘法，也沒有計劃將 INT 加入到他們的技術路線圖中。由于不支持 INT4 的加載或存儲，你甚至無法像將權重存儲為 INT4，然后量化轉回高精度格式（如 INT8、bfloat16 等）。