DisaggregatedSet 自动扩缩容RoleScaler 如何为分离式推理按需动态扩容【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lwsLeaderWorkerSetLWS项目推出的 DisaggregatedSet 自动扩缩容能力通过新增的 DisaggregatedSetRoleScaler简称 RoleScaler资源让 Kubernetes 上的分离式推理Disaggregated Inference服务能够按角色prefill、decode、encode独立动态扩容。本文将用通俗易懂的方式带你理解 RoleScaler 的工作原理、配置步骤与最佳实践让你快速掌握这套为 LLM 推理量身打造的自动扩缩容方案。为什么分离式推理需要按角色动态扩容在 vLLM、SGLang 等主流 LLM 推理框架中一次请求会被拆分成多个阶段分别由不同的角色role处理prefill预填充处理输入 Prompt生成 KV Cache属于计算密集型瓶颈通常在算力decode解码逐 token 生成输出属于内存带宽密集型瓶颈通常在显存带宽encode编码可选的上下文编码阶段资源需求与前面两者又不一样这三个角色的资源瓶颈完全不同流量高峰也往往只集中在某一个阶段。如果整组服务一起扩容要么浪费昂贵的 GPU 资源要么响应不过来。这正是 DisaggregatedSet 自动扩缩容要解决的核心问题让 prefill 和 decode 各自独立地按需伸缩互不干扰。传统扩缩容方式的两个痛点在 RoleScaler 出现之前给 DisaggregatedSet 做自动扩缩容非常痛苦子资源名字不稳定DisaggregatedSet 管理的是多个 LeaderWorkerSetLWS而每个 LWS 的名字里都带有 revision 哈希例如my-ds-0-6ad7c921-prefill。每次滚动更新哈希都会变化指向旧名字的 HPA 就变成了孤儿必须手动重建。无法表达只扩 prefillDisaggregatedSet 聚合了多个角色单一的/scale子资源无法表达把 prefill 从 5 扩到 8但 decode 保持不动这种诉求。RoleScaler 的出现恰好同时解决了这两个问题。RoleScaler 是什么一个角色一个稳定的扩缩容目标DisaggregatedSetRoleScaler是一个轻量级 CRDCustom Resource Definition为 DisaggregatedSet 的每一个角色暴露标准的/scale子资源。它的核心设计是自动创建只要你在角色的配置里声明scaling.mode: ExternalDisaggregatedSet 控制器就会自动创建对应的 RoleScaler无需手工编写命名确定RoleScaler 的名字固定为DisaggregatedSet名称-角色名例如my-llm-prefill并且与 revision 哈希无关无论滚动更新多少次这个目标始终稳定生命周期托管RoleScaler 由 DisaggregatedSet 持有owner referenceDisaggregatedSet 删除时它会自动被回收角色改回静态模式后控制器也会顺手把它清理掉这段逻辑的核心实现可以参考 scaler_manager.go 与 CRD 定义 disaggregatedsetrolescaler_types.go。动态扩容的完整链路从 HPA 写入到 Pod 扩容RoleScaler 自动扩缩容的完整工作流程如下自动扩缩容器写入 /scale → RoleScaler.spec.replicas 更新 → 触发 DisaggregatedSet 控制器 → 驱动对应角色的 LeaderWorkerSet → Pod 扩容拆开来看每一环都经过精心设计写入端HPA、KEDA 或任何支持/scale的控制器通过标准接口把期望副本数写入 RoleScaler 的spec.replicas读取端DisaggregatedSet 控制器每次调谐reconcile时读取该值并驱动底层对应角色的 LeaderWorkerSet回写端控制器把当前实际副本数写回status.replicas并维护一个只匹配 leader Pod 的status.selectorworker-index0保证 HPA 在做每 Pod 指标平均时除数与被除数口径一致——这对leaderWorkerTemplate.size 1每个组有多个 worker的场景至关重要快速上手给分离式推理接入 HPA 自动扩缩容的步骤配置过程非常简单只需要两步第一步在 DisaggregatedSet 中把角色标记为 ExternalapiVersion: disaggregatedset.x-k8s.io/v1 kind: DisaggregatedSet metadata: name: my-llm-serving spec: roles: - name: prefill scaling: mode: External # 交给外部自动扩缩容器管理 spec: leaderWorkerTemplate: size: 2 # ... 容器配置 - name: decode spec: replicas: 4 # decode 保持静态 leaderWorkerTemplate: size: 1 # ... 容器配置第二步创建一个指向 RoleScaler 的 HPAapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-llm-prefill spec: scaleTargetRef: apiVersion: disaggregatedset.x-k8s.io/v1 kind: DisaggregatedSetRoleScaler name: my-llm-serving-prefill # 固定命名DS名-角色名 minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50应用到集群后控制器会自动创建my-llm-serving-prefill这个 RoleScalerHPA 即刻开始工作。你随时可以用kubectl get dsrsRoleScaler 的短名查看期望副本数与当前副本数。 一个贴心细节控制器在创建 RoleScaler 时会做好种子值处理——全新角色默认种子为 1避免 HPA 读到 0 而进入 ScalingDisabled 死锁从静态模式切换过来的角色则继承当前副本数避免线上服务瞬间被排空。支持从零扩容的 KEDA 或开启 HPAScaleToZero 的 HPA 仍可在此基础上继续缩到 0。滚动更新与自动扩缩容如何和平共处生产环境中扩容和发版往往同时发生。RoleScaler 在这方面做了两个关键设计selector 跨 revision 聚合滚动更新期间新旧两个 revision 的 LWS 会短暂共存。RoleScaler 的status.selector不区分 revisionHPA 看到的是整个在服务集群指标计算不会因版本切换而抖动滚动更新期间禁止缩容回退规划器planner保证新 revision 的目标副本数不会低于当前在途值。如果 HPA 在滚动更新中途发来缩容指令新版本只会停止增长、不会收缩等滚动更新完成后再完全跟随 HPA 的指令这套交互设计的完整推导见设计文档 keps/849-DisaggregatedSet-HPA/README.md有完整的故事场景与风险分析。使用 RoleScaler 的注意事项与最佳实践为了让自动扩缩容稳定运行有几点需要特别留意当前仅支持单 slicescaling.mode: External目前要求spec.slices保持默认值 1多 slice 场景正在设计中一个角色一个 HPAprefill、decode 各自绑定独立的 HPA/KEDA避免互相干扰不要手写 RoleScaler它会由控制器自动管理如果你手工创建同名对象且不属于当前 DisaggregatedSet控制器会拒绝接管并发出警告事件资源指标需要 metrics-server像上面的 CPU 指标示例需要集群中已安装 metrics-server想退出外部扩容把角色的scaling.mode改回Static或移除scaling字段即可控制器会自动删除对应的 RoleScaler总结DisaggregatedSet 自动扩缩容通过 RoleScaler 这个轻量设计把按角色独立扩容变成了 Kubernetes 生态的标准操作你只需要声明scaling.mode: External并创建一个 HPA剩下的都由控制器自动完成。对于运行分离式 LLM 推理的团队来说这意味着 GPU 资源可以真正按需伸缩让 prefill 和 decode 各自应对自己的流量高峰既不浪费算力也不拖累体验。如果想深入了解配置细节可以参考仓库中的 config/samples/disaggregatedset_v1_3role.yaml 示例文件直接 clone 项目后即可在本地环境复现这套自动扩缩容能力。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/8/20 16:55:17 · 阅读 1.2k DisaggregatedSet 自动扩缩容：RoleScaler 如何为分离式推理按需动态扩容
DisaggregatedSet 自动扩缩容RoleScaler 如何为分离式推理按需动态扩容【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lwsLeaderWorkerSetLWS项目推出的 DisaggregatedSet 自动扩缩容能力通过新增的 DisaggregatedSetRoleScaler简称 RoleScaler资源让 Kubernetes 上的分离式推理Disaggregated Inference服务能够按角色prefill、decode、encode独立动态扩容。本文将用通俗易懂的方式带你理解 RoleScaler 的工作原理、配置步骤与最佳实践让你快速掌握这套为 LLM 推理量身打造的自动扩缩容方案。为什么分离式推理需要按角色动态扩容在 vLLM、SGLang 等主流 LLM 推理框架中一次请求会被拆分成多个阶段分别由不同的角色role处理prefill预填充处理输入 Prompt生成 KV Cache属于计算密集型瓶颈通常在算力decode解码逐 token 生成输出属于内存带宽密集型瓶颈通常在显存带宽encode编码可选的上下文编码阶段资源需求与前面两者又不一样这三个角色的资源瓶颈完全不同流量高峰也往往只集中在某一个阶段。如果整组服务一起扩容要么浪费昂贵的 GPU 资源要么响应不过来。这正是 DisaggregatedSet 自动扩缩容要解决的核心问题让 prefill 和 decode 各自独立地按需伸缩互不干扰。传统扩缩容方式的两个痛点在 RoleScaler 出现之前给 DisaggregatedSet 做自动扩缩容非常痛苦子资源名字不稳定DisaggregatedSet 管理的是多个 LeaderWorkerSetLWS而每个 LWS 的名字里都带有 revision 哈希例如my-ds-0-6ad7c921-prefill。每次滚动更新哈希都会变化指向旧名字的 HPA 就变成了孤儿必须手动重建。无法表达只扩 prefillDisaggregatedSet 聚合了多个角色单一的/scale子资源无法表达把 prefill 从 5 扩到 8但 decode 保持不动这种诉求。RoleScaler 的出现恰好同时解决了这两个问题。RoleScaler 是什么一个角色一个稳定的扩缩容目标DisaggregatedSetRoleScaler是一个轻量级 CRDCustom Resource Definition为 DisaggregatedSet 的每一个角色暴露标准的/scale子资源。它的核心设计是自动创建只要你在角色的配置里声明scaling.mode: ExternalDisaggregatedSet 控制器就会自动创建对应的 RoleScaler无需手工编写命名确定RoleScaler 的名字固定为DisaggregatedSet名称-角色名例如my-llm-prefill并且与 revision 哈希无关无论滚动更新多少次这个目标始终稳定生命周期托管RoleScaler 由 DisaggregatedSet 持有owner referenceDisaggregatedSet 删除时它会自动被回收角色改回静态模式后控制器也会顺手把它清理掉这段逻辑的核心实现可以参考 scaler_manager.go 与 CRD 定义 disaggregatedsetrolescaler_types.go。动态扩容的完整链路从 HPA 写入到 Pod 扩容RoleScaler 自动扩缩容的完整工作流程如下自动扩缩容器写入 /scale → RoleScaler.spec.replicas 更新 → 触发 DisaggregatedSet 控制器 → 驱动对应角色的 LeaderWorkerSet → Pod 扩容拆开来看每一环都经过精心设计写入端HPA、KEDA 或任何支持/scale的控制器通过标准接口把期望副本数写入 RoleScaler 的spec.replicas读取端DisaggregatedSet 控制器每次调谐reconcile时读取该值并驱动底层对应角色的 LeaderWorkerSet回写端控制器把当前实际副本数写回status.replicas并维护一个只匹配 leader Pod 的status.selectorworker-index0保证 HPA 在做每 Pod 指标平均时除数与被除数口径一致——这对leaderWorkerTemplate.size 1每个组有多个 worker的场景至关重要快速上手给分离式推理接入 HPA 自动扩缩容的步骤配置过程非常简单只需要两步第一步在 DisaggregatedSet 中把角色标记为 ExternalapiVersion: disaggregatedset.x-k8s.io/v1 kind: DisaggregatedSet metadata: name: my-llm-serving spec: roles: - name: prefill scaling: mode: External # 交给外部自动扩缩容器管理 spec: leaderWorkerTemplate: size: 2 # ... 容器配置 - name: decode spec: replicas: 4 # decode 保持静态 leaderWorkerTemplate: size: 1 # ... 容器配置第二步创建一个指向 RoleScaler 的 HPAapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-llm-prefill spec: scaleTargetRef: apiVersion: disaggregatedset.x-k8s.io/v1 kind: DisaggregatedSetRoleScaler name: my-llm-serving-prefill # 固定命名DS名-角色名 minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50应用到集群后控制器会自动创建my-llm-serving-prefill这个 RoleScalerHPA 即刻开始工作。你随时可以用kubectl get dsrsRoleScaler 的短名查看期望副本数与当前副本数。 一个贴心细节控制器在创建 RoleScaler 时会做好种子值处理——全新角色默认种子为 1避免 HPA 读到 0 而进入 ScalingDisabled 死锁从静态模式切换过来的角色则继承当前副本数避免线上服务瞬间被排空。支持从零扩容的 KEDA 或开启 HPAScaleToZero 的 HPA 仍可在此基础上继续缩到 0。滚动更新与自动扩缩容如何和平共处生产环境中扩容和发版往往同时发生。RoleScaler 在这方面做了两个关键设计selector 跨 revision 聚合滚动更新期间新旧两个 revision 的 LWS 会短暂共存。RoleScaler 的status.selector不区分 revisionHPA 看到的是整个在服务集群指标计算不会因版本切换而抖动滚动更新期间禁止缩容回退规划器planner保证新 revision 的目标副本数不会低于当前在途值。如果 HPA 在滚动更新中途发来缩容指令新版本只会停止增长、不会收缩等滚动更新完成后再完全跟随 HPA 的指令这套交互设计的完整推导见设计文档 keps/849-DisaggregatedSet-HPA/README.md有完整的故事场景与风险分析。使用 RoleScaler 的注意事项与最佳实践为了让自动扩缩容稳定运行有几点需要特别留意当前仅支持单 slicescaling.mode: External目前要求spec.slices保持默认值 1多 slice 场景正在设计中一个角色一个 HPAprefill、decode 各自绑定独立的 HPA/KEDA避免互相干扰不要手写 RoleScaler它会由控制器自动管理如果你手工创建同名对象且不属于当前 DisaggregatedSet控制器会拒绝接管并发出警告事件资源指标需要 metrics-server像上面的 CPU 指标示例需要集群中已安装 metrics-server想退出外部扩容把角色的scaling.mode改回Static或移除scaling字段即可控制器会自动删除对应的 RoleScaler总结DisaggregatedSet 自动扩缩容通过 RoleScaler 这个轻量设计把按角色独立扩容变成了 Kubernetes 生态的标准操作你只需要声明scaling.mode: External并创建一个 HPA剩下的都由控制器自动完成。对于运行分离式 LLM 推理的团队来说这意味着 GPU 资源可以真正按需伸缩让 prefill 和 decode 各自应对自己的流量高峰既不浪费算力也不拖累体验。如果想深入了解配置细节可以参考仓库中的 config/samples/disaggregatedset_v1_3role.yaml 示例文件直接 clone 项目后即可在本地环境复现这套自动扩缩容能力。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考