分子模擬異構算力適配開發(fā)教程20完整項目——異構算力 MD 平臺適配層、調(diào)度器、基準流水線三位一體版本聲明塊工具/軟件本系列全部組件適配層 18 篇、調(diào)度器 17 篇、流水線 12 篇、對賬器 19 篇底座 K8sVolcano/HAMi14/15 篇或 SlurmApptainer16 篇語言/環(huán)境Python 3.10、Linux本文目標讀完你擁有一個可落地的平臺藍圖——分層架構、目錄骨架、核心代碼組裝、可觀測性設計與部署決策能把本系列任意單篇的產(chǎn)出接入對應層一句話結論異構 MD 平臺 四層總裝——底座層K8sVolcano/HAMi 或 SlurmApptainer管設備與作業(yè)組、適配層18 篇探測/協(xié)商/注入/執(zhí)行/歸一、調(diào)度層17 篇槽位回收/補位/aging 的 continuous batching 內(nèi)核、運維層12 篇基準檔案 19 篇對賬巡檢 Prometheus 指標——用戶只見統(tǒng)一的 MDJobSpec 提交接口異構性引擎×硬件×精度×調(diào)度器全部被中間兩層吸收。〇、本篇要解決的認知問題平臺的完整分層是什么每層對應本系列哪幾篇的產(chǎn)出三大組件適配層/調(diào)度器/流水線怎么組裝——接口與數(shù)據(jù)流可觀測性指標/檔案/巡檢怎么設計成平臺的“體檢系統(tǒng)”部署形態(tài)怎么選K8s 原生 / Slurm 旁掛 / 單機起步一、機制解析1.1 平臺分層19 篇知識的歸位圖為什么這一節(jié)對你重要總裝不是把 19 篇代碼堆一起——每篇的產(chǎn)出有它的層放錯層比如把引擎協(xié)商塞進 K8s 調(diào)度器、或把槽位管理下沉到 gmx 命令行會造成職責糾纏這是平臺工程最常見的返工源。┌────────────────────────────────────────────────────────────┐ │ 用戶接口層 mdctl submit / REST API / Web │ │ 統(tǒng)一作業(yè)描述 MDJobSpec18 篇 │ ├────────────────────────────────────────────────────────────┤ │ 調(diào)度層 MDScheduler17 篇槽位回收/補位/aging │ │ 平臺隊列策略優(yōu)先級/配額的 app 層版本 │ ├────────────────────────────────────────────────────────────┤ │ 適配層 Adapter 族18 篇探測/協(xié)商/注入/執(zhí)行/歸一 │ │ GromacsAdapter / OpenMMAdapter / ... │ ├────────────────────────────────────────────────────────────┤ │ 底座層 K8s Volcano/HAMi14/15 篇 │ │ 或 Slurm GRES Apptainer16 篇 │ │ 設備分配、可見性注入、gang/配額 │ └────────────────────────────────────────────────────────────┘ 旁路系統(tǒng)貫穿四層 基準流水線12 篇 perf-archive.json→ 性能檔案庫 對賬巡檢19 篇 reconcile→ 數(shù)值健康 診斷體系19 篇分類學→ 故障定位各層職責的一句話邊界底座管“有什么資源、怎么隔離”適配層管“這個作業(yè)具體怎么跑”調(diào)度層管“什么時候、在哪個槽位跑”用戶層管“用戶說什么語言”。旁路系統(tǒng)不屬于任何層——它們消費所有層的輸出。1.2 數(shù)據(jù)流一次作業(yè)的一生① 用戶提交 MDJobSpec(kindtpr, precisionmixed, priority5) ② 調(diào)度層入隊有效優(yōu)先級 5 等待×aging——17 篇 ③ 槽位空閑 → 取出作業(yè) → 交給適配層 ④ 適配層探測緩存的能力矩陣gmx 三要素 OpenMM 平臺表——18 篇 → 協(xié)商形態(tài)/精度/偏好過濾→ 選定 GromacsAdapter ⑤ 環(huán)境注入build_envdevice → CUDA_VISIBLE_DEVICES——18 篇 → 執(zhí)行gmx mdrun 全家桶 -cpi 斷點語義——3/16 篇 ⑥ 運行中底座的健康流device plugin Unhealthy——14 篇異常 → 調(diào)度層標記、回收、換槽位續(xù)跑17 篇 checkpoint ⑦ 完成JobResultns/day、環(huán)境快照、軌跡路徑 → 歸一化入檔perf-ledger.csv 追加——16 篇 ⑧ 夜間巡檢抽體系跑三方對賬19 篇→ 數(shù)值健康分兩個設計決策值得點名能力矩陣帶緩存探測有成本——gmx --version 是進程調(diào)用、OpenMM 枚舉要 import緩存 TTL 手動刷新按鈕健康流是旁掛的調(diào)度器不主動輪詢設備訂閱底座的事件——掉卡秒級感知的 K8s 版是 ListAndWatchSlurm 版是作業(yè)自檢段的退出碼。1.3 可觀測性平臺的體檢系統(tǒng)三個維度、三套數(shù)據(jù)、一個消費口維度數(shù)據(jù)源存儲消費性能md.log 六指標12 篇流水線perf-archive.json / ledger.csv趨勢圖、瓶頸定位19 篇、鐵律 9 實測依據(jù)數(shù)值對賬巡檢19 篇巡檢報告版本升級的回歸門禁運行作業(yè)狀態(tài)、槽位利用率、隊列深度Prometheus 指標告警、容量規(guī)劃Prometheus 指標命名平臺側約定Prom 命名慣例namespace_subsystem_namemdplatform_jobs_total{engine,backend,precision,state} # 計數(shù)作業(yè)按維度 mdplatform_slots{device_type} # gauge槽位在用/空閑 mdplatform_job_ns_per_day{engine,backend,system} # histogram性能分布 mdplatform_reconcile_pass_ratio{pair} # gauge對賬通過率 mdplatform_queue_wait_seconds{priority_class} # histogram排隊延遲SLA設計要點指標標簽維度對齊能力矩陣engine/backend/precision——性能問題定位時能下鉆到“是不是 MUSA 后端的作業(yè)普遍慢”對賬通過率進指標——數(shù)值健康從“某天有人發(fā)現(xiàn)”變成“儀表盤紅綠燈”。1.4 部署形態(tài)三種起步形態(tài) A單機旁掛最快起步——適配層 調(diào)度器跑在一臺 GPU 服務器cron 或 systemd無 K8s/Slurm 依賴。適合課題組級幾人到十幾人、幾張卡。本篇骨架代碼就是這個形態(tài)的直接可用版。形態(tài) BSlurm 旁掛HPC 存量——平臺調(diào)度器翻譯作業(yè)為 sbatch 腳本16 篇模板GRES/可見性交給 Slurm平臺只管隊列策略與適配層。適合算力中心已有 Slurm 且不想動底座。形態(tài) CK8s 原生平臺化目標——調(diào)度層對接 Volcano Queue/PodGroup15 篇、HAMi 管切分14 篇適配層以 Job/DaemonSet 形態(tài)部署。多租戶、彈性、混載推理MD的目標形態(tài)。演進路徑 A→B/C 平滑因為適配層與調(diào)度內(nèi)核在三種形態(tài)里零改動它們不感知底座底座差異被 build_env 與“提交翻譯器”吸收——這是 18 篇分層設計的回報。二、完整代碼與逐行剖析平臺骨架把 17/18/19 篇組件組裝成可運行的最小平臺——形態(tài) A 直接可用#!/usr/bin/env python3mdplatform.py —— 異構 MD 平臺最小可用版形態(tài) A單機。 組裝MDScheduler17 Adapter 族與協(xié)商18 檔案與對賬12/19。 運行python mdplatform.py submit jobs.json # 提交一批作業(yè) python mdplatform.py status # 查看隊列/槽位 python mdplatform.py reconcile a b # 對賬兩個作業(yè)的能量 from__future__importannotationsimportjsonimportsysimporttimefrompathlibimportPath# ── 組件復用本系列產(chǎn)出非重寫──────────────────────────────────# 17 篇調(diào)度內(nèi)核槽位回收/補位/aging# from md_scheduler import MDScheduler, MDJob as SchedJob, State# 18 篇適配層探測/協(xié)商/注入/執(zhí)行# from adapter_layer import (MDJobSpec, probe_gromacs, probe_openmm,# negotiate, GromacsAdapter, OpenMMAdapter)# 19 篇對賬器# from reconcile import load_energies, reconcile_L1, Tolerance# —— 教學版內(nèi)聯(lián)演示組裝關系生產(chǎn)用上面 import 連接真實模塊———classPlatform:平臺的組裝點三個組件 一個檔案口。def__init__(self,slots:int2,archive:strplatform-ledger.csv):frommd_schedulerimportMDScheduler self.schedulerMDScheduler(slotsslots,modedemo)# 能力矩陣帶緩存1.2 節(jié)決策探測有成本self._caps_cache:list[dict]|NoneNoneself._caps_ts:float0.0self.archivePath(archive)defcapabilities(self,ttl:float300.0)-list[dict]:能力矩陣TTL 緩存——5 分鐘內(nèi)復用探測結果。ifself._caps_cacheisNoneortime.time()-self._caps_tsttl:fromadapter_layerimportprobe_gromacs,probe_openmm self._caps_cache[probe_gromacs(),probe_openmm()]self._caps_tstime.time()returnself._caps_cachedefsubmit_batch(self,specs:list[dict])-dict:批量提交MDJobSpec 字典 → 協(xié)商驗證 → 調(diào)度器隊列。 注意順序先協(xié)商提交時就說不而不是運行時撞墻——18 篇問題 4。fromadapter_layerimportMDJobSpec,negotiatefrommd_schedulerimportMDJob accepted[]forsinspecs:specMDJobSpec(**s)chosennegotiate(spec,self.capabilities())# 提交期協(xié)商accepted.append(MDJob(job_idf{spec.kind}-{int(time.time()*1000)%100000},tprspec.tpror-,nstepsspec.nstepsor10,priorityspec.backend_prefinteractiveand5or0))self.scheduler.jobsaccepted statsself.scheduler.run()# 檔案口12/16 篇結果追加進 ledger——平臺的記憶withself.archive.open(a)asf:f.write(f{time.strftime(%FT%T)},{json.dumps(stats)}\n)returnstatsdefstatus(self)-dict:隊列/槽位快照1.3 節(jié)指標的來源。return{capabilities:self.capabilities(),jobs:[{id:j.job_id,state:j.state.value}forjinself.scheduler.jobs]}defmain()-None:cmdsys.argv[1]iflen(sys.argv)1elsestatusplatPlatform(slots2)ifcmdsubmit:specsjson.loads(Path(sys.argv[2]).read_text(encodingutf-8))print(json.dumps(plat.submit_batch(specs),ensure_asciiFalse,indent2))elifcmdstatus:print(json.dumps(plat.status(),ensure_asciiFalse,indent2))elifcmdreconcile:fromreconcileimportload_energies,reconcile_L1,Tolerance rreconcile_L1(load_energies(Path(sys.argv[2])),load_energies(Path(sys.argv[3])),Tolerance())print(json.dumps(r,ensure_asciiFalse,indent2))else:print(__doc__)if__name____main__:main()配套的作業(yè)描述文件用戶視角的全部復雜度——這就是“用戶只說什么語言”的答案// jobs.json —— 用戶提交的全部語言一個 JSON 數(shù)組[{kind:tpr,tpr:/data/benchMEM.tpr,nsteps:5000,precision:mixed,backend_pref:gromacs,device:0},{kind:tpr,tpr:/data/ligand-prod.tpr,nsteps:500000,precision:mixed,backend_pref:null,platform_hint:null,device:1}]逐段剖析組裝的本質(zhì)是“連接件”Platform 類沒有重寫任何引擎邏輯——它做的是三件事能力緩存性能決策、提交期協(xié)商體驗決策錯誤早爆、檔案口記憶決策。平臺代碼的價值在連接件不在重復造輪子——19 篇的組件各就各位。submit_batch的協(xié)商前置第 18 篇問題 4 的落實作業(yè)不合法如 tprdouble 但 gmx 是 mixed 構建在提交秒級被拒——帶原因的拒絕比運行三小時后的崩潰好一百倍。status()的輸出結構直接映射 1.3 節(jié)指標capabilities 是標簽維度來源、jobs 的 state 分布是隊列深度——接 Prometheus exporter 就是把這兩個 dict 變成 gauge/counter 的事。jobs.json 里backend_pref: null自動協(xié)商與顯式gromacs并存——平臺對“懂的用戶”開放控制、對“不懂的用戶”提供默認——兩種用戶都被同一層服務。部署清單形態(tài) C 的 K8s 化要點對照 14/15 篇# 平臺組件的 K8s 形態(tài)示意# md-scheduler → Deployment無狀態(tài)對接 Volcano Queue 的 app 層策略# adapter-worker → Job/DaemonSet有狀態(tài)執(zhí)行走 HAMi vGPU 申請 gpumem# capability-probe → CronJob定期刷新能力矩陣——底座設備變化的感知# prometheus exporter → 側車容器消費 status() 輸出# 底座前置Volcano 部署 HAMi 部署 各廠商 device plugin#全部在第 14/15 篇有落地步驟平臺的 K8s 化不改變適配層與調(diào)度內(nèi)核——1.4 節(jié)承諾三、常見報錯與排查問題 1現(xiàn)象——平臺上線后用戶反饋“還是直接 gmx 命令快平臺有開銷”。根因開銷解剖——正常開銷協(xié)商毫秒級、環(huán)境構造微秒級可忽略異常開銷三個來源能力探測無緩存每次全量探測18 篇決策未落地調(diào)度器 poll 過密17 篇問題 3作業(yè)排隊時間被計入“平臺慢”其實是槽位不足的容量問題。解法三層分別處理——TTL 緩存本文 capabilitiespoll 調(diào)到秒級容量問題看 queue_wait_seconds 指標1.3 節(jié)說話加槽位或錯峰。用指標分清“開銷”與“排隊”——多數(shù)抱怨其實是后者。問題 2現(xiàn)象——某引擎升級后平臺作業(yè)全體數(shù)值告警對賬巡檢紅了。根因這是巡檢系統(tǒng)正常工作——引擎升級改變了數(shù)值行為精度路徑/積分器實現(xiàn)變化平臺用 19 篇的對賬把它攔在了生產(chǎn)之前。解法按 19 篇層級定性差異合法變化 vs 真 bug——合法則在平臺登記新基線巡檢的黃金值隨版本更新帶版本標簽真 bug 則凍結該引擎版本能力矩陣把它摘掉上游修復后再放行。巡檢不是擋板的成本是灰度的依據(jù)。問題 3現(xiàn)象——雙底座K8s Slurm 各管一部分節(jié)點時能力矩陣與可見性行為不一致。根因兩底座注入語義差異Slurm 的 job step 環(huán)境 vs K8s 的 Allocate 注入漏過了適配層的統(tǒng)一收口——某處代碼繞過 build_env 直接用了 os.environ。解法架構紀律檢查——適配層外的任何代碼不許構造子進程環(huán)境grep 檢查 subprocess 調(diào)用點的 env 參數(shù)能力探測在雙底座節(jié)點各自跑CronJob/旁掛探測按節(jié)點記錄——矩陣的粒度是節(jié)點不是集群。問題 4現(xiàn)象——平臺故障調(diào)度器崩了時在跑的作業(yè)全部丟失。根因把“調(diào)度器存活”與“作業(yè)存活”耦合了——其實 gmx/OpenMM 進程是底座systemd/K8s/Slurm的公民調(diào)度器崩不該帶走它們丟失的是“管理”不是“計算”。解法調(diào)度器崩潰恢復流程——重啟后掃描作業(yè)產(chǎn)物目錄md.log/deffnm 文件在、按 checkpoint 狀態(tài)重建作業(yè)清單-cpi 語義天然支持、繼續(xù)調(diào)度本文 Platform 的 jobs 狀態(tài)可持久化到 ledger已經(jīng)在做——控制面與數(shù)據(jù)面分離這是 17 篇“調(diào)度內(nèi)核與執(zhí)行后端分離”的運維版。四、動手練習練習 1基礎把 17/18 篇的模塊文件md_scheduler.py/adapter_layer.py與本文 mdplatform.py 放同目錄跑python mdplatform.py status看到帶緩存的能力矩陣輸出。判定成功標準status 輸出雙引擎能力或明確的 unavailable二次調(diào)用 status 在 TTL 內(nèi)不再觸發(fā)探測加個 print 在 probe 里驗證緩存生效。練習 2進階給 Platform 加bench命令——調(diào)第 12 篇流水線對當前槽位跑 benchMEM 短程基準把 ns/day 追加進 ledger 并打印與歷史均值讀 ledger 計算的對比。判定成功標準ledger 里出現(xiàn)新的性能記錄對比輸出含“當前/歷史均值/偏差%”三要素偏差超過 30% 時給出 19 篇決策樹的入口提示。練習 3思考題無標準答案平臺上線一年后能力矩陣膨脹到幾十個條目多引擎版本 × 多硬件 × 多精度協(xié)商變慢、維護變難——該怎么治理思考方向驗證要點① 矩陣的生命周期管理廢棄條目的淘汰機制——性能檔案能否提供依據(jù)② 協(xié)商結果的緩存與失效策略③ “能力即代碼”capability as config還是“能力即探測”runtime probing的長期取舍。五、系列總結20 篇收官?；氐降?1 篇的三個問題現(xiàn)在的你能這樣回答修改引擎GROMACS 四后端的構建2 篇與執(zhí)行控制3 篇、gpu_utils 抽象層5 篇、HIP/SYCL/MUSA 三條移植路線的完整方法論6/7/9 篇——昇騰的特殊性11 篇與“沒有后端”時的決策樹。封裝引擎OpenMM 平臺抽象與插件協(xié)議4/8/10 篇、雙引擎統(tǒng)一適配層18 篇——能力探測、協(xié)商、環(huán)境收口。調(diào)度封裝從 Device Plugin/vGPU14 篇到 Volcano/vNPU15 篇到 Slurm/Apptainer16 篇的底座全景推理調(diào)度思想遷移的 MD 批調(diào)度器17 篇驗證與診斷閉環(huán)12/19 篇最終總裝成平臺20 篇。貫穿全系列的十條鐵律第 0 篇計劃定義在每篇各自主戰(zhàn)場兌現(xiàn)版本先錨定2/13 篇的環(huán)境變量三代史、單后端編譯2 篇、工具邊界6 篇 hipify、昇騰無后端的事實鏈11 篇、GPU-resident 前提3 篇、性能帶上下文12 篇、雙精度慎用2 篇、移植必須過驗證12 篇、切分必須實測14/17 篇、封裝不改物理18/19 篇。下一步去哪把第 9 篇的 SCS 容器跑起來用第 12 篇流水線給你的硬件建檔第 18 篇的適配層接入你手頭的引擎——平臺從第一個真實作業(yè)開始生長。本篇認知問題回顯FAQQ1異構 MD 平臺的完整分層是什么A四層——用戶接口層統(tǒng)一 MDJobSpec 提交、調(diào)度層continuous batching 內(nèi)核槽位回收/補位/aging、適配層能力探測/后端協(xié)商/環(huán)境注入/執(zhí)行/結果歸一、底座層K8sVolcano/HAMi 或 SlurmGRESApptainer管設備分配與可見性旁路系統(tǒng)基準檔案、對賬巡檢、診斷體系貫穿四層——每層職責一句話底座管資源隔離、適配層管作業(yè)怎么跑、調(diào)度層管何時何槽位、用戶層管語言。Q2平臺的三大組件怎么組裝A連接件模式不重復造輪子Platform 類做三件事——能力矩陣 TTL 緩存探測有成本、提交期協(xié)商前置作業(yè)不合法秒級拒絕而非運行數(shù)小時后崩潰、檔案口結果追加 ledger 形成平臺記憶調(diào)度器崩不影響在跑作業(yè)控制面與數(shù)據(jù)面分離重啟后按 checkpoint 產(chǎn)物重建清單續(xù)調(diào)。Q3MD 平臺需要哪些可觀測性指標A三維度對齊能力矩陣標簽engine/backend/precision性能維度mdplatform_job_ns_per_day histogram、六指標來自 12 篇流水線、數(shù)值維度mdplatform_reconcile_pass_ratio 對賬通過率——版本升級的回歸門禁、運行維度jobs_total 計數(shù)、slots gauge、queue_wait_seconds 排隊延遲 SLA——性能定位能下鉆到“某后端是否普遍慢”數(shù)值健康從人工發(fā)現(xiàn)變成儀表盤紅綠燈。Q4平臺部署形態(tài)怎么選A三種起步——單機旁掛適配層調(diào)度器 systemd 跑一臺 GPU 服務器課題組級最快可用、Slurm 旁掛翻譯作業(yè)為 sbatchGRES 交給 SlurmHPC 存量友好、K8s 原生對接 Volcano Queue/HAMi vGPU多租戶彈性目標形態(tài)演進平滑的關鍵是適配層與調(diào)度內(nèi)核對底座零感知底座差異被環(huán)境注入與提交翻譯器吸收。