ZenML Deployers 实战指南：将 Pipeline 部署为可实时调用的 HTTP 服务

ZenML Deployers 实战指南：将 Pipeline 部署为可实时调用的 HTTP 服务

【免费下载链接】zenmlZenML 🙏: One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml

本文以 ZenML 的 Deployer 栈组件（Stack Component）为核心，系统讲解如何将 ZenML 流水线部署为长期运行的容器化 HTTP 服务，实现请求-响应（Request-Response）模式的实时执行。你将掌握 Deployer 的适用场景与六种 Flavor 选型、通过 CLI 与 SDK 完成部署/调用/生命周期管理的完整操作流程、可部署 Pipeline 的编写约束，以及本地、Docker、Kubernetes、GCP Cloud Run、AWS App Runner、Hugging Face Spaces 六种部署目标的配置细节与资源/扩缩容设置。文中所有命令与配置均以当前仓库源码为据，可直接复制运行。

什么是 Deployer：从批处理到实时服务

在 ZenML 中，流水线（Pipeline）默认由 Orchestrator 按计划或批量方式执行。而Pipeline Deployment（流水线部署）则是把流水线变成长期运行的 HTTP 服务：它通过 Deployer 这一栈组件，将流水线打包成暴露 REST API 的容器化服务。

部署后的流水线成为一个可以被并发多次调用的 Web 服务：外部请求通过 HTTP 携带参数进入，流水线执行完成后以 JSON 形式返回输出。这为实时推理、交互式工作流、Web 应用集成以及响应外部事件触发执行的 AI Agent 系统提供了基础能力。

从源码看，Deployer 的职责在 base_deployer.py 中定义得非常清晰，它承担三件事：

1. 持有栈相关配置：与远端部署平台交互所需的 hostname、URL、凭证引用、客户端配置等；
2. 实现部署生命周期管理：包括发现、创建、删除、更新（LCM）；
3. 充当部署注册中心：每次流水线部署都会作为数据库实体（Deployment）通过 ZenML Client 持久化，便于追踪和管理所有外部运行中的部署实例。

也就是说，Deployer 不仅仅是"把流水线跑起来"，它还负责把每个部署的状态、URL、连接信息记录到 ZenML 数据库中，这正是后面zenml deployment list/describe等管理命令的数据来源。

什么时候应该使用 Deployer？

Deployer 是 ZenML Stack 中的可选组件，它与 Orchestrator 是互补关系：

具体而言，Deployer 适用于以下场景：

• 实时流水线执行：通过 HTTP 请求按需执行流水线，而非定时批处理；
• 交互式工作流：构建需要立即获得流水线响应的应用；
• API 集成：将 ML 工作流以 REST API 形式暴露给 Web 应用或微服务；
• 实时推理：通过流水化推理工作流对外提供模型服务；
• Agent 系统：创建响应外部事件、执行流水线的 AI Agent。

部署后的服务形态

从 utils.py 的invoke_deployment实现可以看到服务的调用语义：默认情况下，调用会阻塞等待流水线运行结束并返回输出；也可以通过submit=True（CLI 对应--no-wait）提交后台执行并立即返回 run ID。调用前会校验部署状态必须为RUNNING且具有可访问的 URL，否则抛出DeploymentProvisionError——这解释了为什么部署完成后需要等待服务就绪。

Deployer Flavors 总览

ZenML 开箱即用自带localDeployer（已包含在默认 Stack 中），其余 Flavor 由集成（Integration）提供：

查看当前环境所有可用的 Deployer Flavor：

zenml deployer flavor list

各类 Deployer 的关键差异

• Local Deployer：无需任何云基础设施，零配置即可使用，适合入门、快速实验与调试（详见 local.md）；
• Docker Deployer：只要本机装有 Docker 即可，ZenML 会构建名为zenml:<PIPELINE_NAME>的本地镜像并以容器方式运行（详见 docker.md）；
• Kubernetes Deployer：适合已有集群（EKS/GKE/AKS 或自建）的团队，提供资源、网络、安全精细控制，支持自动扩缩容、健康探针与高可用（详见 kubernetes.md）；
• GCP Cloud Run / AWS App Runner：Serverless 方案，按用量付费、自动扩缩容，适合已有对应云厂商依赖的团队（详见 gcp-cloud-run.md 与 aws-app-runner.md）；
• Hugging Face Deployer：将流水线发布为 Hugging Face Space，便于向社区分享或托管私有 AI 应用（详见 huggingface.md）。

快速上手：从默认 Stack 到首个部署

你无需在代码中直接与 Deployer 组件交互。只要目标 Deployer 位于当前激活的 ZenML Stack中，就可以通过 ZenML CLI 或 SDK 部署流水线或快照（Snapshot），并通过 CLI/SDK 管理生成的部署。

方式一：使用默认 Stack（Local Deployer）

默认 Stack 自带 Local Deployer，会以本地后台进程的方式部署流水线：

zenml stack set default

方式二：注册新 Deployer 并创建 Stack

zenml deployer register docker --flavor=local zenml stack register docker_deployment -a default -o default -D docker --set

注：示例中以--flavor=local注册名为docker的组件，实际使用时请按需命名与选择 Flavor。

用 SDK 部署流水线

from zenml import pipeline @step def my_step(name: str) -> str: return f"Hello, {name}!" @pipeline def my_pipeline(name: str = "John") -> str: return my_step(name=name) if __name__ == "__main__": # 将流水线 my_pipeline 部署为名为 my_deployment 的部署 deployment = my_pipeline.deploy(deployment_name="my_deployment") print(f"Deployment URL: {deployment.url}")

用 CLI 部署同一流水线

zenml pipeline deploy --name my_deployment my_module.my_pipeline

调用已部署的流水线

通过 CLI 调用：

zenml deployment invoke my_deployment --name="Alice"

或使用 curl 直接请求 HTTP 端点：

curl -X POST http://localhost:8000/invoke \ -H "Content-Type: application/json" \ -d '{"parameters": {"name": "Alice"}}'

基于快照（Snapshot）的部署

除了直接部署流水线，还可以先创建流水线快照再部署，实现版本化的可复现部署：

zenml pipeline snapshot create --name my_snapshot my_module.my_pipeline zenml pipeline snapshot deploy my_snapshot --deployment my_deployment

从 base_deployer.py 的provision_deployment主流程可以看到，无论哪种方式，底层都遵循同一套流程：校验快照的输入输出 Schema → 在数据库中创建或更新Deployment实体（记录snapshot_id、deployer_id、auth_key）→ 调用具体 Flavor 的do_provision_deployment创建外部基础设施 → 通过_poll_deployment轮询直到状态达到RUNNING（期间还会调用健康检查端点验证服务可用性）。

可部署 Pipeline 的编写要求

并非所有流水线都适合部署为 HTTP 服务。编写可部署流水线需遵循以下约束：

参数要求：

• 流水线应接受带默认值的显式参数；
• 参数类型必须是 JSON 可序列化类型（int、float、str、bool、list、dict、Pydantic 模型）；
• 参数名应与 Step 输入名保持一致。

输出要求：

• 流水线应返回有意义的返回值作为 HTTP 响应；
• 返回值必须 JSON 可序列化；
• 建议使用类型注解指定输出产物名称。

一个标准的可部署流水线示例：

from typing import Annotated from zenml import pipeline, step @step def process_weather(city: str, temperature: float) -> Annotated[str, "weather_analysis"]: return f"The weather in {city} is {temperature} degrees Celsius." @pipeline def weather_pipeline(city: str = "Paris", temperature: float = 20.0) -> str: """A deployable pipeline that processes weather data.""" analysis = process_weather(city=city, temperature=temperature) return analysis

为什么这些约束如此重要

源码层面给出了硬性校验：在 base_deployer.py 的_check_deployment_inputs_outputs中，部署前会强制检查快照的pipeline_spec是否已编译出input_schema与output_schema；若缺失（通常因为输入或输出不是 JSON 可序列化类型），会直接抛出DeploymentProvisionError。这正是"参数必须有默认值、类型必须 JSON 可序列化"约束的底层原因——ZenML 需要根据这些 Schema 动态生成 HTTP 请求的输入校验与输出包装（详见deployment describe --show-schema展示的 Input/Output Schema）。

部署生命周期管理

Deployment对象代表一个已部署到服务环境的流水线，它保存在 ZenML 数据库中，包含部署配置、状态与连接信息。部署是独立实体：即使之后切换了活动 Stack，仍可通过当初创建它的 Deployer 栈组件独立管理这些部署。

列出部署

CLI：

$ zenml deployment list ┏━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ NAME │ PIPELINE │ URL │ STATUS ┃ ┠──────────────────────┼──────────────────────────────────────┼────────────────────────────────┼──────────────────────────┨ ┃ weather_service │ weather_pipeline │ http://localhost:8001 │ ⚙ RUNNING ┃ ┠──────────────────────┼──────────────────────────────────────┼────────────────────────────────┼──────────────────────────┨ ┃ ml_inference_api │ inference_pipeline │ http://k8s-cluster/ml-api │ ⚙ RUNNING ┃ ┗━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

SDK：

from zenml.client import Client client = Client() deployments = client.list_deployments() for deployment in deployments: print(f"{deployment.name}: {deployment.status}")

查看部署详情

CLI（--show-schema可同时展示请求的输入/输出 JSON Schema）：

$ zenml deployment describe my_deployment --show-schema 🚀 Deployment: my_deployment is: RUNNING ⚙ Pipeline: my_pipeline Snapshot: my_snapshot Stack: docker-deployer 📡 Connection Information: Endpoint URL: http://localhost:8002 Swagger URL: http://localhost:8002/docs CLI Command Example: zenml deployment invoke my_deployment --name="John" cURL Example: curl -X POST http://localhost:8002/invoke \ -H "Content-Type: application/json" \ -d '{ "parameters": { "name": "John" } }' 📋 Deployment JSON Schemas: Input Schema: { "additionalProperties": false, "properties": { "name": { "default": "John", "title": "Name", "type": "string" } }, "title": "PipelineInput", "type": "object" } Output Schema: { "properties": { "output": { "title": "Output", "type": "string" } }, "required": [ "output" ], "title": "PipelineOutput", "type": "object" } ⚙️ Management Commands ╭────────────────────────────────────────────┬─────────────────────────────────────────────────────╮ │ zenml deployment logs my_deployment -f │ Follow deployment logs in real-time │ │ zenml deployment describe my_deployment │ Show detailed deployment information │ │ zenml deployment deprovision my_deployment │ Deprovision this deployment and keep a record of it │ │ zenml deployment delete my_deployment │ Deprovision and delete this deployment │ ╰────────────────────────────────────────────┴─────────────────────────────────────────────────────╯

SDK：

from zenml.client import Client deployment = client.get_deployment("my_deployment") print(deployment)

删除与撤销部署

"撤销部署（Deprovision）"会销毁外部运行实例但保留数据库记录；"删除（Delete）"则同时删除两者。CLI：

$ zenml deployment delete my_deployment

SDK：

from zenml.client import Client client = Client() client.delete_deployment("my_deployment")

底层实现在 base_deployer.py：deprovision_deployment调用do_deprovision_deployment销毁外部资源后轮询直到状态变为ABSENT，delete_deployment支持force=True在撤销失败时强制清除数据库记录。

调用部署并获取响应

CLI：

$ zenml deployment invoke my_deployment --name="John" Invoked deployment 'my_deployment' with response: { "success": true, "outputs": { "output": "Hello, John!" }, "execution_time": 3.2781872749328613, "metadata": { "deployment_id": "95d60dcf-7c37-4e62-a923-a341601903e5", "deployment_name": "my_deployment", "snapshot_id": "f3122ed4-aa13-4113-9f60-a80545f56244", "snapshot_name": "my_snapshot", "pipeline_name": "my_pipeline", "run_id": "ea448522-d5bf-411e-971e-d4550fdbe713", "run_name": "my_pipeline-2025_09_30-12_52_01_012491", "parameters_used": {} }, "error": null }

SDK：

from zenml.deployers.utils import invoke_deployment response = invoke_deployment( deployment_name_or_id="my_deployment", name="John", ) print(response)

阻塞等待 vs 后台提交

默认情况下，invoke会阻塞直到流水线运行结束并返回输出。若希望提交后台执行并立即拿到 run ID，使用--no-wait（CLI）或submit=True（SDK）：

$ zenml deployment invoke my_deployment --name="John" --no-wait

response = invoke_deployment( deployment_name_or_id="my_deployment", name="John", submit=True, )

对应源码见 utils.py：invoke_deployment的submit参数控制同步/异步语义，timeout默认 300 秒（5 分钟），**kwargs会被序列化进 HTTP 请求参数。

为部署指定资源与扩缩容

如果 Step 需要额外硬件资源，可在 Step 上通过ResourceSettings声明。所有 Deployer 共用的基础设置（定义于 base_deployer.py 的BaseDeployerSettings）：

• auth_key：调用部署 API 时使用的自定义认证密钥；
• generate_auth_key：是否生成并使用随机认证密钥（而非用户自定义）；
• lcm_timeout：等待部署生命周期管理（LCM）完成的最大秒数，默认 600 秒。

在流水线级指定资源的方式如下（以 Cloud Run 为例）：

from zenml import step, pipeline from zenml.config import ResourceSettings resource_settings = ResourceSettings( cpu_count=2, memory="32GB", min_replicas=0, max_replicas=10, max_concurrency=50 ) @pipeline(settings={"resources": resource_settings}) def greet_pipeline(name: str = "John"): greet(name=name)

资源默认值与平台约束

不同云平台的资源规格有各自限制，ZenML 会在部署时自动对齐合法取值：

GCP Cloud Run（未显式设置时的默认值）：cpu_count=1、memory=2GiB、min_replicas=1、max_replicas=100、max_concurrency=80。Cloud Run 的 CPU/内存组合有硬性规则（如 0.08 到 1.0 之间的分数 CPU 按 0.01 递增，整数 CPU 仅支持 1/2/4/6/8；<=1 CPU最低 128 MiB、4 CPU最低 2 GiB 等）。配置不合法不会报错，而是被自动调整到最近的合法组合，例如cpu_count=0.25+memory="100MiB"会被调整为0.25CPU +128MiB。

AWS App Runner（截至文档记录支持的组合）：0.25 vCPU 支持 0.5/1 GB，0.5 vCPU 支持 1 GB，1 vCPU 支持 2/3/4 GB，2 vCPU 支持 4/6 GB，4 vCPU 支持 8/10/12 GB。默认情况下非法组合会被自动调整为"优先满足 CPU、最小化浪费"的最近组合；可通过strict_resource_matching=True强制精确匹配（不匹配即报错），也可通过resource_combinations配置自定义允许组合。

按需配置各 Flavor 的设置

每个 Deployer Flavor 都提供专属设置类，可在注册组件时或定义/部署流水线时通过settings={"deployer": ...}传入。以下为各 Flavor 的关键设置要点。

Local Deployer 专属设置

定义于zenml.deployers.local.local_deployer模块（详见 local.md）：

• port：部署服务监听的端口，默认不设置；
• allocate_port_if_busy：若配置的端口被占用或未设置，自动分配空闲端口，默认True；
• port_range：搜索空闲端口的范围，默认(8000, 65535)；
• address：部署服务监听地址，默认127.0.0.1；
• blocking：是否在当前进程运行而非守护进程，默认False，调试 ASGI 应用本身时使用；
• auto_reload：是否启用 uvicorn 自动重载，便于本地开发时热更新，默认False（注意：对流水线/Step/Stack 配置变更无效）。

示例——指定部署端口：

from zenml import step, pipeline from zenml.deployers.local.local_deployer import LocalDeployerSettings @step def greet(name: str) -> str: return f"Hello {name}!" settings = { "deployer": LocalDeployerSettings( port=8000 ) } @pipeline(settings=settings) def greet_pipeline(name: str = "John"): greet(name=name)

Docker Deployer 专属设置

定义于zenml.deployers.docker.docker_deployer模块（详见 docker.md）：

• port：暴露部署服务的端口；
• allocate_port_if_busy/port_range：端口占用时的自动分配策略；
• run_args：透传给docker run的参数，可参考 docker-py 的 Containers API 文档。

Kubernetes Deployer 设置与进阶用法

Kubernetes Deployer 采用渐进式复杂度模型（详见 kubernetes.md），完整设置参考KubernetesDeployerSettings：

基础设置（Level 1，覆盖约 80% 场景）：namespace、service_type（LoadBalancer/NodePort/ClusterIP，默认LoadBalancer）、service_port（默认 8000）、image_pull_policy（默认IfNotPresent）、labels、annotations。

生产级设置（Level 2）：健康探针（readiness_probe_path默认/api/health、readiness_probe_initial_delay默认 10s、readiness_probe_period默认 10s、readiness_probe_timeout默认 5s、readiness_probe_failure_threshold默认 3；liveness 探针同理但initial_delay默认 30s）、容器配置（command、args、service_account_name、image_pull_secrets）。

附加资源（Level 3）：通过additional_resources指向 YAML 文件，可随主 Deployment/Service 一起下发 Ingress、HorizontalPodAutoscaler、PodDisruptionBudget、NetworkPolicy 等资源；strict_additional_resources（默认True）控制任一资源失败时是否整体失败。YAML 中可使用模板变量：{{name}}、{{namespace}}、{{labels}}（含managed-by: zenml、zenml-deployment-id、zenml-deployment-name）、{{replicas}}、{{image}}、{{command}}、{{args}}、{{env}}、{{resources}}、{{pod_settings}}等。

自定义模板（Level 4）：通过custom_deployment_template_file/custom_service_template_file指定自定义 Jinja2 模板，可完全覆盖内置的 Deployment/Service 资源定义（例如注入 initContainer、sidecar 等）。注意自行维护模板时需保证标签选择器（zenml-deployment-id、managed-by: zenml）、容器端口（{{settings.service_port}}）、健康探针与环境变量透传的正确性。

Kubernetes 集群访问支持三种方式：本地kubectl上下文（--kubernetes_context）、Service Connector（生产推荐）、集群内认证（--incluster=True，适用于 ZenML Server 与部署目标同集群的场景）。

GCP Cloud Run 专属设置

定义于zenml.integrations.gcp.flavors.gcp_deployer_flavor模块（详见 gcp-cloud-run.md），要点包括：

• location（默认europe-west3）：部署目标 GCP 区域；
• service_name_prefix（默认zenml-）：Cloud Run 服务名前缀，避免命名冲突；
• timeout_seconds（默认 300）：请求超时，范围 1–3600 秒；
• ingress（默认all）：可选all、internal、internal-and-cloud-load-balancing；
• vpc_connector：私有网络的 VPC 连接器（格式projects/PROJECT_ID/locations/LOCATION/connectors/CONNECTOR_NAME）；
• service_account：运行服务用的 SA 邮箱，默认使用 Compute Engine 默认 SA；
• environment_variables/labels/annotations：环境变量、标签与注解；
• execution_environment（默认gen2）：可选gen1/gen2；
• traffic_allocation（默认{"LATEST": 100}）：修订版本流量分配；
• allow_unauthenticated（默认True）：是否允许未认证请求；
• use_secret_manager（默认True）：敏感环境变量是否存入 GCP Secret Manager，secret_name_prefix（默认zenml-）控制密钥名前缀。

AWS App Runner 专属设置

定义于zenml.integrations.aws.flavors.aws_deployer_flavor模块（详见 aws-app-runner.md），要点包括：

• region：部署区域（未指定则取自认证会话）；
• service_name_prefix（默认zenml-）、port（默认 8080，容器监听端口）；
• 健康检查系列：health_check_grace_period_seconds（默认 20）、health_check_interval_seconds（默认 10）、health_check_path（默认/health）、health_check_protocol（默认TCP）、health_check_timeout_seconds（默认 2）、health_check_healthy_threshold（默认 1）、health_check_unhealthy_threshold（默认 5）；
• is_publicly_accessible（默认True）、ingress_vpc_configuration（私有服务的 VPC 配置）；
• use_secrets_manager（默认True）：敏感信息存入 AWS Secrets Manager，需配置 App Runner instance role；secret_name_prefix（默认zenml-）；
• instance_role_arn（实例角色，use_secrets_manager=True时必需）、access_role_arn（ECR 拉取角色，私有 ECR 必需）；
• strict_resource_matching（默认False）：CPU/内存组合严格匹配开关；
• observability_configuration_arn、encryption_kms_key、tags、environment_variables。

Hugging Face Deployer 专属设置

定义于zenml.integrations.huggingface.flavors.huggingface_deployer_flavor模块（详见 huggingface.md）：

• space_hardware：Space 硬件档位（如cpu-basic、cpu-upgrade、t4-small、t4-medium、a10g-small、a10g-large），未指定则用免费 CPU 档；
• space_storage：持久存储档位（small/medium/large），未指定则无持久存储；
• private（默认True）：是否创建私有 Space；
• app_port（默认 8000）：部署服务监听端口，Hugging Face 会将流量路由到该端口。

Hugging Face 部署特别强调凭据安全：环境变量通过HfApi.add_space_variable()、密钥通过HfApi.add_space_secret()设置，永不写入 Dockerfile，因此即使是公开 Space 也不会泄露凭据。同时该 Flavor 要求 Stack 中包含公开可访问的容器镜像仓库（如 Docker Hub 公开仓库、GHCR 公开镜像），因为 HF Spaces 构建时需要拉取镜像。

环境与前提条件速查

注意：Kubernetes、GCP Cloud Run、AWS App Runner、Hugging Face 四种远端 Deployer 均要求配合远端 ZenML 安装使用，仅用本地 ZenML 环境部署可能导致意外行为。

排错与最佳实践

针对 Kubernetes 部署，kubernetes.md 给出了系统性的排错指南，其中通用方法同样适用于其他 Flavor：

• 部署卡在 Pending：用zenml deployment describe my-deployment查看状态、zenml deployment logs my-deployment -f跟进日志，再用kubectl get pods/kubectl describe pod检查底层资源；常见原因包括集群资源不足、镜像拉取失败（检查image_pull_secrets）、节点选择器/亲和性约束不满足、PVC 未就绪；
• LoadBalancer 拿不到外部 IP：确认集群是否支持 LoadBalancer（云厂商通常支持、本地集群通常不支持）；本地集群改用NodePort，无 LoadBalancer 支持的生产环境用ClusterIP+ Ingress；
• 附加资源下发失败：用kubectl apply --dry-run=client -f k8s-resources.yaml先行校验，检查 CRD、metrics-server、ingress controller 等集群组件是否安装；
• 镜像拉取失败：docker pull <image>验证镜像存在，核对image_pull_secrets与 SA 的仓库访问权限，检查镜像拉取策略。

通用最佳实践：

1. 生产环境优先使用 Service Connector，凭证可移植、可管理；
2. 生产部署务必配置健康探针；
3. 用 Ingress + ClusterIP 替代 LoadBalancer，兼顾成本与灵活性；
4. 使用 labels/annotations 辅助组织、监控与成本追踪；
5. 配置资源限额防止资源耗尽，用 HPA 按真实负载自动扩缩容；
6. 配置 PodDisruptionBudget 保证集群更新期间的高可用；
7. 将附加 K8s 资源文件与流水线代码一同纳入版本控制。

关键源码路径一览

想深入了解 Deployer 的底层实现，可重点关注以下仓库文件：

• BaseDeployer 与 BaseDeployerSettings：Deployer 抽象基类、生命周期管理主流程、轮询与健康检查、认证密钥生成；
• ContainerizedDeployer 基类：容器化部署器的镜像获取与 Docker 构建配置（DEPLOYER_DOCKER_IMAGE_KEY）；
• invoke_deployment 实现：HTTP 调用部署、输入 Schema 解析（基于jsonref解析引用）、同步/异步调用语义；
• Local Deployer 实现：本地后台进程/守护进程部署与LocalDeployerSettings；
• Docker Deployer 实现：Docker 容器部署与DockerDeployerSettings；
• 部署 CLI 命令：zenml deployment list/describe/invoke/logs/deprovision/delete的入口实现；
• 流水线部署 CLI 命令：zenml pipeline deploy的入口实现；
• 各云端 Flavor 的部署器与设置类位于 src/zenml/integrations/ 下的kubernetes、gcp、aws、huggingface集成目录中。

至此，你已掌握从选择 Deployer Flavor、编写可部署流水线、执行部署与调用，到生命周期管理、资源调优与排错的全链路能力，可以在本地或云端把 ZenML 流水线快速变成可对外服务的实时 API。

【免费下载链接】zenmlZenML 🙏: One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml