作者 | 山竹

出品 | 鋅產業

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

或者說，工程實踐能力推動的大模型應用落地，在這時成了繼模型訓練后的第二戰場。

在這一新戰場，模型推理的重要性開始凸顯，“模型算子化”、“模型即服務”逐漸成為常態，大模型正在由此規模化邁入企業AI，并藉由此改變著社會運轉的底層邏輯。

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

而就在大模型又一次改變人類生活方式之前，每個人都值得花幾分鐘對這項顛覆性技術有一個基本認知。

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

這一次，鄭緯民院士在演講中通過五個環節總結了大模型全生命周期——數據獲取、數據預處理、模型訓練、模型微調、模型推理。

這五個環節，也是我們認清大模型的開始。

01數據獲取

“大模型是數據喂出來的”。

關于大模型，這是我這兩年聽到最多的解釋。

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

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

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

海量小文件存儲過程中面臨著一個挑戰，那就是元數據的管理：

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

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

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

我們現在需要一個方法，既讓數據能“放得下”，也要能被“讀得快”。

鄭緯民院士團隊研發的分布式文件系統SuperFS，在國產超算鵬城云腦II上特別針對海量小文件場景進行了優化，從而實現了快速讀寫和可擴展性。

02數據預處理

數據預處理是第二環節。

在拿到數據后，模型在訓練之前，還需要對這些數據進行預處理，以獲得高質量的樣本數據。

由于從兩個不同地方獲取到的數據可能存在數據重復等問題，這就需要對這些數據進行預處理，需要去除重復數據、需要去除數據中的廣告內容，還需要數據格式統一。

以OpenAI的GPT-4訓練為例：

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

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

據谷歌數據中心統計，在大模型訓練過程中，30%的時間花在了數據預處理上。

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

因而，數據預處理是一件相當耗時耗力的事兒。

那么，為什么數據預處理這么慢呢？

這是因為如今的數據處理面臨著兩方面的挑戰：

第一，已有數據處理方法通常以計算為中心，將需要預處理的數據搬移到進行計算任務的節點上；

第二，需要處理的數據往往分散在多個節點上，讀取遠端節點的數據往往又會引入很大的網絡開銷。

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

答案是，有的。

那就是將數據處理方法改為以數據為中心，將計算任務搬到數據節點上。

將計算任務動態地根據其需要的數據調度到數據所在的節點上，從分布系統的數據讀入轉換為從本地文件系統讀入。

具體到生產環境中，目前業界在進行數據處理時使用最多的是Spark軟件，由于用的人多，生態就好，在可擴展性、容錯性上都有不錯的表現，然而，Spark依然存在兩個缺點：

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

第二，大數據處理為內存計算模式，需要將數據放在內存上，這些內存大小往往是被處理數據大小的20倍，內存往往很貴，這直接導致數據處理過程往往開銷很大。

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

03模型訓練

第三個環節是模型訓練。

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

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

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

第二，GPU大規模集群的容錯問題。

大模型訓練需要的算力難以通過單一GPU提供，萬卡集群、十萬卡集群已經成為基礎大模型訓練的必備條件。

然而，即便是業界領先的神威平臺，十萬卡組成的集群訓練萬億參數量模型時，訓練過程中，平均每小時也會發生一次軟硬件錯誤。

這已經是世界先進水平。

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

這就需要在模型訓練過程中設置模型參數檢查點：

在模型訓練到40分鐘時主動停下來，將當前的軟硬環境存儲到系統中，然后繼續進行模型訓練。

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

以此類推。

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

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

經過這樣的架構調整，十萬億參數量模型一次檢查點存儲的時間就被縮短到了10分鐘。

04模型微調

第四個環節是模型微調。

經過模型訓練后，訓練出的就是傳說中的基礎大模型，相當于現在的DeepSeek V3，拿到基礎大模型對于大多數商業場景而言，并不意味著就可以直接使用，還需要進行模型微調才能真正被應用到產業中。

如果直接將基礎大模型應用到諸如醫療、金融等場景中，實際使用效果并不如人意，這是因為訓練基礎大模型用到的數據是來自互聯網的通識數據，這些數據無法形成某一行業的專業知識，因而無法處理專業領域的問題。

以醫療場景為例，基礎大模型要應用到醫院場景，就需要收集醫院場景的數據，對基礎大模型進行第二次訓練，由此才能得到醫院大模型。

如果還要應用到更垂直的應用領域，例如B超檢測，還可以基于B超檢測的數據進行第三次訓練，第四次訓練……

依次類推，我們就可以得到一個垂直細分領域應用的大模型。

05模型推理

第五個環節，也是最后一個環節是模型推理。

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

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

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

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

以萬億參數規模模型為例：

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

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

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

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

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

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

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

Kimi作為2024年國內大模型創業公司中跑出的一匹黑馬，一經破圈，曾連續五次算力擴容卻仍經歷了服務器過載宕機。

那么，Kimi后來是如何進行模型推理架構調整，進而平穩承載流量洪峰的呢？

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

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

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

第二個用戶向Kimi提問：這篇論文的關鍵創新點是什么？

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

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

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

數據獲取——數據預處理——模型訓練——模型微調——模型推理，這五個環節構成了大模型的全生命周期。

對于中國算力產業而言，這其中的萬卡集群構建和異構卡聯合訓練，是如今我們面臨的兩大難題。