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

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

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

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

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

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

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

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

作者 | Rain Zhang; Qi Zhang; Jian HuangAgent Harness 在云原生托管架构落地的核心意义在于实现弹性、效率与运维的全面优化。借助云原生的虚拟化、容器化与动态编排能力，Agent Harness 能够打破资源闲置的瓶颈，实现按需自动扩缩容，显著降低计算成本。同时，云原生的声明式 API 和服务自愈机制，将复杂的生命周期管理转化为自动化运维，极大减轻了人工负担。此外，依托统一的可观测性与标准化交付流程，Agent Harness 可以无缝集成现有技术生态，加速 AI 代理从原型到生产级应用的转化，从而为企业提供高可靠、低成本且易于治理的智能服务运行底座。▍1. Agent Harness 面向云原生托管的落地挑战当前 Agent Harness 在面向云原生托管架构落地过程中，主要面临冷启动延迟、状态持久化与执行安全三个维度的核心挑战，业界主流方案正通过架构解耦、轻量级虚拟化以及工程化治理来系统性地加以应对。首先，在冷启动延迟和资源浪费方面，传统虚拟机或容器的启动往往需要数秒时间，难以满足 AI 交互场景对实时性的严苛要求。其结果表现为用户等待时间被拉长，使用体验受到明显影响。为了降低延迟，不少系统采用预留“热池”的方式，但这又导致资源利用率在闲时极低，资源浪费严重，而当突发流量来临时，系统的性能表现也不够稳定。其次， 在稳定性与成本控制方面，问题主要体现在上下文窗口的有限性与状态执行的脆弱性上。由于上下文窗口存在上限，任务运行时间较长时容易出现“遗忘”或崩溃现象。一旦沙箱发生故障，正在执行的任务便会直接终止，长任务因此中断且无法恢复，进而引发记忆混乱、运维负担加重以及成本失控等问题。最后，在安全隔离方面，主要风险来自不可信代码的执行以及凭据的泄露。大语言模型生成的代码本身不可信，存在逃逸的潜在威胁。如果凭据与可执行代码同处一个沙箱环境中，提示词注入攻击便可能导致密钥泄露，进而引发系统被破坏、数据泄露、跳板攻击以及权限越级滥用等严重后果。 ▍2. 面向云原生托管 Agent Harness Infrastructure 的设计为了解决上述痛点，华为云托管的 Agent Harness 提出了从架构设计到 Agent Infrastructure 基础设施的解决方案。 对于企业而言， Agent Infrastructure基础设施不再将精力耗费在维护脆弱的单体容器上，而应转向构建 Agent 沙箱容量规划与并行调度、Agent 协调层和执行层架构解耦、具备极简轻量、极速启动、自动恢复能力和安全隔离的 Serverless 沙箱环境。图 1. Agent 猎鹰调度与羽量沙箱Agent 沙箱并行规划与调度通过采用容量预测技术，对 Agent 资源进行精准画像与预热管理。与传统基于时序的算法相比，该模型将拟合精准度提升30%，资源碎片率降低25%，利用率提高10%。在并行调度方面，系统基于资源碎片率、资源余量和预热分配量三个维度的因素，采用分片并行调度机制，使调度吞吐量显著提升至原来的5倍。在生态主导方面，项目在 CNCF 社区内主导了 Volcano 沙箱调度器生态的建设，吸引了超过200家公司参与使用，形成了良好的社区影响力与客户基础。Agent 协调层和执行层架构解耦，实现自动恢复能力采纳轻量级虚拟化技术（microVM），将 Agent Harness 协调层 与 Sandbox 执行层 彻底解耦，支持 Serverless 按需模式，配置合理的闲置超时回收策略。通过 SessionID 保证多轮对话路由到同一实例维持状态，并将会话日志外置持久化。Harness 故障后，新实例可重放日志恢复任务，实现“断点续传”。图 2. Agent  Runtime 运行时架构安全隔离使用 microVM 级 VMM（CloudHypervisor），最小化设备集和每 VM 进程开销（3‑13MiB量级）。在单节点数千并发沙箱规模下，通过 microVM、定制 Guest 环境和动态资源控制，实现 VM 级安全隔离与高密度的兼得。强制隔离 Harness 与 Sandbox，实施最小权限原则与凭据托管。极简轻量华为云针对 Agent 与容器场景进行了极致优化，构建了由“基础操作系统 ContainerOS + 动态生成操作系统 On-the-fly OS”相结合的组合方案,  实现羽量级虚拟化，匹配 Agent 和 Serverless 场景对开销和速度的极致诉求。其中，ContainerOS 仅包含运行容器所必需的基础服务，On-the-fly OS 根据 Agent 运行需求组装和构建所需的 OS 的增量系统 。该方案采用轻量化的内核与根文件系统，可实现秒级启动，且空载状态下的内存占用低于50M字节。作为不可变基础设施，基础操作系统的根文件系统为只读，并以镜像为粒度进行原子化的升级与回滚操作。极速启动通过对 Sandbox 依赖资源及关键流程的预置，系统在计算、网络、存储及启动文件等方面提前准备，将资源准备时间从秒级压缩至毫秒级。在启动优化方面，采用操作系统裁剪与共享内存技术加速虚拟机启动，同时结合快照启动、Fork 机制以及容器组件的预热与重用，使实例创建时间从十秒级缩短至100毫秒。此外，基于预热实例的分层管理能力，系统根据供给性能构建分层预热池，并依据客户使用特征持续优化预热策略，最终将预热命中率提升至冷启动实例占比的80%。图3. Agent Sandbox 启动过程 ▍3. 工作展望：面向 AI Agent 与 Serverless 场景的极致高效、低成本的云原生沙箱体系围绕云原生架构， 后续工作会持续打磨优化 AI Agent 与 Serverless 场景的极致高效、低成本的安全沙箱体系，核心方案围绕以下三个目标展开：图4. 基于预调度 + Snapstart + lazyloading的microVM启动首先，为了应对云原生时代不同场景对安全隔离与弹性效率的多样化需求，以 CNCF （云原生计算基金会）旗下的多沙箱容器运行时项目 Kuasar 为底座，通过采用单 VM 单应用的极简架构，并剔除 Guest Agent 等冗余组件，打造出轻量化的 Appliance Sandbox 模式，目标是使单沙箱的底噪降低20%。图5. 云原生计算基金会CNCF多沙箱容器运行时项目Kuasar其次，为了实现亚秒级甚至百毫秒内的极速启动，方案扩展了 VMM 以支持基于 UFFD 的内存缺页 Hook，实现内存懒加载，并将 Snapstart 作为 Kuasar 的标准启动方式，同时结合虚拟机内存只读页面的复用技术，在降低资源消耗的同时确保单沙箱启动延迟小于100毫秒。最后，为了支撑大规模、高并发的创建需求，即持续10分钟每分钟创建10万个沙箱，方案设计了一个基于块级复用与内容寻址技术的镜像分发底座。该底座在多租户云系统中，将不同租户的镜像数据切块并计算指纹：相同指纹的数据块在多租户间复用，不同指纹的则按租户隔离存储，同时通过全链路块级加密保障安全合规。最终，这一设计在同构工作负载下实现了10倍的存储与带宽缩减，大幅降低了总成本，达成了成本优化与安全合规的双重竞争力。图6. microVM 的快速启动和批量创建 ▍4. 总结面向云原生托管的 Agent Harness 为企业提供了一套完整的 Agent 基础设施解决方案，核心在于将精力从维护单体容器转向构建 Serverless 沙箱环境。该方案通过容量预测与分片并行调度，显著提升了资源利用率和调度吞吐量；利用轻量级虚拟化技术实现协调层与执行层解耦，支持断点续传的自动恢复。在安全方面，采用 microVM 级隔离实现高并发下的安全防护。同时，通过组合式轻量操作系统实现低内存占用与秒级启动，并借助资源预置、快照及预热重用等优化，将实例创建时间缩短至100毫秒，预热命中率达冷启动的80%，从而构建出极简轻量、极速启动且安全隔离的沙箱环境。 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

一次典型的 Code Interpreter 调用，往往从一个很小的动作开始：用户点击“运行代码”。但在一个原生 Kubernetes 环境中，这个动作背后通常意味着一整套秒级链路：调度 Pod、分配网络、拉取镜像、启动容器。对于需要多步推理、频繁调用工具、强依赖交互体验的 AI Agent 应用来说，这样的启动路径并不自然。这也是 AgentCube 试图解决的问题：在 Kubernetes 的算力底座之上，补齐面向 Agent 工作负载的关键机制缺口，提供一层真正理解会话、沙箱和工具调用语义的 Serverless 编排层。AgentCube（cid:link_2） 提供了一组可直接落地的核心机制。本文重点展开这些能力在实现层面的设计取舍：会话如何绑定沙箱、预热池如何消除冷启动、PicoD 如何替代 SSH、JWT 安全链如何保护外部访问，以及系统如何自动回收不再活跃的沙箱资源。  从 Kubernetes 到 Agent Native  随着大语言模型（LLM）技术的成熟，技术架构正从“无状态推理”向“自主智能体（Autonomous Agents）”演进。Kubernetes 凭借成熟的生态和对异构算力的标准化管理，已经成为构建 AI 基础设施的事实标准。但在面对 AI Agent 这种“高并发、短时效、强状态依赖”的新型负载时，原生 Kubernetes 仍存在几类明显的粒度错配与机制缺位。启动延迟与交互体验的矛盾。 Agent 的交互通常要求毫秒级响应，而原生 K8s Pod 的启动流程往往是秒级甚至分钟级。对于需要频繁拉起 Code Interpreter 或临时子 Agent 的场景，这样的冷启动延迟很难被终端用户接受。资源利用率的挑战。 Agent 是典型的 IO 密集型负载。在一次会话中，大量时间都消耗在等待 LLM 返回 Token 或等待外部工具响应。如果在 K8s 上为每个 Agent 独占一个 Pod，CPU 和内存资源会在等待期间被大量闲置。会话状态管理的缺失。 K8s 对无状态工作负载天然友好，但 Agent 高度依赖上下文（Context / Memory）。Pod 的重建意味着内存态上下文的丢失，开发者被迫在应用层额外拼接外部状态存储，系统复杂度和网络开销都会随之上升。安全隔离难题。 高级 Agent（如 Data Analyst）需要运行由 LLM 生成的不可信代码。普通的 runC 容器很难为这种场景提供足够强的隔离边界，企业级 Agent 平台需要一种既能快速启动、又具备强隔离能力的沙箱环境。围绕这些问题，AgentCube 给出了一组明确的工程实现：Kubernetes 面临的缺口AgentCube 的对应机制冷启动延迟高Warm Pool 预热池，提前准备可分配的沙箱实例会话请求需要保持上下文Session ID 到沙箱实例的绑定式路由不可信代码执行风险高MicroVM 沙箱 + PicoD 执行面 + JWT 认证链会话结束后资源容易堆积基于空闲超时和绝对时长的双策略 GCAgentCube 不是简单增加几条 CRD，而是在 Kubernetes 之上补上一层面向 Agent 工作负载的运行时与编排机制。  整体架构  AgentCube 的核心架构可以分为三部分：数据平面（Router）、控制平面（Workload Manager） 和 沙箱执行面（PicoD）。系统通过 Redis/Valkey 维护会话状态和索引，使不同组件可以独立扩展。图 1：AgentCube 整体架构 —— Router 接收请求并路由至沙箱，Workload Manager 管理沙箱生命周期，PicoD 负责沙箱内执行核心组件一览：组件角色关键能力AgentCube Router数据平面入口HTTP 反向代理、会话路由、JWT 签名、并发控制Workload Manager控制平面沙箱创建/删除、预热池管理、双策略 GCPicoD沙箱内守护进程代码执行、文件 I/O、JWT 认证、路径沙箱化Session Store状态存储Redis/Valkey 支持，Sorted Set 索引加速查询一次典型请求的大致链路如下：+----------+ +----------+ +------------------+ | Client | --- 1) HTTP ---> | Router | --- 2) alloc --> | Workload Manager | +----------+ +----+-----+ +--------+---------+ | | 4) sign JWT 3) create/claim + proxy Sandbox Pod | | v v +--------+ +-------------+ | PicoD | <-- running in --- | Sandbox Pod | +---+----+ +-------------+ | 5) verify JWT execute cmd return result | v stdout / stderr / exit_code图中的 Sandbox Pod 底层是由 Kuasar 调用 CloudHypervisor 拉起的 MicroVM，PicoD 作为守护进程运行在 MicroVM 内部，负责接收来自 Router 的请求并在隔离环境中执行。  核心特性深度解读  一、Session-Based MicroVM Routing：让会话真正绑定执行环境AI Agent 工作负载的一个本质特征，是有状态、交互式，并且可能跨越多次调用。一次完整的任务往往包含多步推理、工具调用、环境探查和中间结果写入。如果每个请求都被路由到新的执行环境，上下文就无法自然延续。AgentCube 通过 Session ID -> 沙箱实例 的绑定关系解决这个问题：客户端首次调用时不携带 x-agentcube-session-id，Router 会为其分配新的沙箱实例响应头中返回 x-agentcube-session-id客户端后续请求携带该 Session ID，即可继续命中同一个会话沙箱从客户端视角看，整个过程是透明的。它不需要理解底层沙箱的生命周期，只需要在多轮调用中带上同一个 Session ID。Router 基于 Gin 构建，核心 handler handleInvoke() 的逻辑大致如下：// 从请求头提取 Session ID sessionID := c.GetHeader("x-agentcube-session-id") // 通过 SessionManager 查找或创建沙箱 sandbox, err := s.sessionManager.GetSandboxBySession( c.Request.Context(), sessionID, namespace, name, kind) // 更新会话最后活跃时间（用于 GC 判定） s.storeClient.UpdateSessionLastActivity(ctx, sandbox.SessionID, time.Now()) // 反向代理转发至沙箱 s.forwardToSandbox(c, sandbox, path)Router 同时支持 HTTP/2 (h2c) 透传，并内置可配置的并发请求上限（默认 1000），避免突发流量直接冲垮后端沙箱集群。当前暴露的调用入口包括：POST /v1/namespaces/{namespace}/agent-runtimes/{name}/invocations/*path GET /v1/namespaces/{namespace}/agent-runtimes/{name}/invocations/*path POST /v1/namespaces/{namespace}/code-interpreters/{name}/invocations/*path GET /v1/namespaces/{namespace}/code-interpreters/{name}/invocations/*path二、两种 CRD：两种工作负载抽象AgentCube 在 Kubernetes 之上引入了两类核心 CRD，对应 AI Agent 领域里两种典型的运行模式：一种强调通用能力与灵活性，一种强调安全默认与沙箱约束。AgentRuntime：面向通用 Agent 的运行时抽象AgentRuntime 面向需要完整 Kubernetes 能力的对话式或工具调用型 Agent。它接受完整的 PodSpec 模板，因此可以挂载 Volume、注入凭据、配置 Sidecar 容器。apiVersion: runtime.agentcube.volcano.sh/v1alpha1 kind: AgentRuntime metadata: name: my-agent spec: podTemplate: containers: - name: agent image: my-agent:latest ports: - containerPort: 8080 targetPort: - pathPrefix: "/" port: 8080 protocol: HTTP sessionTimeout: 15m maxSessionDuration: 8hCodeInterpreter：面向安全代码执行的受约束抽象CodeInterpreter 更适合 Notebook、REPL、“运行代码”按钮等多租户安全执行场景。相比 AgentRuntime，它采用更受约束的模板能力，以便将隔离、运行时和资源限制统一收敛到更安全的默认值。apiVersion: runtime.agentcube.volcano.sh/v1alpha1 kind: CodeInterpreter metadata: name: my-interpreter spec: template: image: ghcr.io/volcano-sh/picod:latest runtimeClassName: kata resources: requests: { cpu: "500m", memory: "512Mi" } limits: { cpu: "2", memory: "2Gi" } warmPoolSize: 3 authMode: picod sessionTimeout: 15m maxSessionDuration: 8h两者的核心差异在于：AgentRuntime 更开放，优先满足复杂 Agent 应用的组合能力CodeInterpreter 更收敛，优先满足安全沙箱场景的开箱即用三、Warm Pool：预热池如何消除冷启动从零创建沙箱实例，会不可避免地引入启动延迟。对于交互式 Agent 场景，这种等待通常是用户最直接感知到的体验问题。为此，AgentCube 引入了 Warm Pool 预热池机制。+-----------------------------------------------------------+ | Warm Pool | | | | +-----------+ +-----------+ +-----------+ | | | Sandbox | | Sandbox | | Sandbox | <- idle | | | (idle) | | (idle) | | (idle) | | | +-----+-----+ +-----------+ +-----------+ | | | | | v new session --> SandboxClaim | | +-----------+ | | | Sandbox | <- claimed, ready to use | | | (active) | | | +-----------+ | | | | pool replenishes asynchronously | +-----------------------------------------------------------+Workload Manager 中的 CodeInterpreterReconciler 通过三层 CRD 协作完成这一机制：1. SandboxTemplate：定义沙箱实例模板，并注入 PicoD 所需的认证公钥2. SandboxWarmPool：声明预热副本数，维持一组可被直接认领的空闲实例3. SandboxClaim：新会话到来时，从池中认领一个已就绪实例这种做法的好处，是将“创建实例”和“分配实例”解耦。沙箱启动的慢路径前置到后台完成，用户请求只需走认领路径，因此可以显著缩短首跳延迟。整个过程是幂等的。Reconciler 在调和循环中只对不一致状态做最小变更，这也使 Warm Pool 的管理方式天然贴合 Kubernetes 声明式控制器的工作模型。面向更进一步的启动加速，社区后续计划集成 Kuasar Snapstart，通过内存快照进一步将沙箱就绪时间从秒级压缩至百毫秒量级。四、PicoD：替代 SSH 的轻量级沙箱守护进程传统代码沙箱方案通常依赖 SSH 进行远程执行。但对一个本质上是单请求 RPC 的场景来说，SSH 会引入过重的协议开销，包括密钥管理、多路复用协商和持久会话维护。PicoD（Pico Daemon）就是在这样的背景下被引入的。它运行在沙箱内部，通过一组精简的 HTTP API 代替 SSH，完成命令执行、文件读写和健康检查等操作。API 端点方法功能/api/executePOST执行任意命令，支持超时、工作目录、环境变量/api/filesPOST文件上传或写入（multipart 或 base64 JSON）/api/files/*pathGET文件下载或读取，支持流式传输/healthGET健康检查（免认证）PicoD 运行在 MicroVM 内部，外部请求在触达它之前已经穿越了 VM 级隔离边界。Router 对每个请求签发短期 JWT，PicoD 校验通过后才执行——这道认证门与 MicroVM 隔离分别在两个层次上独立生效。其执行逻辑的核心实现大致如下：ctx, cancel := context.WithTimeout(ctx, timeout) defer cancel() cmd := exec.CommandContext(ctx, command[0], command[1:]...) cmd.Dir = workspaceDir cmd.Env = mergedEnv if ctx.Err() == context.DeadlineExceeded { exitCode = 124 }对应的防护措施包括：路径沙箱化：通过 sanitizePath() 将文件访问限制在指定 workspace 根目录下请求体大小限制：默认 32 MB，防止恶意请求耗尽内存无状态处理模型：每个请求独立处理，避免持久连接带来的额外攻击面五、JWT 安全链：外部访问沙箱时，如何建立信任沙箱实例是临时资源，会随时被创建和销毁。如果在集群中直接分发共享密钥，密钥轮换和安全边界都会变得脆弱。为此，AgentCube 在 Router 与 PicoD 之间建立了一条基于 RSA 非对称加密 的认证链。+--------------+ +-------------------------+ | Router | | Kubernetes Secret | | | generate on boot | picod-router-identity | | RSA-2048 | ------------------> | | | key pair | | private.pem (Router) | | | | public.pem (PicoD) | +------+-------+ +------------+------------+ | | | sign with Workload Manager injects | private key PICOD_AUTH_PUBLIC_KEY | (5min TTL) into sandbox env | | v v +--------------+ RS256 JWT Token +--------------+ | Router signs | ------------------> | PicoD verify | | (private key)| | (public key) | +--------------+ +--------------+这条链路解决的是访问认证问题：Router 对外接收请求，对内使用私钥签发短时有效的 JWT；PicoD 持有公钥，负责校验请求是否合法。关键设计点包括：5 分钟短有效期：即使 Token 泄漏，影响范围也能被压缩到很小1 分钟时钟漂移容忍：兼顾分布式环境中的时钟偏差私钥不出 Router：PicoD 仅做校验，不持有签发能力启动时自动生成并注入：降低运维配置复杂度六、双策略 GC：如何回收不再活跃的沙箱在 Agent 场景下，资源创建不是难点，难点在于如何及时、稳定地回收已经闲置的沙箱。如果会话终止后资源不能自动回收，集群最终会被大量“已经没人使用、但仍然占资源”的实例拖垮。为此，AgentCube 在 Workload Manager 中实现了双重垃圾回收策略：策略触发条件默认值空闲超时（Idle TTL）沙在 sessionTimeout 内无任何请求15 分钟绝对最大时长（Max Duration）沙箱创建时间超过 maxSessionDuration8 小时GC 循环每 15 秒执行一次，每轮最多检查 100 个候选沙箱，避免单次 GC 扫描时间过长。底层索引结构基于 Redis Sorted Set：session:{sessionID} -> SandboxInfo JSON session:expiry -> Sorted Set (score = 到期时间戳) session:last_activity -> Sorted Set (score = 最后活跃时间)这种设计让系统可以用 ZRANGEBYSCORE 高效找出已过期或长期不活跃的会话。删除时，GC 会同时清理 Kubernetes 中的 Sandbox / SandboxClaim 资源和 Redis 中的会话记录，避免出现“实例删了但索引还在”或“索引删了但实例还活着”的不一致状态。  生态集成  除了运行时和沙箱机制，AgentCube 还提供了面向上层框架的接入能力，使应用开发者不需要直接处理底层基础设施细节。Python SDKfrom agentcube import CodeInterpreterClient interpreter = CodeInterpreterClient() result = interpreter.run_code("python", "print('Hello, AgentCube!')") print(result) interpreter.write_file(content="data", remote_path="/workspace/data.txt") interpreter.download_file("/workspace/data.txt", "./local_data.txt")LangChain / LangGraph 集成AgentCube 可以作为 LangChain 的 @tool 接入 ReAct Agent 工作流，将代码执行部分自然下沉到受隔离的沙箱环境中，应用层无需直接理解底层实例调度和生命周期管理。Dify 插件项目仓库中的 dify-plugin 目录提供了 Dify 工具接入方式，使 Dify 用户也可以直接消费 AgentCube 的沙箱能力。  快速上手  前置条件Kubernetes 集群 v1.24+Redis 或 Valkey 实例sigs.k8s.io/agent-sandbox v0.1.1 CRD 已安装Helm 安装helm install agentcube manifests/charts/base \ --namespace agentcube-system --create-namespace \ --set redis.addr=<redis-host>:6379 \ --set redis.password="<password>"创建第一个 CodeInterpreterapiVersion: runtime.agentcube.volcano.sh/v1alpha1 kind: CodeInterpreter metadata: name: my-interpreter namespace: default spec: template: image: ghcr.io/volcano-sh/picod:latest resources: requests: { cpu: "500m", memory: "512Mi" } limits: { cpu: "2", memory: "2Gi" } warmPoolSize: 2 sessionTimeout: 15m maxSessionDuration: 8h发起调用curl -X POST \ http://<router-host>/v1/namespaces/default/code-interpreters/my-interpreter/invocations/api/execute \ -H "Content-Type: application/json" \ -d '{"command": ["python3", "-c", "print(1+1)"]}'响应头中的 x-agentcube-session-id 即为会话 ID。后续请求继续携带它，就可以复用同一个沙箱执行环境。  致 谢  从项目启动到今天，AgentCube 已经吸引了多位社区开发者参与共建。感谢所有为 AgentCube 做出贡献的开发者：@YaoZengzeng@acsoto@hzxuzhonghu@Sagar-6203620715@mahil-2040@t2wang@FAUST-BENCHOU@tjucoder@LaynePeng@yashisrani@katara-Jayprakash@LiZhenCheng9527@Tweakzx@warjiang@LeslieKuo@MahaoAlex@VanderChen@kevin-wangzefeng@ifelseend@cairon-ab@RushabhMehta2005@Sanchit2662@qizha@ssfffss@wjf295004046@Aman-Cool@Storm1289@sicaario   相关链接[1] GitHub 仓库: cid:link_2[2] Volcano 官网: https://volcano.sh[3] 设计文档: cid:link_0[4] Python SDK: cid:link_1AgentCube 开源项目欢迎广大开发者参与。无论是提交 Issue、贡献 PR，还是在你的项目中试用 AgentCube，都是对项目的支持。 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着大语言模型（LLM）成为现代 AI 应用的核心引擎，支撑其运行的基础设施范式也随之进化。在解决了“智能路由”与“模型编排”等空间维度的请求分发问题后，运维的核心焦点转向了时间维度的资源博弈：如何实时、动态地确定最佳推理实例规模？Kthena Autoscaler 便是针对这一命题的标准答案。作为内置于 kthena-controller-manager 的核心控制器，它深度集成于 Kubernetes 生态，能够基于实时负载特征自动平滑地调整推理服务实例数。其核心价值在于：在严守业务 SLO（服务等级目标）红线的同时，最大化榨取计算资源的利用效率。本文将深入剖析 Kthena Autoscaler 的架构拓扑、通用策略逻辑以及多样化的绑定形态。 ▍1. 为什么 LLM 推理需要专用弹性伸缩？LLM 推理工作负载具有独特的特征，对传统弹性伸缩方案提出挑战：特征对伸缩的影响业务指标驱动相比于 CPU/内存利用率，推理引擎（如 vLLM）暴露的队列长度、KV Cache 利用率等业务指标更能直接反映服务饱和度。突发流量模式用户请求突然激增时需要快速扩容以维持延迟 SLOPrefill/Decode 不对称PD 解耦部署需要对预填和解码角色进行独立且灵活的伸缩。异构硬件与成本不同实例类型（GPU/NPU）提供不同的性能/成本权衡，需要精细化调度。传统的 Kubernetes HPA 或 KEDA 缺乏针对 LLM 工作负载的模型感知能力。Kthena Autoscaler 通过 直连 Pod 采集业务指标、角色级伸缩支持 以及 成本感知优化算法 弥合了这一差距。 ▍2. 架构概览Kthena Autoscaler 遵循控制器模式，作为 kthena-controller-manager 的子控制器运行。它通过直接采集 Pod 业务指标，结合用户定义的策略进行闭环控制。▍3. 通用策略 (AutoscalingPolicy)：定义“如何缩容”AutoscalingPolicy 是一个通用的逻辑模板，定义了计算副本需求的核心大脑。3.1 核心指标与容差Autoscaler 允许直接从 Pod 的 /metrics 端点抓取推理专属指标。这意味着它能感知到 vLLM 内部的请求队列状态。常见指标包括：vllm:num_requests_waiting：等待队列长度（最核心指标）。vllm:kv_cache_usage_perc：KV Cache 利用率。通过 targetValue 设置目标值，并利用 tolerancePercent（容差带）防止在目标值附近的微小抖动触发频繁伸缩。3.2 伸缩行为：稳定模式与紧急模式为了应对推理场景的流量特性，Policy 支持双模式策略：稳定模式 (Stable Mode)：使用较长的稳定窗口（如 1 分钟）观察持续趋势，避免对瞬时波动过度反应。紧急模式 (Panic Mode)：当指标严重偏离目标（如超过 150%）时触发，绕过稳定窗口实现秒级快速扩容。apiVersion: workload.serving.volcano.sh/v1alpha1kind:AutoscalingPolicymetadata: name:vllm-queue-policyspec: metrics: - metricName:vllm:num_requests_waiting targetValue:100 tolerancePercent:50 behavior: scaleUp: stablePolicy: stabilizationWindow:1m period:30s scaleDown: stabilizationWindow:5m period: 1m3.3 成本感知优化算法当伸缩涉及多个实例类型或硬件时，Policy 底层的算法引擎会执行带倍增策略的贪心算法。该算法根据每种实例类型的单位成本 (Cost) 将容量划分为指数级批次（基于 costExpansionRate），并按成本升序排序生成伸缩序列。这确保了：成本效率：优先选择低成本实例。减少冷启动：序列在周期内保持稳定，优先复用已运行的实例。 ▍4. 伸缩绑定 (AutoscalingPolicyBinding)：定义“缩容什么”AutoscalingPolicyBinding 是连接通用策略与具体目标的“粘合剂”。通过不同的绑定目标，可以实现完全不同的伸缩形态。4.1 作用于 ServingGroup：实现固定 PD 比例伸缩这是最常见的形态。通过target将 Policy 绑定到 ModelServing 或其中的 ServingGroup。逻辑：Autoscaler 将整组作为一个整体进行扩缩。效果：系统会严格保持定义的 Role 比例（如 prefill:decode = 1:2）同步增减。这适用于 PD 拓扑固定的标准部署场景。# 绑定到 ModelServing (整组同步伸缩)apiVersion:workload.serving.volcano.sh/v1alpha1kind:AutoscalingPolicyBindingmetadata: name:vllm-group-bindingspec: policyRef: name:vllm-queue-policy homogeneousTarget: target: targetRef: kind:ModelServing name:vllm-llama3 minReplicas:1 maxReplicas: 104.2 作用于 Role：实现独立 PD 异构伸缩AutoScaler通过subTargets，能够将 Policy 绑定到 ModelServing 内特定的 Role（如仅绑定 decode 角色）。逻辑：Autoscaler 仅针对该特定角色计算并修改副本数。效果：可以实现 prefill 副本保持稳定，而 decode 副本根据长输出负载独立增加。反过来说，也可以实现decode副本保持稳定，扩缩prefill副本数。这种PD 异构伸缩能极大提高资源利用率。# 包含 Role 定义的 ModelServing 示例apiVersion:workload.serving.volcano.sh/v1alpha1kind:ModelServingmetadata: name:deepseek-servingspec: template: roles: - name:prefill replicas:1 # ... 容器配置 ... - name:decode replicas:2 # ... 容器配置 ...---# 独立绑定到 Role 的示例apiVersion:workload.serving.volcano.sh/v1alpha1kind:AutoscalingPolicyBindingmetadata: name:decode-independent-bindingspec: policyRef: name:llm-scaling-policy homogeneousTarget: target: targetRef: kind:ModelServing name:deepseek-serving subTargets: kind:Role name:decode# 仅针对 decode 角色独立伸缩 minReplicas:2 maxReplicas: 8 ▍5. 最佳实践与故障排查配置建议保守起步：初始配置使用较宽容差带 (15-20%) 和较长稳定窗口。角色差异化目标：在 PD 异构场景下，为 decode 角色设置比 prefill 更敏感的阈值。成本校准：异构伸缩时，根据实际云定价或 TCO 调整 cost 值。可观测性Kthena Autoscaler 在 /metrics 暴露以下指标：kthena_autoscaler_desired_replicas：决策后的目标副本数。kthena_autoscaler_current_replicas：实际观测到的副本数。kthena_autoscaler_scaling_events_total：伸缩动作计数器。 ▍6. 进阶：成本感知优化与异构伸缩示例在实际生产中，我们往往拥有不同规格的 GPU 资源。Kthena Autoscaler 的 heterogeneousTarget 允许在多个目标之间进行成本优先的伸缩分配。# 跨硬件成本优化绑定示例apiVersion:workload.serving.volcano.sh/v1alpha1kind:AutoscalingPolicyBindingmetadata: name:heterogeneous-cost-bindingspec: policyRef: name:vllm-queue-policy heterogeneousTarget: params: - target: targetRef: kind:ModelServing name:deepseek-h100# 性能高，成本高 cost:100 minReplicas:1 maxReplicas:10 - target: targetRef: kind:ModelServing name:deepseek-a100# 成本低，优先扩容 cost:50 minReplicas:1 maxReplicas:20 # 定义成本扩张率，影响算法对成本与容量的权衡 costExpansionRatePercent: 200通过配置不同的 cost 值，Autoscaler 的算法引擎会优先尝试在低成本资源上扩容，而在缩容时则优先保留高效率或特定成本的实例，从而在满足性能需求的同时实现最优 TCO。 ▍总结Kthena Autoscaler 通过将“伸缩逻辑 (Policy)”与“伸缩目标 (Binding)”解耦，提供了极大的灵活性。通过 ServingGroup 绑定可以实现稳定的固定比例扩缩，而通过 Role 绑定则能实现精细的异构扩缩。结合内置控制器的架构和成本感知算法，它为构建高效、低成本的 LLM 推理平台提供了坚实基础。 相关链接[1] Kthena 官方文档: https://kthena.volcano.sh[2] GitHub 仓库: cid:link_0欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入Kthena技术交流群

Karmada 用户组再迎重要新成员，GMI Cloud[1]正式加入。作为云原生计算基金会（CNCF）旗下的项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。GMI Cloud 的加入将进一步加强 Karmada 社区，为项目的持续创新带来新的活力，标志着社区发展和 Karmada 在多样化生产环境中采用的又一个重要里程碑。   关于GMI Cloud  GMI Cloud 是一款面向生产级人工智能推理场景打造的原生 AI 基础设施平台。从无服务器应用程序接口到专属 GPU 集群，GMI Cloud 依托英伟达 GPU 平台，可提供稳定可控的性能、弹性扩容的算力以及高性价比的运行服务。GMI Cloud 打造了全栈垂直整合的人工智能基础设施体系，覆盖推理接口、调度编排、算力计算至硬件设备的全链路环节。  关于 Karmada 用户组  Karmada 用户组是一个由在其环境中成功采用 Karmada 的组织和用户组成的社区。作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享，助力云原生多云多集群生态系统的蓬勃发展。成为 Karmada 用户组成员具有以下优势：社区认可：作为云原生多集群管理领域的领导者来展示您的组织，在 CNCF 和 Karmada 社区中获得知名度；协作与交流：与其他采用者建立联系，分享最佳实践，并在实际用例和解决方案上进行协作；保持更新：及时接收重要更新通知，包括关键功能、错误修复和安全建议；活动参与：受邀参与 Karmada 相关活动，包括 KubeCon + CloudNativeCon、网络研讨会和聚会；职位发布：有机会在 Karmada 社区支持的职位公告板上发布与 Karmada 相关的职位空缺（暂不可用）；扩展商业机会：与 Karmada 生态系统的其他成员建立潜在的商业联系和合作。您可以在 GitHub 社区仓库中了解更多关于 Karmada 用户组[2] 的信息， 并在 karmada.io/adopters [3] 查看完整的公开的采用者列表。截至目前，Karmada 用户组已吸纳来自全球的 40+ 家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters   加入 Karmada 用户组   Karmada 用户组对当前正在生产环境中使用 Karmada 的最终用户和供应商开放。这包括：最终用户：在其生产环境中运行 Karmada 的组织；供应商：提供基于 Karmada 的产品或服务，并有客户在生产环境中使用这些产品或服务的公司。您是否在生产环境中使用 Karmada 并有兴趣加入 Karmada 用户组？访问下方 Karmada 用户组申请表单 [4]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。扫码申请加入用户组更多信息，请访问：[1] GMI Cloud: https://www.gmicloud.ai/[2] Karmada 用户组: https://github.com/karmada-io/community/tree/main/adopter-group[3] Karmada 采用者列表: http://karmada.io/adopters[4] Karmada 用户组申请表单: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yamlKarmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于 Karmada Adopter Group 的信息，请联系：Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io Karmada（https://karmada.io/）是 CNCF 首个跨云跨集群容器编排引擎，由华为云、工商银行、小红书、中国一汽等八家企业联合发起。Karmada的贡献企业与贡献者遍布全球 22 个国家和地区的 100 多个组织，包括华为、道客、浙江大学、腾讯、滴滴、Bloomberg、Yunhorn、携程等。截至目前，项目在 GitHub 上已获得 5.2k+Star。 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

由 Linux Foundation 组织的 LFX Mentorship 计划[1]，从2019年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获 2w+ 申请，发起 2000+ 课题，毕业实习生1400+，发放超过 380 万美金报酬。LFX Mentorship 2026 夏季(Term 2）申请时间为5月5日 – 5月19日（11:00 PDT；18:00 UTC)，远程实习将从 6 月 8 日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为 3000 美金，约合 20000 人民币）。Karmada 社区在 LFX Mentorship 计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官方平台申请:https://mentorship.lfx.linuxfoundation.org/  Karmada 社区介绍  Karmada 是 CNCF 首个多云多集群容器编排项目。作为开放的多云多集群容器编排引擎，Karmada 旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada 社区在 GitHub 上 Star 超过5.6k+,贡献者广泛分布于 20+国家和地区，现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。社区地址：cid:link_0  面向对象  本期计划申请者需 2026 年 5 月 19 日前在 LFX 官网[1]完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定，对 Mentee 申请者有以下要求[2]:在参加该计划时您至少年满 18 周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 年 Term2 申请及实习流程如下：Mentee 注册与项目申请：5月5日-5月19日（11:00 AM PDT/18:00 UTC)申请者审核期： 5月20日-6月2日（11:00 AM PDT/18:00 UTC)申请者入选通知：6月3日实习正式开始：6月8日中期考核：7月21日（11:00 AM PDT/18:00 UTC)首次津贴支付：7月22日结项考核、实习报告提交：8月25日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：8月26日本期结束最终日期：8月31日参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在 6 月 3 日通知到申请人。主线开发日期为 2026 年 6 月 8 日-8 月 25 日，全程线上协作，无需线下参与。结项需要在 2026 年 8 月 25 日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  Karmada 项目课题  在 LFX Mentorship 2026 Term 2，Karmada社区的课题如下：▍Karmada: Build Agent Skills课题描述：Karmada 是一个多集群编排系统，当前的 AI 编程智能体尚未形成与该系统深度匹配的技能结构。在缺乏专用技能库的情况下，智能体往往需要依赖零散的文档、在不充分的上下文中推断策略行为，这可能导致生成的PropagationPolicy、OverridePolicy或排查建议不够准确。本课题旨在为 AI 编程智能体系统性地构建面向 Karmada 的技能集。整体设计沿用成熟的“多技能库”模式，包含共享知识库、面向工作流的专项技能，以及用于处理格式敏感任务的确定性辅助工具。预期产出：一个共享知识库，涵盖策略 API、策略模式、故障排查案例、组件指南以及可复用的示例。用于策略生成、策略评审、放置解释、传播调试以及多集群管理的确定性辅助脚本、测试夹具和示例场景。面向贡献者的文档，说明如何在 hack/agent-skills/ 下新增技能、示例和知识文件。前置技能：Go; Kubernetes; React; CI/CD Systems ( GitHub Actions); Document tools课题导师：Hongcai Ren（@RainbowMango ）qdurenhongcai@gmail.comZhen Chang （@XiShanYongYe-Chang ）changzhen5@huawei.com课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/12821d1d-9528-4cf3-ac3c-d57a6b585599对课题内容有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。扫码回复“Karmada” 进入技术群今年夏季，Karmada社区期待在 LFX Mentorship 见到您！附：申报指引[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: https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2026/02-Jun-Aug/README.md[4] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply

欢迎阅读「从零开始理解大模型」系列 —— 十篇文章，从"下一个词预测"到完整的大模型心智模型。每篇配可运行代码。第一篇：一切从"猜下一个词"开始第二篇：Token——大模型眼中的"字"长什么样第三篇：向量与 Embedding——把文字变成数学第四篇：Attention——大模型的"阅读理解"机制第五篇：Transformer 全景——积木怎么搭成大厦第六篇：训练——70 亿个参数是怎么"学"出来的第七篇：推理——你按下回车后的这一秒发生了什么第八篇：上下文窗口——大模型的"工作记忆"第九篇：Scaling Law——为什么"大力出奇迹"有效第十篇：从大模型到 Agent——下一个词预测如何长出手脚* 本系列配套运行代码，可在公众号后台回复“大模型”完整获取。作者：十一前五篇讲的是大模型的"身体结构"——Token、Embedding、Attention、FFN 怎么组装在一起。但结构只是骨架，参数才是灵魂。一个刚初始化的模型，所有参数都是随机数。问它 "Thank you very" 后面是什么？完全瞎猜——50257 个 token 概率差不多。训练之后呢？99.2% 的概率输出 "much"。从随机到精准，中间发生了什么？ ▍一、先说结论 一句话版本：训练 = 喂数据 → 预测 → 算误差 → 调参数 → 重复几万亿次。▍二、训练的核心循环想象你在调一台有 70 亿个旋钮的收音机。目标是调到某个电台（让预测尽可能准），但你不知道每个旋钮该转到什么位置，只能靠试：随便拧 —— 给所有旋钮一个随机初始位置听一下 —— 用当前参数预测下一个词对答案 —— 看预测和真实文本差多远（算 Loss）微调旋钮 —— 每个旋钮稍微转一下，方向是让差距变小重复 —— 换下一段文本，再来一轮重复几万亿次。每次只调一点点，但积累下来，70 亿个旋钮就逐渐到了正确的位置。下面把每一步展开。 ▍三、Loss——“猜得有多离谱”模型输出 50257 个概率。训练时我们知道正确答案，所以可以量化"猜得有多差"——这个数叫 Loss（损失）。3.1 具体例子输入 "Thank you very"，正确答案是 "much"。 随机初始化的模型 训练好的模型"much" 的概率: 1/50257 ≈ 0.002% 0.992 (99.2%)3.2 Loss 的计算公式Loss = -log(P(正确答案))代入数字：随机模型: Loss = -log(1/50257) = 10.8 ← 很大，猜得很离谱训练好的: Loss = -log(0.992) = 0.008 ← 接近 0，猜得很准为什么用负对数？两个好处：概率从 0 到 1，取负对数后变成 0 到正无穷——数值范围更适合做优化猜得越离谱（概率越小），Loss 越大，惩罚力度和"离谱程度"成正比你不需要记公式，只需记住：Loss 是一个数字，越小越好。训练的目标就是让它不断变小。 ▍四、梯度——“每个旋钮该往哪边转”知道了 Loss（猜得有多差），下一个问题是：70 亿个参数，每个该往哪个方向调？调多少？4.1 梯度是什么回到收音机。你现在 Loss 是 10.8（信号很差）。把某个旋钮稍微往右转一点点，听听 Loss 变了没：变成 8.3 → 往右转是对的，继续变成 8.7 → 方向反了，应该往左梯度就是这个信号：告诉每个参数"往哪个方向调"以及"调多大步"。 数学上，梯度是 Loss 对每个参数的偏导数。但不需要理解偏导数——只要知道它给出了方向和幅度。4.2 反向传播——从输出往回推模型的计算方向是：输入 → Embedding → Layer 1 → Layer 2 → ... → Layer 12 → 输出 → Loss梯度的计算方向是反过来的：Loss → 输出 → Layer 12 → ... → Layer 2 → Layer 1 → Embedding从 Loss 出发，通过链式法则，把"该怎么调"的信号一路传回每一层的每一个参数。这叫反向传播（Backpropagation）。就像多米诺骨牌倒着推——Loss 推倒最后一块，连锁反应一路传到第一块。每个参数都收到了自己该怎么调的信号。4.3 梯度下降——一步一步走下山有了梯度，就可以更新参数：新参数 = 旧参数 - 学习率 × 梯度学习率（learning rate） 是一个很小的数（比如 0.0001），控制每步走多远。太大会跨过最优解来回震荡，太小训练太慢。整个过程就像在一个 70 亿维的山谷里找最低点：梯度告诉你哪边是下坡，学习率决定每步多远，一步一步走，最终走到（接近）谷底——也就是 Loss 最小的地方。 ▍五、代码实验：亲手训练一个微型模型GPT-2 太大，没法在笔记本上训练。附件 train_tiny.py[1] 实现了一个微型 Transformer——2 层、4 个头、128 维，在 10 句话上训练，CPU 几分钟跑完。训练循环的核心只有四行，所有大模型的训练都是这四行：# 1. 前向传播：用当前参数做预测logits = model(x)# 2. 算 Loss：预测和正确答案差多远loss = F.cross_entropy(logits.view(-1, vocab_size), y.view(-1))# 3. 反向传播：算出每个参数的梯度（该往哪调）loss.backward()# 4. 更新参数：沿梯度方向微调一步optimizer.step()不管模型有 10 万参数还是 1 万亿参数，训练循环都是这四步。差别只在每一步的计算量。运行效果 Step 0: Loss = 83.250 (0.1s) Step 50: Loss = 2.395 (0.5s) ████████████ Step 100: Loss = 1.767 (0.8s) ████████████████ Step 150: Loss = 1.311 (1.0s) ████████████████████ Step 200: Loss = 0.976 (1.3s) ██████████████████████ Step 250: Loss = 0.834 (1.7s) ███████████████████████ Step 300: Loss = 0.527 (2.0s) ██████████████████████████ Step 350: Loss = 0.312 (2.3s) ███████████████████████████ Step 400: Loss = 0.263 (2.6s) ████████████████████████████ Step 450: Loss = 0.264 (2.8s) ████████████████████████████ Step 499: Loss = 0.219 (3.1s) ████████████████████████████训练后测试： 输入: 'The capital of ' → 输出: 'The capital of Italy is Rome.' ✓ 输入: 'Thank you very' → 输出: 'Thank you very much for your help.' ✓这说明了什么Loss 从 83.250 降到 0.219——模型从瞎猜变成了能续写训练数据中的句子。前 100 步下降最快（容易的规律先学到），后面越来越慢（难的规律需要更多迭代）。但它只是在"背课文"——我们只喂了 10 句话，模型记住了这 10 句话的模式。问它训练数据里没有的内容，它就会胡说。真正的大模型在几万亿个 token 上训练，覆盖了互联网上的海量文本。所以它"记住"的不是具体句子，而是语言的统计规律——语法结构、事实知识、推理模式。数据量的差异，决定了"背课文"和"学会语言"的区别。完整可运行代码见附件 train_tiny.py，纯 PyTorch 实现，不需要 transformers 库。* 本系列配套运行代码，可在公众号后台回复“大模型”完整获取。 ▍六、真实的大模型训练：三个阶段我们的微型模型只经历了一个阶段。真实的大模型要经过三个阶段，每个阶段解决不同的问题。6.1 预训练（Pre-training）——“广泛读书”目标：让模型学会语言——语法、知识、推理能力。数据：几万亿个 token 的互联网文本——网页、书籍、论文、代码、维基百科……任务：就是我们讲过的"预测下一个词"。把文本切成片段，每个位置预测下一个 token，算 Loss，调参数。规模感受：预训练完成后，模型已经能生成流畅的文本，知道大量事实，能做简单推理。但它有个问题：不会好好回答问题。你问它一个问题，它可能不回答，而是继续生成看起来像网页的内容——因为在训练数据里，一段文本后面跟的通常是另一段文本，不是"回答"。6.2 SFT（监督微调）——“入职培训”目标：教模型"好好回答问题"。数据：人工编写的高质量问答对，通常几万到几十万条：用户：法国的首都是哪里？助手：法国的首都是巴黎。巴黎位于法国北部...用户：写一个 Python 斐波那契函数助手：def fibonacci(n): if n <= 1: return n return fibonacci(n-1) + fibonacci(n-2)训练方式：和预训练完全一样——预测下一个 token，算 Loss，调参数。只是数据换成了对话格式，模型就学会了"看到问题后给出回答"的模式。SFT 的数据量比预训练小得多（几万条 vs 几万亿 token），但它让模型从"续写机器"变成了"能回答问题的助手"。6.3 RLHF（基于人类反馈的强化学习）——“师傅带徒弟”目标：让回答更符合人类偏好——更有帮助、更安全、更诚实。SFT 教模型"怎么回答"，RLHF 教模型"什么样的回答更好"。分两步做：第一步：训练一个"打分模型"。同一个问题让模型生成两个回答 A 和 B，人类标注员选更好的那个。用大量这种偏好数据训练一个打分模型，让它能自动给回答打分。第二步：用打分模型优化语言模型。模型生成回答 → 打分模型打分 → 分数作为奖励信号 → 调整参数让模型倾向于生成高分回答。6.4 三阶段的效果变化预训练前: "jk2#x..." ← 随机噪声预训练后: "...the city is known for..." ← 流畅续写，但不会回答问题SFT 后: "巴黎是法国的首都。" ← 能回答了，但质量参差不齐RLHF 后: "法国的首都是巴黎。巴黎位于法国北部..." ← 回答详细、有帮助、安全▍七、训练的工程挑战原理不复杂，但真把一个 70B 模型训出来，工程上很难。7.1 显存装不下一个 7B 模型的训练需要多少显存？参数本身: 7B × 4 字节 = 28 GB 梯度: 同样大小 = 28 GB 优化器状态: Adam 需要额外存两份 = 56 GB 激活值: 中间计算结果 = 数十 GB ────────────────────────────── 总计: 远超 100 GB一张 A100 GPU 有 80 GB 显存，连参数和优化器都装不下——一张卡根本没法训 7B 模型。解决办法是分布式训练：把模型切成几块，分到不同的 GPU 上，几千张 GPU 通过高速网络协同工作。这就是为什么训大模型要花数百万美元——大部分是算力成本。7.2 数据质量比数据数量更重要训练数据里如果充满错误信息、恶意内容或低质量文本，模型就会学到这些"坏习惯"。所以训练前要做大量清洗：去重（互联网上到处是重复内容）、过滤垃圾页面、去除隐私信息、平衡语言和领域的比例。数据配比（多少英文、多少中文、多少代码、多少数学）是各家模型团队的核心秘方。 ▍八、训练改变了什么回顾前五篇，训练到底改变了哪些东西：Embedding 表（第三篇）：训练前是随机数。训练后，"France" 和 "Paris" 的向量变得接近，"国王 - 男人 + 女人 ≈ 女王" 自动形成。Attention 的 Q/K/V 权重（第四篇）：训练前，注意力分数是随机的，每个词对所有词的关注度差不多。训练后，"very" 学会了重点关注 "Thank you" 这个搭配。FFN 的权重（第五篇）：训练前，FFN 做的是随机变换。训练后，FFN 学会了存储和调用知识——看到 "Thank you very" 就激活 "much"。所有这些变化，都来自同一个训练信号：预测下一个词。 没有人告诉模型 "France 的首都是 Paris"，也没人告诉它 "Thank you very 后面接 much"。它只是在几万亿次预测中自动发现了这些规律，编码进了参数里。 ▍九、结语训练的本质简单得令人意外：预测 → 算误差 → 调参数 → 重复。复杂的不是算法，而是规模——70 亿个参数、几万亿个 token、数千张 GPU、数月时间。把一个简单过程推到极致的规模，涌现出了看起来像"理解语言"的能力。"Deep learning is just gradient descent on a loss function. Everything else is engineering."深度学习就是在 Loss 上做梯度下降。剩下的全是工程。下一篇，我们从训练切换到使用——你按下回车后的这一秒，模型内部发生了什么？为什么第一个字等得久、后面快了？KV Cache 是什么？本文配套代码：train_tiny.py（微型 Transformer 从零训练）。纯 PyTorch 实现，不需要 transformers 库，CPU 几分钟跑完。扫码回复“大模型”获取本系列文章完整配套代码「从零开始理解大模型」是「从零开始理解 Agent」的姊妹系列。Agent 系列讲"四肢"，本系列讲"大脑"。建议对照阅读 专栏入口。

由Linux Foundation组织的LFX Mentorship计划[1]，从2019年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获2w+申请，发起2000+课题，毕业实习生1400+，发放超过380万美金报酬。LFX Mentorship 2026 夏季(Term 2）申请时间为5月5日 – 5月19日（11:00 PDT；18:00 UTC)，远程实习将从 6 月 8 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为3000美金，约合20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官方平台申请（在校/在职符合条件可）:https://mentorship.lfx.linuxfoundation.org/  Volcano 社区介绍  Volcano 是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.5k+ Star 和 1.3K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。社区地址：🌋 https://github.com/volcano-sh在LFX Mentorship 2026夏季计划，Volcano期待与你协作开拓AI大数据、LLM大模型推理等场景调度的更多可能。  面 向 对 象 本期计划申请者需2026年5月19日前在LFX官网[1]完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定，对Mentee申请者有以下要求[2]:在参加该计划时您至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 年 Term2 申请及实习流程如下：Mentee注册与项目申请：5月5日-5月19日（11:00 AM PDT/18:00 UTC)申请者审核期： 5月20日-6月2日（11:00 AM PDT/18:00 UTC)申请者入选通知：6月3日实习正式开始：6月8日中期考核：7月21日（11:00 AM PDT/18:00 UTC)首次津贴支付：7月22日结项考核、实习报告提交：8月25日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：8月26日本期结束最终日期：8月31参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在6 月 3 日通知到申请人。主线开发日期为2026年6月8日-8月25日，全程线上协作，无需线下参与。结项需要在2026年8月25日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  Volcano 项目课题  欢迎各位申请者申报CNCF Volcano社区课题：▍支持 Namespace 级别的 Queue课题描述：Volcano 当前的 Queue 是集群级别的资源，只有集群管理员才有权限创建和修改。这在多租户场景下对普通租户不太友好：租户通常只拥有自己 namespace 下的权限，但也想用上 Queue 提供的能力（资源共享、capability/guarantee/deserved、队列层级等）来管理自己的作业，而不是每改一次都要依赖集群管理员。本课题会在 Volcano 中引入 namespace 级别的 NamespaceQueue。NamespaceQueue 从 cluster 级别的 Queue 派生，语义和使用方式与 cluster Queue 保持一致，租户可以直接在自己的 namespace 下创建和管理队列，并像使用 cluster Queue 一样把 PodGroup/Job 关联到 NamespaceQueue 上进行调度。对不使用这个特性的用户，原有 cluster Queue 的行为和 API 完全不受影响。预期产出：新增 namespace 级别的 NamespaceQueue CRD，从 cluster 级别的 Queue 派生，capability/guarantee/deserved、队列层级等字段语义保持一致租户不需要集群管理员权限，就能在自己 namespace 下创建和管理 NamespaceQueuePodGroup/Job 支持引用 NamespaceQueue，调度行为与引用 cluster Queue 一致NamespaceQueue 的资源统计、status、事件等能够正常工作与原有 cluster Queue 和 scheduling.volcano.sh/queue-name annotation 兼容，老用户可以平滑迁移覆盖核心流程和异常场景的 E2E 测试Volcano 官网和代码仓库的用户文前置技能：GoKubernetes（CRD、controller、RBAC）熟悉 Volcano（scheduler、queue、PodGroup/Job 等）E2E 测试（Ginkgo）GitHub workflow 与 shell 脚课题导师：Zicong Chen（@JesseStutler ）jessestutler97@gmail.comHajnal Máté （@hajnalmt）hajnalmt@gmail.comJoão Azevedo （@devzizu）jazevedo960@gmail.com原始Issue：cid:link_2/issues/5251课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/9e582ac4-4e12-4fcc-a1cd-27855d79730a▍Kthena Router 支持第三方模型 API课题描述：目前 Volcano/Kthena Router 已经能够很好地支持集群内部的路由能力。但在与用户的交流中,部分用户提出希望能够对接外部的大语言模型 API。因此,Kthena 社区计划借助本期 LFX,让 Router 具备访问第三方 LLM API 的能力。预期结果：设计提案(Proposal)代码实现(包含单元测试;如能补充端到端测试更佳。但考虑到外部 LLM API 通常不会提供长期、稳定的免费访问,端到端测试不作为强制要求)用户指南及相关文前置技能：Go、Kubernetes、网络、LLM课题导师：Zengzeng Yao（@yaozengzeng ）yaozengzeng@huawei.com原始Issue：cid:link_3/issues/939课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/baa6fb1f-58c9-4255-849c-21aca35ce5e1▍Kthena Router 性能基准测试(Benchmark)课题描述：Kthena Router 是 Volcano/Kthena 项目中的 LLM 路由组件,负责将推理请求转发到集群内(以及即将支持的)第三方模型后端。随着 Kthena 逐步走向成熟,社区需要一套可复现的基准测试,用来在真实的 LLM 流量模式下衡量 Router 的性能特征(吞吐、延迟、TTFT、资源占用),并在版本迭代中及时发现性能回退。本项目希望设计并实现一套面向 Kthena Router 的基准测试框架,产出完整的测试报告。如果在过程中发现明显的瓶颈或可优化点,还需要与 Maintainer 协作,将代码层面的优化合入上游。预期产出：一套可复用的 Kthena Router 基准测试框架(压测客户端、场景配置、指标采集、结果汇总),可在本地乃至 CI 中运行。一组覆盖典型 LLM 路由模式的测试场景(不同的 QPS、prompt/response 长度、并发数、后端数量、路由策略等)。端到端测试流程文档化为 runbook(集群准备、mock/真实后端、运行方式、结果解读)。一份基准测试报告,包含吞吐、TPOT、TTFT、GPU/CPU/内存等指标,以及瓶颈分析。针对识别到的明显瓶颈进行优化并提交上游 PR,附上优化前后的性能对比数据前置技能：Go、Kubernetes、性能基准测试与性能剖析(pprof)、对 LLM 推理及 HTTP/gRPC 路由有基本了解。课题导师：Zengzeng Yao（@yaozengzeng ）yaozengzeng@huawei.comZhonghu Xu （@hzxuzhonghu ）zhhxu2011@gmail.com原始Issue：cid:link_3/issues/942课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/1cf34cb5-3520-4f15-81c8-4258cb9abcb9▍支持多 AgentCube 协同能力课题描述：目前, Volcano社区AgentCube项目 在 Code Interpretation和 Agent Runtime场景下都只会拉起单个 Agent。然而,当前我们已经进入多 Agent 协作的时代。因此,AgentCube 计划支持多 Agent 编排,使多个 Agent 能够围绕同一个任务进行协作,并由 AgentCube 统一管理这些 Agent 的生命周期。预期结果：设计提案(Proposal)代码实现(包含单元测试和端到端测试)用户指南及其他相关文前置技能：Go、Kubernetes、Agent课题导师：Zhonghu Xu （@hzxuzhonghu ）zhhxu2011@gmail.com原始Issue：cid:link_1/issues/301课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/9e7dd1c1-5d14-4c5e-af43-83454099e490更多Volcano课题，请访问LFX Mentorship官网[1]；对课题感兴趣/有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。今年夏季，Volcano社区期待在 LFX Mentorship 见到您！ 附：相关指引链接[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_2[6] Volcano/Kthena GitHub: cid:link_3[7] Volcano/AgentCube GitHub: cid:link_1 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入Volcano技术交流群