随着大模型向长上下文（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技术交流群

随着大模型向长上下文（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/v1alpha1 kind: ModelRoute metadata: name: deepseek-v4 namespace: default spec: modelName: "deepseek_v4" rules: - name: "default" targetModels: - modelServerName: "deepseekv4-pd" --- apiVersion: networking.serving.volcano.sh/v1alpha1 kind: ModelServer metadata: name: deepseekv4-pd namespace: default spec: 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: mooncake EOF3. 验证部署与测试完成上述三个 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_3 欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

在云原生时代，Kubernetes集群的运维复杂度正在以指数级增长。Pod频繁重启、节点异常、告警风暴、容量风险……每一类问题背后，都涉及Pod、节点、事件、日志等多层资源的交叉关联，人工定位链路长，判断成本极高。华为云云原生Skills的诞生，正是为了解决这一困境——将专业知识、操作流程和最佳实践转化为可复用的能力单元，让AI Agent具备专业的云原生运维能力。 什么是云原生Skills？Skill是将专业知识、操作流程和最佳实践转化为可复用能力单元的开放范式。在AI Agent体系中，Skill使Agent能够按照预定义的流程和规则，自动执行特定领域的复杂任务。华为云云原生Skills承接该范式，将专家经验沉淀为Agent可调用的能力模块，为企业的云原生运维提供了一条从传统人工排障向 Agentic Ops 演进的新路径，既支持在现有运维体系中嵌入AI提效，也支持为关键业务构建Agent原生的诊断与恢复模式：全栈可观测覆盖：云原生Skills整合CCE、AOM、LTS、ELB、ECS、HSS等云服务的运维能力，可自动汇聚告警、日志、K8s事件、Pod/Node指标形成诊断上下文，覆盖故障诊断、可观测分析、巡检治理、自动恢复等场景。意图驱动的智能诊断：Agent通过读取Skill的description自动理解触发时机，用户只需用自然语言描述故障现象，无需显式指定Skill。Agent即可完成从现象识别、证据采集、根因分析到恢复方案的全流程诊断。场景化编排与闭环：单个Skill内部串联多个操作步骤，自动完成上下文收集、分析和结论输出，一站式闭环。多个Skill可按工作流组合使用，Agent根据任务需要自动选择和调用合适的Skill组合。Agent友好与安全可控：Skill以独立目录提供，可在Web、CLI、API等不同Agent平台上运行，无需为每个平台单独适配。内置风险分级机制与安全护栏，所有删除、扩缩容、drain等变更类操作必须先预览、再经用户确认后方可执行。 从故障诊断到主动治理：典型应用场景全覆盖华为云云原生Skills覆盖了云原生运维的全链路场景：故障诊断：Pod CrashLoopBackOff、节点NotReady、Ingress 502、PVC Pending等常见故障分析。可观测分析：汇聚AOM告警、LTS日志、K8s事件、Pod/Node指标形成诊断上下文。巡检治理：每日集群健康检查、容量趋势预测、成本优化建议、可用性风险扫描。自动恢复：扩缩容、cordon/drain节点、重启ECS、HSS漏洞修复等受控变更。交付方案：容器迁移规划、资源盘点、依赖矩阵分析。集群管理：CCE集群升级规划、工作负载管理、UCS集群纳管与策略治理。 让智能运维落地有声：最佳实践华为云提供了丰富的最佳实践，帮助用户快速上手： ▍实践一：使用AI CLI对CCE工作负载进行故障诊断与恢复  基于用户描述的故障现象（如Pod长时间未就绪、容器频繁重启、镜像拉取失败等），AI Agent自动完成上下文识别、证据采集、根因分析、恢复方案预览、用户确认、恢复执行和结果验证的全流程。 ▍实践二：配置、查询和治理CCE AOM告警 用户用自然语言完成CCE AOM告警规则配置、查询、聚合分析和严重告警根因追查。 AI CLI会自动归并同类告警，帮助用户快速判断“哪些告警最紧急、影响哪些资源、下一步应该查什么”。 ▍实践三：集群定期巡检 通过OpenClaw Agent用自然语言配置周期性巡检任务，自动完成集群健康检查、告警聚合、异常分析、风险分级、报告生成和通知推送。巡检过程只执行只读查询，不会自动执行任何变更动作。 ▍实践四：配置CCE集群秒级弹性至CCI 2.0通过提示词即可自动完成集群预检、插件安装及网络配置，采用预览确认机制，用户确认后执行，支持短时高负载场景下的秒级弹性伸缩。 ▍实践五：ChatOps智能运维 基于Hermes构建生产环境智能运维Agent ，定时扫描现网告警，自动归并分析，生成恢复方案，在手机端确认后执行恢复动作。将“告警发现→归并→上下文采集→根因分析→恢复预览→用户确认→执行恢复→效果验证→结果归档”沉淀为可复用的ChatOps值班能力。 让运维经验可传承、可进化华为云云原生Skill当前已上线云容器引擎CCE服务官网，用户可在各类Agent客户端中安装调用。它将华为云在云原生领域积累的诊断经验与运维最佳实践，封装为开放的能力单元，让企业无需从零构建，即可获得开箱即用的智能运维能力——从诊断到恢复，对话即完成。让AI读懂云原生，让运维回归创造性工作——这正是华为云云原生Skills的使命所在。 立即体验：cid:link_1  

开发者专属免费考证福利来了！【云学堂·云原生技术实战营】活动正式开营！集齐5个微认证兑换云原生入门级开发者认证证书。 一、【活动时间】2026年 06月 15日 - 2026年 09月 30日二、【报名链接】cid:link_1三、【活动福利】1、每通过1门微认证考试→获得对应华为云官方微认证证书2、通过指定5门云原生微认证→免费兑换华为云云原生入门级开发者认证证书3、一键免费领取华为云码道体验版，开启你的编码自动驾驶模式！四、参与流程Step1、AI智能编码辅助工具体验，0 门槛上手，小白也能变大神​！支持 Java/Python/Go 等 7 种主流语言，代码生成、注释、调试、翻译一键搞定！一键免费领取体验版：https://developer.huaweicloud.com/codeartsco.html?source=dmznteducation&sourcead=dmznthd，立即体验，开启你的编码自动驾驶模式！ Step2、集齐5个微认证证书免费兑换云原生入门级开发者认证证书序号认证名称（含免费激活入口）1云原生基础设施之容器入门2云原生基础设施之容器进阶3基于CCE Kubernetes编排实战4CCE网络与存储实战5云容器快速搭建网站通过序号1-5微认证且获得证书后，点此兑换云原生入门级开发者证书（我的认证→我的证书兑换）【考试说明】1、云原生5个微认证无需购买，点击表格中认证名称进入认证详情页，点击“免费激活”按钮即可，如考试未通过可再次点击“免费激活”。2、云原生5个微认证需要理论考试≥70分+实验考试≥60分才算考试通过。3、考试通过后第1个自然日后将发放证书，可前往我的学堂- 我的证书查看证书编号和下载电子证书。 不管是入门新手、在校同学还是职场开发者，都可以一站式学练考！

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，进入技术交流群

随着大模型技术的飞速发展，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，进入技术交流群

随着大模型技术的飞速发展，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” 进入技术群