1.AI 訓練穩(wěn)定性的百度百舸演進歷程

2012 年 ImageNet 競賽中 AlexNet 的橫空出世,開啟了現(xiàn)代 AI 發(fā)展的新紀元。彼時我們不會想到,集群踐十年后支撐 AI 訓練的 GPU 集群會從研究室里的幾臺服務器,發(fā)展成需要專門供電系統(tǒng)的萬卡級計算矩陣。在這個算力爆發(fā)式增長的訓定性過程中,訓練系統(tǒng)的穩(wěn)定性管理正經(jīng)歷著從「簡單運維」到「精密工程」的深刻變革。

1.1早期的練穩(wěn)小模型時代:手動運維的黃金年代

2022 年之前的 AI 訓練,更像是手工作坊式的精雕細琢。大多數(shù)訓練任務只需十幾塊 GPU,系統(tǒng)利用 PyTorch 或 TensorFlow 的數(shù)據(jù)并行功能就能輕松應對。記得那時算法工程師們有個共識:如果訓練遇到問題,設計重啟往往比排查更高效。

當時我們構(gòu)建的和實監(jiān)控系統(tǒng)就像汽車儀表盤,只能顯示最基本的任務狀態(tài)。當訓練意外中斷時,百度百舸工程師們會像偵探一樣翻查日志 —— 如果發(fā)現(xiàn)是 GPU 報錯,就聯(lián)系運維同事。運維人員則帶著「NVIDIA三件套」(nvidia-smi、集群踐dcgm、訓定性nsys)到機房巡檢,練穩(wěn)像老中醫(yī)把脈般通過溫度、功耗等指標判斷硬件狀態(tài)。系統(tǒng)這種工作模式雖簡單,設計但應對數(shù)十卡規(guī)模的集群還算游刃有余。

1.2大模型風暴:從量變到質(zhì)變的和實沖擊

ChatGPT 的登場如同打開潘多拉魔盒,將 AI 訓練帶入新的紀元。當我們開始部署千卡/萬卡集群時,百度百舸才發(fā)現(xiàn)原有的運維體系就像用小漁網(wǎng)捕鯨魚 —— 完全無法匹配新需求。

讓我們通過百度百舸經(jīng)歷過的一個真實案例來深入理解這個問題:

2024 年初,百度百舸幫助一家 AIGC 創(chuàng)業(yè)公司迅速將其訓練規(guī)模從百卡擴展到千卡級別。然而在訓練數(shù)天后的某個周末凌晨,訓練進程意外發(fā)生了 hang 死。由于當時缺乏有效的故障感知和容錯機制,直到第二天算法工程師發(fā)現(xiàn)任務超時退出時,已經(jīng)耽誤了數(shù)小時寶貴的訓練時間。更糟糕的是,任務日志中除了簡單的 timeout 報錯外毫無線索,平臺監(jiān)控也顯示所有訓練節(jié)點狀態(tài)正常。著急恢復訓練的算法工程師沒有立即上報問題,而是選擇直接重新提交任務。但不幸的是,新任務運行數(shù)小時后再次出現(xiàn)相同的超時退出。這時他們才不得不尋求技術支持,但值班工程師面對這種任務 hang 死的問題也缺乏診斷經(jīng)驗,只能通過二分法慢慢定位。最終發(fā)現(xiàn)是某個節(jié)點的靜默故障(SDC)導致了訓練進程假死。等問題得到解決時,距離首次故障已經(jīng)過去將近 30 小時,這意味著損失了價值巨大的千卡算力資源。

2.百度百舸集群訓練穩(wěn)定性全景圖

站在現(xiàn)在的時間點回望,AI 訓練穩(wěn)定性已從輔助功能演變?yōu)楹诵幕A設施。就像現(xiàn)代建筑中的抗震結(jié)構(gòu),它雖不直接參與空間構(gòu)成,卻是萬丈高樓得以屹立的關鍵。當行業(yè)向著數(shù)萬卡集群邁進時,這套隱形護甲的質(zhì)量,將直接決定 AI 進化的速度與邊界。

在 2024 年百度百舸對訓練過程的生命周期進行了更細致的拆分,提出了「無效訓練時間」這一關鍵指標,并致力于將其最小化。具體來說:

任務無效訓練時間 = 故障中斷次數(shù) × 任務故障恢復時長 + 任務常態(tài)寫 Ckpt 總時長

其中,任務故障恢復時長 = 故障感知召回耗時(自動/人工定位)+ 任務調(diào)度耗時 + 任務初始化耗時 + 任務重算時長。

通過這個公式可以看出,要降低無效訓練時間,需要「圍繞基礎設施穩(wěn)定性」、「任務容錯」兩個維度來系統(tǒng)展開,重點解決三個方面的問題:

提高基礎設施的交付質(zhì)量。

提高任務故障容錯的召回率、準確率和時效性。

優(yōu)化 checkpoint 機制,減少保存時間和恢復時的重算時間。

經(jīng)過容錯架構(gòu)的整體變革,百度百舸形成了從「任務負載 —框架 —通信—基礎架構(gòu)」全鏈路的自動異常感知、診斷、恢復能力,可覆蓋 90%+ 的訓練異常場景,時效性最快可以實現(xiàn)秒級異常感知、分鐘級定位,以及平均 3 分鐘的故障自愈能力。

3. 基礎設施交付質(zhì)量保障

基礎設施的交付質(zhì)量保障是穩(wěn)定性的基礎。

CPU 時代,機器的交付前可能僅會跑一些常規(guī)的 CPU 計算、網(wǎng)絡的壓力測試,并不會從業(yè)務視角去評估基礎架構(gòu),機器交付后硬件異常的故障頻率相對較少。有硬件故障時,通常走工單系統(tǒng)人工換機用戶相對是可接受的。

而 GPU 時代,AI Infra 的交付則需要考慮 CPU、GPU、RDMA 網(wǎng)絡、存儲,甚至機房的功率、溫度等各方面因素,遺漏任何一個環(huán)節(jié)都會成為后續(xù)穩(wěn)定性的隱患。在交付給客戶后,機器也可能會由于長時間的高負載運行頻繁出現(xiàn)硬件故障,而 GPU 機器的高昂成本,使客戶對節(jié)點故障感知、換機的時效性提出了非常高的要求。

因此百度百舸對 GPU 機器交付前及交付后的穩(wěn)定性質(zhì)量進行了系統(tǒng)性管理:

交付前,百度百舸會對機器進行 200 多項指標檢測,然后進行 48 小時烤機,以及 NCCL-Test 的機內(nèi)、機間的大環(huán)、同號卡通信性能基準測試,端到端的大模型訓練、推理性能基準測試。

交付后,需要能夠?qū)崟r的感知節(jié)點故障及定期巡檢,并具備分級處理的自愈能力,例如 Error 級別的故障實現(xiàn)自動排水、重啟,Fault 級別故障實現(xiàn)自動換機。

4. 任務容錯的準召率保障

任務層面穩(wěn)定性最核心的就是做好容錯,能夠讓業(yè)務在無論遇到何種故障時都能快速恢復。那么,首要的工作就是我們能夠準確的識別出異常,然后對故障進行診斷定位,最后能夠自動化的從異常中恢復。因此,任務容錯需要能夠從端側(cè)(即每個訓練 worker)探測到進程與環(huán)境的各類異常,同時有個中心服務(Master)從任務全局的視角去診斷、定位異常,最終做出相應的決策來使任務能夠快速從異常中恢復。

任務容錯最重要的就是提升故障的召回率與準確率,即如何能夠盡可能的準確識別、定位所有故障。我們將故障分類兩類:顯式故障和隱式故障。

顯式的故障通常比較容易召回,我們將實踐積累的各種進程異常狀態(tài)及各類報錯pattern形成專家知識庫,再結(jié)合硬件感知服務(HAS Agent)的硬件全鏈路 10 秒級監(jiān)控能力,可以實現(xiàn)顯式故障的召回率達到 95%+。

隱式的異常則往往很難輕易的識別,例如訓練進程 hang、慢節(jié)點就是典型的隱式故障,需要豐富的經(jīng)驗積累才能準確的識別出異常。

下面我們就以最典型的隱式故障場景 —— 訓練進程 hang 死為例,來看下如何能夠做好 hang 自動感知、診斷。

4.1. 訓練 hang 的自動感知

訓練任務發(fā)? hang 之后,絕?多數(shù)情況都會以 timeout 的?式報錯并退出進程,最常?的就是在通信過程中如果發(fā)? hang,NCCL 的 watchdog 會中斷通信,并有報如下 timeout 報錯,然后再由 pytorch 的 torchrun 進程感知并中斷訓練過程。

[E ProcessGroupNCCL.cpp:828] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802710 milliseconds before timing out.

[E ProcessGroupNCCL.cpp:828] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802713 milliseconds before timing out.

Pytorch 默認為 10 分鐘 NCCL 通信超時,而 Megatron-LM 為 30 分鐘。在萬卡規(guī)模訓練場景中,意味著一萬張卡要至少浪費 30 分鐘才能被發(fā)現(xiàn)。這個時效性是不可接受的。而且當 30 分鐘超時后程序會立馬退出,很難有機會進行下一步定位,需要一些時效性更高的感知機制,并且在程序退出前獲取一些有效信息供后續(xù)診斷分析。

很多公司、實驗室在面對 hang 的問題時,會在采用框架層插樁的方式來 trace 訓練進程,這種方式通常是比較直接且準確的,但是有比較強的侵入性,而且可能還會有一些性能開銷。對于云廠商來說,需要尋找對用戶更透明、更無損的方式來感知、定位 hang 異常。

如何感知訓練 hang,以百度百舸的產(chǎn)品設計思路為例,我們可以從以下幾個方向去思考:

1.訓練進程 hang 的最直觀表現(xiàn)是什么?

人工判斷一個任務是否 hang 了,最直接的方式就是看是否所有 worker 的任務日志一段時間內(nèi)都不輸出日志了,所以 hang 自動感知的第一種方法就是采集所有 worker 的日志,并判斷所有 worker 日志中最后一行日志是否為 x 分鐘前的(x 小于 Pytorch 的通信超時時間,例如 8 分鐘),如果是則基本可以判定為 hang。

2.任務 hang 時進程有什么樣的表現(xiàn)?

任務 hang 時,可能進程的調(diào)用棧都不在發(fā)生變化,進程的調(diào)用?？梢酝ㄟ^ py-spy/pystack 等工具進行探測,所以我們可以用此類工具對所有訓練任務進行一個定時采樣,當采集 n 個樣本所有進程棧都沒有變化時,可以判定一次 hang,這種方式通?？梢詫?hang 感知縮小至 3～5 分鐘。

3.任務 hang 時監(jiān)控指標有哪些變化?

訓練進程中的 CUDA 算子計算、集合通信操作通常都是在毫秒,甚至微秒、納秒內(nèi)完成的,當任務在正常迭代過程中發(fā)生了 hang,我們常遇到的情況是所有 rank 的 RDMA 流量會降到 0,而 GPU 的利用率為 100%、SM 利用率則在很低的水位。如果持續(xù)幾分鐘都是這種狀態(tài)時,意味著訓練進程已經(jīng)計算完成,在等著集合通信完成,這種情況下基本可以判定為 hang。

4.是否能在通信庫中更快的感知通信 hang?

通常單次集合通信操作都是在 ms 級的,如果一次操作在 30 秒鐘都沒有完成,那就可以判定為通信 hang 死了。百度自研的 BCCL 集合通信庫層可以對每一次集合通信操作都進行打點,來實現(xiàn)通信 hang 感知。

上述幾種方法,我們可以分別實現(xiàn)一種探針,來抓取相應的特征到中心端 master 組件進行下一步診斷和容錯決策。

百度集合通信庫 BCCL是百度智能云推出的一款面向大模型訓練場景優(yōu)化的集合通信庫。

BCCL 基于開源的 NCCL 進行了功能擴展和能力增強,針對大模型訓練場景在可觀測性、故障診斷、穩(wěn)定性等方面進行優(yōu)化,進一步提升集合通信庫的可運維能力。相比 NCCL,BCCL 的關鍵特性如下:

* 可觀測性:新增集合通信帶寬實時統(tǒng)計能力;

* 故障診斷:新增集合通信 hang 時的故障診斷能力;

* 穩(wěn)定性:增強網(wǎng)絡穩(wěn)定性和故障容錯能力;

* 性能優(yōu)化:提升大模型訓練主流 GPU 芯片的集合通信性能。

4.2. 訓練 hang 的自動診斷

有了以上感知手段,我們需要進一步的診斷、定位,來確定是否真的發(fā)生了 hang,以及 hang 的具體位置。具體的來講,master 收集到各類 agent 的數(shù)據(jù)后,會做一些綜合分析:

1.是否真的發(fā)生了 hang?感知階段各種探針只能探測到 hang 的一種特征,并沒有辦法 100% 的確定是否真的 hang 住了,事實上不侵入用戶進程是很難做到 100% 確定 hang 的。因此,為了提高 hang 的判定準確率,我們需要將各種特種綜合起來判斷,探針上報到 master 后,由一個 hang 診斷模塊,按照一個時間窗口(例如 5 分鐘),進行綜合判斷。如果在時間窗口內(nèi)日志、監(jiān)控、進程調(diào)用棧、通信庫中有 2 條以上都處于不處于活躍狀態(tài)時,我們判斷任務真正發(fā)生了 hang。

2.hang 的具體發(fā)生的位置?確定任務 hang 了之后,我們需要找到 hang 所在的節(jié)點來對它進行隔離。因此診斷模塊需要在探針上報的數(shù)據(jù)中進一步找尋特征,來確定 hang 發(fā)生的位置:

a.BCCL Tracehang 診斷:在感知階段,BCCL 可以在通信庫層面對所有 rank 的通信進行打點。如果有節(jié)點一直未完成通信則是發(fā)生了 hang。但是此節(jié)點可能并非真正發(fā)生 hang 的源頭,有可能是在等待其他節(jié)點完成通信。診斷模塊可以根據(jù) BCCL 打印的通信組信息,進行交叉判斷,如果某個節(jié)點在多個通信組中都未完成通信,那這個節(jié)點就是 hang 的源頭。

b.RDMA/GPU 指標診斷:上文中我們提到,通信階段發(fā)生 hang 之后,所有 rank 的 RDMA 流量都會降到 0,而同時絕大部分 rank 的 GPU 利用率持續(xù)為 100%,只有某一兩個 rank 的 GPU 利用率為 0,那這個 rank 很有可能是 hang 的源頭。

c.進程調(diào)用棧診斷:進程調(diào)用棧也可以作為一個 hang 源頭診斷的重要參考。當發(fā)生 hang 之后,絕大部分的 rank 都要么處于 barrier 等待狀態(tài),要么處于通信等待階段。只有個別的 rank 卡在其他函數(shù)上,那么通過對比分析,可以將調(diào)用棧與其他 rank 不同的節(jié)點初步判定為 hang 的源頭。

d.綜合診斷:上面 3 種特征為我們提供了 hang 的診斷依據(jù),將 3 者關聯(lián)起來分析后,我們基本上可以比較準確的確定一個具體的 hang 的源頭,再結(jié)合硬件故障感知的相關信息可以進一步明確根因。

4.3.基于 eBPF 的隱式故障感知與診斷在復雜的大規(guī)模分布式訓練場景中,傳統(tǒng)用戶態(tài)監(jiān)控往往難以捕獲系統(tǒng)內(nèi)核層面的異常事件。百度百舸基于 eBPF(Extended Berkeley Packet Filter)技術的隱式故障感知體系,能夠在不侵入用戶代碼的前提下,對訓練進程的系統(tǒng)調(diào)用、網(wǎng)絡通信、CPU 調(diào)度等內(nèi)核態(tài)行為以及訓練框架關鍵函數(shù)運行時間建立立體觀測能力。eBPF 探針部署原理通過在內(nèi)核關鍵路徑注入輕量級探針,實現(xiàn)低開銷的系統(tǒng)級行為捕獲。針對訓練場景特點,主要聚焦 4 類事件跟蹤:

訓練關鍵函數(shù)跟蹤:微秒級跟蹤訓練過程中,前向計算、反向計算、集合通信操作等關鍵函數(shù)執(zhí)行耗時,記錄函數(shù)間調(diào)用關系。

進程調(diào)度阻塞跟蹤:掛鉤 sched_switch 事件,檢測進程在 TASK_UNINTERRUPTIBLE 狀態(tài)持續(xù)時間,當單次持續(xù)超過閾值(如 5 秒)時捕獲調(diào)用棧。

CUDA 運行時 API 監(jiān)控:通過 uprobe 在 libcuda.so 等關鍵庫注入探針,記錄 CUDA API 調(diào)用耗時分布。

RDMA Verbs 級通信監(jiān)控:在 ibv_post_send/ibv_poll_cq 等核心通信接口設置觀測點,統(tǒng)計通信時延分布。

結(jié)合上面 4 類事件,完成以下 2 類數(shù)據(jù)分析:

單體異常探測基線與實時數(shù)據(jù)對比。

群體一致性檢測。采用卡間對比算法,當某一 rank 的以下指標偏離集群中位數(shù)超過閾值時判定異常,包括系統(tǒng)調(diào)用頻率、進程就緒隊列等待時長、NVLink/RDMA 帶寬利用率等。

基于以上所述方法,百度百舸針對以下 2 類典型的隱式故障進行診斷:

訓練 hang 根因定位。通過關聯(lián) eBPF 捕獲的多維度數(shù)據(jù)進行如下操作:

當檢測到某 rank 的 GPU Kernel 執(zhí)行出現(xiàn)分鐘級空跑(SM 利用率 > 70% 但無有效計算輸出)。

同時伴隨該節(jié)點 RDMA QP 狀態(tài)停滯(ibv_poll_cq 無新完成事件)。

內(nèi)核調(diào)度器顯示進程處于 D 狀態(tài)超過閾值。

性能抖動溯源?；?eBPF 火焰圖、時序圖等進行分析:

抓取發(fā)生性能下降時段的 CPU on-cpu/off-cpu 堆棧。

對比正常時段數(shù)據(jù),識別出異常的鎖競爭(futex 調(diào)用占比上升)。

結(jié)合 NUMA 內(nèi)存訪問統(tǒng)計,定位跨 NUMA 內(nèi)存訪問導致的 TLB 顛簸問題。

此類技術已在百度百舸的萬卡規(guī)模訓練集群中驗證,相比單純依賴應用層監(jiān)控的方案,將隱式故障的平均檢測時間從分鐘級縮短至秒級,診斷準確率提升 40% 以上。

通過與既有硬件故障感知服務、BCCL 通信庫監(jiān)測體系聯(lián)動,百度百舸形成了覆蓋從硬件到系統(tǒng)內(nèi)核再到應用層的立體化診斷能力。

5. 任務故障恢復的時效性保障

故障恢復的時效性也是容錯能力的一個重要指標,反映的是任務從故障發(fā)生到再次重新進入訓練迭代的時間,恢復效率越高則算力浪費越少。影響到任務恢復效率有 2 個重要因素,一是任務平均中斷時間,二是訓練重算時間。5.1.多級重啟策略減少故障中斷時間

任務發(fā)生異常后,上文中我們提到需要經(jīng)過故障自動感知、診斷和自愈等 3 個環(huán)節(jié),那么減少中斷時間的核心思想,就是盡可能的縮短這 3 個環(huán)節(jié)的時間,通過多維度的感知、診斷手段可以將故障發(fā)現(xiàn)、定位的時效性降低至分鐘級甚至秒級。自愈則需要能夠根據(jù)不同的診斷結(jié)果進行分級恢復和故障屏蔽的能力:

單點顯式故障:重調(diào)度異常節(jié)點(replace),對節(jié)點進行集群級別屏蔽。

單點隱式故障:重調(diào)度異常節(jié)點,對節(jié)點進行任務級別屏蔽。

非單點故障:原地重啟嘗試恢復(restart),無法恢復時重新調(diào)度所有節(jié)點(resubmit)。

通過多級重啟策略,盡可能避免單點故障引發(fā)全部節(jié)點的重新調(diào)度。在萬卡級別的訓練場景中,百度百舸將大部分訓練異常場景恢復時間從過去的 30min 縮短至現(xiàn)在的 30s 內(nèi),成功率到 95%+。

5.2. 觸發(fā)式 checkpoint 減少訓練重算時間

除了上述的多級任務重啟策略外,另一個提高任務故障恢復效率的重要手段就是減少訓練重算時間。在探討具體技術方案之前,我們先來看看目前主流的 checkpoint 保存策略。

傳統(tǒng)的 checkpoint 保存通常采用固定間隔策略,比如每隔 N 個 step 或每隔 T 小時保存一次,這種方式實現(xiàn)簡單但缺乏靈活性,可能會產(chǎn)生大量冗余存儲,同時在故障發(fā)生時可能會損失較多訓練進度。

而觸發(fā)式 checkpoint 則是一種更智能的方案,它根據(jù)特定條件或異常事件(如故障、顯存不足、顯式指令等)動態(tài)觸發(fā)模型狀態(tài)保存。其核心目標是通過靈活的控制保存時機,減少不必要的存儲開銷和訓練中斷時間,從而降低因頻繁或冗余保存導致的重算時間浪費。

隨著大模型訓練規(guī)模的擴大,還有一種更激進的「零重復 checkpoint」技術,即在每個訓練 step 都保存一次 checkpoint。這種方案的優(yōu)勢在于可以將重算時間降到最低,確保故障發(fā)生時能夠從最近的 step 恢復,幾乎不會損失訓練進度。但其顯著的缺點是存儲開銷巨大,即使采用增量式存儲,仍然需要相當大的存儲空間和 I/O 帶寬。此外,頻繁的 checkpoint 操作也可能影響訓練性能。

相比之下,觸發(fā)式 checkpoint 走的是一條平衡之路。我們來看下它實現(xiàn)的幾個核心要點:

集成容錯:訓練進程集成容錯的故障感知與定位機制,在進程退出前自動觸發(fā)保存。這種主動感知機制能夠在故障發(fā)生的第一時間保存訓練狀態(tài),最大限度減少進度損失。

高速轉(zhuǎn)儲:異步 checkpoint 保存機制會將 checkpoint 暫存到共享內(nèi)存中,再由外部程序轉(zhuǎn)儲至磁盤。當某個節(jié)點異常時,容錯組件會拉起新節(jié)點,并在新節(jié)點訓練進程啟動前,利用 RDMA 技術實現(xiàn) checkpoint 快速從故障節(jié)點轉(zhuǎn)儲至新節(jié)點,這大大減少了從遠程存儲拉取 checkpoint 的時間。

冗余備份:觸發(fā)式 checkpoint 也并非完美無缺,例如在節(jié)點發(fā)生內(nèi)核 crash 等嚴重故障時,可能無法觸發(fā)自動保存。因此,需要通過定期的冗余備份機制進行兜底,確保 checkpoint 不會完全丟失。

實踐表明,當觸發(fā)式 checkpoint 與異步、增量式的 checkpoint 機制結(jié)合使用時,可以在保證數(shù)據(jù)安全性的同時,顯著提高 checkpoint 保存效率,減少訓練重算時間。

相比零重復 checkpoint 的重型方案,觸發(fā)式 checkpoint 提供了一個更實用的折中方案,在合理的存儲開銷下實現(xiàn)較好的容錯效果。當然,具體選擇哪種方案,還需要根據(jù)實際的訓練規(guī)模、硬件條件和可用資源來權(quán)衡。

隨著分布式訓練規(guī)模的持續(xù)增長,相信未來會出現(xiàn)更多創(chuàng)新的 checkpoint 方案,比如基于預測的主動保存策略、多級存儲架構(gòu)的智能調(diào)度等,這些都將為提高大規(guī)模訓練的可靠性提供新的可能。

6.業(yè)務發(fā)展對穩(wěn)定性的要求

AI 訓練的穩(wěn)定性管理已經(jīng)演變?yōu)橹悄軙r代的精密工程。從最初靠人工重啟解決問題的摸索階段,到如今能自動感知異常、快速恢復的智能系統(tǒng),每一次進步都映照著算力規(guī)模的跨越式發(fā)展。

讓人不禁思考,在未來十萬卡集群的算力洪流中,或許會出現(xiàn)更精妙的動態(tài)平衡方案:既能像鷹隼般敏銳捕捉故障征兆,又能如雁群遷移般智能調(diào)度資源,在秒級恢復與 PB 級存儲成本之間找到新的平衡支點。

目前百度百舸支持廠內(nèi)千卡和萬卡集群有效訓練時長已經(jīng)可達 99.5%,為客戶大模型的預訓練保駕護航,比如國內(nèi)第一個數(shù)學大模型——九章算術,國內(nèi)第一個類 Sora 大模型 —— Vidu 等。

（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）