ZenML Google Cloud Vertex AI Orchestrator 实战指南从权限配置到 GPU 加速与定时调度【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml本文基于 ZenML 开源仓库中的 Vertex AI Orchestrator 官方文档并结合 vertex_orchestrator_flavor.py、vertex_orchestrator.py、vertex_custom_job_parameters.py 等源码实现系统讲解如何在 ZenML 中使用 Google Cloud Vertex AI Pipelines 作为生产级、Serverless 的管线编排器。读完本文你将掌握Vertex 编排器的适用场景与部署前提、三种 GCP 认证/权限配置方案、栈注册与运行、运行级 GPU 与自定义作业参数Custom Job Parameters配置、定时调度以及基于 Persistent Resources 的开发提速方案。Vertex AI Orchestrator 是什么何时使用它Vertex AI Pipelines 是运行在 Google Cloud Platform 上的无服务器Serverless机器学习工作流工具。在 ZenML 中Vertex orchestrator 让您无需预先配置并长期支付闲置计算资源即可在云端以近乎零基础设施维护成本的方式将代码以生产就绪、可重复的方式快速运行。⚠️重要前提该组件仅应在 远程 ZenML 部署场景 下使用。与本地 ZenML 部署配合使用可能导致意外行为从源码看VertexOrchestratorConfig.is_remote 恒为True即它被明确定位为“远程组件”要求连接到远程 ZenML Server 后才能使用。以下情况应使用 Vertex orchestrator您已经在使用 GCP您需要一个经过验证的生产级编排器您需要一个可以跟踪管线运行的 UI您需要一个托管managed方案来运行管线您需要一个 Serverless 方案来运行管线。部署前提远程 ZenML 与 GCP 项目准备要使用 Vertex AI orchestrator需要先把 ZenML 部署到云端。建议将 ZenML 部署在与 Vertex 基础设施相同的 Google Cloud 项目中并非必须。在使用该栈组件之前必须确保已连接到远程 ZenML Server。除此之外唯一必要的准备工作是在 GCP 项目中启用 Vertex 相关 API。使用 Vertex orchestrator 需要具备已安装 ZenMLgcp集成——若未安装运行zenml integration install gcpDocker 已安装并运行栈中包含一个远程 Artifact Store栈中包含一个远程 Container Registry具备正确权限的 GCP 凭证希望运行 Vertex AI 管线的 GCP 项目 IDproject ID与区域location。其中“GCP 凭证与权限”是整个使用过程中最复杂的部分下文将重点展开。GCP 凭证与权限模型要在 Vertex AI 上运行管线您需要拥有一个 GCP 用户账号和/或一个或多个具备适当权限的 GCP 服务账号Service Account具体取决于您是否希望遵循最小权限原则将权限分散到多个服务账号上。向编排器提供凭证有三种方式使用gcloudCLI 在本地使用 GCP 账号进行认证在编排器配置中设置service_account_path参数使用服务账号密钥文件认证推荐配置一个携带 GCP 凭证的 GCP Service Connector并将 Vertex AI Orchestrator 栈组件与 Service Connector 关联。Vertex AI 管线涉及的两类组件及其权限要理解需要创建哪些账号以及为什么需要先弄清 Vertex orchestrator 的两类运行环境ZenML 客户端环境ZenML client environment运行 ZenML 代码、负责构建管线 Docker 镜像并提交管线到 Vertex AI 的环境。通常是您的本地机器或用于自动化运行管线的 CI/CD 作业。该环境需要能够认证 GCP并具备在 Vertex Pipelines 中创建作业的权限例如Vertex AI User角色。如果计划定时运行管线还需要额外权限Storage Object Creator角色以便直接将管线 JSON 文件写入 Artifact Store注意如果 Artifact Store 已配置凭证或关联了 Service Connector则不需要此角色。Vertex AI 管线环境Vertex AI pipeline environment管线步骤实际在 GCP 中运行的环境。Vertex AI 管线以某个 GCP 服务账号下文称workload service account的身份运行。该服务账号可在编排器配置中通过workload_service_account参数显式指定如果省略编排器将使用管线运行所在 GCP 项目的 Compute Engine 默认服务账号。该服务账号需要具备运行 Vertex AI 管线的权限例如Vertex AI Service Agent角色。可以看到运行一条 Vertex AI 管线可能涉及多个专用服务账号——如果客户端环境也使用服务账号认证那就是两个服务账号。当然也可以简化处处使用同一个服务账号。配置用例一本地 gcloud CLI 用户账号该方案假设您已通过gcloud auth login在本地配置了gcloudCLI 认证并满足您的 GCP 账号具备在 Vertex Pipelines 中创建作业的权限例如Vertex AI User角色管线运行所在 GCP 项目的 Compute Engine 默认服务账号 已更新具备运行 Vertex AI 管线所需的额外权限例如Vertex AI Service Agent角色。这是配置 Vertex AI Orchestrator 最简单的方式但有如下缺点配置无法在其他机器上移植、也无法由其他用户复现使用了 Compute Engine 默认服务账号这不被推荐因为它默认拥有大量权限且被许多其他 GCP 服务共用。随后按如下方式注册编排器zenml orchestrator register ORCHESTRATOR_NAME \ --flavorvertex \ --projectPROJECT_ID \ --locationGCP_LOCATION \ --synchronoustrue配置用例二GCP Service Connector 单一服务账号该方案假设您已配置了一个具备以下权限的 GCP 服务账号在 Vertex Pipelines 中创建作业的权限例如Vertex AI User角色运行 Vertex AI 管线的权限例如Vertex AI Service Agent角色Storage Object Creator 角色以便直接将管线 JSON 文件写入 Artifact Store。同时假设您已为该服务账号创建了密钥并下载到本地例如connectors-vertex-ai.json文件。如果您注重安全这种方式并不推荐它没有应用最小权限原则管线步骤运行的环境拥有许多它并不需要的权限。zenml service-connector register CONNECTOR_NAME --type gcp --auth-methodservice-account --project_idPROJECT_ID --service_account_jsonconnectors-vertex-ai.json --resource-type gcp-generic zenml orchestrator register ORCHESTRATOR_NAME \ --flavorvertex \ --locationGCP_LOCATION \ --synchronoustrue \ --workload_service_accountSERVICE_ACCOUNT_NAMEPROJECT_NAME.iam.gserviceaccount.com zenml orchestrator connect ORCHESTRATOR_NAME --connector CONNECTOR_NAME配置用例三GCP Service Connector 不同服务账号最小权限该方案通过为运行 Vertex AI 管线的不同组件分别使用权限最小化的服务账号实践最小权限原则。同时使用 GCP Service Connector 使配置可移植、可复现。这是生产中通常会采用的“最佳实践”级配置但准备工作要多得多。 该方案需要创建并配置多个 GCP 服务账号工作量较大且容易出错。如果不需要额外的安全性可以直接使用上文单一服务账号方案。需要以下 GCP 服务账号一个“client” 服务账号具备以下权限在 Vertex Pipelines 中创建作业的权限例如Vertex AI User角色创建 Google Cloud Function 的权限例如Cloud Functions Developer角色Storage Object Creator 角色以便直接将管线 JSON 文件写入 Artifact Store注意如果 Artifact Store 已配置凭证或关联了 Service Connector则不需要。一个“workload” 服务账号具备运行 Vertex AI 管线的权限例如Vertex AI Service Agent角色。替代方案使用自定义角色实现最大安全性如需更细粒度的控制可以创建自定义角色代替预定义角色Client 服务账号自定义权限aiplatform.pipelineJobs.createaiplatform.pipelineJobs.getaiplatform.pipelineJobs.listcloudfunctions.functions.createstorage.objects.create用于访问 Artifact StoreWorkload 服务账号自定义权限aiplatform.customJobs.createaiplatform.customJobs.getaiplatform.customJobs.liststorage.objects.getstorage.objects.create这提供了 Vertex AI 管线操作所需的最小权限集合。还需要为 “client” 服务账号创建密钥并下载到本地例如connectors-vertex-ai-client.json文件。准备好所有服务账号和密钥后按如下方式注册 GCP Service Connector 和 Vertex AI orchestratorzenml service-connector register CONNECTOR_NAME --type gcp --auth-methodservice-account --project_idPROJECT_ID --service_account_jsonconnectors-vertex-ai-client.json --resource-type gcp-generic zenml orchestrator register ORCHESTRATOR_NAME \ --flavorvertex \ --locationGCP_LOCATION \ --synchronoustrue \ --workload_service_accountWORKLOAD_SERVICE_ACCOUNT_NAMEPROJECT_NAME.iam.gserviceaccount.com zenml orchestrator connect ORCHESTRATOR_NAME --connector CONNECTOR_NAME注册栈并运行管线编排器注册完成后即可在活动栈active stack中使用它# 注册并激活包含新编排器的栈 zenml stack register STACK_NAME -o ORCHESTRATOR_NAME ... --set ZenML 会构建一个名为CONTAINER_REGISTRY_URI/zenml:PIPELINE_NAME的 Docker 镜像其中包含您的代码并用它在 Vertex AI 中运行管线步骤。关于 ZenML 如何构建这些镜像以及如何自定义可参考容器化相关文档。现在即可使用 Vertex orchestrator 运行任何 ZenML 管线python file_that_runs_a_zenml_pipeline.py源码视角的栈校验从 VertexOrchestrator.validator 可以看到Vertex orchestrator 对栈有严格的校验逻辑——栈中必须包含 Container Registry 和 Image Builder 组件任何本地组件都会被拒绝因为 Vertex 无法连接到您的本地机器如果未设置pipeline_root且 Artifact Store 不是 GCP Artifact Storezenml.integrations.gcp.artifact_store.GCPArtifactStore也会校验失败。对应的集成测试见 test_vertex_orchestrator.py。该校验逻辑与文档中“需要远程 Artifact Store 与远程 Container Registry”的要求完全一致。查看运行Vertex UI 与 orchestrator_urlVertex 自带 UI可用于查看管线运行的更多细节例如步骤日志对于任何在 Vertex 上执行的运行可以在 Python 中通过以下代码片段获取指向 Vertex UI 的 URLfrom zenml.client import Client pipeline_run Client().get_pipeline_run(PIPELINE_RUN_NAME) orchestrator_url pipeline_run.run_metadata[orchestrator_url]从源码看该 URL 由 get_pipeline_run_metadata 生成静态管线指向https://console.cloud.google.com/vertex-ai/locations/location/pipelines/runs/run_id动态管线则指向.../training/run_id并附带?projectproject参数。它同时把METADATA_ORCHESTRATOR_RUN_ID与METADATA_ORCHESTRATOR_URL写入运行元数据这就是文档中run_metadata[orchestrator_url]的数据来源。定时调度管线Vertex Pipelines orchestrator 支持使用其原生调度能力定时运行管线。如何调度管线from datetime import datetime, timedelta from zenml import pipeline from zenml.config.schedule import Schedule pipeline def first_pipeline(): ... # 每 5 分钟运行一次管线 first_pipeline first_pipeline.with_options( scheduleSchedule( cron_expression*/5 * * * * ) ) first_pipeline() pipeline def second_pipeline(): ... # 每小时运行一次管线 # 从一天后开始到三天后结束 second_pipeline second_pipeline.with_options( scheduleSchedule( cron_expression0 * * * *, start_timedatetime.now() timedelta(days1), end_timedatetime.now() timedelta(days3), ) ) second_pipeline()⚠️ Vertex orchestrator 只支持Schedule对象中的cron_expression、start_time可选和end_time可选参数会忽略为定义调度而提供的所有其他参数。start_time和end_time时间戳参数均为可选以本地时间指定它们定义了管线运行被触发的时间窗口。如果未指定管线将无限期运行。cron_expression参数支持时区。例如表达式TZEurope/Paris 0 10 * * *将在 Europe/Paris 时区的 10:00 触发运行。源码中submit_pipeline 对调度的处理印证了这一点若调度包含catchup或interval_second会告警提示“Vertex orchestrator 只使用cron_expression及可选的start_time/end_time属性”若cron_expression为None则直接抛出ValueError。实际提交时调用run.create_schedule(...)使用 Vertex 原生调度能力见 vertex_orchestrator.py。如何更新/删除已调度的管线请注意ZenML 只负责调度一次运行而调度生命周期的维护是用户的责任。要取消已调度的 Vertex 管线需要手动在 Vertex AI 中删除调度通过 UI 或 CLI。以下是一个示例警告运行它将会删除所有调度from google.cloud import aiplatform from zenml.client import Client def delete_all_schedules(): # 初始化 ZenML 客户端 zenml_client Client() # 获取所有 ZenML 调度 zenml_schedules zenml_client.list_schedules() if not zenml_schedules: print(No ZenML schedules to delete.) return print(f\nFound {len(zenml_schedules)} ZenML schedules to process...\n) # 处理每个 ZenML 调度 for zenml_schedule in zenml_schedules: schedule_name zenml_schedule.name print(fProcessing ZenML schedule: {schedule_name}) try: # 首先删除对应的 Vertex AI 调度 vertex_filter fdisplay_name{schedule_name} vertex_schedules aiplatform.PipelineJobSchedule.list( filtervertex_filter, order_bycreate_time desc, locationeurope-west1 ) if vertex_schedules: print(f Found {len(vertex_schedules)} matching Vertex schedules) for vertex_schedule in vertex_schedules: try: vertex_schedule.delete() print(f ✓ Deleted Vertex schedule: {vertex_schedule.display_name}) except Exception as e: print(f ✗ Failed to delete Vertex schedule {vertex_schedule.display_name}: {e}) else: print(f No matching Vertex schedules found for {schedule_name}) # 然后删除 ZenML 调度 zenml_client.delete_schedule(zenml_schedule.id) print(f ✓ Deleted ZenML schedule: {schedule_name}) except Exception as e: print(f ✗ Failed to process {schedule_name}: {e}) print(\nSchedule cleanup completed!) if __name__ __main__: delete_all_schedules()运行级设置标签、节点选择器与 GPU如需对 Vertex orchestrator 进行额外配置可以传入VertexOrchestratorSettings它允许为 Vertex Pipeline 作业配置标签labels或指定使用哪种 GPUfrom zenml.integrations.gcp.flavors.vertex_orchestrator_flavor import ( VertexOrchestratorSettings ) vertex_settings VertexOrchestratorSettings(labels{key: value})从 vertex_orchestrator_flavor.py 源码可以看到VertexOrchestratorSettings包含以下字段字段默认值说明labels{}分配给管线作业的标签例如{environment: production, team: ml-ops}synchronousTrue为True时客户端等待所有步骤运行完成为False时客户端立即返回管线异步执行node_selector_constraintNone键值对标签形式的节点约束已标记为 deprecated见下文说明pod_settingsNone应用于编排器与步骤 Pod 的 Kubernetes Pod 设置KubernetesPodSettingscustom_job_parametersNoneVertex AI 自定义作业的定制参数VertexCustomJobParameters如果您的管线步骤有特定的硬件需求可以通过ResourceSettings指定from zenml.config import ResourceSettings resource_settings ResourceSettings(cpu_count8, memory16GB)要在 GPU 上运行整个管线或其部分步骤需要同时设置节点选择器和 GPU 数量from zenml import step, pipeline from zenml.config import ResourceSettings from zenml.integrations.gcp.flavors.vertex_orchestrator_flavor import ( VertexOrchestratorSettings ) vertex_settings VertexOrchestratorSettings( pod_settings{ node_selectors: { cloud.google.com/gke-accelerator: NVIDIA_TESLA_A100 }, } ) resource_settings ResourceSettings(gpu_count1) # 在步骤级别指定设置 step( settings{ orchestrator: vertex_settings, resources: resource_settings, } ) def my_step(): ... # 或者在管线级别指定 pipeline( settings{ orchestrator: vertex_settings, resources: resource_settings, } ) def my_pipeline(): ...可用的加速器类型accelerator types列表可参考 GCP Vertex AI 的 compute 配置文档。源码视角的 GPU 下发逻辑在 vertex_orchestrator.py 的_configure_container_resources中GPU 的生效需要同时满足两个条件节点选择器指向cloud.google.com/gke-accelerator标签常量定义见 constants.py且ResourceSettings.gpu_count大于 0若指定了加速器类型但 GPU 数量为 0则只会记录告警并忽略加速器类型。另外pod_settings中除node_selectors外的其他字段在 Vertex Pipelines 2.x 下不受支持会被忽略见 vertex_orchestrator.py。自定义作业参数VertexCustomJobParameters对于更高级的硬件配置可以使用VertexCustomJobParameters定制每个步骤的执行环境。这允许指定启动盘大小、加速器类型、机器类型等详细要求而无需单独的 Step Operatorfrom zenml.integrations.gcp.vertex_custom_job_parameters import ( VertexCustomJobParameters, ) from zenml import step, pipeline from zenml.integrations.gcp.flavors.vertex_orchestrator_flavor import ( VertexOrchestratorSettings ) # 创建使用更大启动盘1TB的设置 large_disk_settings VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( boot_disk_size_gb1000, # 1TB 磁盘 boot_disk_typepd-standard, # 标准持久磁盘更便宜 machine_typen1-standard-8 ) ) # 创建带 GPU 加速的设置 gpu_settings VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( accelerator_typeNVIDIA_TESLA_A100, accelerator_count1, machine_typen1-standard-8, boot_disk_size_gb200 # 为 GPU 负载使用更大的磁盘 ) ) # 需要大磁盘但不需要 GPU 的步骤 step(settings{orchestrator: large_disk_settings}) def data_processing_step(): # 处理需要大量磁盘空间的大数据集 ... # 需要 GPU 加速的步骤 step(settings{orchestrator: gpu_settings}) def training_step(): # 使用 GPU 训练 ML 模型 ... # 定义同时使用两个步骤的管线 pipeline() def my_pipeline(): data data_processing_step() model training_step(data) ...也可以在管线级别指定这些参数将其应用到所有步骤pipeline( settings{ orchestrator: VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( boot_disk_size_gb500, # 为所有步骤使用 500GB 磁盘 machine_typen1-standard-4 ) ) } ) def my_pipeline(): ...VertexCustomJobParameters支持的常用配置选项默认值与源码 vertex_custom_job_parameters.py 一致参数说明boot_disk_size_gb启动盘大小GB默认100boot_disk_type磁盘类型pd-standard、pd-ssd等默认pd-ssdmachine_type计算所用的机器类型如n1-standard-4默认n1-standard-4accelerator_type加速器类型如NVIDIA_TESLA_T4、NVIDIA_TESLA_A100accelerator_count附加的加速器数量默认0service_account作业使用的服务账号persistent_resource_id用于加快作业启动的持久资源 IDadditional_training_job_args透传给底层 Google Cloud Pipeline Components 库的附加参数见下文高级自定义作业参数对于高级场景可以使用additional_training_job_args将附加参数直接透传给底层 Google Cloud Pipeline Components 库step( settings{ orchestrator: VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( machine_typen1-standard-8, # 直接透传给 create_custom_training_job_from_component 的高级参数 additional_training_job_args{ timeout: 86400s, # 24 小时超时 network: projects/12345/global/networks/my-vpc, enable_web_access: True, reserved_ip_ranges: [192.168.0.0/16], base_output_directory: gs://my-bucket/outputs, labels: {team: ml-research, project: image-classification} } ) ) } ) def my_advanced_step(): ...这些高级参数直接传递给 Google Cloud Pipeline Components 库的create_custom_training_job_from_component函数。这种方式让您可以无需等待 ZenML 更新即可使用 Google API 的新特性。⚠️ 如果在additional_training_job_args中指定的参数同时也是显式属性如machine_type或boot_disk_size_gbadditional_training_job_args中的值将覆盖显式值。例如VertexCustomJobParameters( machine_typen1-standard-4, # 将被覆盖 additional_training_job_args{ machine_type: n1-standard-16 # 优先 } )最终生效的机器类型将是n1-standard-16。发生这种情况时ZenML 会在运行时记录一条告警提示参数被覆盖以避免对实际生效的配置值产生困惑。源码中的覆盖检测与告警逻辑见 vertex_orchestrator.py。 使用custom_job_parameters时ZenML 会自动应用编排器配置中的某些设置网络配置Network Configuration如果在 Vertex orchestrator 配置中设置了network它会自动应用到所有自定义作业除非您在additional_training_job_args中显式覆盖它。加密规范Encryption Specification如果在编排器配置中设置了encryption_spec_key_name它会被应用到自定义作业以保证加密一致。服务账号Service Account对于非持久资源作业如果自定义作业参数中未指定服务账号将使用编排器配置中的workload_service_account。这种继承机制确保跨管线步骤的配置保持一致无需为每个步骤手动指定即可维护与 GCP 资源如数据库的连接性、安全设置和计算资源。该逻辑的实现见 vertex_orchestrator.py。请注意当自定义作业参数使用persistent_resource_id时必须同时指定service_account。additional_training_job_args字段为 ZenML 管线提供了面向未来的能力。如果 Google 为其 API 增加了新参数您可以立即使用它们而无需等待 ZenML 更新。这对于使用新的硬件配置、网络特性或安全设置尤其有用。为 GPU 硬件启用 CUDA请注意如果您希望使用此编排器在 GPU 上运行步骤需要参考分布式训练相关文档中的说明来确保其正常工作。这需要增加一些额外的设置定制并且对于 GPU 充分发挥其全部加速能力来说启用 CUDA 是必需的。使用持久资源Persistent Resources加速开发迭代在开发使用 Vertex AI 的 ML 管线时每个步骤的启动时间可能非常显著因为 Vertex 需要为每次运行预置新的计算资源。为了加快开发迭代可以使用 Vertex AI 的持久资源Persistent Resources功能它在各次运行之间保持计算资源处于热状态。要使用带 Vertex orchestrator 的持久资源首先需要创建持久资源通过 GCP Cloud UI或遵循 GCP 文档中的说明。接下来需要配置编排器在持久资源上运行。这可以通过仪表盘dashboard或 CLI 完成此时将应用于所有使用该编排器运行的管线也可以在代码中针对特定管线甚至单个步骤动态配置。⚠️ 注意具备访问持久资源权限的服务账号是必需的请务必始终将其包含在配置中。使用 CLI 配置编排器# 也可以使用 zenml orchestrator update zenml orchestrator register NAME -f vertex --custom_job_parameters{persistent_resource_id: PERSISTENT_RESOURCE_ID, service_account: SERVICE_ACCOUNT_NAME, machine_type: n1-standard-4, boot_disk_type: pd-standard}使用仪表盘配置编排器导航到 ZenML 仪表盘的Stacks部分创建新的 Vertex orchestrator 或更新现有编排器。在创建/更新过程中在custom_job_parameters属性中设置持久资源 ID 和其他值。在代码中动态配置编排器from zenml.integrations.gcp.vertex_custom_job_parameters import ( VertexCustomJobParameters, ) from zenml.integrations.gcp.flavors.vertex_orchestrator_flavor import ( VertexOrchestratorSettings ) # 在管线级别配置适用于所有步骤 pipeline( settings{ orchestrator: VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( persistent_resource_idPERSISTENT_RESOURCE_ID, service_accountSERVICE_ACCOUNT_NAME, machine_typen1-standard-4, boot_disk_typepd-standard ) ) } ) def my_pipeline(): ... # 为单个步骤配置 step( settings{ orchestrator: VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( persistent_resource_idPERSISTENT_RESOURCE_ID, service_accountSERVICE_ACCOUNT_NAME, machine_typen1-standard-4, boot_disk_typepd-standard ) ) } ) def my_step(): ...如果需要在显式指定不使用任何持久资源请将persistent_resource_id设置为空字符串step( settings{ orchestrator: VertexOrchestratorSettings( custom_job_parametersVertexCustomJobParameters( persistent_resource_id, # 显式不使用持久资源 boot_disk_size_gb1000, # 设置大磁盘 machine_typen1-standard-8 ) ) } ) def my_step(): ...使用持久资源在本地开发并希望快速迭代需要云资源的步骤时特别有用作业的启动时间可以极其迅速。⚠️ 使用持久资源指定了persistent_resource_id时必须始终包含service_account。反之当显式设置persistent_resource_id以避免使用持久资源时ZenML 会自动将服务账号设置为空字符串以避免 Vertex API 报错——因此这种情况下不要再设置服务账号。源码中这一行为在 vertex_orchestrator.py 有所体现指定了持久资源 ID 但未提供服务账号时会回退使用编排器配置中的workload_service_account。⚠️ 请记住持久资源只要在运行就会持续产生费用即使处于空闲状态也是如此。请务必监控您的用量并配置适当的空闲超时时间。附Vertex orchestrator 配置字段速查综合 vertex_orchestrator_flavor.py 源码VertexOrchestratorConfig的完整字段如下供注册与更新编排器时参考字段是否必填/默认说明location必填GCP 区域管线作业将在此执行Vertex AI Pipelines 仅在特定区域可用project可选GCP 项目 IDpipeline_root可选Vertex AI Pipelines 使用的 Cloud Storage URI未提供且栈中 Artifact Store 为 GCPArtifactStore 时自动使用其子目录encryption_spec_key_name可选用于保护作业的 Cloud KMS 客户管理加密密钥资源标识符格式为projects/PROJECT/locations/REGION/keyRings/KR/cryptoKeys/KEYworkload_service_account可选工作负载运行身份账号未提供时使用 Compute Engine 默认服务账号network可选作业所对等的 Compute Engine 网络全名例如projects/12345/global/networks/myVPCprivate_service_connect可选作业所对等的 Private Service Connect 端点全名如projects/12345/regions/us-central1/networkAttachments/NAMEsynchronousTrue是否同步等待管线运行完成labels{}应用于管线作业的标签pod_settingsNonePod 设置仅node_selectors受支持custom_job_parametersNone自定义作业参数cpu_limit/memory_limit/gpu_limit已废弃分别被custom_job_parameters或pod_settings取代function_service_account/scheduler_service_account已废弃旧版定时管线相关该功能已不再支持此外VertexOrchestratorFlavor声明了对 GCP 类型 Service Connector 的资源要求vertex_orchestrator_flavor.py这正是文档中“推荐使用 GCP Service Connector 认证”在实现层面的体现——注册编排器后可通过zenml orchestrator connect将其与 Service Connector 关联。至此您已经掌握了 ZenML Vertex AI Orchestrator 从权限规划、注册部署到调度、GPU 定制与持久资源提速的完整链路可以据此在自己的 GCP 项目中落地生产级、Serverless 的管线编排方案。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考