ZenML Local Orchestrator 完全指南零基础设施本地运行与调试机器学习流水线【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlZenML 的 Local Orchestrator本地编排器是随 ZenML 内置的编排器 flavor负责在你自己的机器上以进程内方式直接执行流水线无需任何云基础设施与额外配置。阅读本文后你将掌握本地编排器的适用场景、通过zenml orchestrator register与zenml stack register注册激活的完整操作步骤、其底层执行流程与三种失败执行模式并能结合源码理解它的能力边界与调试技巧。什么是 Local Orchestrator在 ZenML 中**编排器orchestrator**是栈Stack中的一个核心组件负责决定流水线pipeline中的各个步骤step在哪里、以何种方式执行。Local Orchestrator 是名为local的编排器 flavor它随 ZenML 一起内置发布直接在本机运行流水线。从源码结构看localflavor 由三部分构成全部定义在 本地编排器实现 中LocalOrchestrator继承自BaseOrchestrator的执行类负责流水线提交与步骤执行LocalOrchestratorConfig继承自BaseOrchestratorConfig的配置类LocalOrchestratorFlavorflavor 定义其name属性返回localtype为StackComponentType.ORCHESTRATOR。其核心定位在源码类文档字符串中写得很清楚Orchestrator responsible for running pipelines locally并且明确说明它不允许步骤并发执行也不支持定时调度运行。这两个约束是理解本地编排器适用边界的关键。在 单元测试 中flavor 的基础属性得到了验证flavor.type StackComponentType.ORCHESTRATOR且flavor.name local确保local能被 ZenML 正确识别为编排器类型组件。什么时候应该使用它Local Orchestrator 是你初次接触 ZenML 时默认栈default stack的组成部分。由于它完全运行在你的机器上因此无需任何额外搭建不需要配置云账号、不需要安装 Kubernetes 集群、不需要申请 GPU 实例易于使用和调试步骤与你的 Python 进程共享同一个环境报错栈、日志输出和断点调试都像运行普通脚本一样直观。官方文档给出的推荐使用场景有两个你刚开始使用 ZenML希望在不搭建任何云基础设施的前提下先把流水线跑起来你在编写一个新的流水线希望快速实验和调试而不是把时间花在等待远程资源调度上。相反如果你的流水线需要并发执行步骤、按计划schedule定时运行或者需要海量算力支撑的训练任务那么本地编排器并不合适应当考虑 local_docker 或其他远程编排器 flavor。如何部署它Local Orchestrator随 ZenML 一起发布开箱即用不需要任何额外部署步骤。安装 ZenML 之后它便立即可用这也是它成为新手默认选择的原因。如何注册并使用它尽管它是默认栈的一部分你也可以显式地注册它并在自己的栈中激活使用。完整操作如下# 注册一个 flavor 为 local 的编排器组件 zenml orchestrator register ORCHESTRATOR_NAME --flavorlocal # 注册一个包含该编排器的栈并立即激活它 zenml stack register STACK_NAME -o ORCHESTRATOR_NAME ... --set其中ORCHESTRATOR_NAME是你要给这个编排器组件起的名字例如local_orchSTACK_NAME是栈的名字-o ORCHESTRATOR_NAME指定栈使用的编排器...表示你还需要按需补充栈中的其他组件如 artifact store、orchestrator 之外的可选组件--set表示注册完成后立刻把该栈设为当前激活栈。注册并激活后你就可以用本地编排器运行任何 ZenML 流水线了——只需像执行普通 Python 脚本一样运行包含流水线构建与执行的代码python file_that_runs_a_zenml_pipeline.py源码级原理本地编排器如何执行流水线要真正用好一个编排器理解它的执行模型至关重要。下面我们沿着 本地编排器实现 中的submit_pipeline方法梳理一次流水线在本地的完整执行链路。执行流程总览生成运行 IDsubmit_pipeline首先通过str(uuid4())为本次运行生成唯一的_orchestrator_run_id流水线内所有步骤共享同一个 ID供步骤执行上下文与元数据关联使用。执行 init hook调用run_init_hook初始化流水线级运行上下文。顺序执行每个步骤进入setup_execution_context()然后按顺序遍历snapshot.step_configurations中的每个步骤逐个调用self.run_step(stepstep)。这正是不允许并发执行的源码体现——步骤在一个进程内串行执行。执行 cleanup hook全部步骤结束后调用run_cleanup_hook收尾。汇总结果记录整个运行耗时并以人类可读格式get_human_readable_time打印Pipeline run has finished in ...。失败处理与执行模式submit_pipeline内部维护failed_steps、skipped_steps两个列表来跟踪执行状态。每当某个步骤抛出异常它会被记入failed_steps并打印错误日志。此时具体行为取决于流水线配置的执行模式execution mode由 执行模式枚举 定义。本地编排器通过supported_execution_modes属性声明其支持的全部三种模式执行模式枚举值行为说明FAIL_FASTfail_fast某个步骤失败后立即终止后续步骤并抛出该步骤的异常STOP_ON_FAILUREstop_on_failure一旦有步骤失败跳过所有尚未执行的后续步骤不继续执行CONTINUE_ON_FAILUREcontinue_on_failure某个步骤失败后仍继续执行其他步骤最后统一报告失败此外代码还会针对上游步骤失败或跳过的下游步骤给出明确警告Skipping step ... due to failure in upstream step(s)保证依赖关系不被破坏。当所有步骤执行完毕且存在失败步骤时最终会抛出RuntimeError(Pipeline run has failed due to failure in step(s): ...)。同步执行与本地组件属性LocalOrchestratorConfig覆盖了基类 编排器基类配置 中的两个关键属性is_local返回True声明该组件运行在本地环境is_synchronous返回True声明该编排器同步执行——python file_that_runs_a_zenml_pipeline.py会一直阻塞等待流水线完整结束这在快速实验场景中非常友好。与之对比基类BaseOrchestratorConfig的默认is_synchronous为False异步提交is_schedulable为False不可调度而supports_client_side_caching默认为Truehandles_step_retries默认为False。Hook 的运行时机基类中run_init_cleanup_at_step_level默认返回True即 init/cleanup hook 需要在每个步骤级别执行适用于步骤运行在相互隔离环境中的编排器而本地编排器将其覆盖为False。源码注释解释了原因由于本地编排器的步骤共享同一个进程环境和共享内存init 与 cleanup hook 可以在运行run级别只执行一次而不是在每个步骤中重复执行。这是本地编排器在语义上区别于容器化编排器的一个重要细节。动态流水线与隔离步骤除常规流水线外本地编排器还实现了submit_dynamic_pipeline通过DynamicPipelineRunner支持动态流水线dynamic pipeline的执行同样以同步方式运行并在结束时打印耗时信息。能力边界与注意事项基于源码实现使用本地编排器时有几个事实层面的边界需要了解不支持步骤级资源请求submit_pipeline会检查requires_resources_in_orchestration_environment(step)若步骤配置了资源需求会打印警告 Specifying step resources is not supported for the local orchestrator, ignoring resource configuration即资源配置会被忽略。如需 GPU、内存等资源约束应使用支持资源调度的编排器或 step operator。不支持并发步骤严格串行执行。不支持调度is_schedulable为False流水线只能手动触发。运行环境依赖由于步骤直接在你的 Python 进程中执行所有步骤的依赖包、环境变量都在本机解释器环境中解析因此保持本地环境的可复现性例如使用虚拟环境或容器镜像管理依赖对稳定运行尤为重要。调试与验证建议本地编排器最大的优势就是调试体验接近原生 Python 开发步骤抛出的异常会携带完整的 Python traceback 直接展示在终端配合日志即可快速定位由于是同步执行你可以在步骤函数内直接打断点进行单步调试参考 本地编排器单元测试 的写法验证 flavor 的注册属性是否符合预期若你希望步骤在本地 Docker 容器中隔离执行以贴近生产环境可以改用local_dockerflavor见 local_docker 编排器它同样运行在本地但会为每个步骤构建并运行容器。总结Local Orchestrator 是 ZenML 中最轻量、最易上手的编排器零部署成本、同步执行、进程内串行运行步骤非常适合新手入门、流水线原型开发与快速调试。理解其不支持并发、不支持调度、忽略步骤资源请求、hook 运行级执行等源码级行为边界能帮助你在正确的场景选择正确的编排器避免在规模化需求上误用本地方案。需要进一步了解 flavor 的全部可配置属性时可直接查阅 本地编排器源码 与 编排器基类。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/18 3:59:42 · 阅读 1.2k ZenML Local Orchestrator 完全指南：零基础设施本地运行与调试机器学习流水线
ZenML Local Orchestrator 完全指南零基础设施本地运行与调试机器学习流水线【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlZenML 的 Local Orchestrator本地编排器是随 ZenML 内置的编排器 flavor负责在你自己的机器上以进程内方式直接执行流水线无需任何云基础设施与额外配置。阅读本文后你将掌握本地编排器的适用场景、通过zenml orchestrator register与zenml stack register注册激活的完整操作步骤、其底层执行流程与三种失败执行模式并能结合源码理解它的能力边界与调试技巧。什么是 Local Orchestrator在 ZenML 中**编排器orchestrator**是栈Stack中的一个核心组件负责决定流水线pipeline中的各个步骤step在哪里、以何种方式执行。Local Orchestrator 是名为local的编排器 flavor它随 ZenML 一起内置发布直接在本机运行流水线。从源码结构看localflavor 由三部分构成全部定义在 本地编排器实现 中LocalOrchestrator继承自BaseOrchestrator的执行类负责流水线提交与步骤执行LocalOrchestratorConfig继承自BaseOrchestratorConfig的配置类LocalOrchestratorFlavorflavor 定义其name属性返回localtype为StackComponentType.ORCHESTRATOR。其核心定位在源码类文档字符串中写得很清楚Orchestrator responsible for running pipelines locally并且明确说明它不允许步骤并发执行也不支持定时调度运行。这两个约束是理解本地编排器适用边界的关键。在 单元测试 中flavor 的基础属性得到了验证flavor.type StackComponentType.ORCHESTRATOR且flavor.name local确保local能被 ZenML 正确识别为编排器类型组件。什么时候应该使用它Local Orchestrator 是你初次接触 ZenML 时默认栈default stack的组成部分。由于它完全运行在你的机器上因此无需任何额外搭建不需要配置云账号、不需要安装 Kubernetes 集群、不需要申请 GPU 实例易于使用和调试步骤与你的 Python 进程共享同一个环境报错栈、日志输出和断点调试都像运行普通脚本一样直观。官方文档给出的推荐使用场景有两个你刚开始使用 ZenML希望在不搭建任何云基础设施的前提下先把流水线跑起来你在编写一个新的流水线希望快速实验和调试而不是把时间花在等待远程资源调度上。相反如果你的流水线需要并发执行步骤、按计划schedule定时运行或者需要海量算力支撑的训练任务那么本地编排器并不合适应当考虑 local_docker 或其他远程编排器 flavor。如何部署它Local Orchestrator随 ZenML 一起发布开箱即用不需要任何额外部署步骤。安装 ZenML 之后它便立即可用这也是它成为新手默认选择的原因。如何注册并使用它尽管它是默认栈的一部分你也可以显式地注册它并在自己的栈中激活使用。完整操作如下# 注册一个 flavor 为 local 的编排器组件 zenml orchestrator register ORCHESTRATOR_NAME --flavorlocal # 注册一个包含该编排器的栈并立即激活它 zenml stack register STACK_NAME -o ORCHESTRATOR_NAME ... --set其中ORCHESTRATOR_NAME是你要给这个编排器组件起的名字例如local_orchSTACK_NAME是栈的名字-o ORCHESTRATOR_NAME指定栈使用的编排器...表示你还需要按需补充栈中的其他组件如 artifact store、orchestrator 之外的可选组件--set表示注册完成后立刻把该栈设为当前激活栈。注册并激活后你就可以用本地编排器运行任何 ZenML 流水线了——只需像执行普通 Python 脚本一样运行包含流水线构建与执行的代码python file_that_runs_a_zenml_pipeline.py源码级原理本地编排器如何执行流水线要真正用好一个编排器理解它的执行模型至关重要。下面我们沿着 本地编排器实现 中的submit_pipeline方法梳理一次流水线在本地的完整执行链路。执行流程总览生成运行 IDsubmit_pipeline首先通过str(uuid4())为本次运行生成唯一的_orchestrator_run_id流水线内所有步骤共享同一个 ID供步骤执行上下文与元数据关联使用。执行 init hook调用run_init_hook初始化流水线级运行上下文。顺序执行每个步骤进入setup_execution_context()然后按顺序遍历snapshot.step_configurations中的每个步骤逐个调用self.run_step(stepstep)。这正是不允许并发执行的源码体现——步骤在一个进程内串行执行。执行 cleanup hook全部步骤结束后调用run_cleanup_hook收尾。汇总结果记录整个运行耗时并以人类可读格式get_human_readable_time打印Pipeline run has finished in ...。失败处理与执行模式submit_pipeline内部维护failed_steps、skipped_steps两个列表来跟踪执行状态。每当某个步骤抛出异常它会被记入failed_steps并打印错误日志。此时具体行为取决于流水线配置的执行模式execution mode由 执行模式枚举 定义。本地编排器通过supported_execution_modes属性声明其支持的全部三种模式执行模式枚举值行为说明FAIL_FASTfail_fast某个步骤失败后立即终止后续步骤并抛出该步骤的异常STOP_ON_FAILUREstop_on_failure一旦有步骤失败跳过所有尚未执行的后续步骤不继续执行CONTINUE_ON_FAILUREcontinue_on_failure某个步骤失败后仍继续执行其他步骤最后统一报告失败此外代码还会针对上游步骤失败或跳过的下游步骤给出明确警告Skipping step ... due to failure in upstream step(s)保证依赖关系不被破坏。当所有步骤执行完毕且存在失败步骤时最终会抛出RuntimeError(Pipeline run has failed due to failure in step(s): ...)。同步执行与本地组件属性LocalOrchestratorConfig覆盖了基类 编排器基类配置 中的两个关键属性is_local返回True声明该组件运行在本地环境is_synchronous返回True声明该编排器同步执行——python file_that_runs_a_zenml_pipeline.py会一直阻塞等待流水线完整结束这在快速实验场景中非常友好。与之对比基类BaseOrchestratorConfig的默认is_synchronous为False异步提交is_schedulable为False不可调度而supports_client_side_caching默认为Truehandles_step_retries默认为False。Hook 的运行时机基类中run_init_cleanup_at_step_level默认返回True即 init/cleanup hook 需要在每个步骤级别执行适用于步骤运行在相互隔离环境中的编排器而本地编排器将其覆盖为False。源码注释解释了原因由于本地编排器的步骤共享同一个进程环境和共享内存init 与 cleanup hook 可以在运行run级别只执行一次而不是在每个步骤中重复执行。这是本地编排器在语义上区别于容器化编排器的一个重要细节。动态流水线与隔离步骤除常规流水线外本地编排器还实现了submit_dynamic_pipeline通过DynamicPipelineRunner支持动态流水线dynamic pipeline的执行同样以同步方式运行并在结束时打印耗时信息。能力边界与注意事项基于源码实现使用本地编排器时有几个事实层面的边界需要了解不支持步骤级资源请求submit_pipeline会检查requires_resources_in_orchestration_environment(step)若步骤配置了资源需求会打印警告 Specifying step resources is not supported for the local orchestrator, ignoring resource configuration即资源配置会被忽略。如需 GPU、内存等资源约束应使用支持资源调度的编排器或 step operator。不支持并发步骤严格串行执行。不支持调度is_schedulable为False流水线只能手动触发。运行环境依赖由于步骤直接在你的 Python 进程中执行所有步骤的依赖包、环境变量都在本机解释器环境中解析因此保持本地环境的可复现性例如使用虚拟环境或容器镜像管理依赖对稳定运行尤为重要。调试与验证建议本地编排器最大的优势就是调试体验接近原生 Python 开发步骤抛出的异常会携带完整的 Python traceback 直接展示在终端配合日志即可快速定位由于是同步执行你可以在步骤函数内直接打断点进行单步调试参考 本地编排器单元测试 的写法验证 flavor 的注册属性是否符合预期若你希望步骤在本地 Docker 容器中隔离执行以贴近生产环境可以改用local_dockerflavor见 local_docker 编排器它同样运行在本地但会为每个步骤构建并运行容器。总结Local Orchestrator 是 ZenML 中最轻量、最易上手的编排器零部署成本、同步执行、进程内串行运行步骤非常适合新手入门、流水线原型开发与快速调试。理解其不支持并发、不支持调度、忽略步骤资源请求、hook 运行级执行等源码级行为边界能帮助你在正确的场景选择正确的编排器避免在规模化需求上误用本地方案。需要进一步了解 flavor 的全部可配置属性时可直接查阅 本地编排器源码 与 编排器基类。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考