解讀：訓練推理拆分、有效算力折算與容量規(guī)劃)
簡介《2025年中國人工智能計算力發(fā)展評估報告》由IDC數(shù)據(jù)支撐面向政策制定者、企業(yè)管理者、研究人員及投資者幫助把握生成式人工智能驅動下的算力需求變化與產(chǎn)業(yè)趨勢。資源為1個PDF文件壓縮包約2.02MB內容涵蓋全球及中國人工智能發(fā)展概述、算力及應用、發(fā)展評估與IDC建議四大板塊目錄結構清晰便于按章節(jié)檢索。報告系統(tǒng)梳理了算力五大趨勢提升算力效能、芯片與服務器高性能演進、存儲與網(wǎng)絡優(yōu)化、可持續(xù)數(shù)據(jù)中心建設及邊緣計算擴展并深入分析液冷技術、智能算力服務中心、開源大模型普及等焦點議題。讀者可從中獲取2025年中國智能算力規(guī)模預測、行業(yè)與地域排名、企業(yè)擴容與提效并行策略等關鍵結論為制定人工智能發(fā)展規(guī)劃、研判技術政策走向提供參考。目前已有253人學習下載。1. 算力評估報告背后一線工程師該怎么讀、怎么用2025 年各類人工智能計算力發(fā)展評估報告陸續(xù)出爐圈子里討論最多的不是排名本身而是「算力賬到底怎么算」。我在某實驗室做推理集群的容量規(guī)劃每年這類報告出來都要逐頁拆一遍——不是為了看誰排第一而是為了搞清楚三件事訓練卡和推理卡的比例怎么定、國產(chǎn)芯片在真實業(yè)務里的有效算力打幾折、以及明年采購預算該往哪個方向壓。這份評估報告類的材料本質上是一份行業(yè)級的「算力體檢表」它把芯片供給、服務器出貨、智算中心上架率、行業(yè)滲透度這些指標串成一條鏈。對做基礎設施、模型部署、預算規(guī)劃的工程師來說它解決的是「我手里的集群在行業(yè)里處于什么水位、下一步該補哪塊短板」的問題。適合誰讀做智算中心運營的、管推理成本的、寫算力采購方案的以及需要向非技術管理層解釋「為什么還要加卡」的人。下面我按自己拆報告的習慣把這份材料從讀法到落地講透。2. 拆解評估報告的四個核心指標從算力口徑到有效利用率2.1 訓練算力與推理算力為什么要分開算很多報告把「智能算力規(guī)?！够\統(tǒng)寫成一個總數(shù)單位是 EFLOPSFP16 或 INT8 口徑但一線做規(guī)劃的人必須把它拆成訓練和推理兩條線。原因很直接訓練卡追求的是互聯(lián)帶寬和顯存容量推理卡追求的是單位功耗下的吞吐和延遲。一張卡在訓練集群里可能因為通信瓶頸只能發(fā)揮 60% 的標稱算力放到推理場景里做 batch 推理反而能跑到 85%。我一般會按下面這個口徑去還原報告里的數(shù)字# 把報告里的總算力拆成訓練/推理兩條線 # 假設報告給出智能算力總規(guī)模 total_eflops訓練占比 train_ratio total_eflops 320.0 # 示例報告口徑下的 FP16 智能算力 train_ratio 0.55 # 訓練側占比需從報告分項里反推 infer_ratio 1 - train_ratio train_eflops total_eflops * train_ratio infer_eflops total_eflops * infer_ratio # 有效算力折算訓練按 0.55~0.65推理按 0.75~0.85 train_effective train_eflops * 0.60 infer_effective infer_eflops * 0.80 print(f訓練有效算力: {train_effective:.1f} EFLOPS) print(f推理有效算力: {infer_effective:.1f} EFLOPS)這段代碼的邏輯是報告給的永遠是標稱峰值而實際可用算力要乘一個「有效率」。訓練側有效率低是因為大規(guī)模并行時 AllReduce 通信、checkpoint 寫入、故障重啟都在吃時間推理側有效率相對高但受限于顯存帶寬和調度碎片。參數(shù)怎么定訓練有效率我通常取 0.55 到 0.65集群規(guī)模越大越往低取推理有效率取 0.75 到 0.85如果業(yè)務是長上下文場景要再降 10 個點。報告里如果只給了總數(shù)沒給拆分比例就去翻它的分項章節(jié)通常會有「訓練/推理」或「智算/通算」的拆分表。2.2 國產(chǎn)芯片的有效算力折算系數(shù)怎么取評估報告里國產(chǎn)芯片的份額是繞不開的一段。但報告寫的是「出貨量占比」或「算力占比」這兩個數(shù)差別很大。出貨量占比高不代表算力占比高因為單卡算力密度不同。我在做替代方案評估時會單獨建一張折算表指標含義常見取值區(qū)間對規(guī)劃的影響標稱算力廠商標稱 FP16 峰值按具體型號僅作上限參考實測算力典型模型下的穩(wěn)定值標稱的 50%~70%決定真實吞吐生態(tài)折算框架適配成熟度0.6~0.9影響遷移成本綜合有效系數(shù)三者相乘0.3~0.6用于容量規(guī)劃這張表的關鍵在最后一行的「綜合有效系數(shù)」。我見過太多方案直接拿標稱算力做容量規(guī)劃結果上線后吞吐只有預期的一半血淚經(jīng)驗就是國產(chǎn)卡在早期適配階段綜合有效系數(shù)取 0.3 到 0.4 是常態(tài)成熟框架下能到 0.5 到 0.6。報告里如果提到「國產(chǎn)算力占比達到 XX%」你要追問的是這個占比是按標稱算的還是按有效算力算的兩者能差出一倍。2.3 智算中心上架率與算力利用率的區(qū)別報告里常出現(xiàn)兩個容易混淆的詞上架率和利用率。上架率是物理機柜裝了多少卡利用率是這些卡實際跑了多少活。一個智算中心上架率 90% 但利用率只有 30%說明卡裝進去了但沒業(yè)務跑這在行業(yè)里不是個別現(xiàn)象。我排查這類問題時習慣看三個數(shù)# 從監(jiān)控系統(tǒng)拉取集群真實利用率示例命令按實際監(jiān)控棧替換 # 1. GPU 顯存占用率 nvidia-smi --query-gpuindex,memory.used,memory.total,utilization.gpu \ --formatcsv,noheader,nounits # 2. 過去 7 天平均 SM 利用率需 DCGM 或類似采集 dcgmi dmon -e 1002,1003 -c 10 # 3. 任務隊列等待時長 kubectl get pods -n ai-training --field-selector status.phasePending第一條命令看顯存和瞬時利用率第二條看持續(xù) SM 活躍度第三條看排隊情況。如果顯存占滿但 SM 利用率長期低于 20%多半是推理服務 batch 太小或者模型加載后空轉如果排隊任務多但利用率低那是調度策略有問題。報告里的「利用率」指標你要看清楚它統(tǒng)計的是哪個口徑是卡級 SM 利用率還是任務級占用率兩者能差 20 個百分點。2.4 行業(yè)滲透度指標怎么映射到自己的業(yè)務報告最后通常有一張行業(yè)滲透度表按互聯(lián)網(wǎng)、金融、制造、醫(yī)療等分類。這張表對一線工程師的價值不是看排名而是看「同行業(yè)的算力投入強度」。比如金融行業(yè)滲透度高說明風控和客服場景已經(jīng)規(guī)?；圃煨袠I(yè)滲透度低但增速快說明質檢和排產(chǎn)場景在起量。我一般會把這張表轉成自己的預算參照# 把行業(yè)滲透度映射為算力預算系數(shù) industry_penetration { 互聯(lián)網(wǎng): 0.85, 金融: 0.70, 制造: 0.45, 醫(yī)療: 0.35, } # 本企業(yè)所處行業(yè) my_industry 制造 # 行業(yè)平均單業(yè)務算力投入示例值需按報告分項替換 avg_投入 12.0 # 單位PFLOPS/業(yè)務線 my_budget avg_投入 * industry_penetration[my_industry] print(f參照行業(yè)水位單業(yè)務線建議投入: {my_budget:.1f} PFLOPS)這段代碼不是讓你照抄數(shù)字而是建立「行業(yè)水位 → 自身預算」的換算思路。滲透度 0.45 意味著同行業(yè)里還有一半以上的業(yè)務場景沒上算力你的增量空間就在那里。參數(shù)替換成報告里的實際分項值即可。3. 用報告數(shù)據(jù)做一次本地算力盤點從采集到出圖3.1 采集本集群的算力臺賬讀完報告下一步是拿它當鏡子照自己。我一般先建一份本地算力臺賬把每臺機器的卡型、數(shù)量、顯存、互聯(lián)方式、當前負載記下來。采集腳本用 Python 寫最順手import subprocess import json import csv def collect_gpu_info(): 采集本機 GPU 信息輸出為結構化列表 result subprocess.run( [nvidia-smi, --query-gpuindex,name,memory.total,utilization.gpu, --formatcsv,noheader,nounits], capture_outputTrue, textTrue ) gpus [] for line in result.stdout.strip().split(\n): idx, name, mem, util [x.strip() for x in line.split(,)] gpus.append({ index: int(idx), name: name, memory_total_mb: int(mem), utilization_pct: int(util), }) return gpus def export_to_csv(gpus, pathgpu_ledger.csv): with open(path, w, newline) as f: writer csv.DictWriter(f, fieldnamesgpus[0].keys()) writer.writeheader() writer.writerows(gpus) print(f臺賬已寫入 {path}共 {len(gpus)} 張卡) if __name__ __main__: export_to_csv(collect_gpu_info())邏輯說明第一條命令拉取每張卡的型號、顯存和瞬時利用率轉成字典列表后寫 CSV。參數(shù)上--query-gpu支持的字段很多做臺賬至少要有 index、name、memory.total、utilization.gpu 四個。注意nounits讓輸出不帶單位方便后續(xù)解析。如果集群是多機多卡把這段腳本推到每臺機器跑一遍匯總時按機器名加一列即可。失敗時先看nvidia-smi是否在 PATH 里容器環(huán)境里經(jīng)常沒裝驅動工具需要掛載宿主機的設備節(jié)點。3.2 把臺賬和報告口徑對齊臺賬有了接下來做口徑對齊。報告里的算力單位是 EFLOPS你臺賬里是卡數(shù)和單卡算力中間要換算。換算時最容易翻車的地方是精度口徑報告寫 FP16你的卡可能標稱 BF16 或 INT8直接乘會差出好幾倍。我一般用下面這張對照表來統(tǒng)一口徑精度相對 FP16 折算適用場景FP320.5科學計算、部分訓練FP161.0主流訓練和推理BF161.0大模型訓練INT82.0量化推理INT44.0極致量化推理折算時先把所有卡統(tǒng)一到 FP16 口徑再乘卡數(shù)得到總標稱算力最后乘前面說的有效系數(shù)。這一步做完你就能回答「我的集群在報告口徑下相當于多少 EFLOPS」這個問題。注意 INT8 的 2 倍只是理論值實際推理里受顯存帶寬限制能到 1.5 倍就不錯了。3.3 生成自己的算力水位圖數(shù)據(jù)對齊后出一張水位圖最直觀。用 matplotlib 畫一個簡單的對比條形圖import matplotlib.pyplot as plt # 示例數(shù)據(jù)報告行業(yè)均值 vs 本集群 labels [訓練算力, 推理算力, 有效利用率] industry [180, 140, 0.62] mine [95, 110, 0.48] x range(len(labels)) fig, ax1 plt.subplots(figsize(8, 5)) ax1.bar([i - 0.2 for i in x], industry, width0.4, label行業(yè)水位) ax1.bar([i 0.2 for i in x], mine, width0.4, label本集群) ax1.set_xticks(list(x)) ax1.set_xticklabels(labels) ax1.set_ylabel(算力 (PFLOPS) / 利用率) ax1.legend() plt.title(本集群算力水位 vs 行業(yè)參照) plt.tight_layout() plt.savefig(water_level.png, dpi150)這段代碼把訓練、推理、利用率三個指標并排畫出來一眼能看出短板在哪。參數(shù)上width0.4控制條寬dpi150保證出圖清晰。如果你的利用率明顯低于行業(yè)均值問題多半在調度或業(yè)務填充率上而不是卡不夠。這張圖拿去做匯報也比純數(shù)字有說服力。4. 避坑讀算力報告時最容易翻車的五個地方4.1 把標稱算力當有效算力用現(xiàn)象按報告里的總算力做規(guī)劃上線后吞吐只有預期一半。原因報告口徑是峰值標稱實際受通信、調度、故障影響。解決訓練側乘 0.55~0.65推理側乘 0.75~0.85國產(chǎn)卡再乘生態(tài)系數(shù)。4.2 忽略精度口徑差異現(xiàn)象拿 INT8 算力直接和 FP16 算力相加。原因不同精度不能直接相加折算系數(shù)不同。解決統(tǒng)一折算到 FP16 口徑再匯總INT8 按 1.5~2.0 倍折算別取滿。4.3 把上架率當利用率現(xiàn)象看到智算中心上架率 90% 就認為算力充足。原因上架率是物理裝機利用率是業(yè)務負載。解決分別統(tǒng)計利用率低于 40% 時優(yōu)先優(yōu)化調度而不是加卡。4.4 用出貨量占比推斷算力占比現(xiàn)象國產(chǎn)芯片出貨量占比高就認為算力供給充足。原因單卡算力密度不同出貨量不等于算力。解決按「出貨量 × 單卡有效算力」重新計算占比。4.5 直接套用行業(yè)滲透度做預算現(xiàn)象照搬報告里的行業(yè)滲透度系數(shù)做采購預算結果超配或欠配。原因滲透度是行業(yè)均值企業(yè)業(yè)務結構差異大。解決先用自身業(yè)務量反推所需算力再用滲透度做修正別反過來。5. 把評估報告變成季度容量規(guī)劃的實操技巧報告讀完、臺賬建完、坑也避了最后落到一個具體動作把這份評估報告變成你每個季度的容量規(guī)劃輸入。我的習慣是建一張「算力規(guī)劃跟蹤表」每季度更新一次字段包括本季度實際峰值利用率、下季度業(yè)務增量預估、按報告有效率折算的缺口、采購或調度建議。這張表不需要多復雜Excel 或 CSV 就夠關鍵是每季度用真實監(jiān)控數(shù)據(jù)回填而不是拍腦袋。具體操作上我一般按這個節(jié)奏走季度初拉一次集群利用率基線季度中跟蹤業(yè)務上線帶來的負載變化季度末對照報告里的行業(yè)增速修正下季度預期。修正時有個技巧——報告里的增速是行業(yè)整體你要把它拆成「存量業(yè)務自然增長」和「新業(yè)務場景增量」兩部分前者通常 10%~15%后者看業(yè)務規(guī)劃。兩部分加完再乘一個 0.8 的安全系數(shù)避免過度樂觀。還有一個容易被忽略的點報告里的算力數(shù)據(jù)有滯后性通常反映的是半年前到一年前的供給情況。所以讀報告時要結合當下的芯片交付周期來判斷。如果報告說某類卡供給充足但你知道當前交付周期還在 8 周以上那規(guī)劃時就要留出緩沖。這個判斷沒有公式靠的是平時對供應鏈的跟蹤。驗證方法上我建議每季度做一次「反推校驗」用實際業(yè)務吞吐反推需要的有效算力再和臺賬里的標稱算力對比看有效率是否落在預期區(qū)間。如果連續(xù)兩個季度有效率低于預期下限說明要么調度有問題要么卡型選錯了這時候再回頭看報告里的選型建議才有意義。我自己的教訓是早年太信報告里的總數(shù)直接按標稱算力做了一年規(guī)劃結果半年后就被業(yè)務打臉不得不臨時加預算。后來養(yǎng)成習慣任何報告數(shù)據(jù)進規(guī)劃前先乘有效率、先拆精度口徑、先對齊上架和利用兩個概念翻車次數(shù)明顯少了。希望幫到你。本文還有配套的精品資源點擊獲取 算力評估報告實戰(zhàn)解讀：訓練推理拆分、有效算力折算與容量規(guī)劃
簡介《2025年中國人工智能計算力發(fā)展評估報告》由IDC數(shù)據(jù)支撐面向政策制定者、企業(yè)管理者、研究人員及投資者幫助把握生成式人工智能驅動下的算力需求變化與產(chǎn)業(yè)趨勢。資源為1個PDF文件壓縮包約2.02MB內容涵蓋全球及中國人工智能發(fā)展概述、算力及應用、發(fā)展評估與IDC建議四大板塊目錄結構清晰便于按章節(jié)檢索。報告系統(tǒng)梳理了算力五大趨勢提升算力效能、芯片與服務器高性能演進、存儲與網(wǎng)絡優(yōu)化、可持續(xù)數(shù)據(jù)中心建設及邊緣計算擴展并深入分析液冷技術、智能算力服務中心、開源大模型普及等焦點議題。讀者可從中獲取2025年中國智能算力規(guī)模預測、行業(yè)與地域排名、企業(yè)擴容與提效并行策略等關鍵結論為制定人工智能發(fā)展規(guī)劃、研判技術政策走向提供參考。目前已有253人學習下載。1. 算力評估報告背后一線工程師該怎么讀、怎么用2025 年各類人工智能計算力發(fā)展評估報告陸續(xù)出爐圈子里討論最多的不是排名本身而是「算力賬到底怎么算」。我在某實驗室做推理集群的容量規(guī)劃每年這類報告出來都要逐頁拆一遍——不是為了看誰排第一而是為了搞清楚三件事訓練卡和推理卡的比例怎么定、國產(chǎn)芯片在真實業(yè)務里的有效算力打幾折、以及明年采購預算該往哪個方向壓。這份評估報告類的材料本質上是一份行業(yè)級的「算力體檢表」它把芯片供給、服務器出貨、智算中心上架率、行業(yè)滲透度這些指標串成一條鏈。對做基礎設施、模型部署、預算規(guī)劃的工程師來說它解決的是「我手里的集群在行業(yè)里處于什么水位、下一步該補哪塊短板」的問題。適合誰讀做智算中心運營的、管推理成本的、寫算力采購方案的以及需要向非技術管理層解釋「為什么還要加卡」的人。下面我按自己拆報告的習慣把這份材料從讀法到落地講透。2. 拆解評估報告的四個核心指標從算力口徑到有效利用率2.1 訓練算力與推理算力為什么要分開算很多報告把「智能算力規(guī)?！够\統(tǒng)寫成一個總數(shù)單位是 EFLOPSFP16 或 INT8 口徑但一線做規(guī)劃的人必須把它拆成訓練和推理兩條線。原因很直接訓練卡追求的是互聯(lián)帶寬和顯存容量推理卡追求的是單位功耗下的吞吐和延遲。一張卡在訓練集群里可能因為通信瓶頸只能發(fā)揮 60% 的標稱算力放到推理場景里做 batch 推理反而能跑到 85%。我一般會按下面這個口徑去還原報告里的數(shù)字# 把報告里的總算力拆成訓練/推理兩條線 # 假設報告給出智能算力總規(guī)模 total_eflops訓練占比 train_ratio total_eflops 320.0 # 示例報告口徑下的 FP16 智能算力 train_ratio 0.55 # 訓練側占比需從報告分項里反推 infer_ratio 1 - train_ratio train_eflops total_eflops * train_ratio infer_eflops total_eflops * infer_ratio # 有效算力折算訓練按 0.55~0.65推理按 0.75~0.85 train_effective train_eflops * 0.60 infer_effective infer_eflops * 0.80 print(f訓練有效算力: {train_effective:.1f} EFLOPS) print(f推理有效算力: {infer_effective:.1f} EFLOPS)這段代碼的邏輯是報告給的永遠是標稱峰值而實際可用算力要乘一個「有效率」。訓練側有效率低是因為大規(guī)模并行時 AllReduce 通信、checkpoint 寫入、故障重啟都在吃時間推理側有效率相對高但受限于顯存帶寬和調度碎片。參數(shù)怎么定訓練有效率我通常取 0.55 到 0.65集群規(guī)模越大越往低取推理有效率取 0.75 到 0.85如果業(yè)務是長上下文場景要再降 10 個點。報告里如果只給了總數(shù)沒給拆分比例就去翻它的分項章節(jié)通常會有「訓練/推理」或「智算/通算」的拆分表。2.2 國產(chǎn)芯片的有效算力折算系數(shù)怎么取評估報告里國產(chǎn)芯片的份額是繞不開的一段。但報告寫的是「出貨量占比」或「算力占比」這兩個數(shù)差別很大。出貨量占比高不代表算力占比高因為單卡算力密度不同。我在做替代方案評估時會單獨建一張折算表指標含義常見取值區(qū)間對規(guī)劃的影響標稱算力廠商標稱 FP16 峰值按具體型號僅作上限參考實測算力典型模型下的穩(wěn)定值標稱的 50%~70%決定真實吞吐生態(tài)折算框架適配成熟度0.6~0.9影響遷移成本綜合有效系數(shù)三者相乘0.3~0.6用于容量規(guī)劃這張表的關鍵在最后一行的「綜合有效系數(shù)」。我見過太多方案直接拿標稱算力做容量規(guī)劃結果上線后吞吐只有預期的一半血淚經(jīng)驗就是國產(chǎn)卡在早期適配階段綜合有效系數(shù)取 0.3 到 0.4 是常態(tài)成熟框架下能到 0.5 到 0.6。報告里如果提到「國產(chǎn)算力占比達到 XX%」你要追問的是這個占比是按標稱算的還是按有效算力算的兩者能差出一倍。2.3 智算中心上架率與算力利用率的區(qū)別報告里常出現(xiàn)兩個容易混淆的詞上架率和利用率。上架率是物理機柜裝了多少卡利用率是這些卡實際跑了多少活。一個智算中心上架率 90% 但利用率只有 30%說明卡裝進去了但沒業(yè)務跑這在行業(yè)里不是個別現(xiàn)象。我排查這類問題時習慣看三個數(shù)# 從監(jiān)控系統(tǒng)拉取集群真實利用率示例命令按實際監(jiān)控棧替換 # 1. GPU 顯存占用率 nvidia-smi --query-gpuindex,memory.used,memory.total,utilization.gpu \ --formatcsv,noheader,nounits # 2. 過去 7 天平均 SM 利用率需 DCGM 或類似采集 dcgmi dmon -e 1002,1003 -c 10 # 3. 任務隊列等待時長 kubectl get pods -n ai-training --field-selector status.phasePending第一條命令看顯存和瞬時利用率第二條看持續(xù) SM 活躍度第三條看排隊情況。如果顯存占滿但 SM 利用率長期低于 20%多半是推理服務 batch 太小或者模型加載后空轉如果排隊任務多但利用率低那是調度策略有問題。報告里的「利用率」指標你要看清楚它統(tǒng)計的是哪個口徑是卡級 SM 利用率還是任務級占用率兩者能差 20 個百分點。2.4 行業(yè)滲透度指標怎么映射到自己的業(yè)務報告最后通常有一張行業(yè)滲透度表按互聯(lián)網(wǎng)、金融、制造、醫(yī)療等分類。這張表對一線工程師的價值不是看排名而是看「同行業(yè)的算力投入強度」。比如金融行業(yè)滲透度高說明風控和客服場景已經(jīng)規(guī)?；圃煨袠I(yè)滲透度低但增速快說明質檢和排產(chǎn)場景在起量。我一般會把這張表轉成自己的預算參照# 把行業(yè)滲透度映射為算力預算系數(shù) industry_penetration { 互聯(lián)網(wǎng): 0.85, 金融: 0.70, 制造: 0.45, 醫(yī)療: 0.35, } # 本企業(yè)所處行業(yè) my_industry 制造 # 行業(yè)平均單業(yè)務算力投入示例值需按報告分項替換 avg_投入 12.0 # 單位PFLOPS/業(yè)務線 my_budget avg_投入 * industry_penetration[my_industry] print(f參照行業(yè)水位單業(yè)務線建議投入: {my_budget:.1f} PFLOPS)這段代碼不是讓你照抄數(shù)字而是建立「行業(yè)水位 → 自身預算」的換算思路。滲透度 0.45 意味著同行業(yè)里還有一半以上的業(yè)務場景沒上算力你的增量空間就在那里。參數(shù)替換成報告里的實際分項值即可。3. 用報告數(shù)據(jù)做一次本地算力盤點從采集到出圖3.1 采集本集群的算力臺賬讀完報告下一步是拿它當鏡子照自己。我一般先建一份本地算力臺賬把每臺機器的卡型、數(shù)量、顯存、互聯(lián)方式、當前負載記下來。采集腳本用 Python 寫最順手import subprocess import json import csv def collect_gpu_info(): 采集本機 GPU 信息輸出為結構化列表 result subprocess.run( [nvidia-smi, --query-gpuindex,name,memory.total,utilization.gpu, --formatcsv,noheader,nounits], capture_outputTrue, textTrue ) gpus [] for line in result.stdout.strip().split(\n): idx, name, mem, util [x.strip() for x in line.split(,)] gpus.append({ index: int(idx), name: name, memory_total_mb: int(mem), utilization_pct: int(util), }) return gpus def export_to_csv(gpus, pathgpu_ledger.csv): with open(path, w, newline) as f: writer csv.DictWriter(f, fieldnamesgpus[0].keys()) writer.writeheader() writer.writerows(gpus) print(f臺賬已寫入 {path}共 {len(gpus)} 張卡) if __name__ __main__: export_to_csv(collect_gpu_info())邏輯說明第一條命令拉取每張卡的型號、顯存和瞬時利用率轉成字典列表后寫 CSV。參數(shù)上--query-gpu支持的字段很多做臺賬至少要有 index、name、memory.total、utilization.gpu 四個。注意nounits讓輸出不帶單位方便后續(xù)解析。如果集群是多機多卡把這段腳本推到每臺機器跑一遍匯總時按機器名加一列即可。失敗時先看nvidia-smi是否在 PATH 里容器環(huán)境里經(jīng)常沒裝驅動工具需要掛載宿主機的設備節(jié)點。3.2 把臺賬和報告口徑對齊臺賬有了接下來做口徑對齊。報告里的算力單位是 EFLOPS你臺賬里是卡數(shù)和單卡算力中間要換算。換算時最容易翻車的地方是精度口徑報告寫 FP16你的卡可能標稱 BF16 或 INT8直接乘會差出好幾倍。我一般用下面這張對照表來統(tǒng)一口徑精度相對 FP16 折算適用場景FP320.5科學計算、部分訓練FP161.0主流訓練和推理BF161.0大模型訓練INT82.0量化推理INT44.0極致量化推理折算時先把所有卡統(tǒng)一到 FP16 口徑再乘卡數(shù)得到總標稱算力最后乘前面說的有效系數(shù)。這一步做完你就能回答「我的集群在報告口徑下相當于多少 EFLOPS」這個問題。注意 INT8 的 2 倍只是理論值實際推理里受顯存帶寬限制能到 1.5 倍就不錯了。3.3 生成自己的算力水位圖數(shù)據(jù)對齊后出一張水位圖最直觀。用 matplotlib 畫一個簡單的對比條形圖import matplotlib.pyplot as plt # 示例數(shù)據(jù)報告行業(yè)均值 vs 本集群 labels [訓練算力, 推理算力, 有效利用率] industry [180, 140, 0.62] mine [95, 110, 0.48] x range(len(labels)) fig, ax1 plt.subplots(figsize(8, 5)) ax1.bar([i - 0.2 for i in x], industry, width0.4, label行業(yè)水位) ax1.bar([i 0.2 for i in x], mine, width0.4, label本集群) ax1.set_xticks(list(x)) ax1.set_xticklabels(labels) ax1.set_ylabel(算力 (PFLOPS) / 利用率) ax1.legend() plt.title(本集群算力水位 vs 行業(yè)參照) plt.tight_layout() plt.savefig(water_level.png, dpi150)這段代碼把訓練、推理、利用率三個指標并排畫出來一眼能看出短板在哪。參數(shù)上width0.4控制條寬dpi150保證出圖清晰。如果你的利用率明顯低于行業(yè)均值問題多半在調度或業(yè)務填充率上而不是卡不夠。這張圖拿去做匯報也比純數(shù)字有說服力。4. 避坑讀算力報告時最容易翻車的五個地方4.1 把標稱算力當有效算力用現(xiàn)象按報告里的總算力做規(guī)劃上線后吞吐只有預期一半。原因報告口徑是峰值標稱實際受通信、調度、故障影響。解決訓練側乘 0.55~0.65推理側乘 0.75~0.85國產(chǎn)卡再乘生態(tài)系數(shù)。4.2 忽略精度口徑差異現(xiàn)象拿 INT8 算力直接和 FP16 算力相加。原因不同精度不能直接相加折算系數(shù)不同。解決統(tǒng)一折算到 FP16 口徑再匯總INT8 按 1.5~2.0 倍折算別取滿。4.3 把上架率當利用率現(xiàn)象看到智算中心上架率 90% 就認為算力充足。原因上架率是物理裝機利用率是業(yè)務負載。解決分別統(tǒng)計利用率低于 40% 時優(yōu)先優(yōu)化調度而不是加卡。4.4 用出貨量占比推斷算力占比現(xiàn)象國產(chǎn)芯片出貨量占比高就認為算力供給充足。原因單卡算力密度不同出貨量不等于算力。解決按「出貨量 × 單卡有效算力」重新計算占比。4.5 直接套用行業(yè)滲透度做預算現(xiàn)象照搬報告里的行業(yè)滲透度系數(shù)做采購預算結果超配或欠配。原因滲透度是行業(yè)均值企業(yè)業(yè)務結構差異大。解決先用自身業(yè)務量反推所需算力再用滲透度做修正別反過來。5. 把評估報告變成季度容量規(guī)劃的實操技巧報告讀完、臺賬建完、坑也避了最后落到一個具體動作把這份評估報告變成你每個季度的容量規(guī)劃輸入。我的習慣是建一張「算力規(guī)劃跟蹤表」每季度更新一次字段包括本季度實際峰值利用率、下季度業(yè)務增量預估、按報告有效率折算的缺口、采購或調度建議。這張表不需要多復雜Excel 或 CSV 就夠關鍵是每季度用真實監(jiān)控數(shù)據(jù)回填而不是拍腦袋。具體操作上我一般按這個節(jié)奏走季度初拉一次集群利用率基線季度中跟蹤業(yè)務上線帶來的負載變化季度末對照報告里的行業(yè)增速修正下季度預期。修正時有個技巧——報告里的增速是行業(yè)整體你要把它拆成「存量業(yè)務自然增長」和「新業(yè)務場景增量」兩部分前者通常 10%~15%后者看業(yè)務規(guī)劃。兩部分加完再乘一個 0.8 的安全系數(shù)避免過度樂觀。還有一個容易被忽略的點報告里的算力數(shù)據(jù)有滯后性通常反映的是半年前到一年前的供給情況。所以讀報告時要結合當下的芯片交付周期來判斷。如果報告說某類卡供給充足但你知道當前交付周期還在 8 周以上那規(guī)劃時就要留出緩沖。這個判斷沒有公式靠的是平時對供應鏈的跟蹤。驗證方法上我建議每季度做一次「反推校驗」用實際業(yè)務吞吐反推需要的有效算力再和臺賬里的標稱算力對比看有效率是否落在預期區(qū)間。如果連續(xù)兩個季度有效率低于預期下限說明要么調度有問題要么卡型選錯了這時候再回頭看報告里的選型建議才有意義。我自己的教訓是早年太信報告里的總數(shù)直接按標稱算力做了一年規(guī)劃結果半年后就被業(yè)務打臉不得不臨時加預算。后來養(yǎng)成習慣任何報告數(shù)據(jù)進規(guī)劃前先乘有效率、先拆精度口徑、先對齊上架和利用兩個概念翻車次數(shù)明顯少了。希望幫到你。本文還有配套的精品資源點擊獲取