前不久，馬斯克旗下的xAI122天建成十萬卡集群，也讓外界意識到算力集群對AI的重要性。（雷峰網(公眾號：雷峰網)雷峰網雷峰網）

之前坊間還流傳一句話：服務器集群的規(guī)模越大，其訓練出來的人工智能表現就越出色。

在這波浪潮之下，全球科技巨頭紛紛投入巨資建設高性能AI計算集群，以提升AI算法的效率和能力。谷歌推出了其AI Platform，依托多模態(tài)生成式AI模型Gemini，大幅提升了在文本、圖像、音頻和視頻處理上的能力。微軟的Azure AI Compute Cluster整合了最新AI技術，為開發(fā)者提供了從數據處理到模型訓練的全方位支持。（添加微信Who123start，解鎖獨家科技內幕和行業(yè)趣聞）

作為國內最早推出大模型之一的百度，也展現出其強大的創(chuàng)新能力。11月6日，在百度智能云舉辦的百舸媒體沙龍，深入探討“十萬卡集群”的技術創(chuàng)新、實施過程及其對AI行業(yè)的推動作用，并邀請百度杰出系統(tǒng)架構師、百度AI計算部負責人王雁鵬在現場做了分享和交流。

以下是媒體與三位嘉賓在會上的對談實錄，雷峰網在不改變原意的情況下做了編輯和調整：

 

Q：百舸的客戶群是哪些？重點的行業(yè)客戶是否之前有一些成功案例可以來分享？

 

A：我們的客戶主要分為兩類。一類是大模型創(chuàng)企，他們需要萬卡規(guī)模的計算能力，因而對快速建設和成本控制有較高的需求。這類客戶雖然數量較少，但其需求非常明確；

另一類是典型的互聯網客戶，他們的需求規(guī)模通常在千卡到5000卡之間。這些客戶包括教育行業(yè)的公司。

 

這些互聯網客戶的主要需求是利用他們大量的自有數據進行后期訓練（Post Train），以適應各種場景和優(yōu)化，從而構建他們的數據飛輪。目前，這些訓練需求依然是我們的主要業(yè)務，而推理需求相對較少。這也解釋了為什么業(yè)界對AI算力落地效果仍存疑慮。預計在今年或明年，算力需求仍將以訓練為主，而推理和SFT（小規(guī)模微調）的長尾客戶將會增多，但總體資源需求仍低于頭部客戶。

 

Q：百舸客戶的主要需求和痛點是什么？我們是如何解決的？

 

A：各類客戶的需求其實有很多共通之處，我們可以一層層來分析。

1.       基礎設施層面：這些客戶首先需要一個強大的網絡硬件互聯架構。企業(yè)在嘗試自行搭建大規(guī)模集群時，常常會遇到網絡上的難題。我們的任務是為他們提供更好的網絡硬件互聯架構，使他們能夠成功搭建一個大規(guī)模的計算集群。

2.       系統(tǒng)穩(wěn)定性：沒有經驗的客戶在自行搭建系統(tǒng)時，常會遇到有效訓練時間過低的問題。這些穩(wěn)定性問題是客戶面臨的第二大難題，我們需要幫助他們提高系統(tǒng)的可靠性和有效訓練時間。

3.       加速框架：在提供加速框架方面，我們幫助客戶優(yōu)化并行策略，提升性能。通過更好的框架，我們能顯著提升計算速度，解決加速問題。

4.       資源利用率：客戶購買大量資源后，需要有效利用這些資源。他們可能既有推理任務又有訓練任務，最初可能是為訓練任務購買資源，但隨后也需要利用這些資源進行推理。我們通過任務混合部署，提升資源利用率，確保資源能夠被高效利用。

 

Q：您剛才花很大篇幅講跨地域網絡問題，能否舉例說明實際效果？

 

A: 跨網絡問題主要涉及兩個方面：一是當進行十萬卡規(guī)模的部署時，確實需要跨地域的支持；二是我們云服務的能力。舉例來說，我們可以在云上兩個機房同時部署計算任務，但客戶在使用時完全感知不到差異。例如，即使客戶使用的是5000卡的規(guī)模，我們在不同地點分配資源，但使用體驗依然一致，這是我們的一大優(yōu)勢。

 

Q：面對不同客戶需求，如1000到5000卡的規(guī)模，如何確保任務級別的混合調度的效率提升？

 

A: 混合調度我們已經做了許多工作，實質上是通過混合集群實現不同特征的工作負載的混合。

例如，推理任務有波峰波谷，波峰時使用的資源更多，波谷時使用較少；而訓練任務則需要固定數量的計算卡（如1000卡），如果資源不足，比如僅有990卡，任務將無法運行。

為了解決這些問題，我們提供了一個非常靈活的隊列機制，將業(yè)務視為虛擬隊列，并配置優(yōu)先級策略。這些隊列根據實際情況動態(tài)調整資源分配，當資源不再需要時，可以被其他隊列的任務搶占，從而提高資源利用率。此外，我們的框架能夠自動重新分配并行策略。例如，一個需要1000卡的任務，在資源不足時（如僅有900卡），能夠調整并行策略以繼續(xù)運行，從而確保任務的連續(xù)性和有效性。

 

Q： 請詳細聊一下Checkpoint環(huán)節(jié)，大家有不同的策略，可能有些效果更好，有些則影響訓練有效時間和成本，我們在這方面是怎么做的？

 

A： 原來的Checkpoint策略是隔一段時間創(chuàng)建一個Checkpoint，在故障發(fā)生后恢復。但是，這種方法的缺點是，如果每小時創(chuàng)建一次Checkpoint，出現故障時通常會浪費一半的時間，即30分鐘。因此，我們希望Checkpoint越密集越好，但這也帶來新的問題。

最初的Checkpoint策略需要停止訓練，將數據寫入存儲，這會耗費大量時間，因為存儲帶寬有限。當時停下來寫Checkpoint需要幾分鐘，這顯然無法接受，尤其在Checkpoint頻繁時。

第一階段：改進為異步Checkpoint，訓練過程不中斷，先將數據復制到內存，然后異步寫入存儲。這樣可以縮短Checkpoint時間，從原來的兩小時一次縮短到每30分鐘一次。但依然存在瓶頸，如存儲帶寬限制。

第二階段：引入觸發(fā)式Checkpoint。在正常情況下不創(chuàng)建Checkpoint，只有在故障發(fā)生時才創(chuàng)建。很多GPU故障不會導致數據丟失，可以在故障點恢復數據并存儲。這種方法在大多數情況下有效（95%以上），僅在傳統(tǒng)Checkpoint保留的情況下無回退和浪費。

雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。