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

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

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

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

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

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

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

你以普通用户 appuser 执行 ./start.sh，报错 Permission denied。但 ls -l start.sh 显示 -rwxr-xr--，你是文件所有者。可能是什么原因？如何解决？

使用 frp 做内网穿透，本地服务正常可以访问，公网访问 frp 服务端却连接失败，有哪些高频排查点？

一台 2 核 2G 的 Linux 服务器，部署 Nginx 做反向代理，访问网站偶尔出现 502 Bad Gateway，请问最常见的 3 个可能原因是什么？

简述什么是IP地址，IP地址在网络通信中的作用是什么？

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

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

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

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