NVIDIA Minerva 推出，聚焦 AI 工廠營運
NVIDIA 於 10 月 22 日發表 Minerva，將基礎設施監控與 AI 工作負載分析結合，圍繞一個更棘手的問題：究竟交付了多少有用的工作成果？NVIDIA Minerva 的推出帶來一個 AIOps 平台，即將人工智能應用於 IT 營運的軟件。NVIDIA 表示，該平台結合營運資料與專門建立的模型，協助團隊更早識別問題。
這令 AI 工廠可觀測性——即透過 AI 基礎設施所發出的訊號理解其狀況的能力——更貼近生產決策。AI 工廠是用作訓練及運行 AI 模型而組織的基礎設施。其營運者需要知道設備活動是否轉化為已完成的工作。一枚繁忙的圖形處理器（GPU），並不能說明應用程式是否達成目標。
現有供應商已處理當中部分問題。Datadog 提供 GPU 監控，而 OpenTelemetry 則提供收集營運訊號的框架。NVIDIA 正以硬件為中心的視角，進入既有的營運工作流程。眼前壓力落在基礎設施團隊身上：他們必須連繫設備健康狀況、工作負載行為及服務表現，同時避免再建立一套割裂的監控系統。
NVIDIA Minerva 的推出帶來甚麼改變
根據 NVIDIA 的 Minerva 平台公告，該平台結合來自基礎設施及 AI 工作負載的遙測資料。遙測資料是指由作業系統發出的測量數據及事件紀錄。NVIDIA 表示，其模型會將這些輸入轉化為可採取行動的發現。
該公司將目標表述為 AI 工廠產出，即一項部署所產生的有用工作。其例子包括 GPU 小時、叢集正常運行時間及 token 產生量。Token 是語言模型處理或生成的文字單位。這些指標將不同的營運問題納入同一討論。
NVIDIA 亦描述了在人手介入，以及透過基礎設施介面和外部系統連接自動化之間作出選擇。這項區分很重要，因為識別問題與授權變更，涉及不同責任。
這項公告令營運解讀成為 NVIDIA AI 基礎設施方案中更明確的一環。
對買家而言，這改變了採購監控方案時的討論。一個平台應說明它改善哪一項營運決策、甚麼證據支持該決策，以及其後由誰繼續負責。單靠另一個儀表板，並不足以提供有力答案。
試想一個示例性的訓練工作：即使獲分配的 GPU 仍在運作，進度卻十分緩慢。從設備角度看，可能沒有明顯硬件故障；從應用程式角度看，則可能顯示完成時間延遲。任何人要作出有用回應前，調查都必須連繫這些觀察結果。
這可能有多種解釋，而公告並未證實 Minerva 能否在生產環境中可靠地區分它們。減速可能涉及資料傳送、通訊、軟件行為或資源分配。將這些可能性視為等同，會令處理人員轉向不同團隊及採取不同介入措施。
這正是「可採取行動」需要具體定義的原因。一項有用發現應指出受影響的工作、呈現相關證據、說明不確定性，並建議相稱的應對方式。它的價值在於為處理事故的人減少模糊空間。
因此，這次推出帶來的是評估議程，而非既定的效能判決。買家可以詢問，一項發現是否能縮短調查時間、避免不必要的變更，或識別出現有工具漏掉的問題。每個問題都需要真實營運中的證據。
NVIDIA 的公告確立了其預期方向。但單憑公告本身，並不能證實每個客戶環境都會獲得可量度的改善。把這些主張分開看，能讓營運者更清楚判斷產品應放在何處。
有用產出為基礎設施團隊帶來壓力
基礎設施擁有人與應用程式擁有人，往往會以不同問題看待同一事故。一方會問機器是否健康；另一方則會問工作負載是否正確且準時完成。共享的營運視圖必須保留兩種觀點。
有用產出為這些團隊提供共同目標，但仍需要對成功作出一致定義。
對訓練而言，該定義或包括朝模型 checkpoint 的有效進展；checkpoint 是用於延續或復原工作的已儲存狀態。對推論而言，即運行已訓練模型的過程，該定義或包括在服務目標內交付可接受的回應。
這些例子是評估標準，並非已報道的 Minerva 客戶成果。它們說明了為何設備活動不能解答每一項營運問題。系統可以仍然可用，但工作卻停滯；工作亦可以完成，卻錯過令其具價值的期限。
壓力首先落在維護共享運算環境的平台工程師身上。他們需要足夠背景資料，才能判斷警示涉及的是個別工作負載、共享依賴項，還是基礎設施問題。責任歸屬會隨此區分而改變。
應用程式團隊亦面對相關責任。如果他們希望基礎設施發現反映用戶影響，就必須提供相關工作負載資料。當組織的優先事項從未進入其資料或政策時，營運平台無法可靠地推斷那些優先事項。
容量規劃也變得更具挑戰。在批准增添設備前，買家應了解現有資源為何未能滿足需求。營運證據可協助區分容量不足，與工作在其他環節受延誤的情況。
兩者皆非自動得出的答案。更多硬件可能解決真正的短缺，也可能令原有瓶頸絲毫未變。更佳可見性的價值，在於讓組織投入資源前能為這項選擇提出理據。
業務擁有人也必須參與。他們決定哪些成果重要，以及可接受哪些取捨。更高的產出率或許值得追求，但組織仍需就回應品質、完成期限及可靠性訂定要求。
這帶來一個實際的管治問題：誰來判定某項營運變更改善了服務？基礎設施團隊可核實設備行為；應用程式擁有人可評估工作負載成果；服務擁有人則必須將這些發現與承諾的體驗相互協調。
對開發人員而言，後果很直接。一項緩慢的工作應附帶足夠背景資料，以支持跨團隊調查。對企業買家而言，監控要求應在供應商開始展示個別功能前，先與生產目標相連繫。
NVIDIA Minerva 的推出，為這些討論提供一項可供評估的具體產品。更廣泛的責任仍由營運者承擔：他們必須為自身工作定義何謂具生產力的基礎設施。
AI 工廠可觀測性依賴互相連繫的證據
技術挑戰始於 AI 模型作出任何解讀之前。訊號必須描述相關系統、帶著可用的背景資料到達，並在整個調查過程中保持可比較。欠缺背景資料，即使收集到詳盡的測量數據，也可能削弱其價值。
OpenTelemetry 訊號為這項區分提供有用參考。其框架涵蓋收集、處理及匯出營運資料，包括 metrics（隨時間變化的測量數據）、logs（已記錄的事件）及 traces（追蹤工作如何穿越系統組件的紀錄）。
只有當處理人員能將更多訊號連繫到同一營運問題時，收集更多訊號才有幫助。
想像一項示例性服務，其回應時間在部署後惡化。同期 GPU 活動亦出現變化。一項有用調查必須確立，到底是部署、設備行為，還是另一個依賴項導致惡化。
時間關係提供線索，卻不能證實因果。事件可以重疊而不共享同一源頭。一項令人信服的發現，應顯示為何某個解釋較其他替代解釋更符合證據，並指出哪些部分仍屬未知。
系統身分同樣重要。處理人員需要知道，在受影響時段內，哪個工作負載使用了哪些資源。當測量數據與事故的關係仍不清楚時，即使非常精確，其用處也會下降。
軟件變更亦然。如果應用程式修訂改變工作如何到達硬件，設備層面的比較可能需要額外背景資料。否則，工作負載行為的正常變化可能看似基礎設施退化。
自動化解讀的承諾正是在此變得重要。能夠排列最可能解釋的模型，可協助處理人員聚焦注意力。其實際價值取決於該排序的品質，以及可供檢視的證據。
解釋亦應區分觀察與推論。「這項測量數據改變了」與「這項改變導致減速」是不同陳述。營運者需要兩類資料，而且應有清晰標示，以評估建議。
行動邊界再增添一層考量。建議展開調查，與變更正在運行的服務，帶來不同後果。買家應檢視擬議行動如何獲得批准、其效果如何被記錄，以及不成功的變更如何撤回。
這些是營運評估問題，並非對 Minerva 實作方式已獲確認的描述。公開產品定位無法回答有關證據處理、權限或復原行為的所有問題。部署文件及客戶經驗必須填補這些空白。
即使平台偏好的解釋是錯誤的，它也應保持有用。處理人員需要接觸底層證據及其他假設。一個鼓勵不加質疑地接受結論的介面，會削弱調查過程。
因此，重要機制是一條鏈：互相連繫的觀察支持解釋，解釋支持決策，決策產生結果。逐一評估每個連結，比起單獨評估模型的複雜程度更具資訊價值。
現有監控工具塑造 Minerva 的採用方式
Minerva 進入的是一個買家已有營運投資的市場。這些投資包括監控配置、事故工作流程、責任規則，以及對反覆故障累積的知識。採用與否，部分取決於新平台如何融入這個工作環境。
Datadog 的 GPU 監控 文件說明了對 GPU 基礎設施、工作負載及可用容量的可見性。其 GPU Monitoring Explorer 將工作負載視圖連繫到底層基礎設施，並突顯可能降低覆蓋範圍的安裝缺口。
這顯示了相關重疊，但並不能證實產品等同性。買家仍須比較支援的環境、調查深度、部署要求，以及自身營運需要。共用的類別標籤無法解決這些差異。
採用上的問題，是 Minerva 在既有營運技術堆疊中應承擔哪些責任。
NVIDIA 的 Minerva 產品頁面 說明其洞察可輸送至外部可觀測性系統及 AI 工具。這種定位為整合留下空間，但並不代表每位客戶現有的工作流程都能無須額外工作便完成連接。
買家或會希望採用專門的基礎設施分析，同時保留現有的事故管理流程。另一些買家則可能偏好更整合的營運介面。兩種做法都需要清晰界定警報、證據及行動審批的責任歸屬。
OpenTelemetry 在這項比較中扮演不同角色。它有助標準化營運資料的產生及傳輸方式，但本身並不能取代營運人員所需的所有分析、儲存或事故應對功能。
真正重要的分別，在於收集證據、詮釋證據及採取行動之間的界線。產品可在這些功能上有所重疊，同時仍服務於不同的組織需求。採購比較應明確識別這些界線。
對既有供應商而言，NVIDIA 的進場帶來一個實際的競爭問題：其現有平台能否以足夠深度解釋 AI 基礎設施的行為，以滿足要求嚴格的營運人員？對 NVIDIA 而言，問題則在於如何整合至其硬件周邊的營運環境。
兩個問題都不需要作出贏家通吃的預測。如果組合能減少調查工作量，企業可同時採用專門分析及較廣泛的監測工具。若整合成本超過新增資訊的價值，企業亦可選擇不增加工具。
舉證責任應放在具代表性的事故中。買家應比較各種方案如何處理相同的工作負載問題，並使用在相同階段可取得的證據。否則，示範可能獎勵的是展示效果，而非調查實用性。
團隊亦應把營運交接納入比較。調查結果必須送達理解其含義並有權回應的人員手上。即使技術解釋非常詳細，若送達錯誤的工作流程，仍可能失效。
對工程組織而言，持久保存的事故知識應放在可搜尋的知識庫中。記錄決策及已驗證的補救措施，有助未來的應對人員判斷新的建議是否符合過往經驗。
這一知識層的用途有別於即時監測。它保存組織圍繞事故作出的推理，包括為何某項建議修正方案獲接受、修改或拒絕。
產能主張需要營運驗證
最明顯的不確定性在於已展示的成果。本文檢閱的發布材料並未證實，在具代表性的客戶環境中存在經獨立驗證的改善。在有支持證據出現前，讀者應將預期效益視為公司的主張。
可信的評估必須在既定條件下，把調查結果連結至更佳的營運成果。
AI 工廠產能作為一種框架具參考價值，因為它將焦點引向生產。然而，作為衡量指標，它需要明確界線。買家必須知道哪些工作會計入、包括哪些故障，以及結果如何比較。
Token 產出說明了這個問題。產出數量增加，並不能確定回應是否符合應用程式要求。評估在比較營運變更時，應保留相關的品質及服務限制。
訓練亦帶來自身的問題。完成的工作必須對項目維持有效和有用。當失敗或重複工作影響結果時，較高的活動指標不能取代經驗證的進展。
比較期間同樣重要。不同工作負載可導致不同設備行為，但不代表營運較佳或較差。評估應披露足夠背景，以顯示比較條件是否真正具可比性。
警報質素值得獨立關注。偵測到更多異常事件或有幫助，但亦可能增加所需的調查工作量。營運人員應檢視哪些發現值得採取行動，以及應對人員放棄這些發現的頻率。
預測亦應及早送達，才足以影響結果。在工作已經失敗後才提供正確解釋，與能夠預防問題的預警所帶來的效益並不相同。兩者都可能重要，但不應混為一談。
復原亦帶來另一個模糊來源。若服務在介入後有所改善，評估應檢視該介入是否導致改善。無關的工作負載變動可令效果不佳的補救措施看似成功。
這些考慮因素均不代表 Minerva 存在缺陷，而是指出評估平台所述用途時需要的證據。相同問題亦適用於提出可比營運主張的既有監測產品。
部署開銷亦應納入評估。收集及處理營運資料會消耗資源，並需要維護。買家需要在任何已報告的調查或生產力改善之外，一併了解這些要求。
資料存取帶來另一項採購問題。組織應確定哪些資訊會離開受監測環境、誰可以查看，以及可保留多久。具體答案需要產品文件及合約審閱。
審慎的立場很直接：確認發布、檢視其提出的機制，並將性能判斷留待量度結果出現後再作。這種做法讓評估可以推進，而不會把公告當作證明。
營運人員下一步應留意甚麼
下一批有用證據應回答有關部署、成果及整合的問題。這些訊號有助買家將 Minerva 納入營運策略，而毋須單靠發布用語。
最有力的後續資訊，應令產品效益及其運作界線都更容易評估。
首先，留意部署細節。支援的配置、收集要求、工作負載覆蓋範圍及營運相依項目，將決定在哪些地方適合評估。具體文件可透過清楚展示前提條件，加強採用理據。
這些細節亦應說明覆蓋不完整時會發生甚麼情況。營運人員需要分辨健康的環境，與平台無法完全觀察的環境。清晰的限制有助提升對其餘發現的信心。
其次，留意與明確營運問題掛鈎的客戶證據。有用的案例應說明工作負載、最初問題、Minerva 提供的證據，以及最終決策。它應區分量度結果與客戶觀感。
若比較結果披露基準，資訊價值將尤其高。當讀者知道團隊此前如何調查時，更快的調查才更具意義。當工作負載及服務要求保持可比時，產出改善才更具意義。
包含未成功發現的證據亦會有幫助。營運人員需要了解平台在哪些地方增加價值，以及哪些地方仍必須依賴人手調查。一項界線審慎的結果，比廣泛的成功主張更能支持穩健的採購決定。
第三，留意整合證據及既有供應商的回應。與現有監測及事故工作流程的具體連接，可支持 NVIDIA 圍繞外部系統的定位。買家應檢視這些連接能否在整個調查過程中保留有用背景。
既有供應商的回應可釐清競爭壓力集中在哪裏。更深入的硬件分析、更清晰的工作負載背景，或更佳的事故處理，各自針對同一營運問題的不同部分。
這些訊號應一併評估。廣泛部署支援若沒有量度成果，效益仍然不確定。狹窄環境中的強勁結果，則需要在其他地方審慎詮釋。整合主張需要來自營運人員實際使用工作流程的證據。
NVIDIA Minerva 的發布，為 AI 基礎設施團隊帶來一個可供研究的新平台，以及一組可供驗證的具體主張。隨着部署指引及客戶成果揭示所提出連接的實際運作成效，其相關性將更為清晰。
目前，應選擇一個反覆出現的生產問題，並界定解決它所需的證據。使用相同工作負載及服務要求，將建議平台與現有調查流程比較。記錄哪些發現改變了決策、哪些需要修正，以及回應是否改善結果。把這些結果連同團隊的營運文件保存，讓未來事故能受惠於這次評估。檢閱 NVIDIA Minerva 發布報道時，應優先考慮將特定觀察連結至經驗證結果的證據。哪一宗尚未解決的事故，最能讓你的團隊判斷這種方法是否改善其工作？
