NVIDIA and Google Cloud Collaborate to Advance Agentic and Physical AI
blogs.nvidia.com · 2026-04-22
在 Google Cloud Next 2026 拉斯維加斯峰會上，NVIDIA 與 Google Cloud 宣布了一項涵蓋 AI 基礎設施、代理 AI、物理 AI 的大型合作。這不是小型功能發布，而是從晶片、雲端平台、到行業應用的全棧式戰略佈局。
硬體基礎：Vera Rubin GPU 加持的新世代算力
合作核心之一是全新 A5X 裸機實例，搭載 NVIDIA Vera Rubin GPU，官方宣稱可帶來最高 10 倍的推論成本降幅，同時大幅提升 token 吞吐量。對於需要高頻呼叫 LLM API 的代理工作流而言，這個數字相當關鍵——每次 agent 循環中的 LLM 呼叫成本直接決定商業可行性。
規模方面，平台可擴展至 960,000 顆 NVIDIA Rubin GPU 的多站點集群，這是目前業界最大規模的公開算力承諾之一。此外，NVIDIA Blackwell 系列產品線從 A4 VM 到 A4X Max 全面覆蓋，並支援分數化 G4 VM，搭載 RTX PRO 6000 Blackwell Server Edition GPU。工程師可以根據工作負載特性，靈活選擇從邊緣推論到超大規模訓練的不同實例規格。
安全性與機密運算
Confidential G4 VM 是這次合作中最值得關注的安全特性。在多租戶環境中，傳統 VM 共享硬體資源的方式存在側信道攻擊風險。透過 NVIDIA Blackwell GPU 上的機密運算支援，用戶的 prompt 和 fine-tuning 資料可以在加密狀態下處理，即便是雲端供應商本身也無法讀取明文內容。
具體實現方式是 NVIDIA Confidential Computing，它在 GPU 的可信執行環境（TEE）中運行工作負載，確保敏感金融、醫療、法律資料的保密性。Google Gemini 模型在 NVIDIA Blackwell 上運行的版本現已在 Google Distributed Cloud 上以預覽形式開放。
代理 AI 平台整合
代理 AI 方面，NVIDIA Nemotron 3 Super 已可在 Gemini Enterprise Agent Platform 上使用。Nemotron 3 Super 是針對代理推論場景優化的模型，特別適合需要多步驟工具呼叫、規劃、與自我評估的任務。
另一個值得關注的是全新的受管強化學習 API，基於 NVIDIA NeMo RL 構建。這讓工程師無需自行搭建 RLHF 或 RLAF 管線，便可對模型進行基於獎勵的微調——對於希望針對特定業務流程優化代理行為的團隊來說，這大幅降低了準入門檻。
物理 AI 與工業應用
物理 AI 是此次合作的另一大主軸。NVIDIA Omniverse 函式庫與 Isaac Sim 機器人模擬環境正式上架 Google Cloud Marketplace，讓工程師可以在雲端大規模執行機器人訓練和模擬測試，不再受限於本地算力。
NVIDIA Cosmos Reason 2——一個專為物理世界推論設計的多模態基礎模型——現可部署至 Vertex AI 與 Google Kubernetes Engine，並已與 Cadence（EDA 工具）和 Siemens（工業軟體）完成整合，覆蓋電子設計自動化到智慧製造等場景。
實際客戶案例
- Snap：透過 GPU 加速的 Apache Spark 降低 A/B 測試成本，加速推薦系統實驗迭代。
- Schrödinger：藥物發現模擬從數週壓縮到數小時，直接影響研發週期。
- CrowdStrike：使用 NVIDIA NeMo 建構網路安全領域專用代理，強化威脅偵測與回應能力。
目前 NVIDIA 與 Google Cloud 的聯合開發者社群已超過 90,000 人。對工程師來說，這意味著生態系資源、範例程式碼、以及社群支援都在快速擴大。
工程師的行動建議
如果你正在評估大規模代理 AI 基礎設施，A5X 裸機實例的 10x 成本優勢值得認真計算一次 TCO。對於有合規需求的場景，Confidential G4 VM 提供了目前業界少數能在 GPU 層面保護資料的解決方案。物理 AI 領域的工程師則可以開始評估 Isaac Sim 在 Google Cloud 上的雲端化模擬工作流，以替代昂貴的本地 GPU 集群。
7 tips to optimize Azure Cosmos DB costs for AI and agentic workloads
devblogs.microsoft.com · 2026-04-22
AI 應用與代理工作負載的特性——向量搜尋、低延遲檢索、爆發性流量——正在快速暴露傳統資料層設計的效率問題。這篇文章整理了 7 個針對 Azure Cosmos DB 的成本優化策略，每一條都有真實客戶案例佐證，工程師可以直接對照自己的架構逐項評估。
Tip 1：開發測試環境善用免費層
Azure Cosmos DB 的免費層（Free Tier）每個訂閱帳戶每月提供免費的吞吐量與儲存配額，搭配本地 Cosmos DB Emulator 可以做到零雲端成本的本地開發。對於有多個環境（dev、staging、test、prod）的團隊，這是最直接的成本控制起點。SDK 方面支援 Python、Node.js、Go、.NET、Java，且免於 schema 管理與手動索引維護。
Tip 2：依據流量形態選擇正確的吞吐量模式
Azure Cosmos DB 提供三種模式：
- Serverless：適合爆發性或低量流量，按用量計費，無最低消費。
- Autoscale：適合有需求峰值的生產環境，在設定範圍內自動伸縮。
- Provisioned Throughput：適合穩定、可預測的持續性工作負載。
Novo Nordisk 的案例非常典型：將四個環境從預設配置切換到 Serverless 並重新設計資料模型後，月費從 $240 降到不足 $1。選錯模式是很多早期 AI 專案燒錢的根本原因。
Tip 3：Autoscale 是爆發性 AI 流量的最高槓桿
代理工作負載的流量極難預測——一個 agent 被觸發時可能在幾秒內發出數十次資料庫查詢，然後沉寂數分鐘。Autoscale 讓你設定吞吐量上限（如 4,000 RU/s），系統在 10% 到 100% 範圍內自動伸縮，只在使用時付費。
Kinectify 的案例展示了另一種優化思路：租戶層級的邏輯分區配合 Autoscale，讓多個租戶共享吞吐量配額，避免為每個租戶各自預留峰值容量。
Tip 4：分區設計是成本決策，不只是擴展決策
Request Unit（RU/s）是 Cosmos DB 的計費貨幣，跨分區查詢的 RU 消耗遠高於單分區查詢。高基數（high-cardinality）的分區鍵能避免熱分區，讓查詢只掃描特定物理分區子集。
Veeam 利用 Autoscale 搭配階層式分區（hierarchical partitioning）管理數十億筆資料，將搜尋範圍收斂到少數物理分區，同時降低成本與延遲。Unite Digital 則透過分區導向的擴展策略，每月節省 $25,000。分區鍵的選擇在設計初期就必須考慮查詢模式，後期修改代價很高。
Tip 5：對齊存取模式以優化 RU 消耗
RU/s 的消耗量由以下因素決定：文件大小、索引策略、查詢複雜度。對於 AI 應用，常見的優化方向包括：
- 將大型向量嵌入（embeddings）與頻繁存取的元資料分離儲存，避免每次讀取都拉取高維向量。
- 縮減文件大小，同時降低儲存與讀寫成本。
- 調整自動索引策略，排除不需要查詢的欄位。
Novo Nordisk 將任務儲存重新設計為單一文件結構（而非多文件引用），在降低 RU 消耗的同時也改善了查詢效能——這是典型的「以資料模型換效率」設計思維。
Tip 6：整合資料集，避免不必要的服務費用
AI 檢索管線中常見的反模式是：向量資料庫、關聯式資料庫、快取層各自獨立部署，導致跨服務的 ingress/egress 費用疊加，管理複雜度也成倍增長。Cosmos DB 原生支援向量儲存（DiskANN 索引），在許多場景可以取代獨立的向量資料庫。將向量 store 與主要資料共置於同一帳戶，不但消除網路傳輸費，也能使用共享吞吐量配額。
Tip 7：多區域部署要對齊實際流量分布
多區域讀取副本按每個副本的 RU 消耗計費。如果用戶實際只分布在兩個地區，卻開啟了五個讀取區域，等於無謂地乘以 5 倍的吞吐量費用。定期審視各區域的實際流量指標，移除或整合低利用率的區域，並考慮單寫入區域搭配選擇性讀取副本的架構，是多區域部署成本控制的關鍵動作。
工程師的行動建議
這 7 條建議的優先序大致是：先選對吞吐量模式（Tip 2），再設計分區鍵（Tip 4），然後優化資料模型（Tip 5），最後處理多區域（Tip 7）。對於正在評估 RAG 架構的工程師，Tip 6 的向量共置策略值得優先考慮——能省下一整套獨立向量資料庫的維運成本。
Introducing Toolboxes in Foundry
devblogs.microsoft.com · 2026-04-22
Microsoft Foundry 推出了 Toolbox 功能（目前為預覽版），直指多代理系統開發中最痛的一個點：工具整合的重複工作與治理混亂。每個代理各自維護一套工具設定、認證憑證、端點配置，在組織規模擴大後幾乎必然演變成維護噩夢。Toolbox 嘗試用「定義一次、到處使用」的思路解決這個問題。
問題背景：工具整合的重複成本
想像一個員工入職代理需要調用五種不同工具：Microsoft Entra ID 帳號建立、GitHub 倉庫存取、雲端資源配置、Azure DevOps 任務管理、Teams 訊息發送。這五種工具對應五套認證模型、五個不同的負責團隊、以及五份維護成本。當組織內有 10 個代理時，這個問題乘以 10 倍；有 100 個代理時，情況幾乎失控。
傳統做法是每個代理各自硬編碼工具設定，結果是憑證重複、行為不一致、部署脆弱。
Toolbox 的四柱架構
Foundry Toolbox 圍繞四個核心能力設計：
- Discover（即將推出）：不需要手動瀏覽工具目錄，系統協助找到合適的工具。
- Build（今日可用）：將工具篩選、組合成命名的可重用集合，一次定義，反覆使用。
- Consume（今日可用）：透過單一 MCP 相容端點連接，任何代理都可以直接消費。
- Govern（即將推出）：集中式認證與可觀察性，統一追蹤所有工具呼叫。
支援的工具類型
目前 Toolbox 支援兩大類工具：
- 內建工具：Web Search、Code Interpreter、File Search、Azure AI Search，開箱即用，無需額外設定。
- 協議工具：Model Context Protocol（MCP）、Agent-to-Agent（A2A）、OpenAPI，涵蓋主流代理通訊標準。
認證設計：OAuth 與 Managed Identity
Toolbox 的認證採用兩種機制：OAuth identity passthrough（將使用者身份傳遞給工具）與 Microsoft Entra Managed Identity（以服務帳號代表代理執行）。這意味著個別代理不再需要持有任何憑證——所有認證邏輯由 Foundry 集中管理，大幅降低憑證外洩風險。
「Foundry Homed, Not Foundry-Bound」設計原則
這是 Toolbox 最關鍵的設計決策：工具箱在 Foundry 中建立和治理，但可以被任何 MCP 相容的代理運行時消費。官方列舉的相容框架包括：Microsoft Agent Framework、LangGraph、GitHub Copilot、Claude Code、以及支援 MCP 的 IDE。
消費端點格式如下：
https://zava.services.ai.azure.com/api/projects/<project>/toolbox/<toolbox-name>/mcp?api-version=v1這個端點可以直接配置到任何支援 MCP server URL 的框架，無需修改代理本身的邏輯。
快速上手流程
官方文件描述的啟動步驟：使用 AIProjectClient 設定 Foundry 專案用戶端、建立 Toolbox 並加入所需工具、透過 MCP 端點將 Toolbox 附加到代理、測試驗證後推送到生產環境、最後將端點分享給其他團隊使用。提供 AZD CLI starter template 與 Microsoft Agent Framework、LangGraph、Copilot SDK 的範例程式碼。
工程師的行動建議
如果你的團隊正在建構超過兩個以上的代理，Toolbox 的工具共享機制值得現在就開始評估。特別是對於有安全合規需求的場景，集中式認證能夠顯著降低憑證管理的複雜度。由於 Govern（集中可觀察性）功能尚未推出，現階段可以先聚焦在 Build 與 Consume 兩個已上線的能力，建立工具目錄的基礎，等 Discover 與 Govern 就位後再做全面整合。
From Local to Production: The Complete Developer Journey for Building, Composing, and Deploying AI Agents
devblogs.microsoft.com · 2026-04-22
Microsoft 以密集的產品發布節奏宣告其代理 AI 平台的全面成熟：Microsoft Agent Framework v1.0 正式發布、Foundry Toolkit for VS Code 進入 GA、記憶體能力上線預覽、Toolbox 開放預覽、Hosted Agents 加速預覽、Foundry Control Plane 的可觀察性功能全面 GA。這篇文章用「從本地到生產」的七步開發旅程，系統性地梳理整個代理開發棧的每一層。
Step 1：本地構建——Microsoft Agent Framework v1.0
v1.0 是一個重要里程碑，代表 API 穩定性承諾的開始。核心特性包括：多模型支援（不綁定特定 LLM provider）、結構化工作流定義、原生 Foundry 整合、以及開放標準相容（MCP、A2A、OpenAPI）。Foundry Toolkit for VS Code 則提供本地測試、除錯、以及直接部署的完整 IDE 體驗。
Step 2：Agent Harness 與多代理組合
Harness 是代理執行的沙盒環境，分為兩個層級：
- 本地 Shell Harness：在本地執行，支援帶有審批流程的 shell 指令執行，適合開發與測試。
- Hosted Shell Harness：在供應商管理的沙盒中執行，適合生產環境的隔離需求。
Context compaction（上下文壓縮）功能解決長對話中 token 消耗爆炸的問題，透過智慧截斷保留關鍵資訊。多代理組合則支援 GitHub Copilot SDK 整合，讓代理可以協同工作。
Step 3：有狀態記憶體——定價與架構
Foundry 的受管記憶體功能與 Microsoft Agent Framework 和 LangGraph 原生整合，提供兩種層級：
- 短期記憶體：$0.25 per 1,000 events
- 長期記憶體：$0.25 per 1,000 memories/月，$0.50 per 1,000 次檢索
在 2026 年 6 月 1 日之前的預覽期間免費。這個定價對於高頻率的代理對話場景需要仔細評估——一個每天處理 10,000 次互動的代理，長期記憶體的月費可能達到數百美元。
Step 4：工具管理——Toolbox
透過統一的 MCP 端點整合 Web Search、Code Interpreter、File Search、Azure AI Search，以及 MCP、OpenAPI、A2A 協議工具。工具定義一次，多個代理共享消費，詳見 Toolbox 單獨發布的說明。
Step 5：Hosted Agents——計費模式與核心特性
Hosted Agents 從 2026 年 4 月 22 日起正式開始計費：
- 計算費用：$0.0994 per vCPU-hour
- 記憶體費用：$0.0118 per GiB-hour
架構特性：每個代理 session 獨立 VM 隔離、VNET 支援、sub-100ms 啟動時間、零閒置成本（scale-to-zero）、持久化檔案系統（跨 scale-down 事件存活）。這個 scale-to-zero 特性對於流量不穩定的生產代理特別重要——傳統容器化方案通常需要維持最低副本數以確保響應速度，而 sub-100ms 的冷啟動讓真正的零閒置成本成為可能。
Step 6：可觀察性——OpenTelemetry + AI Red Teaming
追蹤基於 OpenTelemetry 標準，支援評估（evaluation）與追蹤（trace）的關聯，讓工程師可以直接從評估結果跳轉到對應的執行追蹤。AI Red Teaming Agent 現已 GA，提供自動化對抗性測試，協助在上線前識別模型安全風險。Microsoft Agent 365 整合提供組織層級的代理治理能力。
Step 7：發布——Teams 與 Microsoft 365 Copilot
代理可以發布到 Microsoft Teams 和 Microsoft 365 Copilot，分為個人使用、組織共享（需管理員審核）兩種範圍。這條路徑讓企業內部的自建代理能夠直接透過員工日常使用的協作工具觸達，降低採用門檻。
工程師的整體評估
Microsoft 這次的發布節奏顯示代理 AI 基礎設施的「地基」已經就位：穩定的框架（v1.0）、受管運算（Hosted Agents）、受管記憶體、統一工具治理（Toolbox）、以及可觀察性。對於企業工程師，最值得立即行動的是：評估 Hosted Agents 的 sub-100ms 啟動能否取代自管容器集群、以及在 6 月 1 日免費期結束前充分測試記憶體功能。對於使用 LangGraph 的團隊，與 Foundry 記憶體和 Toolbox 的原生整合尤其值得優先評估。
Introducing the new hosted agents in Foundry Agent Service: secure, scalable compute built for agents
devblogs.microsoft.com · 2026-04-22
傳統的雲端運算模型——容器、serverless 函數——在面對代理 AI 工作負載時暴露出根本性的設計限制。Microsoft Foundry Agent Service 的 Hosted Agents（現為公開預覽版）針對這些限制重新設計了一套代理專屬的計算平台。
為什麼傳統計算模型不適合代理？
問題的核心在於安全隔離。代理工作負載的特殊性在於它會執行程式碼、寫入檔案、存取憑證——而傳統容器和 serverless 函數通常在多用戶 session 之間共享資源。在這種架構下，一個 session 的代理理論上可能影響另一個 session 的狀態，產生安全風險。
另一個問題是生命週期管理。代理 session 的長度不可預測，可能從幾秒到數小時不等。傳統的函數計算通常有嚴格的執行時間限制（如 AWS Lambda 的 15 分鐘上限），而容器冷啟動時間（通常數秒到數十秒）對於需要快速響應的代理場景是不可接受的。
Hosted Agents 的核心架構
六個關鍵設計決策：
- Per-session VM 隔離：每個代理 session 分配獨立的 VM 沙盒，不與其他 session 共享任何資源，消除跨 session 的安全風險。
- Sub-100ms 冷啟動：解決傳統 VM 啟動時間長的問題，讓 scale-to-zero 在實踐中可行。
- Scale-to-zero 經濟學：閒置時不消耗任何資源，計費精確到 session 級別的實際使用量。
- 跨 scale-down 的持久化檔案系統：session 結束後檔案系統狀態保留，下次啟動可以從上次中斷處繼續，支援長生命週期的有狀態代理。
- Bring-Your-Own VNet：出站流量可以透過自定義 VNet 路由，滿足企業網路合規要求。
- 生產就緒的端點管理：支援版本化部署和加權流量切換（weighted rollout），讓代理的灰度發布成為可能。
身份與安全整合
Hosted Agents 內建 Entra Agent ID，讓代理具有獨立的數位身份（區別於代表用戶執行的身份），結合 DLP（資料遺失預防）策略與 Responsible AI guardrails，形成多層次的企業安全框架。這與需要共享服務帳號的傳統架構相比，在稽核追蹤和最小權限原則上有顯著優勢。
框架無關性
Hosted Agents 明確支援多種主流代理框架：LangGraph、Microsoft Agent Framework、Claude Agent SDK、OpenAI Agents SDK、GitHub Copilot SDK。用戶可以透過 Dockerfile 定義自定義環境，安裝特定的工具鏈和依賴，平台不強制綁定特定框架。協議支援方面，同時相容 OpenResponses 和 Activity Protocol。
平台整合生態
Hosted Agents 作為底層計算層，與 Foundry 的其他服務緊密整合：
- Toolbox：統一工具配置與管理。
- Memory：受管長期記憶體，原生整合 Microsoft Agent Framework 和 LangGraph。
- Microsoft Agent Framework v1.0：穩定的生產就緒框架版本。
- 企業上下文：與 Work IQ、Fabric IQ、Foundry IQ 整合，讓代理能夠存取組織內部的業務數據上下文。
快速部署路徑
官方提供三個起點：Foundry Agent Service Portal（UI 操作）、Azure Developer CLI（azd deploy 指令部署）、以及 12 分鐘的 Microsoft Mechanics 教學影片。社群支援透過 GitHub 和 Discord 提供。
工程師的評估重點
Sub-100ms 的啟動時間是這個平台最有說服力的技術主張。如果實測數據能夠驗證這個指標，它意味著代理工作負載終於可以在不犧牲響應速度的前提下實現真正的 scale-to-zero。對於正在評估代理基礎設施的工程師，建議優先測試兩個場景：高並發短 session 的成本表現（驗證 scale-to-zero 效益），以及長生命週期有狀態代理的持久化檔案系統可靠性（這在自管容器環境中通常需要額外的持久化儲存方案）。計費方面，$0.0994 per vCPU-hour 的價格需要與自管 AKS 集群的 TCO（包含管理成本）進行全面比較，才能得出真實的成本結論。
來源：blogs.nvidia.com, devblogs.microsoft.com