CCI的云原生cloudbursting有哪些计费方式？如何降低管理维护成本？

在使用CloudBursting解决方案时，如何进行故障排除和调试？

CCI和k8s集群有哪些关系？

CCI如何从容器访问公网？

创建负载时，在CBC-资金管理-收支明细内，出现保证金冻结信息，该怎么解决此问题

账户重置后有余额，在CCI 中新建命名空间仍然提示欠费，无法操作。

CCI弹性伸缩策略如何配置？

创建工作负载时，CCI如何设置实例（Pod）数？ 

CCI 资源包中的核时怎么理解？求大佬帮助

北京时间2025年9月29日，Volcano v1.13 版本[1]正式发布。本次更新在多方面进行了功能增强，为用户提供更完善的云原生批量计算解决方案。新版本主要亮点包括：新增对大模型推理LWS的支持；新增定时任务管理能力；提供更灵活的网络拓扑发现机制，并增强对主流AI计算框架的兼容性。同时在混部架构上实现了重要改进，提升了在不同环境中的部署灵活性。这些增强功能共同提升了Volcano[2]在复杂工作负载管理中的实用性和易用性，旨在打造更高效、更稳定的大规模计算平台，为AI时代的基础设施提供关键调度支撑。  大模型推理场景支持 LeaderWorkerSet  LeaderWorkerSet (LWS)[3] 是一个用于在 Kubernetes 上部署一组 Pod 的 API。它主要用于解决 AI/ML 推理工作负载中的多主机推理，尤其是需要将大型语言模型（LLM）分片并跨多个节点上的多个设备运行的场景。Volcano自开源以来，积极与上下游生态进行集成，构建了完善的AI、大数据等批量计算社区生态，LWS在 v0.7[4]的版本中，原生集成了Volcano的AI调度能力，配合Volcano的新版本，用户在使用LWS时，可自动创建PodGroup，由Volcano进行Pod的调度与资源管理，从而实现了大模型推理场景下的Gang调度等高阶能力。展望未来，Volcano 将继续扩展其生态系统集成能力，为更多致力于在 Kubernetes 上实现分布式推理的项目提供强大的调度和资源管理支持。使用文档请参考：LeaderWorkerSet With Gang[5]相关PRs:cid:link_12 cid:link_13由衷感谢社区开发者：@JesseStutler 对该特性的贡献！  新增 Cron Volcano Job  该版本引入了对 Cron Volcano Job 的支持，用户可以像使用原生 Kubernetes CronJob 一样，按预定的时间计划（schedule）来周期性地创建和运行 Volcano Job，以实现周期性运行AI、大数据等批量计算任务。详细功能如下：定时调度：通过标准的 Cron 表达式（spec.schedule）定义作业的执行周期。时区支持：支持在 spec.timeZone 中设置时区，以确保作业在预期的本地时间执行。并发策略：通过 spec.concurrencyPolicy 控制并发行为：AllowConcurrent：允许并发运行多个作业（默认）。ForbidConcurrent：如果前一个作业尚未完成，则跳过本次调度。ReplaceConcurrent：如果前一个作业仍在运行，则终止它并启动新的作业。历史记录管理：可配置保留成功（successfulJobsHistoryLimit）和失败（failedJobsHistoryLimit）的作业历史记录数量，自动清理旧的作业。错过调度处理：通过 startingDeadlineSeconds 字段，可以容忍一定时间内的调度延迟，超时则视为错过执行。状态追踪：CronJob 的状态（status）会追踪当前活跃的作业、上一次调度时间以及上一次成功完成的时间，便于监控和管理。使用例子请参考：Cron Volcano Job Example[6]相关PRs：cid:link_24 cid:link_14由衷感谢社区开发者：@GoingCharlie, @hwdef, @Monokaix 对该特性的贡献！  支持基于 Label 的 HyperNode 自动发现机制  Volcano 在 v1.12 版本中正式推出了网络拓扑感知调度能力，并率先实现了基于 InfiniBand (IB) 网络的 UFM 自动发现机制。然而，对于不支持 IB 网络或采用其他网络架构的硬件集群（如以太网），手动维护网络拓扑结构依然繁琐。为解决这一问题，新版本引入了基于节点标签（Label）的 HyperNode 自动发现机制。该功能为用户提供了一种通用且灵活的方式来描述网络拓扑，将复杂的拓扑管理工作转变为简单的节点标签管理。该机制允许用户在 volcano-controller-configmap 中定义拓扑层级与节点标签的对应关系。Volcano 控制器会周期性地扫描集群中的所有节点，并根据其标签自动完成以下工作：自动构建拓扑：根据节点上的一组标签，从上至下（例如：机架 -> 交换机 -> 节点）自动构建出多层 HyperNode 拓扑结构。动态维护：当节点的标签发生变化，或节点被添加、移除时，控制器会自动更新 HyperNode 的成员和结构，确保拓扑信息始终与集群状态保持一致。支持多种拓扑类型：允许用户同时定义多种独立的网络拓扑，以适应不同的硬件集群（如 GPU 集群、NPU 集群等）或不同的网络分区。配置示例：# volcano-controller-configmap.yamlapiVersion: v1kind: ConfigMapmetadata:  name: volcano-controller-configmap  namespace: volcano-systemdata:  volcano-controller.conf: |    networkTopologyDiscovery:      - source: label        enabled: true        interval: 10m # 发现周期        config:          networkTopologyTypes:            # 定义一个名为 topology-A 的拓扑类型            topology-A:              # 定义拓扑层级，顺序从上到下              - nodeLabel: "volcano.sh/hypercluster"# 顶层 HyperNode              - nodeLabel: "volcano.sh/hypernode"   # 中间层 HyperNode              - nodeLabel: "kubernetes.io/hostname"# 底层物理节点 通过在 Volcano 控制器的 ConfigMap 中添加 label 源即可启用此功能。以下配置定义了一个名为 topology-A 的三层拓扑结构：顶层 (Tier 2) ：由 volcano.sh/hypercluster 标签定义。中间层 (Tier 1) ：由 volcano.sh/hypernode 标签定义。底层 ：物理节点，由 Kubernetes 内置的 kubernetes.io/hostname 标签标识。当一个节点被打上如下标签时，它将被自动识别并归入 cluster-s4 -> node-group-s0 的拓扑路径下：# 节点 node-0 的标签labels:  kubernetes.io/hostname: node-0  volcano.sh/hypernode: node-group-s0 volcano.sh/hypercluster: cluster-s4基于label的网络拓扑自动发现功能具有出色的通用性与灵活性，不依赖于特定的网络硬件（如 IB），因此适用于各类异构集群，并允许用户通过标签灵活定义任意深度的层级结构。它将复杂的拓扑维护工作转变为简单的节点标签管理，实现了自动化，从而显著降低运维成本和出错风险。此外，该机制能够动态适应集群节点和标签的变化，无需人工干预即可实时保持拓扑信息的准确性。使用文档请参考：HyperNode Auto Discovery[7]相关PR：cid:link_15由衷感谢社区开发者：@zhaoqi612 对该特性的贡献！  原生支持 Ray 框架  Ray是一个开源的统一分布式计算框架，其核心目标是简化从单机到大规模集群的并行计算，特别适合扩展Python和AI应用。为了在Kubernetes上管理和运行Ray，社区提供了KubeRay——一个专为Kubernetes设计的Operator，它充当了Kubernetes和Ray框架之间的桥梁，极大地简化了Ray集群和作业的部署与管理。一直以来，在Kubernetes上运行Ray工作负载主要依赖于KubeRay Operator，同时Kuberay在v0.4.0 (2022年release) 版本已经集成了Volcano来进行Ray Cluster的调度和资源管理，以解决分布式训练场景的资源死锁等问题。现在，通过新版本的Volcano，用户可以直接通过原生Volcano Job来创建和管理Ray集群，并提交计算任务。这为Ray用户提供了另一种使用方案，可以更直接地使用Volcano的Gang Scheduling、队列管理与公平调度、作业生命周期管理等能力来运行Ray工作负载。相关PR: cid:link_16设计文档请参考: Ray Design Doc[8]使用文档请参考: Ray User Guide[9]由衷感谢社区开发者：@Wonki4 对该特性的贡献！  新增 HCCL 插件支持  新版本在Volcano Job中增加了分布式AI训练场景需要的HCCL Rank 插件（hcclrank），用于在分布式任务中自动为 Pod 分配 HCCL Rank。具体包括：新增 Volcano Job的hcclrank 插件实现，支持通过任务类型（master/worker）和索引自动计算并注入 HCCL Rank 到 Pod 注解。插件支持自定义 master/worker 任务名，用户可以指定分布式任务的master/worker角色。该功能提升了 Volcano 在华为昇腾等 HCCL 通信场景下的原生支持，方便用户在 AI 训练任务中自动管理和分配 Rank。相关PR:cid:link_27/pull/4524由衷感谢社区开发者：@kingeasternsun 对该特性的贡献！  增强 NodeGroup 功能  在层级队列结构中，为每个子队列重复配置与其父队列相同的节点组亲和性（nodeGroupAffinity）会导致配置冗余且难以维护。为解决此问题，Nodegroup 插件新增了对层级队列亲和性的继承支持。启用后，调度器将遵循以下规则解析队列的有效亲和性：优先自身配置：若队列已定义 spec.affinity，则直接使用该配置。向上继承：若队列未定义 spec.affinity，则沿其父级向上查找，并继承最近的祖先队列所定义的亲和性配置。覆盖能力：子队列可通过定义自身的 spec.affinity 来覆盖继承的配置，保证了灵活性。此功能允许管理员在父队列（如部门级别）设置统一的节点组亲和性，其下的所有子队列（如团队级别）将自动继承该设置，从而简化了管理。同时对于未设置NodeAffinity的队列，用户可以在插件配置中设置"strict"参数来决定调度行为。当 strict 为 true（默认值）时，这些队列的任务将无法被调度到任何节点上。当 strict 设置为 false 时，这些任务则被允许调度到未设置 "volcano.sh/nodegroup-name" 标签的普通节点上。在调度配置文件的 nodegroup 插件参数中，设置 enableHierarchy: true可开启层级队列模式，设置strict为false可设置non-strict模式，示例配置如下：actions: "allocate, backfill, preempt, reclaim"tiers:- plugins:  - name: nodegroup    enableHierarchy: true# 启用层级队列    arguments:     strict: false# 设置为non-strict模式，队列内任务可以被调度到不包含"volcano.sh/nodegroup-name"标签的节点上相关PRs:cid:link_27/pull/4455 cid:link_17NodeGroup设计文档请参考：NodeGroup Design[10]NodeGroup使用文档请参考: NodeGroup User Guide[11]由衷感谢社区开发者：@JesseStutler , @wuyueandrew 对该特性的贡献！  新增 ResourceStrategyFit 插件  在 Kubernetes 原生的 noderesources 调度策略中，只能对所有资源应用单一的聚合（MostAllocated）或分散（LeastAllocated）策略。这在复杂的异构计算环境（如 AI/ML 集群）中存在局限性。为了满足差异化调度需求，Volcano 增强提出了 ResourceStrategyFit 插件，以应对更加复杂的场景。该插件现在集成了两大核心功能：按资源类型配置独立策略以及稀缺资源规避（SRA）。▍按资源类型的独立打分策略  此功能允许用户为不同的资源（如 cpu, memory, nvidia.com/gpu）分别指定 MostAllocated（聚合）或 LeastAllocated（分散）策略，并为其分配不同权重。调度器会根据每个资源的独立配置精细化计算节点得分。为了简化对同一系列资源（如来自同一供应商的不同型号 GPU）的管理，该功能还支持资源名称的后缀通配符（*）匹配。语法规则：仅支持后缀通配符，例如 nvidia.com/gpu/*。诸如 vendor./gpu 等模式将被视为无效。匹配优先级：采用“最长前缀匹配”原则。精确匹配的优先级最高；当没有精确匹配时，将选择前缀最长的通配符模式。配置示例： 以下配置为特定型号的 V100 GPU 设置了高优先级的聚合策略，为所有其他 NVIDIA GPU 设置了通用的聚合策略，同时为 CPU 资源配置了分散策略。actions: "enqueue, allocate, backfill, reclaim, preempt"tiers:- plugins:  - name: resource-strategy-fit    arguments:      resourceStrategyFitWeight: 10      resources:        # 精确匹配，最高优先级        nvidia.com/gpu-v100:          type: MostAllocated          weight: 3        # 通配符匹配，适用于其他所有 NVIDIA GPU        nvidia.com/gpu/*:          type: MostAllocated          weight: 2        # 精确匹配，用于 CPU 资源        cpu:          type: LeastAllocated          weight: 1同时ResourceStrategyFit 插件也支持设置Pod粒度的资源打分策略。主要通过以下两个注解进行设置：volcano.sh/resource-strategy-scoring-type: 指定该 Pod 的资源调度策略，可选值为 "LeastAllocated"（优先调度到资源使用率最低的节点）或 "MostAllocated"（优先调度到资源使用率最高的节点）。volcano.sh/resource-strategy-weight: 以 JSON 格式为不同的资源（如 CPU、内存、GPU 等）设置自定义的调度权重，以影响最终的节点评分。以下示例展示了如何为一个 Volcano Job 配置 Pod 粒度的资源调度策略：apiVersion: batch.volcano.sh/v1alpha1kind: Jobmetadata:  name: resource-strategy-jobspec:  minAvailable: 2  schedulerName: volcano  tasks:  - replicas: 2    name: worker    template:      metadata:        annotations:          # 为该任务的 Pod 设置调度策略为 LeastAllocated          volcano.sh/resource-strategy-scoring-type: "LeastAllocated"          # 为 CPU 和内存资源设置不同的调度权重          volcano.sh/resource-strategy-weight: '{"cpu": 2, "memory": 1}'      spec:        containers:        - name: worker          image: my-worker:latest          resources:            requests:              cpu: "2"              memory: "4Gi"            limits:              cpu: "2"              memory: "4Gi"       restartPolicy: Never在这个例子中，worker 任务下的所有 Pod 在调度时将遵循 LeastAllocated 策略。在计算节点分数时，CPU 的权重是 2，内存的权重是 1。这意味着调度器会更倾向于将 Pod 调度到 CPU 和内存空闲资源（根据权重加权后）更多的节点上。▍稀缺资源规避（Scarce Resource Avoidance, SRA）SRA 是一项“软”策略，旨在提高昂贵或稀缺资源（如 GPU）的整体利用率。它通过影响节点评分，引导那些不需要特定稀缺资源的普通任务（如纯 CPU 任务）尽量避开包含这些资源的节点。这样可以将稀缺资源节点“预留”给真正需要它们的任务，从而减少资源竞争和任务等待时间。工作机制：1.  用户在配置中定义一组“稀缺资源”（如 nvidia.com/gpu）。2.  当调度一个不请求任何已定义稀缺资源的 Pod 时，SRA 策略会生效。3.  调度器会降低那些拥有这些稀缺资源的节点的得分。节点上存在的稀缺资源种类越多，其得分就越低。4.  对于那些请求了稀缺资源的 Pod，SRA 策略不会对其调度决策产生负面影响。配置示例：以下配置将 nvidia.com/gpu 定义为稀缺资源。当调度纯 CPU 任务时，拥有 GPU 的节点得分会降低，从而使任务更倾向于被调度到没有 GPU 的节点上。actions: "enqueue, allocate, backfill, reclaim, preempt"tiers:- plugins:  - name: resource-strategy-fit    arguments:      # ... resourceStrategyFit 的聚合/分散策略配置 ...      resources:        nvidia.com/gpu:          type: MostAllocated          weight: 2        cpu:          type: LeastAllocated          weight: 1      # SRA 策略配置      sra:        enable: true        resources: "nvidia.com/gpu"# 定义稀缺资源列表，逗号分隔        weight: 10 # SRA 策略在总分中的权重        resourceWeight:          nvidia.com/gpu: 1 # 定义 nvidia.com/gpu 为稀缺资源及其权重通过将 ResourceStrategyFit 的聚合/分散策略与 SRA 的规避策略相结合，用户可以实现更精细、更高效的异构资源调度。关于ResourceStrategyFit设计和使用文档，请参考：ResourceStrategyFit[12]，how to use resource strategy fit plugin[13]相关PRs：cid:link_18 cid:link_19 cid:link_20由衷感谢社区开发者：@LY-today, @XbaoWu, @ditingdapeng, @kingeasternsun对该特性的贡献！  实现混部与 OS 解耦  Volcano 混部能力分为应用态和内核态两部分，应用态混部提供在离线统一调度、动态资源超卖、节点压力驱逐等能力，内核态混部分为内核层面的CPU/Memory/Network等资源的QoS保障，内核态混部能力通常需要特性OS支持（如OpenEuler等）。在新版本中，Volcano将混部能力与OS进行了解耦，对于使用了不支持混部能力的OS的用户来讲，可以选择使用Volcano应用态的混部能力，来达到在离线任务统一调度、动态资源超卖、高优任务保障等能力。具体使用方式如下，在安装Volcano agent时指定--supported-features参数：helm install volcano . --create-namespace -n volcano-system --set custom.colocation_enable=true --set"custom.agent_supported_features=OverSubscription\,Eviction\,Resources"混部相关文档请参考：https://volcano.sh/en/docs/colocation/相关PRs:cid:link_27/pull/4409 cid:link_21由衷感谢社区开发者：@ShuhanYan, @Monokaix 对该特性的贡献！  支持自定义混部超卖资源名称  Vocano混部Agent新增参数 --extend-resource-cpu-name 和 --extend-resource-memory-name，允许用户自定义超卖资源名称，支持自定义设置 CPU 和内存资源的名称（默认分别为 kubernetes.io/batch-cpu 和 kubernetes.io/batch-memory）。提升了超卖资源名称设置的灵活性。具体使用方式如下，在安装Volcano时指定--extend-resource-cpu-name和--extend-resource-memory-name参数：helm install volcano . --create-namespace -n volcano-system --set custom.colocation_enable=true --set custom.agent_extend_resource_cpu_name=example.com/cpu --set custom.agent_extend_resource_memory_name=example.com/gpu混部相关文档请参考：https://volcano.sh/en/docs/colocation/相关PRs：cid:link_22 cid:link_21由衷感谢社区开发者：@ShuhanYan, @Monokaix 对该特性的贡献！  将网络拓扑感知调度能力扩展至 Kubernetes 标准工作负载  在新版本中，Volcano 的网络拓扑感知调度能力不再局限于 Volcano Job。现在，也可以为 Kubernetes 的标准工作负载（如 Deployment、StatefulSet 等）配置网络拓扑约束。该功能通过 Pod 模板中的注解（Annotation）实现。当为 Deployment 或 StatefulSet 的 Pod 模板添加网络拓扑相关的注解后，Volcano 的 podgroup-controller 会自动为这些 Pod 创建一个PodGroup，并将注解中定义的网络拓扑约束继承到 PodGroup 的规约（Spec）中，从而在调度时应用相应的网络亲和性策略。可以通过以下两个注解来配置网络拓扑感知调度：Deployment 配置示例以下示例展示了如何为一个 Deployment 配置网络拓扑感知调度。调度器将把该 Deployment 的 Pod 调度到网络层级不超过 2 的节点上：apiVersion: apps/v1kind: Deploymentmetadata:  name: network-aware-deploymentspec:  replicas: 3  selector:    matchLabels:      app: my-app  template:    metadata:      labels:        app: my-app      annotations:        # 设置网络拓扑为硬约束        topology.volcano.sh/network-topology-mode: "hard"        # 设置允许调度的最高网络层级为 2        topology.volcano.sh/network-topology-highest-tier: "2"    spec:      # 必须指定调度器为 volcano      schedulerName: volcano      containers:      - name: main-container        image: nginx:latest        resources:          requests:            cpu: "1"            memory: "1Gi"          limits:            cpu: "1"            memory: "1Gi"相关PRs:cid:link_27/pull/4583cid:link_25由衷感谢社区开发者：@zhifei92 对该特性的贡献！  适配 Kubernetes 1.33  Volcano 版本紧随 Kubernetes 社区版本。v1.13 支持最新的 Kubernetes v1.33 版本，并通过完整的 UT 和 E2E 测试用例确保功能和可靠性。如需参与 Volcano 对新 Kubernetes 版本的适配工作，请参考：adapt-k8s-todo[14]。相关PR：cid:link_23由衷感谢社区开发者：@mahdikhashan 对该特性的贡献！  致谢贡献者  Volcano v1.13 版本包含了来自 36 位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢，贡献者 GitHub ID：相关链接[1]Volcano v1.13版本: cid:link_10[2]Volcano: https://volcano.sh/en/[3]LeaderWorkerSet (LWS): cid:link_26[4]LWS v0.7: cid:link_11[5]LeaderWorkerSet With Gang: cid:link_6[6]Cron Volcano Job Example: cid:link_8[7]HyperNode Auto Discovery: cid:link_1[8]Ray Design Doc: cid:link_4[9]Ray User Guide: cid:link_5[10]NodeGroup Design: cid:link_9[11]NodeGroup User Guide: cid:link_3[12]ResourceStrategyFit: cid:link_2[13]how to use resource strategy fit plugin: cid:link_0[14]adapt-k8s-todo: cid:link_7Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。Website：https://volcano.shGitHub: cid:link_27每周例会：https://zoom.us/j/91804791393  添加社区小助手回复“Volcano”进入技术交流群 

近期，快手 Kwaipilot 团队推出了 KAT 系列两款突破性 Agentic Coding 大模型：开源 32B 参数模型 KAT-Dev-32B 与闭源旗舰模型  KAT-Coder。 这两款模型在 Code Intelligence 领域分别体现出轻量级的超强表现和极致性能。其中，在 SWE-Bench Verified 上，KAT-Dev-32B 展现出强劲性能并取得了 62.4% 的解决率，在所有不同规模的开源模型中排名第 5。与此同时，KAT-Coder 以 73.4% 的解决率在 SWE-Bench Verified 上取得了极佳的单模型表现，比肩全球顶尖闭源模型。  图 1：在 SWE-Bench Verified 上，和全尺寸开源模型对比，KAT-Dev 用极小的模型尺寸取得了第一梯队的性能   图 2：在 SWE-Bench Verified 上，KAT-Coder 取得极佳的单模型表现，比肩全球顶尖闭源模型性能 模型开源和 API 开放KAT-Dev-32B 已在开源模型托管平台 Hugging Face 上线，可供进一步研究和开发使用。KAT-Coder 模型的 API 密钥近期也在 “快手万擎” 企业级大模型服务与开发平台上开放申请，用户将能够通过 Claude Code 等工具直接访问并进行编码。快手 Kwaipilot 团队的官方技术 Blog：https://kwaipilot.github.io/KAT-Coder/KAT-Dev-32B 模型开源地址：https://huggingface.co/Kwaipilot/KAT-DevKAT-Coder 开发工具接入指南：https://www.streamlake.com/document/WANQING/me6ymdjrqv8lp4iq0o9KAT-Coder API Key 申请：https://console.streamlake.com/wanqing/ 核心贡献点摘要KAT-Dev-32B 和 KAT-Coder 在多个训练阶段进行了创新和优化，包括 Mid-Training 阶段、监督微调 (SFT) 阶段、强化微调 (RFT) 阶段，以及大规模智能体强化学习 (RL) 阶段，具体如下：Mid-Training：Kwaipilot 团队发现，在这一阶段大量增加工具使用能力、多轮交互和指令遵循的训练，虽然在当前结果上（例如在 SWE-bench 等排行榜）可能不会带来显著的性能提升，但对后续的 SFT 和 RL 阶段具有重大影响。SFT & RFT：团队在 SFT 阶段精心策划了八种任务类型和八种编程场景，以确保模型的泛化能力和综合能力。此外，在 RL 之前，创新性地引入了 RFT 阶段，使用人类工程师标注的 "教师轨迹" 作为训练期间的指导。大规模 Agentic RL：当前，扩展智能体 RL 面临三个挑战：非线性轨迹历史的高效学习、利用内在模型信号以及构建可扩展的高吞吐量基础设施。对此，Kwaipilot 团队通过对数概率计算的前缀缓存（Log-Probability Prefix Caching）、基于熵的轨迹剪枝（Entropy-based Tree Pruning）和自研的工业级规模强化学习训练框架 SeamlessFlow 来解决这些问题。 KAT 系列模型的核心技术路线一、Mid-TrainingKwaipilot 团队对经过预训练的模型进行了两阶段训练，该阶段被称为 Mid-Training。在其中的第一个阶段，增强了模型与 “LLM-as-Agent” 相关的全方位能力，包括但不限于以下几种能力：工具调用能力：构建了在沙盒环境真实执行工具的调用方法以及执行结果的交互数据，用于提升模型的工具调用能力；多轮交互能力：构建了最长数百轮的人类、模型、工具的交互数据，用于提升在长文本情况下模型的多轮交互能力；编码知识注入：加入了高质量的与编码相关的领域知识数据，用于进一步增强模型在编码场景下的性能；Git Commit 数据：加入了大量来自于真实 Git 仓库的 PR 数据，用于进一步提升模型在真实编程任务下的表现；指令跟随数据：收集了 30 + 类常见的用户指令，用于增强模型对用户指令的理解能力；通用及思考数据：构建了多类通用数据，用于增强模型在通用领域以及在调用工具时进行思考的能力。二、监督微调 (Supervised Fine-Tuning, SFT) 在第二阶段，Kwaipilot 团队收集了大量人类工程师标记的真实需求交付轨迹，并基于此合成了大量的轨迹数据，进一步对模型进行训练，以增强其端到端需求交付的能力。其中覆盖了多种任务类型：八大用户任务类型：Feature Implementation（功能实现）Feature Enhancement（功能增强）Bug Fixing（缺陷修复）Refactoring（结构优化）Performance Optimization（性能优化）Test Case Generation（测试用例生成）Code Understanding（代码理解）Configuration & Deployment（配置与部署）八大用户编程场景：Application Development（应用开发）UI/UX Engineering（界面与用户体验工程）Data Science & Engineering（数据科学与工程）Machine Learning & AI（机器学习与人工智能）Database Systems（数据库系统）Infrastructure Development（基础设施开发）Specialized Programming Domains（专业编程领域）Security Engineering（安全工程） 三、强化微调（Reinforcement Finetune，RFT）在这一阶段，Kwaipilot 团队在强化学习流程的基础上，额外引入了多个 ground truth 用于轨迹探索的指导，提升 rollout 效率，从绝对 reward 到衡量与 ground truth 的差异，提升了强化学习阶段的效率和稳定性。从直接给定绝对 reward 更新为衡量 rollout 样本和 ground truth 之间的相对差异给了强化学习更稳定和更准确的奖励信号，同时也会在 rollout 阶段实时监督样本的正确性，并及时终止与 ground truth 有明显偏离的样本生成，这也给强化学习带来了更高的样本效率。  图 3：在强化微调（RFT）流程中，引入教师轨迹作为指导  经过三阶段的训练，团队获得了为 RL 阶段准备的冷启动模型，RFT 的加入也为 SFT 和 RL 之间构建了桥梁。Mid-Training：首先，团队教会大模型各种基本技能，包括如何使用工具、如何理解用户意图等；SFT：其次，用高质量的轨迹数据，让模型学习如何执行真实的下游任务；RFT：最后，在模型准备 “自由探索” 之前，先由教师轨迹手把手教会模型如何探索，保障了模型后续在 RL 阶段的稳定性。 四、大规模 Agentic RL1、基于熵的树剪枝（Entropy Based Tree Pruning）Kwaipilot 团队发现，即便使用上述技术，对完整树中的所有 token 进行训练的成本仍然过高，因此亟需设计一种能够优先聚焦于携带最强训练信号节点的机制。为此，团队将轨迹压缩成一个前缀树，其中每个节点表示一个共享前缀，每条边对应一段 token。在固定的计算预算下，目标是只保留最有价值的节点进行训练。团队基于树中聚合的熵信号和节点被到达的可能性来估计节点的信息量，并按照重要性顺序扩展节点来剪枝树，直到预算耗尽。额外的启发式方法确保保留结构上的重要区域（例如，工具或内存事件），并维护局部上下文以稳定训练。这种基于熵的剪枝大幅减少冗余计算，同时保留大部分有效的训练信号，从而实现显著的吞吐量提升和更低的总体成本。 2、RL infra：自研 SeamlessFlow 框架 图 4：Kwaipilot 团队自研的 RL 训练框架 SeamlessFlow 架构 为扩展 RL，必须将 RL 训练与智能体的多样化内部逻辑完全解耦，同时最大化异构计算架构的利用率。遵循 SeamlessFlow 的设计，Kwaipilot 团队在智能体和 RL 训练之间设计了一个专门用于轨迹树管理的中间层，确保两者之间的严格分离。此外，采用提出的标签驱动调度机制来协调异构集群中的任务分配，从而最小化管道气泡并维持高吞吐量训练。 3、统一环境接口和企业级 RL 数据构建Kwaipilot 团队还通过统一不同 RL 执行环境的部署和评估接口，使任何新添加的环境都能以低成本无缝集成。这种统一设计为跨异构数据源和任务类型扩展 RL 训练奠定了坚实基础。具体到软件开发场景，团队聚集于三个基本组件：与相应分支代码配对的问题描述、可执行环境和可验证的测试用例。Kwaipilot 团队从开源仓库收集拉取请求和相关问题，并根据这些仓库的星标、PR 活动和问题内容过滤低质量数据，随后系统地为每个收集的实例构建可执行环境镜像并生成单元测试用例。除了软件工程数据，团队还纳入了其他可验证领域，如数学和推理任务，进一步丰富了 RL 信号的多样性。更重要的是，除了开源数据，团队还进一步收集并利用来自真实世界工业系统的匿名企业级代码库进行 RL 训练。与仅在公共仓库（如 GitHub 上的仓库）上训练不同，这些仓库通常包含较简单的项目，而这些大规模、复杂的代码库 —— 跨越多种编程语言并代表真实的业务逻辑 —— 让模型接触到更具挑战性的开发场景，为 RL 提供了高价值的资产。训练智能体解决这些真实世界的工业问题不仅增强了学习的鲁棒性，还将所得模型的编程能力建立在现实的生产级环境中。  图 5：在 SWE-Bench Verified 上，各阶段训练对模型的性能影响 模型效果展示 KAT-Coder 模型具备强大的代码生成能力，可独立完成完整的项目开发，通过调用编程工具可实现从交互式游戏到代码重构等多样化编程任务。用户仅需描述需求，模型即可交付完整的代码解决方案。1、星空效果  2、水果忍者🥷  3、代码重构  大规模 Agentic RL 后的涌现能力对经过大规模 Agentic RL 训练后的模型进行分析，Kwaipilot 团队观测到了两个显著的涌现现象：对话轮次显著降低：模型倾向于用更少的交互轮次完成任务，相较于 SFT 模型，平均对话轮次下降了 32%；多工具并行调用：模型展现出同时调用多个工具的能力，而非传统的串行调用。 团队推测，这源于轨迹树结构带来的隐式优化压力，使模型自然形成效率偏好与并行调用能力。效率偏好的形成：在轨迹树结构中，较短的路径（更少的对话轮次）会被更多的训练样本共享。这创造了一个隐式的优化压力：模型倾向于学习更高效的解决方案；并行化的自然选择：在树结构中，多工具并行调用创造了更多的分支可能性，这些分支在训练时被独立处理，使得模型能够同时探索多个工具组合。同时熵剪枝机制（Long-term Entropy Pruning）保留了信息量较大的节点，而多工具调用节点往往具有更高的熵值，使模型逐渐学会了 "批处理" 思维。 未来展望Kwaipilot 团队将持续探索代码智能的前沿领域，开拓创新可能：增强工具集成：与流行的 IDE、版本控制系统和开发工作流深度集成，创建无缝的编码体验。多语言扩展：扩展 KAT 模型能力以覆盖新兴的编程语言和框架，确保全面的语言支持。协作编码：探索多智能体系统，让 KAT 模型能够在复杂的软件项目上协同工作，实现前所未有的协作。多模态代码智能：集成视觉理解能力，处理架构图、UI 设计、调试截图和文档图像以及代码，使开发过程更加直观和高效。 原文链接：https://kwaipilot.github.io/KAT-Coder/ 

CCI Administrator 有上传镜像包的权限吗？

CCI 是否提供基础容器镜像的下载服务？

CCI如何制作容器镜像？

CCE集群界面的某个节点磁盘监控高达80%以上，而进入云监控界面看到的磁盘使用率在40%不到