當以“降本”聞名的馬斯克對外公佈由 10 萬個液冷 H100 GPU 組成的超大叢集,並宣佈未來幾個月內還要再增加 10 萬顆 GPU 時,業界對 AI 基礎設施的衡量標準,一時間變得有些單一——大家更傾向於對比卡的數量,而對叢集效能,尤其是特定業務場景下的效能表現,考量不足。
2025 年甫一開年,DeepSeek 就大幅降低了預訓練成本,繼而在 3 月份,螞蟻 Ling 團隊給出了基於國產算力的新成本最佳化方案,2025 國產的 GenAI 的主題顯然是極為務實的。這種務實的背景是,國內的 AI 應用市場,正處於爆發中,即將到來的是無數挑戰傳統 SaaS 的 AI 原生應用,以及被智慧程式設計武裝起來的“超級團隊”。
這些應用和團隊需要的是,更有針對性的算力基礎設施,更靈活的算力獲取方式,更安全可靠的算力獲取保障,針對訓推一體和多模態資料的全域性最佳化。
算力規模的擴充套件當然是必需的,也是當下算力開支的主要方向。但在規模問題之外,更緊迫的問題是對基建整體效能的調優。
這事兒聽起來沒有“堆卡”震撼,但難度卻絕不容小覷——這要求頭部雲廠商,必須開始著手翻新整個基礎設施。
實際上,這種翻新也是有明確“偏好”的,其中最顯眼的部分來自 GTC 2025 ,黃仁勳話裡話外的意思是:整個 AI 產業正在經歷結構性的轉變——從做基礎模型預訓練,轉向推理業務。曾經在大模型預訓練這條賽道上,搶下行業接近 90% 利潤的英偉達, 如今認為,在 2028 年的智算中心預算支出裡,推理晶片需求佔比將達 70%。
造成這種轉變的原因主要有兩個:一是可供大模型做預訓練的公開資料有限,行業內公開的、深度的資料合作還很少,導致做預訓練的規模受限;二是行業已經從“百模大戰”的階段,進入“AI 應用落地”階段,對推理的需求大幅增加。據 Omdia 在 2024 年年中預測,全球生成式 AI 軟體收入在 2024 年增長 124%,複合年增長率將達到 53%。
這其中包含了從 ChatBot 形態的簡單推理業務,過渡到覆蓋智慧駕駛、具身智慧、端側智慧等對模型推理表現要求更高的業務場景。
對企業而言,主要是解決四個關鍵問題:
-
如何讓大模型的冷啟動更快些 -
如何讓推理的速度更快些 -
如何支撐推理業務的流量洪峰 -
如何進一步降低網路成本和儲存成本

據官網介紹,PAI 是阿里雲專為開發者打造的一站式機器學習平臺,主要由視覺化建模(Designer)、互動式建模(DSW)、分散式訓練(DLC)、模型線上服務(EAS)等核心功能模組組成。簡單理解就是,PAI 解決的是 AI 落地問題,AI 開發在基礎設施搭建、工具框架部署、運維合規等方面的複雜工作,幫助企業從 0 到 1 開發、訓練、部署、推理一個模型服務,與 AWS SageMaker、Google Vertex AI 相似。
而 PAI 則是透過全新的模型權重服務來解決大模型冷啟動,以及提升擴容效率、應對流量洪峰的問題;透過分散式推理引擎 Llumnix 以及流量感知的 PD 分離推理服務共同完成推理加速,最後透過提升 KV Cache 的命中率,來進一步降本。
模型權重服務,簡單來說就是圍繞模型權重進行管理、儲存、分發等操作的一系列服務。模型在首次啟動或長時間未使用後重新啟動時,需要載入模型權重並準備好進行推理,也就是模型的“冷啟動”。所謂“全新模型權重服務”,和冷啟動效率的提升關係頗大。
根據本次釋出,阿里雲官方給出的最佳化成績是:縮短大引數模型冷啟動時間,0 到 100 節點冷啟動加速 21X;50 到 100 節點擴容加速 12X;降低模型儲存側網路壓力,減少頻寬成本。
而分散式推理引擎 Llumnix,看起來是對標 NVIDIA 開源的 Dynamo 推理框架。Llumnix 透過跨模型例項的請求執行時重新排程來解決 LLM 推理服務中的負載均衡、資源碎片化、優先順序區分等問題,透過高效可擴充套件的即時遷移技術來遷移請求及其記憶體狀態。用一句話總結就是, Llumnix 可以直接影響終端感受到的推理速度。

當然,改善 TPOT 資料表現是一個複合型工程,PD 分離的技術實現情況,也必須被納入計算。
大模型推理可以籠統分為 Prefill(預填充)階段和 Decode(解碼)階段,前者處理使用者輸入的 prompt,生成 KV 快取(Key-Value Cache),屬於計算密集型任務,需要高並行度和視訊記憶體頻寬;後者基於 KV 快取逐 Token 生成輸出,屬於儲存密集型任務,依賴低延遲的視訊記憶體訪問和高效的批處理排程。
傳統操作方式是允許兩階段在同一 GPU 叢集執行,但資源爭搶會導致吞吐下降和長尾延遲增加。例如,prefill 階段佔用大量算力時,decode 階段的即時生成能力會被擠壓。
所謂 PD 分離,就是對 Prefill(預填充)階段和 Decode(解碼)階段進行隔離,分別進行資源排程。但僅實現預填充與解碼階段的物理資源隔離也不夠好,這缺乏動態調整能力,容易導致預填充叢集空閒時解碼任務無法搶佔資源。
所以阿里雲本次釋出的是 PAI-EAS 多機 PD 分離部署架構,其核心在於透過分層排程與動態資源協同實現更高效的算力利用和延遲控制,給出的答卷是端到端服務吞吐提升 91%。

這裡涉及到兩個關鍵元件:LLM Gateway,LLM Scheduler。前者作為全域性流量入口,負責請求的協議轉換(REST/GRPC)和負載均衡。後者專為多模態大模型設計的協議適配層,支援文 / 圖 / 影片輸入的混合解析,並透過請求分片技術將長文字拆解為多段並行預填充(Prefill),解決單機視訊記憶體不足的問題。
預填充任務在多機 GPU 上並行生成 KV Cache,並透過 RDMA 網路同步至解碼叢集,並在解碼階段透過動態批處理(Dynamic Batching)聚合多個請求,共享 KV Cache。
而所謂流量感知,是指系統能夠即時監測和分析網路流量或請求流量的情況,讓智慧路由更智慧一些。
這裡出現的 KV Cache,也是個熱門概念。實際上,KV Cache 是 Transformer 架構的核心元件,已成為突破大模型推理效能瓶頸、最佳化服務經濟性的關鍵基礎設施。
原本 KV Cache 的視訊記憶體佔用會隨上下文長度線性增長,但 Transformer 架構本來就包含自迴歸生成時的重複計算,因此留有很大的最佳化空間。
阿里雲這次釋出對 KV Cache 做了進一步升級,提升了請求排程效率,使千萬級活躍使用者場景下, KV Cache 命中率提升 10X。
然而,對於雲計算而言,脫離計算、網路、儲存這“三大件”去談推理加速屬於“空中樓閣”,而阿里雲強化 AI 基礎設施的核心落腳點是靈駿叢集。
靈駿叢集的主要關注點,仍然是“三大件”,但在側重場景上,卻出現了很大的變化,其中最主要的變數,仍然是從預訓練轉向推理場景後,構建在 IaaS 層之上的業務場景變化很大。
與預訓練業務更偏好高算力 GPU 相比,推理業務更偏好高視訊記憶體頻寬 GPU,儲存也需分級快取,結合物件儲存(如 OSS)實現冷熱分層。同時也需要算力本身有一定自愈能力,避免對業務造成影響。
在網路層面,預訓練業務的需求可以總結為:對吞吐量的要求高,尤其是張量並行通訊頻寬,但對延遲不敏感,可以接受分鐘級的延遲。而推理業務對延遲非常敏感,很多場景都是即時互動,比如自動駕駛決策,且需要應對突發性高併發要求。
至於儲存,推理業務更看重對資料訪問模式的最佳化,以及記憶體視訊記憶體直連最佳化,對能效比也更為敏感。
阿里雲靈駿叢集是支援超大規模 AI 訓練與推理的智算基礎設施,可提供超大規模、超強效能的智慧算力,靈駿叢集透過 HPN7.0 高效能網路架構可實現單叢集 10 萬張 GPU 卡互聯,萬卡規模下效能線性度可以達到 96%。
在伺服器層面,阿里雲採用磐久 AI 計算伺服器,單臺伺服器支援 8-16 張 GPU 卡,配備 3.2Tb/s RDMA 網路與 400Gb/s 儲存訪問網絡卡,滿足大規模緊耦合計算需求。GPU 例項透過硬體級最佳化(如視訊記憶體頻寬提升、計算指令集加速)實現 MFU(Model FLOPs Utilization)提升 20% 以上。
在 4 月 9 日的 AI 基礎設施大會上,能看到靈駿叢集的各項資料又有更新,主要是圍繞 AI 負載進行最佳化,包括整合計算(GPU 叢集、磐久伺服器)、網路(HPN)、儲存(CPFS)硬體,搭配統一資源池、全域性排程等軟體模組,以形成高可靠、高效能的雲超級計算機。
具體包括:
● EBS:靈駿支援塊儲存,快速叢集擴縮容
● CPFS:單客戶端吞吐提升至 40GB/s
● VPC:VPC 頻寬能力全面升級,提升至 200Gbps
● HPN 最佳化:支援 IPV6,全面支援多路徑能力,最佳化專家並行的網路通訊效能(效能提升 25%)
● 最佳化故障自愈系統:透過 PAI AI Master、AI Task、AI Cluster 與靈駿故障自愈系統、運維監控系統聯動,提升系統穩定性與算力利用率。

涵蓋了網路、儲存和系統穩定性問題,可見阿里雲圍繞算力有效利用率做了較多工作。
在網路能力的最佳化方面,靈駿採用多路徑並行傳輸與 IPV6 通訊域擴充套件,顯著提升了跨 Segment 的任務處理效率。這顯然與今年 AI 應用出海的大趨勢是相互呼應的。
在儲存方面, CPFS 迎來了升級。
在架構層面,CPFS 採用高效能並行架構,升級了全鏈路 RDMA 技術、容量效能水平擴充套件、CIPU 硬體加速隔離、全分散式元資料管理、彈性多租 Serverless 化。而且 CPFS 在 端側快取和分層儲存有許多最佳化成績,包括:彈性檔案客戶端 EFC 支援分散式快取(藉助 GPU 記憶體 / 本地盤加速)、支援 KVCache 儲存、與 OSS 資料流動(Tb 級頻寬)、分層儲存。
同時,阿里雲 CPFS 檔案儲存系統經全鏈路最佳化,單客戶端吞吐性達到 40GB/s,單計算節點快取吞吐 15GB/s,配合目錄級許可權控制,在保障模型訓練速度的同時實現企業級資料隔離,為大規模 AI 訓練提供了高效的儲存支援。
阿里雲的 CPFS、KV Cache 已經形成了架構上的協同效應——CPFS 以 TB 級吞吐量將模型引數載入至 KV Cache,KV Cache 提供即時 K/V 向量,減少 GPU 視訊記憶體佔用,最後將推理結果非同步落盤至 CPFS,支援冷熱分層。
除此之外,OSS 物件儲存服務的最佳化也同樣值得關注。
阿里雲 OSSFS 2.0 在單執行緒讀取 100GB 檔案場景中實現吞吐效能提升 7.65 倍,Qwen-2.5-72B 超大規模模型的資料拉取速度提升 7.73 倍,意味著儲存層與 AI 算力的協同最佳化進入了一個新階段。
同時,資源池 QoS 新增的 BucketGroup 流控能力,實現多 Bucket 業務分組池化管理,將儲存資源管理粒度從單點擴充套件至業務單元。
這也契合企業混合雲架構下儲存資源集約化運營的趨勢,尤其適用於需要跨地域協同的全球化 AI 訓練場景。
從地區覆蓋來看,新加坡成為繼北京、上海等核心節點後第五個具備 100Gbps 預設讀吞吐能力的地域。隨著東南亞成為 AI 晶片供應鏈關鍵節點,該地域的儲存頻寬升級可直接支撐 10 萬卡級 GPU 叢集的併發資料訪問需求。結合 OSS 加速器產品吞吐密度提升 50%、最大效能達 100GBps 的能力,阿里雲正在構建覆蓋訓練、推理、邊緣計算的全球資料高速公路,為多模態大模型、自動駕駛等場景提供跨地域資料協同的基礎支撐。
阿里雲 OSS 的升級某種程度上揭示了雲端儲存的進化方向:從被動承接資料儲存轉向主動參與計算最佳化。OSSFS 2.0 的突破驗證了"儲存即服務"向"儲存即算力"的正規化轉換,而 BucketGroup 流控則是進一步加強精細化運營的思想體現。
整體來看,靈駿智算叢集和人工智慧平臺 PAI,已經成為阿里雲支撐 AI 推理需求和 AI 應用落地的樞紐,阿里雲甚至還在結合自己對客戶業務的理解,繼續將這種優勢外擴,使之也蔓延到了算力高可用、網路安全等其他領域。
要服務好 AI 應用落地這一宏觀趨勢,在效能層面滿足業務要求,通常是 ToB 業務的准入門檻,能在多大程度上做好高可用以及安全合規服務,對最終業務落地也有較大影響。
由於跟客戶走得足夠近,雲計算企業的嗅覺都很敏銳,因此對算力高可用的關注也比較及時。
在萬億引數模型訓練成為行業標配的今天,對服務可用性的要求已從 99.9% 的常規標準,進化為毫秒級響應 + 零故障容忍”的雙重閾值。從雲服務層面,避免單節點故障造成的推理中斷,已經是個必選項,不然成本會高到客戶無法忍受。
而這種算力高可用的強需求,主要體現在算力高可用、即時資料同步、動態擴充套件性等多個方面。
具體來說,MoE 模型的分散式架構需要雲計算平臺具備跨地域冗餘儲存和智慧流量排程能力,確保單點故障時專家模組的無縫切換,同時需要支援彈性資源分配以應對突發負載,並透過細粒度快照技術實現模型狀態與訓練資料的即時備份;此外,雲計算平臺還需要高效的故障檢測與自動化恢復機制,並結合增量備份策略,最小化災難場景下的服務中斷時間和資料丟失風險,從而保障大規模 AI 服務連續性。
另一項關乎業務連續性的重要課題是網路安全,在 GenAI 時代,發動一場網路攻擊的成本足夠低,但危害足夠大,共同導致網路安全事件的頻發。

業內構建並維護萬卡叢集的共識是,要求其像“一張卡”一樣對外提供服務。但在今天看起來,這是個很粗暴,也很“浪漫主義”的說法。
點選閱讀原文,關注飛天釋出時刻,及更多精彩釋出內容