由 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” 技术交流群

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。 ▍为什么需要负载感知调度1. Pod Request 值与真实资源使用错配业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。2. 监控数据更新和调度决策之间存在时间差短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。3. 批量下发和滚动升级会放大偏差单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。▍CCE 负载感知调度架构核心方案在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。▲ CCE Volcano 负载感知调度架构1. 引入真实负载CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。2. 引入影子负载对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。3. 引入 Pod 资源预估对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。4. 把这些信息接入调度流程在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低▍关键实现要点1. 影子负载缓存解决监控滞后问题影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。2. Pod 资源预估公式对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request） × burst_ratio)× applied_risk_factor变量含义request/ limitPod 声明的 Request / Limit 值request_ratioRequest 部分的权重，默认 0.7burst_ratio突发量（limit − request）部分的权重，默认 0applied_risk_factor动态风险系数：当节点综合水位 < risk_threshold 时取 1；≥ risk_threshold 时取 risk_factor（默认 1.2）3. 高水位风险保护让调度更保守当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。变量含义risk_threshold触发风险系数的节点综合水位线，默认60%。risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数，默认1.2。4. 预估值回滚一致性CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。5. 支持业务化调优Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。下面是一个配置示例：actions: "enqueue, allocate, backfill"tiers: - plugins: - name: usage enablePredicate: false arguments: usage.weight: 5 cpu.weight: 1 memory.weight: 1 thresholds: cpu: 80 mem: 80 estimator: request_ratio: 0.7 burst_ratio: 0 risk_threshold: 0.6 risk_factor: 1.2 be_cpu: 250m be_mem: 200Mimetrics: type: prometheus address: http://prometheus:9090 interval: 30s参数说明参数含义默认值enablePredicate真实负载阈值生效方式。true（默认）= 硬约束，达阈值后该节点不再调度新任务；false = 软约束，达阈值后新任务优先调度到未达阈值节点，但该节点仍允许调度。本示例设为 false 以演示软约束下的打分效果。trueusage.weightUsage 插件在 NodeOrder 阶段对节点打分的权重。1cpu.weight / memory.weight增大对应资源种类的均衡权重。1 / 1thresholds.cpu/ thresholds.mem节点真实利用率阈值，超过后按 enablePredicate 的约束方式调度新工作负载（已运行工作负载不受影响，需配合 enablePredicate 使用）。80 / 80request_ratioRequest 占 Pod 预估值的权重。0.7burst_ratio突发量（Limit − Request）占 Pod 预估值的权重。0risk_threshold触发风险系数的节点综合水位线。0.6risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数。1.2be_cpu / be_memBestEffort Pod 的默认 CPU / 内存估算值。250m / 200Mi▍效果验证下面将介绍如何在华为云CCE集群上验证这个特性的效果。在华为云 CCE 集群使用 Volcano 负载感知调度能力1. 开启负载感知调度关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：cid:link_22. 环境准备CCE集群环境信息：2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。3. 验证调度效果环境现状通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。执行操作下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；在 Deployment 稳定运行后，进行两次滚动升级操作。预期结果集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：集群中每个节点的真实压力；同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。实际结果批量下发一批新负载后的结果。第一次滚动升级后的调度结果：第二次滚动升级后的调度结果：可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。▍演进方向Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本▍总结负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。 参考资料CCE Volcano 负载感知调度官方文档：cid:link_2Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/ 关注魔方公众号，获取更多前沿资讯 

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。▍为什么需要负载感知调度1. Pod Request 值与真实资源使用错配业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。2. 监控数据更新和调度决策之间存在时间差短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。3. 批量下发和滚动升级会放大偏差单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。▍CCE 负载感知调度架构核心方案在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。▲ CCE Volcano 负载感知调度架构1. 引入真实负载CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。2. 引入影子负载对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。3. 引入 Pod 资源预估对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。4. 把这些信息接入调度流程在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低▍关键实现要点1. 影子负载缓存解决监控滞后问题影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。2. Pod 资源预估公式对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request × burst_ratio)× applied_risk_factor变量含义request/ limitPod 声明的 Request / Limit 值request_ratioRequest 部分的权重，默认 0.7burst_ratio突发量（limit − request）部分的权重，默认 0applied_risk_factor动态风险系数：当节点综合水位 < risk_threshold 时取 1；≥ risk_threshold 时取 risk_factor（默认 1.2）3. 高水位风险保护让调度更保守当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。变量含义risk_threshold触发风险系数的节点综合水位线，默认60%。risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数，默认1.2。4. 预估值回滚一致性CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。5. 支持业务化调优Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。下面是一个配置示例：actions: "enqueue, allocate, backfill"tiers: - plugins: - name: usage enablePredicate: false arguments: usage.weight: 5 cpu.weight: 1 memory.weight: 1 thresholds: cpu: 80 mem: 80 estimator: request_ratio: 0.7 burst_ratio: 0 risk_threshold: 0.6 risk_factor: 1.2 be_cpu: 250m be_mem: 200Mimetrics: type: prometheus address: http://prometheus:9090 interval: 30s参数说明参数含义默认值enablePredicate真实负载阈值生效方式。true（默认）= 硬约束，达阈值后该节点不再调度新任务；false = 软约束，达阈值后新任务优先调度到未达阈值节点，但该节点仍允许调度。本示例设为 false 以演示软约束下的打分效果。trueusage.weightUsage 插件在 NodeOrder 阶段对节点打分的权重。1cpu.weight / memory.weight增大对应资源种类的均衡权重。1 / 1thresholds.cpu/ thresholds.mem节点真实利用率阈值，超过后按 enablePredicate 的约束方式调度新工作负载（已运行工作负载不受影响，需配合 enablePredicate 使用）。80 / 80request_ratioRequest 占 Pod 预估值的权重。0.7burst_ratio突发量（Limit − Request）占 Pod 预估值的权重。0risk_threshold触发风险系数的节点综合水位线。0.6risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数。1.2be_cpu / be_memBestEffort Pod 的默认 CPU / 内存估算值。250m / 200Mi▍效果验证下面将介绍如何在华为云CCE集群上验证这个特性的效果。在华为云 CCE 集群使用 Volcano 负载感知调度能力1. 开启负载感知调度关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：cid:link_12. 环境准备CCE集群环境信息：2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。3. 验证调度效果环境现状通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。执行操作下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；在 Deployment 稳定运行后，进行两次滚动升级操作。预期结果集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：集群中每个节点的真实压力；同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。实际结果批量下发一批新负载后的结果。第一次滚动升级后的调度结果：第二次滚动升级后的调度结果：可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。▍演进方向Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本▍总结负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。 参考资料CCE Volcano 负载感知调度官方文档：cid:link_1Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入CCE技术交流群

| 核心变化：从“仅支持并行文件系统”到“同时支持对象桶&并行文件系统”对于许多开发者而言，obsfs 一直是连接本地文件系统与华为云 OBS的关键工具，但在过去，其“不支持挂载对象存储桶”的限制，让不少习惯使用标准对象存储（OBS Bucket）的开发者感到困扰，不得不在数据访问方式上做出妥协。近期，华为云 OBS 服务对 obsfs 工具进行了重大升级，正式支持将标准的对象存储桶挂载至本地文件系统。这一改变，意味着开发者现在可以像访问本地目录一样，直接操作对象存储桶中的海量数据，为 AI 训练、大数据分析等场景提供了全新的存储访问路径。这一变化最直接的影响是：覆盖更广的使用场景：你可以直接对项目中已有的、正在使用的对象桶进行操作，无需为了使用 obsfs 而额外创建或迁移数据到并行文件系统。降低使用门槛：使得更多开发者可以零成本地尝试用本地文件系统的方式管理云上对象存储。| obsfs 对象桶挂载：能解决什么问题？简单来说，obsfs 是一款基于 FUSE 的文件系统工具，它的核心价值在于零代码改造。无论是日志收集脚本、数据处理任务，还是传统的 Web 应用，都无需修改任何文件读写逻辑，就能将数据持久化到 OBS。新能力带来的典型适用场景包括：日志、归档数据的自动上传：将本地日志目录挂载为 OBS 桶，新产生的日志文件自动进入云存储。数据分析与处理的输入输出：在 Spark、Hadoop 等计算任务中，直接将 OBS 作为数据源和结果存储池。遗留系统的存储云化：对于难以改造的老旧应用，通过挂载方式无缝将数据迁移至 OBS。不过需要了解的是，由于对象桶本身的对象语义限制（不支持追加写、随机写），obsfs 通过 FUSE 层模拟了文件操作。任何“修改”在后台实际是“新对象覆盖旧对象”的适配行为。因此，它更适用于顺序读写的场景，而非高并发、小文件频繁读写的数据库类应用。| 实战：三步挂载，体验新能力如何快速体验这个新能力？以下是将一个 OBS 对象桶挂载到本地的具体操作步骤。1. 获取与安装 obsfsobsfs 支持直接下载和编译两种方式。详细步骤参考官网：方式一：下载并安装obsfs方式二：通过编译生成obsfs2. 初始化访问密钥创建一个密钥文件，用于存放你的 OBS 访问密钥（AK/SK），并设置权限为 600 以确保安全。初始化访问密钥3. 执行挂载命令挂载命令格式：./obsfs obs桶名 本地挂载目录 -o url=区域终端节点地址 -o passwd_file=密钥文件路径 -o bucket_type=object -o multipart_size=128 -o 其他挂载参数假设你有一个名为 my-obs-bucket 的 OBS 对象桶，想挂载到本地 /mnt/obs 目录。执行以下命令即可：./obsfs my-obs-bucket /mnt/obs -o url=obs.cn-south-1.myhuaweicloud.com -o passwd_file=/etc/passwd-obsfs -o bucket_type=object注意这里的关键变化：-o bucket_type=object 参数，用于显式声明挂载的是对象桶。这是使用新能力时必须指定的参数，用以区分以往的并行文件系统挂载。挂载成功后，执行 df -h 就能看到你的对象桶已作为一个文件系统挂载在本地。之后，无论是 cp、mv、rm 等常规文件操作，还是你的应用程序通过标准文件接口读写数据，都会直接映射到 OBS 桶中。| 核心设计解析：对象桶挂载的工作原理与注意事项理解 obsfs 对象桶模式的设计逻辑，能帮助你更好地使用它，避免踩坑。1. 回写模式与数据持久性对象桶挂载采用回写模式。数据会先写入本地临时文件（由 tmpdir 或 use_cache 控制）。在默认情况下，只有当应用调用 close() 关闭文件时，才会触发实际上传，close() 返回成功表示数据已持久化到 OBS。因此，进程异常退出（如 kill -9、断电）可能导致未关闭文件的数据永久丢失。针对大文件的优化：对于超大文件上传，可以通过 -o max_dirty_data=1024（单位MB）等参数设置阈值，当本地未上传的脏数据量超过该值时，obsfs 会自动触发流式分段上传，将已写入的数据提前上传，避免 close() 时因全量重传导致长时间阻塞。实践建议：对于关键数据，务必检查 close() 的返回值；对持久性要求极高的场景，可考虑使用 fsync() 定期刷新（需权衡性能）；大文件场景下合理设置 max_dirty_data 和 multipart_size 参数以优化上传效率。2. 缓存机制与性能调优obsfs 提供多个缓存参数，用以提升性能：use_cache：指定本地磁盘缓存目录。启用后，读写的数据会缓存到本地，重复读取时性能显著提升。建议指向高性能的本地 SSD。multipart_size 与 parallel_count：分别控制分段上传的大小和并发线程数，调整这两个参数可以有效利用网络带宽，提升大文件的吞吐量。max_stat_cache_size：控制文件属性（大小、修改时间等）的缓存条目数，减少对 OBS 的 HEAD 请求，提升 ls -l 等操作的响应速度。3. 数据一致性与多挂载点需要注意的是，一个 OBS 桶可以同时挂载到多台服务器上，但各挂载点之间互不感知。obsfs 本身不提供文件锁机制，也无法感知 OBS 的多版本控制。因此，如果多个客户端并发写入同一个文件，可能出现数据覆盖或一致性问题，需要在应用层通过其他方式（如分布式锁）来协调。| 结语从仅支持并行文件系统，到 2026 年 6 月起新增对标准对象桶的挂载支持，obsfs 的这次升级，本质上是将一套统一的本地文件系统访问接口，覆盖到了 OBS 中更广泛、更常用的存储类型上。它为开发者提供了一种零侵入、低成本的云存储接入方式，尤其为那些希望利用云存储但代码改造困难的场景，提供了一条平滑的迁移路径。当然，你也要认识到它在随机写、强一致性场景下的局限，并将其用在合适的地方。关于 obsfs 的完整参数列表和最佳实践，欢迎查阅华为云官方文档。如果你在挂载过程中遇到问题，也欢迎在华为云开发者社区发帖交流，共同探讨。 相关链接：[1] obsfs 开源 GitHub 仓库：cid:link_5[2] obsfs 官方工具指南：cid:link_3[3] 挂载对象存储桶详细指导：cid:link_4

随着大模型向长上下文（Long-Context）和复杂推理任务演进，Prefill-Decode（预填充-解码，简称 PD）分离架构已成为提升集群整体吞吐量的标准实践。然而，在分布式架构下，将庞大的 KVCache 从 Prefill 节点跨网络传输至 Decode 节点，往往会带来显著的通信开销，成为制约系统性能的新瓶颈。业界优秀的开源 LLM 推理增强系统 Mooncake 凭借其对 KVCache 的全局池化管理与跨节点复用能力，有效解决了这一难题。作为一款云原生环境下的分布式推理负载编排引擎，Kthena 在 v0.4.0 版本中已全面支持基于 vLLM 和 Mooncake 的 PD 分离部署，并深度针对华为昇腾（Ascend）NPU 集群进行了硬件级优化。 ▍解决 KVCache 传输痛点：Mooncake 的核心价值在传统的 PD 分离方案中，每次请求都需要在节点间进行点对点的 KVCache 搬运。而 Kthena 引入 Mooncake 后，系统具备了以下关键能力：全局 KVCache 池化：将集群中分布在各个节点（特别是高算力的昇腾节点）的内存与显存统一管理，构建分布式的 KVCache 存储池。跨节点复用：对于具有相同前缀（Prefix）的请求，Mooncake 可以直接复用已生成的 KVCache，显著降低重复的 Prefill 计算开销。降低 TTFT（Time to First Token，首Token延迟）：通过高效的底层传输与缓存命中，长上下文场景下有效降低首Token延迟。 ▍Kthena 中的分布式编排与昇腾硬件加速在 Kubernetes 环境中手动配置复杂的 PD 分离与 Mooncake 组件是一项繁琐的工作。Kthena 将这种复杂的分布式拓扑抽象为声明式的 API，并与华为昇腾硬件底座深度融合：1. 精细化的节点调度与资源分配Kthena 允许用户根据 Prefill 和 Decode 的不同计算特征进行资源编排：Prefill 阶段（计算密集型）：自动调度至具备高计算吞吐量的昇腾节点，利用 NPU 的并行张量运算能力快速生成初始 KVCache。Decode 阶段（显存/内存密集型）：调度至配备大容量内存的昇腾节点，专注于自回归的 Token 生成。2. 基于 HCCL 的底层通信优化在 KVCache 的实际传输链路上，Kthena 结合了华为集合通信库（HCCL）。通过 NPU 专用的网络接口和通信协议，系统能够在支持 NPU 的节点之间实现更低延迟的数据交换，确保 Mooncake 的高速缓存读取不受底层网络限制。 ▍实战：在集群中启用分离推理通过以下步骤，您可以快速在配备昇腾 NPU 的 K8s 集群中部署基于 Mooncake Connector的分离式deepseek-v4推理服务。1. 部署 ModelServing（编排工作负载）首先，创建 ModelServing 资源[1]以拉起预填充和解码的具体工作负载。该配置定义了预填充角色和解码角色，并分配了针对 NPU 优化的容器及硬件资源。kubectl apply -f https://raw.githubusercontent.com/volcano-sh/kthena/main/examples/models/deepseek-v4-flash/modelserving.yaml2. 创建推理路由策略ModelServer（配置网络拓扑）接下来，创建 ModelRoute和ModelServer 资源[2]。这一步负责创建模型路由规则和KV Connector感知，包含感知Prefill、Decode不同角色的工作负载，以及传输层的流量策略。cat <<EOF | kubectl apply -f -apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelRoutemetadata:  name: deepseek-v4  namespace: defaultspec:  modelName: "deepseek_v4"  rules:  - name: "default"    targetModels:    - modelServerName: "deepseekv4-pd"---apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelServermetadata:  name: deepseekv4-pd  namespace: defaultspec:  inferenceEngine: vLLM  model: "deepseek_v4"  workloadPort:    port: 7100    protocol: http  workloadSelector:    matchLabels:      modelserving.volcano.sh/name: deepseekv4-pd    pdGroup:      groupKey: "modelserving.volcano.sh/group-name"      prefillLabels:        modelserving.volcano.sh/role: prefill      decodeLabels:        modelserving.volcano.sh/role: decode  trafficPolicy:    timeout: "300s"    retry:      attempts: 3      retryInterval: "150ms"  kvConnector:    type: mooncakeEOF3. 验证部署与测试完成上述三个 CRD 的部署后，PD分离推理即搭建完成。您可以通过调用 Chat API 来测试预填充和解码服务是否正常通信：curl --location 'http://${ENDPOINT}/v1/chat/completions' \--header 'Content-Type: application/json' \--data '{    "model": "deepseek_v4",    "messages": [        {            "role": "user",            "content": "Where is the capital of China?"        }    ],    "stream": false}'(注：请将 ${ENDPOINT} 替换为您的实际Kthena Router入口的IP 地址和端口。)如果收到正确的响应文本，即表明预填充服务已成功将生成的 KV 缓存通过底层通信层传输给解码服务，分离推理架构正在按预期高效工作。 ▍结语随着各类推理框架对 PD 分离和 KVCache 优化的持续跟进，分布式推理架构的落地标准正在不断提高。Kthena 通过集成 Mooncake 并结合昇腾 NPU 的硬件级优化，为开发者提供了一个开箱即用的分布式推理负载编排解决方案，旨在以客观的工程指标提升 LLM 在生产环境中的实际运行效率。了解完整的部署指南与架构细节，欢迎访问 Kthena [3]官方文档或访问 GitHub 仓库 (volcano-sh/kthena[4])。 相关链接：[1] Deepseek-v4部署脚本 modelserving: cid:link_0[2] Deepseek-v4部署脚本 router: cid:link_1[3] Kthena官网: https://kthena.volcano.sh/[4] volcano-sh/kthena GitHub: cid:link_2欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入Kthena技术交流群

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.18[1] 版本现已发布，本版本包含下列新增特性：支持混合云场景下的溢出式集群亲和调度引入调度超分保护机制这些更新进一步增强了 Karmada 在混合云和大规模调度场景中的可用性与灵活性。我们鼓励您升级[2] 到 v1.18.0，体验这些新能力带来的价值。  新特性概览  支持混合云场景下的溢出式集群亲和调度在混合云环境中，企业通常会将本地数据中心作为主要资源池，把公有云作为峰值流量到来时的弹性补充资源。此前，Karmada 的 ClusterAffinities 已经支持声明多个候选集群组，但这些集群组在一次调度过程中是互斥的：调度器最终只会选择其中一个集群组，无法在首选资源池容量不足时，将剩余副本继续扩展到补充资源池。Karmada v1.18 引入了引入了Overflow Cluster Affinities 能力，在 ClusterAffinityTerm 中新增 overflowAffinities 字段，用于声明按优先级排列的补充集群组。调度器会优先填满主集群组；当主集群组资源耗尽后，再按声明顺序逐级向补充集群组溢出副本，从而实现“优先使用 IDC，容量不足时再溢出到云”的混合云调度模式。这项能力主要带来以下价值：渐进式溢出：用户可以在同一个 ClusterAffinityTerm 中声明多个补充集群组，调度器会按照顺序逐级扩展调度范围。反向收缩：在缩容场景下，副本会优先从补充集群组回收，从而尽量保留主资源池中的稳定负载。成本优化：让基线工作负载稳定运行在成本更优的本地集群上，只在确有需要时才使用公有云资源承接突发流量。这一能力特别适用于如下场景：弹性 GPU 调度：本地 IDC GPU 集群承载日常推理流量，云上 GPU 集群仅用于承接峰值负载。成本控制：将常态业务留在本地基础设施，借助公有云弹性处理流量波峰。容量规划：用清晰的优先级关系定义资源池使用顺序，减少人工干预。效果图如下:下面是一个精简示例，优先将工作负载调度到 IDC GPU 集群，不足时再溢出到云上 GPU 集群：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: gpu-inference-overflow spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment placement: clusterAffinities: - affinityName: idc-gpu clusterNames: - idc-gpu-cluster1 overflowAffinities: - affinityName: cloud-gpu clusterNames: - cloud-gpu-cluster1 - cloud-gpu-cluster2 replicaScheduling: replicaSchedulingType: Divided replicaDivisionPreference: Weighted weightPreference: dynamicWeight: AvailableReplicas更多有关此功能的资料请参考：官方特性文档[3] 和 特性提案[4]。引入调度超分保护机制在大规模多集群环境中，调度器虽然按顺序处理调度请求，但在决定某个集群是否还有可用容量时，需要依赖 karmada-scheduler-estimator 提供的集群容量估算结果。问题在于：调度器刚刚完成一次副本分配后，新的工作负载真正下发到成员集群、创建 Pod 并绑定到节点之间，存在天然的时间窗口。如果在这个窗口内又到来新的调度请求，scheduler-estimator 看到的仍然可能是“旧的容量快照”，从而导致多个连续调度决策重复使用同一份尚未更新的空闲资源，造成资源超卖。最终结果就是：调度阶段看起来成功，但工作负载落地后可能因为资源不足长期 Pending。为了解决这一问题，Karmada v1.18 引入了 Scheduling Overcommit Protection（调度超分保护）。该特性在调度器和估算器之间引入“assume and deduct（先假定、再扣减）”机制：调度器在完成一次调度决策后，会先假定这部分资源已经被占用估算器在后续容量计算时，会把这部分“假定占用”的资源一起考虑进去从而避免后续调度在真实状态尚未更新前重复消耗同一批资源这一特性尤其适用于高吞吐量调度场景，可以显著降低由于状态延迟带来的资源超卖问题，让副本分配结果更贴近成员集群的真实承载能力。当前该特性是 Alpha 特性，默认关闭，并且需要同时在 karmada-scheduler 和 karmada-scheduler-estimator 上启用：--feature-gates=SchedulingOvercommitProtection=true需要注意的是，该特性只对 ReplicaSchedulingType: Divided 且采用容量感知分配策略的场景生效，例如 Aggregated 或 DynamicWeight。对于 Duplicated 模式以及完全静态权重分配的场景，不会产生影响。更多有关此功能的资料请参考：官方特性文档[5]和 调度超分保护[6]。  致谢贡献者  Karmada v1.18 版本包含了来自 31 位贡献者的 144 次代码提交，在此对各位贡献者表示由衷的感谢： 参考资料[1] Karmada v1.18 release: cid:link_3[2] Karmada v1.18 发行说明: cid:link_2[3] 溢出式集群亲和调度特性官方文档: https://karmada.io/docs/userguide/scheduling/propagation-policy#how-overflowaffinities-works[4] 溢出式集群亲和调度提案: cid:link_0[5] 调度超分保护特性官方文档: https://karmada.io/zh/docs/userguide/scheduling/scheduling-overcommit-protection[6] 调度超分保护提案: cid:link_1  关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着大模型技术的飞速发展，AI Agent 正从概念走向生产。与传统的批处理任务或推理服务不同，Agent 工作负载呈现出独特的运行特征——间歇性活跃、极低延迟敏感、多轮会话状态持久化。然而，现有的 Kubernetes 调度体系主要面向批处理和长运行服务设计，难以有效应对这类"潮汐式"交互负载：空闲时资源白白占用，唤醒时又无法做到亚秒级响应，状态管理更是一大痛点。 AgentCube[1] 正是为解决这一矛盾而生。作为 Volcano社区[2]的子项目，AgentCube 专为 AI Agent 工作负载打造了专用的控制面与数据面，核心优势体现在四个方面： 极速启动—— 通过 Warm Pool （预热池）机制预先创建并暂停一批沙箱，当 Agent 请求到来时以 "Claim-and-Go" 的方式进行毫秒级分配，消除冷启动瓶颈。高效调度 —— 借助 Volcano Agent Scheduler 的乐观并发控制与精简调度策略，大幅提升调度吞吐，并能与 Volcano 原有的 Batch Scheduler 无缝协作，确保 Agent 与传统批处理作业的统一调度与资源协调。原生会话管理 —— 以 Session ID 为核心路由标识，会话到来时自动识别并路由请求至对应沙箱，并在沙箱休眠时自动唤醒，保障多轮交互的上下文连续性。安全隔离 —— 为每个会话分配独立沙箱，确保计算、内存与文件系统的端到端隔离，防止跨租户数据泄露。同时支持以安全容器运行 Agent，借助安全运行时技术实现内核级强隔离。本文将聚焦 AgentCube 在华为云 CCE（云容器引擎）上的实践，探讨如何将 AgentCube 的调度能力与 CCE 的基础设施深度结合，为 AI Agent 应用提供高效、稳定的云原生运行底座。关于AgentCube的原理可通过设计文档[3]或往期文章[4]了解。  环境准备  已经创建好了一个1.29或更高版本的CCE集群确保本地安装的python版本>=3.11安装SDK[5] ： pip install agentcube_sdk  安装 AgentCube 插件  AgentCube目前已上架华为云 CCE 插件市场。可通过登录CCE控制台[6]进入集群插件中心界面，找到AgentCube插件进行配置安装。 AgentCube主要组件： workloadmanager：管理AgentRuntime和CodeInterpreter的生命周期。agentcube-router：API 网关，代理客户端请求到沙箱实例。volcano-agent-scheduler：调度器组件，提供低延迟和高吞吐的负责调度。agent-sandbox-controller：管理AgentSandbox资源。安装时需要设置如下参数：redis.addr：Redis的地址，必须配置。redis.password：Redis的密码，必须配置。agentSandbox.install：是否自动安装agent-sandbox。AgentCube插件运行时依赖 agent-sandbox[7]，当参数配置为true时会自动安装。如果集群已手动安装了agent-sandbox，则可配置为false跳过安装。agentSandbox.extensions：是否启用agent-sandbox的extension controller。volcano.scheduler.enabled：是否安装volcano agent-scheduler调度器。由于AgentCube运行时依赖Redis维护会话状态和索引，从稳定性和可扩展性考虑，建议购买和使用华为云分布式缓存服务 DCS[8]。此外，如果要在集群外访问 AgentCube，可为workloadmanager和agentcube-router的Service绑定ELB Ingress。  开始使用  ▍步骤一：环境变量设置export WORKLOAD_MANAGER_URL="http://workloadmanager-addr:workloadmanager-port" export ROUTER_URL="http://agentcube-router-addr:agentcube-router-port"其中workloadmanager-addr、workloadmanager-service-nodeport为workload-manager的访问地址和端口，agentcube-router-addr、agentcube-router-port为agentcube-router的访问地址和端口。▍步骤二：使用CodeInterpreterCodeInterpreter是AgentCube两大核心能力之一（另一个是AgentRuntime），是专为执行 LLM 生成的不可信代码而设计的受限运行时。通过收窄模板配置、内置 JWT 认证和预热池加速，在保障安全隔离的同时实现毫秒级启动，适用于代码解释器等沙箱执行场景。部署CodeInterpreter首先创建文件code-interpreter.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: CodeInterpretermetadata:  name: my-codeinterpreter  namespace: defaultspec:  template:    # runtimeClassName: kata    # 若使用安全容器，则可配置runtimeClassName为kata或kuasar-vmm（需要有支持安全运行时的节点）    image: swr.ap-southeast-3.myhuaweicloud.com/container/picod:latest    # 使用 PicoD 镜像，当前示例使用的镜像仅支持执行shell和python代码    resources:      requests:        cpu: "100m"        memory: "128Mi"      limits:        cpu: "500m"        memory: "512Mi"  sessionTimeout: "15m"      # 空闲 15 分钟后超时  maxSessionDuration: "8h"   # 最大会话时长 8 小时  warmPoolSize: 5    # 预热 5 个 Pod执行部署：kubectl apply -f code-interpreter.yaml验证是否部署成功：kubectl get codeinterpreter部署完成后，等待一段时间执行kubectl get pods |grep my-codeinterpreter可以看到已经预热出了5个CodeInterpreter。远程执行第一份代码创建python脚本quickstart.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')with CodeInterpreterClient(name="my-codeinterpreter", namespace="default") as client:    result = client.run_code("python", "print('Hello from AgentCube!')")    print(result)上述python脚本会连接到上一步部署的CodeInterpreter，启动一个隔离的沙箱会话，向其发送一段待执行的 Python 代码片段，并打印输出结果。执行python quickstart.py开始运行，输出：2026-06-05 15:25:22,584 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:25:22,790 | INFO | agentcube.code_interpreter | Session created: 900923f4-4d1c-4383-ac6b-331c5ec83acbHello from AgentCube!2026-06-05 15:25:22,921 | INFO | agentcube.code_interpreter | Deleting session 900923f4-4d1c-4383-ac6b-331c5ec83acb...尝试在一个会话中连续执行代码在步骤三中，我们创建的 CodeInterpreter 仅运行了单次代码便自动结束了会话。但在真实的业务场景中，我们往往需要处理多轮连续交互。接下来，我们将通过一个更具实战价值的进阶示例，来展示 AgentCube 的会话保持能力。创建python脚本longtask.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def session_reuse_workflow():    # 步骤 1：创建会话并写入数据    print("step 1: Create a session and write initial data.")    client1 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,    )    # 写入多个文件    client1.write_file("100", "counter.txt")    client1.write_file("[]", "results.json")    session_id = client1.session_id    print(f"session ID: {session_id}")    print("The file system status has been saved.\n")    # 注意：不调用 client1.stop()，让会话保持活跃    # 步骤 2：复用会话，读取并处理数据    print("step 2: Reusing sessions and processing data.")    client2 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,        session_id=session_id,  # 复用会话    )    code = """import jsonimport time# 读取计数器with open('counter.txt') as f:    counter = int(f.read().strip())print(f"current count: {counter}")# 增加计数counter += 1with open('counter.txt', 'w') as f:    f.write(str(counter))# 读取结果列表with open('results.json') as f:    results = json.load(f)# 添加新结果results.append({    'timestamp': time.time(),    'counter': counter})# 保存结果with open('results.json', 'w') as f:    json.dump(results, f, indent=2)print(f"new count: {counter}")print(f"result count: {len(results)}")"""    result = client2.run_code("python", code)    print(f"{result}\n")    # 步骤 3：查看文件系统状态    print("step 3: Verifying the File System Statuses")    files = client2.list_files(".")    print(f"Files in session: {[f['name'] for f in files]}\n")    # 清理会话    client2.stop()    print("session is deleted")if __name__ == "__main__":    session_reuse_workflow()上述python脚本首先创建了一个会话，往CodeInterpreter中上传了两个文件counter.txt和results.json。然后并不立即关闭会话，而是使用第一次创建会话时返回的session_id（会话ID）再次创建了一个客户端并远程执行代码。执行python longtask.py开始运行，输出如下：step 1: Create a session and write initial data.2026-06-05 15:45:03,386 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:45:03,775 | INFO | agentcube.code_interpreter | Session created: eda5f22f-ad7d-4d95-9adf-b74dbf015051session ID: eda5f22f-ad7d-4d95-9adf-b74dbf015051The file system status has been saved.step 2: Reusing sessions and processing data.2026-06-05 15:45:03,893 | INFO | agentcube.code_interpreter | Reusing existing session: eda5f22f-ad7d-4d95-9adf-b74dbf015051current count: 100new count: 101result count: 1step 3: Verifying the File System StatusesFiles in session: ['.bashrc', '.profile', 'counter.txt', 'picod', 'results.json', 'script_1780645503894.py']2026-06-05 15:45:04,072 | INFO | agentcube.code_interpreter | Deleting session eda5f22f-ad7d-4d95-9adf-b74dbf015051...session is deleted可以看到3轮请求的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个CodeInterpreter实例而非创建新的。且第2、3轮请求能够读取到第1轮请求上传的文件，说明这个CodeInterpreter实例并没有被销毁和重建，它的整个运行时状态——包括文件系统、内存中的变量、进程上下文等，都在请求之间完整保留。这正是 CodeInterpreter 区别于无状态函数调用的核心优势。▍步骤三：使用AgentRuntime有别于 CodeInterpreter，AgentRuntime 支持完整的 PodSpec 自定义，适用于对话、工具调用等常规 Agent 场景。部署AgentRuntime创建agent.py、requirements.txt文件，其中agent.py文件内容为官方提供的Agent示例代码[9]，requirements.txt如下：agentcube_sdk使用如下Dockerfile制作Agent容器镜像，并将制作好的镜像上传华为云SWR。FROM python:3.11-slimWORKDIR /app# 复制依赖文件COPY requirements.txt .# 安装 Python 依赖RUN pip install --no-cache-dir -r requirements.txt# 复制应用代码COPY agent.py /app/# 暴露端口EXPOSE8080# 运行应用CMD ["python", "/app/agent.py"]创建文件agent-runtime.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: AgentRuntimemetadata:  name: my-agent-app  namespace: defaultspec:  targetPort:    - pathPrefix: "/"      port: 8080      protocol: "HTTP"  podTemplate:    labels:      app: my-agent-app    spec:      schedulerName: default-scheduler    # 如果开启安装了volcano agent-scheduler调度器，可配置为agent-scheduler      containers:        - name: my-agent-app          image: {{agent image}}    # 构建好并上传华为云SWR的Agent容器镜像          env:            - name: WORKLOAD_MANAGER_URL              value: http://workloadmanager.agentcube.svc.cluster.local:8080            - name: ROUTER_URL              value: http://agentcube-router.agentcube.svc.cluster.local:8080            - name: CODEINTERPRETER_NAME              value: my-codeinterpreter            - name: CODEINTERPRETER_NAMESPACE              value: default          readinessProbe:            httpGet:              path: /health              port: 8080            periodSeconds: 5  sessionTimeout: "15m"             # 空闲 15 分钟后超时  maxSessionDuration: "8h"          # 最大会话时长 8 小时status: {}执行部署:kubectl apply -f agent-runtime.yaml验证是否部署成功:kubectl get agentruntime输出:NAME           AGEmy-agent-app   1m说明部署成功，my-agent-app为我们创建的Agent的名字。与Agent进行对话创建python脚本chatToAgent.py：from agentcube.agent_runtime import AgentRuntimeClientimport osimport timeROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def test_conversation():    # 第一轮对话    agent_client1 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0    )    # 记录会话ID，后续对话复用    session_id = agent_client1.session_id    result = agent_client1.invoke(        payload={"prompt": "Introduce yourself"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第二轮对话    agent_client2 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client2.invoke(        payload={"prompt": "What can you do?"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第三轮对话    agent_client3 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client3.invoke(        payload={"prompt": "Write a Python function for me"},    )    print(f"response: {result}\n")if __name__ == "__main__":    test_conversation()上述python脚本首先创建了一个对话，对话的对象是上一步创建的my-agent-appAgent应用，然后连续发起3次对话。输出如下：2026-06-05 16:33:28,396 | INFO | agentcube.agent_runtime | Bootstrapping AgentRuntime session...2026-06-05 16:33:29,771 | INFO | agentcube.agent_runtime | AgentRuntime session created: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Introduce yourself', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:29.839193', 'original_prompt': 'Introduce yourself'}2026-06-05 16:33:30,812 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: What can you do?', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:30.912573', 'original_prompt': 'What can you do?'}2026-06-05 16:33:31,886 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Write a Python function for me', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:31.989551', 'original_prompt': 'Write a Python function for me'}可以看到3次对话的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个AgentRuntime实例。  总 结  AgentCube 以极速启动、高效调度、原生会话管理、安全隔离四大核心能力，补齐了 K8s 集群承载 AI Agent 工作负载的短板。华为云 CCE 将持续集成 AgentCube ，为用户打造低延迟、高吞吐、强隔离的高性能 AI Agent 运行底座。 相关链接[1] AgentCube GitHub仓库: cid:link_7[2] Volcano官网: https://volcano.sh[3] AgentCube设计文档: cid:link_3[4] Kubernetes 跑 AI Agent，缺的不只是算力——AgentCube 补上了什么: cid:link_6[5] Python SDK: cid:link_4[6] 华为云CCE控制台: cid:link_1[7] AgentSandbox: cid:link_5[8] 华为云分布式缓存服务 DCS: cid:link_2[9] Agent示例代码: cid:link_0 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

6月5日，2026华为云INSPIRE创想者大会Agentic Infra云基础设施技术论坛在上海圆满落幕。此次论坛以“进化，从AI Infra到Agentic Infra”为主题，汇聚顶尖技术专家、行业精英与生态伙伴，共同探讨Agentic时代AI基础设施的架构设计、技术创新与演进方向。会上，华为云重磅解读“Agentic Infra”技术新范式——“Agentic计算机”，以四大突破极致重构AI算力底座，为中国企业Agent创新发展持续注入强劲动能！▍云计算跨入Token工业时代，基础设施面临范式跃迁▲华为云基础设施云服务产品线总裁鲍亮“Agentic AI时代正在引发计算范式的一系列根本性跃迁。”华为云基础设施云服务产品线总裁鲍亮在致辞中表示，云计算已跨入Token工业时代。因此，华为云提出Agentic Infra新范式，核心是构建“高效Token工厂+通智一体化调度+持续学习+安全自治”四大能力，具体通过灵衢智算集群AICS打造极致效能Token工厂、以存代算提供PB级记忆空间打破Agent记忆瓶颈、AgentSphere提供高性能安全部署运行时、以及Volcano实现通智一体化调度，通过持续做强根技术，与AI智能化的技术深度融合，为千行百业提供最优的Agentic基础设施底座！▍软硬芯深度协同，华为云重磅解读“Agentic计算机”▲华为公司Fellow、云系统首席专家余洲“在Agent时代，云基础设施就是‘Agentic计算机’”华为公司Fellow、云系统首席专家余洲指出，“Agentic计算机”与传统云基础设施相比，其核心变化在于服务对象从人转向AI、面向每天万亿级Token的处理进行整体优化等方面。为此，华为云基于软硬芯协同，以“Agentic计算机”为核心概念，构建了高效的Agentic Infra，并实现四大突破。一是灵衢网络实现多资源一体化，把分散在数百个机柜中的CPU、NPU、SSD和内存互联起来，使它们能够像同一台计算机里的设备一样协同工作；二是超节点规模和带宽持续演进。基于昇腾950，华为云发布1024卡的灵衢智能计算集群（AICS），让算力提升2.6倍；基于灵衢总线和弹性统一内存池，突破了大模型推理的内存墙瓶颈，更灵活地支持万亿参数模型训推；三是推出记忆存储解决方案AMS。依托NPU直通CMS硬件（上下文记忆存储），为Agent提供PB级超大记忆空间，支持KV Cache分层池化，将缓存命中率提升至95%，成本节省高达63%。最后是提供高性能极简网络，实现算力资源和网络IO资源的灵活配比，以及多网合一。基于以上四大核心突破，Agentic计算机能够充分满足更高的推理效率、更长的序列和更快的推理速度的需求。▲华为公司Fellow、华为云服务首席架构师顾炯炯华为公司Fellow、华为云服务首席架构师顾炯炯指出，Agentic AI云基础设施面临小模型单卡吃不满、大模型推理PD分离资源偏科、潮汐效应等因素导致的算力资源利用率低、万卡训练集群故障爆炸半径大等核心困境，传统软硬耦合架构已无法应对。华为云为此推出FlexNPU柔性液态算力创新架构，在业界主流训练和推理框架与昇腾NPU硬件算力层之间引入一层“软件定义调度与虚拟化”软件，实现了多模型及PD推理共卡的算子级的细粒度时空复用，硬件故障隔离以及基于透明快照的极速Serverless弹性，FlexNPU由此带来三重突破：更高效，更敏捷，零宕机，能够大幅降低大模型推理单位Token小模型算力性价比，同时将节点级弹性及硬件故障恢复时间从分钟级降至秒级，从而让用户的每一分算力投入物尽其用，让每一笔Token的支出，不再为空闲算力买单。▍面向Agent时代，通智融合增强智能基础设施▲云原生计算基金会（CNCF）中国区总监陈泽辉云原生计算基金会（CNCF）中国区总监陈泽辉现场分享了一个趋势：CNCF技术栈从云原生平台底座，到今天作为Agentic时代的引擎发展迅速。Kubernetes已经成为标准的AI操作系统，82%的受访企业在生产环境中使用K8s。目前企业优先部署Agentic AI的比例高达74%。从云原生到AI Native，再到现在的Agentic Infra，以Volcano为代表的调度编排成为决胜关键——Agentic不再是工具，而是真正的资源概念。▲CNCF TOC副主席、华为云云原生开源负责人王泽锋CNCF TOC副主席、华为云云原生开源负责人王泽锋表示，Volcano从设计之初就针对训练和推理的工作负载做深层次优化，现在演进到全新的多调度器免锁并行架构：面向Agentic工作负载，采用极简的沙箱调度策略，调度耗时相比原来下降99%；而传统训推工作负载保持采用批量调度策略，在与Agentic调度一致无冲突情况下，仍可获得最优调度结果。在运行时层面，AgentCube + Kuasar的组合实现了端到端冷启动控制在50毫秒以内的突破。此外，Kthena引入更多智能化算法做路由感知，相关能力将在630版本发布，并在Kthena 1.0版本达到正式可商用级别。▍产学研用深度融合，共筑国产Agent基础设施护城河先进架构还需在真实业务场景千锤百炼。论坛现场，行业领军代表分享了与华为云合作的实战成果。▲香港科技大学助理教授、AReaL开源社区负责人袁彬航香港科技大学助理教授、AReaL开源社区负责人袁彬航分享了基于AReaL构建asearcher，训练能够自动使用搜索引擎、通过多轮迭代回答问题的智能体。AReaL不仅在华为云上完成适配，华为云还帮助其在NPU上适配算子和参数传输模块，并完善两个在云原生场景、真实多任务RL训练中非常重要的功能——On-policy蒸馏进最终交付版本以及LoRA适配。未来AReaL2.0将面向智能体开发，提供自适应的演化基座，实现智能体轨迹数据协议、数据代理和动态进化RL模块的完整支持。▲小红书大模型基建部RL引擎负责人杨睿在互联网应用侧，小红书大模型基建部RL引擎负责人杨睿介绍了小红书内部的全异步框架Relax。这是基于全模态统一、生产级框架等三大支柱设计，并通过华为云完成昇腾生态的适配；通过Transfer Queue实现训推解耦，分布式Checkpoint服务保证权重同步耗时占比在5%以内，同时针对多模态训练优化了图片计算复用与混合并行策略。目前，Relax在多模态、全异步实践、Hybrid混合部署以及Agentic RL上已经深度沉淀，未来还将支持潮汐资源下的弹性扩缩。▲面壁智能端侧智能业务总经理周树峰针对端侧部署的需求，面壁智能端侧智能业务总经理周树峰表示，面壁智能从两年前转向端侧和边缘侧，探索在相对小的参数量级上实现对标大尺寸模型的能力，核心是提升智能密度、降低训练与推理开销。2024年9月，面壁智能4B模型已达到3.5水平，随后发布的1.3B超小尺寸模型更是越级挑战。今年，面壁智能将三值量化技术搬到华为昇腾卡上完成训练和推理验证，使模型在保持精度的同时大幅提升速度，已应用于手机、汽车等行业。▲芒果AIGC创新制作中心主任李俊俊在行业应用领域，芒果TV AI产业化中心和智能研究中心副总经理 李俊俊介绍，AI在内容制作上经历了三个阶段：从辅助决策到与创作者实时共创，再到AI成为基础设施。目前，芒果TV推出芒果灵创AIGC创作平台，聚合全域模型，主打可控生成，其中视频模型在进行昇腾适配，它不是抽卡式的生成，而是从内容土壤里长出来的、支持团队协作与成本可控的开放生态，让AI从功能变成了伙伴。面对Agentic时代万亿Token级的复杂任务，传统“堆卡”模式已成过去，取而代之的是一台以Token为粒度、以AI操作为对象、通智融合的“超级计算机”。未来，华为云将致力于把“Agentic Infra”打造为中国AI产业的自主引擎，让智能体真正跑在坚实、高效的国产底座之上，共同开启智能时代的无限可能。 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着批量训练、推理、AI Agent、HPC、大数据等多种负载在同一Kubernetes集群中混合部署，调度器需要在资源竞争更加激烈的环境下做出更高质量的决策，同时保持作业级语义、队列公平性、拓扑亲和性与运行稳定性。Volcano v1.15.0 现已正式发布，围绕这些方向，在调度核心、异构资源管理、多调度器协同与性能可观测等方面进行了增强。本次最值得关注的新增能力是 Gang-Aware Preemption and Resource Reclamation：抢占决策在抢占方与被抢占方两侧均以Gang为整体进行评估——抢占方按Gang整体进行放置，被抢占候选者同样按Gang粒度进行排序和评估，优先驱逐冗余副本，避免逐Pod随机驱逐打断多个训练任务而抢占方自身仍无法启动的情况。此外，v1.15.0在capacity插件中引入了DRA队列配额，新增了可插拔的多分片策略框架以及Benchmark与性能可观测工具，支持Kubernetes 1.35，并在NodeGroup调度优先级、Agent Scheduler稳定性、GPU/vGPU及队列准入控制等方面做了补充增强。Release Note: cid:link_11  Volcano v1.15.0 版本亮点  本次发布主要围绕以下方向展开：Gang-Aware Preemption and Resource Reclamation：以Job/Gang为粒度组织被抢占候选，区分冗余副本与关键副本，优先驱逐冗余副本减少任务扰动，并在驱逐前模拟整体放置确认抢占方能成功启动，避免逐Pod抢占打断多个训练任务而抢占方自己也无法运行的情况。DRA Queue Quota：capacity插件将DRA ResourceClaim纳入Volcano现有的队列容量模型，让DRA设备资源也能通过队列配额管理。Pluggable Multi-Sharding Policy：Sharding Controller支持通过ConfigMap组合多种分片策略，并支持运行时热加载。Volcano Benchmark框架：提供一键化性能测试环境搭建和报告输出，支持Kind/KWOK及已有集群。Scheduling Gates for Queue Admission：区分"队列配额不足"和"集群资源不足"，避免autoscaler因队列限额触发不必要的扩容。此外，v1.15.0还包含Kubernetes 1.35支持、NodeGroup preferred ordering、Agent Scheduler稳定性增强、GPU/vGPU增量增强以及安全修复。它们会在后文简要介绍，对生产可用性和生态兼容性同样重要。  重点特性  ▍1. Gang-Aware Preemption and Resource Reclamation（Alpha）在大模型训练、HPC等分布式任务中，一个Job往往需要多个Pod同时运行才有意义。如果抢占只按单个Pod进行决策，就可能从多个正在运行的训练任务里各抢一个Pod——表面上释放了资源，实际上既把多个任务都打断了，发起抢占的Gang也未必能凑齐minAvailable成功启动。v1.15.0引入Gang-Aware Preemption and Resource Reclamation，让抢占方和被抢占方在决策时都以Gang为整体来考量，避免出现"释放了一堆Pod，但谁都没跑起来"的情况。在被抢占方一侧，Volcano以Job/Gang为粒度组织被抢占候选，而不是把所有Pod看成可互换的抢占对象。每个候选Job的Pod被区分为冗余副本（超出minAvailable的部分）和关键副本，调度器优先选择冗余副本——驱逐它们不会打断任务——尽量避免触碰关键副本。这与原有action逐Pod选择、不区分破坏代价的方式有本质区别。在抢占方一侧，调度器逐步累计可释放的资源，当累计量足以覆盖抢占方Gang的整体需求时，先做放置模拟——在释放后的资源视图上验证抢占方Gang能否整体调度成功——只有模拟通过才真正执行驱逐。这样不会出现"抢了一堆Pod结果抢占方还是起不来"的情况。不论是否启用HyperNode拓扑，这套机制都能减少随机抢占带来的任务扰动。启用HyperNode拓扑后，Volcano还会将victim搜索限定在选定的拓扑范围内，避免跨拓扑域抢占。该特性目前为Alpha，需要显式配置gangPreempt和gangReclaim两个新的action。后续版本会继续评估是否将Gang-Aware驱逐机制与原有preempt、reclaim action合并。配置示例：actions: "enqueue, allocate, backfill, gangPreempt, gangReclaim"tiers:- plugins:  - name: priority  - name: gang  - name: drf  - name: predicates  - name: nodeorder - name: binpack相关资料：相关PR：cid:link_13,  cid:link_14,  cid:link_15设计文档：Gang-Aware Eviction Design:cid:link_5设计文档：EvictableFn Evolution for Gang Eviction:cid:link_2感谢社区开发者：@vzhou-p▍2. DRA Queue QuotaKubernetes Dynamic Resource Allocation（DRA）为设备资源申请提供了更灵活的模型。此前版本的Volcano已经支持调度使用DRA资源的Pod，但队列quota尚未覆盖DRA ResourceClaim。v1.15.0在capacity插件中补齐了这一能力，将DRA资源纳入Volcano已有的队列配额体系。用户仍然可以使用capability、deserved、guarantee容量模型管理队列资源，无需为DRA单独维护一套quota API。目前支持两类资源管控：基于DeviceClass的整卡/整设备数量配额基于可消费设备维度的配额，如虚拟GPU core、显存等当多个Pod引用同一个共享ResourceClaim时，Volcano会自动去重，避免同一份资源被重复计入队列用量。这样，集群管理员可以用同一套队列容量模型统一管理CPU、内存、扩展资源以及DRA设备资源。配置示例：tiers:- plugins:  - name: capacity    arguments:      capacity.DynamicResourceAllocationEnable: true      capacity.DRAConsumableCapacityEnable: trueapiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: ml-teamspec:  capability:    cpu: "100"    memory: "200Gi"    "deviceclass/gpu.nvidia.com": "8"    "cores.deviceclass/hami-core-gpu.project-hami.io": "800"    "memory.deviceclass/hami-core-gpu.project-hami.io": "320Gi"相关资料：相关PR：cid:link_16设计文档：DeviceClass Quota Support in Capacity Plugin:cid:link_7使用文档：DeviceClass Quota User Guide:cid:link_6感谢社区开发者：@xu-wentao▍3. Pluggable Multi-Sharding Policy（Alpha）在多调度器架构下，不同调度器通常面向不同类型的工作负载，对候选节点的范围也有不同要求。v1.15.0对Sharding Controller进行了增强，支持以可插拔的策略流水线组合多种分片逻辑。每个scheduler shard可以配置一组有序的策略，覆盖filter、score、select等阶段。内置策略包括：allocation-rate：根据节点资源利用率进行过滤和打分warmup：优先处理warmup节点node-limit：限制每个shard的节点数量范围策略通过ConfigMap配置，支持运行时热加载。如果新配置校验失败，系统会沿用上一份有效配置，避免线上变更引入风险。这让多调度器的节点分片能够更灵活地适配不同集群规模和业务类型，也为后续扩展更多sharding policy提供了清晰的接口。配置示例：custom:  sharding_configmap_enable: true  sharding_configmap_data: |    schedulerConfigs:      - name: volcano        type: volcano        policies:          - name: allocation-rate            weight: 1            arguments:              minCPUUtil: 0.0              maxCPUUtil: 0.6          - name: node-limit            arguments:              minNodes: 1              maxNodes: 100      - name: agent-scheduler        type: agent        policies:          - name: allocation-rate            weight: 1            arguments:              minCPUUtil: 0.7              maxCPUUtil: 1.0          - name: warmup            weight: 2相关资料：相关PR：cid:link_17, cid:link_18, cid:link_19使用文档：How to Configure Sharding via ConfigMap: cid:link_3感谢社区开发者：@lixmgl, @agrawalcodes▍4. Volcano Benchmark框架调度器的性能优化离不开稳定、可复现的测试基线。v1.15.0新增了Benchmark框架，支持一键部署测试环境、运行标准场景并输出性能报告。该框架支持两类环境：本地Kind + KWOK环境，用于开发者快速复现和分析调度性能问题已有Kubernetes集群，用于用户在真实环境中评估Volcano的调度吞吐和延迟测试场景覆盖VolcanoJob Gang调度、普通Pod调度、KWOK拓扑标签、HyperNode生成等，配合scheduler/controller metrics、audit-exporter报告和Grafana dashboard，可以帮助快速定位调度性能瓶颈。对于新接触Volcano的用户，也可以借助该框架在自己的集群中运行一轮测试，快速了解实际的调度吞吐和延迟表现。使用示例：cd benchmarkmake setup VOLCANO_VERSION=v1.15.0make test-gang-env JOBS=10 REPLICAS=100 MIN_AVAILABLE=100make cleanup-all相关资料：相关PR：cid:link_20, cid:link_21, cid:link_22,  cid:link_23使用文档：Benchmark README:cid:link_9感谢社区开发者：@JesseStutler, @3th4novo▍5. Scheduling Gates for Queue Admission（Alpha）当Pod因为队列容量不足而无法调度时，Cluster Autoscaler或Karpenter可能将这些Pod误判为集群资源不足，从而触发不必要的扩容。v1.15.0引入Scheduling Gates for Queue Admission。用户通过annotation为Pod开启后，当队列容量不足时，Volcano会通过Kubernetes原生的schedulingGates机制阻止Pod进入调度，使其对autoscaler不可见，从而不会触发扩容。等队列释放出容量后，Volcano再移除gate，Pod恢复正常调度流程。这样可以有效区分"队列配额不足"和"集群资源不足"两种情况，避免因队列quota限制导致的无效扩容。该特性目前为Alpha，需要同时在scheduler和webhook-manager中开启SchedulingGatesQueueAdmission。配置示例：helm install volcano volcano/volcano --namespace volcano-system --create-namespace \  --set custom.scheduler_feature_gates="SchedulingGatesQueueAdmission=true" \  --set custom.admission_feature_gates="SchedulingGatesQueueAdmission=true"apiVersion: v1kind: Podmetadata:  name: queue-gated-pod  annotations:    scheduling.volcano.sh/queue-allocation-gate: "true"spec:  schedulerName: volcano  containers:  - name: worker    image: nginx相关资料：相关Issue：cid:link_12相关PR：cid:link_25/pull/5033,cid:link_24设计文档：Gate-Controlled Scheduling for Cluster Autoscalers Compatibility: cid:link_4使用文档：How to Use Scheduling Gates for Queue Admission: cid:link_1感谢社区开发者：@devzizu  其他值得关注的增强  ▍Kubernetes 1.35支持v1.15.0更新了Kubernetes依赖、生成代码、fake client、informer、volumebinding集成、CI/lint工具链以及兼容性文档，支持Kubernetes 1.35。▍NodeGroup preferred orderingNodeGroup plugin新增enablePreferredOrder，Queue中preferredDuringSchedulingIgnoredDuringExecution的顺序会影响调度打分。靠前的NodeGroup会获得更高分数，适合“优先使用固定资源池，资源不足时再fallback到弹性资源池”的场景。配置示例：tiers:- plugins:  - name: nodegroup    arguments:      enablePreferredOrder: trueapiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: bigdataspec:  affinity:    nodeGroupAffinity:      preferredDuringSchedulingIgnoredDuringExecution:      - spark-fixed      - spark-serverless相关配置可参考：cid:link_0▍Agent Scheduler稳定性增强v1.15.0修复了Agent Scheduler多worker乐观并发冲突、共享action实例复用framework/cycle state、CSI manager注册缺失、binder节点优先级处理以及E2E duration metric等问题，并补充了相关E2E覆盖。这些修复主要提升了延迟敏感型AI Agent工作负载的调度稳定性。▍GPU/vGPU增量增强v1.15.0对deviceshare plugin做了多项增强，包括GPU exclusive支持、vGPU preemption支持，以及在不允许共享时避免同一PodGroup内的Pod使用同一张物理vGPU设备。▍安全修复v1.15.0包含webhook request body size mitigation，用于修复CVE-2026-44247相关的拒绝服务风险。该修复限制admission webhook请求体大小，避免超大请求导致webhook server内存耗尽。  总 结  Volcano v1.15.0的核心变化是Gang-Aware Preemption and Resource Reclamation，将抢占决策从逐Pod粒度提升到Gang粒度，在抢占方与被抢占方两侧同时进行整体性评估，减少分布式训练场景下因随机驱逐导致的连锁任务失败。DRA Queue Quota将DRA设备资源纳入已有的队列容量模型，使异构资源与CPU、内存在配额管理上保持一致。Pluggable Multi-Sharding Policy、Benchmark框架与Agent Scheduler稳定性修复，则分别完善了多调度器协同、性能基线建立与延迟敏感负载调度方面的工程能力。Volcano将继续面向AI训练、推理、Agent、HPC与大数据等混合部署场景，持续完善统一调度平台的调度能力与工程质量。  升级注意事项 可以通过Helm或YAML方式升级到v1.15.0：helm repo updatehelm upgrade volcano volcano-sh/volcano --version 1.15.0kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/v1.15.0/installer/volcano-development.yaml当前Gang-Aware Preemption and Resource Reclamation特性为Alpha阶段，需要显式配置gangPreempt和gangReclaim两个新的action。当前不推荐在同一个scheduler action list中同时配置新的gangPreempt/gangReclaim和旧的preempt/reclaim action。Scheduling Gates for Queue Admission为Alpha，需要同时在scheduler和webhook-manager中开启。DRA scheduling integration默认开启，以对齐Kubernetes 1.34+的DRA默认行为。如需关闭，可设置predicate.DynamicResourceAllocationEnable: false。DRA Queue Quota依赖Kubernetes DRA支持和可用的DRA driver。  参考链接  本文重点介绍v1.15.0的主要能力。完整的API Changes、Bug Fixes、依赖更新、测试与维护项和贡献者列表，请参考正式Release Note及相关文档。Release Note: cid:link_11Full Changelog: cid:link_10  致 谢  Volcano v1.15共有43位社区贡献者参与。衷心感谢每一位贡献者，是你们的努力让Volcano不断进步，成为更强大、更稳定的统一调度平台！  🌋 Volcano 是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.6k+ Star 和 1.3K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。欢迎参与社区贡献：Volcano官网： https://volcano.sh GitHub: cid:link_25 每周例会：https://zoom.us/j/91804791393关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

摘要 本文介绍了基于 KubeEdge-Ianvs 分布式协同AI基准测试框架的大语言模型联邦微调系统。该系统针对企业应用大模型面临的算力门槛高、数据孤岛严重等挑战，通过联邦学习实现"数据不动模型动"的隐私保护训练模式。系统集成 LoRA 和 P-Tuning 两种参数高效微调技术，大幅降低通信成本和计算开销，支持 FedAvg 和 FedAvgM 聚合算法，并创新性地设计了 GPU 感知任务调度机制以避免显存溢出。在 MedQuad 医疗问答数据集上的实验验证了不同 PEFT 方法与聚合算法组合的有效性，为垂直领域的联邦大模型应用提供了可行方案。本文还提供了详细的安装配置和使用教程，帮助用户快速上手联邦大模型微调实践。代码请见：cid:link_1一、背 景近年来，以大语言模型（LLM）为代表的人工智能技术迅猛发展，ChatGPT、LLaMA、GLM 等模型在自然语言理解、代码生成、智能问答等任务中展现出卓越能力，推动各行业迈向智能化新阶段。这些模型不仅能够理解复杂的语义，还能进行创造性的内容生成，为各行各业带来了前所未有的智能化机遇。然而，企业在实际落地大语言模型过程中仍面临两大核心挑战，制约技术普及并可能加剧数字鸿沟。这些挑战不仅制约了技术的普及，更可能加剧数字鸿沟，让 AI 的红利难以惠及更广泛的群体。📌 挑战一：算力门槛高，中小企业难以承担大语言模型训练对算力需求巨大，通常需数十亿至千亿级参数，依赖大规模 GPU 集群持续运行数周乃至数月。据估算，训练一个类似 GPT-3 规模的模型，成本可能高达数百万美元。高昂的资源投入使大模型能力逐渐成为大型科技公司的专属优势。对于资源有限的中小企业而言，即便拥有宝贵的行业数据和应用场景，也往往因算力不足难以自主完成模型训练，限制了技术普惠与创新多样性。📌 挑战二: 数据孤岛困境,高质量数据难以整合高质量训练数据是大模型能力的核心基础。大语言模型的强大能力，很大程度上依赖于海量、多样化的训练数据。然而现实情况是，真正有价值的数据往往分散在不同的企业、机构和组织中，形成了一个个难以逾越的"数据孤岛"。这种数据分散的局面，源于多重因素：隐私合规要求：医疗、金融等领域的敏感数据受到严格的法律保护，不能随意共享或传输商业竞争壁垒：企业积累的私有数据往往是核心竞争力，难以对外开放数据主权意识：各方对数据控制权的重视，使得数据集中面临信任难题更为严峻的是，研究表明互联网上的公开数据可能即将耗尽。随着大模型训练需求的持续增长，如何在保护隐私的前提下，合理利用分散在各方的私有领域数据，已成为行业亟需解决的关键问题。破局方向：联邦学习赋能大模型微调。面对这些挑战，联邦学习(Federated Learning)为我们开辟了一条创新路径。联邦学习作为一种隐私保护的协同机器学习范式，通过“数据不动模型动”的方式，使各参与方本地数据保留不动，仅交换模型参数或梯度信息，实现多方协同训练。这种技术范式带来的价值是多维度的：在资源层面：联邦学习允许多个企业汇聚各自的算力资源，采用分布式的方式共同承担大模型训练的计算负担。一家企业可能无力独立训练大模型，但十家、百家企业的算力聚合，就能让 AI 能力的获取不再是大公司的专利。这种"众人拾柴火焰高"的协作模式，有望打破算力垄断，推动AI的普惠化发展。在数据层面：联邦学习通过同态加密、安全多方计算、差分隐私等密码学和隐私保护技术，在保护各方数据隐私和安全的前提下，充分挖掘分散数据的集体智慧。各参与方既能贡献自己的数据价值，又无需担心隐私泄露，真正实现了"数据可用不可见"。在合规层面：联邦学习天然契合数据保护法规的要求，为跨机构、跨地域的数据协作提供了合法合规的技术方案，让数据要素的价值释放有了坚实的制度保障。联邦学习与大语言模型结合形成联邦大模型学习（FedLLM），进一步引入参数高效微调技术（如 LoRA、P-Tuning），显著降低通信与计算开销。这一技术融合不仅继承了联邦学习的隐私保护优势，还针对大模型的特点进行了创新性的优化设计。联邦大模型学习通过参数高效微调(如 LoRA、P-Tuning)等技术，大幅降低了通信成本和计算开销，使得在联邦场景下训练和微调大模型成为可能。这为企业提供了突破资源和数据瓶颈的可行方案，更开启了 AI 协作发展的新时代。该方案使中小企业能够与行业领先者协同构建领域大模型，医院之间可以在保护患者隐私的前提下，协作提升医疗 AI 的诊断能力；金融机构可以联合建立更精准的风控模型，而无需担心客户数据的泄露风险。二、基于KubeEdge-Ianvs的大模型联邦微调算法实现本项目基于 KubeEdge-Ianvs 分布式协同 AI 基准测试框架，设计并实现了一套完整的联邦大模型微调系统。该系统充分继承了 Ianvs 的模块化架构优势，并针对大语言模型的特点进行了专门优化，在保持原有 federated learning 范式完全向后兼容的前提下，构建了适用于大规模语言模型的联邦学习解决方案。▍2.1 总体架构设计整体架构采用分层设计理念，从底层到上层依次为测试环境管理层、测试用例控制层和故事管理层，如图1所示。测试环境管理层负责基准测试指标的定义与计算，新增支持 ROUGE-1、ROUGE-2、ROUGE-L、BLEU-4 等自然语言生成评估指标，同时提供数据预处理和分割工具，支持 JSONL 格式的大语言模型数据集处理，并实现联邦场景下的数据分区策略以模拟真实的数据分散情况。测试用例控制层基于现有的联邦学习范式扩展实现了全新的联邦大模型微调算法，标准化了联邦微调的完整训练和评估流程，采用模块化设计使得用户只需指定相关模型与聚合接口即可完成算法配置。故事管理层则为用户提供直观的排行榜视图和详细的测试报告，支持跨联邦轮次的 LLM 基准指标可视化，便于算法性能的横向对比和纵向追踪。图1 整体架构设计在核心技术方案上，系统针对大语言模型参数规模庞大、全量微调成本高昂的问题，集成了 LoRA 和 P-Tuning 两种主流的参数高效微调技术，如图2所示。 LoRA 通过在权重矩阵中插入低秩可训练适配器，仅需训练极少量额外参数（通常小于1%模型参数量），推理时无需合并即可保持原模型结构。P-Tuning 则在嵌入层学习连续的提示向量，仅修改输入表示，对不同任务具有良好的灵活性且参数量更小，适合资源受限场景。根据实验数据，LoRA 方式的通信成本与 P-Tuning-v2 的通信成本均小于1%，这种数量级的降低使得联邦大模型学习在实际生产环境中具备了可行性。图2 算法设计方案系统支持 FedAvg 和 FedAvgM 两种聚合算法供用户根据场景灵活选择。FedAvg 对客户端模型参数进行加权平均，权重通常基于各客户端的数据量，简单高效且适合同构场景。FedAvgM 则在服务器端引入动量机制，提供更稳定的收敛性能，在非独立同分布数据下表现更优。每轮训练中，仅 LoRA 适配器或 P-Tuning 提示向量在客户端与服务器间传输，原始 LLM 的主体参数始终冻结，既保护了模型知识产权，又极大降低了通信负担。针对传统联邦学习多线程方法在大模型场景下容易导致 GPU 显存溢出的问题，系统创新性地设计了 GPU 感知任务调度机制。该机制将所有客户端训练任务放入全局任务队列，为每个可见 GPU 启动专属工作线程，线程通过 torch.cuda.set_device 绑定到特定设备后采用 FIFO 方式逐个处理客户端任务，训练完成后立即释放显存。这种设计确保每个 GPU 同时只加载一个 LoRA 增强模型，使得峰值显存使用量可预测且恒定，同时严格的 FIFO 顺序保证所有 GPU 得到均衡利用。实践证明，该调度器能够在单个节点的多 GPU 环境（如4×Nvidia A100）上稳定运行数十个7B参数级别的 LLM 客户端微调任务，避免 OOM 错误，实现了固定内存上限、负载均衡和线性扩展的设计目标。系统的完整训练流程如图3所示。从初始化阶段开始，服务器加载预训练大模型（如ChatGLM-6B、LLaMA等）并初始化全局 LoRA 适配器或 P-Tuning 提示向量，配置联邦参数包括客户端数量、通信轮次和聚合策略等。进入迭代训练阶段后，每一轮都经历客户端采样、模型分发、本地训练、参数上传、安全聚合和性能评估等步骤。服务器从所有客户端中采样参与本轮训练的子集，将当前全局适配器或提示向量下发给选中的客户端，各客户端在私有数据上执行 PEFT 微调更新本地适配器参数，随后将训练后的适配器参数上传至服务器，服务器使用选定的聚合算法更新全局模型并在测试集上评估性能。当达到预设轮次或性能指标后停止训练，将最终的全局适配器与基础模型结合并部署到实际应用环境。整个流程中，原始训练数据始终保留在各客户端本地，仅交换模型参数，真正实现了"数据不动模型动"的隐私保护目标。图3 任务时序图▍2.2 案例分析为了全面验证系统的有效性，我们在 MedQuad 医疗问答数据集上进行了深入的实验研究[1]。实验采用 ChatGLM-6B 作为基础大语言模型，该模型包含60亿参数，在中文理解与生成任务上表现优异。硬件配置方面，单机4张 NVIDIA A100 GPU。联邦配置模拟4个客户端参与学习，训练总轮次设置为5轮。评估指标采用自然语言生成领域的标准体系，包括衡量单词级别重叠度的 ROUGE-1、衡量二元组重叠度的 ROUGE-2、基于最长公共子序列的 ROUGE-L，以及评估 n-gram 精确匹配度的 BLEU-4 指标。图4 医疗联邦示例图5 部分实验效果展示从图4的排行榜可以看出，FedAvg-LoRA 组合取得了最佳性能，在所有评估指标上均位列第一，ROUGE-1 达到0.3283，ROUGE-2 为0.0965，ROUGE-L 为0.1907，BLEU-4 为0.0525。对比相同聚合算法下的不同微调方法，LoRA 始终优于 P-Tuning，以 FedAvg 为例，LoRA 方案在 ROUGE-1 指标上比 P-Tuning 高出13.5%，在 ROUGE-2 上优势更为明显，提升了34.2%。这种差异源于两种方法的本质区别：LoRA 通过在模型权重矩阵中注入低秩适配器能够更深入地调整模型内部表征，而 P-Tuning 仅在输入层学习连续提示，在医疗问答这类需要深度理解专业术语和复杂语义的任务中，LoRA 的优势得以充分体现。聚合算法方面，FedAvg 与 FedAvgM 的对比结果揭示了有趣的交互作用：在 LoRA 场景下 FedAvg 显著优于 FedAvgM（ROUGE-1相差12.8%），但在 P-Tuning 场景下两者性能相当接近（差距仅为0.8%），这表明 FedAvgM 的动量机制在 LoRA 较大的参数空间中可能引入额外不稳定性，而在 P-Tuning 的低维参数空间中则能更好发挥平滑作用。实验结果为实践应用提供了明确指导：资源充足时推荐 FedAvg-LoRA 获得最佳性能，资源受限场景下 FedAvgM-P-Tuning 能够在保持稳定收敛的同时最小化通信开销，数据异构场景则建议优先尝试 FedAvgM 应对非独立同分布挑战。值得注意的是，所有方案的 ROUGE-2 和 BLEU-4 指标相对较低，反映了医疗问答任务需要生成精确匹配的专业术语和复杂句式的固有难度，未来可探索引入领域知识增强、对比学习等技术进一步提升联邦大模型在垂直领域的表现。通信成本分析揭示了 PEFT 方法的巨大优势。LoRA 方法仅需传输 3.6MB 的参数，占模型总参数的0.058%，这意味着在 10Mbps 的网络下单次通信仅需约3秒，相比全量微调通信成本降低了1724倍，极其适合带宽受限的边缘设备或跨地域联邦学习。P-Tuning-v2 虽然参数量为是 LoRA 的1.25倍。 三、基于KubeEdge-lanvs的使用教程在本章中，我们通过运行 Ianvs 联邦学习的 FedLLM-PEFT 样例向大家讲解基于 KubeEdge-Ianvs 实现大语言模型联邦微调的基本流程。Ianvs 安装流程以及联邦学习更详细的介绍可以参考：Ianvs官方文档[2]。▍3.1 准备环境首先确保您的系统满足以下要求：Python 3.8.18PyTorch 2.4.1+cu118兼容 CUDA 的 GPU（建议使用 Nvidia A100 80GB）建议 32GB 以上内存我们需要配置好联邦学习的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /data cd /data mkdir fedllm_datasets cd fedllm_datasets下载 MedQuad 医疗问答数据集：# 从HuggingFace下载数据集 wget https://huggingface.co/datasets/keivalya/MedQuad-MedicalQnADataset/resolve/main/train.jsonl wget https://huggingface.co/datasets/keivalya/MedQuad-MedicalQnADataset/resolve/main/test.jsonl💭 注意：下载原始 JSONL 文件后，需要创建测试拆分，并删除冗余的 qtype 字段。数据集格式应为每行一个 JSON 对象，至少包含 question 和 answer 两个字段：{"question": "What is diabetes?", "answer": "Diabetes is a chronic disease..."}配置好数据集后，我们需要安装 Ianvs 和相关依赖。首先克隆 Ianvs 仓库：cd /ianvs/project git clone cid:link_2git cd ianvs安装系统依赖和 Ianvs 核心依赖：# 安装Ianvs核心 sudo python setup.py install # 安装PEFT相关依赖 pip install transformers==4.30.0 pip install peft==0.4.0 pip install datasets==2.12.0 pip install accelerate==0.20.3 pip install sentencepiece==0.1.99 pip install protobuf==3.20.3我们使用 ChatGLM-6B 作为基础大语言模型，需要先下载模型权重：cd /ianvs/project mkdir models cd models # 从HuggingFace下载ChatGLM-6B模型 git lfs install git clone https://huggingface.co/THUDM/chatglm-6b▍3.2 配置文件修改示例代码放在[3]下，我们需要修改相关配置文件中的路径。首先配置算法参数，编辑 algorithm/algorithm.yaml：# 修改模型路径 modules: -type: "basemodel" name: "model" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/model.py" hyperparameters: model_name: "/ianvs/project/models/chatglm-6b" save_dir: "/ianvs/project/fedllm_output" initial_model_url: "/ianvs/project/models/chatglm-6b" peft_method: "lora"# 可选"lora" 或"ptuning" batch_size: 1 learning_rate: 0.0001 local_epochs: 2 -type: "aggregation" name: "FedAvg-PEFT" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/FedAvg-PEFT.py"然后配置测试环境，编辑 testenv/testenv.yaml：# 修改数据集路径 dataset: train_data: "/data/fedllm_datasets/train.jsonl" test_data: "/data/fedllm_datasets/test.jsonl" # 配置联邦学习参数 round: 5 gpu_num: 4 client_number: 4 if_mode_llm: true # 配置评估指标路径 metrics: -name: "rouge1_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/rouge1_metric.py" -name: "rouge2_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/rouge2_metric.py" -name: "rougel_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/rougel_metric.py" -name: "bleu4_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/bleu4_metric.py"最后配置基准测试作业，编辑 benchmarkingjob.yaml：workspace: "/ianvs/project/fedllm_workspace" testenv: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/testenv.yaml" algorithm: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/algorithm.yaml" rank: sort_by: "rouge1_metric" visualization: mode: "select_all"▍3.3 运行联邦微调配置完成后，设置 Python 路径并运行基准测试：# 设置Python路径 export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/federated-llm/fedllm-peft # 运行FedAvg-LoRA联邦微调 cd /ianvs/project/ianvs ianvs -f examples/federated-llm/fedllm-peft/benchmarkingjob.yaml▍3.4 尝试不同配置如果想尝试不同的 PEFT 方法或聚合算法，只需修改 algorithm.yaml 中的相应参数：# 使用P-Tuning代替LoRA： peft_method: "ptuning" # 使用FedAvgM代替FedAvg： aggregation: name: "FedAvgM-PEFT" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/FedAvgM-PEFT.py" hyperparameters: beta: 0.7 server_lr: 1.0▍3.5 查看结果训练完成后，结果将保存在工作目录中，包括：排行榜显示不同算法组合的性能对比详细的评估指标（ROUGE-1、ROUGE-2、ROUGE-L、BLEU-4）训练日志和模型检查点您可以在/ianvs/project/fedllm_workspace目录下查看完整的实验报告和可视化结果。相关链接[1] MedQuad医疗问答数据集实验研究：HuggingFace- keivalya/MedQuad-MedicalQnADataset[2] Ianvs官方文档：cid:link_0[3] 配置文件示例代码：/ianvs/project/ianvs/examples/federated-llm/fedllm-peft 参考文献[1] McMahan, H. B., Moore, E., Ramage, D., Hampson, S., & Aguera y Arcas, B. Communication-Efficient Learning of Deep Networks from Decentralized Data. In AISTATS, 2017[2] Hsu, T.-M. H., Qi, H., & Brown, M. Measuring the Effects of Non-Identical Data Distribution for Federated Visual Classification. arXiv:1909.06335, 2019[3] Fan, T., Kang, Y., Ma, G., Chen, W., Wei, W., Fan, L., & Yang, Q. FATE-LLM: A Industrial Grade Federated Learning Framework for Large Language Models. In Symposium on Advances and Open Problems in Large Language Models (LLM@IJCAI'23), 2023[4] Liu, X., Ji, K., Fu, Y., et al. P-Tuning v2: Prompt Tuning Can Be Comparable to Fine-tuning Universally Across Scales and Tasks. arXiv:2110.07602, 2021[5] KubeEdge. Ianvs: Distributed Synergy AI Benchmarking Framework. GitHub repository: cid:link_2 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

Karmada 非常高兴地宣布， Wellhub正式加入 Karmada 用户组，成为社区的重要成员。作为云原生计算基金会（CNCF）旗下项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。Wellhub的加入将进一步加强 Karmada 社区，为项目的持续创新带来新的活力，标志着我们社区发展和 Karmada 在多样化生产环境中采用的又一个重要里程碑。▍Wellhub，驱动全球企业健康转型的数字引擎Wellhub （https://wellhub.com/en-us/）秉持一大使命：助力每家企业转型为健康型企业，让员工每日关注自身身心健康状态。为此，平台推出高性价比、一站式综合服务方案，全面守护员工的身体、心理、营养与情绪健康。依托 Wellhub，员工无论居家还是在职场，都能主动建立并长期坚持健康的日常生活作息。目前，全球 11 个国家超 19000 家企业已选用 Wellhub，为数百万员工提供行业顶尖的企业健康福利项目。该项目经实践验证，能大幅提升员工参与度与投入度。Wellhub 可使参与健康管理的员工数量实现翻倍增长。员工的广泛参与，能让企业人员流失率降低 40%，同时为企业节省最高 35% 的医疗相关开支。 ▍技术落地：通过Karmada实现多集群资源统一管理随着业务快速扩张，Wellhub 构建了大规模的多集群 Kubernetes 环境，需要高效管理分布在不同地域和云上的服务网格配置。在生产环境中，Wellhub 采用 Karmada 作为多集群编排平台，核心使用场景是大规模分发 Istio 资源。通过 Karmada 的 Propagation 策略，Wellhub 构建多集群架构将 VirtualService、DestinationRule 和 ServiceEntry 等 Istio 关键资源一键分发到整个集群舰队（fleet），实现服务路由、流量治理和外部服务注册的统一管理。作为其云原生基础设施的重要组成部分，该实践不仅提升了平台的可扩展性，也降低了多集群管理的运维成本，帮助工程团队将更多精力投入到业务创新和健康体验优化上。与此同时，Wellhub 的案例为其他大规模采用 Istio + Kubernetes 的企业提供了宝贵参考，尤其适合拥有全球分布式集群、需要统一治理服务网格配置的组织。 ▍欢迎加入Karmada用户组Karmada 用户组是一个由在其环境中成功采用 Karmada 的组织和用户组成的社区。加入用户组可与同行深度交流协作并共享最佳实践，优先获悉关键版本更新与安全通知。此外，成员还将受邀参与 KubeCon 等官方活动，享有社区职位发布、拓展潜在商业合作等专属权益：🔖 Karmada adopter-group：cid:link_1您可以在 GitHub 社区仓库中了解更多关于 Karmada 用户组的信息，截至目前，Karmada 用户组已吸纳来自全球的 40+ 家企业和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters您是否在生产环境中使用 Karmada ？欢迎加入Karmada用户组！访问下方 Karmada 用户组申请链接 ，提交 issue 申请，即可接收申请进度：Karmada 用户组申请表单: cid:link_0 扫码加入用户组如需了解更多关于 Karmada Adopter Group 的信息，请联系：Maintainer Mailing List：cncf-karmada-maintainers@lists.cncf.io 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

华为云云容器引擎CCE近期推出多项核心能力升级，从可观测性、技术栈前沿性、操作便捷性等维度，全面进化您的云原生体验，助力业务高效、稳定、安全地运行。欢迎体验！

欢迎阅读【LLM推理】专栏系列文章，在首个系列，我们将带来大模型智能推理方向开源项目Kthena技术解析： ★【第一期】《Kthena 核心原语：ModelServing CRD 如何定义分布式推理的“新标准”？》★【第二期】《Kthena Router：插件架构解析及Benchmark测试》（本文）★【第三期】《Kthena AutoScaling：深度解析 Kthena 如何通过“语义感知弹性”重塑 AI 推理成本》★ 项目地址：cid:link_0/ 本文深入分析 Kthena Router 中 ScorePlugin（评分插件） 模块的系统设计与实现。该模块利用可配置、可插拔的架构，实现了推理请求的多维度评分和智能路由。我们将详细探讨目前已实现的六种 ScorePlugin，并构建一个基于 DeepSeek-R1-Distill-Qwen-7B 模型的标准化基准测试环境，评估不同调度策略在长、短系统提示词（System Prompt）场景下的性能表现。实验结果表明，在长系统提示词场景下，“KVCacheAware 插件 + Least Request 插件”的组合实现了 2.73 倍的吞吐量提升，并将 TTFT（首字延迟）降低了 73.5%。这显著优化了整体推理服务性能，验证了缓存感知调度对于长文本推理的核心价值。1. 背 景  随着大语言模型（LLM）推理需求的爆炸式增长，如何高效利用 GPU 资源并降低延迟成为核心挑战。传统的负载均衡器（如简单轮询或随机分发）在处理 LLM 推理请求时显得捉襟见肘，因为它们无法感知后端的实时负载、KV Cache 状态以及预填充（Prefill）与解码（Decode）分离的复杂需求。Kthena 作为一个云原生、高性能的 LLM 推理路由与调度系统，通过其 ScorePlugin 机制提供了灵活的流量管理能力。2. ScorePlugin 架构设计  ScorePlugin 采用插件化设计，允许用户根据业务场景自由组合不同的评分逻辑。type ScorePlugin interface { Name() string Score(ctx *Context, pods []*datastore.PodInfo) map[*datastore.PodInfo]int }每个插件会根据特定的指标为候选后端（Pod）打分，Router 最终汇总这些分数并选择得分最高的节点转发请求。目前 Kthena 实现了以下六种核心插件：① GPU Cache Usage Plugin： 实时监控 Pod 的 GPU 显存缓存使用率，优先调度到使用率较低的节点以降低显存溢出风险。② Least Request Plugin:通过优先将任务调度到已缓存所需数据的节点，显著降低数据传输开销并缩短大模型等任务的启动延迟。③ Least Latency Plugin： 根据监控到的首字延迟（TTFT）和单字生成延迟（TPOT）指标进行打分，优先选择性能表现更优的 Pod。④ KVCacheAware Plugin：核心插件。 它通过计算请求的提示词（Prompt）与后端 Pod 中已缓存内容的匹配度进行评分。匹配度越高，得分越高。这能极大提高 KV Cache 复用率，减少 Prefill 阶段的计算量。⑤ Prefix Cache Plugin： 利用字节级前缀匹配算法和 LRU 淘汰机制，优先选择具有最长前缀匹配记录的 Pod 以提升缓存效率。⑥ Random Plugin: 在候选节点中随机选择，适用于对调度要求不高的简单场景。3. ScorePlugin 插件实现细节  3.1 GPU Cache Usage 插件（GPU 缓存使用率插件）一种基于 GPU 显存缓存利用率 的资源感知型调度策略。算法原理：实时监控每个 Pod 的 GPU 缓存使用率 (GPUCacheUsage)。评分函数：Score = (1.0 - GPUCacheUsage) x 100优先选择 GPU 缓存占用较低 的 Pod，从而降低显存溢出（OOM）的风险。适用场景： 显存资源受限或显存压力较大的环境。3.2 Least Request 插件（最少请求插件）一种基于 活动请求队列长度 的负载均衡策略。▍算法原理：监控指标：正在运行的请求数：RequestRunningNum等待队列长度：RequestWaitingNum基础负载计算：base = RequestRunningNum + 100 x RequestWaitingNum归一化评分：score = ((maxScore - baseScores[info]) / maxScore) x 100▍关键设计细节：将等待队列的权重因子设置为 100，旨在严厉惩罚已有请求堆积的 Pod。实现 动态负载感知 的均衡分布。3.3 Least Latency 插件（最低延迟插件）一种以 推理延迟指标 为驱动的性能导向型调度策略。▍算法原理：监控指标：TTFT (Time To First Token，首字延迟)TPOT (Time Per Output Token，单位输出 Token 延迟)归一化处理： ScoreTTFT = （MaxTTFT - CurrentTTFT）/ （TTFT - MinTTFT）x 100 ScoreTPOT = （MaxTPOT - CurrentTPOT）/（MaxTPOT - MinTPOT）x 100最终加权评分： Score = α x ScoreTTFT + (1 - α) x ScoreTPOT▍配置参数：TTFTTPOTWeightFactor:0.5 # TTFT 权重因子 α3.4 KVCacheAware 插件（KV 缓存感知插件）一种利用 KV 缓存命中率 的高级 缓存感知调度策略。技术亮点：Token 级语义匹配：使用特定模型的 Tokenizer 进行精确分词。分布式缓存协同：通过 Redis 实现跨 Pod 的状态同步。优化连续块匹配算法：最大限度提高缓存命中率。算法工作流：① 分词阶段 (Tokenization)输入 → 模型特定 Tokenizer → Token 序列 [t₁, t₂, ..., tₙ]② 分块切割 (Block Segmentation)Token 序列 → 固定大小的数据块 [B₁, B₂, ..., Bₘ] 数据块大小：128 tokens（可配置）③ 哈希生成 (Hash Generation)对每个 Bᵢ 计算：Hash(Bᵢ) = SHA256(Bᵢ) → hᵢ④ 分布式缓存查询Redis 管道查询： 针对每个 hᵢ → 获取 {Pod₁: 时间戳₁, Pod₂: 时间戳₂, ...}⑤ 连续匹配评分Score = (连续匹配的数据块数量 / 总块数) × 100配置示例：blockSizeToHash:128 # Token 块大小 maxBlocksToMatch:128 # 最大处理块数Redis 键值结构：Key Pattern: "matrix:kv:block:{model}@{hash}" Value Structure: { "pod-name-1.namespace": "1703123456", "pod-name-2.namespace": "1703123789" }3.5 Prefix Cache 插件（前缀缓存插件）一种基于 长前缀缓存 的感知调度策略。架构设计：三层映射：模型 (Model) → 哈希 (Hash) → Pod。基于 LRU 的缓存淘汰：实现高效的内存管理。Top-K 前缀匹配策略：返回具有最长前缀匹配的前 N 个 Pod。主要特性：字节级前缀匹配算法。优化的内存级 LRU 实现。缓存容量和候选 Pod 数量可配置。3.6 Random 插件（随机插件）一种 轻量级的随机负载均衡策略。实现方式：生成均匀分布的随机分数： Score ~ Uniform(0, 100)采用线程安全的独立随机数生成器。无状态设计，确保长期的负载分布均衡。适用场景：模式不明显的混合工作负载。追求极低调度开销的轻量级部署。作为性能对比的基准线（Baseline）。4. 实验设计与性能评估  4.1 实验步骤为了验证不同插件组合的实际效果我们建立了一个标准化的测试环境：表 1: 实验环境配置4.2 性能测试结果分析4.2.1 长系统提示词场景 (4096 tokens)表 2: 性能指标 – Long Prompt在处理具有长固定前缀（System Prompt）的并发请求时，KVCacheAware + Least Request 组合表现出了压倒性优势：吞吐量 (Throughput): 提升了 2.73倍。由于大量请求命中了同一 Pod 上的缓存，避免了重复计算。TTFT (首字延迟): 降低了 73.5%。缓存命中意味着 Prefill 阶段几乎瞬间完成，用户感知的响应速度极大提升。4.2.2  短系统提示词场景 (256 tokens)表 3: 性能指标 – Short Prompt在短示词场景下，各插件表现相对平稳，但 Least Request 依然在保持负载均衡、防止单点过热方面优于传统的 RoundRobin。5. 场景化部署建议  5.1 高缓存命中场景推荐配置：KVCacheAware 插件（KV缓存感知） + Least Request 插件（最少请求）适用用例：智能客服机器人、代码生成以及类似的高度结构化工作负载。带有长系统提示词（System Prompts）的多轮对话。基于模板的内容生成服务。5.2 常规负载均衡场景推荐配置：Least Request 插件（最少请求） + Least Latency 插件（最低延迟）适用用例：具有多样化请求模式的通用推理服务。需要公平分配资源的多租户环境。实时交互式应用。5.3 资源受限环境推荐配置：GPU Cache Usage 插件（GPU缓存使用率）适用用例：显存（GPU Memory）有限的边缘计算部署。对成本敏感的云端环境。多个模型共享底层 GPU 资源的场景。6. 总 结  Kthena 通过 ScorePlugin 机制，将原本复杂的推理调度逻辑拆解为可组合的模块。实验证明：缓存感知 (KV Cache Awareness) 是提升 LLM 推理效率的关键，尤其是在 RAG（检索增强生成）和长文本场景中。多插件协同（如 KVCache + Least Request）能够兼顾“缓存复用”与“负载均衡”，达到最优的综合性能。作为 Volcano 的子项目，Kthena 致力于将 Volcano 的调度优势从 AI 训练扩展到推理领域，为企业提供从训练到推理的完整全栈解决方案。 🌋 Kthena GitHub地址：cid:link_0 🌋 更多信息，欢迎访问 Volcano 官网： https://volcano.sh  欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！扫码回复“Kthena” 进入技术群