ChatGPT 的火熱持續到了今天,圍繞著它的爆點新聞和技術解讀不斷湧現。關於其參數量,有一個普遍的假設認為,ChatGPT 的參數量與 GPT-3 論文中介紹的 1750 億參數模型相同。但是,深耕大語言模型領域工作的人很清楚這不是真的。透過對 A100 GPU 的記憶體頻寬分析,就會發現 ChatGPT API 的實際推理速度比 1750 億 Dense equivalent 模型的最大理論推理速度快很多。
本文將使用反證法來證明並支持上面的論點,只需要使用大學裡學到的一些理論知識。另外要注意,還有相反的問題,有人聲稱 ChatGPT 只有 X 億個參數(X 遠低於 1750 )。但是,這些說法無法被驗證,因為說這些話的人通常是道聽途說。
接下來是詳細的論證過程。
先假設ChatGPT 模型有1750 億個參數,通常用INT8 格式來儲存LLM 權重,以便進行更低延遲的推理、更高的吞吐量和更低的記憶體需求(比用float16 格式來儲存少兩倍的記憶體)。每個 INT8 參數需要 1 個位元組進行儲存。簡單的運算就知道,模型需要 175GB 的儲存空間。
圖片出自INT8 SmoothQuant 論文,網址:https://arxiv.org/abs/2211.10438
就推理而言,GPT 風格的語言模型在每次前向傳遞時都是「自回歸」的,它預測下一個最可能的token(對於類似ChatGPT 的RLHF 模型,它會預測其人類標註者更偏好的下一個token)。這意味著要產生 200 個 token,因此需要執行 200 個前向傳遞。對於每個前向傳遞,我們需要將模型的所有權重從高頻寬(HBM)記憶體載入到矩陣運算單元(GPU 的張量計算核)中, 也就是說需要為每個前向傳遞載入175GB 的權重。
在微軟 Azure 平台上,一個節點上可以分配 A100 的最大數量是 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 的後端和動態批次系統獲得最低開銷。
結論
#根據前面假設和論證,我們可以發現矛盾的地方,因為基於實證的結果比基於A100 平台記憶體頻寬的最大理論結果快得多。因此可以得出結論,OpenAI 用於推理的 ChatGPT 模型絕對不是等價於 1750 億參數的稠密模型。
1、為什麼預測 ChatGPT 推理模型的參數量而不是訓練模型的參數量?
使用記憶體頻寬方法來估計模型參數數量,這只適用於推理模型。我們無法確切地知道 OpenAI 是否應用了蒸餾等技術,使其推理模型比訓練模型更小。
許多昆蟲都有一種幼蟲形態,其在從環境中提取能量和營養方面進行了優化,而完全不同的成體形態則在旅行和繁殖的非常不同的要求方面進行了最佳化. —— 出自 Geoffrey Hinton、Oriol Vinyals、Jeff Dean,2015 年。
2、是否有做其它的假設?
證明中其實也包含3 個假設:
3、Dense Equivalent 是什麼意思?
在過去幾年中,研究人員已經進行關於稀疏混合專家 LLM(如 Switch Transformer)的研究。 Dense equivalent 表示每次前傳遞使用多少參數。使用本文所述的方法,無法證明 ChatGPT 不是一個 1750 億參數的稀疏 MoE 模型。
4、是否考慮過 KV 快取 Transformer 推理最佳化?
就算使用KV 快取優化,每次前向傳遞仍需要載入整個模型,KV 快取僅在FLOPs 上節省,但不會減少記憶體頻寬消耗(實際上它會增加,因為需要每次前向傳遞都載入KV 快取)。
5、是否考慮過 Flash Attention?
雖然 Flash Attention 在記憶體頻寬效率和實際時間速度方面表現更好,但每次前向傳遞仍需要載入整個模型,因此前面的論證仍然成立。
6、是否考慮過管道並行 / 更細粒度的平行策略?
利用 pipeline 並行會導致相同的最大前向傳遞次數。但是,透過使用 micro-batch 和更大的 batch 大小,吞吐量(總 token 數 / 秒)可以增加。
#7、考慮過將張量並行性增加到 8 以上嗎?
A100 平台支援每個節點 16 個 A100,但 Azure 不支援此功能。只有 Google Cloud 支援此功能,但幾乎沒有人使用。 Azure 不太可能為 OpenAI 客製化一個具有 16 個 A100 的節點,並且不會將其發佈為公共 GA 版本,以分攤設計或維護新節點的成本。關於節點間的張量並行性,這只是一個可能性,但這是一種不太具成本效益的在 A100 上進行推理的方式。就連英偉達也不建議節點間的張量並行處理。
8、有沒有考慮使用 INT4 儲存權重?
儘管使用INT4 被證明有效,但是OpenAI 的GPU Kernel Compiler 不支援INT4 的載入、儲存或矩陣乘法,也沒有計劃將INT 加入到他們的技術路線圖中。由於不支援 INT4 的載入或存儲,你甚至無法像將權重存儲為 INT4,然後量化轉回高精度格式(如 INT8、bfloat16 等)。
以上是ChatGPT模型參數≠1750億,有人用反證法證明了的詳細內容。更多資訊請關注PHP中文網其他相關文章!