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、响应和保存设置会走到哪里。
