尧图网站建设 
LeaderWorkerSet 核心概念精讲Leader 与 Worker 如何组成 AI 推理的超级 Pod【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws在大模型推理全面走向多机多卡的今天如何在 Kubernetes 上把多个 Pod 编排成一个协同工作的整体成为 AI 推理部署中最棘手的问题。LeaderWorkerSet简称 LWS正是为解决这一难题而生的开源项目它提供了一套 Kubernetes 原生 API将一组 Pod 作为一个复制单元统一管理——由 1 个Leader负责协调、多个Worker负责并行计算共同组成一个 AI 推理的超级 Pod。本文将以通俗易懂的方式精讲 LeaderWorkerSet 的核心概念带你彻底理解 Leader 与 Worker 如何分工协作支撑起大模型分布式推理场景。一、什么是 LeaderWorkerSet为什么 AI 推理离不开它如果你部署过 vLLM、TensorRT-LLM 这类大模型推理框架一定遇到过这样的场景一个超大的模型无法塞进单张显卡必须把模型切分shard到多台机器、多块 GPU上让多个进程通过网络协同完成推理。在 Kubernetes 里这些进程天然对应多个独立的 Pod。传统做法是把这些 Pod 当成普通工作负载管理问题随之而来生命周期不同步一个 Pod 重启了其他 Pod 还在运行模型状态瞬间错乱身份不明确每个 Pod 无法确定自己是第几个、如何与其他 Pod 通信调度不协调多个 Pod 被分散调度到不同节点跨节点通信延迟飙升。LeaderWorkerSet 的答案是把一组 Pod抽象成一个整体来管理。它定义了两种角色Leader组内唯一的协调者和Worker组内的计算节点所有 Pod 拥有统一的身份索引、并行创建、统一启停就像一个被放大到多台机器上的超级 Pod。二、核心概念拆解Leader 与 Worker 如何分工Leader组的大脑与协调者每个组中只有一个 Leader Pod它的职责是协调整个组接收外部流量、分发任务、汇总组内各 Worker 的状态与指标。在 AI 推理场景里Leader 通常扮演调度器或API Server角色比如负责接收推理请求并路由给各个 Worker 分片。Leader 在组内的索引恒为0命名格式为LeaderWorkerSet名-组索引例如my-lws-0这也是整个组的名字。Worker并行计算的双手组内的其余 Pod 都是 Worker索引从1到M命名格式为LeaderWorkerSet名-组索引-Worker索引例如my-lws-0-1。在模型并行推理中每个 Worker 持有模型的一个分片各自承担一部分计算。双模板设计一份配置两种角色LWS 最巧妙的设计是Dual Template双模板一份配置里同时定义leaderTemplate和workerTemplateLeader 与 Worker 可以使用不同的镜像、资源配额和启动参数。如果不指定 leaderTemplate则默认复用 worker 模板一份配置搞定整个组。LWS 还会自动向组内所有容器注入三个关键环境变量让应用零配置感知组内身份环境变量含义LWS_LEADER_ADDRESSLeader 的访问地址Worker 可直接用它连接 LeaderLWS_GROUP_SIZE当前组的总 Pod 数量LWS_WORKER_INDEX当前 Pod 在组内的唯一索引这些标签、注解与环境变量的完整定义可以在 leaderworkerset_types.go 中查看。三、复制单元一组 Pod 就是一个超级 Pod在 LWS 中Replicas表示要创建多少个Leader Workers组而Size表示每组内的总 Pod 数。比如replicas: 3、size: 4意味着创建 3 个组每组 1 个 Leader 3 个 Worker共 12 个 Pod。唯一索引与稳定身份每个组拥有从 0 到 N-1 的唯一索引Pod 名称、域名、标签全都基于这个索引生成。这让组内成员可以稳定地互相发现配合 headless ServiceWorker 可以直接通过my-lws-0-1.my-lws这样的域名访问 Leader 或其他成员。并行创建与统一生命周期组内所有 Pod 同时创建、同时就绪、同时销毁生命周期完全绑定。这正是分布式推理最需要的特性——避免组内一半 Pod 在跑、一半 Pod 在重启的尴尬局面。以组为单位的滚动更新LWS 的滚动更新以组为最小单元一次只升级一个组该组内的 Leader 和所有 Worker整体更新、整体就绪后才轮到下一个组。配合maxUnavailable、maxSurge和partition金丝雀发布等参数你可以安全地灰度升级整个推理集群。相关实现见 leaderworkerset_controller.go。四、关键机制精讲调度、重启与扩容全有或全无调度Gang Scheduling组内 Pod 要么全部被调度成功要么一个都不调度。这避免了资源不足时部分 Pod 被调度、其余卡在 Pending造成的死锁——毕竟组内缺了任何一员整个推理任务都无法启动。下图展示了 LWS 的编排时序StatefulSet 控制器创建 Leader Pod 后LWS 的 Pod Controller 自动为其生成对应的 Workers StatefulSet整个过程全自动衔接。重启策略要么一起重启要么都不重启分布式推理最怕组内步调不一致。LWS 提供三种重启策略RecreateGroupOnPodRestart默认组内任意 Pod 重建或容器重启整个组一起重建保证全组同时启动RecreateGroupAfterStart组内所有 Pod 启动完成后才执行全组重建避免部署初期被误触发None仅重启失败的那个 Pod行为与普通 StatefulSet 一致。拓扑感知与亲和调度通过拓扑亲和Topology-aware PlacementLWS 可以尽量把同一个组的 Pod 调度到同一个拓扑域内如同一节点或同一机架把分布式推理所需的跨节点通信降到最低。相关调度逻辑见 pod_controller.go 与 disaggregatedset 下的 affinity.go。借助 HPA 实现自动扩缩容LWS 暴露了标准的 scale 子资源可以直接对接 Kubernetes HPA当 Leader 上报的指标显示负载升高时HPA 自动增加组数负载下降时自动缩减。扩容、缩容都以整组为单位进行绝不会有半个组在运行。完整的 HPA 示例可参考 hpaexample.yaml。五、快速上手最小的 LeaderWorkerSet 配置长什么样理解了概念看一个最精简的配置就会豁然开朗。下面这份清单创建 3 个组每组 4 个 Pod1 个 Leader 3 个 WorkerapiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: name: leaderworkerset-sample spec: replicas: 3 leaderWorkerTemplate: size: 4 restartPolicy: RecreateGroupOnPodRestart workerTemplate: spec: containers: - name: nginx image: nginxinc/nginx-unprivileged:1.27可以看到你只需描述组的规格剩下的组内 Pod 创建、命名、环境变量注入、生命周期管理全部由 LWS 控制器自动完成。更多可直接运行的示例见 docs/examples/sample/lws.yaml 与 leaderworkerset_v1_leaderworkerset.yaml。如果你想亲自体验可以克隆仓库https://gitcode.com/gh_mirrors/lws2/lws并查看其中丰富的示例与测试用例。六、从 LeaderWorkerSet 到 DisaggregatedSet进阶之路如果预填充prefill和解码decode阶段需要拆分到不同基础设施上运行LWS 之上还有更进阶的DisaggregatedSetAPI。它将多个 LeaderWorkerSet 作为底层单元统一编排支持多角色协同滚动更新、自动服务编排与精细的故障处理适合更复杂的分离式推理架构。相关设计与进展可阅读 keps/766-DisaggregatedSet。总结理解超级 Pod就理解了 LWS 的一切回到最初的问题Leader 与 Worker 如何组成 AI 推理的超级 Pod答案可以浓缩为三句话一个组 1 个 Leader M 个 WorkerLeader 负责协调Worker 负责计算组是 LWS 的基本单位创建、调度、更新、扩缩容全部以组为单位原子进行身份、通信、生命周期全部由平台自动管理应用只需专注推理逻辑本身。对于正在 Kubernetes 上部署大模型推理服务的团队来说LeaderWorkerSet 提供了一种既符合直觉又足够稳健的抽象把多机协作的复杂度封装起来让每一个推理实例都像一个普通 Pod 那样简单可控。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LeaderWorkerSet 核心概念精讲：Leader 与 Worker 如何组成 AI 推理的超级 Pod
LeaderWorkerSet 核心概念精讲Leader 与 Worker 如何组成 AI 推理的超级 Pod【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws在大模型推理全面走向多机多卡的今天如何在 Kubernetes 上把多个 Pod 编排成一个协同工作的整体成为 AI 推理部署中最棘手的问题。LeaderWorkerSet简称 LWS正是为解决这一难题而生的开源项目它提供了一套 Kubernetes 原生 API将一组 Pod 作为一个复制单元统一管理——由 1 个Leader负责协调、多个Worker负责并行计算共同组成一个 AI 推理的超级 Pod。本文将以通俗易懂的方式精讲 LeaderWorkerSet 的核心概念带你彻底理解 Leader 与 Worker 如何分工协作支撑起大模型分布式推理场景。一、什么是 LeaderWorkerSet为什么 AI 推理离不开它如果你部署过 vLLM、TensorRT-LLM 这类大模型推理框架一定遇到过这样的场景一个超大的模型无法塞进单张显卡必须把模型切分shard到多台机器、多块 GPU上让多个进程通过网络协同完成推理。在 Kubernetes 里这些进程天然对应多个独立的 Pod。传统做法是把这些 Pod 当成普通工作负载管理问题随之而来生命周期不同步一个 Pod 重启了其他 Pod 还在运行模型状态瞬间错乱身份不明确每个 Pod 无法确定自己是第几个、如何与其他 Pod 通信调度不协调多个 Pod 被分散调度到不同节点跨节点通信延迟飙升。LeaderWorkerSet 的答案是把一组 Pod抽象成一个整体来管理。它定义了两种角色Leader组内唯一的协调者和Worker组内的计算节点所有 Pod 拥有统一的身份索引、并行创建、统一启停就像一个被放大到多台机器上的超级 Pod。二、核心概念拆解Leader 与 Worker 如何分工Leader组的大脑与协调者每个组中只有一个 Leader Pod它的职责是协调整个组接收外部流量、分发任务、汇总组内各 Worker 的状态与指标。在 AI 推理场景里Leader 通常扮演调度器或API Server角色比如负责接收推理请求并路由给各个 Worker 分片。Leader 在组内的索引恒为0命名格式为LeaderWorkerSet名-组索引例如my-lws-0这也是整个组的名字。Worker并行计算的双手组内的其余 Pod 都是 Worker索引从1到M命名格式为LeaderWorkerSet名-组索引-Worker索引例如my-lws-0-1。在模型并行推理中每个 Worker 持有模型的一个分片各自承担一部分计算。双模板设计一份配置两种角色LWS 最巧妙的设计是Dual Template双模板一份配置里同时定义leaderTemplate和workerTemplateLeader 与 Worker 可以使用不同的镜像、资源配额和启动参数。如果不指定 leaderTemplate则默认复用 worker 模板一份配置搞定整个组。LWS 还会自动向组内所有容器注入三个关键环境变量让应用零配置感知组内身份环境变量含义LWS_LEADER_ADDRESSLeader 的访问地址Worker 可直接用它连接 LeaderLWS_GROUP_SIZE当前组的总 Pod 数量LWS_WORKER_INDEX当前 Pod 在组内的唯一索引这些标签、注解与环境变量的完整定义可以在 leaderworkerset_types.go 中查看。三、复制单元一组 Pod 就是一个超级 Pod在 LWS 中Replicas表示要创建多少个Leader Workers组而Size表示每组内的总 Pod 数。比如replicas: 3、size: 4意味着创建 3 个组每组 1 个 Leader 3 个 Worker共 12 个 Pod。唯一索引与稳定身份每个组拥有从 0 到 N-1 的唯一索引Pod 名称、域名、标签全都基于这个索引生成。这让组内成员可以稳定地互相发现配合 headless ServiceWorker 可以直接通过my-lws-0-1.my-lws这样的域名访问 Leader 或其他成员。并行创建与统一生命周期组内所有 Pod 同时创建、同时就绪、同时销毁生命周期完全绑定。这正是分布式推理最需要的特性——避免组内一半 Pod 在跑、一半 Pod 在重启的尴尬局面。以组为单位的滚动更新LWS 的滚动更新以组为最小单元一次只升级一个组该组内的 Leader 和所有 Worker整体更新、整体就绪后才轮到下一个组。配合maxUnavailable、maxSurge和partition金丝雀发布等参数你可以安全地灰度升级整个推理集群。相关实现见 leaderworkerset_controller.go。四、关键机制精讲调度、重启与扩容全有或全无调度Gang Scheduling组内 Pod 要么全部被调度成功要么一个都不调度。这避免了资源不足时部分 Pod 被调度、其余卡在 Pending造成的死锁——毕竟组内缺了任何一员整个推理任务都无法启动。下图展示了 LWS 的编排时序StatefulSet 控制器创建 Leader Pod 后LWS 的 Pod Controller 自动为其生成对应的 Workers StatefulSet整个过程全自动衔接。重启策略要么一起重启要么都不重启分布式推理最怕组内步调不一致。LWS 提供三种重启策略RecreateGroupOnPodRestart默认组内任意 Pod 重建或容器重启整个组一起重建保证全组同时启动RecreateGroupAfterStart组内所有 Pod 启动完成后才执行全组重建避免部署初期被误触发None仅重启失败的那个 Pod行为与普通 StatefulSet 一致。拓扑感知与亲和调度通过拓扑亲和Topology-aware PlacementLWS 可以尽量把同一个组的 Pod 调度到同一个拓扑域内如同一节点或同一机架把分布式推理所需的跨节点通信降到最低。相关调度逻辑见 pod_controller.go 与 disaggregatedset 下的 affinity.go。借助 HPA 实现自动扩缩容LWS 暴露了标准的 scale 子资源可以直接对接 Kubernetes HPA当 Leader 上报的指标显示负载升高时HPA 自动增加组数负载下降时自动缩减。扩容、缩容都以整组为单位进行绝不会有半个组在运行。完整的 HPA 示例可参考 hpaexample.yaml。五、快速上手最小的 LeaderWorkerSet 配置长什么样理解了概念看一个最精简的配置就会豁然开朗。下面这份清单创建 3 个组每组 4 个 Pod1 个 Leader 3 个 WorkerapiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: name: leaderworkerset-sample spec: replicas: 3 leaderWorkerTemplate: size: 4 restartPolicy: RecreateGroupOnPodRestart workerTemplate: spec: containers: - name: nginx image: nginxinc/nginx-unprivileged:1.27可以看到你只需描述组的规格剩下的组内 Pod 创建、命名、环境变量注入、生命周期管理全部由 LWS 控制器自动完成。更多可直接运行的示例见 docs/examples/sample/lws.yaml 与 leaderworkerset_v1_leaderworkerset.yaml。如果你想亲自体验可以克隆仓库https://gitcode.com/gh_mirrors/lws2/lws并查看其中丰富的示例与测试用例。六、从 LeaderWorkerSet 到 DisaggregatedSet进阶之路如果预填充prefill和解码decode阶段需要拆分到不同基础设施上运行LWS 之上还有更进阶的DisaggregatedSetAPI。它将多个 LeaderWorkerSet 作为底层单元统一编排支持多角色协同滚动更新、自动服务编排与精细的故障处理适合更复杂的分离式推理架构。相关设计与进展可阅读 keps/766-DisaggregatedSet。总结理解超级 Pod就理解了 LWS 的一切回到最初的问题Leader 与 Worker 如何组成 AI 推理的超级 Pod答案可以浓缩为三句话一个组 1 个 Leader M 个 WorkerLeader 负责协调Worker 负责计算组是 LWS 的基本单位创建、调度、更新、扩缩容全部以组为单位原子进行身份、通信、生命周期全部由平台自动管理应用只需专注推理逻辑本身。对于正在 Kubernetes 上部署大模型推理服务的团队来说LeaderWorkerSet 提供了一种既符合直觉又足够稳健的抽象把多机协作的复杂度封装起来让每一个推理实例都像一个普通 Pod 那样简单可控。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考