Microsoft Foundry Blog 於 2026 年 9 月 3 日詳細說明 Fireworks on Microsoft Foundry 的架構。這次更新的重點不是又加入一個模型，而是把企業採用 open-weight models 時最容易被簡化的問題攤開：誰負責身份和治理、誰實際運行 GPU、prompt 會經過哪個邊界，以及哪些合規承諾不適用。
架構可以先用兩個平面理解。Microsoft Foundry 是 control plane，負責 Microsoft Entra ID、Azure RBAC、quota、Foundry guardrails、endpoint management、audit、metering 和 billing。Fireworks 則是 inference provider，負責 GPU、模型權重、gateway routing、workload isolation、retention 和 inference observability。模型會出現在 Foundry catalog，客戶可用 Azure 的入口部署及管理，但 inference 實際在 Fireworks Inference Cloud 執行。
這個分工的好處是企業可以繼續沿用 Azure 的身份、政策和付款流程，同時得到較新的 open models、custom weights、serverless consumption 和 provisioned throughput 選擇。Microsoft 也表示不需要另開一個 Fireworks account 或 contract 才可使用 Foundry consumption experience。對要比較模型、做 bursty evaluation 或逐步轉入 production 的團隊，這種入口一致性可以減少管理摩擦。
但最重要的句子是：prompt 會從 Microsoft Foundry endpoint 經過 Microsoft 和 Fireworks 的邊界，資料會送到 Fireworks 的 inference cloud。Microsoft 的文章把這個 boundary 說清楚，亦指出 customer data 在這部分受 Fireworks 的控制。這並不等於架構不安全，反而讓風險可以被畫出來；企業不能把「在 Foundry catalog 裏」誤解為「所有資料都留在自己的 Azure tenant 內」。
Microsoft 列出的控制包括：inference 預設 zero data retention、prompt 和 completion 只在請求期間暫存、不用客戶資料訓練或 fine-tune、TLS 1.2 或以上、AES-256、邏輯隔離、最小權限和受限 production access。文章同時提醒 Responses API 的 store=true 可以保留 conversation state 30 日；要做 stateless operation，應使用 store=false 或刪除 response record。這些設定差異會直接影響敏感資料的風險評估。
合規邊界也沒有被包裝成「全部適用」。Microsoft 表示 Fireworks on Foundry 不在 EU Data Boundary 承諾內、未達 FedRAMP、不能用於 Azure Government，PCI DSS 亦不適用。客戶仍要自行評估模型的安全、品質、責任 AI 特性和用途適合度。這些限制對金融、醫療、公共部門和需要地區資料邊界的工作尤其重要。
部署選擇包括 serverless、按 token 計費的 Data Zone Standard，適合 evaluation 和波動需求；以及預留 PTU 的 Global Provisioned Throughput，適合可預測、高量和低延遲 workload。企業應先用代表性資料測試 latency、quality、retention 和 geographic routing，再決定是否承諾容量或把自己的 weights 帶入平台。不要先由 marketing 的「open model choice」推斷已經符合所有 production policy。
Fireworks on Foundry 值得留意的原因，是它把 open-model 採用變成一張可審核的資料流圖。Azure 的身份和治理可以保留，但 inference、資料留存和合規責任有一個清楚的第三方邊界。對 Agent workflow 來說，這比「同一個 endpoint 可以呼叫很多模型」更重要：真正要批准的，是每一個 prompt、tool call、回應和保存設定會走到哪裏。
