選自 orenleung.super.site
作者：Oren
機器之心編譯
編輯：rome rome
OpenAI 推出的 ChatGPT 到底是不是 1750 億參數的等價大模型呢？這篇文章或許能帶給你答案。
ChatGPT 的火熱持續到了今天，圍繞它的爆點新聞和技術解讀不斷湧現。關於其參數量，有一種普遍的假設認為，ChatGPT 的參數量與 GPT-3 論文中介紹的 1750 億參數模型相同。但是，深耕於大語言模型領域工作的人很清楚這不是真的。通過對 A100 GPU 的內存帶寬分析，就會發現 ChatGPT API 的實際推理速度要比 1750 億 Dense equivalent 模型的最大理論推理速度快很多。
本文將使用反證法來證明並支持上面的論點，只需要使用大學裡學到的一些理論知識。另外需要注意，還存在相反的問題，即有人聲稱 ChatGPT 只有 X 億個參數（X 遠遠低於 1750 ）。但是，這些說法無法得到驗證，因為說這些話的人通常是道聽途說。
接下來是詳細的論證過程。
反證法
先假設 ChatGPT 模型有 1750 億個參數，通常用 INT8 格式來存儲 LLM 權重，以便進行更低延遲的推理、更高的吞吐量和更低的內存需求（比用 float16 格式來存儲要少兩倍的內存）。每個 INT8 參數需要 1 個字節進行存儲。簡單的計算就知道，模型需要 175GB 的存儲空間。
就推理而言，GPT 風格的語言模型在每次前向傳遞時都是「自回歸」的，它預測下一個最可能的 token（對於類似 ChatGPT 的 RLHF 模型，它會預測其人類標註者更偏好的下一個 token）。這意味著要生成 200 個 token，因此需要執行 200 個前向傳遞。對於每個前向傳遞，我們需要將模型的所有權重從高帶寬（HBM）內存加載到矩陣計算單元（GPU 的張量計算核）中， 也就是說需要為每個前向傳遞加載 175GB 的權重。
在微軟 Azure 平台上，一個節點上可以分配 A100 的最大數量是 8。這意味著每個模型實例的最大張量並行度是 8。因此，其實不需要為每個前向傳遞加載 175GB 的權重，而只需要為每個前向傳遞的每個 GPU 加載 21.87GB，因為張量並行性可以在所有 GPU 上並行化權重和計算。
在 A100 80GB SXM 版本上，最大內存帶寬是 2TB/s。這意味著在 batchsize=1 的情況下（受內存帶寬限制），前向傳遞最大的理論速度將達到 91 次 / 秒。同時，大部分時間都花在加載權重上，而不是計算矩陣乘法。
ChatGPT 的實際延遲是多少？
在夜間運行 Python 編寫的腳本（夜間運行的開銷更低），來測試通過 OpenAI API 使用 ChatGPT 的延遲，前向傳遞能夠獲得的最大實證速度是 101 次 / 秒。本文使用了實驗的最大實證結果，這是因為需要從 OpenAI 的後端和動態批處理系統獲得最低開銷。
結論
根據前面假設和論證，我們可以發現存在矛盾的地方，因為基於實證的結果比基於 A100 平台內存帶寬的最大理論結果要快得多。因此可以得出結論，OpenAI 用於推理的 ChatGPT 模型絕對不是等價於 1750 億參數的稠密模型。
常見問題問答
1、為什麼預測 ChatGPT 推理模型的參數量而不是訓練模型的參數量？
使用內存帶寬方法來估計模型參數數量，這隻適用於推理模型。我們無法確切地知道 OpenAI 是否應用了蒸餾等技術，使其推理模型比訓練模型更小。
許多昆蟲都有一種幼蟲形態，其在從環境中提取能量和營養方面進行了優化，而完全不同的成體形態則在旅行和繁殖的非常不同的要求方面進行了優化。—— 出自 Geoffrey Hinton、Oriol Vinyals、Jeff Dean，2015 年。
2、是否有做其它的假設？
證明中其實還包括 3 個假設：
假設計算巨大矩陣乘法所需的時間相對於每個前向傳遞加載參數的時間為 0；
假設進行 GPU 之間的通信所需的時間也為 0。如果不假設 GPU 之間的通信和矩陣乘法所需的時間為 0，則 1750 億參數模型的每秒最大理論 token 將會減少；
假設 ChatGPT 是基於 Transformer 架構的變種。
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 等）。
參考連結：
https://kipp.ly/blog/transformer-inference-arithmetic/
https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/a100/pdf/nvidia-a100-datasheet-us-nvidia-1758950-r4-web.pdf
https://openai.com/research/techniques-for-training-large-neural-networks
https://arxiv.org/abs/2211.10438
https://arxiv.org/abs/1909.08053
https://arxiv.org/abs/2005.14165