GPT-4 “煉丹”指南：MoE、參數量、訓練成本和推理的秘密

原創：拾象

**來源：**海外獨角獸

作者：Dylan Patel，Gerald Wong

編輯：海娜、文莉、凱奇

編輯：Siqi

圖片來源：由無界AI‌生成

本文編譯自專欄SemiAnalysis，作者是Dylan Patel 和Gerald Wong。不久前，Dylan Patel 還爆料過Google 內部信：We Have No Moat, And Neither Does OpenAI 。

GPT-4 是科學和工程深度結合創新的結果，中間有無數的tricks，對於外界，如果能了解GPT-4 的結構就如同獲得了最強模型的“煉丹秘方”。這篇內容十分詳盡地給出了GPT-4 的架構、訓練和推理的基礎設施、參數量、訓練數據集、token 數、成本、以及MoE 模型等參數和信息細節。

Dylan 和Gerald 認為，OpenAI 之所以不公開GPT-4 的架構，並不是出於所謂AI Safety 的考慮，而是因為這個架構很容易被複製；被稱為“天才黑客”的George Hotz 也表達過類似觀點，不過，George 認為GPT-4 由8 個專家模型的MoE 構成，每個專家模型的參數量約為1100 個。

兩位作者預計，Google、Meta、Anthropic、Inflection、Character.ai、騰訊、字節跳動、百度等公司在短期內將擁有與GPT-4 一樣甚至更強大的模型能力。即便GPT-4 的架構“很容易被複製”，但在他們看來OpenAI 擁有最持久的護城河——最多體量的終端用戶、領先的工程人才，以及在模型代際變化中的先發優勢。

友情提示：文章中的數據來自於原作者的多方收集和研究，尚未經OpenAI 證實，而Dylan Patel 的研究普遍被認為可信度很高，可以作為一篇不錯的GPT-4 深度研究材料參考。此外，我們認為文章中易複製的觀點可能有些“標題黨”的嫌疑，因為除OpenAI 和Google 外，目前擅長複雜MoE 框架訓練和推理的科學家很稀缺，且當前的GPT-4 也只是初代MoE，並不是OpenAI 給出的最終答案，並且過程中的大量經驗是其他團隊沒有的，而這些經驗一定也會成為OpenAI 的獨特優勢。

以下為本文目錄，建議結合要點進行針對性閱讀。

👇

01 概述

02 模型結構

03 數據集

04 並行策略

05 訓練成本

06 教育部

07 推理

08 推理的Infra 與成本

09 多查詢注意力機制

10 連續批處理

11 推測解碼

12 視覺多模態

01.概述

OpenAI 的工程設計能力和他們所創造出東西十分驚艷，但這並不代表這些解決方案是不可超越的。他們的解決方案非常優雅，背後也涉及到了一系列複雜因素的考量和平衡，模型規模的擴大僅僅只是其中的一部分。 **OpenAI 最持久的護城河來自於三個方面：首先，他們擁有最多的現實世界用戶，另外是領先的工程人才，最後是他們在未來的模型開發中很可能繼續保持領先優勢。 **

不僅弄清楚GPT-4 選定某種架構的原因是很有價值，更近進一步地，我們還會概述GPT-4 在A100 上的訓練和推理成本，以及在下一代模型架構中如何使用H100 進行擴展。

從GPT-3 到GPT-4，OpenAI 想要將模型的規模擴大100 倍，這個過程最核心的自然是成本問題。稠密模型（dense transformers）是OpenAI GPT-3、Google PaLM、Meta LLaMA、TII Falcon、MosaicML MPT 等普遍使用的模型架構，目前至少有50 家使用這種架構訓練LLM 的公司，這是一個很好的架構，但它的擴展能力十分有限。

AI Brick Wall 這篇文章中曾討論過模型的訓練成本，當時GPT-4 還未發布。從訓練成本的角度來看，稠密模型（dense transformers）即將面臨自己的“AI Brick Wall”，在這篇文章中，我們也提出OpenAI 正在為GPT-4 的架構以及各種現有模型的訓練成本做出一些上層架構方面的努力。

AI Brick Wall：現階段的硬件在稠密模型（Dense Transformer）方面已經到達極限，所以不斷擴大模型規模到具有一萬億或十萬億參數的模型是不切實際的，並且成本很高。在新一代硬件之前，需要通過各種策略和技術來減少訓練成本、提升模型訓練效率從讓模型擴展到更高的參數數量。作者認為這一系列技術將在2023 年左右實現，有能力參與的公司包括OpenAI、谷歌、DeepMind、微軟和Nvidia。這些策略中有許多是在NeurIPS 會議上提出的，很可能會在AI 應用產生重大影響。

但在過去的6 個月中，我們意識到訓練成本可能是一個無關緊要的問題。雖然花費數百萬甚至上億美元來訓模型聽起來很瘋狂，但對於科技巨頭們來說其實是微不足道的。大模型是一個資本投入項目（Capex line item），而模型規模越大、結果越好，唯一的限制因素反而在於模型規模拓展的同時要人類是否有充足能力和時間來提供反饋、修改模型架構。

Meta 每年在“Metaverse”上投入160 多億美元、Google 在新項目的嘗試上要花費100 億美元左右，Amazon 在Alexa 上累計投入了500 多億美元，而加密貨幣在“沒有價值的東西”上浪費了超過1000 億美元。整個社會將花費超過1000 億來創建能夠訓練大規模模型的超級計算機，這些大規模模型可以以各種方式產品化。多個國家和公司將重複進行大模型的訓練工作**，大模型是新的“太空軍備競賽”**。與之前那些“資源浪費”相比，真正的價值將因為人類助理和Autonomous Agent 的出現在短期內實現。

但在接下來的幾年中，Google、Meta 和OpenAI、Microsoft 等多家公司將投入超過1000 億美元搭建一個超級計算機來訓練模型。

擴大模型規模更重要的問題，即真正的“AI Brick Wall”，在於推理環節。這裡的目標是將訓練算力與推理算力分離，所以對於任何將被部署的模型來說，訓練超過DeepMind 的Chinchilla-optimal 是有意義的。 （拾象注：增加訓練數據量使模型過度學習，是增加小模型能力、降低推理成本的策略。）這也是為什麼要使用稀疏模型架構（sparse model architecture）的原因，這種架構下的推理並不需要激活所有參數。

Chinchilla optimal：來源於Deepmind 的論文Training Compute-Optimal Large Language Models，表示在有一個固定的FLOPS 總數情況下，應該使用什麼樣的模型大小和數據大小來獲得最低的損失。

目前，Chinchilla-optimal 是訓練側的最優策略，而用更多的tokens 進行訓練以超越Chinchilla-optimal 的效果，是推理側的最優策略。並且由於推理成本佔“大頭”，大部分公司會選擇超過Chinchilla-optimal 的策略。

推理環節的問題本質是將模型部署到用戶和Agents 的成本太高了。推理成本比訓練成本高數倍，而解決這一問題正是OpenAI 在模型架構和基礎設施方面的目標。

在大模型推理方面，特別是稠密模型，模型大小會成為一個多變量問題。 On Device AI- Double Edged Sword 這篇文章中曾討論過邊緣計算環境下的情況。簡單來說，終端設備永遠不可能擁有滿足大語言模型實現所需的吞吐量（throughput）和足夠內存帶寬，即使帶寬足夠，邊緣設備利用硬件計算資源的效率也十分低下。數據中心面臨的問題類似。

計算資源的利用率（utilization）對於數據中心和雲（Cloud）十分重要。 （拾象注：目前業界對GPU/TPU 利用率的上限在50% 左右。）NVIDIA 的軟件之所以廣受稱讚，一個重要原因在於在持續推出新一代GPU 的過程中， NVIDIA 也在不斷更新下一代的軟件，通過在芯片周圍、芯片之間和內存之間實現更智能的數據移動，來推動FLOPS 利用率的提高。

FLOPS：浮點操作數（Floating Point Operations Per Second）的，是用來量度計算機運算速度的一個單位。 FLOPS 越高，計算機處理問題的能力就越強。 GPU 的算力主要來自它所能提供的FLOPS，GPU 提供越高的FLOPS，代表它的算力越強。

現階段， LLM 推理的用例大多是“實時助手（live assistant）”，這意味著它必須達到足夠高的吞吐量才能真正對用戶有用。拿人類做類比，人類的平均閱讀速度為每分鐘約250 字，而有些人可以達到每分鐘約1,000 字，對應到模型則意味著每秒鐘至少輸出8.33 個token、最好是每秒33.33 個token，才有可能滿足所有人類需求。

但由於內存帶寬的限制，即使是在最新NVIDA H100 GPU 服務器上，擁有萬億個參數的稠密模型（dense model）從數學層面也無法達到這個吞吐量。每生成一個token 都需要把它從內存加載到芯片上，然後這個token 又被送入，生成下一個token。此外，為實現注意力機制的KV 緩存（KV Cache）也需要額外的帶寬。

KV 緩存（KV Cache）：採樣過程中，Transformer 模型會執行自註意力操作（Self-Attention），為此需要為當前序列中的每個項目（無論是/context 還是生成的token）提取鍵值（Key-Value，KV）向量。這些向量存儲在一個矩陣中，通常被稱為KV 緩存或者過去緩存（past cache）。 KV 緩存的作用是為了避免每次採樣token 時重新計算鍵值向量。利用預先計算好的K 值和V 值，可以節省大量計算時間，儘管這會佔用一定的存儲空間。 KV 緩存在Transformer 模型中扮演著非常重要的角色，能夠幫助大幅提高模型的效率和性能。

這個圖表假設無法融合每個操作是低效率的，注意力機制所需的內存帶寬以及硬件開銷與參數讀取相當。在現實中，即使使用NVIDIA FasterTransformer 這類“優化的”庫，整體開銷會更大。

上圖展示了在足夠高的吞吐量情況下，服務於單個用戶LLM 所需的內存帶寬。從這張圖可以看出：

• 即便是8 倍於H100 的帶寬也無法實現以每秒33.33 個token 的速度為1 萬億參數規模的稠密模型提供服務；

• 此外，8x H100 的FLOPS 利用率在每秒20 個token 時仍低於5%，這會導致極高的推理成本。

實際上，對於今天的8-way 張量（tensor）並行的H100 系統來說，推理約束為約3000 億前饋參數。

然而，OpenAI 正在用A100 以及大於1 萬億參數的模型實現人類的閱讀速度，以每1000 個token 0.06 美元的低價廣泛提供，之所以能夠實現這一點正是因為它的稀疏架構。

接下來，我們會討論GPT-4 的模型架構、訓練和推理的infra、參數數量、訓練數據集構成、token 數量、層數、並行策略、多模態視覺編碼器等一系列不同工程設計背後的考量、實現技術，以及OpenAI 是如何解決大模型推理過程中的瓶頸的。

02.模型結構

GPT-4 的規模是GPT-3 的10 倍以上，我們估計它有約1.8 萬億個參數，這些參數分佈在120 個transformer 層上，作為對比，GPT-3 的參數為大約1750 億個。 （拾象注：GPT-3 僅有12 個transformer 層，層數是GPT-4 的1/10。）

為了控製成本，OpenAI 選擇使用MoE 模型。 OpenAI 在模型中使用了16 個MLP.2 類型的專家，每個專家的參數大約為1110 億個。每次前向傳遞中會調用其中的兩個專家模型。

• 專家混合模型（Mixture-of-Experts，MoE）：MoE 模型是一種深度學習架構，該架構，通常由多個專家（Experts）組成，每個專家負責處理輸入數據的不同方面，並擁有自己的參數集（也有一些參數，例如embedding，可以被所有專家共享，即共享參數）。在模型的推理過程中，根據輸入數據的不同特徵，模型會將輸入路由到不同的專家，每個專家根據其參數集處理對應分配到的輸入後完成輸出，最終輸出則是各個專家輸出的集成。

• MLP：即多層感知機(Multi-Layer Perceptron），MLP 是一種人工神經網絡，包含了多個隱藏層，MoE 模型中通常有多個獨立的MLP 專家。

有很多文獻中都在討論如何將每個待處理token 路由（assign）至某個專家模型的算法，但據說OpenAI 所採用的這一套算法卻相當簡單，至少GPT-4 是這樣的。

此外，大約有550 億個共享參數被用於注意力機制。

每次前向推理（生成一個token）僅利用了約2800 億個參數和560 TFLOP，相比之下，如果純粹使用稠密模型每次前向推理所需的約18000 億個參數和3700 TFLOP 。

03.數據集

GPT-4 是在約13 萬億個tokens 上訓練的，考慮到CommonCrawl RefinedWeb 包含有約5 萬億個高質量的tokens，13 萬億這個數字還算合理。作為參考，Deepmind 的Chinchilla 和Google 的PaLM 模型分別是用約1.4 萬億個token 和約0.78 萬億個token 訓練的，PaLM2 據說也是在約5 萬億個token 上訓練的。

CommonCrawl Refinedweb： CommonCrawl 是一項非營利項目，旨在構建和維護一個開放、可訪問的互聯網數據集，可使用網絡爬蟲技術定期掃描互聯網上的網頁，並將抓取到的網頁和相關的元數據進行整理和存檔。 CommonCrawl RefinedWeb 是CommonCrawl 通過算法和人類審查後，從原始收集的數據中篩選出高質量文本形成的資料庫。

OpenAI 訓練GPT-4 所使用的這個數據集不是13 萬億個unique tokens。相反，由於缺乏高質量的token，該數據集包含了多個epoch。基於文本的數據有2 個epoch，基於代碼的數據有4 個epoch。 （拾象注：這裡指部分高質量的文本和代碼給模型多次學習過。）這遠遠沒有實現Chinchilla-optimal（需要在雙倍的token 數上訓練模型），這也說明網絡上的易獲得token 不足。網絡上實際存在的高質量文本tokens 應該是現如今可利用的1000 倍，音頻和視頻類的token 則要更多，但採集這些tokens 並不能簡單通過網絡抓取來實現。比較遺憾的是，我們還沒有找到太多關於OpenAI 的RLHF 到數據信息。

一個epoch 指的是將整個訓練集（training set）中的所有樣本都用於訓練模型一次的過程。具體來說，一個epoch 包括多個訓練步驟（training steps），每個訓練步驟都是將一個小批量（batch）的樣本輸入模型中進行訓練，並更新模型的參數，以最小化損失函數（loss function）。

如果epoch 過小，那麼模型可能無法充分利用訓練集中的信息，導致欠擬合（underfitting），即模型無法很好地擬合訓練數據，導致在測試集上的表現不佳。相反的，如果一個epoch 過大，那麼模型可能會過擬合（overfitting），過多地學習訓練集中的噪聲和局部特徵，而忽略了全局特徵。

在預訓練階段，上下文長度（seqlen）是8k。 GPT-4 的32k 上下文版本是在預訓練後對8k 進行微調的基礎上實現的。

Batch size 在集群上經過若干天的逐步提升，但到最後，OpenAI 使用了高達6000 萬的batch size。當然，由於不是每個參數都看到所有參數，這只是每個專家的batch size 大小為750 萬。

Batch size 指的是每一次迭代(iteration) 或者前向傳遞(forward pass) 的訓練樣本數量。模型訓練中會把數據分批次來訓練，Batch size 就表示每一批次中樣本的數量。分批訓練的好處在於可以規避內存限制、節省用於重複計算中間結果的計算資源。

Batch Size 的大小對模型的訓練效果和速度有很大的影響。 Batch Size 越大，每次更新參數的計算量就越大，但是訓練過程會更加穩定，因為每個Batch 中的樣本可以平均化噪聲和不確定性。另一方面，如果Batch Size 過小，訓練過程可能會變得不穩定，並且需要更多的訓練步驟才能收斂到最優解。此外，Batch Size 的大小也會受到硬件資源的限制。因此，在實際應用中，選擇適當的Batch Size 是非常重要的。

04.並行策略

在所有A100 GPU 上進行並行處理非常重要。

OpenAI 使用了8 路（8-way）規模的張量並行（Tensor Parallelism)，之所以是8 路（8-way）是因為這是NVLink 的極限。此外，我們還聽說OpenAI 正在使用15 路（15-way）的流水線並行策略。從理論上講，考慮數據通信與計算時間，15路（15-way）顯得數量過多，但如果他們受限於內存容量，這一點也很合理。

大模型訓練中存在幾種經典的分佈式並行範式，分別為流水線並行（Pipeline Parallelism），數據並行（Data Parallelism）和張量並行（Tensor Parallesim）。微軟開源的分佈式訓練框架FastSpeed 就融合了這三種並行範式。

如果只是使用流水線並行和張量並行，每個GPU 上的參數在FP16 下大約需要30GB，而一旦考慮到KV 緩存和KV 開銷，如果OpenAI 所採用的大部分GPU 是40GB 的A100 的話，這個架構從理論上也是合理的。 OpenAI 可能使用了ZeRo stage 1、塊級FSDP 或混合共享數據並行。

• KV 開銷（KV overhead)：是指在KV 存儲系統中由於額外的開銷而產生的負擔。這些開銷可能包括存儲和管理鍵值對的元數據、索引結構、數據複製和同步、網絡通信等。 KV overhead 的增加可能導致性能下降、存儲需求增加以及系統複雜性的增加。

• ZeRo Stage 1：ZeRO（Zero Redundancy Optimizer）是指原來每張卡存儲完整的優化器狀態。若每張卡只存儲一部分優化器狀態，所有卡的優化器狀態共同構成完整的狀態，即Pos （Partition Optimizer States），被稱為ZeRO-stage1。

• Block-level FSDP：是指基於塊的全精度動態量化（Full Precision Dynamic Quantization）技術。可以在訓練和推理過程中保留更高的模型精度，使模型inference 的時候成本更低。

之所以不使用全模型FSDP 的原因可能在於過高的通信成本。雖然OpenAI 在大多數節點之間有高速網絡，但可能不是所有的節點都這樣，我們認為至少存在一些集群的連接帶寬要比其他集群低得多。

我們暫時還不清楚OpenAI 是如何在如此高的管道並行性下避免出現巨大的bubble。很可能他們只是承擔了這個成本。

Bubble: 在每個批次（batch）中由於高度的管道並行性而導致的延遲或等待時間。它表示在進行高度並行的計算過程中，由於不同部分的計算速度不同，可能會導致某些部分需要等待其他部分完成計算，從而產生延遲或空閒時間。這種情況下，"bubble" 指的是這些空閒或等待的時間間隔。這句話意味著他們可能只是接受了在計算過程中存在一些空閒時間或延遲。

05.訓練成本

OpenAI 在GPT-4 的訓練中使用了大約2.15e25 的FLOPS，在大約25,000 個A100 GPU 上進行了90 到100 天的訓練，這裡的**算力利用率約為32% 至36%。 **

這種極低的利用率部分是由於大量的故障導致需要重新啟動檢查點，上文中提到的bubble 佔據了大量成本。

另一個原因是在這麼多的GPU 之間進行all-reduce 的代價非常高。尤其是如果我們懷疑這個集群實際上是由許多較小的集群組成，並且它們之間的網絡連接相對較弱，例如在集群的不同部分之間以800G/1.6T 的非阻塞方式連接，但這些部分只能以200G/400G 的速度連接。

all-reduce 是一種並行計算中的通信操作，用於在分佈式計算中實現數據的全局歸約（global reduction）。在分佈式深度學習中，all-reduce 是一種常用的通信操作，用於在多個計算節點之間共享並聚合梯度信息，以便於在訓練過程中更新模型參數。

如果他們在Cloud 上的的成本約為每個A100 每小時1 美元，單這次訓練的成本就達到了約6300 萬美元。這還不包括所有的試驗、失敗嘗試以及數據收集、RLHF、員工等其他費用。如果考慮到這些因素，實際成本還要高得多。此外，還需要考慮到需要有一個團隊來完成芯片配置、網絡設備以及數據中心，承擔資本投入（Capex），並將它們租給你。

目前預訓練（pre-training）可以用大約8,192 個H100 在約55 天內完成，總費用為2150 萬美元，每個H100 GPU 的費用為2 美元/小時。

我們預計到今年年底會有9 家公司擁有更多的H100 GPU。可能這些H100 並不會全部用於模型訓練，但那這幾家公司一定會擁抱大模型、成為重要參與者。 Meta 到今年年底預計將擁有超過10 萬個H100，其中很大一部分會被部署到自己的數據中心用於推理，不過，他們最大的單個集群將擁有超過25,000 個H100 GPU。 （拾象注：Meta 的算力資源將使LLaMA 的能力進化成為開源和私有化部署的重要變量。）許多公司將在今年年底前訓練一個能力和GPT-4 齊平的模型。

06.教育部

MoE 是一種在推理過程中減少參數數量的有效方法，同時它還能增加參數數量，有助於每個訓練標記編碼更多信息。因為獲得足夠多的高質量token 十分困難，所以選擇MoE 架構很必要。因為如果OpenAI 真的要實現有實現Chinchilla-Optimal，他們就必須訓練兩倍於現在的token 數量。

話雖如此，OpenAI 做出了多種權衡。例如，在推理過程中處理MoE 非常困難，因為並非模型的每個部分都在生成每個token 時被使用。這意味著當其他部分被使用時，某些部分可能處於休眠狀態。在為用戶提供服務時，這會嚴重影響利用率。

研究人員證明，使用64 到128 個專家比使用16 個專家獲得更好的損失結果，但這只是研究結果。減少專家的數量有多個原因。 OpenAI 選擇16 個專家的原因之一是專家越多越難泛化，以及更難實現收斂。考慮到如此大規模的訓練運行，OpenAI 選擇在專家數量上更加保守。

此外，使用較少的專家對推理架構也有幫助。當轉向MoE 推理架構時，會有各種複雜的權衡。讓我們從基本的LLM 推理權衡開始，然後再探討OpenAI 面臨的問題以及他們所做的選擇。

07.推理

在這一部分，我們首先想指出，我們所接觸的每一家LLM 公司都認為NVIDIA 的FasterTransformer 推理庫相當糟糕，TensorRT 則更嚴重。一旦沒有能力使用Nvidia 的模板並對其進行修改，就意味著需要從頭開始創建自己的解決方案，NVIDIA 需要盡快解決這個問題，來適應LLM 推理的需求，否則事實上它將成為一個開放工具，可以更容易地添加第三方硬件支持。越來越多的大模型還在湧現，如果NVIDA 無法在推理中提供軟件優勢，而且仍然需要手動編寫內核，那麼AMD 的MI300 和其他硬件將擁有一個更大的市場。

LLM 的推理環節有3 個關鍵因素，這些因素主要和所使用的芯片數量相關。

1. 延遲（Latency）

模型必須在合理的延遲內做出響應。人們不希望在等待幾秒鐘後才開始在聊天應用程序中接收輸出。輸入和輸出token 處理時間會出現波動。

2. 吞吐量（Throughput）

模型必須每秒輸出一定數量的token。人類使用大約每秒30 個token，對於其他各種用例，吞吐量可以更低或更高。

3.利用率

運行模型的硬件必須實現高利用率，否則成本將過高。雖然可以通過更高的延遲和較低的吞吐量將更多的用戶請求進行分組，從而實現更高的利用率，但這會增加難度。

LLM 推理主要是為了平衡兩個主要因素，即內存帶寬和計算量。

簡單來說，每個參數都必須被讀取與其相關聯的是兩個FLOP 。因此，大多數芯片的比例（例如，H100 SXM 只有3TB/s 的內存帶寬，但有2,000 TFLOP/s FP8）在batch-size 為1 的推理中完全不平衡。如果只為一個用戶提供服務，即批量大小為1，則為了每次token 生成而流式傳輸每個參數所需的內存帶寬會佔據推理時間的主導地位，計算時間幾乎可以忽略不計。

為了能夠將大模型擴展到多個用戶，批量大小必須大於1，多個用戶分攤參數讀取成本。例如，在批量大小為256 或512 時，每個讀入的內存字節對應512 FLOP/s 或1024 FLOP/s。這個比例更接近H100 的內存帶寬與FLOPS 之間的比值。有助於實現更高的利用率，但缺點是延遲更高。

很多人認為內存容量是LLM 推理的主要瓶頸，因為模型的大小可能適合多個芯片，但這個觀點可能存在問題。雖然大模型的推理需要多個芯片，並且較高的內存容量導致更少的適配芯片，但實際上更好的做法是使用超過所需容量的芯片，以便將延遲降低，增加吞吐量，並且可以使用更大的批量規模，以不斷提高利用率。

Google 在PaLM 推理論文中也提到了對上述三個問題的處理。值得注意的是，**這是針對PaLM 類的稠密模型，而不是GPT4 這類的稀疏模型。 **

如果一個應用程序需要盡可能低的延遲，我們需要更多的芯片，並以盡可能多的方式對模型進行分割，這樣才能有經濟效益。較小的批處理量可以實現較低的延遲，但較小的批處理量也會導致較差的MFU [利用率]，導致每個token 的總成本（以芯片秒數或美元計算）較高。

如果一個應用需要離線推理，並且延遲不是問題，那麼主要目標是最大限度地提高每個芯片的吞吐量（即最小化每個token 的總成本）。增加批處理量是最有效的，因為較大的批處理量通常會帶來更好的MFU [利用率]，但是某些對小批處理量無效的分區策略會隨著批次處理量的增長而變得有效。

**更多的芯片和更大的批次量反而是更便宜的，因為它們提高了利用率，但這也引入了第三個變量，即聯網時間（Networking Time）。 **把模型部署在多個芯片上的方法可以有效解決延遲，但要對利用率做出犧牲。

存儲時間的權重加載部分和非注意計算時間都與模型大小成正比，與芯片數量成反比。對於一個給定的分區佈局，芯片與芯片之間的通信所需時間隨著所用芯片數量的增加而減少得不那麼快（或根本不減少）， 所以隨著芯片數量的增加，它成為一個越來越重要的瓶頸。

我們注意到，隨著批處理量和規模的增長，KV 緩存的內存需求量會激增。

如果一個應用程序需要生成具有長注意力上下文（long attention contexts）的文本，就會大大增加推理時間。對於一個具有多頭注意力500B 以上的模型，注意力的KV 緩存會變得很大：對於批量大小為512、上下文長度為2048 的模型，KV 緩存的總量為3TB， 是模型參數大小的3 倍。片上存儲器（on-chip memory）需要從片外存儲器（off-chip memory）中加載這個KV 緩存，每產生一個token 就加載一次，在此期間芯片的計算核心基本上是空閒的。

較長的序列長度對內存帶寬和內存容量來說特別麻煩。 OpenAI 16k 上下文的GPT-3.5 turbo 和32k 上下文的GPT-4 很貴的原因是由於內存的限制，它們不能採用更大的批次。

較小的批次導致較低的硬件利用率。此外，隨著序列長度的增加，KV 緩存會膨脹。 KV 緩存不能在用戶之間共享，所以需要單獨的內存讀取，這進一步降低了內存帶寬。關於MQA 的更多信息，請見下文。

08.推理的Infra 與成本

基礎設施

MoE 的架構則讓GPT-4 的推理在延遲、吞吐量和利用率上都面臨挑戰。因為每個token 的前向傳遞可以路由到不同的專家模型，這種情況下要盡可能實現低延遲、高吞吐量和高利用率就十分困難，尤其是在高batch-size 的情況下。

OpenAI 的GPT-4 架構中包含了16 個專家模型，每個前向通道有2 個路由（router）。這意味著在batch-size 為8 的情況下，每個專家的參數讀取可能只佔批量大小的“1”。更嚴重的是，這還會導致某個專家的batch-size 為8，而其他專家的batch-size 可能只有4、1 或0。

此外，每一次 token 生成，路由算法都会将前向传递路由到不同的方向，这会导致 token 到 token 之间的延迟和专家批处理量的显著变化。也就是说，处理不同的 token 时，不同的专家可能会被分配到不同的任务，计算负载和批量大小都可能因此发生变化。

推理infra 是OpenAI 在MoE 的設計上選擇較少數量專家的主要考量之一。如果他們使用更多的專家，內存帶寬將成為推理面臨的一個更大瓶頸。 OpenAI 在自己的推理集群上常常能達到4k 以上的batch-size，這意味著即使在專家之間實現了最佳負載平衡，每個專家的批處理量也只能達到大約500 個。這需要非常大的使用量才能實現。

我們的理解是，OpenAI 在由128 個GPU 組成的集群上運行推理，並且在不同的數據中心和地理區域擁有多個這樣的集群。推理是以8 路張量（tensor）並行和16 路流水線並行的方式進行的。每個節點使用8 個GPU，每個GPU 只有大約130B 的參數，或者在FP16 下每個GPU 不到30GB，在FP8/int8 下不到15GB。只要所有批次的KV 緩存大小不會膨脹得太大，這就可以在40GB 的A100 上運行推理。

FP16、FP8 和int8 是不同的數值精度（precision）表示方式，常用於深度學習中的計算過程中，以減少內存和計算資源的使用，從而提高模型訓練和推理的效率。

FP16 、FP8、int8 分別指的是16 位浮點數、8 位浮點數和8 位整數，它們的精度相對於32 位的單精度浮點數（FP32）更低，但可以大大減少內存和計算資源的使用，從而加速深度學習中的模型訓練和推理。例如，使用FP16 可以在不損失太多精度的情況下，將計算時間減少一半以上，而使用int8 可以在不損失太多精度的情況下，將計算時間減少約4 倍。

需要注意的是，使用低精度計算可能會對模型精度產生一定的影響，因此需要在精度和效率之間進行權衡，並根據具體的任務需求選擇最合適的精度表示方式。

為了避免網絡通信過於不規則，同時避免在每個token 生成之間重新計算KV 緩存的成本過高，包含各種專家的各個層並沒有在不同的節點上進行分解，以便共享KV 緩存。

**未來所有的MoE 模型擴展和條件路由的最大困難。在於如何處理KV 緩存周圍路由層數最大為120 的限制。 **

在MoE 模型中，每個分支的路由層數不能超過120 層，否則將無法有效地處理KV 緩存。這是因為在模型的推理過程中，每個分支都需要計算KV 緩存，這會導致計算成本的增加。

解決這個問題的一個簡單方案是，基於120 的層數限制，在15 個不同的節點中放置一個橫跨路由。這樣就可以將計算負載平均分佈在不同的節點上，從而提高模型的效率和性能。然而，由於第一個節點需要進行數據加載和嵌入，因此如何在推理集群的頭部節點上放置更少的層是很重要的。

另外，在對輸入數據進行編碼和解碼的過程中，可能會存在一些關於推理解碼的噪音，這個問題我們將在後面進一步討論。較為關鍵的問題在於確定這些噪音是否應該被相信。這也可以解釋為什麼頭部節點上包含較少的層是有意義的。

推理成本

相較於175B 參數的Davinchi 模型，GPT-4 有1.6 倍的前饋參數，但成本卻是Davinchi 的3 倍。這主要是因為GPT-4 需要更大的集群，以及實現利用率更低。

我們猜測使用128 個A100s 進行GPT-4 8k 上下文長度（seqlen）的推理，每1k tokens 的成本約為0.0049 美元。而使用128 個H100s 進行GPT-4 8k 上下文的推理，每1k tokens 的成本約為0.0021 美元。 (拾象注：當前GPT-4-8k 的價格是0.03/1k input tokens, 0.06/1k output tokens，當前OpenAI 對推理芯片使用不會如作者推測的一樣奢侈，該測算可以作為未來降價的lower bound。) 需要特別注意的是，**這些成本的計算是在利用率和batch-size 都很高的情況下得出的。 **

考慮到OpenAI 集群的利用率有時可能會非常低，我們的這一假設也有可能是錯的。

我們假設，OpenAI 在低谷時期會關閉集群，並重新利用將這些節點重新分配給其他任務，例如恢復小型測試模型的檢查點訓練，或嘗試各種新技術。這樣的做法有助於保持低推理成本，否則OpenAI 的利用率可能會更低，這意味著成本估算會是現在的2 倍以上。

恢復小型測試模型的檢查點訓練，通常是指在訓練深度學習模型時，使用之前保存的模型參數檢查點，重新開始訓練一個較小的模型（例如，一個僅使用模型的一部分參數的子集），以便在較短的時間內快速測試新的模型結構或算法。這種方法可以幫助研究人員快速迭代模型設計，並尋找最佳的模型結構和參數。

09.多查詢注意力機制

多查询注意力机制（Multi-Query Attention）的使用已经相当普遍，但我们想强调的是 OpenAI 也是这么做的。总的来说就是只需要 1 个注意力头（head），内存容量就能够显著减少以用于 KV 缓存。即便如此，32k 上下文的 GPT-4 肯定无法在 40GB 的 A100 上运行， 而 8k 的最大批量大小已经达到上限。如果没有 MQA，8k 的最大批处理量将被大大限制，经济效益大打折扣。

• 多查詢注意力機制（Multi-Query Attention，MQA）：Fast Transformer Decoding: One Write-Head is All You Need 這篇論文於2019 年提出了MQA 這一概念，後來成為了自然語言處理中經常使用的注意力機制。

傳統的注意力機制中，將一個查詢（query）和一組鍵值對進行匹配，以獲得對每個鍵的加權表示。而在多查詢注意力中，有多個查詢，並且每個查詢都會與鍵值對進行匹配，以獲得對每個鍵的不同加權表示。這個過程可以看作是在多個不同的“視角”下對輸入進行編碼，從而獲得更全面和準確的表示。

• 注意力頭（Head）：在深度學習模型中，通常包含多個層（layers）和一個頭（head），head 用於將模型的輸出映射到期望的輸出空間。頭部層通常是為了滿足特定的任務而添加到模型中的，例如在自然語言處理任務中，head 通常用於將模型的輸出轉換為文本，進行文本分類等任務。在深度學習模型中，head 通常是緊跟在最後一個層的後面，用於將最後一層的輸出轉換成期望的輸出形式。

10.連續批處理

為了允許一定程度的最大延遲和優化推理成本，OpenAI 同時使用了可變批次大小和連續批次的技術。這種方法可以在不犧牲模型性能的情況下提高計算資源的利用率，並在模型的推理過程中實現更低的延遲和更高的吞吐量。如果不了解連續批處理這一概念的話，AnyScale 官方發布的How continuous batching enables 23x throughput in LLM inference while reducing p50 latency 這篇文章非常值得一讀。 （拾象注：Anyscale 開發的分佈式計算框架Ray 是OpenAI 在模型的infra pipeline 中使用的，拾象之前發布過對這家公司的研究。）

連續批處理（Continuous batching）：一種在深度學習訓練過程中使用的技術，旨在提高訓練效率和通過硬件的資源利用率。傳統的批處理方法是將一定數量的訓練數據一次性加載到內存中，然後對這些數據進行訓練，這種方式可以提高訓練效率，但也可能會浪費內存空間。

而連續批處理則是將訓練數據分成若干個小批次，每次只加載一個小批次進行訓練，訓練完成後再加載下一個小批次，以此類推，直到完成整個訓練數據集的訓練過程。使用連續批處理技術可以在減少內存使用的同時提高訓練效率，還可以提高模型的穩定性和泛化能力。

來源：Anyscale

11.推測解碼

有傳言說，OpenAI 在GPT-4 模型的推理任務中使用了推測解碼（Speculative Decoding）技術。儘管我們不能確定這一消息的準確性，但是在進行簡單的檢索任務和更複雜的任務時，從一個token 到另一個token 的延遲和差異的一般變化似乎表明這種技術是可能存在的。然而，由於存在太多變量，我們無法確認這一技術是否確實被使用。

為了避免內容上的爭議，這裡引用Accelerating LLM Infeferencewith Staged Speculative Decoding 中的一些內容，並在重點內容上加粗。

使用LLMs 一般分為兩個階段：

1. 預填充（prefill）階段

在這個階段中，首先需要給定一個提示（）作為輸入，並通過模型運行來生成KV 緩存和第一個輸出logits。其中，logits 是LLM 在每個時間步長輸出的概率分佈向量，用於表示每個token 的可能性。這個預填充階段通常是很快的，因為並行計算。

2. 解碼（decoding）階段

在這個階段中，從輸出的logits 中選擇一個token 並反饋到模型中，為下一個token 產生logits。這樣反復進行，直到產生所需數量的tokens。由於每次解碼都必須按順序進行計算以產生一個token，所以在小批量運行時，這個第二階段的算術強度（即計算的FLOP/內存帶寬的字節）非常低（拾象注：序列計算導致算力無法被充分利用。）因此，解碼通常是自回歸生成中最昂貴的部分。

這就是為什麼在OpenAI 的API 調用中，輸入token 要比輸出token 便宜很多的原因。

推測解碼的核心思想是使用一個較小、較快的draft 模型提前解碼幾個token，並將它們作為一個批次送入oracle 模型。如果draft 模型的預測是正確的（即與oracle 模型的預測一致），就可以使用一個批次來解碼幾個token，從而為每個token 節省大量的內存帶寬和時間。

Oracle 模型是指在推測解碼方法中使用的一個較大、較慢的LLM 模型，用於驗證draft 模型的預測結果。 Oracle 模型會根據draft 模型的預測結果和之前生成的token 來計算出下一個token 的概率分佈，然後將這個概率分佈作為輸出返回給draft 模型。

通過使用Oracle 模型來驗證draft 模型的預測結果，可以避免draft 模型在後續解碼過程中產生誤差和偏差，從而提高模型的準確度和穩定性。同時，Oracle 模型也可以幫助draft 模型更好地學習和理解語言模型中的上下文信息，從而提高模型的生成能力和效果。

然而，如果較大的模型拒絕了draft 模型所預測的token，那麼其餘的批次就會被丟棄，算法會恢復到標準逐token 解碼的方式。推測解碼也可以結合拒絕採樣方案，從原始分佈中去採樣token。需要注意的是，這種方法只能在帶寬為瓶頸的小批量設置中發揮作用。

簡而言之，推測解碼以計算量換取帶寬，有兩個關鍵原因可以說明為什麼它是一個有吸引力的性能優化目標。首先，推測解碼完全不會降低模型質量，因為它只是通過修改解碼階段的計算流程來提高模型的推理速度和吞吐量。第二，它所提供的收益與其他方法通常是獨立的，因為它的優勢在於將順序執行的計算轉換為並行執行，而其他方法則主要從模型結構、參數、訓練等方面入手進行優化。

目前的推測方法是針對每個批次預測一個單一序列。然而**這種方法在大批次或低精度draft 模型的情況下無法很好地擴展。 **直觀來說，對於長連續token 序列，兩個模型預測一致的概率呈指數級下降，這意味著隨著算法強度的擴大，推測解碼的回報會迅速減少。

我們認為，如果OpenAI 正在使用推測解碼，他們很可能只將其用於長度約為4 個token 的短序列。此外，還有人認為GPT-4 模型性能的下降是因為OpenAI 在模型預訓練中加入了來自推測解碼模型的低概率的序列，這種猜測可能不是真實的。

也一有些人認為Bard 模型也使用了推測解碼，因為谷歌在向用戶發送完整序列之前會等待完整序列的產生，但我們並不認為這種猜測是真實的。

12.視覺多模態

視覺多模態技術（Vision Multi-Modal）在GPT-4 中可能是最不引人注目的部分，至少與其他研究相比。到目前為止，還沒有人進行關於多模態LLM 研究商業化的探索。

視覺多模態（Vision Multi-Modal）：它是指將來自不同模態（如圖像、文本、語音等）的信息進行聯合處理和分析的技術。通常，這些不同模態的信息在語義上是相關聯的，因此將它們結合起來可以提供更豐富的信息和更準確的推理結果。

GPT-4 的視覺多模態能力是通過一個獨立於文本編碼器的視覺編碼器來實現的，並且與文本編碼器有交叉注意力機制（Cross-Attention），據說它的架構與Flamingo 模型相似。這個視覺編碼器是在1.8 萬億參數的GPT-4 模型中微調的，但是，它只是使用了額外的約2 萬億token 的文本數據進行預訓練，而沒有使用視覺數據進行預訓練。

交叉注意力機制（Cross-Attention）：是一種在多個序列數據之間建立關聯的機制，它在自然語言處理和計算機視覺等領域得到了廣泛應用。在序列到序列的任務中，如機器翻譯和文本摘要，交叉注意力機制用於計算源序列和目標序列之間的相關性，以便在生成目標序列時使用源序列中的信息。

在計算機視覺任務中，交叉注意力機制用於將圖像和文本之間建立聯繫，以便在圖像描述生成和視覺問答等任務中使用。

OpenAI 計劃在視覺模型方面從頭訓進行練，但該技術尚不夠成熟，因此他們希望通過從文本開始訓練來降低風險。

**有傳言說，OpenAI 的GPT-5 將從頭開始訓練視覺模型，並且具有自動生成圖像和音頻處理的能力。 **

視覺多模態技術的一個主要目的是讓自主代理能夠閱讀網頁並轉錄其中的圖像和視頻內容。 OpenAI 訓練這個模型的數據包括聯合數據（包括渲染的LaTeX/文本）、網頁截圖和Youtube 視頻採樣幀等，並使用Whisper 技術來進行轉錄。

關於LLM 過度優化的問題，一個有趣的事情是，視覺模型的IO 成本與純文本模型的IO 成本不同。文本模型的IO 成本十分低廉，但在視覺模型中，數據加載的IO 成本約為文本模型的150 倍。每個token 的大小為600 個字節，而文本模型只有4 個字節。目前，有很多工作正在進行圖像壓縮方面的研究。 （拾象注：文字的信息更容易壓縮，圖片/視頻的tokenization 是多模態領域值得重點關注的方向。）

IO 成本：IO 成本是指在計算機系統中完成輸入/輸出操作所需的時間、資源和能源成本。這些成本包括數據傳輸、存儲和處理等方面。在機器學習和深度學習領域中，IO 成本通常是指從存儲介質（如硬盤、內存、網絡等）中讀取和寫入數據的成本。在模型訓練和推斷過程中，IO 成本可能會成為瓶頸，影響系統的性能和效率。因此，為了提高計算機系統的性能和效率，需要考慮和優化IO 成本。

這對於那些在2-3 年後優化硬件的供應商來說非常重要，他們需要考慮到每個模型都具備強大的視覺和音頻能力的情況。他們可能會發現他們架構的適應性很差。總而言之，未來的LLM 架構肯定會發展到超過我們今天看到的基於文本的簡化稠密型和/或MoE 模型。

參考