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