CubeStudio 是一款国产化、云原生的一站式开源人工智能平台，同时覆盖传统机器学习、深度学习与大模型全链路（MLOps / MaaS / 算力调度 / 训推平台），开源协议 MIT，开源免费商用，开源版本已有数千家企业私有化部署。平台提供多租户与算力纳管调度、算力租赁与 Token 中转站、拖拉拽 Pipeline 任务流编排、多机多卡分布式训练、超参搜索、推理服务、vGPU 虚拟化、云边端协同与边缘计算、图文音多模态自动化标注、大模型 SFT 微调 / 奖励模型 / 强化学习训练、vLLM / Ollama / MindIE 大模型多机推理、私有知识库 / LLMOps / 智能体、AI 模型市场，以及从数据到上线的全流程模型部署。原生适配昇腾、寒武纪、海光、摩尔线程、沐曦等国产异构算力与 x86 / ARM CPU 架构，支持 IB / RoCE / RDMA 高速网络及信创私有化、内网离线部署。
官网：www.cubestudio.vip ｜ GitHub：github.com/data-infra/… ｜ Gitee：gitee.com/data-infra/…
关键词：CubeStudio、cube-studio、分布式训练、distributed training、CRD、operator、train-operator、TensorFlow、PyTorch、Horovod、MPI、Ray、ring allreduce、gang调度、kube-batch、volcano、批调度、优先级调度、kube-scheduler、打分策略、RequestedToCapacityRatioPriority、亲和反亲和、GPU利用率、DCGM、共享GPU、vGPU、DALI、资源动态调整、资源池均衡
分布式训练不是「多加几台机器就快」那么简单。真正的挑战在调度层：多个分布式任务抢一个资源池会死锁，worker 乱放会被网络时延拖垮，GPU 利用率上不去多买的卡全是浪费。CubeStudio 在云原生分布式训练上做了一整套调度与加速设计。本文从架构角度讲清它怎么建集群、怎么调度、怎么把算力榨干。
一、分布式集群怎么自动建：CRD + Operator
要跑分布式，先得有分布式集群（tf / pytorch / spark / ray / mpi / horovod / volcano / mxnet 等）。CubeStudio 用云原生标准范式实现「按需自动建集群」，需要四层支持：
- CRD 描述集群：用户每次的框架和规模都不同，用一个 CRD（一份 yaml）描述本次要什么样的集群。
- Operator 创建集群：Operator 监听、解析 CRD，创建并监控里面定义的集群。tf/pytorch/mxnet/ray 有官方 K8s 方案可直接用；多机多卡训练基于
train-operator开发，horovod 基于 mpi-operator 开发。 - 代码识别角色：有状态集群里，用户代码要能识别自己是什么角色（
role:ps/role:worker）——K8s 里主要靠环境变量。无状态集群则只管收任务、处理、返回。 - 框架支持分布式：算法框架本身要支持分布式通信协议与角色分工。
二、选对分布式框架
按角色形式，分布式框架分三类，选型直接影响效率：
| 类型 | 特点 | 代表 |
|---|---|---|
| 无状态 | worker 可横向扩展、无数据倾斜；但受任务分发机制限制（Ray 只能传可序列化函数） | Kafka 消费者、Ray |
| 有序（不定义通信） | 预先分配好各 worker 的任务；易出数据倾斜（一个慢 worker 拖垮全局） | volcano-job |
| 分角色有序（定义通信） | 既分工又协同，worker 要知道如何访问其他 worker | TensorFlow / PyTorch 的 ring allreduce |
同一框架也有多种模式：tf 分布式既有 PS 模式也有 ring allreduce——单机放得下模型时 ring allreduce 效率更高，放不下时用 PS 做模型并行。
三、三层调度优化：让多机算力真正用起来
平台在三个层次做均衡，避免分布式任务过早撞上性能瓶颈。
1. 亲和 + 反亲和
- 同任务的不同 worker：GPU 训练若通信时延占比高，倾向把 worker 放同一台机器（减少跨机通信）；CPU 训练前向计算耗时大、通信可忽略，则倾向分散到不同机器多吃 CPU。
- 同 Pipeline 的不同 task：CPU/内存 K8s 能隔离，但网络 IO、磁盘 IO、三方限速隔离不了。所以作用相同的并行 task 倾向打散到不同机器。
2. 修正 kube-scheduler 打分策略
K8s 调度分「过滤 + 打分」两段（像推荐的召回+排序）。默认 RequestedToCapacityRatioPriority 倾向调度到「之前跑成功过的机器」，这不适合分布式训练——我们要调度到资源申请率最低的机器。
平台在 install/kubernetes/scheduler-policy-config.json 提供了修正配置：把 RequestedToCapacityRatioPriority 的 shape 设为 utilization:0 → score:10、utilization:100 → score:0——利用率越低分越高，从而把新 pod 优先铺到最空的机器上。
3. gang 调度：解决资源死锁
多个分布式任务抢一个池会死锁：3 台 4 卡机器，每任务 4 个 worker 各占 1 卡，本应最多同时跑 3 个；但若同时提交 4 个，可能每个都只起了 3 个 worker、第 4 个抢不到卡，于是全部互相等待。
CubeStudio 引入 kube-batch 的 gang 调度：调度队列里先算「剩余资源能否满足全部 worker」，要么全占要么不起，从根上避免死锁；再用 volcano 在批调度基础上叠加优先级调度。
四、把 GPU 利用率榨干
GPU 是整卡独占的（训练不推荐用 vGPU），利用率上不去就是纯浪费。GPU 利用率低的本质是 CPU 操作慢阻塞了 GPU 计算（数据加载/预处理/存模型/算 loss/打日志等）。
平台从监控到优化给出完整手段（GPU 利用率采集自 dcgm-exporter 的 DCGM_FI_DEV_GPU_UTIL）：
数据加载：提高 PyTorch num_workers / tf num_parallel_calls；开 prefetch（CPU、GPU 并行）；pin_memory=true；先增大 batch_size 吃满显存再调 num_workers。
数据预处理：把预处理和训练拆成两个 task，让 GPU 只做训练；用 NVIDIA DALI 把预处理搬到 GPU。
减少频繁 IO：降低 checkpoint / tensorboard 保存频率；别在训练迭代里打个人日志（频繁 CPU/GPU 切换）。
单 worker 通信也能优化：容器间 TCP 通信受内核版本影响，Linux3 升到 Linux4 后 pod 间实测带宽从 1.3Gi 提到 18Gi（主机 25Gi），再加 NVLink 等方案。
五、架构层兜底：共享 GPU 与动态资源调整
代码优化需要用户配合，用户搞不定时就靠架构层解决：
- 共享 GPU：用户代码 GPU 利用率只有 10% 时，与其多买卡，不如让多个进程共享一张卡——重置每个进程的 rank/world_size，在同一张卡上跑出更多 worker 的效果，直到某项资源（如 CPU）到瓶颈。这与训练中用 vGPU 不同：vGPU 会造成算力碎片化、且只提利用率不加速，更适合推理。
- 任务资源动态调整：用户常不知道该申请多少资源，平台会智能修正 CPU/内存（GPU 独占不缩减）。特殊任务可在模板里用
TASK_RESOURCE_CPU/_MEMORY/_GPU/_RDMA固定资源，或用NO_RESOURCE_CHECK屏蔽动态校验。 - 资源池动态均衡：一个集群内的多个项目组之间做均衡——保住每组最低算力，临时任务从公共池借算力、用完释放回去。
小结
CubeStudio 的分布式训练加速是一条从「建集群」到「榨算力」的完整链路：CRD+Operator 自动建集群、三类框架选型、亲和反亲和 + 打分修正 + gang 调度三层调度、GPU 利用率代码优化 + 共享 GPU + 动态资源均衡兜底。目标只有一个——让每一张卡都不闲着，让多机算力真正线性转化为训练速度。
了解更多
CubeStudio 采用 MIT 开源协议，开源免费商用并支持源码交付与二次分发，开源版本已有数千家企业私有化部署。
- 官网与在线文档：www.cubestudio.vip
- 开源仓库（GitHub）：github.com/data-infra/…
- 开源仓库（Gitee）：gitee.com/data-infra/…
