OCI 上的 NVIDIA Vera Rubin 擴展至多吉瓦規模，CPU 角色更為重要
NVIDIA 與 Oracle 於 10 月 27 日宣布規劃中的多吉瓦擴展，同時宣布 NVIDIA Vera Rubin on OCI 正式全面推出。這項發布結合新增 GPU 容量與供模型呼叫之間工作使用的獨立 Vera CPU。其意義不只在於更大的叢集：客戶可隨應用程式需求變化，獨立擴展這些資源。
OCI，即 Oracle Cloud Infrastructure，正向開發 agent 的開發者推廣這種彈性；agent 是會呼叫模型並執行工具的軟件系統。這類應用程式會在產生答案與執行一般運算工作之間交替進行。購買更多模型服務容量，並不會自動令周邊工作更快完成。
核心張力在於擴展已部署的運算容量，同時保持該容量高效運作。Google Cloud 已透過 Ironwood 和 Axion 推廣協調式 CPU 與加速器基礎設施。Oracle 的公告令同一層面的系統競爭更受關注，亦令 NVIDIA 的 CPU 業務在 GPU 以外佔據更明顯的位置。
OCI 上的 NVIDIA Vera Rubin 結合現有供應與擴展計劃
即時產品推出與規劃中的基礎設施擴展，代表不同的里程碑。
在雙方聯合發布的 Vera Rubin 擴展計劃中，NVIDIA 與 Oracle 區分了目前可供使用的服務與未來規模。Vera Rubin NVL72 系統及 Vera CPU 已在 OCI 正式全面推出。至於以這些系統將 OCI Superclusters 擴展至多吉瓦規模，仍屬既定計劃。
這項區分對解讀標題的讀者相當重要。正式全面推出代表已建立商業供應，並不表示整個規劃中的擴展已完成安裝、通電、預留，或正為客戶工作負載提供服務。
吉瓦衡量的是電力，而非已完成的運算工作。要把電力承諾轉化為實用的 AI 服務，還需要設備、網絡、冷卻、軟件及客戶部署。因此，標題描述的是預期的基礎設施規模，並未證明相應規模的應用程式輸出已交付。
機架本身提供了更具體的參考點。NVIDIA 的 NVL72 規格描述了一套結合 72 枚 Rubin GPU 及 36 枚 Vera CPU 的配置。GPU 即圖像處理器，負責模型訓練及推理所需的平行運算；推理則是產生模型輸出的過程。
這些組件在機架內協同運作，但獨立 CPU 供應回應的是另一種採購決策。運行工具執行或應用程式服務的客戶，需要緊密連接的模型服務系統以外的運算容量。Oracle 與 NVIDIA 表示，客戶可獨立擴展 CPU 及 GPU 資源。
實際意義在於客戶組裝應用程式時有更大彈性。團隊未必需要在某個階段出現擠塞時，同時擴展每一個資源池。他們可以評估究竟是模型生成、程式碼執行、檢索，還是其他步驟需要額外容量。
這是一項架構選項，而非自動提升效率。應用程式仍需要有軟件把工作導向合適資源，並在需求變化時作出回應。獨立擴展讓營運人員多一項控制手段；並不會決定他們應如何使用。
對買家而言，這項公告帶來有關供應與交付的不同問題。他們現時可以取得哪些配置？可在哪些地點取得？Oracle 可在其部署期內承諾提供多少容量？
這些問題亦決定了應如何看待擴展計劃。龐大的未來規模為長期採購提供有用背景；具體的資源分配、支援的配置及部署時間表，則為工程決策提供更即時的證據。
Agent 工作負載令模型呼叫之間的運算承受壓力
這項公告令主要按 GPU 機隊衡量 AI 容量的團隊面臨壓力。
模型回應只是 agent 工作的一部分。選定行動後，應用程式必須執行它、檢視結果，並決定下一步。這些階段帶來不同的運算需求和不同的延遲來源。
設想一個示例：某個 coding agent 的任務是修復失效的應用程式。它檢索專案檔案、要求模型提出修改方案、運行測試，再把結果交回作出下一輪決策。模型與測試執行器執行的是不同工作，儘管使用者感受到的是一項連續任務。
當生成是瓶頸時，增加模型服務容量會有所幫助。但如果測試正在等待執行環境，或花時間編譯依賴項，這樣做的作用便有限。真正相關的問題是工作流程在哪裏等待，而不是哪個組件的規格最亮眼。
NVIDIA 與 Oracle 明確指出，執行工具、測試程式碼及檢索資料，均是支援 agent 的 CPU 密集型工作。CPU，即中央處理器，運行一般應用程式指令，並管理大量這類周邊工作。兩家公司將獨立 Vera 容量定位為可分開支援這些階段的方式。
Oracle 的 Vera CPU 部署提出一項規模說法：初始部署為 150,000 枚 CPU。Oracle 亦描述了早期客戶存取情況，並表示 OpenAI 正將 Vera 投入 agentic 工作負載的生產環境。這些均是透過 Oracle 刊物提出的供應商及客戶說法。
CPU 數量顯示 Oracle 為該服務設定的規模，卻沒有揭示某個客戶可預留多少處理器、其運行負載有多高，或可提供多少應用程式吞吐量。這些區分可避免部署規模取代營運證據。
即時壓力落在基礎設施規劃者及 AI 應用程式團隊身上。他們需要理解模型請求與這些請求觸發的工作之間的平衡。若採購流程只聚焦加速器數量，這項平衡便會被忽略。
這不代表每個 agent 應用程式都需要專用 CPU 部署。有些工作流程大部分時間都在等待外部服務；另一些則產生很長的模型回應，但工具執行相對較少。合適的資源組合取決於應用程式實際的操作順序。
同一原則亦適用於知識工作流程。搜尋 AI 知識庫的助理，必須先檢索相關材料，才能產生有用答案。額外的生成容量無法補償無法存取的文件、缺少的權限或緩慢的檢索。
對企業買家而言，這將基礎設施決策與使用者體驗連結起來。任務在流程任何一處停滯，服務都會令人覺得緩慢。客戶很少會區分延遲是來自模型、工具、資料庫，還是協調它們的軟件。
因此，這項公告鼓勵採用更廣泛的評估標準。團隊應詢問基礎設施如何支援完成一項任務，包括其中間步驟。這正是發布帶來的壓力：解釋應用程式效能，變得與描述已部署硬件同樣重要。
獨立擴展回應的是排程問題
分開擴展 CPU 與 GPU，只有在應用程式能有效運用這種分隔時才會有幫助。
從架構層面看，OCI 上的 NVIDIA Vera Rubin 背後機制相當直接：模型需要緊密連接資源時，就把它們保持在一起；至於需求模式不同的周邊工作，則提供獨立運算容量。
NVIDIA 的 Rubin 平台架構描述了一個圍繞協調運算、網絡及軟件而設計的系統。NVLink 是 NVIDIA 處理器之間的高速連接，支援模型運算系統內的通訊。這種內部連接的用途，與配置獨立的工具執行工作池不同。
這項區分避免了一個常見誤解。獨立擴展並不表示 NVL72 機架內每個組件都會獨立變動。它描述的是客戶如何在整體應用程式基礎設施中，擴展不同的 CPU 及 GPU 資源。
回到 coding agent 的例子。測試活動突然增加時，可能需要額外執行工作程序，而模型需求則維持相對穩定。另一種工作負載則可能產生更多模型請求，卻不會相應增加編譯或測試需求。
固定配置可能令一個資源池使用不足，另一個則形成佇列。獨立資源池讓營運人員可以調整這種失衡。收益取決於其軟件能否辨識瓶頸，並及時配置有用容量。
這正是排程——即把工作分配給可用資源——變得關鍵的地方。應用程式需要決定工具在哪裏運行、接收甚麼資料，以及結果何時返回。若工作無法有效到達額外處理器，單靠更多處理器仍是未完整的答案。
資料放置令決策更複雜。工作程序需要存取檔案、依賴項、憑證及相關應用程式狀態。把執行工作從模型服務基礎設施移開，會形成另一道需要由軟件管理的邊界。
這道邊界本身並非缺點。它可支援更清晰的資源分配及隔離。不過，買家在評估獨立資源池的好處時，應計入其營運影響。
有用的評估方式，是追蹤一項具代表性的任務由提交至完成的全程。它會記錄產生模型輸出、等待工具、運行程式碼、檢索資訊及重試失敗步驟所花的時間，目的是找出額外容量在哪個環節能改變結果。
成功完成同樣重要。若更快的執行帶來更多失敗任務，或需要額外嘗試，其價值便會下降。有意義的比較應保持任務及驗收標準不變，同時檢視所消耗的資源。
這些是評估原則，而非公告所發布的結果。它們說明了甚麼證據可支持兩家公司提出的效率論點。發布確立了可用架構；客戶量度結果才可確立其對特定應用程式的價值。
當工作負載隨時間改變時，營運挑戰會加劇。現時主要回答問題的服務，在產品更新後可能會執行更多行動。只要應用程式提供營運人員所需資訊，獨立擴展便能提供應對空間。
這令 CPU 供應不只是 GPU 發布的附屬品。它為 NVIDIA 與 Oracle 創造了另一個可參與應用程式基礎設施的位置。客戶能否受惠，取決於這套基礎設施與他們實際工作內容的匹配程度。
雲端競爭對手正圍繞完整 AI 應用程式競爭
Oracle 的公告屬於一場圍繞協同系統的競爭，其中包括支援 AI 模型的通用運算能力。
Google Cloud 提供了一個有用的比較對象，因為它明確將加速器與 CPU 的開發連繫起來。其 Ironwood and Axion 公告討論了 agent 工作流程所需的協調。Ironwood 是 TPU，即 Google 為機器學習設計的專用處理器，而 Axion 則支援通用運算。
其關聯性在於架構。Google 將模型加速與所需的應用程式服務、資料準備及其他相關工作一併描述。Oracle 和 NVIDIA 現正透過 Rubin 系統及可獨立取得的 Vera CPU，強調相近的需求。
這並不代表產品或效能相等。各平台的處理器、軟件環境、服務供應及部署安排均有不同。不過，它們的公告均指向一個共同的採購問題：完整系統對應用程式的支援程度如何？
對 Oracle 而言，獨立 Vera CPU 令討論範圍擴展至 NVIDIA 加速器的存取以外。公司可推介用於模型服務，以及其周邊執行工作的資源。客戶在決定應在哪裡運行其 agents 時，便多了一種配置可供評估。
對 NVIDIA 而言，這項公告延伸了其 CPU 在整合式機架以外的商業重要性。如果客戶採用 Vera 作獨立的執行服務，NVIDIA 便能參與其更大部分的運算架構。
這個機會不應被視為普遍遷移的理由。現有應用程式帶有既定的依賴關係和營運做法。團隊必須權衡新配置的價值，以及採用和維護它所需的工作。
競爭壓力亦延伸至傳統伺服器部署。考慮 Vera 的買家會希望與目前運行其工具和應用程式服務的系統作比較。熟悉的基礎設施提供實際基準，因為團隊了解它在自身工作負載下的表現。
因此，最有力的比較應由客戶現有的應用程式開始。它會檢視改變執行平台，是否能改善任務完成情況、回應速度、資源消耗或營運可靠性。元件層面的優勢只處理了這項決定的一部分。
軟件延續性同樣重要。已建立模型服務環境的公司，會考慮新配置如何融入其部署和支援流程。任何忽略這些流程的硬件評估，都會低估採用所需的工作。
這正是競爭敘事應與沒有根據的勝出宣稱分開看待的原因。Oracle 的推出擴展了其可用選項。Google 的 CPU 和加速器策略提供了相關背景。兩項公告均未證實哪一個平台能為每種 agent 工作負載帶來最佳結果。
更廣泛的轉變，在於供應商要求客戶評估的內容。加速器規格仍然重要，但支援執行環境日益進入同一場討論。基礎設施供應商必須說明其元件如何在整個任務中協同運作。
對追蹤 OCI 上 NVIDIA Vera Rubin 的讀者而言，這是最有用的競爭框架。標題談的是更大型的基礎設施承諾；採購決定則取決於某個特定服務組合，是否能比現有安排更有效地支援應用程式。
供應情況及處理器數量仍留下重要問題
這項公告確立了產品和計劃，卻未能證實客戶生產力會普遍提升。
首項不確定性涉及正式推出與實際存取之間的關係。公開發布並不代表每位客戶的配額、部署地點或交付時間表均已確定。買家需要這些資料，才能將公告轉化為實施計劃。
第二項涉及計劃中的多吉瓦規模。公告描述了擴展，但標題本身沒有提供完整的交付時間表。隨着更多資訊公布，讀者應區分預期規模與實際運行容量。
第三項涉及應用程式成果。大規模 CPU 部署和新一代 GPU，本身並不能量化 agent 完成有用工作的速度會快多少。這需要明確定義的工作負載，以及與清晰基準作比較。
Oracle 的發布內容包括效能聲稱，但除非有可由獨立人士評估的方法論支持，否則仍屬公司說法。買家應檢視任何宣傳改善背後的配置、軟件、工作負載及量度範圍。
這個範圍對 agents 尤其重要。量度處理器的執行速度，與量度包含模型呼叫和外部服務的完整任務並不相同。某一階段的改善，並不代表整個工作流程也有同等改善。
資源使用率與客戶價值之間也有分別。繁忙的處理器可能正在處理具生產力的工作、重試，或不必要的運算。只有當高活動量有助產生獲接受的結果時，才有意義。
相反，部分閒置容量具有營運用途。應用程式可能需要保留餘裕，以應付突發流量、故障或回應時間要求。評估應區分可避免的浪費，以及為履行服務承諾而保留的容量。
獨立擴展亦將決策責任轉移至應用程式營運者。團隊必須決定何時增加容量、保留多少，以及依賴項失效時如何應對。靈活性很有價值，但同時引入需要量度和營運判斷的選擇。
安全性增加了另一個維度。執行生成程式碼的 agents 需要控制其環境和存取權限。sandbox，即隔離的執行環境，會限制該程式碼可接觸的範圍，但其成效取決於周邊實作。
客戶應連同吞吐量，一併評估執行權限、資料處理及故障隔離。存取權限不當的更快工作程序，並不能建立更好的生產系統。當 agent 擷取專有資訊，或透過已連接的企業工具採取行動時，這點尤其重要。
遷移則帶來另一個問題。將應用程式移至不同的 CPU 環境，需要檢查軟件依賴關係及部署相容性。所需工作取決於應用程式，因此一項廣泛的推出公告無法為每位客戶解決這個問題。
這些不確定性並不否定這次推出。它們指出了準確判斷所需的證據。這些公司已公布一個具有清晰架構理據的基礎設施選項；最終營運效益仍取決於工作負載。
因此，審慎的解讀應具體明確。獨立的 CPU 和 GPU 資源，讓客戶多了一種應對供需不匹配的方式。此選項是否能減少浪費或改善回應速度，必須透過應用程式層面的結果證實。
關注容量存取、客戶量度和執行軟件
下一批證據應把已公布的基礎設施，與可取得的容量和已完成的客戶工作負載連繫起來。
第一個訊號是更具體的存取資訊。在未來數月，客戶應留意支援的配置、部署地點、分配條款和擴展里程碑。這些詳情將說明已公布產品如何轉化為實際容量。
更具體的交付資訊，將加強擴展能支援近期客戶規劃的論據。若持續強調整體規模，卻沒有相應的存取詳情，這部分敘事仍會較不明朗。
這個訊號對 GPU 系統和獨立 CPU 都分別重要。採用其中一種的客戶，未必與採用另一種的客戶有相同要求或時間表。分別提供供應資訊，將令獨立擴展的主張更易評估。
第二個訊號是客戶對完整工作流程的量度。有用的證據應描述應用程式、原有配置、改變後的資源及驗收準則，亦應說明任務完成情況和資源消耗有何變化。
例如，對 coding agent 的評估應包括執行和測試，而非止於模型生成。檢索應用程式則應包括存取其底層資訊。當比較跟隨用戶任務跨越這些邊界時，說服力會更強。
若有證據顯示新增 Vera 容量消除了已量度的執行限制，便能支持這次推出的核心論點。若結果顯示大部分延遲發生在其他地方，則會縮窄相關使用案例。無論哪一種結果，都有助買家作出更明智的決定。
第三個訊號是令獨立資源池更易營運的生產軟件。留意應用程式如何處理工作程序分配、資料存取、執行狀態及故障。這些能力決定獨立資源能否作為協調服務運作。
這個訊號值得關注，因為硬件選項不會自動造就可用的應用程式架構。營運者需要足夠可視性，以了解工作在哪裡等待；也需要足夠控制能力作出回應。更佳協調可加強效率理據，而毋須每個元件都同等改善。
合起來看，這些訊號提供了一種務實方式追蹤 OCI 上的 NVIDIA Vera Rubin。容量披露涉及交付；客戶量度涉及價值；執行軟件則涉及連接可用元件的實際工作。
對開發者而言，這項公告是檢視自身 agent 工作流程在哪裡花費時間的理由。對企業買家而言，這是要求應用程式層面證據的理由。對用戶而言，相關結果仍是一項能可靠完成有用工作的服務。
在承諾採用新基礎設施配置前，應讓一項具代表性的任務走完整個系統，並找出其真正限制。要求供應商區分可用容量與計劃擴展，以及元件聲稱與已量度的應用程式結果。評估中應包括執行、檢索、故障和復原。比較不同方案時，應保持工作負載和驗收準則一致。這種做法可公平評估 OCI 上的 NVIDIA Vera Rubin，同時令採購決定緊扣客戶需要完成的工作。額外 CPU 或 GPU 容量會改善你應用程式的哪一個階段？又需要甚麼量度來證明該項改善？
