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