ChatGPT背後的經濟賬

語言: CN / TW / HK

影象2023-2-7 09.52.jpeg

ChatGPT能否取代Google、百度這樣的傳統搜尋引擎?為什麼中國不能很快做出ChatGPT?當前,對這些問題的探討大多囿於大型語言模型(LLM)的技術可行性,忽略或者非常粗糙地估計了實現這些目標背後的經濟成本,從而造成對LLM的開發和應用偏離實際的誤判。

本文作者從經濟學切入,詳細推導了類ChatGPT模型搜尋的成本、訓練GPT-3以及繪製LLM成本軌跡的通用框架,為探討LLM成本結構和其未來發展提供了可貴的參考視角。

作者|Sunyan

翻譯|楊婷、徐佳渝、賈川

重點概覽:

  • LLM驅動的搜尋已經在經濟上可行:粗略估計,在現有搜尋成本結構的基礎上,高效能LLM驅動搜尋的成本約佔當下預估廣告收入/查詢的15%。
  • 但經濟可行並不意味著經濟合理:LLM驅動搜尋的單位經濟性是有利可圖的,但對於擁有超1000億美元搜尋收入的現有搜尋引擎來說,新增此功能可能意味著超100億美元的額外成本。
  • 其他新興的LLM驅動業務利潤很高:比如Jasper.ai使用LLM生成文案,很可能有SaaS服務那樣的毛利率(超75%)。
  • 對於大公司而言,訓練LLM(即使是從頭開始)的成本並不高:如今,在公有云中訓練GPT-3僅需花費約140萬美元,即使是像PaLM這樣最先進的模型也只需花費約1120萬美元。
  • LLM的成本可能會顯著下降:自GPT-3釋出的兩年半時間裡,與GPT-3效能相當的模型的訓練和推理成本下降了約80%。
  • 資料是LLM效能的新瓶頸:與增加高質量訓練資料集的大小相比,增加模型引數的數量能獲得的邊際收益越來越小。

1、動機

LLM的驚人表現引發了人們的廣泛猜想,這些猜想主要包括LLM可能引發的新興商業模式和對現有模式的影響。

搜尋是一個有趣的機會,2021年,僅谷歌就從搜尋相關的廣告中獲得了超1000億美元的收入[1]。ChatGPT(一個使用LLM的聊天機器人,它可以生成高質量的答案,以回答類似於搜尋的查詢)的“病毒性”傳播已經引發了許多關於搜尋領域潛在影響的思考,其中一個就是LLM如今的經濟可行性:

  • 一位聲稱是谷歌員工的人在HackerNews上表示,要想實施由LLM驅動的搜尋,需要先將其成本降低10倍。
  • 與此同時,微軟預計將在3月份推出LLM版本的Bing[3],而搜尋初創公司如You.com已經將該技術嵌入到了他們的產品之中[4]。
  • 最近,《紐約時報》報道,谷歌將在今年推出帶有聊天機器人功能的搜尋引擎[5]。

更廣泛的問題是:將LLM納入當前產品和新產品的經濟可行性如何? 在本文中,我們梳理了當今LLM的成本結構,並分析其未來可能的發展趨勢。

2、重溫LLM工作原理

儘管後續章節的技術性更強,但這篇文章對機器學習熟悉程度不做要求,即使不熟悉這方面內容的人也可以放心閱讀。為了說明LLM的特殊之處,現做一個簡要複習。

語言模型在給定上下文的情況下,對可能輸出的token作出預測:

自迴歸語言模型(Autoregressive Language Model)輸入上下文和輸出內容的圖示(在實踐中,token通常是子詞:即“happy”可能被分解為兩個token,例如“hap”、“-py”)

為了生成文字,語言模型根據輸出token的概率重複取樣新token。例如,在像ChatGPT這樣的服務中,模型從一個初始prompt開始,該prompt將使用者的查詢作為上下文,並生成token來構建響應(response)。新token生成後,會被附加到上下文視窗以提示下一次迭代。

語言模型已經存在了幾十年。當下LLM效能的背後是數十億引數的高效深度神經網路(DNN)驅動。引數是用於訓練和預測的矩陣權重,浮點運算(FLOPS)的數值通常與引數數量(parameter count)成比例。這些運算是在針對矩陣運算優化的處理器上計算的,例如GPU、TPU和其他專用晶片。

隨著LLM引數量呈指數增長,這些操作需要更多的計算資源,這是導致LLM成本增加的潛在原因。

3、LLM驅動搜尋的成本

本節,我們將估算執行LLM驅動搜尋引擎的成本。應該如何實施這樣的搜尋引擎仍是一個活躍的研究領域,我們這裡主要考慮兩種方法來評估提供此類服務的成本範圍:

  • ChatGPT Equivalent:一個在龐大訓練資料集上訓練的LLM,它會將訓練期間的知識儲存到模型引數中。在推理過程中(使用模型生成輸出),LLM無法訪問外部知識[6]。
  • 這種方法有如下兩大缺點: - 容易“幻想”事實。 - 模型知識滯後,僅包含最後訓練日期之前的可用資訊。
  • 2-Stage Search Summarizer:一種架構上類似的LLM,可以在推理時訪問Google或Bing等傳統搜尋引擎。在這種方法的第一階段,我們通過搜尋引擎執行查詢以檢索前K個結果。在第二階段,通過LLM執行每個結果以生成K個響應,該模型再將得分最高的響應返回給使用者[7]。
  • 相比ChatGPT Equivalent,這種方法的優點是:
    • 能夠從檢索到的搜尋結果中引用其來源。
      • 能獲取最新資訊。

然而,對於相同引數數量的LLM,這種方法需要更高的計算成本。使用這種方法的成本也增加了搜尋引擎的現有成本,因為我們在現有搜尋引擎的結果上增加了LLM。

一階近似:基礎模型API

最直接的成本估算方法是參考市場上現有基礎模型API的標價,這些服務的定價包括成本的溢價部分,這部分是供應商的利潤來源。一個代表性的服務是OpenAI,它提供基於LLM的文字生成服務。

OpenAI的Davinci API由GPT-3的1750億引數版本提供支援,與支援ChatGPT的GPT-3.5模型具有相同的引數數量[8] 。現在用該模型進行推理的價格約為0.02美元/750個單詞(0.02美元/1000個token,其中1000token約等於750個單詞);用於計算定價的單詞總數包括輸入和輸出[9]。

按模型功能劃分的基礎模型API定價 (OpenAI)

我們這裡做了一些簡單假設來估計將支付給OpenAI的搜尋服務費用:

  • 在ChatGPT equivalent的實現中,我們假設該服務平均針對50字的prompt生成400字的響應。為了產生更高質量的結果,我們還假設模型對每個查詢取樣5個響應,從中選擇最佳響應。因此:

在2-Stage Search Summarizer的實現中,響應生成過程是相似的。然而:

  • 提示明顯更長,因為它同時包含查詢和搜尋結果中的相關部分
  • 為每K個搜尋結果生成一個單獨的LLM響應
  • 假設K = 10並且搜尋結果中的每個相關部分平均為1000個單詞:

假設優化的快取命中率為30%(谷歌歷史搜尋快取命中率的下限[10])和OpenAI雲服務的毛利率為75%(與典型的SaaS服務一致),我們的一階估計意味著:

按照數量級,ChatGPT Equivalent服務的預計雲端計算成本為0.010美元/次,與公眾評論一致:

OpenAI執行長Sam Altman談ChatGPT每次聊天的成本([推特](http://twitter.com/sama/status/1599671496636780546?lang=en)

鑑於ChatGPT Equivalent的上述缺點(即幻想事實、模型資訊陳舊),在實際操作中,LLM驅動搜尋引擎的開發者更可能部署2-Stage Search Summarizer變體。

2012年,谷歌搜尋主管表示,其搜尋引擎每月處理的搜尋次數達1000億次[11]。世界銀行資料顯示:全球網際網路普及率已從2012年的34%上升到了2020年的60%[12]。假設搜尋量按比例增長,則預計其年均搜尋量將達2.1萬億次,與搜尋相關的收入將達約1000億美元[13],平均每次搜尋的收入為0.048美元。

換句話說,2-Stage Search Summarizer的查詢成本為0.066美元/次,約為每次查詢收入0.048美元的1.4倍。

  • 通過以下優化,預估成本大約會降至原來的1/4:1、量化(使用較低精度的資料型別) 2、知識蒸餾(通過學習較大的模型去訓練一個較小的模型) 3、訓練更小的“計算優化”模型,該模型具有相同的效能(稍後將對此展開更詳細的討論)
  • 假設雲端計算的毛利率約為50%,與依賴雲服務提供商相比,執行自建(內部)基礎設施(infrastructure in-house)會使成本降低至當前的1/2。

綜合以上改進,降低至原有成本的1/8之後,在搜尋中融入高效能LLM的成本大約佔據當前查詢收入的15%(現有的基礎設施成本除外)。(注:成本最低可降至 0.066 美元/次 * 1/4 * 1/2, 約定於0.008美元,因此大約佔每次查詢收入 0.048 美元的 15%)

深度解析:雲端計算成本

如今,SOTA大型語言模型通常會用到可比較的模型架構(最常見的是僅包含解碼器的Transformer模型),在推理過程中每個token的計算成本(以FLOPs為指標)約為2N,其中N為模型引數數量(model parameter count)[14]。

目前,NVIDIA A100是AWS最具成本效益的GPU選擇,若預定1年使用該GPU,擁有8個A100的AWS P4例項的有效時薪(effective hourly rate)將達19.22美元。[15]每個A100提供峰值312 TFLOPS(萬億次浮點數/秒)FP16/FP32 混合精度吞吐量,這是LLM訓練和推理的關鍵指標[16]。FP16/FP32混合精度是指以16位格式(FP16)執行操作,而以32位格式(FP32)儲存資訊。由於FP16的開銷較低,混合精度不僅支援更高的FLOPS吞吐量,而且保持精確結果所需的數值穩定性也會保持不變[17]。

假設模型的FLOPS利用率為21.3%,與訓練期間的GPT-3保持一致(雖然最近越來越多的模型效率得以提升,但其FLOPS利用率對於低延遲推理而言仍充滿挑戰)[18]。因此,對於像GPT-3這樣擁有1750億引數的模型:

我們也應用了基於GCP TPU v4定價( GCP TPU v4 pricing)相同的計算方法,並得到了相似的結果[19]:

預估GPT-3通過雲服務提供商 (AWS, GCP)每處理1000個token所需的推理成本

OpenAI的API定價為0.02美元/1000詞,但我們估計其成本約為0.0035美元/1000詞,佔定價的20%左右。這就意味著:對於一臺一直執行的機器而言,其毛利率約為80%。 這一估算與我們之前設想的75%毛利率大致相同,進而為ChatGPT Equivalent和2-Stage Search Summarizer搜尋成本估算提供了合理性驗證(sanity check)。

4、訓練成本如何?

另一個熱門話題是GPT-3(擁有1750億引數)或最新的LLM(如擁有2800億引數的Gopher和擁有5400億引數的PaLM)的訓練成本。基於引數數量和token數量,我們構建了一個用於估算計算成本的框架,雖然稍作修改,但同樣適用於此:

  • 每個token的訓練成本通常約為6N(而推理成本約為2N),其中N是LLM的引數數量[20]
  • 假設在訓練過程中,模型的FLOPS利用率為46.2% (而在之前的推理過程中,模型的FLOPS利用率約為21.3%),與在TPU v4晶片上進行訓練的PaLM模型(擁有5400億引數)一致[21]。

1750億引數模型的GPT-3是在3000億token上進行訓練的。谷歌使用了GCP TPU v4晶片來訓練PaLM模型,若我們現在也像谷歌那樣做,那麼如今的訓練成本僅為140萬美元左右。

此外,我們還將該框架應用到一些更大的LLM模型中,以瞭解其訓練成本。

預估LLM在GCP TPU v4晶片上的訓練成本

5、繪製成本軌跡的通用框架

為了推導LLM的推理成本/訓練成本,我們總結了如下框架:

密集啟用純解碼器LLM模型Transformer(Densely Activated Decoder-Only Transformer LLMs)的推理成本和訓練成本(其中“N”是模型引數數量,“processor”是指TPU、GPU或其他張量處理加速器)

因此,我們假設LLM的架構相似,那麼推理成本和訓練成本將根據上述變數的變化而變化。雖然我們會詳細考慮每個變數,但是以下部分才是關鍵點:

自2020年GPT-3釋出以來,使用與GPT-3一樣強大的模型進行訓練和推理的成本大大降低,低於先前的五分之一。

相比2020年推出的GPT-3,與其效能對等的模型的推理與訓練成本降低情況總結

引數數量效率:巨型語言模型引數每年增長10倍的神話

考慮到過去5年中模型引數呈指數增長,我們普遍猜測:下一代LLM模型很可能是萬億引數(密集啟用)模型:

LLM中模型引數數量的增長

雖然LLM的引數數量每年約增長10倍,但是大多數模型訓練資料集的大小並沒有顯著變化:

所選LLM的模型引數數量與訓練token數量 (訓練計算最優大語言模型)

然而,最新文獻表明,假設計算資源和硬體利用率(即訓練“計算最優”模型)保持不變,關注擴充套件引數數量(scaling parameter count)並不是效能最大化的最佳方式:

Google DeepMind的研究人員將一個引數函式(parametric function)擬合到他們的實驗結果中,發現引數數量N的增速應與訓練token數量D的增長速度大致相同,從而讓模型損失L實現最小化(即效能最大化):

模型損失的引數函式 (訓練計算最優大語言模型)

研究人員還訓練了一個名為Chinchilla的模型(擁有700億的引數)。雖然該模型的計算資源與Gopher(擁有2800億引數)相同,但是該模型是在1.4萬億token上進行訓練的而非3000億token。Chinchilla的效能明顯優於擁有相同FLOPs預算的大型模型,從而證明了大多數LLM過度支出了計算量和對資料的渴望 (譯者注:換言之,對大多數LLM來說,使用更多的資料來訓練比增大模型引數量要更加划算)。

通過訓練資料大小與模型引數來預測模型損失(錯誤更少:Chinchilla的自然環境含義)

雖然Chinchilla的引數(以及推理計算需求)比GPT-3少60%,但是其效能遠遠優於擁有1750億引數的GPT-3模型。

實際上,即使我們用與GPT-3相同的3000億token資料集去訓練一個萬億引數模型,仍可以預見該模型的表現不如Chinchilla:

萬億引數模型相應損失項的相對量級(0.03的模型引數損失與0.25的訓練token損失)也表明,通過增加模型大小獲得的邊際效益低於增加資料量獲得的邊際效益。

展望未來,我們不會繼續擴大模型引數數量,而是將增量計算資源(incremental computational resources)轉移到質量相當的更大資料集上進行訓練,以獲得極佳的效能。

Cost/FLOP效率

對於訓練LLM而言,最重要的硬體效能指標(hardware performance metric)是可實現的混合精度FP16/FP32 FLOPS。改進硬體旨在實現成本最小化,同時使得峰值FLOPS吞吐量和模型FLOPS利用率實現最大化。

雖然這兩個部分在硬體開發中密不可分,但為了讓分析變得更簡單,本節重點關注吞吐量,下一節再討論利用率。

目前,我們已經通過檢視雲實例定價(cloud instance pricing)估算了Cost/FLOP效率。為了進行下一步探究,我們估算了執行以下機器的成本。主要包括以下兩個方面:1)硬體購買(hardware purchase) 2)能源支出(energy expense)。為說明這一點,我們再來看看GPT-3(一款由OpenAI推出的模型,該模型在Microsoft Azure的10000個V100 GPU上訓練了14.8天)[22]:

2020年用英偉達V100 GPU訓練GPT-3的成本(碳排放與大型神經網路訓練)

黃仁勳定律(英偉達執行長黃仁勳於2018年提出)指出,在硬體成本方面,GPU的增長速度比五年前快了25倍[23]。在訓練LLM的背景下,GPU的效能得到了很大提升,這很大程度上得益於張量核心(Tensor Cores)(AMD採用的是矩陣核心(matrix cores))。此外,GPU不再將向量作為計算原語,而是轉為矩陣,從而實現了效能更好、效率更高的混合精度計算。

2016年,NVIDIA通過V100資料中心GPU首次推出了張量核心。與最初引入的張量核心相比,雖然這一改進不太明顯,但是每一代張量核心都進一步提高了吞吐量。如今,對於用於訓練LLM的資料中心GPU,我們仍能看到每一代GPU的吞吐量都提升了50%(或者說年均吞吐量提升了22%左右)。

資料中心GPU FP16/FP32吞吐量/美元 (NVIDIA)

桌面GPU和資料中心GPU、按精度劃分的吞吐量/美元 (英偉達,深度學習推理中的計算和能源消耗趨勢)

能源效率提升得更快。現在我們可以看到,用於訓練LLM的資料中心GPU的代際吞吐量/瓦特提高了80%(或者說年均吞吐量提高了34%):

資料中心 GPU FP16/FP32 吞吐量/瓦特 (英偉達)

按精度劃分的桌面和資料中心GPU吞吐量/瓦特(英偉達,深度學習推理中的計算和能耗趨勢)

僅從V100(用於訓練 GPT-3)到即將推出的H100的改進來看,我們預計內部訓練成本將降低58%(即訓練成本由74.4萬美元降低到31.2萬美元)。

目前使用英偉達H100 GPU訓練GPT-3的成本

展望未來,我們預測,隨著硬體設計的不斷創新,硬體成本和能效將逐步改進。 例如,從V100到A100 GPU,NVIDIA添加了稀疏特性(sparsity features),這進一步將某些深度學習架構的吞吐量提高了2倍[24] 。NVIDIA正在H100中新增對FP8資料型別的本地支援,當與推理量化等現有技術相結合時,可以進一步提高吞吐量[25]。

此外,TPU和其他專用晶片的出現從根本上重塑了深度學習用例的晶片架構。谷歌的TPU建立在脈動陣列結構(systolic array architecture)之上,可顯著減少暫存器使用,提高吞吐量[26]。正如下一節將提到的,隨著我們將訓練和推理擴充套件到大型引數模型,最近許多硬體都著力於提高利用率。

硬體利用率提升

出於記憶體需求,LLM訓練的主要挑戰之一就是將這些模型從單個晶片擴充套件到多個系統和叢集級別。在典型的LLM訓練中,設定儲存優化器狀態、梯度和引數所需的記憶體為20N,其中N是模型引數數量[27]。

因此,BERT-Large(2018年早期的LLM之一,擁有3.4億引數)僅需6.8GB記憶體,就可輕鬆裝入單個桌面級GPU。另一方面,對於像GPT-3這樣的1750億引數模型,記憶體要求轉換為3.5TB。同時,NVIDIA最新的資料中心 GPU(H100)僅包含80GB的高頻寬記憶體(HBM),這表明至少需要44個H100才能滿足GPT-3的記憶體要求。[28]此外,即使在10000個V100 GPU上訓練GPT-3也需要14.8天。

因此,即使我們增加用於訓練的晶片數量,FLOPS利用率也仍然需要保持高水平,這一點至關重要。

硬體利用率的第一個維度是在單晶片層面。 在單個A100 GPU上訓練GPT-2模型時,硬體利用率達35.7%[29]。事實證明,片上記憶體(on-chip memory)和容量是硬體利用的瓶頸之一:處理器核心中的計算需要重複訪問HBM,而頻寬不足會抑制吞吐量。同樣,有限的本地記憶體容量會迫使從延遲較高的HBM進行更頻繁的讀取,從而限制吞吐量[30]。

硬體利用率的第二個維度與晶片到晶片的擴充套件有關。訓練像GPT-3這樣的LLM模型需要跨多個GPU對模型和資料進行劃分。正如片上儲存器的頻寬可能成為硬體利用的瓶頸一樣,晶片間互連的頻寬也可能成為硬體利用的限制因素。隨著V100的釋出,NVIDIA的NVLink實現了每個GPU 300GB/s的頻寬。對於A100來說,寬頻速度實現了600GB/s[31]。

硬體利用率的最後一個維度是系統到系統的擴充套件。一臺機器最多可容納16個GPU,因此擴充套件到更多數量的GPU要求跨系統的互連不能成為效能瓶頸。為此,Nvidia的Infiniband HCA在過去3年中將最大頻寬提高了2倍[32]。

在第二和第三個維度上,軟體劃分策略是硬體有效利用的關鍵考慮因素。通過結合模型和資料並行技術,2022年使用MT-NLG的Nvidia晶片叢集級別的LLM訓練的模型FLOPS利用率達到了30.2%[33],而使用GPT-3的模型FLOPS利用率在2020年只有21.3%:

選擇LLM的模型FLOPS利用率(PaLM:使用路徑擴充套件語言建模)

TPU等專用硬體實現了更高的效率。

谷歌5400億引數的PaLM模型在TPU v4晶片上實現了46.2%的模型FLOPS利用率,是GPT-3訓練利用率的2.2倍[34]

FLOPS利用率的提高得益於更高效的並行訓練(使用Google的Pathways ML系統)以及從根本上TPU具有完全不同的架構。該晶片的脈動陣列結構和每個核心的顯著的本地記憶體密度(local memory density)降低了高延遲全域性記憶體(global memory)的讀取頻率。

同樣地,我們可以看到CerebrasGraphcore和SambaNova等公司在處理器中分配了更多的共享記憶體容量。展望未來,我們預計其他新興創新,例如將晶片擴充套件到晶圓級以減少延遲/增加頻寬,或通過可程式設計單元優化資料訪問模式等將進一步推動硬體利用率的發展[35]。

6、大型語言模型即將迎來全盛時期

據《紐約時報》近日報道,谷歌宣稱ChatGPT是其搜尋業務的“紅色警報”( code red),它的搜尋量呈病毒式發展。

[36]從經濟角度來看,通過粗略估算,將高效能LLM納入搜尋將花費約15%的查詢收入,這表明該技術的部署已經切實可行。然而,谷歌的市場主導地位阻礙了它成為這方面的先行者:谷歌目前的搜尋收入為1000億美元,將高效能LLM納入搜尋會使谷歌的盈利能力減少一百多億美元。

另一方面,也就難怪微軟會計劃將大語言模型納入Bing了[37]。儘管LLM支援的搜尋成本高於傳統搜尋,並且與谷歌相比,微軟搜尋引擎的市場份額要低得多,但是微軟並未虧損。因此,如果微軟能夠成功地從谷歌手中奪取搜尋市場份額,那麼即使現有查詢成本更高,微軟仍然能夠獲得極高的利潤。

有趣的是,對於其他產品,通過部署LLM已經可以通過SaaS來盈利。例如,最近估值為15億美元、使用LLM生成文案的Jasper.ai收費為82美元/100000字(相當於1.09美元/1000個token)[38]。使用OpenAI的Davinci API 定價為 0.02美元/1000個token,即使我們對多個響應(response)進行取樣,毛利率也可能遠高於75%。

同樣令人驚訝的是,如今在公有云中僅需約140萬美元即可對GPT-3進行訓練,而且即使是SOTA模型(如PaLM,約1120萬美元)的訓練成本也不會太高。在過去的兩年半里,類似GPT-3等模型的訓練成本下降了80%以上,高效能大語言模型的訓練成本將進一步降低。

換句話說,訓練大語言模型並不便宜,但也沒那麼燒錢,訓練大語言模型需要大量的前期投入,但這些投入會逐年獲得回報。更近一步,Chinchilla論文表明,在未來,相比資金,高質量資料會成為訓練LLM的新興稀缺資源之一,因為擴充套件模型引數數量帶來的回報是遞減的。

參考文獻

  1. Alphabet 2021 10K
  2. Comparing Google and ChatGPT
  3. Microsoft and OpenAI Working on ChatGPT-Powered Bing in Challenge to Google
  4. Introducing YouChat - The AI Search Assistant that Lives in Your Search Engine
  5. Google Calls In Help From Larry Page and Sergey Brin for A.I. Fight
  6. ChatGPT: Optimizing Langauge Models for Dialogue(實際上,ChatGPT還在基礎1750億引數語言模型之上使用了RLHF(Reinforcement Learning from Human Feedback,即從反饋中獲得強化學習)機制,但為了簡單起見,我們不考慮強化學習成本。)
  7. Teaching language models to support answers with verified quotes
  8. ChatGPT: Optimizing Langauge Models for Dialogue
  9. OpenAI Pricing
  10. Building Software Systems at Google and Lessons Learned
  11. What’s New With Google Search
  12. Our World in Data: Internet
  13. Alphabet 2020 10K
  14. Scaling Laws for Neural Language Models(對於encoder-decoder模型,推理FLOPs約為N,而不是僅解碼器模型的2N)
  15. AWS EC2 P4 Instances
  16. NVIDIA A100 Tensor Core GPU Architecture
  17. Mixed precision training(針對FP16/FP32描述的所有內容也適用於BF16/FP32混合精度運算,這些運算在A100和其他處理器上具有類似的吞吐量)
  18. PaLM: Scaling Langauge Modeling with Pathways
  19. Cloud TPU pricing
  20. Scaling Laws for Neural Language Models(對於encoder-decoder模型,訓練FLOPS約為3N,而不是僅解碼器模型的6N)
  21. PaLM: Scaling Langauge Modeling with Pathways
  22. Carbon Emissions and Large Neural Network Training
  23. GTC 2018 Keynote with NVIDIA CEO Jensen Huang
  24. NVIDIA A100 Tensor Core GPU Architecture
  25. NVIDIA Hopper Architecture In-Depth
  26. An in-depth look at Google’s first Tensor Processing Unit (TPU)
  27. Using DeepSpeed and Megatron to Train Megatron-Turing NLG 530B, A Large-Scale Generative Language Model(假設基於使用混合精度訓練的Adam優化器,每個引數佔用20位元組的記憶體)
  28. NVIDIA Hopper Architecture In-Depth
  29. State-of-the-Art Language Modeling Using Megatron on the NVIDIA A100 GPU
  30. Which GPU(s) to Get for Deep Learning: My Experience and Advice for Using GPUs in Deep Learning
  31. NVLink and NVSwitch
  32. NVIDIA ConnectX InfiniBand Adapters
  33. PaLM: Scaling Langauge Modeling with Pathways
  34. PaLM: Scaling Langauge Modeling with Pathways
  35. Cerebras Architecture Deep Dive: First Look Inside the HW/SW Co-Design for Deep Learning
  36. Graphcore IPU Hardware Overview
  37. SambaNova SN10 RDU at Hot Chips 33
  38. A New Chat Bot is a ‘Code Red’ for Google’s Search Business
  39. Microsoft and OpenAI Working on ChatGPT-Powered Bing in Challenge to Google
  40. Jasper.ai Pricing

歡迎 Star、試用 OneFlow 最新版本:
http://github.com/Oneflow-Inc/oneflow/