Core Concepts and Object Relationships

This topic helps you understand the primary objects in Siverse and how they work together across development environments, training jobs, and inference service runtimes.

Collaboration Scope and Deployment Location

Before creating a development environment, training job, or inference service, first determine “who can use it” and “where it runs.” These two dimensions must be selected separately.

Concept	Description	Confirm Before Use
Tenant	The management scope of an enterprise or organization.	The currently logged-in account belongs to the tenant associated with the current work.
Project group	The management scope for team collaboration and object visibility; it is not equivalent to a group of physical servers.	Which project group an object belongs to, and which members can view or operate it.
Region and cluster	The deployment location of workloads and the availability scope for resources, images, data, and models.	Required resources and assets are available in the same region and cluster. After switching regions or clusters, recheck the available options.
Resource pool	Computing resources organized by resource type, isolation method, and usage policy.	You have permission to use the resource pool; the resource pool supports the current workload type and provides suitable instance specifications and quotas.

Selecting a project group does not automatically grant permissions for resource pools, images, models, or Volumes. When creating a task or service, object visibility, resource usage permissions, and data read/write permissions must all be satisfied.

Workload-Referenced Resources and Assets

The following diagram illustrates the relationship between the configuration used to create a task or service and the instances that actually run it.

Platform Object and Runtime Relationships

In the figure, Data and Models refers to input files. When needed, select a dataset, model source, or storage mount according to the options supported by the relevant module; not every workload must use both data and models.

Object	Role in Creation and Runtime
Project Group	Determines the collaboration scope and visibility of tasks or services.
Region and Cluster	Determine where tasks or services are deployed, as well as the available resources and assets.
Resource Pool and Specifications	Provide computing resources such as GPUs, CPUs, and memory for tasks or services.
Image	Provides the software environment required for container runtime and the code included in the image.
Data and Models	Are read by workloads as input files and may come from datasets, model sources, or storage mounts.
Tasks or Services	Store the creation configuration and are the objects managed, viewed, modified, and troubleshot by the platform.
Running Instances	The actual execution units started by the platform based on the creation configuration and resource scheduling results.
Persistent Outputs, Logs, and Metrics	Used to save runtime results, explain program behavior, and observe runtime trends, respectively.

Submitting the creation request only indicates that the platform has accepted the configuration. Resource scheduling, image pulling, storage mounting, and application startup must still take place afterward.

Images, Datasets, Models, and Volumes

These types of objects serve different responsibilities. Managing them separately facilitates dependency updates, data reuse, and result preservation.

Object	What It Mainly Stores or Describes	Example Use	Notes
Image	The software environment required by a container, as well as code built into the image.	Pin versions of Python, training frameworks, CUDA, and system dependencies.	Save images to preserve the software environment; they cannot replace storage backups.
Dataset	Data that workloads can select and read.	Mount as input to development environments or training jobs.	Ensure that the target workload can access the dataset and write outputs to a writable Volume.
Model	The model name, version, source, and related information.	Specify weights, a tokenizer, and configuration files for inference.	Model records must correspond to files that are actually accessible; before training artifacts can be used for inference, they may need to be organized or converted.
Volume	Persistent file storage that can be mounted by workloads.	Store project code, Notebooks, training results, and checkpoints.	Paths inside the container are determined by the mount configuration. For example, if a program reads `/mnt/data`, the target data must be mounted at that path.

Execution progress must be saved by the program itself; for example, a training program should save checkpoints. The platform can restart the training task, but it cannot replace the program in saving and loading progress.

Tasks, Services, and Running Instances

When you create a training job or inference service, you configure a platform-managed object. Based on this configuration, the platform starts one or more running instances.

Relationship	Description	What to Check During Use
Creation configuration	Includes information such as the image, commands, resources, mounts, ports, and environment variables.	Whether the configuration matches the code, data, model, and resource requirements.
Running instance	The actual execution unit started by the platform based on the creation configuration and resource scheduling results.	Whether the target instance has been created and whether the expected number of ready instances has been reached.
Status, events, and logs	Record the object lifecycle, scheduling process, and program runtime output.	Whether the issue is caused by a configuration not taking effect, resources not being scheduled, or an exception in the program itself.
Persistent output	Written by the program to a Volume or other persistent storage to save results and resume progress.	Whether outputs, checkpoints, or model files have been written to a persistent location.

Tasks or services are not directly equivalent to running instances in terms of quantity. A service may have multiple replicas, and a training task may also include multiple roles or execution units.

Specification Count, Replicas, and Resource Usage

Instance specification describes a set of resources, such as GPU, CPU, and memory. Number of specifications determines how many sets of specifications an execution unit requests, while number of replicas determines how many such execution units are needed. For example, each allocation includes 2 GPUs, each replica uses 2 allocations, and 2 replicas are running in total:

Calculation Item	Calculation Result
GPU requirement per replica	2 GPUs × 2 copies = 4 GPUs.
GPU requirement for all replicas	4 GPUs × 2 replicas = 8 GPUs.

CPU and memory are calculated using the same quantities and replica counts. For multi-role jobs, sum the resources for each role; for multi-node inference, also account for the number of nodes in each group. Refer to the resource configuration on the relevant creation page for details. Quota indicates the amount of resources allowed for use, while schedulable capacity indicates the amount of resources that can actually be scheduled under current conditions. Even when the quota is sufficient, tasks or services may still wait because of nodes, instance type combinations, resource pool status, or scheduling policies.

Permission and Visibility Boundaries

Project team visibility, resource usage rights, and data read/write permissions are distinct permission boundaries.

Requirement	Required Conditions
View task configurations, status, and logs	Object visibility and the corresponding view permissions.
Stop, delete, or modify objects	Permissions for the corresponding operations and authorization for the object scope.
Submit tasks or services using a resource pool	Resource pool usage permission, available quota, and an appropriate instance specification.
Read data or write results	Read and write permissions for the Volume, directory, or data source.
Reuse another user’s configuration	Meet the applicable requirements for using compute resources, images, models, and storage, and reset the output path.

Task links are used to locate objects and do not grant access permissions themselves. Before sharing configurations, commands, environment variables, or logs, ensure that they do not contain passwords, access tokens, storage keys, or other sensitive information.

Next Steps

Quick Start with Siverse

Get Started

Resources

Development & Training

Models & Inference

Operations & Governance

Best Practices

Developer Access

FAQ

Core Concepts and Object Relationships

Collaboration Scope and Deployment Location

Workload-Referenced Resources and Assets

Images, Datasets, Models, and Volumes

Tasks, Services, and Running Instances

Specification Count, Replicas, and Resource Usage

Permission and Visibility Boundaries

Next Steps

​Collaboration Scope and Deployment Location

​Workload-Referenced Resources and Assets

​Images, Datasets, Models, and Volumes

​Tasks, Services, and Running Instances

​Specification Count, Replicas, and Resource Usage

​Permission and Visibility Boundaries

​Next Steps

Collaboration Scope and Deployment Location

Workload-Referenced Resources and Assets

Images, Datasets, Models, and Volumes

Tasks, Services, and Running Instances

Specification Count, Replicas, and Resource Usage

Permission and Visibility Boundaries

Next Steps