OpenAI 模型將登陸 Google Cloud，把模型選擇納入 Google 平台

儘管 OpenAI 在 AI 領域直接與 Google 競爭，仍正把旗下模型帶到 Google Cloud。OpenAI 模型將透過 Google 的模型探索及存取平台 Model Garden 登陸 Google Cloud，並可經由 Google Cloud Marketplace 購買。這項合作於 10 月 21 日公布，將競爭對手的技術納入 Google 的企業銷售渠道。

這項商業變化與模型存取本身同樣重要。持有合資格 Google Cloud 消費承諾的客戶，將可把該等承諾用於 OpenAI 採購。這帶來另一種採購決策：選擇 AI 模型，未必同時需要改變雲端服務關係。

核心張力在於模型靈活性與平台依賴之間。Google 多了一個讓客戶把 AI 工作負載留在其環境內的理由；OpenAI 則可在這些客戶之中擴大分銷。OpenAI 表示，Microsoft 仍是其主要雲端合作夥伴；企業買家則多了一條使用其技術的途徑。

OpenAI 模型將分階段透過 Google Cloud 推出

合作關係已獲確認，但公告並不代表今日已可無限制地取得生產環境存取權。

OpenAI 的雲端模型整合涵蓋前沿模型，即其能力最強的通用系統，並包括 Codex 工作流程。Codex 是 OpenAI 的軟件工程代理，可利用程式碼及工具處理開發工作。OpenAI 表示，預計將於未來數周正式全面推出。

截至 10 月 22 日，關鍵分別在於已公布的目的地，與個別客戶實際可取得的存取權。圍繞這項合作規劃的企業，需要確認自己的帳戶適用於哪個階段。單憑推出公告，未足以解答這個問題。

Google 對初始目錄的描述更為具體。Google 指出，GPT-6 Astra、GPT-6.1 Sol 及 GPT-6 Luna 將向指定企業客戶提供私人預覽。Google 亦提到，會把本機 Codex 開發工作流程連接至其平台，以進行模型處理。

這些細節令這項協議有別於泛泛而談的合作承諾。已命名的模型與界定清晰的預覽，讓客戶有具體內容可供評估。不過，預覽仍只是評估機會，其條件與廣泛可用的服務不同。

採購途徑亦值得審慎表述。Model Garden 提供模型存取及探索層，Marketplace 則處理商業交易。兩者是方案中相互關聯的部分，但分別回答企業如何採用該方案的不同問題。

對開發人員而言，眼前問題在於可用能力；對採購團隊而言，則在於購買資格；對應用程式負責人而言，則在於服務是否獲批准用於預定工作負載。這項合作把這些決策連結起來，但不代表它們完全相同。

公告亦指向在 Google Antigravity 和 Gemini Agent 中提供存取。這些計劃中的整合，令故事不止於為自訂應用程式選擇模型，也讓 OpenAI 技術更貼近人們日常工作的開發工具及代理體驗。

不過，這些目的地不應被視作可互換的推出承諾。經由 Model Garden 存取，並不代表所有其他整合都具有相同時間表或功能組合。每項產品都需要各自的可用性細節。

因此，這項消息意義重大，但毋須作出誇大解讀。Google 正為 OpenAI 開闢另一個分銷途徑，而 OpenAI 正進入競爭對手模型開發商的企業平台。其影響取決於客戶可透過該途徑購買、部署及營運甚麼。

共用雲端消費改變採購決策

最直接且最具吸引力的商業誘因，是可在既有 Google Cloud 採購關係內評估 OpenAI。

設想一家已在 Google Cloud 上營運應用程式基礎設施的公司。其工程師希望評估使用 OpenAI 開發內部程式編碼助手。在技術表現成為關鍵因素之前，公司必須先確定如何購買、審批及核算該服務。

這項合作改變了起點。OpenAI 表示，合資格採購可動用既有的 Google Cloud 消費承諾。Google 表示，交易將顯示於 Google Cloud 帳單上。兩項說法均不代表每份客戶合約都具備相同資格。

消費承諾是指在合約期內同意採購指定金額雲端服務的協議。將另一項服務納入該承諾，會改變預算分配；但這本身並不表示該服務可帶來較低的總營運成本。

這個分別很容易在新產品報道中被忽略。一項採購或可配合既有預算安排，但仍可能需要大量工程與監督工作。買家需要評估整個工作負載，而不應把熟悉的計費方式視為技術適用性的證明。

儘管如此，商業上的熟悉感具有實際價值。團隊在評估新模型時，可能尚未進行有意義的技術測試，便已面對合約、責任歸屬及開支問題。把採購納入既有關係，可解決部分行政問題。

這會把壓力轉向企業平台團隊。他們需要說明哪些可用模型獲批准、適合哪些工作，以及須在甚麼條件下使用。更大的目錄令缺乏工作負載證據的一概偏好更難合理化。

財務團隊亦獲得更具體的比較方式。他們可檢視建議的模型採購是否符合既有承諾，以及其成果是否足以支持所需的營運投入。這些問題把商業資格與應用程式成果連結起來。

即使客戶在特定工作上選擇 OpenAI 而非 Gemini，Google 仍可受惠。在這項安排下，該選擇仍可透過 Google 的平台進行。不論哪個模型在個別評估中勝出，雲端服務關係本身仍具價值。

OpenAI 則可在另一個成熟的採購環境內滿足企業需求。這是分銷優勢，並非模型表現較佳的證據。這項合作擴大了客戶可考慮其技術的場所。

對競爭性分銷渠道而言，啟示很直接。當另一個供應商把存取權與既有企業帳戶結合時，單靠模型存取便不再是完整方案。支援、管治、可用性及採購條件都會納入比較。

公告中沒有經驗證的採用結果，可證明客戶反應有多強烈。商業機制很清晰，但其對實際工作負載部署的影響仍有待衡量。企業採購會比表達興趣提供更有力的證據。

Google 可在銷售競爭對手模型時爭取工作負載

即使 Gemini 未有取得某項工作負載，Google 的雲端平台仍可從 OpenAI 模型選擇中獲得業務。

這是協議中最明顯的逆轉。Google 與 OpenAI 在模型開發上互相競爭，卻可在企業分銷上合作。這些關係運作於客戶決策的不同層面。

買家同時選擇模型，以及使用該模型的環境。模型影響應用程式的品質及行為；環境則影響機構如何採購、控制、監察及支援該應用程式。

Google 的企業模型方案把已公布的 OpenAI 目錄與其更廣泛的模型平台結合。Google 提及專用基礎設施、集中式審核及身分識別控制，亦表示部分額外安全功能將於日後推出。

策略上的推論是，Google 希望模型選擇在其企業環境內進行。這個詮釋源於方案結構，而非任何已披露的客戶行為數據。公告並未說明買家會多常切換模型。

競爭背景已支持這個更廣泛的模式。獨立的模型選擇報道指出，Model Garden 已提供 Anthropic 模型、Gemini 及開放模型。加入 OpenAI 擴展了這個既有做法。

因此，較量不僅是 OpenAI 對 Gemini。企業評估一項工作時，可以考慮不同模型家族，同時維持共同的平台關係。真正的競爭在於哪種組合能產生可接受的商業成果。

就程式編碼應用程式而言，成果或包括正確的修改、有用的測試及可管理的審查工作。就文件分析而言，成果或包括根據獲授權材料作出的準確答案。這些只是示例性的評估準則，並非對已公布模型的效能聲明。

這項安排亦改變了對模型競爭的理解。模型可在某項工作中勝出，而其開發商未必擁有完整的客戶關係。雲端供應商亦可保留工作負載，而無須提供獲選模型。

這為合作創造空間，卻不會消除競爭。Google 仍有理由改善 Gemini，OpenAI 亦仍有理由令旗下模型與眾不同。共同分銷不會令其底層產品變得等同。

Microsoft 的定位同樣需要準確表述。OpenAI 明確表示，Microsoft 仍是其主要雲端合作夥伴。單憑與 Google 的協議，並不能證明 Microsoft 已失去這個角色，或客戶正從 Azure 遷離。

可辯護的結論較狹窄，但也更有用。企業取得 OpenAI 的方式，正不再那麼緊密地與單一採購途徑掛鈎。買家多了一個選項，雲端供應商則圍繞整體營運關係展開競爭。

OpenAI 模型將在這場更廣泛的競爭中登陸 Google Cloud。這項合作令模型選擇在 Google 平台內佔據更顯著的位置。然而，它尚未證明客戶可在多大程度上把完整應用程式自由移往其他地方。

Codex 把決策帶入日常開發工作

Codex 令這項合作與軟件交付息息相關，因為模型存取必須轉化為可用的工作成果。

開發層面十分重要，因為工程團隊評估的不只是對單一問題的回應。他們需要了解代理如何處理其儲存庫、遵循指示、使用工具，以及呈交變更以供審查。

代理式工作流程是 AI 利用工具及中間結果來推進任務的過程。這個過程會產生超出底層模型以外的依賴關係。儲存庫存取權、執行權限及審查程序都會影響結果。

OpenAI 的限量預覽存取頁面說明支援的開發及內部評估使用情境。當中提及 Responses API，這是一個用於要求模型輸出及工具互動的程式介面，亦列出可透過支援的開發介面存取 Codex。

預覽版需要邀請。對於正考慮是否應圍繞這項公布安排評估的團隊而言，這點相當重要。登記表示有興趣，並不代表已獲批准、可即時存取，或獲准用於特定生產環境部署。

假設某個工程團隊希望在相依項目變更後，讓代理更新一項內部服務，便可說明實際影響。理想結果包括正確的修補程式、適切的測試，以及讓審核人員可評估的說明。

團隊需要將已完成的工作與目前的開發流程比較。一個看似合理、卻令審核工作增加的修補程式，與工程師可安心接納的改動並不相同。模型能力只是評估的一部分。

運作環境亦會影響代理可完成甚麼工作。無法存取相關文件的編程助手，可能會忽略重要的專案限制；權限過大的助手，則會帶來另一種管理問題。

這正是既有工程知識與雲端決策相關之處。團隊需要可靠地存取設計筆記、內部慣例及過往決策。建立一個可供搜尋的知識庫，可處理與選擇模型不同的另一項相依因素。

這項區分可避免過度解讀這項合作關係。將模型存取移至 Google Cloud，並不會自動提升企業文件的質素；亦不代表每項開發工具都可使用所有已公布的功能。

計劃中的 Antigravity 與 Gemini 整合，帶來另一個分發機會。若開發人員可在熟悉的工具中看到 OpenAI 選項，便能更貼近日常工作地評估它們。這會否成為日常採用模式，仍取決於存取權、實際表現及團隊接納程度。

應用程式擁有者亦應區分本機開發工具與處理模型請求的服務。熟悉的介面可以連接至不同的運作環境；單憑可見體驗，無法說明完整的資料路徑。

對軟件團隊而言，這則消息帶來具體的評估機會。真正有意義的問題是，這條新路徑是否有助在可接受的監管下完成已獲批准的開發工作。這比將 Codex 的出現視為自動帶來生產力成果，更具參考價值。

共用目錄不代表模型可互換

較容易採購及選擇模型，並未解決應用程式行為、復原能力及安全性方面的重要差異。

Google 將彈性視為其平台的核心優勢。買家應區分可選擇另一個模型，與可原封不動遷移整個應用程式的能力。兩者屬於不同的技術及營運主張。

文件助手正好說明原因。應用程式可能依賴特定輸出格式、存取規則及對來源材料的引用。更換模型時，必須檢查這些行為是否仍符合應用程式的要求。

編程代理則會引入額外相依因素。其工作可能涉及檔案、指令、工具結果及已採取的行動。選擇另一個模型，並不能說明未完成的工作如何延續，或如何核實先前行動。

OpenAI 關於供應商故障轉移的指引作出了相關區分。故障轉移是指當原有路徑無法提供服務時，透過另一個供應商重試符合資格的工作。OpenAI 警告，更換供應商並不會自動還原進行中的代理工作階段。

這項指引屬於相關背景，而非這項合作獨有的已記錄限制。它說明即使有多條可用路徑，也不代表應用程式具備韌性。復原能力需要按實際工作流程評估。

同樣的推理亦適用於模型比較。一次成功示範只表示特定工作在特定條件下可行，並不代表在企業可能遇到的每份文件、每個程式碼庫或每項用戶請求中都會有一致表現。

對安全性措辭亦應同樣審慎看待。Google 表示，提示、上下文及輸出內容會保留在指定資料邊界內，且不會用於訓練基礎模型。這些是公司說法，買家應對照適用的服務文件及條款審視。

Google 亦將 Zero Data Retention 選項標示為即將推出。Zero Data Retention 是指在適用條件下，旨在避免保留指定客戶請求資料的選項。其已公布的未來供應時間，不應與每位預覽版客戶現已啟用的控制措施混為一談。

Confidential Compute 亦被描述為稍後推出。這個詞是指旨在於處理期間保護資料的技術。這項公布不足以支持以下假設：這項未來能力已適用於今天正在評估的應用程式。

這些時間上的區分，對受監管機構尤其重要。公司的要求必須配合其實際能夠取得的服務配置。計劃中的控制措施可為未來評估提供參考，但不能滿足目前的部署條件。

整合帳單亦不代表已得出完整的合規結論。一張熟悉的帳單，對哪些應用程式行動獲授權，或敏感資料如何進入提示內容，幾乎沒有說明。這些問題仍然與工作負載本身相關。

審慎解讀並非否定這項協議，而是指出商業承諾在哪些地方需要營運證據。Google 與 OpenAI 已建立通往更廣泛選擇的途徑；客戶仍需判斷這種選擇實際支援甚麼。

這亦是平台依賴可能持續存在的地方。公司或可在模型之間獲得更大彈性，同時更依賴其雲端供應商的周邊服務。模型多樣性與應用程式可攜性應分開評估。

接下來留意存取權、已交付功能及客戶成果

下一項有意義的證據，將來自可用服務及已完成的工作負載，而非更長的合作主張清單。

第一個訊號是正式全面推出。OpenAI 表示時間表在未來數周內，因此具體發布將是最接近的推出測試。買家應尋找可將服務供應情況與其帳戶、地區及預定用途連結起來的文件。

廣泛可存取的服務將強化分發論點，讓更多企業可透過既有的 Google Cloud 關係評估 OpenAI。較狹窄的發布範圍，則會限制這項商業變動的即時影響力。

細節與標籤同樣重要。正式全面推出的公告，應讓人更容易確認支援哪些模型及開發體驗，亦應釐清客戶如何由預覽評估轉向已獲批准的部署。

第二個訊號是交付目前被描述為即將推出的功能。安全選項及產品整合各自帶來實際影響。它們一旦推出，便會擴大客戶可按實際供應方案評估的要求範圍。

清晰的文件將強化這項合作的企業論據，讓買家區分已可用的控制措施與仍在規劃中的措施。持續含糊不清，將令這項公布更難轉化為營運決策。

Antigravity 及其他已公布的 Google 體驗，亦屬於同一觀察範疇。其整合可顯示模型選擇能否超越中央目錄，進入日常工作。在採購平台上可用，與在開發人員偏好的工具內可用，是兩個不同里程碑。

第三個訊號是來自客戶工作負載的證據。有用的報道應說明工作內容、評估條件及最終營運結果。單憑客戶名稱，較難說明這項合作的實際價值。

對開發團隊而言，獲接納的改動及審核工作量，有助解釋採用情況。對企業內容應用程式而言，答案質素及遵守存取規則將更重要。這些是評估成果的建議指標，而非這項公布已證實的結果。

持續使用的證據，將強化共用採購移除了重要採用障礙的論點；整合困難或功能有限的證據，則會為該論點加上限制。兩種結果都比假設存取權必然帶來需求更具資訊價值。

眼前的重點是企業分發模式的轉變。OpenAI 模型正透過一條將模型評估與既有雲端採購連結起來的路徑進入 Google Cloud。這為買家提供另一個選項，也為 Google 提供另一種保留其工作負載的方式。

在下一次評估時，選擇一項具明確負責人及可觀察結果的工作負載。將可用服務與團隊現時信任的流程比較，記錄模型處理了甚麼、審核人員修正了甚麼，以及哪些控制措施適用於實際配置。將採購資格與部署批准分開處理，並區分已承諾功能與可供測試的功能。待正式全面推出及計劃中的整合到位後，再重新審視決定。對於 OpenAI on Google Cloud，最有用的回應是以組織的實際工作為基礎作聚焦比較。哪項工作值得使用這條新路徑，而甚麼證據會令其負責人願意繼續採用它？