北京时间 2026 年 10 月 14 日，Volcano v1.16.0 正式发布。v1.16.0新增 NamespaceQueue 和 fairshare 插件。NamespaceQueue 支持租户在自己的命名空间内使用 Volcano 的层级队列能力，在管理员授权的资源范围内配置队列配额、组织队列层级。fairshare 则将同一队列内各命名空间的历史资源用量纳入调度排序，改善多团队共享资源时的公平性。本次版本还进一步拓展了 HyperNode 生态。使用其他调度器的平台，可以单独部署 HyperNode 控制器，复用拓扑发现逻辑、维护超节点及其层级关系，再通过 HyperNode API 将拓扑信息接入自己的调度流程。对于使用 Volcano 的推理服务，新增的 PodGroup 拓扑反亲和规则则可以将多个实例分散到不同超节点，降低实例集中在同一故障域的风险。调度性能方面，新增的 Unschedulable Job Cache 缓存作业的调度失败原因，在阻塞条件未变化时跳过重复检查。节点打分、缓存更新与队列查询也有优化，进一步提升调度效率。此外，v1.16.0 还包含 Kubernetes 1.36 适配、批量 Pod 调度时的负载估算、DRA 打分，以及异构资源和稳定性方面的改进。   版本亮点  提升调度性能与可扩展性：新增 Unschedulable Job Cache 减少积压场景下的重复检查，同时优化节点打分、缓存更新与队列查询。新增 NamespaceQueue 支持租户在命名空间内管理队列层级：租户可在自己的命名空间内使用层级队列，在管理员授权的资源范围内管理配额和资源分配。新增 fairshare 改善租户间的长期公平性：面向多个租户按命名空间隔离并共享同一队列的场景，引入类似 Slurm 的历史用量衰减机制。通过 PodGroup 拓扑反亲和分散部署业务实例：可以要求多个实例必须分散到不同拓扑域，也可以设置优先分散的调度偏好。拓展 HyperNode 生态以支持更多调度系统：其他调度器可复用社区已有的拓扑发现和超节点管理逻辑，无需同时运行 Volcano 的其他组件。  重点特性  ▍1. 提升调度性能与可扩展性v1.16.0 新增 Unschedulable Job Cache，改善大量作业等待资源时的调度性能，同时优化节点打分、缓存更新与队列查询。Unschedulable Job Cache :队列配额不足、缺少满足要求的 GPU 节点、节点标签不匹配等因素，都可能导致作业持续等待。在阻塞条件未变化的情况下，逐轮执行相同检查会产生额外调度开销。随着等待作业积压，这些重复检查还会延迟满足调度条件的作业获得资源。UnschedulableJobCache 记录作业未通过的调度检查，并根据插件声明的事件判断重试时机。阻塞条件未变化时，调度器跳过相应的重复检查，收到相关事件后再按正常流程重新评估作业。该机制减少了无效重试，提升了积压场景下可调度作业的调度效率。主要能力：按原因跳过检查：根据记录的调度失败原因，跳过入队检查、整个作业或部分任务的重复评估，同时遵守 Gang 约束。条件变化后重试：例如，节点标签变化后重新检查节点亲和性，资源释放后重试资源不足的作业，队列配置变化后重新检查配额。存储和 DRA 插件也可以通过事件 hint 唤醒相关作业。未覆盖的情况继续逐轮检查：仅当所有拒绝该作业的插件均提供能够安全判断重试时机的事件 hint 时，才缓存该作业。其余情况仍按原有流程逐轮评估，确保重试机会不受影响。不改变 Gang 和队列资源计算：缓存中的作业仍参与资源需求计算，队列资源与 Gang 条件保持原有检查方式。作业唤醒后仍需通过完整调度检查。保留兜底重试：未收到相关事件时，watchdog 会在等待超过设定时长后触发重试，默认五分钟。缓存仅保存在内存中，调度器重启后重新建立。该特性默认关闭，可通过调度器 feature gate 开启：helm upgrade --install volcano volcano-sh/volcano \  --namespace volcano-system --create-namespace --version 1.16.0 \  --set custom.scheduler_feature_gates="UnschedulableJobCache=true"目前已接入 predicates 封装的上游插件 hint，以及 Resource Fit、proportion 和非层级 capacity。因层级 capacity 检查未通过而等待的作业，以及其他缺少 hint 的插件所阻塞的作业，仍会在每轮调度中检查。排查运行情况时，可开启按 Job 记录的调试指标，查看跳过检查、事件唤醒和 watchdog 重试的次数。相关资料：PR：cid:link_16、cid:link_17设计与性能验证：Unschedulable Job Cache (cid:link_7)使用指南：启用 Unschedulable Job Cache (cid:link_1)感谢贡献者：@JesseStutler此外，节点打分支持多个插件在同一次节点遍历中完成评分，降低多插件场景下的打分开销。节点更新与队列查询也减少了不必要的对象拷贝和遍历。(PR: cid:link_18、cid:link_19、cid:link_20)性能与可扩展性将持续优化。后续将结合基准测试和生产反馈，持续优化调度流程、缓存与事件处理、状态更新等环节。▍2. 新增 NamespaceQueue 支持租户在命名空间内管理队列层级不同平台采用不同的租户模型。有的平台通过集群级 Queue 为租户划分资源池，也有的平台以 namespace 作为团队或项目的管理边界，希望租户在各自命名空间内配置队列配额和层级关系。NamespaceQueue 面向后一种场景，让队列管理与租户的资源管理范围保持一致。NamespaceQueue 将 Volcano 的层级队列能力扩展到命名空间。管理员通过集群 Queue 的 spec.allowedNamespaces 授权资源访问范围后，租户可在自己的命名空间内创建队列、建立父子队列层级，并配置 capability、deserved、guarantee、reclaimable 等资源属性。管理员负责资源池授权，租户在授权范围内管理内部配额与队列层级。队列名称在命名空间内隔离，不同命名空间可使用相同名称。该特性默认关闭。使用下面的 Helm 参数后，控制器、调度器和 admission webhook 会同时启用 NamespaceQueue。使用 chart 默认调度配置时，还会自动切换到层级 capacity：helm upgrade --install volcano volcano-sh/volcano \  --namespace volcano-system --create-namespace --version 1.16.0 \  --set custom.namespace_queue_enable=true先创建命名空间和允许接入的集群 Queue，再创建租户队列：apiVersion: v1kind: Namespacemetadata:  name: team-a---apiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: researchspec:  capability:    cpu: "100"    memory: "200Gi"  deserved:    cpu: "100"    memory: "200Gi"  allowedNamespaces:  -team-a---apiVersion: scheduling.volcano.sh/v1beta1kind: NamespaceQueuemetadata:  name: training  namespace: team-aspec:  parent: cluster/research  capability:    cpu: "40"    memory: "80Gi"  deserved:    cpu: "40"    memory: "80Gi"  reclaimable: true管理员还需通过 RBAC 授予租户在本命名空间内操作 namespacequeues 的权限。确认 NamespaceQueue 的 Ready=True、Authorized=True 后，team-a 中的 Job 或 PodGroup 即可使用下面的引用：spec:  queue: namespace/training提交作业时，不带前缀的队列名仍指向原有的集群 Queue。设置 NamespaceQueue 的父队列时，cluster/<name> 指向集群 Queue，普通名称则指向同命名空间内的 NamespaceQueue。使用 NamespaceQueue 需要启用层级 capacity，不应同时启用 proportion。相关资料：PR：cid:link_21、cid:link_22)使用指南：NamespaceQueue 用户指南(https://volcano.sh/zh-Hans/docs/UserGuide/user_guide_how_to_use_namespace_queue)设计文档：命名空间级队列(cid:link_11)感谢贡献者：@gitGurugu▍3. 新增 fairshare 改善租户间的长期公平性Volcano 原有的资源共享与配额治理主要围绕集群级 Queue 展开，适合为租户分配独立队列的模型。另一类平台以 namespace 作为团队或项目的隔离边界，多个租户向同一个 Queue 提交作业，需要在队列内部获得公平的调度机会。两种模型对应不同的资源管理需求。在共享队列中，仅依据当前资源分配量排序，难以反映各租户一段时间内的累计消耗。例如，一个团队持续提交 GPU 作业，已有作业完成后又继续占用释放的资源，后续加入的团队可能长期等待。新增的 fairshare 插件借鉴 Slurm 的 fair-share 思路，以 namespace 标识租户，记录同一队列内各命名空间的累计资源用量（资源数量与使用时长的乘积），优先调度历史用量较少的命名空间。历史用量按指数衰减，默认半衰期为四小时，较早用量对调度排序的影响逐步降低。fairshare 可与 DRF 配合使用，将历史资源用量作为当前资源分配之外的补充排序依据。插件通过调整等待作业的顺序改善公平性，也可按需限制新作业入队，不会抢占运行中的作业。用户可配置生效队列、统计资源类型，以及是否通过 ConfigMap 持久化历史用量。调度配置示例：actions: "enqueue, allocate, backfill"tiers:- plugins:  - name: priority  - name: gang  - name: conformance  - name: fairshare    arguments:      fairshare.targetQueues: "gpu-queue"      fairshare.resourceKey: "nvidia.com/gpu"      fairshare.halfLifeMinutes: "240"      fairshare.enableEnqueueGate: "false"      fairshare.persistState: "false"- plugins:  - name: drf  - name: capacity  - name: predicates  - name: nodeorder配置时应将 fairshare 排在 drf 之前，否则作业顺序可能由 DRF 优先决定。如需保持 PriorityClass 的排序优先级，应将 priority 排在前面。历史用量持久化与入队限制默认关闭。相关资料：特性 PR：cid:link_23设计文档：Fair Share Scheduling (cid:link_13 )使用指南：fairshare 插件 (cid:link_4)特性贡献者：@dmildh-absci▍4. 通过 PodGroup 拓扑反亲和分散部署业务实例推理服务运行多个实例时，同一实例的 Pod 通常需要在拓扑上集中部署，以减少通信开销，不同实例则需要分散到不同故障域，降低单个超节点故障的影响。原有 networkTopology 可以限制一个 PodGroup 内部的调度范围，但多个 PodGroup 仍可能集中在同一个超节点。新增的 group-topology-affinity 插件可以约束不同 PodGroup 之间的调度位置。用户可通过标签选择器匹配需要分散部署的 PodGroup，并指定机架、超节点等 HyperNode 层级。required 规则强制将匹配的 PodGroup 部署到不同拓扑域，preferred 规则则优先选择不同拓扑域。结合 networkTopology，可同时满足实例内部集中部署与实例之间分散部署的需求。选择范围既可以限于当前命名空间，也可以通过 namespace selector 扩展到其他命名空间。在现有调度插件列表中加入以下配置，并保留原有 action 和其他插件：- name: group-topology-affinity  arguments:    weight:10- name: network-topology-aware  arguments:    weight: 10假设 HyperNode 拓扑中已有 supernode 层级，可以为需要分散部署的每个 PodGroup 配置相同规则，并分别设置名称：apiVersion: scheduling.volcano.sh/v1beta1kind: PodGroupmetadata:  name: inference-a  namespace: default  labels:    app:model-aspec:  minMember: 2  queue: default  networkTopology:    mode: hard    highestTierName:supernode  topologyAffinity:    podGroupAntiAffinity:      required:      - podGroupSelector:          matchLabels:            app: model-a        topologyTierName: supernode成员 Pod 需要使用 schedulerName: volcano，并通过 scheduling.k8s.io/group-name 注解关联对应 PodGroup。选择器匹配的是 PodGroup 标签。每条规则必须在 topologyTierName 和 topologyTier 中选择一个，偏好规则还需设置 1 到 100 的权重。当前规则只在 allocate 阶段生效，backfill 调度的 BestEffort Pod 不受这些规则约束。目前还不支持 SubGroup 之间的亲和与反亲和、跨 PodGroup 亲和，以及运行中 Pod 的自动迁移。相关资料：PR：cid:link_24设计文档：PodGroup 拓扑亲和性设计 (cid:link_8)使用指南：PodGroup 反亲和性 (cid:link_3)感谢贡献者：@wangyang0616▍5. 拓展 HyperNode 生态以支持更多调度系统使用其他调度器的平台，也需要发现集群拓扑、维护超节点及其层级关系。此前，这些平台若需复用 HyperNode，仍需运行 Volcano 的 controller manager。v1.16.0 新增 HyperNode 控制器独立部署方式，为其他调度系统集成拓扑发现与超节点管理能力提供支持，进一步拓展 HyperNode 生态。平台可单独部署 HyperNode 控制器，复用社区已有的 UFM、节点标签等拓扑发现方式，由控制器自动创建和更新 HyperNode 资源，维护超节点及其层级关系。其他调度器通过 HyperNode API 获取拓扑信息，并结合业务需求实现拓扑感知调度，无需同时运行 Volcano 调度器和其他控制器。独立控制器与原有集成模式共用拓扑发现和 HyperNode 管理逻辑，后续社区增加的发现方式也可以在两种模式中复用。不同调度系统可共享拓扑发现与超节点管理能力，各平台的相关改进也可贡献到同一套实现中。本次提供了独立的 vc-hypernode-controller-manager 二进制、镜像和 Helm Deployment。chart 可选择 controller-manager、standalone 或 disabled 模式，默认仍由原有 controller manager 管理 HyperNode。只部署 HyperNode 控制器时，可以使用：helm upgrade --install volcano volcano-sh/volcano \  --namespace volcano-system --create-namespace --version 1.16.0 \  --set custom.hypernode_controller_mode=standalone \  --set custom.controller_enable=false \  --set custom.scheduler_enable=false \  --set custom.admission_enable=false拓扑发现仍通过 custom.controller_config_override 配置。如果要保留其他 Volcano 组件，只需调整 HyperNode 模式。从现有部署切换时，先设置为 disabled，等待 controller manager 完成滚动更新，再启用 standalone，确保同一时间只有一个进程管理 HyperNode。相关资料：PR：cid:link_25、cid:link_26设计文档：HyperNode 控制器独立部署 (cid:link_5)使用指南：部署独立 HyperNode 控制器 (cid:link_0)拓扑发现配置：HyperNode Auto Discovery (cid:link_2)感谢贡献者：@wangyang0616  其他值得关注的增强  ▍批量 Pod 调度时的负载估算监控指标存在采集与更新延迟。批量调度 Pod 时，新分配的任务可能尚未反映在监控数据中，调度器可能因此低估节点负载，继续向这些节点分配任务。usage 插件新增 session 级的 shadow load cache，预估尚未反映在监控数据中的 Pod 的 CPU 和内存用量。节点打分时，调度器综合考虑预估用量与实际监控值，减少指标延迟导致的负载误判。缓存保留每个 Pod 的预估值，回滚时扣除对应原值，避免重新计算引入资源用量偏差。可在现有调度配置中补充以下插件参数，同时保留监控数据源配置：- name: usage  enablePredicate: false  arguments:    usage.weight: 5    cpu.weight: 1    memory.weight: 1    estimator:      request_ratio: 0.7      burst_ratio: 0      risk_threshold: 0.6      risk_factor: 1.2      be_cpu: 250m      be_mem: 200Mi用户可以通过 request_ratio、burst_ratio 和 risk_factor 等参数调整估算方式，也可以设置 BestEffort Pod 的固定预估用量。插件根据 metrics.interval 识别可能尚未反映在监控数据中的 Pod，该值默认为 30 秒。相关资料：PR #5314 (cid:link_27 )、Usage-Based Scheduling (cid:link_9)。感谢贡献者 @3th4novo。▍按 NodeGroup 设置队列资源限额通过 NodeGroup 插件新增的队列注解，用户可分别设置队列在各 NodeGroup 中的资源使用上限。例如，先使用固定资源池，达到队列在该池中的限额后，再将新增任务调度到其他允许使用的资源池。metadata:  annotations:    volcano.sh/nodegroup-resource-limits: |      {"fixed": {"cpu": "100", "memory": "200Gi"}, "overflow": {"cpu": "50"}}只限制注解中列出的资源项，未配置的资源不受额外限制。子队列不会继承父队列的这项配置，需要限制用量的队列应各自设置注解。相关资料：PR #5461 (cid:link_28)、NodeGroup 使用指南 (cid:link_6)。感谢贡献者 @ruanwenjun。▍基于 Pod 级分配信息提高 NUMA 资源判断准确性原有节点级 NUMA 汇总信息难以准确区分资源释放和新任务分配。如果节点上的 Pod 释放 CPU 时，另一批 Pod 已完成调度但尚未由 kubelet 分配资源，汇总数据的变化可能导致调度器误判可用 CPU，进而错误拒绝实际满足 NUMA 策略的任务。Numatopology 新增 spec.podAllocations，记录 Pod UID、名称、命名空间及各容器的资源分配，CPU 使用 cpuset 表示。调度器结合 Pod 级实际分配与尚待分配的任务，更新节点 NUMA 资源视图，减少资源信息失真导致的 NUMA 策略误判。细粒度信息也便于定位容器的 CPU 分配与资源占用。使用该能力需配套支持新字段的 resource-exporter。( PR :cid:link_29、cid:link_30)▍DRA 与异构资源调度DRA 打分：调度使用 DRA 优先级设备请求的 Pod 时，接入上游 DynamicResources 的打分及归一化逻辑。( PR :cid:link_31)HAMi Ascend 软切分：接入 hami-vnpu-core，支持设备内存虚拟化与算力时间片共享，需要配套的设备插件和运行时。完整配置请参考 vNPU 使用指南 ( cid:link_10)。( PR : cid:link_32、cid:link_33)Ascend 健康检查：根据 allocatable 设备信息判断 vNPU 健康状态。( PR :cid:link_34)vGPU 选择与一致性修复：新增按 GPU UUID 设置允许和排除列表的注解，并修复绑定与回滚过程中的设备分配元数据一致性问题。( PR : cid:link_35、cid:link_36)▍HyperNode 发现与拓扑调度一致性拓扑更新与发现：修正 HyperNode 更新时的拓扑重建行为，避免 informer 缓存延迟导致重复创建 HyperNode，并在 UFM endpoint 配置缺失或类型错误时返回错误而非触发 panic。( PR :cid:link_37、cid:link_38、cid:link_39)抢占与回收后的拓扑选择：保留并优先处理跨调度周期的 SubJob HyperNode nomination，未启用 hard 拓扑约束的作业也会遵循该结果，使 Gang 抢占或回收释放的资源能够按预期用于后续放置。( PR :cid:link_40、cid:link_41)▍Grove 与 KubeRay 接入多级 Gang 调度Grove 和 KubeRay 已接入 Volcano 的多级 Gang 调度能力，为不同角色和副本提供更细粒度的调度支持。Grove：已合入 Volcano 调度后端，将不同角色映射为 PodGroup 内的 SubGroup，支持按角色设置 Gang 约束。( PR :cid:link_61)KubeRay：已合入 SubGroupPolicy 支持，将 Ray worker group 的副本配置转换为 Gang 约束，支持按完整副本进行调度，包括由多个 Pod 组成的多主机副本。( PR : cid:link_15 )两项集成目前都侧重于 Gang 约束，尚未接入 SubGroup 级网络拓扑感知调度。注：多级 Gang 调度自 Volcano v1.14 起已支持，并不限定于 v1.16。▍Kubernetes 兼容与运行管理v1.16.0 支持 Kubernetes 1.36，依赖版本升级到 Kubernetes 1.36.1，源码构建需要 Go 1.26。存储绑定改用上游 VolumeBinding 实现，并同步更新客户端代码、RBAC、安装清单和 CI 配置。( PR : cid:link_42)运维方面，用户可以调整负责更新 Job、Task 状态的 worker 数量，并通过新增指标查看队列中的工作负载状态和调度器提交的驱逐事务。Volcano agent 也支持 Pod 级资源配置，计算资源请求时会计入原生 sidecar 与 Pod overhead。( PR :cid:link_43 、cid:link_44、cid:link_45、cid:link_46、cid:link_47)新增的 inqueue 资源指标可展示已准入但尚未运行的作业预留的 CPU、内存和标量资源，帮助定位队列配额不足的原因。( PR :cid:link_48)▍稳定性与正确性修复修复准入失败后仍占用 inqueue 预留资源的问题，以及 scheduling gate 预留资源未计入祖先队列的问题。( PR :cid:link_49、cid:link_50)避免已完成的 PodGroup 在 Pod 删除后重新进入队列并预留资源，也避免正在终止的任务退回 Inqueue 状态。( PR :cid:link_51、cid:link_52)修复 PVC informer 尚未同步导致 Pod 无法进入正常调度的问题，以及重建 Pod 被写入旧 PodGroup 注解的问题。( PR :cid:link_53、cid:link_60)修复 Agent Scheduler 提前退出时的队列处理，以及占位节点导致的增量快照空指针问题。( PR :cid:link_54、cid:link_55)资源回收在提交前重新检查设备可用性，避免提交无法满足设备需求的回收决策。( PR :cid:link_56)修正节点打分与 PreFilter 的插件接入，确保批量预计算和跳过检查的结果按预期生效。( PR ：cid:link_57、cid:link_58、cid:link_59)▍安全修复v1.16.0 修复了 GHSA-j38h-7pfq-cxmw (cid:link_12)。在 DRA 容量计算中，过大的设备数量或最小任务数可能导致长时间循环计算。计算过程持续持有缓存锁时，也会阻塞其他命名空间作业的调度。通过 ResourceClaim 触发该问题，需要集群支持 DRA 并显式开启 DRAConsumableCapacity，用户还需有权限创建带容量维度的 ExactCount 请求，以及引用该请求的 Pod。修复后，容量计算改用乘法，不再按用户指定的数量逐次累加，同时加强数量校验和溢出处理。受影响版本为 v1.15.0 和 v1.15.1，修复已随 v1.15.2 首次发布，v1.16.0 同样包含修复。风险等级为中危，CVSS 6.5，使用受影响版本的用户应及时升级。感谢 @thc1006 报告并修复该问题，以及 @JesseStutler 协调安全公告发布。  升级注意事项  v1.16.0 正式发布后，可通过 Helm 或安装清单升级：helm repo add volcano-sh https://volcano-sh.github.io/helm-chartshelm repo updatehelm upgrade volcano volcano-sh/volcano \  --namespace volcano-system --version 1.16.0kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/v1.16.0/installer/volcano-development.yaml使用 NamespaceQueue 或新的 PodGroup、Numatopology 字段前，应同步更新 CRD、RBAC 和控制面组件。NamespaceQueue 与 UnschedulableJobCache 默认关闭。NamespaceQueue 依赖层级 capacity，而本次缓存实现暂不缓存层级 capacity 的拒绝结果。启用 fairshare 前应检查插件顺序，启用拓扑反亲和性前应确认其生效范围。自定义拓扑插件需要适配 HyperNodeGradientResult 并重新构建，同时检查 Kubernetes 1.36 集成接口的变化。源码构建需要 Go 1.26。将 HyperNode 切换到独立控制器时，应先完成 disabled 模式的滚动更新，再启用 standalone。现有 Volcano CRD 增加了 Helm 卸载保留注解，但本次新增的 NamespaceQueue CRD 尚未带有该注解。重新安装前应确认资源保留与归属。▍参考链接本文介绍 v1.16.0 的主要能力，完整 API 变化、问题修复、依赖更新及维护项请参考 Release Note。Release Note: cid:link_14完整变更记录: https://github.com/volcano-sh/volcano/compare/v1.15.0...v1.16.0  致 谢  Volcano v1.16 共有 65 位贡献者参与。衷心感谢每一位贡献者在功能开发、问题修复、测试、文档和评审中的投入，推动 Volcano 持续提升调度能力与稳定性！参与本次版本合并 PR 的作者包括：@106umao@3th4novo@A69SHUBHAM@aeron-gh@agrawalcodes@Aliexe-code@Aman-Cool@anxkhn@archlitchi@autsu@avinxshKD@bhuvan-somisetty@CapThunder19@choosen23@copilot-swe-agent@DarkestSky@dependabot@devzizu@dmildh-absci@DSFans2014@FAUST-BENCHOU@gitGurugu@goyalankit@gucardona@hajnalmt@halcyon-r@harshrajdebug@hzxuzhonghu@iamtanishqjain@JesseStutler@kitianFresh@kryz73@kube-gopher@kubeboiii@linuxfhy@magic-peach@miantalha45@moezdil@netliomax25-code@omlahore@OneSizeFitsQuorum@PrasannaMishra001@Psykii22@r0hansaxena@ranxi2001@ruanwenjun@safiya2610@shettythrishal328-dev@shivansh-gohem@songmingming0827@SquareCatFirst@t2wang@Tau721@thc1006@togettoyou@vanshika2720@vivek41-glitch@vzhou-p@wangyang0616@WHOIM1205@xiezhayang@xuezhaojun@yash-pokhriyal@YiD11@yuanhuaiwang  关注魔方公众号，获取更多前沿资讯

最好的产品，诞生于用户的每一次点击与反馈。华为云云容器引擎 CCE 近期围绕大家反馈的远程登录、日志体验等方向进行了专项优化，欢迎体验：cid:link_1  

近日，全球商业技术洞察机构Gartner®正式发布2026年《容器管理魔力象限》报告，华为云凭借执行能力和愿景完整性，蝉联领导者，标志着在全球容器管理领域的领先地位持续获得国际认可。该报告围绕新云原生应用、存量应用容器化、AI训练负载、AI推理及Agent负载、边缘应用、混合云应用等核心场景，对全球主流云服务商进行全面评估。华为云提供业界最完整的容器产品矩阵，覆盖公有云、分布式云、混合云、边缘等场景，已广泛应用于互联网、金融、制造、交通等行业，持续帮助全球客户取得商业成功。面向AI智能体时代，华为云聚焦AI战略并持续加大AI基础设施投入，在业界率先提出Agentic Infra新范式，以容器技术为核心持续完善算力、调度、运行环境与开源生态等基础能力，夯实“硅基黑土地”。CCE智算集群基于华为云软硬芯协同的优势，高效编排灵衢智算超节点(AICS)，实现十万卡级算力池化与统一调度，为大模型训练、推理等AI负载提供稳定的云原生底座。CCE VolcanoNext通智一体化调度引擎通过“训推共池+碎片整合”实现通智混合算力负载调度革新，将资源利用率提升30%以上；在推理场景中，结合Kthena智能路由及Prefill/Decode多角色编排能力，联动EMS高性能KV Cache缓存，进一步提升推理吞吐，实现算力资源的高效利用。AgentSphere打造安全自治的Agent运行底座，提供极速弹性、生态兼容的Agent基础设施。其中，Agent Sandbox凭借羽量级沙箱技术，实现百毫秒级极速启动与每分钟十万级批量创建能力，高效支撑Agent Serving高频调用及Agentic RL大规模并行训练等场景。华为云积极参与全球云原生技术社区的开源生态建设，向CNCF捐赠了Volcano、KubeEdge、Karmada等标杆开源项目，同时面向AI推理与Agent场景发布了Kthena与AgentCube，持续推动全球容器与云原生技术向AI演进。未来，华为云将继续秉持携手创新、成就共享的理念，深化容器与Agentic Infra的融合创新，为Agent应用规模化落地和千行百业智能化升级提供更加开放、高效、可靠的基础设施。来源： Gartner®, Magic Quadrant for Container Management, 2 September 2026阅读报告：https://www.gartner.com/reprints/?id=00ThR00000EdAxMUAV&ct=260908&st=sb 关注魔方公众号，获取更多前沿资讯

9月8日，在KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026大会现场，云原生计算基金会（CNCF）正式宣布，Karmada晋级为毕业项目。这一里程碑不仅标志着Karmada在技术能力、社区治理与安全实践各领域的高度成熟，更体现了业界对其开源价值与生态影响力的广泛认可，Karmada已成为全球云原生跨云跨集群算力调度与治理的重要基础设施。▲CNCF CTO Chris Aniszczyk宣布 Karmada正式毕业华为云研发总裁王洪利表示：“Karmada迈入毕业阶段，离不开全球贡献者与企业用户的共同推动。面向未来，华为云将秉持开源初心，持续深化与CNCF社区的协同，推进云原生与AI技术深度融合，并进一步面向Agent场景解决跨云大规模通智融合算力调度难题，让多云多集群管理与调度技术成为AI时代产业创新的坚实底座。 ” 引领跨云AI算力池化的技术先驱作为CNCF首个毕业级云原生多云容器编排引擎，Karmada由华为云联合金融、互联网、汽车及出行等多领域头部企业于2021年共同发起，是业界首个聚焦跨集群、跨云编排的开源项目。借助Karmada，企业和开发者可以快速构建无限可扩展的容器资源池，像使用单个集群一样使用多云集群。 自加入CNCF以来，Karmada在全球社区的共同推动下持续演进，正有力支撑企业应对混合云部署、多区域容灾与大规模AI训练推理等复杂场景。与毕业官宣同步发布的Karmada v1.19，其多组件调度与优先级能力直击AI场景痛点。基于优先级的调度特性已提升至Beta并默认开启，帮助平台团队在GPU等资源受限环境中优先保障关键工作负载。企业无需修改现有应用，即可实现跨多个集群、云与区域的统一编排、故障自动恢复与弹性伸缩。凭借对AI训练与推理场景的深度适配，Karmada已成为企业构建跨云AI算力基础设施的核心选择。晋级CNCF毕业级项目后，Karmada也将进一步构建更智能的资源感知控制面，帮助企业应对更大规模、更复杂的跨区域异构资源调度挑战。“当组织在多个集群和GPU受限的AI环境中扩展Kubernetes时，拥有生产就绪的方式来协调整个集群舰队，对运营成功至关重要，”CNCF CTO Chris Aniszczyk表示。“达到CNCF毕业状态，证明Karmada已具备企业所需的技术成熟度、治理和安全工作；我们期待该项目在生态中持续成长。” 持续贡献：从技术开源到产业赋能作为项目的发起组织与核心贡献者，华为云在Karmada的架构设计、关键代码贡献、社区治理及安全审计等环节持续深耕，有力驱动了项目的成熟与演进。作为CNCF唯一的中国创始企业，华为云深度参与CNCF治理，在技术委员会及核心项目的Maintainer团队中均占据重要席位。2024年，华为云技术专家高票当选CNCF中国本土唯一TOC（技术监督委员会）委员席位（全球共11席），并现任CNCF TOC副主席。在推动开源生态建设的同时，华为云将Karmada作为分布式云原生服务（UCS）的核心引擎，落地于智算及混合云生产环境。华为云UCS作为业界首发的分布式云原生服务，依托Karmada构建了覆盖中心Region、专有Region、边缘云、客户数据中心及第三方云等多维基础设施的应用算力供给架构，为云原生工作负载提供跨云跨地域的一致化调度体验。同时，大规模商用场景的持续验证，也反哺Karmada在真实业务压力下不断优化，进一步巩固了其面向生产级分布式云原生场景的稳定性与可靠性。 繁荣生态：全球采用者与贡献者共建Karmada当前拥有来自292家组织的超过1,214名贡献者，GitHub Stars超5,600。其生产采用者覆盖云计算、互联网、通信、AI、旅游、物流、企业IT等众多领域，包括Bloomberg、Wellhub、哔哩哔哩、科大讯飞、携程等40余家公开企业。在诸多用户场景中，Karmada被广泛用于支撑混合云容量调度、多区域弹性扩展、智能流量分发、AI训练与推理、GPU/CPU异构调度、多集群应用交付以及舰队级服务配置分发等核心业务。“当组织规模扩展到单个Kubernetes集群之外时，他们需要在不增加复杂性的情况下实现一致的管理。Karmada通过将熟悉的Kubernetes API扩展到跨集群和云环境，解决了这一问题。该项目拥有来自六家组织的Maintainer，且大量的采用者均在使用它，我们祝贺Karmada成为CNCF毕业项目。”— Chad Beaudin，CNCF TOC Sponsor “Karmada已成为Bloomberg运营弹性云原生基础设施的基础。通过自动化灾难恢复、提升资源利用率，并简化单个Kubernetes集群的管理，它帮助我们的平台工程团队更高效地运营，同时让内部应用团队在部署任务时获得更简单、更一致的体验。作为过去几年与Karmada社区紧密合作的伙伴，我们见证了这个开源项目持续演进，它的毕业反映了其对管理复杂Kubernetes环境的企业组织日益重要的价值。”— Michas Szacillo，Bloomberg流媒体平台工程团队负责人 “在携程，Karmada已成为我们多集群基础设施的关键组成部分，并在生产中带来了显著价值。在不改变现有Kubernetes资源定义的情况下，它使我们能够将多个集群作为统一资源池运营，支持跨集群弹性和故障转移，更高效地将新集群投入生产，并以对应用最小的干扰完成大规模工作负载迁移。这大大降低了大规模运营基础设施的复杂性。随着计算日益跨越区域、云和异构资源，我们相信Karmada将成为可靠、可扩展的云原生与AI基础设施的重要基础。”— 乐鸿辉，携程高级开发专家 开源开放，共建Agentic Cloud坚实底座Karmada从最初的代码提交走向CNCF毕业，是全球数百家企业、上千位贡献者共同推动的结果。这一历程不仅验证了Karmada的技术成熟度，更证明了开源协作在解决复杂基础设施挑战上的独特价值。随着大模型与AI智能体技术的快速演进，云计算正加速迈向智能化时代。面向未来，华为云也将持续与开源社区一道，驱动基础设施迈向面向“Agentic Cloud”的核心底座，让容器具备感知应用意图、自适应调度与跨集群协同的能力的Agentic Container。通过把复杂的底层资源管理下沉为标准的开源能力，帮助开发者更简单、智能地驾驭万卡集群与智能体工作负载，共同开拓云原生在AI时代的全新边界。 关注魔方公众号，获取更多前沿资讯

9月6日至7日，AGNTCon+MCPCon China 2026 将在上海举行。来自全球的开发者、技术专家、开源项目贡献者及行业领袖将汇聚一堂，共同交流智能体Al(AgenticAI)与模型上下文协议(MCP)的最新技术进展和实践经验。华为精彩抢鲜看~  

9月，全球云原生与Al 基础设施顶级盛会 KubeCon+CloudNativeCon+OpenlnfraSummit + PyTorch Conference China 2026 将于中国上海举行，CNCF、OpenlnfraPyTorch三大基金会首次齐聚，云原生、开放基础设施与 AI三大技术生态将在同-会场交汇。访问大会官网，了解更多议程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china  

当 AI Agent 从概念验证走向真实业务与生产环境，工程团队面对的问题正在迅速发生变化：Agent 应该运行在怎样的基础设施之上？企业内部越来越多的 MCP 服务，如何实现高效注册、发现与管理？当一个 Agent 不再足以完成复杂任务，多智能体又该如何真正实现工程化协同2026年9月6日至7日，AGNTCon + MCPCon China 将在上海国际会议中心举行。 作为 AAIF （Agentic AI Foundation）面向开放智能体生态的重要技术大会，活动将汇聚开发者、研究人员、平台建设者、开源社区以及企业技术团队，围绕 MCP、Agent 协议、基础设施、编排、评测、可靠性、安全治理与企业生产环境实践展开深入交流。https://www.lfopensource.cn/mcp-dev-summit-shanghai/本届AGNTCon + MCPCon China，华为三位技术专家将登台进行分享。他们从基础设施、MCP 服务发现到多智能体工程，为开发者带来三个最值得关注的技术方向，直击企业级Agent落地的核心痛点。基础设施：企业级Agent是否需要一套全新的技术栈过去十多年，云原生技术一直是现代应用的基石。但当企业开始在生产环境中部署自主且长时间运行的 Agent 时，一个不得不面对的问题出现了：现有的基础设施，还够用吗？从计算资源、弹性调度、安全隔离到 Agent Runtime，Agentic AI 对底层基础设施提出了与传统应用截然不同的要求。当我们在真实的生产环境中大规模构建和运营智能体系统时，会反复遇到一系列棘手的挑战：长周期状态的管理、工具的安全执行、Agent 行为的可观测与调试、安全边界的定义与人机协同，以及多 Agent 之间的协调。这引出了一个核心议题：企业级智能体究竟只是现有基础设施上的另一种工作负载，还是说它需要全新的底层原语（primitives）与抽象层？为了回答这个问题，在本次大会的圆桌讨论中，来自不同技术栈的基础设施构建者们将同台对话，分享在大规模构建和运营智能体系统过程中的实践经验。其中，Kevin Wang 将作为分享嘉宾，与来自 AWS、Kong Inc. 和腾讯的专家一起，从云原生走向 Agentic AI 的技术演进出发，共同探讨这个越来越现实的问题：企业级 Agent 是否需要一套全新的基础设施技术栈？演讲主题：从云原生走向 Agentic AI：企业需要一套新的基础设施吗？演讲嘉宾：Kevin Wang｜HuaweiCNCF技术监督委员会（TOC）副主席，华为云原生开源 Tech Lead。 MCP：服务越来越多，怎样让 Agent “找得到、连得上”？当企业内部的 MCP Server、Tools 与 Agent 数量持续增加，单纯解决“连接”已经不够。一个更棘手的问题浮出水面：服务如何注册、发现，以及不同运行环境之间如何实现互操作？这并非杞人忧天。据 Anthropic 报告，一个接入了 1,000 个 MCP 工具的智能体，仅工具提示词（tool prompts）就会消耗约 50 万个 Token。而传统的嵌入方法往往会遗漏与查询相关但在语义上并不相似的工具，导致召回率存在天然上限。这就引出了一个核心议题：如何在不耗尽 Token 的前提下，让 Agent 在海量工具中精准、高效地找到所需服务？为了解决这一痛点，在本次大会中，Wei Zheng 将介绍openJiuwen A2X Registry，探讨如何为 MCP 服务提供更高效的注册与发现机制，为 Agent 与工具之间的大规模连接建立更具工程化的基础。华为公开资料也将 A2X Registry 列为 openJiuwen Agent Protocol 中用于 Agent 互操作的重要组成部分。演讲主题：openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution演讲嘉宾：Wei Zheng｜Huawei华为高级工程师，领导开源项目openJiuwen A2X Registry。 多智能体协同：从“一个 Agent”到“一支 Agent 团队”AI Agent 的工程范式正在持续演进。从 Prompt Engineering 到 Context Engineering，再到当下成为主流的 Harness Engineering，单智能体的"驾驭与治理"已经形成了相对清晰的方法论体系。但当任务复杂度跨越单Agent 的能力边界，需要多个智能体分工协作来完成时，原有的工程方法论便不再适用。如何让多个智能体自主分工、高效沟通、无缝协作？成功的协同模式又如何沉淀、复用并持续演进？这就引出了一个核心议题：AI Agent 工程范式从单智能体走向多智能体团队协同之后，开发和运行方式将发生怎样的下一次飞跃？为了回答这个问题，在本次大会中，程烁（Shuo Cheng） 将带来主题分享，探讨这一新阶段的核心命题——Coordination Engineering（协同工程）。他认为，协同工程不是对 Harness Engineering 的替代，而是其在团队协作维度上的自然延伸。AI Agent 工程范式从单智能体走向多智能体团队协同之后，开发和运行方式可能会再次发生变化。华为支持的 openJiuwen 社区目前也正围绕 Agent Team、团队技能沉淀以及协同自演进等方向展开实践。演讲主题：Coordination Engineering：AI Agent 工程范式的下一次跃迁演讲嘉宾：程烁｜Huawei就职于华为2012实验室，专注于 AI Agent 工程化与多智能体协同方向的探索与落地，是Coordination Engineering 理念在开源社区落地的核心推动者之一。 不止华为：两天大会，深入 Agentic AI 的九大技术方向AGNTCon + MCPCon China 的议程并不只讨论“大模型”或单一 Agent 应用，而是进一步进入 Agent 真正落地时必须解决的工程问题。本届大会设置了九大技术方向，涵盖从开发、协议与基础设施，到测试、可靠性、安全、企业采用及多智能体系统等不同层面： 智能体商业构建 智能体工程 构建可靠的智能体系统 企业落地实践 智能体评估与测试 人机协作 互操作性与标准 MCPCon：聚焦MCP最新演进 多智能体与分布式系统 提前规划两天的技术议程，可以从这里开始：👉了解更大会完整议程https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/👉了解更多关于九大技术路径议题AI智能体如何真正落地？AGNTCon + MCPCon China揭晓九大技术路径👉了解更多智能体实际部署过程中的关键问题精选议程抢先看｜五场技术分享，直击智能体落地关键问题更多演讲嘉宾、技术分享、案例讨论及工作坊内容，请以大会官方网站公布的信息为准。 75张免费门票限时开放｜现在就行动AAIF Community 微信读者专享：75张 AGNTCon + MCPCon China 免费门票报名时输入微信专属代码：ACH26WECHAT即可享受本次免费参会机会。仅限前75位成功注册者，额满即止。👉立即注册报名，锁定席位（复制链接至浏览器打开）https://www.lfopensource.cn/mcp-dev-summit-shanghai/register/👉查看完整会议议程（复制链接至浏览器打开）https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/👉了解主题演讲嘉宾（复制链接至浏览器打开）https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/featured-keynote-speakers/ AGNTCon + MCPCon China 2026会议日期： 2026年9月6日至7日 会议场地： 上海国际会议中心 交通地址： 上海市浦东新区滨江大道2727号大会主题：Agentic AI + Model Context Protocol（MCP）从 MCP 和开放协议，到 Agent 工程、基础设施、多智能体系统、可靠性与企业生产实践，两天时间，与正在真正构建 Agentic AI 技术栈的开发者和技术团队面对面。 Agentic AI 的技术栈正在被重新定义。9月6日至7日，上海见。

9月7日至9日，全球云原生与 AI 基础设施顶级盛会 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 将于上海国际会议中心召开，CNCF、OpenInfra、PyTorch 三大基金会首次齐聚，云原生、开放基础设施与 AI 三大技术生态将在同一会场交汇。本届会上，Volcano社区将在议题演讲、展览展示等区域全方位与开发者展开技术交流。 随着AI大模型与Agent应用加速迈入生产环境，传统云原生架构在面对分布式推理部署、异构算力碎片化以及 RL/Agent高并发短生命周期任务时，都难以满足需求。针对低时延和高资源利用率等需求，Volcano社区构建了一套涵盖集群调度、推理服务部署到Agent运行时的完整云原生AI技术栈，实现通智一体化调度。 期待在会上与大家面对面交流 。  Volcano 议题预告  ▍Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia演讲者：Kevin Wang (CNCF TOC Vice Chair, Lead of Cloud Native Open Source, Huawei )时间地点：9月9日 11:00-11:30 | Mandarin Hall I议题看点：深入解析华为小艺（Celia）背后的云原生推理面架构。探讨华为如何依托云原生技术打造高并发、高可用的大规模 AI 推理服务平台，并分享在大规模真实业务场景下的调度优化与算力运维实践经验▍Volcano: A Unified Scheduling Platform for Cloud Native AI演讲者：Zicong Chen ( Volcano Maintainer, Software Engineer, Huawei Cloud); DongYang Wang(Cloud Native AI Infrastructure Engineer, SenseTime)时间地点：9月9日16:15-16:45 | 5B + C议题看点：详细剖析 Volcano 作为统一调度平台的核心架构与演进路径。分享如何通过 Volcano 统一管理和调度异构算力资源，兼顾云原生 AI 场景中复杂且多样的训练、推理及 Batch 工作负载，提升整体集群利用率▍Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration演讲者：Zhencheng Lee (Senior Cloud Develop Engineer, Huawei Cloud)时间地点：9月9日11:00-11:20 | 5B + C议题看点：聚焦强化学习（RL）与多智能体（Multi-Agent）协同场景的性能瓶颈。探讨如何结合 AgentCube 极速沙箱技术与弹性预热池，解决多 Agent 高并发运行时的容器拉起延迟，从而全面加速多智能体环境下的训练与协同执行▍Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet演讲者：Kay Yan (Principal Software Engineer, DaoCloud) ；Zicong Chen( Volcano Maintainer, Huawei Cloud )时间地点：9月8日13:45-14:15  |  5B + C议题看点：超越传统的模型切分技术，探讨大模型服务中基于 LeaderWorkerSet 的原子调度模式。同时深入分析 Prefill-Decode（PD）分离式大模型推理架构的技术细节与最佳落地实践。  Volcano 展台交流  ▍CNCF 项目展区:展位位置： Grand Ballroom I CNCF 展区 T-2 Volcano 展台开放时间：  9月8日 15:00-19:00；9月9日 13:15 - 15:30展台亮点：Volcano 社区核心人员驻场，面对面交流云原生 AI 统一调度、Agent 极速拉起与异构算力管理的最新成果与行业案例，欢迎现场来聊▍展商展区同时，在大会的华为展区“面向 Agentic AI 的容器基础设施”展台，您也可以现场体验Volcano社区企业级最新应用，解锁容器 AI 新引擎：展位位置： Grand Ballroom 1 华为展区开放时间：  9月8日 10:30-19:00；9月9日 10:30-15:30 🌋 Volcano （cid:link_0）是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.9k+ Star 和 2.4K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。9月8日-9日上海，KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 现场见！更多精彩议题，访问大会官网程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/ 关注魔方公众号，获取更多前沿资讯

华为云容器引擎 CCE 近期推出多项核心能力新增和升级，从 AI 容器、备份中心、Gateway API、集群自动升配、负载感知调度等全面进化您的云原生体验，助力业务高效、稳定、安全地运行。即刻访问体验：cid:link_1 

9月8日至9日，全球云原生与 AI 基础设施顶级盛会 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 将于上海国际会议中心举行，CNCF、OpenInfra、PyTorch 三大基金会首次齐聚，云原生、开放基础设施与 AI 三大技术生态将在同一会场交汇。本届大会值得关注的变化，是焦点从“模型能力”推进到了“Agent 规模化落地”——当 Agent 成为企业生产力的组成部分，从算力调度到智能体平台，技术栈的各层能力都在向 Agent 场景持续优化和适配。作为战略级赞助商，华为将在会上全方位分享从算力底座到智能体应用等开源创新与产业实践，既有通智融合调度、多云算力池化、云边AI协同、Agentic AI 容器等开源基础设施层面的深耕，也有企业级智能体平台的商用赋能。本文与你一探究竟： ▍01 面向 AI 训推、RL、Agent 的全场景统一调度大模型与智能体应用正加速迈向生产环境，传统云原生架构在面对万卡扩展性、异构算力碎片化以及 RL/Agent 高并发短生命周期任务时，面临高延迟与资源浪费等挑战。针对这些智算瓶颈，华为云开源技术团队协同社区伙伴，以 CNCF Volcano 为内核，给出了一套解法——构建一条从集群调度、推理服务到 Agent 运行时的完整云原生 AI 技术栈，实现通智一体化调度：调度层，夯实通智一体调度基座：Volcano 在成熟的云原生批量调度能力基础上，面向高并发、短生命周期的 Agent 任务推出 Agent Scheduler，通过多 Worker 并行调度与乐观并发控制提升调度效率；结合 NodeShard 动态节点分片与队列管理，实现 Batch Scheduler 和 Agent Scheduler 的资源协同，兼顾训练作业的规模化运行与推理、Agent 任务的快速响应，形成训推一体、通智协同的调度最佳实践。推理层，突破大模型推理瓶颈：面向 LLM 生产部署的推理服务平台 Kthena 支持 PD 分离部署与PD场景下的自动扩缩容。支持多种可组合的流量路由策略，兼容 vLLM/SGLang 等主流推理引擎， 在复杂对话场景下可帮助企业降低 20% 以上的全局延迟。运行时层，专为 AI Agent 打造的弹性沙箱引擎：Volcano 社区面向 Agent 工作负载的 AgentCube，原生支持 AI Agent 的轻量级与有状态运行时；以预热池（Warm Pool）技术实现隔离容器毫秒级拉起，为多 Agent 并发协同提供类 Serverless 的极速体验。现场相关议题，欢迎关注：🎙️ 议题：Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia[1]  (Kevin Wang, CNCF TOC Vice Chair , Tech Lead of Cloud Native Open Source， Huawei )🎙️议题：Volcano: A Unified Scheduling Platform for Cloud Native AI[2] ( Zicong Chen, Volcano Maintainer, Software Engineer at Huawei Cloud; DongYang, WangCloud Native AI Infrastructure Engineer,SenseTime)🎙️ 议题：Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration[3]（Zhencheng Lee,Senior Cloud Develop Engineer at Huawei Cloud）🎙️议题：Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet[4] (Kay Yan， Principal Software Engineer, DaoCloud； Zicong Chen , Volcano Maintainer, Software Engineer at Huawei Cloud）📍 欢迎打卡 Volcano 社区展台（9月8日15:00-19:00，9月9日 13:15-15:30，T-2，Grand Ballroom I ） 与技术大咖面对面，来自华为云等企业的社区专家将现场探讨云原生 AI 调度的前沿方向与实践经验。 ▍02 打破资源边界，跨云 AI 算力池化算力不应该被困在单一集群里。当企业同时拥有公有云、私有云与边缘节点，算力管控的复杂度随拓扑同步上升：训练任务需要弹性，推理任务需要就近，业务高峰需要冗余。云原生多云编排引擎 Karmada  正成为企业构建跨云“超级 AI 算力池”的核心纽带，让算力在不同环境之间按需流动：海量 AI 任务跨集群动态分发：通过 Karmada 统一联邦控制面，根据公有云、私有云及边缘端的异构算力空闲度，自动分发大规模 AI 训练与推理任务，让算力匹配任务，而不是让任务迁就集群。生产级高可用与渐进式交付：联合 Argo 实现单一声明式规范下的跨云 Canary 灰度发布；支持有状态工作负载在集群故障时平滑迁移与数据恢复，为跨云生产环境提供可靠性保障。🎙️ 议题：Building a Multi-Cluster Progressive Delivery Platform with Karmada & Argo[5] (Zhuang Zhang, Karmada Maintainer, Software Engineer at Huawei  Cloud)🎙️ 议题：Karmada Project Lightning Talk[6]（Hongcai Ren, Karmada Maintainer，Senior Software Engineer at Huawei Cloud; Maintainer, Yiheng Ci ）🎙️ 议题：Multi-cluster Orchestration System: Karmada Updates and Use Cases[7]（Hongcai Ren, Karmada Maintainer，Senior Software Engineer at Huawei Cloud; Zongqing Li,Senior Cloud-Native R&D Engineer, Trip.com ）📍 华为云技术人员将在 Karmada 社区展台（9月8日 10:30-14:30, 9月9日 10:30-12:45, T-2,Grand Ballroom I ） 驻场，与现场开发者共同探讨分布式云原生与多云 AI 算力池化的技术与案例，欢迎现场交流。 ▍03 云边协同：KubeEdge驱动边缘AI规模化演进作为 CNCF 首个毕业的云原生边缘计算项目，KubeEdge 已广泛应用于交通、能源、制造、航天、汽车等各行各业。本届大会，来自华为云，Harmony Cloud 和 VMware 的 KubeEdge TSC 成员将联合带来“毕业报告”式的深度分享。核心架构层面，解析 KubeEdge 如何通过松耦合设计高效管理海量边缘节点与应用；落地实践层面，直面智慧城市、工业物联网 (IIoT)、边缘人工智能、机器人和零售等多个行业的实际部署案例场景真实挑战，分享应对策略；生态层面，解读全新发布的 Certified KubeEdge 一致性认证体系及社区治理的最新动态，为计划规模化落地边缘AI的企业提供参考路径。🎙️ 议题：Solving Industrial Challenges with KubeEdge: A Post-Graduation Report[8]（Yue Bao, Senior Software Engineer at Huawei Cloud; Huan Wei, Senior Technical Director, Harmony Cloud; Yin Ding, Engineering Leader at VMware ） ▍04 赋能企业级智能落地，华为云 AgentArts 等产品重磅亮相作为本届 KubeCon 的重要看点之一，华为云智果 AgentArts 智能体平台、 华为云果办 OfficeAce 办公智能体 、openJiuwen 等一系列智能体相关的产品与创新技术也将重磅亮相。华为云智果（AgentArts）是面向企业级 AI Agent 的全生命周期工程与运行底座，助力企业快速构建、部署和运营能自主执行任务的AI智能体。它向下纳管计算与模型资源，提供完整的 Agent 托管能力。向上对编排、运行与运维进行标准化，通过引入多层控制器、自进化、Agent 认证鉴权、Agent 记忆、会话级隔离、动态令牌和精细化权限控制等机制，解决 Agent 落地生产环境时的工程化与合规难题，为智能体的高并发调度、复杂流程执行、数据安全合规及自动化运维提供标准化、可观测的 Harness 基础设施支撑。openJiuwen 与 AgentArts 内核同源度超过 90%，通过开放核心框架和底层能力，大幅降低了企业及软件开发服务商的二次开发门槛，支持开发者基于开源版本构建本地化、兼容企业生态的智能体应用。其 WorkSwarm 蜂群智能体的多任务模式与高效协同，结合 Coordination Engineering 的多智能体标准化范式 与 Agent Swarm 的双层协同自演进机制，在底层算力亲和加速的保障下 ，全面助力智能体快速构建与应用，携手行业伙伴共同打造智能体生态。华为云果办（OfficeAce）是一款面向个人与企业用户的办公全场景智能体，以AI重构桌面办公体验，通过自动化处理重复事务、智能整合信息及协作辅助，为企业员工打造具备专业 Skills 技能的 Agent 专家团队，将用户从繁琐操作中解放出来，大幅提升办公效率；同时，面向企业提供智能体接入、统一运营、安全治理等企业级能力，推动 AI 从单点办公辅助融入真实业务流程，实现规模化应用。🎙️ 议题：openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution[9] ( Wei Zheng,Senior Engineer, Huawei)🎙️ 议题：Coordination Engineering：The Next Leap of AI Agent Engineering Paradigm[10] (Shuo Cheng, Agent Technical Expert, Huawei)📍 欢迎亲临华为云“智能体全栈平台 Full-Stack Agent Platform”展台（9月8日-9日，Grand Ballroom I 华为展区），现场体验华为云智能体平台从开发、部署到运营的全流程能力。 ▍05 AI 算力底座：面向 Agentic AI 的容器基础设施作为全球云原生与 AI 领域的先驱者与 CNCF 创始成员，华为云凭借多年来的产业实践和技术创新，引领面向 Agentic AI 的容器基础设施，为企业级 Agent 运行提供调度、弹性与安全的一体化支撑，并以丰富的商用落地实践，为智能体规模化应用持续赋能：在调度层面，基于 Volcano 实现 CPU 与 GPU 异构算力的统一调度，满足 AI 训练、推理及 Agent 任务对计算资源的差异化需求。在安全隔离层面，升级 Agent Sandbox 安全沙箱技术，实现轻量级隔离与亚秒级极速冷启动，为高频工具调用与动态代码执行提供全链路安全保障。弹性层面，依托 CCE Turbo 的极速扩容、资源预热与异构算力加速能力，结合 CCE Autopilot 与 CCI 的 Serverless 容器弹性，提供从资源预热、亚秒级扩容到超大资源池的端到端弹性能力，从容应对 Agent 任务突发流量与资源洪峰。同时，华为云 AI 容器团队持续参与 Volcano、Karmada、KubeEdge、Kmesh 等开源社区的贡献与建设，推动云原生技术生态从 AI Native 向 Agentic Native 演进。📍 欢迎打卡 KubeCon China 2026 “面向 Agentic AI 的容器基础设施”展台（9月8日-9日，Grand Ballroom 1 华为展区）， 现场直击 CCE Autopilot + CCI 秒级弹性伸缩与 Agent Sandbox 安全隔离实效，解锁企业级容器 AI 新引擎。从开源社区的前沿探索到企业级商用落地，华为云全栈架构创新极致重构 AI 算力底座，让智能体跑在坚实的算力底座上，也让平台能力真正转化为企业生产力，为千行万业在 Agentic AI 时代的智能化转型提供澎湃动力。期待与您共赴 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026，共探 Agent 时代无尽可能！👉 访问大会官网获取完整议程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/议题索引[1] Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia:https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1224671[2] Volcano: A Unified Scheduling Platform for Cloud Native AI: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222060[3] Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1304033[4] Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222146[5] Building a Multi-Cluster Progressive Delivery Platform with Karmada & Argo: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1225153[6] Karmada Project Lightning Talk: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222021[7] Multi-cluster Orchestration System: Karmada Updates and Use Cases:https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222012[8] Solving Industrial Challenges with KubeEdge: A Post-Graduation Report: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1225125[9] openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution:https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/?id=1242199[10] Coordination Engineering：The Next Leap of AI Agent Engineering Paradigm: https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/?id=1227642 关注魔方公众号，获取更多前沿资讯

🚀 OBS多语言SDK功能与文档焕新，开发体验更流畅长期以来，OBS 各语言 SDK 在功能覆盖上存在一定差异，给开发者在技术选型与跨语言项目协作中带来了诸多不便。相信不少开发者都遇到过类似情形：在某语言 SDK 文档中查阅到一项新特性的使用示例，切换到另一语言项目时却发现该能力尚未支持；或是在团队内不同技术栈之间进行方案复用，却因 SDK 功能不统一而不得不额外封装适配层，这对开发效率与体验都造成了客观影响。这一“语言时差”问题，OBS 团队始终高度关注，并致力于从根本上加以解决。过去半年，OBS 团队系统梳理了各语言 SDK 的功能差异清单，以开发者最高频使用的能力集合为基准，对各主流语言 SDK 进行了功能补全与文档体系焕新。本次优化，OBS 主流语言 SDK 的高优能力正在逐步拉齐。本次更新覆盖 Java、Python、C、Go、BrowserJS、PHP、Node.js 七个语言版本，涵盖功能新增与文档优化两大维度。具体更新情况如下：语言（版本）功能新增文档优化Java（v3.26.6）新增桶在线解压、DIS策略、镜像回源、WORM、归档直读、桶加密配置；优化流式上传、依赖冲突、分段上传、上传进度、自定义头域、批量删除等场景；新增临时URL、base64图片上传、对象标签、OkhttpEventListener日志、断点续传回调等示例Python（v3.26.6）新增桶清单、在线解压、对象标签、桶级WORM、DIS策略、归档直读策略；并行文件系统修改写对象新增异步断点续传（含暂停/取消）、MD5校验、恢复指定路径对象、统计文件夹大小、多段复制、WORM创建桶、多范围下载、临时URL指定版本下载、断点续传回调等示例；优化桶加密、自定义域名证书托管C（v3.26.6）新增自定义HTTP头域、指定端口范围；创建/列举并行文件系统；桶自定义域名管理；上传/下载单链接限速；对象生命周期新增配置option、批量复制/上传/下载/恢复对象等示例；优化复制对象、错误码、临时URL授权访问Go（v3.26.6）新增上传回调参数及结果获取；HeadObject检查对象存在；获取上传/下载进度；列举并行文件系统对象新增单链接限速场景下生成授权URL并下载对象（含指定版本）示例；优化创建并行文件系统、设置对象元数据BrowserJS—新增桶归档直读、恢复归档/深度归档、桶加密、对象标签、取消分段上传、复制对象等操作指导；新增MD5校验、批量上传/下载/复制对象示例PHP—新增清理多段上传碎片、创建/列举并行文件系统操作指导；新增批量上传/复制/下载/恢复对象示例Node.js—新增桶归档直读、恢复归档/深度归档、获取下载进度操作指导；新增分段上传、MD5校验、批量上传/复制/下载对象示例本次拉齐的核心价值：本次升级完成后，开发者无需再因“某功能在特定语言 SDK 中是否支持”而反复确认或调整技术方案，技术选型可完全回归业务需求与团队技术栈偏好。官方文档中此前常见的“该功能仅支持 XX 语言”等限制说明，将在本次更新后大幅减少，显著降低开发者在多语言环境下的学习成本与迁移成本。各语言最新版本已全量推送，欢迎升级体验。请点击后续规划：更多语言的 SDK 功能对齐工作已在持续推进中，后续将逐步覆盖更多技术栈，确保广大开发者无论使用何种语言，均可获得一致的开发体验。如您在升级或使用过程中遇到任何问题，欢迎在评论区留言反馈，OBS 团队将及时响应并跟进处理。各语言 Release Notes 详见下方链接:语言版本功能更新文档优化Javav3.26.6支持桶在线解压策略特性支持桶DIS策略特性支持镜像回源特性支持WORM特性支持归档直读功能支持桶加密配置支持下载对象时限速优化上传段支持流式上传相关内容优化依赖缺失和依赖冲突的解决方法优化列举分段上传任务相关内容优化获取上传对象进度的内容优化有关发送请求时添加自定义头域相关内容优化批量删除文件夹下的所有对象相关内容补充通过临时URL访问OBS的代码示例优化传输时校验文件一致性的内容补充上传base64编码图片的代码示例补充设置、获取、删除对象标签的代码示例补充如何配置OkhttpEventListener日志与打印详细阶段日志补充使用断点续传上传时设置上传回调的代码示例PythonV3.26.6支持配置桶清单。支持配置在线解压策略。支持并行文件系统修改写对象。支持配置对象标签。支持配置桶级默认WORM策略。支持配置桶DIS策略。支持配置桶归档直读策略。 补充异步断点续传上传、暂停和取消的代码示例。优化桶加密内容，通过指定加密方式加密桶。优化桶自定义域名里有关证书托管的内容。补充使用MD5校验文件一致性文档。补充恢复指定路径下的对象的代码示例。补充统计文件夹大小的代码示例。补充多段复制的代码示例。补充创建桶时开启WORM开关的代码示例。补充下载对象时指定多个范围的代码示例。补充临时url指定版本号下载对象的代码示例。补充断点续传上传回调的代码示例。Cv3.26.6支持在发起请求时携带自定义HTTP头域支持指定eth0端口范围支持创建和列举并行文件系统支持设置、获取与删除桶的自定义域名支持上传对象时对单链接请求的带宽进行限制支持下载对象时对单链接请求的带宽进行限制支持设置对象生命周期 补充配置option相关代码示例优化复制对象相关代码示例优化服务端错误码的内容以及相关代码示例优化使用临时URL进行授权访问的内容及相关代码示例补充批量复制对象相关代码示例补充批量上传对象相关代码示例补充批量下载对象相关代码示例补充批量恢复对象相关代码示例Gov3.26.6支持上传对象时支持设置回调参数，并将回调结果返回给用户支持通过HeadObject接口检查指定桶中是否存在指定的对象支持获取上传对象的进度支持获取下载对象的进度支持列举并行文件系统内的对象优化创建并行文件系统的内容补充该场景的代码示例：生成在单链接限速场景里下载对象的带授权信息的URL，并下载对象补充该场景的代码示例：生成在单链接限速场景里下载指定版本对象的带授权信息的URL，并下载对象优化有关设置对象元数据相关参数BrowserJS-  不涉及补充设置、获取与删除桶归档存储对象直读策略操作指导补充恢复归档或深度归档存储对象操作指导补充设置、获取与删除桶加密配置操作指导补充设置、获取与删除对象标签操作指导补充取消分段上传任务操作指导补充复制对象操作指导补充MD5校验文件一致性的示例代码补充批量上传对象的代码示例补充批量下载对象的代码示例补充批量复制对象的代码示例PHP-  不涉及补充清理多段上传任务碎片操作指导补充创建和列举并行文件系统操作指导补充批量上传的代码示例补充批量复制的代码示例补充批量下载的代码示例补充批量恢复对象的代码示例Node.js-  不涉及补充设置、获取、删除桶归档直读策略的操作指导补充恢复归档或深度归档存储对象的操作指导补充下载对象时获取下载进度的操作指导补充文件分段上传的代码示例补充使用md5校验文件一致性的示例代码补充批量上传对象的代码示例补充批量复制代码示例补充批量下载对象的代码示例

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20k+申请，发起2200+课题，毕业超千名实习生，发放超过390万美金报酬。2026年秋季(Term 3）申请时间为8月3日 – 8月18日（23:59 UTC)，远程实习将从 9月 7 日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3100美金，约合￥20916人民币）。 今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于即日起前点击阅读全文，或到官方平台申请：https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍 KubeEdge 社区已经连续6年参与 LFX Mentorship 计划，过去已为学员提供30+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8.2k+Stars和2.3k+Fork，吸引了全球来自35+国家的120+贡献组织及1800+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。 社区地址：🌍https://github.com/kubeedge/kubeedge在 LFX Mentorship 2026秋季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象  秋季计划申请者需在2026年8月18日前在 LFX 官网[1]完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定，对 Mentee 的申请者有以下要求[2]:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026年秋季活动流程如下：Mentee 注册与项目申请：8月3日-8月18日（00:00 UTC/23:59 UTC)申请者审核期： 8月19日-9月1日（11:00 AM PDT/18:00 UTC)申请者入选通知：9月2日-9月4日实习正式开始：9月7日中期考核：10月20日（11:00 AM PDT/18:00 UTC)首次津贴支付：10月21日结项考核、实习报告提交：11月24日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：11月25日本期结束最终日期：11月27日申请者需要在8月18日前完成 Mentee 注册和项目申请，流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply 实习申请结果预计将在9月2日—9月4日通知到申请人。主线开发日期为2026年9月7日 – 11月24日，全程线上协作，无需线下参与。结项需要在2026年11月24日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题   最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍Modernize KubeEdge Controllers and Admission Webhooks课题描述：KubeEdge 当前的云端 Controller 与 Admission Webhook 使用了不同的实现和部署方式。Controller Manager 已经采用 controller-runtime Manager 和 Reconcile 模型，而 Admission 仍然作为独立命令、HTTP Server、Webhook 注册流程、Deployment 和 Service 运行。当前 Kubebuilder 和 controller-runtime 推荐将 Reconcile Controller 与 Admission Webhook Server 运行在同一个 Controller Manager 进程中，从而统一 Kubernetes Client、Scheme、Cache、生命周期、健康检查、Leader Election、Metrics、日志和证书管理。本项目旨在升级 KubeEdge 的 Go 和 Kubebuilder 相关技术栈，将 controller-runtime、controller-tools 与 KubeEdge 使用的 Kubernetes 版本对齐，把现有 Admission Handler 迁移到 controller-runtime Webhook 框架，并最终将 Controller 与 Admission 能力合并到统一的 Controller Manager 组件中。项目同时将引入自动化依赖漏洞检查和工具链版本管理，增强 KubeEdge 的依赖安全基线。预计输出件：梳理 KubeEdge 当前使用的 Go、Kubernetes、controller-runtime、controller-tools、代码生成、Controller Manager 和 Admission Webhook 实现。根据 KubeEdge 使用的 Kubernetes 版本确定合适的 Go、controller-runtime、controller-tools 和 Kubebuilder 兼容版本。提交设计提案，说明统一 Controller Manager 架构、迁移步骤、兼容策略、证书管理、异常处理和回退方案。   统一升级 go.mod、Builder 镜像、Dockerfile、Makefile、构建脚本、GitHub Actions 和贡献者文档中的 Go 版本。   升级 controller-runtime 及相关 Controller 开发依赖，并确保与 KubeEdge Kubernetes 依赖兼容。   根据需要，将现有 Controller 改造为当前 controller-runtime 推荐的 Reconcile 和 Manager 模式。   将 Admission Webhook Server 集成到 KubeEdge Controller Manager 进程中。将现有 Validating 和 Mutating Admission Handler 迁移为 controller-runtime Admission Handler，或者适用情况下使用 Kubebuilder 风格的 Validator 和 Defaulter。   通过同一个 controller-runtime Manager 统一注册 Controller 和 Webhook，并共享 Scheme、Client、Cache、Logger、健康检查和生命周期。   使用 controller-tools Marker 和声明式 Manifest 替代当前手工创建 WebhookConfiguration 的方式。   在完成功能一致性验证后，合并或移除独立 Admission Command、Deployment、Service、配置、RBAC 和证书处理逻辑。保持现有 Device、DeviceModel、Rule、RuleEndpoint、NodeUpgradeJob 和离线迁移等 Admission 能力。   为统一组件补充 Leader Election、Health、Readiness、Metrics、Graceful Shutdown 和 Webhook 就绪检查。   升级并统一  controller-gen、setup-envtes 和相关代码生成工具。  重新生成并验证 CRD、RBAC、WebhookConfiguration 和 API 生成代码。 为 Reconcile Controller 和 Admission Webhook 增加单元测试及基于 envtest 的集成测试。增加端到端测试，验证组件合并前后的 Controller 和 Admission 行为一致。 接入 govulncheck 等 Go 漏洞检查，并记录漏洞处理规则。   验证 AMD64 和 ARM64 构建链路，确保生成文件和 Vendor 依赖一致。   更新安装、升级、开发和故障排查文档。   发布技术博客或贡献者指南，介绍升级后的 KubeEdge Controller 架构。前置技能：Go; Kubernetes; KubeEdge; Kubebuilder; controller-runtime; controller-tools; Admission Webhook; CRD; GitHub Actions; Docker; Linux课题导师：Wei Hu (@WillardHu)wei.hu@daocloud.ioChuanhao Jin  (@chuanhao jin)jch995321@gmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/104f564b-8f94-436b-b52e-8915ff290ef9Github Issue：cid:link_1  ▍Enable RuntimeClass and Confidential Containers on KubeEdge课题描述： Kubernetes RuntimeClass 允许工作负载选择指定的容器运行时处理器，包括标准 OCI 运行时、Kata Containers 和机密容器运行时。目前 KubeEdge 尚未为运行在边缘节点上的工作负载提供完整的 RuntimeClass 支持，因此依赖替代运行时或更强运行时隔离能力的工作负载无法正常部署到边缘节点。本项目旨在为 KubeEdge 实现端到端 RuntimeClass 支持，并结合 Kata Containers 和 Confidential Containers 生态进行验证。学员需要研究 RuntimeClass 资源如何在 KubeEdge 云边组件之间同步、缓存和使用，并确保 Edged 能够正确解析 spec.runtimeClassName，选择对应的运行时处理器。第一阶段聚焦于使用当前支持的 KubeEdge 与 Kata Containers 环境完成 RuntimeClass 验证，识别具体缺失的集成链路。基本 RuntimeClass 流程完成后，可以在具备测试环境和社区支持的情况下，进一步使用 Intel TDX 等技术验证机密工作负载，包括远程证明以及受保护的密钥或 Secret 下发。预计输出件：研究上游 Kubernetes RuntimeClass 工作流程，识别 KubeEdge 在资源同步和运行时选择方面缺失的能力。使用可复现的 KubeEdge 和 Kata Containers 环境验证当前行为。提交设计提案，说明 RuntimeClass 同步、边缘侧缓存、运行时处理器解析、兼容性和异常处理方案。完成所需代码改造，使 RuntimeClass 资源可以从 Kubernetes 控制面同步到 KubeEdge 边缘节点。支持边缘工作负载通过 spec.runtimeClassName 指定运行时。确保 Edged 能够正确选择对应的 CRI Runtime Handler。至少使用一种替代运行时完成验证，例如 Kata Containers。正确处理 RuntimeClass 不存在、配置无效或运行时处理器不可用等情况。增加单元测试和端到端测试，覆盖 RuntimeClass 同步、运行时选择、EdgeCore 重启和云边重新连接。提供可复现的部署清单、配置文件、验证脚本、架构文档和故障排查说明。发布技术博客或用户指南，介绍如何在 KubeEdge 中运行基于 RuntimeClass 的安全工作负载。可选：在 Intel TDX 或其他受支持的机密计算平台上，使用 Confidential Containers Runtime 验证机密工作负载。可选：在 RuntimeClass 和 Confidential Containers 基础集成完成后，演示一个边缘机密 AI 推理场景。前置技能：Go; Kubernetes; KubeEdge; RuntimeClass; Containerd; Container Runtime Interface; Kata Containers; Confidential Containers; Linux; Confidential Computing 课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/ef5b6ae6-99be-42e0-aeae-897684b0e9c8Github Issue：cid:link_2 ▍Comprehensive Example Restoration for KubeEdge Ianvs: Phase IV (2026 Term 3)课题描述： Ianvs 充当着 KubeEdge SIG AI 分布式基准测试工具套件的角色。随着越来越多的贡献者参与其中，KubeEdge Ianvs 目前已拥有多达 30 个样例，且这数字仍在不断增长。然而由于AI类依赖包的快速演进和验证机制的复杂性，KubeEdge Ianvs 面临着日益增多的可用性问题。具体地，随着 Python 版本、第三方库及 Ianvs 功能快速迭代，部分历史样例可能变得过时。这也导致用户报告的 Issue 激增，亟需避免被未稳定贡献代码误损原有功能、修复与实际能力不再匹配的文档。若不进行系统干预，对边缘 AI 开发者、尤其是新入行者而言这些样例可能变得难以使用。因此，我们尝试通过全面的样例修复工作来强化 Ianvs 可用性。 预计输出件：诊断和修复多个样例中的错误，包括依赖关系清单、许可证扫描和运行时配置。文档更新，包括修订带有可复现步骤指南的教程，发布以开发人员为重点的常见故障调试演示手册。编写并上传相应的博客到KubeEdge网站。使用GitHub Actions针对多个Python版本、关键的 Ianvs/上游更新来完善CI管道测试示例，并阻止破坏已验证示例的PR。前置技能：Python; Benchmark; KubeEdge-Ianvs; AI/ML 课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comKai-Wei Chou (@ken6078)ken60786213@gmail.com 课题链接：https://mentorship.lfx.linuxfoundation.org/project/0a346d47-1eff-480c-990d-fa8bf6d9e24aGithub Issue：cid:link_3 ▍KubeEdge-Ianvs Simulation Sandbox: Environment-Isolated Execution课题描述：对于大多数分布式人工智能方案开发者而言，构建和部署大规模云边协作系统通常既复杂又繁琐。尽管 KubeEdge-Ianvs 目前提供了一个单节点算法测试器，可以使用测试数据集评估准确率指标，但对于大规模节点而言，在实际环境中测量带宽、计算能力和峰值内存等系统级指标却极其困难且成本高昂。此外，在单个共享的 Python 进程中执行所有测试用例很容易引发依赖冲突、路径污染以及致命的内存溢出 (OOM) 崩溃，尤其是在运行 LLM、VLA 和基础模型等高负载模型以及轻量级示例时。为了应对这些挑战，本项目旨在引入一种工业级分布式协作系统仿真方案，该方案采用单机上的工作节点嵌套模式，提供低成本、可扩展的测试能力、强大的环境隔离以及精确的系统级指标分析。预计输出件：恢复仿真核心功能：鉴于之前的提案，恢复并扩展 Ianvs 2022 仿真提案（Ianvs PR #35）及其实现（Ianvs PR #39，已发现 5 个以上缺陷），构建仿真控制器，将每个测试用例隔离在独立的瞬态运行时环境中，并强制执行系统级资源配额和边界控制机制，以限制边缘节点资源（CPU 和内存），从而避免依赖冲突和内存溢出 (OOM) 风险。关键组件包括：仿真控制器环境管理员：在测试用例控制器中引入仿真控制器，以在单台机器上提供工作节点嵌套的工作节点系统，模拟多节点系统。实现仿真环境管理员，以解析系统配置、检查主机环境要求（例如，内存 > 4GB），并自动构建、部署、关闭和删除仿真环境。仿真控制器仿真作业管理器：开发关键的仿真作业管理器，负责算法镜像构建（例如 Docker）、YAML 生成、作业部署/删除以及使用工作进程监控仿真结果列表。同时，部署一个使用临时运行时环境和系统资源配额（CPU 和内存）的隔离执行层，以彻底防止依赖冲突和内存溢出崩溃。使用多维指标验证集群：使用 kind + edgecore + Sedna 一体化脚本完成 KubeEdge 原生集群模拟验证。多维指标集成：将底层系统指标（CPU 利用率、峰值内存、实际运行时间）与上层算法指标对齐，并在现有的 StoryManager 排行榜中统一呈现，从而实现分布式 AI 的端到端综合性能评估。前置技能：KubeEdge; Kubernetes; Docker; Linux Kernel mechanisms; Go; Python; Benchmark; AI/ML; KubeEdge-Sedna; KubeEdge-Ianvs课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：https://mentorship.lfx.linuxfoundation.org/project/0aca7087-4985-4d22-a7c2-b8d5845e962bGithub Issue：cid:link_4如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。今年秋季，KubeEdge 社区期待在 LFX Mentorship 见到您！Reference：[1] LFX Mentorship计划官网及申报入口: https://mentorship.lfx.linuxfoundation.org/#projects_all[2] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible[3] LFX Mentorship - Program Readme: cid:link_0[4] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply

由 Linux Foundation 组织的 LFX Mentorship 计划[1]，从 2019 年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获 2w+ 申请，累计课题量 2200+，毕业实习生 1500+，发放超过 390 万美金报酬。LFX Mentorship 2026 秋季 ( Term 3 ）申请时间为8月3日 – 8月18日（23:59 UTC )，正式研发工作将从 9 月 7 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区认可的同时，完成工作还能获取报酬 (位于中国的开发者报酬为3000美金，约合20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官网申请（在校/在职符合条件均可）:🔍 https://mentorship.lfx.linuxfoundation.org/   Volcano 社区介绍  Volcano （cid:link_7）是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.9k+ Star 和 2.4K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。在大模型/AI 推理领域，Volcano Kthena 依托社区在集群拓扑感知与大规模算力调度的优势，结合 KV Cache 感知路由与 Prefill/Decode 分离等高级特性，通过算力与时延的极限优化，显著提升 GPU/NPU 资源利用率与系统吞吐，从而高效解决生产环境中 LLM 大规模部署与服务的核心挑战，助力用户释放模型推理与服务的算力潜能。期待与你在LFX Mentorship 2026 秋季计划协作开拓AI大数据、LLM大模型推理等场景应用的更多可能。  面 向 对 象 本期计划申请者需2026年8月18日前在LFX官网[1]完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下参与开源社区共建。依据官方规定，对Mentee申请者有以下要求[2]:在参加该计划时您至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 Term3（秋季） 申请及实习流程如下：Mentee注册与项目申请：8月3日-8月18日（00:00 UTC/23:59 UTC)申请者审核期： 8月19日-9月1日（18:00 UTC)申请者入选通知：9月2日-9月4日实习正式开始：9月7日中期考核：10月20日（18:00 UTC)首次津贴支付：10月21日结项评估：11月24日（18:00 UTC)最终津贴支付批准：11月25日本期结束最终日期：11月27日参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply主线开发日期为2026年9月7日-11月24日，全程线上协作，无需线下参与。结项需要在2026年11月24日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  欢迎申报 Volcano 课题  今年秋季，Volcano 社区带来以下 4 个课题，欢迎各位申请者加入：▍Volcano 通用 xPU 拓扑感知调度课题描述：当前，Volcano 主要根据 Node 上 xPU 资源的总量进行调度，但对 GPU、NPU 等加速设备之间的物理互联关系缺少感知。对于通信密集型 AI 作业，仅仅满足设备数量并不意味着能够获得合适的通信拓扑。例如，一台 16 卡 NPU 服务器可能包含两个相互独立的 8 卡 HCCS 互联域。如果一个互联域空闲 6 张卡，另一个空闲 2 张卡，那么 Node 上虽然共有 8 张空闲 NPU，却无法满足“8 张卡位于同一互联域”的调度要求。NVLink、NVSwitch 以及其他 xPU 高速互联也存在类似问题。多机训练场景还需要区分两类拓扑：普通多节点集群中，NVLink、NVSwitch 或 HCCS 仅存在于单个 Node 内，节点之间通过 InfiniBand 或 RoCE 通信；GB200 NVL72 等系统中，多个 Kubernetes Node 上的 GPU 通过机架级 NVLink 背板组成同一个跨节点高速互联域。本课题将在 Volcano 中实现通用的 xPU 拓扑感知调度能力。调度器需要在 Pod 绑定之前感知设备拓扑及其可用状态，根据作业需求选择合适的 HyperNode 或跨节点互联域、Node、节点内设备互联域以及具体设备。拓扑信息的来源与调度逻辑需要解耦。调度器通过统一接口消费标准化的拓扑信息，底层可以来自 Node Annotation、拓扑 CRD、Device Plugin 配套组件、厂商接口或 DRA ResourceSlice。课题前期可以使用 KWOK 和模拟拓扑数据完成开发及验证，不依赖真实的 NVL72 等硬件环境。预期产出：设计并实现厂商无关的 xPU 拓扑模型及拓扑信息接入接口，统一表达节点内设备互联域、跨节点高速互联域、设备状态以及与 HyperNode 的关系。实现可选的 xPU 拓扑感知调度插件，根据互联域的实际可用设备进行过滤和打分，并支持具体设备选择、Gang 级资源预留及失败回滚。将设备拓扑及其空闲、已分配、已预留和异常状态集成到 Volcano 现有调度缓存中，通过索引和增量更新控制调度开销。基于 KWOK 构建功能和性能测试，覆盖单节点多互联域、无跨节点 xPU 背板的多机作业，以及 NVL72 风格的跨节点互联场景。输出单元测试、集成或 E2E 测试、性能测试报告、使用文档及拓扑接入指南。若条件允许，可进一步对接模拟或真实 Device Plugin，但不作为课题验收的硬性要求。前置技能：熟练使用 Go，具备实际的 Kubernetes 开发经验熟悉 Kubernetes 调度器、控制器或资源管理机制具备 GPU、NPU 或其他 xPU 的使用和资源管理经验了解分布式 AI 作业、Gang 调度或设备拓扑者优先了解 Volcano、Kubernetes Device Plugin、DRA、NVLink、NVSwitch、HCCS 等技术者优先具备测试、性能分析或调度算法开发经验者优先课题导师：Zicong Chen（ @JesseStutler ）jessestutler97@gmail.comYang Wang（ @wangyang0616 ）wangyang8216@gmail.comJoão Azevedo（ @devzizu ）jazevedo960@gmail.comHajnal Mate（ @hajnalmt ）hajnalmt@gmail.com原始 Issue：cid:link_2课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/087b7172-482e-4ae8-af7a-a27f56fbe09f ▍支持 Pod 原地滚动更新功能课题描述：目前，Kthena 的 RollingUpdate 策略主要通过删除旧资源、创建新资源的方式更新工作负载。这种方式适用于任意 Pod 模板变更，但当更新内容仅为容器image时，会带来不必要的资源开销。Kubernetes 支持直接修改现有 Pod 中容器的image。更新后，Kubelet 会重新启动受影响的容器，同时保留原有 Pod 对象。本项目计划为 ModelServing 增加明确的原地滚动更新（Inplace Rolling Update）策略，并完善其安全性、服务可用性、异常恢复及状态展示等相关语义，从而降低镜像更新成本，提升模型服务升级效率。预期产出：完成原地滚动更新功能的设计提案，并在 Kthena 社区会议中进行分享；完成相关功能的代码实现；补充对应的单元测试和端到端测试；编写并完善用户使用指南。 Device Plugin，但不作为课题验收的硬性要求。前置技能：Go 语言开发；熟悉 Kubernetes 基础概念及工作负载更新机制；对云原生、容器编排或模型服务方向感兴趣；具备良好的开源协作与沟通能力。课题导师：ZhenCheng Lee（ @LiZhenCheng9527 ）lizhencheng6@huawei.comJinYu Zhou（ @FAUST-BENCHOU ）2319109590@qq.com原始 Issue：cid:link_3课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/6c797658-daa1-40d6-b24c-3bf496e75755 ▍Volcano Dashboard：Kthena 资源管理与运维可观测性课题描述：Volcano Dashboard 已支持 Job、Queue、Pod 和 PodGroup 等资源的查看与管理，但目前尚未覆盖 Volcano 推理子项目 Kthena 的相关资源。用户在管理和排查 Kthena 工作负载时，仍然需要依赖 kubectl 或其他工具，难以在统一界面中查看服务状态、路由配置、发布进度以及相关资源之间的关系。本课题将在 Volcano Dashboard 中增加对 Kthena 的支持，重点覆盖 ModelServing、ModelBooster、ModelRoute 和 ModelServer 等核心资源，并结合实际运维需求完善资源管理、状态展示和问题排查能力。除了基本的资源列表和详情页面，Dashboard 还需要清晰展示资源 Conditions、实例状态、发布进度、路由关系，以及 Kthena 资源与 Pod、PodGroup、Queue 等底层资源之间的关联。用户可以通过统一界面了解 Kthena 工作负载的整体运行情况，并快速定位服务异常、发布失败或路由配置问题。预期产出：在 Volcano Dashboard 中支持 ModelServing、ModelBooster、ModelRoute 和 ModelServer 等主要 Kthena 资源，提供与现有 Dashboard 风格一致的列表、详情和必要的管理操作。展示 Kthena 资源的 Conditions、实例状态、发布进度和路由信息，并支持在 Kthena 资源与相关 Pod、PodGroup、Queue 等对象之间快速导航。完善 Kthena 的运维和问题排查体验，通过服务健康状态、路由关系和关联资源信息，帮助用户理解工作负载当前状态并定位异常。完成所需的 Kubernetes RBAC 和部署配置调整，并补充自动化测试、用户文档和使用示例。前置技能：熟悉 TypeScript、React 和 Next.js具备 Kubernetes API 和 RBAC 的实际使用经验了解 Kubernetes CRD 及资源状态管理机制具备 Web 管理平台或可观测性功能开发经验了解 Volcano、Kthena 或 AI 推理系统者优先具备自动化测试、技术设计和开源协作经验者优先课题导师：ZhenCheng Lee（ @LiZhenCheng9527 ）lizhencheng6@huawei.comKuldeep Singh（ @de6p ）de6p97@gmail.comZicong Chen（ @JesseStutler ）jessestutler97@gmail.com原始 Issue：cid:link_1课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/b2d21cb7-4380-4375-9384-ca791e652f0d ▍构建支持 KVCache 的调度器端到端（E2E）测试套件课题描述：Kthena Router 已具备较为完善的调度器插件端到端测试框架，目前覆盖 Prefix Cache、Least Request、Least Latency、LoRA Affinity、Random 和 GPU Usage 等调度策略。KVCache 感知调度器插件虽然已经实现，但仍缺少覆盖完整运行链路的端到端测试，包括 Router、模拟后端、Tokenization、ZMQ 事件以及 Redis 等组件之间的协作。本项目计划基于现有 Router 插件测试框架，构建一套可复用的 KVCache 感知调度器 E2E 测试套件。除了验证实际路由行为外，还将提供通用的环境搭建、缓存状态注入、运行状态观测和结果断言工具，为后续新增 KVCache 调度测试场景提供基础设施支持。预期产出：在 test/e2e/router/ 目录下构建可复用的 KVCache 感知 E2E 测试套件。提供 llm-d-sim、ZMQ Bridge、Redis、缓存状态注入、请求生成和路由结果断言等共享 Fixture 与辅助工具。验证完整的数据链路：通过 ZMQ 分发 KV Cache 所有权事件，检查 Redis 中生成的映射关系，并确认 Router 在副本评分和路由决策时能够正确使用这些信息。提供可独立运行该测试套件的专用命令或 Make Target。编写相关文档，帮助贡献者快速添加新的 KVCache 感知测试场景。将测试套件集成至 CI，确保环境能够稳定、确定性地清理，并在测试失败时输出 Router、Redis、ZMQ 和后端状态等有效诊断信息。前置技能：GoKubernetes基于 Kind 的 E2E 测试RedisZMQ可观测性与指标监控分布式系统调试课题导师：Jinyu Zhou（ GitHub:@FAUST-BENCHOU ; LFX ID：@benchou8 ）2319109590@qq.comJprakash（ GitHub:@katara-Jayprakash LFX ID：@lfxkatara1 ）katarajayprakash@icloud.com原始 Issue：cid:link_4 课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/16e5821d-2ae3-4145-a729-1b0c755b613b  更多Volcano课题，请访问LFX Mentorship官网；对课题有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。附：相关指引链接[1] LFX Mentorship计划官网及申报入口: https://mentorship.lfx.linuxfoundation.org/#projects_all[2] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible[3] LFX Mentorship - Program Readme: cid:link_0[4] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply[5] Volcano GitHub: cid:link_5[6] Volcano/Kthena GitHub: cid:link_6关注容器魔方，获取更多前沿资讯

导读：将一张昇腾 NPU 按算力和显存进行细粒度切分，让空闲算力在多个模型之间弹性共享，空闲时充分利用，竞争时各得其所。本文介绍华为云云容器引擎 CCE 如何通过 FlexNPU 实现 NPU 算力共享，覆盖核心架构、调度策略、隔离机制、共享效果验证及高校教学落地实践。 ▍一、为什么需要 NPU 算力共享整卡分配与模型真实需求不匹配Kubernetes 中传统 NPU 资源通常按整卡申请。一个模型即使仅需整卡 20%～30% 的算力，也必须独占一张物理卡。两张卡均未跑满，但剩余算力难以分配给其他 Pod。对于小参数模型、开发调试、低并发在线服务及教学实验，这种资源浪费尤为突出。简单共享难以避免相互干扰若直接让多个进程共享同一张 NPU 而缺乏资源控制，当某一模型请求突增时，将占用更多执行资源，导致同卡其他模型受到干扰。此类"邻居干扰"使无约束共享方案难以满足多业务共存的诉求。Kubernetes 需要理解算力与显存传统 Device Plugin 仅告知调度器"该节点有 8 张 NPU"。在算力共享场景中，调度器还需掌握：每张卡剩余多少可保障算力每张卡还有多少可用显存当前已创建多少共享实例新实例应放置于哪张物理卡应优先集中放置还是分散放置因此，FlexNPU 不仅是节点侧的设备代理，更需要与 Kubernetes 及 Volcano 调度体系深度协同。 ▍二、CCE FlexNPU 核心方案FlexNPU 面向昇腾硬件生态设计，采用 Client-Server 架构将应用发起的 NPU API 调用与物理设备执行解耦。业务容器不再直接持有 /dev/davinciX 等物理设备，而是通过容器内的 FlexNPU Client 发起调用，由宿主机侧的 aclserver 访问真实 NPU。核心组件包括 flexnpu-device-plugin、flexnpu-runtime、flexnpu-daemon 和容器侧 flexnpu-client，各组件通过共享内存或轻量网络链路完成请求转发。▲ CCE FlexNPU 整体架构 整体调用流程如下：当前，FlexNPU 支持将一张昇腾 910B 细粒度切分为多个 NPU 共享实例，关键规格如下：指标规格算力最小切分比例1%，步长 1%显存最小分配单位128 MiB单卡最大实例数32单机最大实例数128FlexNPU 对算力并非简单的静态硬切分，而是保障下限、弹性共享——设备存在空闲算力时，业务可使用超过申请值的算力；多个业务同时繁忙时，保障每个实例获得约定的算力份额，避免过载业务影响同卡其他模型。1. Device Plugin：将 NPU 变为可声明资源flexnpu-device-plugin 负责将算力与显存抽象为两种 Kubernetes 扩展资源：资源名称含义volcano.sh/flexnpu-core.percentage算力保障比例（%）volcano.sh/flexnpu-memory.128mi显存容量，以 128 MiB 为单位资源申请示例：resources: requests: volcano.sh/flexnpu-core.percentage: "50" volcano.sh/flexnpu-memory.128mi: "300" limits: volcano.sh/flexnpu-core.percentage: "50" volcano.sh/flexnpu-memory.128mi: "300"其中 flexnpu-core.percentage: "50" 表示申请 50% 的算力保障；flexnpu-memory.128mi: "300" 表示申请 300 × 128 MiB = 37.5 GiB 显存。用户由此可根据模型真实需求精确申请资源，而非只能声明"一张 NPU"。2. Volcano 调度：算力、显存与实例数的多维约束CCE Volcano 调度器通过 flexnpuaffinity 插件参与 FlexNPU 资源放置，配置示例如下： - name: flexnpuaffinity arguments: scheduleMode: binpackCCE Volcano 插件提供 binpack 和 spread 两种调度方式：调度方式策略适用场景binpack优先填充已使用的物理卡，保留完整物理卡提升资源利用率spread将负载分散到不同物理卡或节点均衡负载、降低单卡压力以 binpack 为例，调度逻辑为：调度过程中，插件需同时校验以下约束：约束条件说明Pod 申请的算力保障 ≤ 物理卡剩余可分配算力算力维度Pod 申请的显存 ≤ 物理卡剩余显存显存维度单卡实例数 < 32实例槽位单机实例总数 < 128实例槽位设备型号 = Ascend 910B硬件兼容这是一种算力、显存与实例槽位共同参与的多维资源调度，而非简单统计物理卡数量。3. Runtime：容器启动阶段透明注入flexnpu-runtime 工作于 OCI 容器创建链路中。Pod 启动时，它将共享实例所需的运行环境注入业务容器：FlexNPU Client 动态库client.conf 等通信配置共享内存目录共享设备相关配置业务容器不直接挂载真实物理 NPU，真正持有并访问物理设备的是宿主机侧的 aclserver。此举将物理设备控制权保留在宿主机侧，降低业务容器直接操作设备、影响同卡其他实例的风险。4. Client 与 aclserver：API 调用与物理执行解耦FlexNPU Client 以动态链接库形式存在于业务容器内部。当 PyTorch、vLLM 等上层框架调用 aclInit、aclrtMalloc、aclrtMemcpy、aclrtCreateStream 等接口时，请求首先由 FlexNPU Client 接管，Client 将调用类型、参数、虚拟句柄及数据描述传递给宿主机侧的 aclserver，由后者调用真实 Ascend Runtime 完成执行。AI 框架和模型代码无需针对算力共享场景重新开发，通过动态库透明接管底层硬件 API，实现上层应用零侵入。5. 双链路通信降低代理开销FlexNPU 支持两类通信路径：链路类型协议用途TAP 链路TCP/IP实例注册、控制指令、状态交互、轻量参数传递Shared Memory 链路共享内存 (/dev/shm)高频数据交互，Client 与执行端映射同一块共享内存区域相比让大块数据反复经过 Socket 缓冲区，共享内存能够减少内核协议栈处理和进程间数据复制，显著降低代理开销。 ▍三、算力共享的关键：空闲可借，竞争有保FlexNPU 的资源策略并非将一张卡静态切分为若干互不流动的小块。假设同一张 NPU 上部署两个模型：模型 A 申请 25% 算力，模型 B 申请 75% 算力。此处的比例表达的是竞争状态下的算力保障。场景一：仅模型 A 有负载模型 B 当前无任务，卡上存在大量空闲算力。FlexNPU 不会将模型 A 限制在 25%，模型 A 可使用设备上的空闲计算能力，实际使用量最高可达当前可用的整卡算力。因此，较小的资源声明不会令单独运行的模型被限制在少量资源内。场景二：模型 A、B 同时繁忙两个模型均产生大量计算任务时，系统进入资源竞争状态：模型 A：至少获得约定的 25%模型 B：至少获得约定的 75%模型 A 即使持续过载，也无法明显侵占模型 B 的保障份额。这套策略可概括为：空闲可借、竞争归还、保障下限。与固定硬切分相比，避免了实例空闲时资源无法利用的问题；与无约束共享相比，又能在竞争时保护不同业务的算力份额。部署策略空闲资源利用率竞争时算力保障整卡独占低强静态硬切分中强无约束共享高弱FlexNPU 保障型共享高强 ▍四、显存隔离与算力共享的语义差异显存和算力是两种性质不同的资源，需区别对待。显存是容量型资源。 当一个实例申请 32768 MiB 显存时：32768 MiB ÷ 128 MiB = 256Pod 中配置为：volcano.sh/flexnpu-memory.128mi:"256"该额度约束实例可使用的显存容量上限，一个实例的异常显存申请不会侵占其他实例已分配的显存空间。算力是可共享的执行资源。 算力随负载动态流动：状态行为无竞争使用自身保障份额 + 空闲算力有竞争恢复各实例的最低保障因此，FlexNPU 同时实现了：显存容量隔离、算力下限保障、空闲算力弹性复用、同卡业务间算力隔离。 ▍五、效果验证：同卡双模型共享推理实测为验证 FlexNPU 的算力共享与隔离效果，在同一张昇腾 910B 上部署两个模型：模型算力保障显存DeepSeek-R1-Distill-Llama-8B25%32768 MiBQwen2-VL-2B-Instruct75%32768 MiB操作演示：基于华为云CCE进行同卡双模型推理延迟实测 测试方法：持续向 Qwen2-VL-2B-Instruct 发送稳定请求对 DeepSeek-R1-Distill-Llama-8B 逐步增加请求压力同时观察两个模型的端到端推理延迟测试结论：随着 DeepSeek-R1-Distill-Llama-8B 请求压力增加，其自身请求开始排队，推理延迟逐渐上升Qwen2-VL-2B-Instruct 的延迟曲线保持平稳，未随 DeepSeek 的过载同步抬升DeepSeek 的过载未明显侵占 Qwen 已获得的算力保障这表明 FlexNPU 在共享物理资源的同时维持了实例间的保障边界。当 Qwen 当前无负载时，DeepSeek 可使用卡上的空闲算力；当 Qwen 恢复请求后，系统重新保障其 75% 的约定份额。FlexNPU 由此同时实现了：低负载时空闲算力充分流动，高负载时各业务各得其所。 ▍六、高校人工智能教学落地：一台服务器支撑 128 名学生同时在线FlexNPU 已在某高校人工智能教学场景成功落地。在传统整卡模式下，每名学生的实验环境需独占一张 NPU。同时支撑 128 名学生在线开展模型推理、AI 框架实践和课程实验，所需资源为：128 名学生 ÷ 每台 8 张 910B = 16 台 8 卡服务器此方案存在明显问题：单个学生实验通常无法持续跑满整张 910B大量 NPU 在课程等待、代码编辑和低负载推理阶段处于空闲状态实验资源成本高，扩容周期长学生环境之间仍需独立管理和隔离引入 FlexNPU 后，一台配备 8 张 910B 的服务器可切分出最多 128 个 FlexNPU 实例：一名学生 → 一个独立 Pod → 一个 FlexNPU 实例 → 独立算力保障 + 独立显存额度资源规模对比：方案服务器数量可支撑学生数传统整卡独占16 台 × 8 卡 910B128 名FlexNPU 方案1 台 × 8 卡 910B128 名服务器数量降至传统方案的 1/16。教学任务具有典型的间歇性特征：编辑代码 → 等待 → 启动模型 → 短时推理 → 查看结果。并非所有学生都会在同一时刻持续占用设备。FlexNPU 在保障各学生基本算力的同时，将暂时空闲的 NPU 能力提供给正在执行实验的实例，契合教学负载的真实使用规律。同时，每个学生的实验运行于独立 Pod 和共享实例中：显存额度相互隔离算力竞争时有最低保障单个学生任务异常或过载不会无限挤占其他学生的算力教师可通过 Kubernetes 统一创建、回收和管理实验环境对于高校而言，此模式不仅降低了硬件投入，也使课程资源能够按班级规模快速交付，提升实验环境的可管理性和并发能力。 ▍七、典型适用场景场景说明多小模型同卡部署不同模型分别申请所需显存和算力保障，通过 binpack 集中到同一张卡，释放更多完整 NPU在线业务与低优先级任务混部在线服务获得明确算力保障，离线任务使用设备空闲能力；低优先级任务过载时不明显影响在线服务性能AI 开发和测试环境为开发者按需分配小规格共享 NPU，避免调试任务长期占用整卡 ▍八、总结传统整卡分配模式难以适应小模型推理、开发测试、人工智能教学等细粒度资源需求；无约束共享虽可提高利用率，却易产生相互干扰。华为云 CCE FlexNPU 将算力共享、显存隔离与云原生调度统一于同一套体系，其核心价值在于：细粒度切分：算力最小支持 1%，显存以 128 MiB 为单位弹性共享：无竞争时，实例可使用更多空闲算力算力保障：资源竞争时，保障各实例的算力份额显存隔离：防止实例越界占用其他业务的显存云原生调度：通过 Device Plugin 与 Volcano 实现声明式申请与自动放置透明接入：Client-Server 架构，上层模型代码无需修改规模化交付：单卡最多 32 个实例，单机最多 128 个实例在某高校人工智能教学项目中，一台 8 卡 910B 服务器通过 FlexNPU 支撑了 128 名学生同时在线，而传统整卡方案实现相同规模需 16 台 8 卡服务器。FlexNPU 的价值不仅在于将一张物理卡切分为更多实例，更在于：让多个业务共享同一张 NPU 时，空闲算力能够充分流动，资源竞争时又能守住各自的算力份额。 参考资料[1] 华为云 CCE 官方文档: cid:link_0[2] Volcano 调度器项目主页: https://volcano.sh/关注魔方公众号，获取更多前沿资讯

Kthena[1] 是面向高扩展性模型推理的云原生 AI 服务平台。它依托 Volcano[2]在集群拓扑感知与大规模算力调度的优势，结合 KV Cache 感知路由与 Prefill/Decode 分离等高级特性，显著提升 GPU/NPU 资源利用率与系统吞吐，实现算力与时延的极限优化，高效解决生产环境中 LLM 大规模部署与服务的核心挑战，全面释放模型推理与服务的算力潜能。Kthena v1.0.0 现已正式发布。这是 Kthena 在 Kubernetes 原生大模型推理领域迈出的重要一步。本次发布全面聚焦生产就绪能力：提升 Gateway API 路由准确性；为预填充/解码（P/D）分离工作负载提供原生的角色级自动扩缩容，大幅提升资源利用率；提供更安全的角色级滚动更新，保障服务发布零中断；增强Router调度性能；能为多轮对话进行会话加速；通过 Prometheus 指标和示例仪表盘提供更丰富的缓存感知路由可观测性；进一步完善 CLI 使用体验。同时，Kthena v1.0.0 对 autoscaler API 进行了重要整合，正式移除AutoscalingPolicyBinding ，目标配置现在通过 homogeneousTarget、heterogeneousTarget 和 disaggregatedTarget 直接定义在 AutoscalingPolicy 中，带来更纯粹易用的一站式声明配置。  Kthena v1.0.0 版本亮点 ▍核心特性概览AutoscalingPolicy 整合与 P/D 协同式分离扩缩容： 移除 AutoscalingPolicyBinding，将自动扩缩容目标配置统一整合到 AutoscalingPolicy 中；新增的 disaggregatedTarget 支持Perfill/Decode工作负载的角色级协同扩缩容。每个角色均可根据自身指标独立扩缩容，同时通过比例约束，将 P/D 副本比例维持在合理范围内。面向多轮对话的会话加速： Router可以优先处理近期已完成会话的后续请求，从而在高并发对话场景下提高 KV-Cache的命中率。路由调度与可观测性增强： 通过 Pod 级在途请求跟踪、基于 Redis 的多Router状态同步、可配置的 Pod 指标抓取，以及缓存感知 Prometheus 指标，提高调度准确性和运维可观测性。角色级滚动更新可用性控制： 进一步增强 RoleRollingUpdate，现在每个角色都可以通过 maxUnavailable 独立控制升级节奏。Gateway API 与 HTTPRoute 行为修正： Kthena Router现在能够遵循 HTTPRoute 主机名配置，在后端选择和 URL 重写过程中始终使用同一条已匹配的路由规则，并修正 PathPrefix 语义，同时遵循 Gateway 监听器的 allowedRoutes 配置。CLI 与 OpenAI 兼容 API 增强： CLI 提供更丰富的状态信息，并新增对 ModelRoute 和 ModelServer 的支持；Router 新增兼容 OpenAI API 的接口。▍AutoscalingPolicy 整合与 P/D 协同式分离扩缩容Kthena v1.0.0 引入了一套更简洁、更强大的自动扩缩容 API。用户现在可以在单个 AutoscalingPolicy 资源中统一配置扩缩容目标、指标采集方式和扩缩容边界。新的 disaggregatedTarget 模式专为基于Role的工作负载部署提供 P/D 协同自动扩缩容，尤其适用于PD分离部署。Prefill和Decode可以分别依据自身指标作出扩缩容决策，同时由自动扩缩容器应用共享约束，使两侧能够协调扩缩，而不会各自变化并逐渐偏离合理比例。每个角色都可以独立定义副本范围、指标和指标来源；运维人员还可以配置 ratioConstraint，将 P/D 副本比例维持在合理区间内。disaggregatedTarget 配置示例：spec:  disaggregatedTarget:    targetRef:      apiVersion: workload.serving.volcano.sh/v1alpha1      kind: ModelServing      name: vllm-qwen-pd-ms    roles:      prefill:        minReplicas: 1        maxReplicas: 8        metrics:          - name: prefill_waiting_requests            targetValue: "1"        metricSources:          prefill_waiting_requests:            prometheus:              serverURL: http://kube-prometheus-stack-prometheus.test.svc.cluster.local:9090              query: sum(vllm:num_requests_waiting{namespace="autoscale-demo", service="vllm-prefill"})      decode:        minReplicas: 1        maxReplicas: 16        metrics:          - name: decode_gpu_cache_usage            targetValue: "0.75"        metricSources:          decode_gpu_cache_usage:            prometheus:              serverURL: http://kube-prometheus-stack-prometheus.test.svc.cluster.local:9090              query: sum(vllm:gpu_cache_usage_perc{namespace="autoscale-demo", service="vllm-decode"})    ratioConstraint:      numeratorRole: prefill      denominatorRole: decode      minRatio: "0.25"      maxRatio: "1"相关变更：Issue： Proposal of merge autoscalingPolicybingding into autoscalingPolicy  #1172[3]PR：merge autoscalingpolicybinding to autoscalingpolicy #1203[4]Implementation of PD disaggregation auto-scaler #1258[5]贡献者：@LiZhenCheng9527 ▍面向多轮对话工作负载的会话加速Kthena v1.0.0 新增会话加速能力，旨在优化多轮对话、智能体工作流和 RAG 链等后续请求依赖先前响应的场景。在这些工作负载中，后续请求通常会复用较长的公共前缀。如果请求在无关流量之后等待过久，对应后端中的 KV-Cache 可能已被淘汰，进而增加 TTFT。会话加速允许 Router 跟踪近期完成的会话，并在等待队列中优先处理这些会话的后续请求。使用会话加速功能，相较于 llm-d router default 延迟能够降低 20%。该机制与用户公平性调度相互独立，并提供专用的会话加速配置，包括会话请求头选择、等待请求准入上限，以及用于高级缓存命中优化的可选宽限期。此功能旨在提高并发多轮请求下的缓存复用机会，但本身并不进行 KV-Cache 感知调度。若要最大限度发挥 KV-Cache 优势，运维人员还应确保同时使用会话加速和 KV-Cache 感知调度。Helm 配置示例：networking:  kthenaRouter:    sessionBoost:      enabled: true      header: X-Session-ID      maxSessions: 4096      inflightPerPod: 16      gracePeriod: 0s相关变更：Issue：Improve multi-round conversation case #1190[6]PR：session boost queue to optimize multi conversation scenario #1183[7]贡献者：@YaoZengzeng、@hzxuzhonghu、@FAUST-BENCHOU、@LiZhenCheng9527 ▍更智能的路由调度与缓存感知可观测性Router现在可以更好的利用的负载信号进行调度决策。Kthena 能够跟踪每个 Pod 的排队的请求数量，并通过 Redis 在多个Router副本之间同步这些计数器，使 least-request 插件能够依据实时全局负载作出决策，而不再局限于当前Router的本地状态。缓存感知调度的可观测性也得到了显著增强。prefix-cache 和 kvcache-aware 评分插件现在通过Router现有的 /metrics 端点导出 Prometheus 指标，将以往仅记录在 klog 中的信息转化为可查询、带模型标签的时间序列，便于开展压力测试和进行请求调度。为准确衡量缓存效果，Kthena 使用匹配比例直方图取代简单的命中/未命中计数器。kthena_router_prefix_cache_match_ratio 和 kthena_router_kvcache_aware_match_ratio 用于表示提示词中已存在于最佳匹配候选 Pod 上的数据块占比，其中 0 表示完全未命中。运维人员既可以通过 le="0.0" 桶推导缓存命中率，也可以直观了解Cache的实际复用程度。相关变更：Issue：Observability for prefix-cache and kvcache-aware Score Plugins[8]PR：feat(router): add per-pod in-flight request tracking with Redis sync #962[9]Add SGLang tokenizer support for KV-cache-aware scheduling #997[10]router: add observability metrics for prefix-cache and kvcache-aware score plugins #1194[11]feat(router): make pod metrics update interval configurable #1151[12]perf(router): cache parsed prompt to avoid redundant ParsePrompt call #1123[13]fix: parallelize pod metrics scraping loop with bounded concurrency #1255[14]贡献者：@hzxuzhonghu、@blenbot、@kube-gopher、@rajnish-jais、@nabrahma ▍角色级滚动更新可用性控制Kthena v0.4.0 引入了 RoleRollingUpdate，但在角色更新期间，系统会一次性删除 ServingGroup 中某个角色的全部旧副本。只有一个 servingGroup 的时候，会导致服务在角色级发布期间暂时不可用。Kthena v1.0.0 为 RoleRollingUpdate 新增角色级 maxUnavailable 支持。运维人员现在可以使用绝对数量或百分比，为每个角色独立控制更新步长。角色级滚动更新由此具备与 ServingGroup 级更新类似的可用性控制能力。角色级发布配置示例：spec:  rolloutStrategy:    type: RoleRollingUpdate  template:    roles:    - name: prefill      replicas: 2      maxUnavailable: 1      # entryTemplate and workerTemplate omitted    - name: decode      replicas: 4      maxUnavailable: 25%      # entryTemplate and workerTemplate omitted相关变更：Issue：Control the number of unavailable Role replicas in RoleRollingUpdate #1188[15]PR：Role rollingupdate support maxUnavailable settings #1239[16]贡献者：@hzxuzhonghu、@LiZhenCheng9527 ▍Gateway API 与 HTTPRoute 行为修正Kthena Router现在能够更准确地处理 Gateway API 流量。Router会遵循 HTTPRoute.spec.hostnames，在后端选择和 URL 重写过滤器处理过程中始终使用同一条已匹配的 HTTPRoute 规则，并在同一路由内优先选择更具体的路径规则。由此可以避免请求误用其他链路中的后端。本次发布还修正了 Gateway API 的 PathPrefix 匹配语义，并确保Router仅在满足 Gateway 监听器 allowedRoutes 约束时接纳 HTTPRoute。相关变更：PR：feat: honor HTTPRoute hostnames and matched rule selection #1174[17]Fix HTTPRoute PathPrefix matching #1119[18]fix(router): respect Gateway allowedRoutes #1263[19]贡献者：@zhy76、@Monti-27、@avinxshKD ▍CLI 与 OpenAI 兼容 API 增强Kthena CLI 现在能够展示更实用的状态信息，并支持更多资源类型：kthena get model-servings 新增 READY 和 STATUS 列。kthena get model-boosters 新增 STATUS 列。新增对 kthena get model-routes 和 kthena get model-servers 的支持。新增对 kthena describe model-route 和 kthena describe model-server 的支持。Router还新增了兼容 OpenAI API 的 GET /v1/models 端点，以标准列表响应格式返回当前可用的模型名称。相关变更：PR：feat: add STATUS and READY columns to kthena get output #978[20]feat: add CLI support for ModelRoute and ModelServer resources #981[21]feat: support /v1/models endpoint  #996[22]贡献者：@anirudh240、@madmecodes ▍其他功能增强通过设置 scale 子资源标签选择器，为 ModelServing 新增 KEDA/HPA 兼容能力。#839为 controller-manager 新增调试端口，可用于查看缓存中的 ServingGroup 和 Role 配置。#900新增 SGLang Dynamo 模拟器测试覆盖与 SGLang 推理模拟器集成。#920、#1231为Router新增 pprof 端点支持。#1057在 Helm Chart 中新增 controller-manager 的 debugPort 配置。#1032改进 ModelBooster 的 GPU 与离线环境支持。#972、#1141、#1146、#945新增 GPU 使用率插件 E2E 测试覆盖。#1199更新快速入门文档，并推荐用户优先从 ModelServing 开始使用 Kthena。#1260新增 DeepSeek-v4 模型服务示例。#936、#937新增 KV 缓存感知调度器插件文档。#910更加具体版本信息可以查看 Kthena v1.0.0 的 Release Note：cid:link_1Kthena 诚挚邀请广大开发者、运维人员和 AI 基础设施团队体验 Kthena v1.0.0，并与我们共同塑造下一代云原生大模型推理平台。 相关链接[1] Kthena v1.0.0: https://kthena.volcano.sh/[2] Volcano: https://volcano.sh/[3] Proposal of merge autoscalingPolicybingding into autoscalingPolicy #1172: cid:link_4[4] merge autoscalingpolicybinding to autoscalingpolicy #1203: cid:link_5[5] Implementation of PD disaggregation auto-scaler #1258: cid:link_6[6] Improve multi-round conversation case #1190: cid:link_2[7] session boost queue to optimize multi conversation scenario #1183: cid:link_7[8] Observability for prefix-cache and kvcache-aware Score Plugins: cid:link_0[9] feat(router): add per-pod in-flight request tracking with Redis sync #962: cid:link_16[10] Add SGLang tokenizer support for KV-cache-aware scheduling #997: cid:link_17[11] router: add observability metrics for prefix-cache and kvcache-aware score plugins #1194: cid:link_8[12] feat(router): make pod metrics update interval configurable #1151: cid:link_9[13] perf(router): cache parsed prompt to avoid redundant ParsePrompt call #1123: cid:link_10[14] fix: parallelize pod metrics scraping loop with bounded concurrency #1255: cid:link_11[15] Control the number of unavailable Role replicas in RoleRollingUpdate #1188: cid:link_3[16] Role rollingupdate support maxUnavailable settings #1239: cid:link_12[17] feat: honor HTTPRoute hostnames and matched rule selection #1174: cid:link_13[18] Fix HTTPRoute PathPrefix matching #1119: cid:link_14[19] fix(router): respect Gateway allowedRoutes #1263: cid:link_15[20] feat: add STATUS and READY columns to kthena get output #978: cid:link_18[21] feat: add CLI support for ModelRoute and ModelServer resources #981: cid:link_19[22] feat: support /v1/models endpoint #996: cid:link_20 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入“Kthena” 技术交流群