今天小編分享的互聯網經驗：從背景到技術儲備：深入解析建“十萬卡集群”的必要性，歡迎閱讀。
前不久，馬斯克旗下的 xAI122 天建成十萬卡集群，也讓外界意識到算力集群對 AI 的重要性。（雷峰網雷峰網雷峰網）
之前坊間還流傳一句話：伺服器集群的規模越大，其訓練出來的人工智能表現就越出色。
在這波浪潮之下，全球科技巨頭紛紛投入巨資建設高性能 AI 計算集群，以提升 AI 算法的效率和能力。谷歌推出了其 AI Platform，依托多模态生成式 AI 模型 Gemini，大幅提升了在文本、影像、音頻和視頻處理上的能力。微軟的 Azure AI Compute Cluster 整合了最新 AI 技術，為開發者提供了從數據處理到模型訓練的全方位支持。（添加微信 Who123start，解鎖獨家科技内幕和行業趣聞）
作為國内最早推出大模型之一的百度，也展現出其強大的創新能力。11 月 6 日，在百度智能雲舉辦的百舸媒體沙龍，深入探讨 " 十萬卡集群 " 的技術創新、實施過程及其對 AI 行業的推動作用，并邀請百度傑出系統架構師、百度 AI 計算部負責人王雁鵬在現場做了分享和交流。
以下是媒體與三位嘉賓在會上的對談實錄，雷峰網在不改變原意的情況下做了編輯和調整：
Q：百舸的客戶群是哪些？重點的行業客戶是否之前有一些成功案例可以來分享？
A：我們的客戶主要分為兩類。一類是大模型創企，他們需要萬卡規模的計算能力，因而對快速建設和成本控制有較高的需求。這類客戶雖然數量較少，但其需求非常明确；
另一類是典型的互聯網客戶，他們的需求規模通常在千卡到 5000 卡之間。這些客戶包括教育行業的公司。
這些互聯網客戶的主要需求是利用他們大量的自有數據進行後期訓練（Post Train），以适應各種場景和優化，從而構建他們的數據飛輪。目前，這些訓練需求依然是我們的主要業務，而推理需求相對較少。這也解釋了為什麼業界對 AI 算力落地效果仍存疑慮。預計在今年或明年，算力需求仍将以訓練為主，而推理和 SFT（小規模微調）的長尾客戶将會增多，但總體資源需求仍低于頭部客戶。
Q：百舸客戶的主要需求和痛點是什麼？我們是如何解決的？
A：各類客戶的需求其實有很多共通之處，我們可以一層層來分析。
1. 基礎設施層面：這些客戶首先需要一個強大的網絡硬體互聯架構。企業在嘗試自行搭建大規模集群時，常常會遇到網絡上的難題。我們的任務是為他們提供更好的網絡硬體互聯架構，使他們能夠成功搭建一個大規模的計算集群。
2. 系統穩定性：沒有經驗的客戶在自行搭建系統時，常會遇到有效訓練時間過低的問題。這些穩定性問題是客戶面臨的第二大難題，我們需要幫助他們提高系統的可靠性和有效訓練時間。
3. 加速框架：在提供加速框架方面，我們幫助客戶優化并行策略，提升性能。通過更好的框架，我們能顯著提升計算速度，解決加速問題。
4. 資源利用率：客戶購買大量資源後，需要有效利用這些資源。他們可能既有推理任務又有訓練任務，最初可能是為訓練任務購買資源，但随後也需要利用這些資源進行推理。我們通過任務混合部署，提升資源利用率，确保資源能夠被高效利用。
Q：您剛才花很大篇幅講跨地網域網絡問題，能否舉例說明實際效果？
A: 跨網絡問題主要涉及兩個方面：一是當進行十萬卡規模的部署時，确實需要跨地網域的支持；二是我們雲服務的能力。舉例來說，我們可以在雲上兩個機房同時部署計算任務，但客戶在使用時完全感知不到差異。例如，即使客戶使用的是 5000 卡的規模，我們在不同地點分配資源，但使用體驗依然一致，這是我們的一大優勢。
Q：面對不同客戶需求，如 1000 到 5000 卡的規模，如何确保任務級别的混合調度的效率提升？
A: 混合調度我們已經做了許多工作，實質上是通過混合集群實現不同特征的工作負載的混合。
例如，推理任務有波峰波谷，波峰時使用的資源更多，波谷時使用較少；而訓練任務則需要固定數量的計算卡（如 1000 卡），如果資源不足，比如僅有 990 卡，任務将無法運行。
為了解決這些問題，我們提供了一個非常靈活的隊列機制，将業務視為虛拟隊列，并配置優先級策略。這些隊列根據實際情況動态調整資源分配，當資源不再需要時，可以被其他隊列的任務搶占，從而提高資源利用率。此外，我們的框架能夠自動重新分配并行策略。例如，一個需要 1000 卡的任務，在資源不足時（如僅有 900 卡），能夠調整并行策略以繼續運行，從而确保任務的連續性和有效性。
Q： 請詳細聊一下 Checkpoint 環節，大家有不同的策略，可能有些效果更好，有些則影響訓練有效時間和成本，我們在這方面是怎麼做的？
A： 原來的 Checkpoint 策略是隔一段時間創建一個 Checkpoint，在故障發生後恢復。但是，這種方法的缺點是，如果每小時創建一次 Checkpoint，出現故障時通常會浪費一半的時間，即 30 分鍾。因此，我們希望 Checkpoint 越密集越好，但這也帶來新的問題。
最初的 Checkpoint 策略需要停止訓練，将數據寫入存儲，這會耗費大量時間，因為存儲帶寬有限。當時停下來寫 Checkpoint 需要幾分鍾，這顯然無法接受，尤其在 Checkpoint 頻繁時。
第一階段：改進為異步 Checkpoint，訓練過程不中斷，先将數據復制到内存，然後異步寫入存儲。這樣可以縮短 Checkpoint 時間，從原來的兩小時一次縮短到每 30 分鍾一次。但依然存在瓶頸，如存儲帶寬限制。
第二階段：引入觸發式 Checkpoint。在正常情況下不創建 Checkpoint，只有在故障發生時才創建。很多 GPU 故障不會導致數據丢失，可以在故障點恢復數據并存儲。這種方法在大多數情況下有效（95% 以上），僅在傳統 Checkpoint 保留的情況下無回退和浪費。
