企業願意將模型放到雲端，但未必願意讓訓練資料、客戶輸入或模型權重暴露在基礎設施管理環節中。Google Cloud 在10月21日宣佈，搭載RTX PRO 6000 Blackwell Server版GPU的Confidential G4已從預覽階段進入一般可用狀態，覆蓋36個可用區，可應用於Compute Engine虛擬機和GKE節點。這則消息的重點不在於「又有一款GPU」，而在於密碼計算開始進入企業高強度AI工作負載的常規採購清單。不過，一般可用並不等於任何AI任務都已自動獲得端到端保密，安全結論仍取決於配置、證明及應用本身。

硬體保護解決了哪一環風險？

Google 在官方說明中強調，Confidential G4 將硬體支援的內存加密、不可導出的硬體密鑰以及可驗證的遠端證明結合起來，試圖保護運行中的數據及模型參數。傳統的數據加密通常會覆蓋儲存和傳輸過程，但當真正開始計算時，數據卻需要進入內存。機密計算所要縮小的正是這段暴露面：讓工作負載在受到硬體限制的執行環境中運行，並能向調用方提供環境狀態的證明。對於將專有模型權重託管在雲端、或處理敏感客戶資料的公司而言，這比單純給磁盤加密更加切題。

但「證明環境可信」與「證明業務正確」並非一回事。遠端證明可以輔助驗證程式在預期的硬體和配置中運行，無法替代輸入清洗、模型輸出核查，也不能自動發現應用邏輯的漏洞。企業仍須弄清證明材料由誰簽發、驗證方如何檢查、鏡像與驅動更新後證明是否變化，以及密鑰在什麼條件下交付給工作負載。如果驗證步驟僅停留在供應商示範階段，而沒有融入上線和故障處理流程，硬體能力就很難成為真正的控制措施。

Google 同時指出，Confidential Space 對安全多方數據共享的支持將在未來幾周內逐步達到一般可用狀態。這與已經一般可用的 Confidential G4 實例並非同一上線狀態。如果將兩者描述為「所有機密數據協作功能已全面上線」，將會誤導那些準備設計跨機構工作流的團隊。應用能否使用這些功能，還取決於所處地區、實例規格、GKE 配置以及具體服務限制，而不能僅從「36個可用區」就推斷每種組合都能立即部署。

企業需要檢驗的並不只是一句「零信任」

將 GPU 纳入機密計算之後，產品的經濟性才真正開始接受實際業務的檢驗。安全團隊關心數據使用過程中的暴露風險，工程團隊關心吞吐量、延遲、驅動兼容性以及運維複雜度，財務團隊則關注每次任務的總成本。Google 在公告中引用了客戶對部署體驗和性能的積極評價，但这些只是特定案例，不應該被視為所有模型、所有批量任務的普遍結果。尤其是在多卡訓練、複雜網絡通信以及頻繁加載權重的場景下，企業需要用自己的鏡像、數據規模和性能基線來進行對比。

實際的試點可以從三個問題開始。第一，哪些敏感數據在運行時需要保護，風險來自雲管理員、宿主環境，還是應用程序自身的調用鏈？如果主要的數據泄露風險是終端用戶誤傳數據，或是代理將內容發送至第三方工具，那麼僅保護 GPU 内存是不足的。第二，工作負載的啟動、擴縮容、升級與回滾是否都納入到證明和密鑰策略中？第三，審計人員獲得的證據能否將一次真正的業務任務與一組可驗證的硬件狀態連在一起，而不仅仅是看到一張產品宣傳圖？

市場意義也在于采購門檻的下降。過去機密 GPU 常被視為少數高度定制的項目；現在變得普遍可用了，這意味著它進入了標準雲產品的支持、計費和運維體系。企業因此能更輕鬆地将隱私保護納入常規架構評審中，而不必在最後為敏感項目另行打造一套計算能力環境。然而，“更容易部署”仍不等於“無需治理”：權限過寬、日誌洩露、外部工具的調用以及輸出側數據的殘留都可能繞開受保護的計算區域。

Google 此次發布確實將機密計算推向了大規模的 AI 服務，但邊界必須明確：Confidential G4 實例已經可以一般使用，而 Confidential Space 相關支持仍在逐步推出中。最穩妥的判斷方法不是問「它是否絕對安全」，而是選擇一個真實但可控制的敏感工作流程，記錄硬體證明是否可以獨立驗證、性能和成本是否可接受、在發生故障時是否可以安全降級。只有這些指標都通過，硬體層的新能力才能轉化為企業敢依賴的生產能力。

還需要查看保護範圍之外的數據去向。一次推理任務可能會將提示詞送入隊列，將中間狀態寫入臨時文件，再將結果交給日誌、監控和下游插件；這些環節不一定都處於同一的機密執行邊界。設計試點時，應畫出輸入、計算、輸出和備份的完整數據流，逐處標明誰能訪問、保存多久、如何刪除。只有將硬件證明與這張數據流圖對上，採購者才能知道自己買到的是哪一段保護，而不是將一個產品名誤認為是覆蓋全系的統的隱私承諾。