CubeStudio: A Kubernetes-Native AI Platform That Tries to Cover Annotation, Training, and Serving in One Repo

The Gap CubeStudio Targets: One Platform Instead of Six

Most machine learning teams end up assembling a platform from parts. A notebook server here, an experiment tracker there, a pipeline tool, a serving layer, a labeling tool, and a scheduler bolted on top. Each part has its own user database, its own permission model, and its own way of mounting storage. CubeStudio's premise is that this assembly is the actual problem, and that a single Kubernetes-native application can hold all of it: multi-tenant accounts, GPU scheduling, notebook development, drag-and-drop pipeline authoring, distributed training, hyperparameter search, inference serving, annotation, and an LLM stack covering fine-tuning and retrieval. The README describes it as covering traditional machine learning, deep learning, and the full large-model chain under the labels MLOps, MaaS, and compute scheduling. The intended user is not an individual data scientist. It is a platform team inside a company that needs to give many users access to shared accelerators with quotas, billing, and project isolation, and that may be required to run on domestic hardware or entirely offline inside a private network. The README states the platform supports 信创 (domestic technology stack) private deployments and intranet offline installation, which is a constraint that eliminates most Western MLOps products from consideration before any feature comparison begins.

How the Pieces Fit: Kubernetes Objects, Resource Groups, and Pipeline DAGs

The architecture is Kubernetes all the way down. Jobs, notebooks, and inference services become pods; the platform's job is deciding which cluster and which resource group those pods land in, and what they are allowed to consume. The README describes a hierarchy of resource groups and clusters, with project groups bound to one or more resource groups, and a per-project namespace option. GPU allocation is not a single mode but a set of them: disabled, shared, exclusive, and vGPU, with the vGPU mode allowing a configured amount of video memory to be reserved. Scheduling policies include a binpack strategy, and NVIDIA cards can be pinned by index. This is the layer where CubeStudio does real work rather than wrapping someone else's API. On top of scheduling sits the pipeline engine, which the README describes as a drag-and-drop canvas where each node is an operator: a custom image, a Python node, a logic node, a data sync step, or one of a long list of feature-engineering operators covering joins, deduplication, encoding, scaling, sampling, dimensionality reduction, and feature importance. Pipelines support scheduled runs, backfill, concurrency limits, timeouts, instance dependencies, global constants, and pause and resume. The README also notes that a running task or pipeline can expose a listening port, which means a training job can serve something while it runs. Data flows between nodes through the platform's storage mounts, and the README lists NFS, CFS, OSS, NAS, COS, GlusterFS, CephFS, and S3/MinIO as supported backends, mounted directly into pods. That storage list is the connective tissue: without it, the pipeline operators would have nowhere to read and write.

Hardware Coverage Is the Differentiator, and the README Says So

The feature table devotes more space to accelerator and architecture support than to almost anything else. Beyond NVIDIA T4, V100, and A100, the README lists scheduling support for Hygon DCU, Huawei NPU (Ascend), Biren, MetaX, Cambricon, Moore Threads, and Baidu Kunlun. It states that ARM architecture is supported across backend components, frontend images, task templates, notebook images, and hyperparameter search, and that about 70 percent of AIHub applications support ARM. Networking support includes IB, RoCE, and RDMA, with RDMA resources described as pass-through into distributed task templates. If your procurement is constrained to a domestic accelerator vendor, this breadth is the reason to look at CubeStudio at all; most platforms in this category assume NVIDIA and stop there. The trade-off is that breadth of hardware support usually means breadth of untested combinations. The README does not publish a compatibility matrix showing which accelerator works with which operator, which inference engine, or which distributed training template. It lists capabilities, not verified pairings. Treat the hardware list as a set of claims to validate against your specific card, driver, and Kubernetes version rather than a guarantee.

LLM Stack: Fine-Tuning, vLLM Serving, and a Token Relay

The large-model portion is built from recognizable open components rather than a proprietary runtime. The README names vLLM, Ollama, and MindIE as inference engines for multi-machine large-model serving, and describes training support for SFT fine-tuning, reward models, and reinforcement learning. Retrieval is covered by a private knowledge base with what the README calls LLMOps and agents. There is also an AI model marketplace and a token relay or token 中转 function, which the description places alongside compute leasing. That combination suggests a deployment model where an organization resells or brokers both GPU time and model API access internally. The token relay is the least specified part of the README. There is no detail on rate limiting, key rotation, upstream provider configuration, or how usage is metered against the billing system that the compute section describes in some depth. If token brokering is your reason for evaluating CubeStudio, that gap matters: the billing and quota machinery is documented in terms of resource limits on notebooks, Docker builds, pipelines, hyperparameter search, internal services, and inference services, and it is not stated how token consumption maps onto those quotas.

Running It: Helm, Ports, and the Configuration Surface

Deployment is Kubernetes-native. The README points to the project wiki for installation, and the repository is organized as a Python application with a frontend and a set of infrastructure manifests. The concrete facts available in the supplied material are these: the platform needs a metadata database, and the README states support for external MySQL, PostgreSQL, OceanBase, Kingbase, and Dameng, with the explicit caveat that the annotation module is excluded from that list. Storage backends are configured per mount and bound to project groups. Networking supports port 80 and non-80 ports, public or domain access, reverse proxy and intranet tunneling, and HTTPS. Machine-level settings are exposed through a web interface: scheduling type, resource group membership, whether RDMA is enabled, whether vGPU is enabled, and which task scenarios the machine can serve. Internationalization is a configuration option with eight languages listed for the MLOps side and separately for the annotation module. The README does not include a copy-pasteable install command block in the portion available, so anyone evaluating this should go to the wiki at github.com/data-infra/cube-studio/wiki before planning a pilot. The honest summary is that installation is a multi-component Kubernetes deployment, not a single container you run locally.

Where CubeStudio Is the Wrong Choice

The cost of consolidation is operational surface area. CubeStudio runs a web application, a scheduler integration, a pipeline engine, an annotation service, an image registry workflow, and multiple inference runtimes inside one Kubernetes cluster. Every one of those is something your team must upgrade, monitor, and debug. A team of three data scientists with a single A100 node does not need multi-tenant project isolation, compute leasing, or a token relay, and will spend more time on the platform than on models. The README's own scope makes this clear: it lists compute leasing with monthly and daily billing, daily settlement, and rental instance management. Those are features for an organization that sells or internally charges for compute. If nobody is charging anybody, that machinery is pure overhead. A second limitation is documentation depth. The README is a feature inventory with a wiki link. There is no published compatibility matrix for the accelerator list, no detail on token relay configuration, and no stated upgrade path between the dated releases. The release cadence visible in the repository is roughly quarterly, with tags like v2026.06.01 and v2026.03.01, which suggests feature drops rather than continuous patching. A third point is the licence discrepancy: the repository metadata reports NOASSERTION while the README states MIT and free commercial use. Those two statements need reconciling before any legal review, and the README's claim is not a substitute for reading the actual licence file.

Alternatives and the Real Difference in Approach

The closest comparison is Kubeflow. Both assume Kubernetes and both aim to cover the training lifecycle, but they differ in what they consider the center of gravity. Kubeflow is a federation of upstream projects (Pipelines, Notebooks, Katib, KServe) that you assemble and version independently. CubeStudio is a single application that owns the user model, the permission model, the resource group model, and the billing model itself, with pipelines and notebooks as features inside it. That means CubeStudio can offer things Kubeflow does not attempt, such as compute leasing with monthly bills, a token relay, and a domestic-accelerator scheduling layer, because those require a unified notion of user and quota. It also means you adopt CubeStudio's opinions wholesale. If you want to swap the pipeline engine but keep the notebook environment, the unified design works against you. For teams whose priority is the LLM serving path specifically, a narrower stack built directly on vLLM plus a Kubernetes operator is less to operate and easier to reason about, at the cost of the annotation, pipeline, and multi-tenant layers that CubeStudio provides. The choice is between one system with a large footprint and several systems with seams between them.

Maintenance, Upgrades, and Licence Questions to Settle First

The repository is active, with the most recent push in August 2026 and releases at roughly quarterly intervals. That cadence is workable for a platform you deploy internally, but it means upgrade planning has to be deliberate: there is no evidence in the supplied material of long-term support branches or a documented migration procedure between release tags. Budget for a staging cluster that mirrors production, because a platform that manages pods, storage mounts, and accelerator scheduling cannot be validated on a laptop. On licensing, the README states MIT with free commercial use, while the repository metadata says NOASSERTION. The README also notes that the old repository at tencentmusic/cube-studio is no longer being synchronized, so anyone arriving from older documentation or forks should confirm they are reading material for data-infra/cube-studio on the main branch. None of this is legal advice; it is a list of things to check in the repository's licence file and release notes before a procurement decision. The practical first step is to read the wiki installation page and confirm the supported database and accelerator combinations for your environment, since the annotation module's database support is explicitly narrower than the rest of the platform.

Editorial conclusion

CubeStudio fits teams that already run Kubernetes and want one internal platform covering notebook development, pipeline orchestration, distributed training, and LLM serving, especially if they must schedule domestic accelerators such as Ascend or Cambricon alongside NVIDIA GPUs. It does not fit a small team that wants a thin training wrapper, or anyone unwilling to operate a multi-service Kubernetes stack. Before committing, verify two things against the wiki: the exact licence text, because the repository reports NOASSERTION while the README claims MIT, and the supported database matrix for the annotation module, which the README says excludes the external databases listed for the rest of the platform.

Official sources

1. data-infra/cube-studio on GitHub
2. Issues
3. Project website
4. README
5. Releases