ZenML Google Cloud Vertex AI Orchestrator 实战指南：从权限配置到 GPU 加速与定时调度

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 需要具备：

1. 已安装 ZenMLgcp集成——若未安装，运行：

   zenml integration install gcp

2. Docker 已安装并运行；

3. 栈中包含一个远程 Artifact Store；

4. 栈中包含一个远程 Container Registry；

5. 具备正确权限的 GCP 凭证；

6. 希望运行 Vertex AI 管线的 GCP 项目 ID（project ID）与区域（location）。

其中“GCP 凭证与权限”是整个使用过程中最复杂的部分，下文将重点展开。

GCP 凭证与权限模型

要在 Vertex AI 上运行管线，您需要拥有一个 GCP 用户账号和/或一个或多个具备适当权限的 GCP 服务账号（Service Account），具体取决于您是否希望遵循最小权限原则，将权限分散到多个服务账号上。

向编排器提供凭证有三种方式：

1. 使用gcloudCLI 在本地使用 GCP 账号进行认证；
2. 在编排器配置中设置service_account_path参数，使用服务账号密钥文件认证；
3. （推荐）配置一个携带 GCP 凭证的 GCP Service Connector，并将 Vertex AI Orchestrator 栈组件与 Service Connector 关联。

Vertex AI 管线涉及的两类组件及其权限

要理解需要创建哪些账号以及为什么，需要先弄清 Vertex orchestrator 的两类运行环境：

1. 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，则不需要此角色）。

2. 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> \ --flavor=vertex \ --project=<PROJECT_ID> \ --location=<GCP_LOCATION> \ --synchronous=true

配置用例二：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-method=service-account --project_id=<PROJECT_ID> --service_account_json=@connectors-vertex-ai.json --resource-type gcp-generic zenml orchestrator register <ORCHESTRATOR_NAME> \ --flavor=vertex \ --location=<GCP_LOCATION> \ --synchronous=true \ --workload_service_account=<SERVICE_ACCOUNT_NAME>@<PROJECT_NAME>.iam.gserviceaccount.com zenml orchestrator connect <ORCHESTRATOR_NAME> --connector <CONNECTOR_NAME>

配置用例三：GCP Service Connector + 不同服务账号（最小权限）

该方案通过为运行 Vertex AI 管线的不同组件分别使用权限最小化的服务账号，实践最小权限原则。同时使用 GCP Service Connector 使配置可移植、可复现。这是生产中通常会采用的“最佳实践”级配置，但准备工作要多得多。

💡 该方案需要创建并配置多个 GCP 服务账号，工作量较大且容易出错。如果不需要额外的安全性，可以直接使用上文单一服务账号方案。

需要以下 GCP 服务账号：

1. 一个“client” 服务账号，具备以下权限：
   • 在 Vertex Pipelines 中创建作业的权限（例如Vertex AI User角色）；
   • 创建 Google Cloud Function 的权限（例如Cloud Functions Developer角色）；
   • Storage Object Creator 角色，以便直接将管线 JSON 文件写入 Artifact Store（注意：如果 Artifact Store 已配置凭证或关联了 Service Connector，则不需要）。
2. 一个“workload” 服务账号，具备运行 Vertex AI 管线的权限（例如Vertex AI Service Agent角色）。

💡替代方案：使用自定义角色实现最大安全性

如需更细粒度的控制，可以创建自定义角色代替预定义角色：

Client 服务账号自定义权限：

• aiplatform.pipelineJobs.create
• aiplatform.pipelineJobs.get
• aiplatform.pipelineJobs.list
• cloudfunctions.functions.create
• storage.objects.create（用于访问 Artifact Store）

Workload 服务账号自定义权限：

• aiplatform.customJobs.create
• aiplatform.customJobs.get
• aiplatform.customJobs.list
• storage.objects.get
• storage.objects.create

这提供了 Vertex AI 管线操作所需的最小权限集合。

还需要为 “client” 服务账号创建密钥并下载到本地（例如connectors-vertex-ai-client.json文件）。准备好所有服务账号和密钥后，按如下方式注册 GCP Service Connector 和 Vertex AI orchestrator：

zenml service-connector register <CONNECTOR_NAME> --type gcp --auth-method=service-account --project_id=<PROJECT_ID> --service_account_json=@connectors-vertex-ai-client.json --resource-type gcp-generic zenml orchestrator register <ORCHESTRATOR_NAME> \ --flavor=vertex \ --location=<GCP_LOCATION> \ --synchronous=true \ --workload_service_account=<WORKLOAD_SERVICE_ACCOUNT_NAME>@<PROJECT_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 Store（zenml.integrations.gcp.artifact_store.GCPArtifactStore），也会校验失败。对应的集成测试见 test_vertex_orchestrator.py。该校验逻辑与文档中“需要远程 Artifact Store 与远程 Container Registry”的要求完全一致。

查看运行：Vertex UI 与 orchestrator_url

Vertex 自带 UI，可用于查看管线运行的更多细节，例如步骤日志：

对于任何在 Vertex 上执行的运行，可以在 Python 中通过以下代码片段获取指向 Vertex UI 的 URL：

from 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>，并附带?project=<project>参数。它同时把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( schedule=Schedule( cron_expression="*/5 * * * *" ) ) first_pipeline() @pipeline def second_pipeline(): ... # 每小时运行一次管线 # 从一天后开始，到三天后结束 second_pipeline = second_pipeline.with_options( schedule=Schedule( cron_expression="0 * * * *", start_time=datetime.now() + timedelta(days=1), end_time=datetime.now() + timedelta(days=3), ) ) second_pipeline()

⚠️ Vertex orchestrator 只支持Schedule对象中的cron_expression、start_time（可选）和end_time（可选）参数，会忽略为定义调度而提供的所有其他参数。

start_time和end_time时间戳参数均为可选，以本地时间指定，它们定义了管线运行被触发的时间窗口。如果未指定，管线将无限期运行。

cron_expression参数支持时区。例如，表达式TZ=Europe/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(f"Processing ZenML schedule: {schedule_name}") try: # 首先删除对应的 Vertex AI 调度 vertex_filter = f'display_name="{schedule_name}"' vertex_schedules = aiplatform.PipelineJobSchedule.list( filter=vertex_filter, order_by='create_time desc', location='europe-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）或指定使用哪种 GPU：

from zenml.integrations.gcp.flavors.vertex_orchestrator_flavor import ( VertexOrchestratorSettings ) vertex_settings = VertexOrchestratorSettings(labels={"key": "value"})

从 vertex_orchestrator_flavor.py 源码可以看到，VertexOrchestratorSettings包含以下字段：

如果您的管线步骤有特定的硬件需求，可以通过ResourceSettings指定：

from zenml.config import ResourceSettings resource_settings = ResourceSettings(cpu_count=8, memory="16GB")

要在 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_count=1) # 在步骤级别指定设置 @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 Operator：

from 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_parameters=VertexCustomJobParameters( boot_disk_size_gb=1000, # 1TB 磁盘 boot_disk_type="pd-standard", # 标准持久磁盘（更便宜） machine_type="n1-standard-8" ) ) # 创建带 GPU 加速的设置 gpu_settings = VertexOrchestratorSettings( custom_job_parameters=VertexCustomJobParameters( accelerator_type="NVIDIA_TESLA_A100", accelerator_count=1, machine_type="n1-standard-8", boot_disk_size_gb=200 # 为 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_parameters=VertexCustomJobParameters( boot_disk_size_gb=500, # 为所有步骤使用 500GB 磁盘 machine_type="n1-standard-4" ) ) } ) def my_pipeline(): ...

VertexCustomJobParameters支持的常用配置选项（默认值与源码 vertex_custom_job_parameters.py 一致）：

高级自定义作业参数

对于高级场景，可以使用additional_training_job_args将附加参数直接透传给底层 Google Cloud Pipeline Components 库：

@step( settings={ "orchestrator": VertexOrchestratorSettings( custom_job_parameters=VertexCustomJobParameters( machine_type="n1-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_gb），additional_training_job_args中的值将覆盖显式值。例如：

VertexCustomJobParameters( machine_type="n1-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_parameters=VertexCustomJobParameters( persistent_resource_id="<PERSISTENT_RESOURCE_ID>", service_account="<SERVICE_ACCOUNT_NAME>", machine_type="n1-standard-4", boot_disk_type="pd-standard" ) ) } ) def my_pipeline(): ... # 为单个步骤配置 @step( settings={ "orchestrator": VertexOrchestratorSettings( custom_job_parameters=VertexCustomJobParameters( persistent_resource_id="<PERSISTENT_RESOURCE_ID>", service_account="<SERVICE_ACCOUNT_NAME>", machine_type="n1-standard-4", boot_disk_type="pd-standard" ) ) } ) def my_step(): ...

如果需要在显式指定不使用任何持久资源，请将persistent_resource_id设置为空字符串：

@step( settings={ "orchestrator": VertexOrchestratorSettings( custom_job_parameters=VertexCustomJobParameters( persistent_resource_id="", # 显式不使用持久资源 boot_disk_size_gb=1000, # 设置大磁盘 machine_type="n1-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的完整字段如下，供注册与更新编排器时参考：

此外，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