AI 和机器学习视角:可靠性

Last reviewed 2025-08-07 UTC

Google Cloud 架构完善框架:AI 和机器学习视角中的本文档简要介绍了在 Google Cloud上设计和运行可靠的 AI 和机器学习系统的原则和建议。本文探讨了如何将高级可靠性实践和可观测性集成到架构蓝图中。本文档中的建议与 Google Cloud 架构完善框架的可靠性支柱保持一致。

在快速发展的 AI 和机器学习领域,可靠的系统对于确保客户满意度和实现业务目标至关重要。为了满足预测性机器学习和生成式 AI 的独特需求,您需要强大、可靠且适应性强的 AI 和机器学习系统。为了应对 MLOps(从开发到部署和持续改进)的复杂性,您需要采用可靠性优先的方法。 Google Cloud 提供专门构建的 AI 基础设施,该基础设施符合站点可靠性工程 (SRE) 原则,并为可靠的 AI 和机器学习系统提供强大的基础。

本文档中的建议与以下核心原则相对应:

确保机器学习基础设施可伸缩且具有高可用性

云端可靠的 AI 和 ML 系统需要可伸缩且高度可用的基础架构。这些系统具有动态需求、多样化的资源需求,并且严重依赖于模型可用性。可扩缩的架构可适应不断变化的负载以及数据量或推理请求的变化。 高可用性 (HA) 有助于确保在组件、可用区或区域级故障发生时保持弹性。

如需构建可伸缩的高可用性机器学习基础设施,请考虑以下建议。

实现自动动态伸缩功能

AI 和 ML 工作负载是动态的,其需求会根据数据到达率、训练频率和推理流量而波动。自动动态伸缩功能可根据需求波动无缝调整基础架构资源。有效扩缩工作负载有助于防止停机、保持性能和优化费用。

如需自动扩缩 AI 和机器学习工作负载,请在 Google Cloud中使用以下产品和功能:

  • 数据处理流水线:在 Dataflow 中创建数据流水线。 将流水线配置为使用 Dataflow 的横向自动扩缩功能,该功能可根据 CPU 利用率、流水线并行性和待处理数据动态调整工作器实例的数量。您可以在启动作业时通过流水线选项配置自动扩缩参数。
  • 训练作业:使用 Vertex AI 自定义训练自动伸缩训练作业。 您可以定义工作器池规范,例如机器类型、加速器类型和数量,以及工作器池数量。对于可以容忍中断的作业以及训练代码实现了检查点设置的作业,您可以使用 Spot 虚拟机来降低费用。
  • 在线推理:对于在线推理,请使用 Vertex AI 端点。 如需启用自动扩缩功能,请配置最小和最大副本数。指定至少两个副本以实现高可用性。Vertex AI 会根据流量和配置的自动扩缩指标(例如 CPU 利用率和副本利用率)自动调整副本数量。
  • Google Kubernetes Engine 中的容器化工作负载:在节点和 Pod 级别配置自动扩缩。配置集群自动扩缩器节点自动预配,以根据待处理 Pod 的资源请求(例如 CPU、内存、GPU 和 TPU)调整节点数量。对于部署,请使用 Pod 横向自动伸缩器 (HPA) 根据 CPU 和内存利用率等指标定义伸缩政策。您还可以根据自定义 AI 和机器学习指标进行扩缩,例如 GPU 或 TPU 利用率以及每秒预测请求数。
  • 无服务器容器化服务:在 Cloud Run 中部署服务,并通过指定容器实例数的下限和上限来配置自动扩缩。按照最佳实践,通过指定加速器类型来自动扩缩启用 GPU 的实例。Cloud Run 会根据传入请求,在配置的下限和上限之间自动扩缩实例。在没有请求时,它会高效地缩减到零个实例。您可以利用 Cloud Run 的自动伸缩功能(由请求驱动)来部署 Vertex AI 代理,还可以部署第三方工作负载,例如使用 Ollama 的量化模型使用 vLLM 的 LLM 模型推理Huggingface Text Generation Inference (TGI)

围绕高可用性和容错能力进行设计

对于生产级 AI 和机器学习工作负载,请务必确保持续运行并具备故障恢复能力。如需实现高可用性和容错,您需要在 Google Cloud上为架构构建冗余和复制功能。这种方法有助于确保单个组件的故障不会导致整个系统发生故障。

为 Google Cloud中的关键 AI 和机器学习组件实现冗余。 以下是可用于实现资源冗余的产品和功能示例:

  • 跨多个可用区部署 GKE 区域级集群
  • 使用 Cloud Storage 多区域或双区域存储分区,确保数据集和检查点的数据冗余。
  • 使用 Spanner 实现元数据的全局一致性高可用性存储。
  • 为运营数据库配置 Cloud SQL 读取副本
  • 确保用于检索增强生成 (RAG) 的向量数据库具有高可用性,并且是多可用区或多区域的。

主动管理资源并预测需求

有效的资源管理对于帮助您优化费用、性能和可靠性至关重要。AI 和 ML 工作负载是动态的,对 GPU 和 TPU 等专用硬件的需求很高。因此,您必须主动管理资源并确保资源可用性。

根据历史监控数据(例如 Cloud Monitoring 中的 GPU 或 TPU 利用率和吞吐率)以及 Cloud Logging 中的日志来规划容量。使用 BigQueryLooker Studio 分析这些遥测数据,并根据增长情况或新模型预测未来的 GPU 需求。通过分析资源使用模式和趋势,您可以预测何时何地需要关键的专用加速器。

  • 通过严格的负载测试验证容量估算值。使用 Apache JMeterLoadView 等工具模拟 AI 和 ML 服务(例如服务和流水线)上的流量。
  • 分析压力下的系统行为。
    • 为了预测并满足生产环境中不断增加的工作负载需求,请主动确定资源需求。监控延迟时间、吞吐量、错误和资源利用率,尤其是 GPU 和 TPU 利用率。根据需要增加资源配额。
    • 对于生成式 AI 服务,在高并发负载下进行测试,并确定加速器可用性限制性能的级别。
  • 对模型查询执行持续监控,并为代理设置主动提醒
    • 使用模型可观测性信息中心查看 Cloud Monitoring 收集的指标,例如每秒模型查询数 (QPS)、token 吞吐量和第一个 token 延迟时间。

优化资源可用性和可获取性

根据工作负载要求战略性地选择合适的计算资源,从而优化费用并确保资源可用性。

  • 对于稳定的全天候推理工作负载或具有固定或可预测容量要求的训练工作负载,请为虚拟机和加速器使用承诺使用折扣 (CUD)
  • 对于 GKE 节点和 Compute Engine 虚拟机,请使用抢占式虚拟机和动态工作负载调度器 (DWS) 功能:

    • 对于容错任务(例如评估和实验工作负载),请使用 Spot 虚拟机。Spot 虚拟机可能会被抢占,但有助于降低总体费用。
    • 为了管理高需求加速器的抢占风险,您可以使用 DWS 来确保更好的可获取性。
      • 对于需要高端 GPU 运行长达 7 天的复杂批处理训练,请使用 DWS 灵活启动模式。
      • 对于运行时间长达三个月的工作负载,请使用日历模式预留特定的 GPU(H100 和 H200)和 TPU(Trillium)。
  • 如需优化 GKE 上的 AI 推理,您可以运行 vLLM 引擎,该引擎可动态使用 TPU 和 GPU 来满足不断变化的容量和性能需求。如需了解详情,请参阅 vLLM GPU/TPU 可互换性

  • 对于涉及加速器且资源和拓扑需求复杂的场景,请使用工具来抽象资源管理。

    • 借助 Cluster Director,您可以部署和管理加速器组,并为多 GPU 训练(A3 Ultra H200 和 A4 B200)实现同位和调度。Cluster Director 支持 GKE 和 Slurm 集群。
    • Ray on Vertex AI 可抽象化分布式计算基础架构。它使应用能够请求资源以进行训练和提供服务,而无需直接管理虚拟机和容器。

在多个实例之间分配传入流量

对于需求波动不定的 AI 应用,有效的负载均衡至关重要。负载均衡可分配流量、优化资源利用率、提供高可用性和低延迟,并有助于确保顺畅的用户体验。

  • 推理资源需求各异:根据模型指标实现负载均衡。 借助 GKE 推理网关,您可以部署具有模型感知型路由功能的负载均衡器后面的模型。网关会优先选择具有 GPU 和 TPU 加速器的实例来处理计算密集型任务,例如生成式 AI 和 LLM 推理。配置详细的健康检查,以评估模型状态。使用 vLLM 或 Triton 等服务框架获取 LLM 指标,并使用 Google Cloud Managed Service for Prometheus 将这些指标集成到 Cloud Monitoring 中。
  • 需要 GPU 或 TPU 的推理工作负载:为确保关键 AI 和 ML 推理工作负载始终在符合工作负载要求的机器上运行,尤其是在 GPU 和 TPU 可用性受限的情况下,请使用 GKE 自定义计算类。您可以定义特定的计算配置,并为自动扩缩设置回退政策。例如,您可以定义一个配置文件,用于为预留的 GPU 或 TPU 实例指定更高的优先级。该配置文件可以包含回退机制,以便在预留资源暂时不可用时使用经济实惠的 Spot 虚拟机。
  • 在各种编排平台上的生成式 AI:使用集中式负载均衡器。例如,为了提高成本效益和管理效率,您可以将 GPU 需求较低的请求路由到 Cloud Run,并将更复杂的 GPU 密集型任务路由到 GKE。对于服务间通信和政策管理,请使用 Cloud Service Mesh 实现服务网格。 使用 Cloud Logging 和 Cloud Monitoring 确保日志记录和监控的一致性。
  • 全球负载分配:如需对来自需要低延迟的全球用户的流量进行负载均衡,请使用全球外部应用负载平衡器。 配置地理定位路由到最近的区域,并实现故障切换。 在 Vertex AI 或 GKE 中建立区域端点复制。为静态资源配置 Cloud CDN。 使用 Cloud Monitoring 监控全球流量和延迟时间。
  • 精细的流量管理:对于具有不同数据类型或复杂性的请求以及长时间运行的请求,请实现精细的流量管理。
    • 配置基于内容的路由,以根据网址路径和标头等属性将请求定向到专用后端。例如,直接向支持 GPU 的后端请求图片或视频模型,以及向经过 CPU 优化的后端请求基于文本的模型。
    • 对于长时间运行的生成式 AI 请求或批处理工作负载,请使用 WebSocket 或 gRPC。实现流量管理,以处理超时和缓冲。使用 API Gateway 或 Apigee 配置请求超时和重试,并实现速率限制和配额。

使用模块化且松散耦合的架构

在模块化、松散耦合的 AI 和 ML 架构中,复杂的系统被划分为更小的、自成一体的组件,这些组件通过明确定义的接口进行交互。此架构可最大限度地减少模块依赖项,简化开发和测试,提高可重现性,并通过限制故障来提高容错能力。模块化方法对于管理复杂性、加速创新和确保长期可维护性至关重要。

如需为 AI 和机器学习工作负载设计模块化且松散耦合的架构,请考虑以下建议。

实现小型自包含模块或组件

将端到端 AI 和 ML 系统拆分为小型的自包含模块或组件。每个模块或组件负责一项特定功能,例如数据注入、特征转换、模型训练、推理服务或评估。模块化设计可为 AI 和 ML 系统带来多项关键优势:提高可维护性、可伸缩性、可重用性,以及更高的灵活性和敏捷性。

以下部分介绍了可用于为 AI 和 ML 系统设计模块化架构的 Google Cloud 产品、功能和工具。

GKE 上的容器化微服务

对于需要精细编排的复杂 AI 和 ML 系统或复杂的生成式 AI 流水线,请将模块实现为由 GKE 编排的微服务。将每个不同的阶段打包为 Docker 容器中的单个微服务。这些不同的阶段包括:针对各种格式量身定制的数据注入、专门的数据预处理或特征工程、大规模基础模型的分布式模型训练或微调、评估或服务。

在 GKE 上部署容器化微服务,并利用基于 CPU 和内存利用率或 GPU 利用率等自定义指标的自动伸缩、滚动更新以及 YAML 清单中的可重现配置。使用 GKE 服务发现功能确保微服务之间的通信高效。对于异步模式,请使用消息队列(例如 Pub/Sub)。

借助 GKE 上的微服务方法,您可以为复杂 RAG 应用等任务构建可伸缩的弹性平台,其中各个阶段可以设计为不同的服务。

无服务器事件驱动型服务

对于可受益于无服务器自动扩缩的事件驱动型任务,请使用 Cloud RunCloud Run functions。这些服务非常适合预处理等异步任务或较小的推理作业。根据事件(例如 Cloud Storage 中创建的新数据文件或 Artifact Registry 中的模型更新)触发 Cloud Run 函数。对于需要容器环境的 Webhook 任务或服务,请使用 Cloud Run。

Cloud Run 服务和 Cloud Run functions 可以快速扩缩,并可缩减至零,这有助于确保在工作负载波动时实现成本效益。这些服务适用于 Vertex AI Agents 工作流中的模块化组件。您可以使用 Workflows Application Integration 来编排组件序列。

Vertex AI 托管式服务

Vertex AI 服务支持模块化,可帮助您简化 AI 和机器学习系统的开发和部署。这些服务可抽象出复杂的基础设施,让您可以专注于应用逻辑。

  • 如需编排由模块化步骤构建的工作流,请使用 Vertex AI Pipelines。
  • 如需运行自定义 AI 和 ML 代码,请将代码打包到可在 Vertex AI 自定义训练和 Vertex AI 预测等受管理服务上运行的 Docker 容器中。
  • 对于模块化特征工程流水线,请使用 Vertex AI Feature Store
  • 如需进行模块化探索和原型设计,请使用 Vertex AI WorkbenchColab Enterprise 等笔记本环境。将代码整理成可重复使用的函数、类和脚本。

智能体应用

对于 AI 智能体,智能体开发套件 (ADK) 提供工具状态等模块化功能。为了实现 LangChainLangGraphLlamaIndex 和 Vertex AI 等框架之间的互操作性,您可以将 ADK 与 Agent2Agent (A2A) 协议模型上下文协议 (MCP) 结合使用。借助这种互操作性,您可以使用各种组件来构建代理工作流。

您可以将智能体部署到 Vertex AI Agent Engine,这是一个经过优化的托管式运行时,可实现可伸缩的智能体部署。如需运行容器化代理,您可以利用 Cloud Run 中的自动扩缩功能。

设计定义完善的接口

为了构建稳健且可维护的软件系统,务必要确保系统的组件松散耦合且模块化。这种方法具有显著优势,因为它可以最大限度地减少系统不同部分之间的依赖关系。当模块松散耦合时,一个模块中的更改对其他模块的影响很小。这种隔离可实现各个模块的独立更新和开发工作流。

以下部分提供了相关指导,可帮助确保 AI 和机器学习系统各模块之间的顺畅通信和集成。

协议选择

  • 为了实现普遍访问,请使用 HTTP API,遵循 RESTful 原则,并使用 JSON 进行与语言无关的数据交换。设计 API 端点以表示对资源的操作。
  • 如需在微服务之间进行高性能的内部通信,请使用 gRPC Protocol Buffers (ProtoBuf),以实现高效的序列化和严格的类型化。使用 .proto 文件定义 ModelInput、PredictionResult 或 ADK 工具数据等数据结构,然后生成语言绑定。
  • 对于性能至关重要的使用情形,请利用 gRPC 流式传输来处理大型数据集或连续流,例如实时文字转语音或视频应用。在 GKE 上部署 gRPC 服务。

标准化且全面的文档

无论您选择哪种接口协议,标准化文档都至关重要。OpenAPI 规范用于描述 RESTful API。使用 OpenAPI 记录 AI 和 ML API:与 JSON 架构关联的路径、方法、参数、请求-响应格式和安全性。全面的 API 文档有助于提高可发现性和客户端集成度。对于 API 编写和可视化,请使用 Swagger 编辑器等界面工具。为了加快开发速度并确保一致性,您可以使用 Gemini Code Assist 等 AI 辅助编码工具生成客户端 SDK 和服务器桩。 将 OpenAPI 文档集成到 CI/CD 流程中。

与 Google Cloud Vertex AI 等托管式服务互动

您可以选择抽象程度更高的 Vertex AI SDK(建议使用此 SDK 以提高开发效率),也可以选择 REST API 提供的精细控制功能。

  • Vertex AI SDK 可简化任务和身份验证。 当您需要与 Vertex AI 互动时,请使用 SDK。
  • REST API 是一种强大的替代方案,尤其是在需要系统各层之间实现互操作性时。对于没有 SDK 的语言中的工具或需要精细控制时,此方法非常有用。

使用 API 来隔离模块并抽象化实现细节

为了确保安全性、可伸缩性和可见性,您必须为 AI 和 ML 服务实现强大的 API 管理。如需为已定义的接口实现 API 管理,请使用以下产品:

  • API Gateway:对于外部公开和管理的 API,API Gateway 提供了一个集中式安全入口点。它简化了对无服务器后端服务(例如预测、训练和数据 API)的访问。 API Gateway 有助于整合访问点、强制执行 API 合约,以及管理 API 密钥和 OAuth 2.0 等安全功能。为了防止后端过载并确保可靠性,请在 API 网关中实现速率限制和使用量配额。
  • Cloud Endpoints:为了简化在 GKE 和 Cloud Run 上进行 API 开发和部署的过程,请使用 Cloud Endpoints,它可提供一种开发者友好的 API 密钥生成解决方案。它还为 API 调用提供集成式监控和跟踪功能,并自动生成 OpenAPI 规范,从而简化文档编制和客户端集成。您可以使用 Cloud Endpoints 管理对内部或受控 AI 和 ML API 的访问权限,例如触发训练和管理特征存储区。
  • Apigee:对于企业级 AI 和 ML,尤其是复杂的生成式 AI API,Apigee 可提供先进而全面的 API 管理。使用 Apigee 实现高级安全性(例如威胁防护和 OAuth 2.0)、流量管理(例如缓存、配额和中介)以及分析。Apigee 可帮助您深入了解 API 使用模式、性能和互动情况,这对于了解生成式 AI API 使用情况至关重要。

规划优雅降级

在生产环境 AI 和 ML 系统中,组件故障是不可避免的,就像在其他系统中一样。平缓降级可确保基本功能继续运行,但性能可能会降低。这种方法可防止完全中断,并提高整体可用性。对于延迟时间敏感型推理、分布式训练和生成式 AI,平缓降级至关重要。

以下部分介绍了用于规划和实现优雅降级的技术。

故障隔离

  • 为了在分布式架构中隔离故障组件,请使用弹性库(例如 Java 中的 Resilience4j 和 Python 中的 CircuitBreaker)实现断路器模式
  • 为防止级联故障,请根据 AI 和 ML 工作负载指标(例如错误率和延迟时间)配置阈值,并定义后备方案(例如更简单的模型和缓存数据)。

组件冗余

对于关键组件,请实现冗余和自动故障切换。例如,使用 GKE 多可用区集群或区域级集群,并在不同区域以冗余方式部署 Cloud Run 服务。如需在检测到运行状况不佳的实例时将流量路由到运行状况良好的实例,请使用 Cloud Load Balancing。

使用 Cloud Storage 多区域存储分区确保数据冗余。 对于分布式训练,请实现异步检查点,以便在发生故障后恢复训练。如需进行弹性训练,请使用 Pathways

主动监控

在发生故障时,优雅降级有助于确保系统可用性,但您还必须实施主动措施,以进行持续的健康检查和全面的监控。收集特定于 AI 和 ML 的指标,例如延迟时间、吞吐量和 GPU 利用率。此外,还可以使用 Cloud Monitoring 和 Vertex AI Model Monitoring 收集模型性能下降指标,例如模型漂移和数据漂移。

健康检查可以触发以下需求:替换故障节点、部署更多容量,或自动触发使用更新数据的流水线的持续重新训练或微调。这种主动方法有助于防止基于准确性的降级和系统级优雅降级,并有助于提高整体可靠性。

SRE 实践

如需监控系统的运行状况,请考虑采用 SRE 实践来实施服务等级目标 (SLO)。有关错误预算损失和消耗率的提醒可以作为系统可靠性问题的早期指标。如需详细了解 SRE 实践,请参阅 Google SRE 一书

构建自动化端到端 MLOps 平台

若要在 Google Cloud上构建强大、可伸缩且可靠的 AI 和 ML 系统,需要一个自动化的端到端 MLOps 平台来支持模型开发生命周期。开发生命周期包括初始数据处理、持续模型训练、部署和生产环境中的监控。通过在 Google Cloud上自动执行这些阶段,您可以建立可重复的流程、减少手动操作、最大限度地减少错误并加快创新步伐。

自动化 MLOps 平台对于为应用建立生产级可靠性至关重要。Automation 有助于确保模型质量、保证可重现性,并实现 AI 和 ML 制品的持续集成和交付。

如需构建自动化端到端 MLOps 平台,请考虑以下建议。

自动执行模型开发生命周期

自动化 MLOps 平台的核心要素是将整个 AI 和 ML 工作流编排为一系列相互关联的自动化步骤:从数据准备和验证到模型训练、评估、部署和监控。

以代码形式管理基础架构

基础设施即代码 (IaC) 对于管理 AI 和 ML 系统基础设施至关重要,有助于实现可重现、可伸缩且可维护的部署。AI 和机器学习系统的基础架构需求是动态且复杂的。这些系统通常需要 GPU 和 TPU 等专用硬件。IaC 有助于确保一致性、实现回滚并使部署可重复,从而降低手动管理基础架构的风险。

如需以代码形式有效管理基础架构资源,请使用以下技巧。

自动预配资源

如需在 Google Cloud上有效管理 IaC,请使用 Terraform 定义和预配 AI 和 ML 基础架构资源。基础设施可能包括以下资源:

  • 配置了节点池的 GKE 集群。您可以根据工作负载要求优化节点池。例如,您可以使用 A100、H100、H200 或 B200 GPU 进行训练,并使用 L4 GPU 进行推理。
  • 配置为用于模型服务的 Vertex AI 端点,具有已定义的机器类型和伸缩政策。
  • 用于存储数据和制品的 Cloud Storage 存储分区

使用配置模板

将 Terraform 配置整理为模块化模板。如需加快 AI 和 ML 资源的配置速度,您可以使用 Cluster Toolkit。该工具包提供蓝图示例,这些蓝图是 Google 精心挑选的 Terraform 模板,可用于在 Slurm 或 GKE 中部署即用型 HPC、AI 和 ML 集群。您可以自定义 Terraform 代码,并在版本控制系统中对其进行管理。如需自动执行资源配置和更新工作流,您可以使用 Cloud Build 将代码集成到 CI/CD 流水线中。

自动执行配置更改

预配基础设施后,以声明方式管理持续的配置更改:

  • 在以 Kubernetes 为中心的环境中,您可以使用 Config Connector 将 Google Cloud资源作为 Kubernetes 对象进行管理。
  • 使用 YAML 清单定义和管理 Vertex AI 资源(例如数据集、模型和端点)、Cloud SQL 实例、Pub/Sub 主题和 Cloud Storage 存储分区。
  • 将清单部署到 GKE 集群,以集成应用和基础架构配置。
  • 使用 CI/CD 流水线自动更新配置,并使用模板来处理环境差异。
  • 使用 IaC 实现 Identity and Access Management (IAM) 政策和服务账号的配置。

与 CI/CD 集成

  • 通过使用 Cloud BuildInfrastructure Manager 等工具将 IaC 集成到 CI/CD 流水线中,自动执行 Google Cloud 基础设施资源生命周期。
  • 定义代码提交时自动更新的触发条件。
  • 在流水线中实现自动化测试和验证。例如,您可以创建一个脚本来自动运行 Terraform validateplan 命令。
  • 将配置存储为制品并启用版本控制。
  • 在版本控制中定义具有不同配置的单独环境(例如开发、预演和生产环境),并自动执行环境升级。

验证模型行为

为了随着时间的推移保持模型准确性和相关性,请在 MLOps 平台中自动执行训练和评估流程。这种自动化与严格的验证相结合,有助于确保模型在部署到生产环境之前,能够根据相关数据按预期运行。

  • 设置持续训练流水线,这些流水线可由新数据和数据漂移等监控信号触发,也可按预定时间表运行。
    • 如需管理自动化训练作业(例如超参数调节试验和大型模型的分布式训练配置),请使用 Vertex AI 自定义训练
    • 对于微调基础模型,请自动执行微调流程并将作业集成到流水线中。
  • 在每次成功完成训练后,实现自动模型版本控制并安全存储训练后的模型制品。您可以将工件存储在 Cloud Storage 中,也可以在 Model Registry 中注册工件。
  • 定义评估指标并设置明确的阈值,例如最低准确率、最高错误率和最低 F1 得分。
    • 确保模型达到相应阈值,以便自动通过评估并被考虑用于部署。
    • 使用 Vertex AI 中的模型评估等服务自动执行评估。
    • 确保评估包含以下方面的指标:生成输出的质量、事实准确性、安全属性,以及对指定样式或格式的遵循情况。
  • 如需自动记录和跟踪每次训练和评估运行的参数、代码版本、数据集版本和结果,请使用 Vertex AI Experiments。这种方法提供的历史记录有助于进行比较、调试和实现可重现性。
  • 如需优化超参数调节并根据您定义的目标自动搜索最佳模型配置,请使用 Vertex AI Vizier
  • 如需直观呈现训练指标并在开发期间进行调试,请使用 Vertex AI TensorBoard

验证 AI 和 ML 流水线的输入和输出

为确保 AI 和 ML 系统的可靠性和完整性,您必须在数据进入系统并流经流水线时对其进行验证。您还必须验证组件边界处的输入和输出。对所有输入和输出(原始数据、处理后的数据、配置、实参和文件)进行稳健的验证,有助于防止意外行为,并在整个 MLOps 生命周期内保持模型质量。将这种主动式方法集成到 MLOps 平台中,有助于在错误传播到整个系统之前检测到它们,从而节省时间和资源。

如需有效验证 AI 和 ML 流水线的输入和输出,请使用以下技巧。

自动进行数据验证

  • 使用 TensorFlow Data Validation (TFDV) 在数据注入和预处理流水线中实现自动化数据验证。
    • 对于基于 SQL 的大规模数据质量检查,请利用可伸缩的处理服务,例如 BigQuery
    • 对于流式数据或批量数据的复杂程序化验证,请使用 Dataflow
  • 利用 TFDV 功能随时间监控数据分布。
    • 使用与 Cloud Monitoring 集成的工具直观呈现趋势,以检测数据漂移。当数据模式发生显著变化时,您可以自动触发模型重新训练流水线。
  • 将验证结果和指标存储在 BigQuery 中,以便进行分析和历史跟踪,并将验证工件归档在 Cloud Storage 中。

验证流水线配置和输入数据

为防止因设置不正确而导致流水线失败或出现意外行为,请对所有流水线配置和命令行实参实施严格的验证:

  • 使用 jsonschema 等 Python 架构验证库,为 YAML 或 JSON 等配置文件定义清晰的架构。在流水线运行开始之前和组件执行之前,根据这些架构验证配置对象。
  • 使用 argparse 等参数解析库,为所有命令行实参和流水线形参实现输入验证。 验证应检查正确的数据类型、有效值和必需的实参。
  • Vertex AI Pipelines 中,使用内置的组件输入验证功能定义组件形参的预期类型和属性。
  • 为确保流水线运行的可重现性并保留审核轨迹,请在 Cloud Storage 或 Artifact Registry 中存储经过验证的已纳入版本控制的配置文件。

验证输入和输出文件

验证输入和输出文件(例如数据集、模型制品和评估报告)的完整性和格式正确性:

  • 使用库验证 CSV、Parquet 等文件格式和图片类型。
  • 对于大型文件或关键制品,请使用 Cloud Storage 数据验证和更改检测功能验证文件大小和校验和,以检测损坏或不完整的传输。
  • 使用 Cloud Run functions(例如,基于文件上传事件)或在 Dataflow 流水线中执行文件验证。
  • 将验证结果存储在 BigQuery 中,以便更轻松地检索和分析。

自动执行部署并实现持续监控

自动部署和持续监控生产环境中的模型有助于确保可靠性、快速执行更新并及时检测问题。这包括管理模型版本、受控部署、使用 CI/CD 进行自动化部署,以及全面监控(如以下部分所述)。

管理模型版本

使用版本控制工具管理模型迭代和相关制品:

  • 如需跟踪模型版本和元数据并关联到基础模型制品,请使用 Model Registry
  • 实现清晰的版本控制方案(例如,语义版本控制)。为每个模型版本附加全面的元数据,例如训练参数、验证流水线的评估指标和数据集版本。
  • 将模型工件(例如模型文件、预训练权重和服务容器映像)存储在 Artifact Registry 中,并使用其版本控制和标记功能。
  • 为满足安全和治理要求,请为模型注册表和 Artifact Registry 定义严格的访问权限控制政策。
  • 如需以编程方式注册和管理版本,并将版本集成到自动化 CI/CD 流水线中,请使用 Vertex AI SDK 或 API。

执行受控部署

使用服务平台的流量管理功能控制模型版本到端点的部署。

  • 使用 Vertex AI 端点的流量分配功能实现滚动部署
  • 如果您将模型部署到 GKE,请使用高级流量管理技术,例如灰度部署
    1. 将一小部分生产流量路由到新模型版本。
    2. 通过指标持续监控性能和错误率。
    3. 证明模型可靠。
    4. 将版本面向所有流量推出。
  • 对 AI 代理执行 A/B 测试
    1. 将两个不同的模型-代理版本或完全不同的模型部署到同一端点。
    2. 在部署之间拆分流量。
    3. 根据业务目标分析结果。
  • 实现自动回滚机制,以便在触发监控提醒或未达到性能阈值时,快速将端点流量恢复到之前的稳定模型版本。
  • 使用 Vertex AI SDK 或 API 以编程方式配置流量拆分和部署设置。
  • 使用 Cloud Monitoring 跟踪不同版本之间的性能和流量。
  • 使用 CI/CD 流水线自动进行部署。您可以使用 Cloud Build 来构建容器、对工件进行版本控制,并触发向 Vertex AI 端点的部署。
  • 确保 CI/CD 流水线管理版本并从 Artifact Registry 中拉取。
  • 在迁移流量之前,请针对预测准确性、延迟时间、吞吐量和 API 功能执行自动端点测试。
  • 将所有配置存储在版本控制系统中。

持续监控

  • 使用模型监控功能自动检测性能下降、数据偏移(与训练相比输入分布发生变化)和预测偏移(模型输出发生变化)。
    • 配置包含阈值和提醒的漂移检测作业。
    • 监控实时性能:预测延迟时间、吞吐量、错误率。
  • Cloud Monitoring 中为业务 KPI 定义自定义指标。
  • 将模型监控结果和自定义指标与 Cloud Monitoring 集成,以实现提醒和信息中心功能。
  • 配置电子邮件、Slack 或 PagerDuty 等通知渠道,并配置自动补救。
  • 如需调试预测日志,请使用 Cloud Logging
  • 将监控与突发事件管理集成。

对于生成式 AI 端点,请监控输出特征,例如有害性和连贯性:

  • 监控特征应用是否存在偏移。
  • 实现精细的预测验证:使用自定义逻辑根据预期范围和格式验证输出。
  • 监控预测分布是否存在变化。
  • 验证输出架构。
  • 为意外的输出和变化配置提醒。
  • 使用 Pub/Sub 跟踪和响应实时验证事件。

确保全面监控的输出反馈到持续训练中。

通过数据和模型治理来维持信任和控制

AI 和机器学习的可靠性不仅限于技术正常运行时间。它包括信任和强大的数据与模型治理。AI 输出的内容可能不准确、有偏见或过时。此类问题会损害信任,并可能造成伤害。全面的可追溯性、严格的访问权限控制、自动验证和透明的实践有助于确保 AI 输出可靠、值得信赖且符合道德标准。

为了通过数据和模型治理来维持信任和控制权,请考虑以下建议。

建立数据和模型目录以实现可追溯性

为了便于全面跟踪、审核和了解 AI 及机器学习资产的沿袭,请在整个生命周期内维护可靠的集中式数据和模型版本记录。可靠的数据和模型目录可作为 AI 和机器学习流水线所使用和生成的所有工件(从原始数据源和处理后的数据集到训练后的模型版本和已部署的端点)的单一可信来源。

您可以使用以下产品、工具和技术来创建和维护数据资产目录:

  • 使用 Dataplex Universal Catalog 构建企业级数据资产目录。 如需自动发现数据资产并构建数据资产清单,请将 Dataplex Universal Catalog 与您的存储系统(例如 BigQueryCloud StoragePub/Sub)集成。
  • 将数据存储在 Cloud Storage 多区域或双区域存储分区中,确保数据具有高可用性和高持久性。 您上传到这些存储分区的数据以冗余方式存储在至少两个不同的地理位置。这种冗余功能可提供内置的弹性,以应对区域性服务中断,并有助于确保数据完整性。
  • 使用相关的业务元数据、所有权信息、敏感度级别和沿袭详细信息来标记和注释数据集。例如,将处理后的数据集与其原始来源以及创建该数据集的流水线相关联。
  • 使用 Model Registry 为模型版本创建中央代码库。 注册每个经过训练的模型版本,并将其与关联的元数据相关联。 元数据可以包括以下内容:
    • 训练参数。
    • 验证流水线的评估指标。
    • 用于训练的数据集版本,沿袭信息可追溯到相关的 Dataplex Universal Catalog 条目。
    • 生成数据集的代码版本。
    • 所用框架或基础模型的详细信息。
  • 在将模型导入模型注册表之前,请将模型文件和预训练权重等模型制品存储在 Cloud Storage 等服务中。将用于提供服务或自定义训练作业的自定义容器映像存储在 Artifact Registry 等安全的代码库中。
  • 为确保数据和模型资产在创建或修改后自动注册并更新到各自的目录中,请在 MLOps 流水线中实现自动化流程。这种全面的编目功能可实现从原始数据到预测的端到端可追溯性,让您可以审核导致特定模型版本或预测的输入和流程。审核功能对于调试意外行为、确保遵守数据使用政策以及了解数据或模型随时间推移而发生的变化所带来的影响至关重要。
  • 对于生成式 AI 和基础模型,您的目录还必须跟踪有关所用特定基础模型、微调参数以及与生成输出的质量和安全性相关的评估结果的详细信息。

实施强大的访问权限控制和审核跟踪

为了在 AI 和 ML 系统中保持信任和控制,您必须保护敏感数据和模型免遭未经授权的访问,并确保所有更改都有明确的责任人。

  • 在 Google Cloud中,针对 AI 和 ML 系统的所有组件实施严格的访问控制并维护详细的审核跟踪记录。
  • 在 IAM 中为与您的 AI 和 ML 资源互动的用户、群组和服务账号定义精细的权限。
  • 严格遵循最小权限原则。
  • 仅授予特定任务所需的最低权限。例如,训练服务账号需要对训练数据具有读取权限,对模型制品具有写入权限,但该服务可能不需要对生产部署端点具有写入权限。

在 AI 和 ML 系统中的所有相关资产和资源(包括以下各项)中,一致地应用 IAM 政策:

  • 包含敏感数据或模型工件的 Cloud Storage 存储分区。
  • BigQuery 数据集。
  • Vertex AI 资源,例如模型代码库、端点、流水线和 Feature Store 资源。
  • 计算资源,例如 GKE 集群和 Cloud Run 服务。

使用审核和日志来捕获、监控和分析访问活动:

  • 为 AI 和 ML 系统使用的所有 Google Cloud 服务启用 Cloud Audit Logs
  • 配置审核日志,以捕获有关 API 调用、数据访问事件以及对资源所做的配置更改的详细信息。监控日志,查看是否存在可疑活动、未经授权的访问尝试,或对关键数据或模型资产的意外修改。
  • 如需进行实时分析、提醒和可视化,请将审核日志流式传输到 Cloud Logging
  • 如需经济高效地进行长期存储,并进行回顾性安全分析或合规性审核,请将日志导出到 BigQuery。
  • 如需集中进行安全监控,请将审核日志与安全信息和事件管理 (SIEM) 系统集成。定期检查访问权限政策和审核轨迹,确保它们符合您的治理要求,并检测潜在的政策违规行为。
  • 对于处理敏感数据的应用(例如用于训练或推理的个人身份信息 (PII)),请在流水线内或数据存储空间中使用敏感数据保护检查。
  • 对于生成式 AI 和智能体解决方案,请使用审核轨迹来帮助跟踪以下信息:谁访问了特定模型或工具、哪些数据用于微调或提示,以及哪些查询发送到了生产端点。审核轨迹有助于确保责任落实,并为您调查数据滥用或违规行为提供关键数据。

解决偏见、透明度和可解释性问题

为了构建值得信赖的 AI 和机器学习系统,您需要解决数据和模型中固有的潜在偏差,努力提高系统行为的透明度,并为模型输出提供可解释性。在敏感领域或使用复杂模型(例如通常用于生成式 AI 应用的模型)时,构建值得信赖的系统尤为重要。

  • 在整个 MLOps 生命周期中实施主动实践,以识别和减轻偏见。
  • 使用可检测不同人口群体或敏感属性的特征分布中是否存在偏差的工具,分析训练数据是否存在偏差。
  • 评估总体模型性能以及在预定义的数据切片中的性能。此类评估有助于您识别影响特定子群组的性能差异或偏差。

为了提高模型透明度和可解释性,请使用可帮助用户和开发者了解模型为何做出特定预测或生成特定输出的工具。

  • 对于部署在 Vertex AI 端点上的表格模型,请使用 Vertex Explainable AI 生成特征归因。 特征归因指出了对预测结果贡献最大的输入特征。
  • 使用与 TensorBoard 集成的 What-If 工具等与模型无关的工具,以交互方式探索数据集上的模型行为和潜在偏见。
  • 将可解释性集成到监控信息中心。在需要了解模型推理过程才能建立信任或做出决策的情况下,请通过应用界面直接向最终用户提供可解释性数据。
  • 对于用于生成式 AI 模型的 LLM 等复杂模型,请说明代理遵循的流程,例如使用轨迹日志。对于此类模型,可解释性相对较难实现,但仍然至关重要。
  • 在 RAG 应用中,为检索到的信息提供引用。您还可以使用提示工程等技巧来引导模型提供说明或展示其推理步骤。
  • 通过在生产环境中实现持续监控,检测模型行为或输出的变化,这些变化可能表明出现了新的偏差或不公平现象。 在模型注册表中将模型限制、预期使用场景和已知的潜在偏见记录为模型元数据的一部分。

实施全面的 AI 和机器学习可观测性和可靠性实践

整体可观测性对于管理生产环境中的复杂 AI 和 ML 系统至关重要。此外,由于复杂 AI 和 ML 系统(尤其是生成式 AI)的复杂性、资源密集性和潜在的不可预测的输出,它对于衡量这些系统的可靠性也至关重要。整体可观测性是指观测基础架构、应用代码、数据和模型行为,以获得相关信息,从而主动检测、诊断和响应问题。这种可观测性最终会带来高性能、可靠的系统。如需实现全面的可观测性,您需要执行以下操作:

  • 采用 SRE 原则。
  • 确定明确的可靠性目标。
  • 跟踪各个系统层的指标。
  • 利用可观测性分析结果持续改进并主动管理。

如需在 Google Cloud中为 AI 和机器学习工作负载实施全面的可观测性和可靠性实践,请考虑以下建议。

确定可靠性目标和业务指标

确定 AI 和 ML 系统直接影响的关键绩效指标 (KPI)。这些 KPI 可能包括受 AI 推荐影响的收入、AI 系统预测或缓解的客户流失情况,以及由生成式 AI 功能带来的用户互动度和转化率。

针对每个 KPI,定义影响该 KPI 的相应技术可靠性指标。例如,如果 KPI 是“客户对对话式 AI 助理的满意度”,则相应的可靠性指标可以包括以下内容:

  • 用户请求的成功率。
  • 回答的延迟时间:LLM 的第一个 token 时间 (TTFT) 和 token 流式传输。
  • 不相关或有害回答的比例。
  • 代理成功完成任务的比率。

对于 AI 和 ML 训练,可靠性指标可以包括模型 FLOP 利用率 (MFU)、每秒迭代次数、每秒令牌数和每个设备的令牌数。

如需有效衡量和提升 AI 和 ML 可靠性,首先要设定明确的可靠性目标,确保其与总体业务目标保持一致。采用 SRE 方法,从用户角度定义 SLO,以量化 AI 和 ML 服务的可接受可靠性和性能水平。使用具体的 SLO 目标来量化这些技术可靠性指标。

以下是 SLO 目标的示例:

  • 99.9% 的 API 调用必须返回成功响应。
  • 第 95 百分位推理延迟时间必须低于 300 毫秒。
  • 99% 的请求的 TTFT 必须低于 500 毫秒。
  • 有害输出的比例必须低于 0.1%。

将 SLO 直接与业务需求保持一致,可确保可靠性工作重点放在影响用户和业务的最关键系统行为上。这种方法有助于将可靠性转变为可衡量且可操作的工程属性。

监控基础架构和应用性能

跟踪 AI 和 ML 系统使用的所有资源的基础设施指标。这些指标包括处理器使用情况(CPU、GPU 和 TPU)、内存使用情况、网络吞吐量和延迟时间以及磁盘 I/O。跟踪托管环境(例如 Vertex AI Training 和 Serving)以及自行管理的资源(例如 GKE 节点和 Cloud Run 实例)的指标。

监控 AI 和机器学习应用的四个黄金信号

  • 延迟时间:响应请求所需的时间。
  • 流量:请求量或工作负载量。
  • 错误率:失败的请求或操作的比率。
  • 饱和度:CPU、内存和 GPU 或 TPU 加速器等关键资源的利用率,表示系统接近容量限制的程度。

使用以下方法执行监控:

  • 使用 Cloud Monitoring 收集、存储和直观呈现基础架构和应用指标。 您可以使用预建的信息中心来监控 Google Cloud 服务,还可以创建自定义信息中心,根据工作负载的特定性能指标和基础设施运行状况量身定制。
  • 使用 Cloud Logging 从 AI 和 ML 应用以及底层基础架构收集详细日志。 这些日志对于问题排查和性能分析至关重要。它们可提供有关事件和错误的背景信息。
  • 使用 Cloud Trace 找出延迟问题,并了解分布式 AI 和 ML 微服务中的请求流。 此功能对于调试复杂的 Vertex AI 智能体互动或多组件推理流水线至关重要。
  • 使用 Cloud Profiler 找出应用代码中函数块内的性能瓶颈。 识别性能瓶颈有助于您优化资源使用情况和执行时间。
  • 使用 NVIDIA Data Center GPU Manager (DCGM) 等工具,收集与加速器相关的特定指标,例如每个进程的详细 GPU 利用率、每个进程的内存用量和温度。

实现数据和模型可观测性

可靠的生成式 AI 系统需要强大的数据和模型可观测性,而这首先要从端到端流水线监控开始。

  • 使用 Dataflow 等服务跟踪数据注入速率、处理量和转换延迟时间。
  • 监控 MLOps 流水线(包括由 Vertex AI Pipelines 管理的流水线)中的作业成功率和失败率。

持续评估数据质量至关重要。

  • 使用 Dataplex Universal Catalog 管理和治理数据:
    • 通过根据标准答案进行验证或跟踪离群点检测率来评估准确率。
    • 根据数据的新旧程度和更新频率,对照 SLA 监控数据新鲜度。
    • 通过跟踪 null 值百分比和必填字段填充率来评估完整性。
    • 通过检查架构一致性和重复情况,确保有效性和一致性。
  • 使用 Cloud Monitoring 提醒主动检测异常,并通过清晰的数据沿袭实现可追溯性。
  • 对于 RAG 系统,请检查检索到的上下文的相关性以及回答的接地性(归因于来源)。
  • 监控向量数据库查询的吞吐量。

关键模型可观测性指标包括输入-输出令牌数量和特定于模型的错误率,例如幻觉或查询解析失败。如需跟踪这些指标,请使用模型监控

  • 持续监控输出的毒性得分和用户反馈评分。
  • 使用 Gen AI Evaluation Service,根据定义的标准自动评估模型输出。
  • 通过全面的错误率指标,系统性地监控数据和概念漂移,确保性能持续稳定。

如需跟踪模型指标,您可以使用 TensorBoardMLflow。如需进行深入分析和性能剖析以排查性能问题,您可以使用 PyTorch XLA 性能剖析NVIDIA Nsight

贡献者

作者:

其他贡献者: