2026年11月2日，NVIDIA 喺技術博客公佈 NVIDIA Workload Map，想解決一個好多運算團隊都撞到嘅牆：喺 Kubernetes 上面管理 AI 負載，每種框架都要另寫一套代碼先讀得明。
講多啲，所謂「負載」（workload）就係喺 GPU 集群上面跑嘅任務，例如一組分散式訓練 job（distributed training job），一個主節點帶幾個 worker，每個 pod 要幾個 GPU。NVIDIA 舉嘅例子係一個 JobSet：一個 leader Job 加兩個 worker Job，每個 pod 申請 4 個 GPU，加埋共 12 個。
問題出喺每一種框架（JobSet、LeaderWorkerSet 等 custom resource definitions）喺 Kubernetes 上面嘅編碼格式都唔同。工具要管理呢啲負載，就必須有對應嘅 adapter。文章指出，NVIDIA Run:ai 團隊做平台時就撞正呢個問題：每新增一個 CRD，開發者都要重新回答同一組問題——結構點樣、狀態點解讀成 phase、點樣改 pod spec 而唔會搞毀負載。答完就產出該 CRD 嘅 adapter，換句話説每個新框架都多寫一個。文章話，這使新框架支援變成 roadmap 項目而非一次性成本，所以支援新 workload 類型「so often waits for a release」。
圖片：Coolcaesar／CC BY-SA 4.0／Wikimedia Commons
Workload Map 嘅做法係提供一個可跨框架重用嘅通用描述，讓調度器、controller、dashboard 同成本工具讀得明受支援嘅負載類型，而唔使維護每款框架嘅獨立解析代碼。文章稱其用途包括 workload inspection、gang scheduling（整組 pod 一齊排入，唔好拆散）同平台可視化。呢個係 NVIDIA DSX AI Factory Platform（一個開放、模組化嘅組件集，支援多租户運算）嘅一部分。
呢個係廠商自家技術博客，冇獨立測試、冇 benchmark、冇第三方驗證；文章只展示一個例子 manifest。就工程角度講，「一次寫完、跨框架通用」呢個話嘅真實度，要睇它點處理各框架差異、實際覆蓋咗幾多 CRD、同維護成本係咪真係慳咗。
模姐驗嚇貨：呢篇係技術文，冇跑分冇宣傳，但「一次寫完通用」呢句廠商自己講，讀者要問：通用到幾通用？覆蓋幾多款 CRD？有冇獨立測試？廠商嘅圖表同示範唔等於獨立驗證。
