大模型的五個環(huán)節(jié)和十大難題

作者 | 山竹

出品 | 鋅產(chǎn)業(yè)

在生成式AI進入全球視野的第四年，大模型競賽在2025年正式進入下半場，下半場考驗的能力從模型訓(xùn)練轉(zhuǎn)向工程能力。

或者說，工程實踐能力推動的大模型應(yīng)用落地，在這時成了繼模型訓(xùn)練后的第二戰(zhàn)場。

在這一新戰(zhàn)場，模型推理的重要性開始凸顯，“模型算子化”、“模型即服務(wù)”逐漸成為常態(tài)，大模型正在由此規(guī)模化邁入企業(yè)AI，并藉由此改變著社會運轉(zhuǎn)的底層邏輯。

這時，沒有人再懷疑大模型的重要性，就像沒有人會懷疑互聯(lián)網(wǎng)改變了人類生活方式一樣。

而就在大模型又一次改變?nèi)祟惿罘绞街埃總€人都值得花幾分鐘對這項顛覆性技術(shù)有一個基本認知。

我是在最近的阿里云PolarDB數(shù)據(jù)庫開發(fā)者大會上，又一次聽到了鄭緯民院士的演講。

這一次，鄭緯民院士在演講中通過五個環(huán)節(jié)總結(jié)了大模型全生命周期——數(shù)據(jù)獲取、數(shù)據(jù)預(yù)處理、模型訓(xùn)練、模型微調(diào)、模型推理。

這五個環(huán)節(jié)，也是我們認清大模型的開始。

01數(shù)據(jù)獲取

“大模型是數(shù)據(jù)喂出來的”。

關(guān)于大模型，這是我這兩年聽到最多的解釋。

所謂大模型，就是先有大數(shù)據(jù)、再有大算力，然后才有大模型。

大模型在訓(xùn)練過程中首先需要收集海量的多模態(tài)數(shù)據(jù)，這些數(shù)據(jù)來自世界各地，通過將這些數(shù)據(jù)收集上來并放到一個系統(tǒng)中，這是“造”出大模型的第一步。

在此過程中，這些海量數(shù)據(jù)涉及到的文件數(shù)量多達數(shù)百億，這數(shù)百億個小文件要存儲在硬盤中，這其中，哪個小文件放在硬盤的哪個位置需要被記住，這就是元數(shù)據(jù)。

海量小文件存儲過程中面臨著一個挑戰(zhàn)，那就是元數(shù)據(jù)的管理：

首先，存儲100億個小文件需要管理7TB元數(shù)據(jù)，這就要求數(shù)據(jù)庫有足夠的擴展性，也就是要讓數(shù)據(jù)能“放得下”；

其次，典型大模型要求訪問延時在百微秒級，這對系統(tǒng)的延時提供了很高的要求，也就是讓數(shù)據(jù)能“讀得快”。

現(xiàn)有的諸如HDFS、Lustre元數(shù)據(jù)集中式管理架構(gòu)訪問延時低（讀得快），但無法橫向擴展（放不下），而CephFS這樣的元數(shù)據(jù)分布式管理架構(gòu)可橫向擴展（放得下），但訪問延時高（讀不快）。

我們現(xiàn)在需要一個方法，既讓數(shù)據(jù)能“放得下”，也要能被“讀得快”。

鄭緯民院士團隊研發(fā)的分布式文件系統(tǒng)SuperFS，在國產(chǎn)超算鵬城云腦II上特別針對海量小文件場景進行了優(yōu)化，從而實現(xiàn)了快速讀寫和可擴展性。

02數(shù)據(jù)預(yù)處理

數(shù)據(jù)預(yù)處理是第二環(huán)節(jié)。

在拿到數(shù)據(jù)后，模型在訓(xùn)練之前，還需要對這些數(shù)據(jù)進行預(yù)處理，以獲得高質(zhì)量的樣本數(shù)據(jù)。

由于從兩個不同地方獲取到的數(shù)據(jù)可能存在數(shù)據(jù)重復(fù)等問題，這就需要對這些數(shù)據(jù)進行預(yù)處理，需要去除重復(fù)數(shù)據(jù)、需要去除數(shù)據(jù)中的廣告內(nèi)容，還需要數(shù)據(jù)格式統(tǒng)一。

以O(shè)penAI的GPT-4訓(xùn)練為例：

業(yè)界推測，GPT-4參數(shù)量高達1.8萬億，模型訓(xùn)練過程中，使用了約2.5萬塊A100 GPU，模型訓(xùn)練周期為90-100天（3-4個月），然而整個數(shù)據(jù)預(yù)處理耗時預(yù)計在半年左右。

在這方面，GPT-4并不是獨一份。

據(jù)谷歌數(shù)據(jù)中心統(tǒng)計，在大模型訓(xùn)練過程中，30%的時間花在了數(shù)據(jù)預(yù)處理上。

與此同時，微軟也分析了9種常見模型，據(jù)悉，在分析的這些模型中，數(shù)據(jù)預(yù)處理最多占用了65%的模型訓(xùn)練時間。

因而，數(shù)據(jù)預(yù)處理是一件相當耗時耗力的事兒。

那么，為什么數(shù)據(jù)預(yù)處理這么慢呢？

這是因為如今的數(shù)據(jù)處理面臨著兩方面的挑戰(zhàn)：

第一，已有數(shù)據(jù)處理方法通常以計算為中心，將需要預(yù)處理的數(shù)據(jù)搬移到進行計算任務(wù)的節(jié)點上；

第二，需要處理的數(shù)據(jù)往往分散在多個節(jié)點上，讀取遠端節(jié)點的數(shù)據(jù)往往又會引入很大的網(wǎng)絡(luò)開銷。

有沒有什么方法可以解決這兩個問題呢？

答案是，有的。

那就是將數(shù)據(jù)處理方法改為以數(shù)據(jù)為中心，將計算任務(wù)搬到數(shù)據(jù)節(jié)點上。

將計算任務(wù)動態(tài)地根據(jù)其需要的數(shù)據(jù)調(diào)度到數(shù)據(jù)所在的節(jié)點上，從分布系統(tǒng)的數(shù)據(jù)讀入轉(zhuǎn)換為從本地文件系統(tǒng)讀入。

具體到生產(chǎn)環(huán)境中，目前業(yè)界在進行數(shù)據(jù)處理時使用最多的是Spark軟件，由于用的人多，生態(tài)就好，在可擴展性、容錯性上都有不錯的表現(xiàn)，然而，Spark依然存在兩個缺點：

第一 ，Spark是在2009年誕生于加州伯克利大學(xué)分校AMP實驗室，軟件以Java語言編寫，處理速度較慢；

第二，大數(shù)據(jù)處理為內(nèi)存計算模式，需要將數(shù)據(jù)放在內(nèi)存上，這些內(nèi)存大小往往是被處理數(shù)據(jù)大小的20倍，內(nèi)存往往很貴，這直接導(dǎo)致數(shù)據(jù)處理過程往往開銷很大。

基于以數(shù)據(jù)為中心的執(zhí)行模式，鄭緯民院士團隊研發(fā)了諸葛弩大數(shù)據(jù)處理引擎，通過基于C++ RDD編程接口，供性能工程師編寫高性能計算模塊，并將此嵌入到PySpark預(yù)處理管線中，兼容PySpark編程接口和生態(tài)。

03模型訓(xùn)練

第三個環(huán)節(jié)是模型訓(xùn)練。

模型訓(xùn)練過程涉及諸多算法和技術(shù)，這其中普遍存在兩個問題：

第一，GPU的存儲容量難以滿足大模型訓(xùn)練的存儲需求。

GPU已經(jīng)成為大模型訓(xùn)練的主要硬件，但GPU存儲容量小且增長緩慢，與此同時，GPU存算資源強耦合，存算資源只能等比擴展，當存儲容量不足時，就需要買卡，這就會導(dǎo)致算力冗余、存力不足的問題。

第二，GPU大規(guī)模集群的容錯問題。

大模型訓(xùn)練需要的算力難以通過單一GPU提供，萬卡集群、十萬卡集群已經(jīng)成為基礎(chǔ)大模型訓(xùn)練的必備條件。

然而，即便是業(yè)界領(lǐng)先的神威平臺，十萬卡組成的集群訓(xùn)練萬億參數(shù)量模型時，訓(xùn)練過程中，平均每小時也會發(fā)生一次軟硬件錯誤。

這已經(jīng)是世界先進水平。

那么，這個問題又該如何解決呢？

這就需要在模型訓(xùn)練過程中設(shè)置模型參數(shù)檢查點：

在模型訓(xùn)練到40分鐘時主動停下來，將當前的軟硬環(huán)境存儲到系統(tǒng)中，然后繼續(xù)進行模型訓(xùn)練。

當模型訓(xùn)練到1小時報錯時，將此前在40分鐘時存儲下來的軟硬件環(huán)境提取出并繼續(xù)進行模型訓(xùn)練。

以此類推。

這一模式看似邏輯簡單，但卻存在另一個問題——寫檢查點需要耗費大量時間，未經(jīng)優(yōu)化時，一次檢查點的存儲需要3小時。

這就需要通過分布式檢查點存儲，將數(shù)據(jù)均勻分布到所有參與并行計算的節(jié)點，每個節(jié)點只需要存儲分配到該節(jié)點的部分數(shù)據(jù)。

經(jīng)過這樣的架構(gòu)調(diào)整，十萬億參數(shù)量模型一次檢查點存儲的時間就被縮短到了10分鐘。

04模型微調(diào)

第四個環(huán)節(jié)是模型微調(diào)。

經(jīng)過模型訓(xùn)練后，訓(xùn)練出的就是傳說中的基礎(chǔ)大模型，相當于現(xiàn)在的DeepSeek V3，拿到基礎(chǔ)大模型對于大多數(shù)商業(yè)場景而言，并不意味著就可以直接使用，還需要進行模型微調(diào)才能真正被應(yīng)用到產(chǎn)業(yè)中。

如果直接將基礎(chǔ)大模型應(yīng)用到諸如醫(yī)療、金融等場景中，實際使用效果并不如人意，這是因為訓(xùn)練基礎(chǔ)大模型用到的數(shù)據(jù)是來自互聯(lián)網(wǎng)的通識數(shù)據(jù)，這些數(shù)據(jù)無法形成某一行業(yè)的專業(yè)知識，因而無法處理專業(yè)領(lǐng)域的問題。

以醫(yī)療場景為例，基礎(chǔ)大模型要應(yīng)用到醫(yī)院場景，就需要收集醫(yī)院場景的數(shù)據(jù)，對基礎(chǔ)大模型進行第二次訓(xùn)練，由此才能得到醫(yī)院大模型。

如果還要應(yīng)用到更垂直的應(yīng)用領(lǐng)域，例如B超檢測，還可以基于B超檢測的數(shù)據(jù)進行第三次訓(xùn)練，第四次訓(xùn)練……

依次類推，我們就可以得到一個垂直細分領(lǐng)域應(yīng)用的大模型。

05模型推理

第五個環(huán)節(jié)，也是最后一個環(huán)節(jié)是模型推理。

GPU顯存容量往往難以滿足大模型推理需求，為此，業(yè)界也出現(xiàn)了針對推理場景特別研發(fā)的推理芯片。

例如2024年2月，谷歌前員工創(chuàng)立的AI芯片創(chuàng)企Groq，就曾憑借基于自研LPU芯片運行的大模型推理任務(wù)，速度堪比英偉達GPU的10倍。

推理卡對存儲同樣有著很高的要求，推理卡的存儲器主要會存放兩類數(shù)據(jù)，一類是模型訓(xùn)練完的參數(shù)，另一類是模型推理過程KV-cache。

這其中，尤以KV-cache占用存儲空間大。

以萬億參數(shù)規(guī)模模型為例：

模型（參數(shù)）大小為2TB，需要26張GPU存儲參數(shù)；

模型KV-cache大小為7TB，需要86張GPU存儲相關(guān)推理過程。

推理卡的存儲器如果不夠大，將會直接影響模型推理效果。

那么，如何提升模型推理過程中的存儲容量，進而提升模型效果？

由于推理卡是插在服務(wù)器上，服務(wù)器原本就有CPU和存儲器，在推理過程中，服務(wù)器上的CPU和存儲器通常處于閑置狀態(tài)。

如果能將這些處于閑置狀態(tài)的CPU和存儲器利用起來，來存儲KV-cache，自然就能提升模型推理效果，模型推理性能至少能因此提升2倍。

這就是存儲一體的分離式KV-cache設(shè)計邏輯。

Kimi作為2024年國內(nèi)大模型創(chuàng)業(yè)公司中跑出的一匹黑馬，一經(jīng)破圈，曾連續(xù)五次算力擴容卻仍經(jīng)歷了服務(wù)器過載宕機。

那么，Kimi后來是如何進行模型推理架構(gòu)調(diào)整，進而平穩(wěn)承載流量洪峰的呢？

這其中的核心邏輯是以存換算。

以大模型輔助讀論文場景為例：

第一個用戶向Kimi提問：請總結(jié)一下這篇論文。

第二個用戶向Kimi提問：這篇論文的關(guān)鍵創(chuàng)新點是什么？

依次類推，這樣一篇論文可能會有10-20萬用戶查詢和提問。

如果以傳統(tǒng)推理過程來看，這就意味著這10-20萬用戶的KV-cache都要存起來。

這時，如果僅僅是將共享可復(fù)用部分的KV-cache存下來進行多次復(fù)用，不同部分不再存儲，而是改由實時計算，這樣就實現(xiàn)了以存換算，大幅降低了算力開銷。

數(shù)據(jù)獲取——數(shù)據(jù)預(yù)處理——模型訓(xùn)練——模型微調(diào)——模型推理，這五個環(huán)節(jié)構(gòu)成了大模型的全生命周期。

對于中國算力產(chǎn)業(yè)而言，這其中的萬卡集群構(gòu)建和異構(gòu)卡聯(lián)合訓(xùn)練，是如今我們面臨的兩大難題。