Amazon 与 Google Cloud 的竞争加剧，AWS GovCloud 新增多种 AI 模型

Amazon 于 8 月 30 日在 AWS GovCloud 中扩展了六个具名 AI 模型家族，对联邦云市场中的单一模型策略构成挑战。Amazon 与 Google 的竞争如今已超越基础设施容量，日益聚焦于哪家服务商能为政府机构提供最广泛且可信的受监管 AI 部署路径。

AWS 表示，政府客户可通过 Amazon Bedrock 访问 Amazon Nova、Anthropic Claude、Meta Llama、Nvidia Nemotron、OpenAI 模型和 xAI Grok。该公司还承诺，随着其目录扩展，将提供更多前沿模型。Google Gemini 明显不在其中，因为它仍是 Google Cloud 竞争性政府 AI 战略的核心。

这项公告之所以重要，是因为联邦买方很少仅依据基准测试结果选择模型。授权边界、数据驻留、人员管控、采购规则以及现有云合同，都会影响团队能够部署什么。AWS 正在押注：在一个受控环境中提供模型选择，将比忠于任何单一 AI 开发商更具吸引力。

这一战略以不同方式对 Google 和 Microsoft 施压。Google 将 Gemini for Government 定位为围绕其模型和智能体技术构建的一体化平台。Microsoft 则通过 Azure 提供 OpenAI 模型和面向政府的专用服务。AWS 则将自身呈现为中立的模型市场，同时也在推广自家的 Nova 系列。

Amazon 与 Google 的竞争如今聚焦于模型访问

AWS 已将模型多样性变成政府云服务的核心卖点，而不再只是次要的开发者功能。

8 月 30 日的模型选择公告称，现在可通过 AWS GovCloud 中的 Amazon Bedrock 使用多个模型家族。Bedrock 是 AWS 的托管服务，可通过通用接口和配套工具，使用基础模型构建应用程序。

公告列出了 Amazon Nova、Anthropic Claude、Meta Llama、Nvidia Nemotron、OpenAI 模型和 xAI Grok。它还提及了其他前沿模型，但未逐一说明所有产品。政府机构仍须查阅最新的模型访问文档，以确认具体的区域和合规可用性。

这不仅是更长的产品目录。AWS 希望政府机构将模型视为更大云架构中可替换的组件。团队可针对同一工作负载测试多个模型，而无需将整个应用迁移至另一家服务商。

这种结构支持实用的政府应用场景。轻量级模型可以对传入文件进行分类，而推理模型可分析复杂案件。另一种模型则可生成或审查代码。Bedrock 在 AWS 环境内为这些组件提供统一的访问层。

这种架构也降低了对单一模型开发商发布周期的依赖。如果某个服务商淘汰某个版本、改变其行为，或在某项具体任务上落后，政府机构仍有替代方案。不过，模型替换仍需要测试，因为输出、安全行为、上下文限制和工具支持各不相同。

AWS 将这一变化描述为其承诺为美国政府投资最多 500 亿美元用于 AI 和高性能计算基础设施的一部分。这一承诺为目录公告赋予了更广泛的竞争背景。AWS 不只是增加接口；随着政府机构加大 AI 支出，它也在巩固自身地位。

Amazon 与 Google 的竞争，通过一项缺失变得更加清晰。Gemini 不在 AWS GovCloud 中列出的 Bedrock 模型家族之列。因此，Google 所面对的平台可以整合多家主要模型开发商，同时排除了 Google 最重要的专有模型。

对政府技术负责人而言，这带来了一个新的采购问题。他们必须决定：AWS 内部的模型多样性，是否比在 Google Cloud 上与 Gemini 深度整合更具战略灵活性。答案将取决于任务、现有架构和授权范围。

为何模型选择已成为任务需求

支持多模型的最有力理由是运营连续性，尽管 AWS 仍需让客户在生产环境中验证这一承诺。

基础模型并非在每项任务上都表现相同。一个模型可能擅长处理长文档，另一个则能生成更好的代码或提供更低延迟的分类。政府工作负载放大了这些差异，因为错误可能影响福利发放、调查、网络安全或公共服务。

AWS 将任务匹配列为扩展目录的原因之一。政府机构可使用自己的数据和要求评估模型，而不是通过公开基准测试选择服务商。这一点很重要，因为通用基准分数很少能代表某个机构的文件、术语或风险容忍度。

成本控制是另一项因素，即使政府机构避免公开模型层面的支出。对每项请求都使用最大的模型可能浪费计算资源。路由系统可以将简单请求发送至较小模型，并将高级推理留给困难任务。

这种方法构成多模型智能体的基础。AI 智能体是能够规划步骤、调用工具并朝既定目标行动的软件。路由模型可先对请求进行分类，再将选定任务发送至专门模型或政府系统。

以国防承包商内部的网络安全工作流为例。一个模型可以分类警报，另一个可以汇总证据，而以代码为重点的模型则可提出补丁建议。人工审核人员仍将控制执行，但系统不必在每一阶段都依赖同一个模型。

同样的模式也可支持文档密集型的民用工作。政府机构可能使用一个模型进行记录分类，另一个模型进行政策分析。当某项决定具有异常的法律或运营风险时，它还可比较不同输出。

通用 API 简化了工程层，但不会让模型变得可以互换。提示格式、支持的参数、工具调用、安全过滤器和 token 限制都可能不同。团队仍需要为投入使用的每个模型建立评估套件和故障转移逻辑。

采购流程也仍比更换一个接口复杂得多。AWS 认为，统一服务可以减少单独的供应商准入和架构重构。然而，政府机构必须确认每个模型和功能是否位于特定工作负载所需的授权边界之内。

因此，当政府机构从一开始就为替换而设计时，模型选择的价值最大。紧密耦合的应用程序可能无法从庞大目录中获得多少收益。模块化应用程序则可以比较模型、路由工作负载，并以更少干扰替换表现不佳的组件。

这也是为什么该公告带来的压力不限于模型供应商。系统集成商和软件承包商必须证明其应用可以安全地使用多种模型。买方将日益质疑那些只能与单一服务商专有接口协作的架构。

AWS 在推广 Amazon Nova 的同时出售“中立性”

核心矛盾在于，AWS 在与自身目录中的供应商竞争时，能否继续成为受信任的模型经纪方。

Amazon Bedrock 通过一项托管服务提供多家公司的模型。这种定位让 AWS 可以强调客户选择，而不是宣称 Nova 应承担所有工作负载。它也使模型开发商能够接触已承诺使用 AWS 基础设施的客户。

不过，AWS 拥有平台、商业关系以及 Nova 模型家族。它控制服务在控制台、文档、评估工具和参考架构中的呈现方式。这会形成一种结构性激励，使其更倾向于自家模型，而非外部服务商。

政府买方已在云市场中见过类似的动态。平台可以支持第三方产品，同时利用市场活动强化自己的服务。问题不在于 AWS 必然会限制竞争对手，而在于中立性必须通过可观察的条款和行为加以证明。

模型可用性提供了一项检验。AWS 表示，客户可通过更改接口和访问配置文件，在受支持模型之间切换。买方应核实，不同服务商之间的配额、功能覆盖、延迟和发布时间是否仍然具有可比性。

评估工具提供了另一项检验。中立的比较流程应让政府机构定义与任务相关的衡量指标并审查失败情况，而不应将模型选择简化为通用分数或服务商选定的基准测试。

数据处理同样重要。AWS 表示，客户数据不会被用于训练或改进可用模型。政府机构应确认，这一承诺如何适用于提示、输出、日志、评估记录以及每项已启用的集成。

还存在连续性问题。目录减少了对单一模型服务商的依赖，但增加了对经纪平台的依赖。使用 Bedrock API、护栏、智能体和知识库功能的政府机构，即使模型切换更容易，也可能发现难以离开 AWS。

这正是“选择”论述背后的反转。AWS 可以减少模型锁定，同时加深平台锁定。模型在 Bedrock 内部变得更具可移植性，但周边应用可能更依附于 AWS 服务。

这并不会抹去目录的价值，但会改变买方衡量该价值的方式。相关的比较并非一个模型与另一个模型，而是整个应用架构，包括身份、数据、编排、监控、安全控制和退出选项。

因此，设计完善的采购流程应要求提供两种可移植性的证据。团队需要了解在 AWS 内部替换模型有多容易，也需要理解将应用迁出 Bedrock 需要什么。

Amazon 与 Google 的竞争正处于这一差异之中。Google 可以认为，一体化 Gemini 技术栈可降低运营复杂性。AWS 可以认为，其更广泛的目录保留了选择权。两种承诺都不会消除依赖；它们只是在不同层面安置这种依赖。

Google 和 Microsoft 面临不同类型的压力

Google 必须捍卫一体化 Gemini 战略，而 Microsoft 必须证明 Azure Government 能够匹配 AWS 的广度和运营灵活性。

Google 围绕 Gemini、生产力工具和不断扩展的智能体平台，构建了其联邦 AI 定位。其政府部署指南称，Gemini for Government 可通过经过配置的 Assured Workloads 环境，支持 FedRAMP High 和 DoD Impact Level 4 部署。

这一授权定位具有重要意义。Google 还在 2025 年宣布，Workspace 应用中的 Gemini 以及 Gemini 应用获得了 FedRAMP High 授权。这些产品面向协作和员工生产力，而 AWS 的公告则聚焦于通过 Bedrock 构建定制化应用程序。

这种差异为 Google 提供了连贯的叙事。政府机构可以在云开发、企业搜索、智能体和生产力软件中使用 Gemini。深度整合可减少安全和运营团队需要管理的接口数量。

不过，当买家希望拥有独立的模型选择时，集成也可能成为弱点。如果某家机构认定 Claude、OpenAI 模型或开放权重模型表现更好，AWS 提供了直接的目录访问路径。Google 必须回答：Gemini 的集成优势是否足以抵消这种选择自由。

Google 可以通过扩大第三方模型访问、增强互操作性，或将 Gemini 提升到足以让机构接受更集中化策略的水平来回应。它还可以强调自己拥有更多技术栈环节的领域，包括搜索、数据分析、生产力工具和模型开发。

Microsoft 面临着不同的挑战。Azure Government 已通过 Microsoft Foundry 提供 OpenAI 模型及其他 AI 服务。其政府模型目录记录了所支持模型在区域和部署方面的差异。

Microsoft 还受益于政府机构对 Microsoft 365、身份服务、开发者工具和 Azure 的既有使用。这些关系可以让其 AI 服务更容易融入已建立的工作流程。不过，Azure Government 中的功能可用性并不总是与商业云保持一致。

Microsoft 的文档说明了这一差距。其政府 Foundry 环境支持多项企业功能，但部分评估和优化能力仍不可用。模型和功能差异可能影响机构从试验阶段转向获授权生产系统的速度。

AWS 正是在利用这一顾虑。其主张是，机构不应等待某一个模型、某一份功能路线图或某一家提供商。相反，团队应围绕一个目录进行构建，并随着新模型获得受监管环境的准入资格而持续更新。

不过，仅凭目录规模无法决定胜负。政府客户关心授权证据、集成成本、支持服务、合同条款和系统性能。如果配额或缺失功能阻碍生产使用，即便名义上可用的模型价值也有限。

因此，Amazon 与 Google 竞争的下一阶段将取决于真正可用的能力。买家会比较哪些模型可在何种区域、何种控制措施下运行，以及可搭配哪些支持服务。营销清单的重要性将低于生产证据。

合规继承并不能消除机构风险

AWS GovCloud 可以提供可复用的控制措施，但无法为某个机构的完整 AI 系统授权，也无法验证每一项由模型生成的决策。

AWS 将 GovCloud 描述为面向敏感政府工作负载的隔离基础设施。其公告提到美国数据驻留、由符合资格的美国人员运营、加密、硬件隔离以及多项合规计划。

该公司表示，适用的 AI 工作负载可以继承 AWS GovCloud 的 FedRAMP 授权。这种继承能够减少重复的评估工作，因为机构可复用已在云服务层面实施并经过评估的控制措施。

但这并不意味着某个机构会自动获得运营授权。联邦授权指南指出，机构仍需对自身的信息系统进行授权。相关负责人必须评估所处理的信息、选定的配置、集成方式以及由客户运营的控制措施。

AWS 自身的责任共担模型也作出了类似区分。AWS 负责保护底层云基础设施，而客户仍需负责数据、权限、应用行为和工作负载专属配置。

对于生成式 AI，这一区分尤为关键。合规的推理端点并不能确保应用产生准确、公平或具有法律效力的结果。它也无法决定某个特定数据集是否应被输入模型。

机构必须测试幻觉问题，即看似合理但缺乏支持依据的模型输出。它们还需要针对提示注入、未经授权的工具使用、敏感数据暴露和过度用户权限设置控制措施。这些风险产生于应用层，而不仅仅是云基础设施层。

对于具有重大影响的决策，人工监督仍然必不可少。模型可以总结证据或建议行动，但机构必须决定何时由人员审核结果。机构还必须保留适当记录，并说明某项输出如何影响了决策。

多模型系统会增加更多复杂性。每个模型可能对同一安全政策作出不同反应。更新可能在不改变周边应用的情况下改变输出模式。因此，评估必须在部署后持续进行。

AWS 提供 Bedrock Guardrails，用于内容过滤、敏感信息控制和主题限制。这些控制措施可以支持机构政策，但无法替代面向具体任务的测试。为公众聊天机器人调优的过滤器，未必适用于情报分析或事件响应。

公告还提出了若干需要谨慎验证的说法。AWS 表示，在推理过程中，任何运营人员都无法访问提示词、补全内容或模型权重。客户应查阅适用于其具体服务和配置的技术文档及授权材料。

详细的 AWS 文章也带来了另一项谨慎理由。其引言将 Meta Llama 列为可用模型家族之一，但后续的编号模型摘要并未为 Llama 单列条目。这种编辑上的不一致并不能证明存在服务缺口，但它进一步说明有必要查阅实时可用性记录。

同样，“额外的前沿模型”这一表述并未指明具体产品或日期。机构应将其视为路线图信号，而非当前可用性。采购文件应明确所需的模型、版本、区域、功能和合规等级。

最大的未决问题，是在真实政府条件下的性能表现。AWS 提供了涉及传感器分类、威胁评估、文档审查和补丁修复的示例。这些只是说明性场景，并非公告中描述的、经过独立验证的机构部署案例。

买家应要求提供针对具体工作负载的证据。其中包括代表性数据下的准确性、响应延迟、故障率、模型更新流程、回退行为和人工审核要求。没有这些指标，模型选择仍只是能力主张，而非任务成果。

三个信号将显示该战略是否奏效

AWS 现在必须证明，广泛的目录能够带来更快、更安全的部署，而不是更复杂的评估和治理。

第一个信号是有文档记录的生产可用性。机构应关注 AWS GovCloud 中确切的模型版本、区域支持、配额和合规映射。只有客户能在所需控制措施下使用这些模型，更多被点名的模型才会强化 AWS 的市场论点。

公告与文档之间不断扩大的差距将削弱这一论点。政府团队不能基于对未来模型的笼统承诺来构建获授权系统。他们需要稳定的标识符、支持时间表和明确的弃用政策。

第二个信号是真实多模型部署的证据。AWS 最有力的主张涉及让应用将不同任务路由至不同模型。公开案例研究应说明团队为何选择每个模型，以及该架构在部署后的表现。

有价值的证据应包括评估方法、运营可靠性，以及迁移工作量的可衡量减少。泛泛的客户证言无法证明模型多样性是否改善了结果。买家需要与真实政府或工业基础工作流程相关的案例。

这一信号也考验系统集成商。宣称具备多模型灵活性的承包商，应展示可运行的回退路径和可重复的评估流程。他们应证明，更换模型不会破坏安全控制、日志记录或授权假设。

第三个信号是 Google 和 Microsoft 的竞争性回应。Google 的回应最值得关注，因为 Gemini 并未出现在公布的 AWS 目录中。Google 政府环境中任何第三方选择的扩展，都会直接挑战 AWS 的中立性优势。

或者，Google 可能加大对集成的投入。它可以将 Gemini 与获授权的搜索、数据、工作空间和代理服务更深入地连接。强劲的采用表现将表明，机构更重视统一技术栈，而不是广泛的模型菜单。

Microsoft 的回应将显示 AWS 能否维持其广度优势。Foundry 中的新模型、政府区域同等能力或扩展的评估功能，都会缩小差距。政府云发布缓慢则会强化 AWS 的路线图独立性主张。

读者还应关注各提供商如何讨论合规性。更清晰的模型级授权数据将增强这三个平台的实力。将云授权模糊表述为完整应用审批的说法，应受到审视。

对于开发者而言，眼前的启示在于架构。在选定永久默认模型之前，应将评估与抽象层构建进应用。记录每个任务为何由某个模型处理、它接收哪些数据，以及发生故障时如何应对。

对于企业买家而言，启示在于合同条款。应要求版本透明度、弃用通知、导出选项，以及每项合规声明的证据。只有运营条款能够支持连续性，模型访问才有价值。

知识工作者将通过政府服务和受监管承包商感受到这些后果。更好的模型匹配可改善文档分析、案件处理、网络安全和内部研究。治理不善则可能在看似同样获授权的系统中传播不一致的答案。

构建自身证据库的团队，可以维护一个可搜索的AI 知识库，用于记录评估结果、政策决策和模型变更。随着应用组合多个提供商，这类记录将愈发重要。

Amazon 与 Google 的竞争不会由最长的模型清单决定。决定因素在于，机构能否在不失去安全性、可靠性或控制力的情况下切换模型。请关注实时目录、生产案例研究以及竞争对手的政府云发布。这些信号将显示，模型选择是否已成为任务优势，还是又一层平台依赖。