簡介《2025年中國人工智能計(jì)算力發(fā)展評估報(bào)告》為IDC出品的行業(yè)研究PDF面向政策制定者、企業(yè)管理者、研究人員及投資者幫助把握生成式人工智能驅(qū)動下的算力需求變化與產(chǎn)業(yè)趨勢。資源包共1個(gè)PDF文件約2.02MB內(nèi)容結(jié)構(gòu)完整涵蓋全球及中國人工智能發(fā)展概述、算力及應(yīng)用、發(fā)展評估與IDC建議四大板塊。報(bào)告圍繞算力效能提升、芯片與服務(wù)器高性能演進(jìn)、存儲與網(wǎng)絡(luò)優(yōu)化、可持續(xù)數(shù)據(jù)中心建設(shè)及邊緣計(jì)算擴(kuò)展五大趨勢展開并深入分析液冷技術(shù)、智能算力服務(wù)中心、算法創(chuàng)新與模型迭代對算力效率的關(guān)鍵作用。目錄中行業(yè)排名與地域排名、大模型開源趨勢、企業(yè)擴(kuò)容與提效并行策略等內(nèi)容可為讀者提供數(shù)據(jù)支撐與決策參考。目前已有253人學(xué)習(xí)下載適合需要系統(tǒng)了解中國智能算力規(guī)模預(yù)測與產(chǎn)業(yè)落地路徑的讀者研讀。1. 算力賬本怎么算從一份評估報(bào)告看2025年AI基礎(chǔ)設(shè)施的真實(shí)水位2025年中國人工智能計(jì)算力發(fā)展評估報(bào)告這類標(biāo)題很多人第一反應(yīng)是宏觀材料跟我寫代碼的沒關(guān)系。但如果你正在做模型訓(xùn)練排期、推理服務(wù)擴(kuò)容或者被老板問我們到底缺多少卡這份報(bào)告背后的評估框架其實(shí)是一本算力賬本。它要回答的核心問題是一個(gè)區(qū)域、一個(gè)行業(yè)、一家公司當(dāng)前的人工智能計(jì)算力供給與需求之間差多少瓶頸在芯片、在機(jī)房、還是在調(diào)度效率。適合三類人看做基礎(chǔ)設(shè)施規(guī)劃的、做模型訓(xùn)練成本估算的、以及需要向非技術(shù)決策者解釋為什么還要加預(yù)算的工程師。這篇筆記不逐條復(fù)述報(bào)告而是把評估邏輯拆成可復(fù)現(xiàn)的測算流程讓你能用自己的數(shù)據(jù)套一遍。2. 評估框架拆解算力供給、需求與效率三個(gè)口徑怎么定2.1 為什么不能只看GPU卡數(shù)算力評估最容易翻車的地方是把有多少張加速卡直接等同于有多少計(jì)算力。實(shí)際有效算力要打三層折扣第一層是硬件利用率卡在集群里不可能7×24跑滿通信等待、數(shù)據(jù)加載、檢查點(diǎn)寫入都會吃掉時(shí)間第二層是精度折算同一張卡跑FP32和跑FP16、INT8的吞吐差好幾倍評估時(shí)必須聲明口徑第三層是任務(wù)匹配度拿訓(xùn)練卡去跑小批量推理利用率可能連20%都不到。常見做法是定義一個(gè)有效算力當(dāng)量以某一種精度比如FP16為基準(zhǔn)把不同精度的峰值算力按實(shí)測吞吐比例折算再乘以集群平均利用率。這個(gè)當(dāng)量才是能拿去做供需對比的數(shù)字。我一般會建議團(tuán)隊(duì)先跑一周的集群監(jiān)控拿到真實(shí)的MFU模型浮點(diǎn)運(yùn)算利用率而不是用廠商標(biāo)稱峰值。2.2 需求側(cè)的三個(gè)來源需求不是拍腦袋估的要拆成三塊分別算。第一塊是存量業(yè)務(wù)的推理需求按當(dāng)前QPS、平均序列長度、模型參數(shù)量反推每日浮點(diǎn)運(yùn)算次數(shù)第二塊是增量訓(xùn)練需求按計(jì)劃中的訓(xùn)練任務(wù)數(shù)、每個(gè)任務(wù)的token量、訓(xùn)練輪次估算第三塊是預(yù)留緩沖通常留15%到30%應(yīng)對突發(fā)流量和實(shí)驗(yàn)性任務(wù)。下面這段Python是一個(gè)簡化的需求估算腳本輸入業(yè)務(wù)側(cè)的幾個(gè)可觀測指標(biāo)輸出每日算力需求單位PFLOPS·天。# 簡化算力需求估算推理 訓(xùn)練 緩沖 # 所有算力單位統(tǒng)一為 PFLOPS每秒千萬億次浮點(diǎn)運(yùn)算 def inference_demand(qps, seq_len, params_b, hours_per_day24): qps: 每秒查詢數(shù) seq_len: 平均序列長度token params_b: 模型參數(shù)量十億 推理一次前向約 2 * params 次浮點(diǎn)運(yùn)算乘加各算一次 flops_per_query 2 * params_b * 1e9 * seq_len daily_flops qps * flops_per_query * 3600 * hours_per_day return daily_flops / 1e15 # 轉(zhuǎn)成 PFLOPS·天 def training_demand(tasks_per_month, tokens_per_task, params_b, epochs1): 訓(xùn)練一次約 6 * params * tokens 次浮點(diǎn)運(yùn)算前向反向 flops_per_task 6 * params_b * 1e9 * tokens_per_task * epochs monthly tasks_per_month * flops_per_task return monthly / 30 / 1e15 # 平均到每天 def total_demand(qps, seq_len, params_b, tasks, tokens, buffer0.2): inf inference_demand(qps, seq_len, params_b) tr training_demand(tasks, tokens, params_b) return (inf tr) * (1 buffer), inf, tr total, inf, tr total_demand(qps500, seq_len1024, params_b13, tasks8, tokens2e9, buffer0.25) print(f推理需求 {inf:.2f} PFLOPS·天訓(xùn)練需求 {tr:.2f} PFLOPS·天) print(f含25%緩沖后總需求 {total:.2f} PFLOPS·天)邏輯說明推理側(cè)用2×參數(shù)量×序列長度近似單次前向計(jì)算量這是行業(yè)里常用的粗估方式誤差在可接受范圍內(nèi)訓(xùn)練側(cè)用6×參數(shù)量×token數(shù)系數(shù)6來自前向2次加反向4次的經(jīng)典估算。參數(shù)怎么改qps和seq_len從網(wǎng)關(guān)日志取P95值而不是均值params_b按實(shí)際部署模型填buffer根據(jù)業(yè)務(wù)波動性在0.15到0.3之間調(diào)。注意這個(gè)腳本算的是天級別的量如果要換算成需要多少張卡還要除以單卡日有效算力和集群利用率。2.3 效率口徑把PUE和MFU分開看評估報(bào)告里常出現(xiàn)兩個(gè)效率指標(biāo)容易被混為一談。PUE是機(jī)房層面的電能利用效率衡量制冷和配電損耗跟計(jì)算本身無關(guān)MFU是計(jì)算層面的利用率衡量芯片實(shí)際干了多少活。一個(gè)機(jī)房PUE很漂亮但MFU很低說明電沒浪費(fèi)在制冷上卻浪費(fèi)在空轉(zhuǎn)上。做評估時(shí)這兩個(gè)要分開列否則優(yōu)化方向會搞錯(cuò)——PUE高去改制冷MFU低去改調(diào)度和并行策略。3. 用公開數(shù)據(jù)跑一遍區(qū)域算力供需測算3.1 數(shù)據(jù)從哪來、怎么對齊口徑做區(qū)域級測算數(shù)據(jù)來源通常有三類公開的統(tǒng)計(jì)材料、廠商披露的產(chǎn)品規(guī)格、以及自己監(jiān)控系統(tǒng)的一手?jǐn)?shù)據(jù)。三類數(shù)據(jù)口徑往往不一致比如統(tǒng)計(jì)材料給的是標(biāo)準(zhǔn)機(jī)架數(shù)廠商給的是單卡峰值算力自己監(jiān)控給的是實(shí)際任務(wù)吞吐。對齊方法是建一張換算表把不同來源統(tǒng)一到有效算力當(dāng)量這一個(gè)口徑上。數(shù)據(jù)來源原始口徑換算動作目標(biāo)口徑統(tǒng)計(jì)材料標(biāo)準(zhǔn)機(jī)架數(shù)按機(jī)架功率和典型部署密度折算卡數(shù)加速卡數(shù)量廠商規(guī)格單卡峰值算力乘實(shí)測MFU按精度折算有效算力當(dāng)量監(jiān)控系統(tǒng)任務(wù)吞吐按任務(wù)類型加權(quán)平均有效算力當(dāng)量機(jī)房臺賬總功耗除以PUE得IT功耗供電約束上限這張表的作用是防止你把蘋果和橘子相加。我見過一個(gè)團(tuán)隊(duì)把標(biāo)稱峰值直接加總得出算力充足的結(jié)論結(jié)果實(shí)際訓(xùn)練排隊(duì)排了兩周就是因?yàn)闆]做精度和利用率折算。3.2 測算腳本從卡數(shù)到可用算力下面這段腳本把卡數(shù)、精度、利用率三個(gè)輸入轉(zhuǎn)成可用算力當(dāng)量再和上一節(jié)的需求做對比輸出缺口。# 供給側(cè)測算從卡數(shù)到有效算力當(dāng)量 # 假設(shè)以 FP16 為基準(zhǔn)精度 # 不同精度相對 FP16 的吞吐系數(shù)經(jīng)驗(yàn)值需按實(shí)測校準(zhǔn) PRECISION_FACTOR { FP32: 0.5, FP16: 1.0, INT8: 1.8, INT4: 2.5, } def effective_supply(card_count, peak_tflops_fp16, precision, mfu): card_count: 加速卡數(shù)量 peak_tflops_fp16: 單卡FP16峰值算力TFLOPS precision: 實(shí)際主要使用的精度 mfu: 實(shí)測模型浮點(diǎn)運(yùn)算利用率0~1 factor PRECISION_FACTOR[precision] per_card peak_tflops_fp16 * factor * mfu # TFLOPS total card_count * per_card # 轉(zhuǎn)成 PFLOPS·天TFLOPS * 86400秒 / 1e3 return total * 86400 / 1e3 def gap(supply, demand): return supply - demand supply effective_supply(card_count2000, peak_tflops_fp16312, precisionFP16, mfu0.35) demand 4200 # 來自上一節(jié)測算的示例值 print(f有效供給 {supply:.0f} PFLOPS·天需求 {demand} PFLOPS·天) print(f缺口 {gap(supply, demand):.0f} PFLOPS·天)邏輯說明單卡有效算力等于峰值乘以精度系數(shù)再乘以MFU這個(gè)乘積才是能真正用于任務(wù)的部分。參數(shù)怎么改peak_tflops_fp16按實(shí)際采購型號填mfu建議用集群監(jiān)控里連續(xù)一周的均值precision按主力任務(wù)的實(shí)際精度填。如果算出來缺口是負(fù)的說明供給不足接下來要么加卡要么提MFU要么把部分任務(wù)遷到別的精度上跑。失敗時(shí)看什么如果結(jié)果和直覺差距很大先檢查mfu是不是填成了理論值再檢查精度系數(shù)是不是用錯(cuò)了檔位。3.3 把結(jié)果翻譯成決策語言測算結(jié)果不能只給一個(gè)數(shù)字要翻譯成決策者能用的選項(xiàng)。缺口是X PFLOPS·天對應(yīng)三種動作加卡需要多少張、提效需要把MFU從多少提到多少、或者調(diào)整任務(wù)結(jié)構(gòu)能省多少。我一般會做一張三列對比表把每種動作的成本、周期、風(fēng)險(xiǎn)列清楚讓決策者選而不是讓工程師替他們選。4. 避坑與排查算力評估里最容易翻車的五個(gè)地方4.1 現(xiàn)象評估結(jié)論是算力充足實(shí)際訓(xùn)練卻排隊(duì)原因把標(biāo)稱峰值直接加總沒有乘MFU和精度系數(shù)。廠商標(biāo)稱的是理論峰值實(shí)際任務(wù)跑不到那個(gè)數(shù)。解決所有供給數(shù)據(jù)必須過一遍有效算力當(dāng)量公式MFU用實(shí)測值沒有實(shí)測就先跑一周監(jiān)控再評估。4.2 現(xiàn)象需求估算每月偏差超過50%原因用均值QPS而不是P95且沒有區(qū)分推理和訓(xùn)練。均值會嚴(yán)重低估峰值壓力混在一起算則無法定位瓶頸。解決推理需求用P95 QPS訓(xùn)練需求單獨(dú)列兩者分別和供給對比不要合并成一個(gè)總數(shù)。4.3 現(xiàn)象加了卡但訓(xùn)練速度沒提升原因瓶頸不在算力在通信或數(shù)據(jù)加載。加卡后通信開銷線性增長如果并行策略沒調(diào)MFU反而下降。解決加卡前先看監(jiān)控里的通信占比和數(shù)據(jù)加載等待時(shí)間如果這兩項(xiàng)超過30%先優(yōu)化這兩塊再加卡。4.4 現(xiàn)象PUE優(yōu)化了但電費(fèi)沒降原因PUE只反映機(jī)房效率如果MFU很低大部分電耗在空轉(zhuǎn)上優(yōu)化制冷省下的電被空轉(zhuǎn)吃掉了。解決PUE和MFU一起看先提MFU再降PUE順序反了效果不明顯。4.5 現(xiàn)象評估報(bào)告的數(shù)據(jù)和實(shí)際監(jiān)控對不上原因口徑?jīng)]對齊統(tǒng)計(jì)材料按機(jī)架算監(jiān)控按任務(wù)算中間缺換算環(huán)節(jié)。解決建一張口徑換算表所有數(shù)據(jù)進(jìn)評估前先過表換算系數(shù)定期用實(shí)測校準(zhǔn)。5. 進(jìn)階技巧把一次性評估變成持續(xù)監(jiān)控的算力水位線評估報(bào)告是快照但算力供需是動態(tài)的。我后來養(yǎng)成的習(xí)慣是把第3節(jié)的測算腳本包成一個(gè)定時(shí)任務(wù)每天凌晨跑一次把有效供給、需求、缺口三個(gè)數(shù)寫進(jìn)時(shí)序庫再用一個(gè)簡單的閾值告警缺口連續(xù)三天為負(fù)就觸發(fā)擴(kuò)容評審MFU連續(xù)一周低于基線就觸發(fā)調(diào)度優(yōu)化評審。下面是一個(gè)最小化的持續(xù)監(jiān)控腳本骨架用cron每天跑一次輸出到本地文件方便接任何時(shí)序庫。# 每日算力水位線快照建議用cron在凌晨低峰期執(zhí)行 import json, datetime def daily_snapshot(): supply effective_supply(card_count2000, peak_tflops_fp16312, precisionFP16, mfu0.35) demand 4200 record { date: datetime.date.today().isoformat(), supply_pflops_day: round(supply, 1), demand_pflops_day: demand, gap: round(supply - demand, 1), mfu: 0.35, } with open(compute_waterline.jsonl, a) as f: f.write(json.dumps(record) \n) return record if __name__ __main__: print(daily_snapshot())邏輯說明每天追加一行JSON到文件字段包括日期、供給、需求、缺口、MFU。參數(shù)怎么改card_count和mfu從監(jiān)控系統(tǒng)拉取而不是寫死demand從業(yè)務(wù)側(cè)接口獲取。這個(gè)骨架的價(jià)值在于把評估從一年一次的大作業(yè)變成每天看一眼的水位線缺口趨勢比單點(diǎn)數(shù)字更有決策價(jià)值。驗(yàn)證方法連續(xù)跑兩周后把缺口和實(shí)際排隊(duì)時(shí)長做相關(guān)性分析如果相關(guān)性高說明測算口徑可信如果相關(guān)性低回去檢查需求側(cè)是不是漏了某類任務(wù)。我自己的血淚經(jīng)驗(yàn)是第一版測算往往漏掉實(shí)驗(yàn)性任務(wù)導(dǎo)致需求低估后來把實(shí)驗(yàn)任務(wù)按存量訓(xùn)練的20%單獨(dú)加了一項(xiàng)才對齊。一個(gè)具體技巧給缺口設(shè)兩條線黃線是缺口小于供給的10%觸發(fā)優(yōu)化評審紅線是缺口為負(fù)觸發(fā)擴(kuò)容評審。兩條線分開避免一有波動就喊加卡。這個(gè)習(xí)慣幫我省過好幾次不必要的采購申請。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取