Getting Started with Siverse

This guide follows the common path for first-time use of Siverse, helping you first confirm the operating scope, resources, and assets, and then proceed to development and training, model deployment, or general service publishing based on your objectives.

​

First-Time Setup

For first-time use, it is recommended to complete a small-scale validation first: read a small number of samples, execute a few training steps, or send a test request. After confirming that the resources, paths, and dependencies are correct, scale up the operation. When a resource or object cannot be found, first check the tenant, region, cluster, project group, and filter criteria. After confirming that the scope is correct, ask the administrator to verify the permissions. All in the list only changes the filter scope; it does not grant additional access permissions.

​

Select a Workload

Select the entry point based on the work objective, then prepare the corresponding resources and assets.

​

Typical Usage Path

Starting from development and debugging, the complete development and service workflow typically includes resource and asset preparation, development and debugging, training and fine-tuning, model artifact verification, inference service creation, and service request validation. If existing training configurations, existing models, or existing custom application images are available, you can enter at the corresponding stage without executing the entire workflow from the beginning. The complete path represents a common workflow handoff and does not mean that the platform automatically executes the entire pipeline. Development, training, and serving use separate configurations; at handoff, the image, file locations, model version, and resource requirements must be specified explicitly.

​

Debug the Code and Complete Training

Suitable for scenarios that move from data exploration and code debugging into training or fine-tuning. The same dataset can be used by different tasks, and output directories should be separated by experiment. Before starting a full long-running training job, first verify checkpoint saving and loading; enabling only platform-level retry cannot verify whether training progress can be resumed. Reference document:

• Prepare instance resources
• Create and use storage volumes
• Use the JupyterLab development environment
• Use the VSCS development environment
• Create training tasks

​

Model deployment as an inference service

Suitable for existing models or scenarios where online reasoning capability needs to be provided externally after training is complete. The trained checkpoint may need to be organized or converted according to the engine requirements before being used for deployment. Before increasing service capacity, distinguish whether the model cannot fit in a single replica or whether the existing replicas lack sufficient request-processing capacity. Reference document:

• Register and Manage Custom Models
• Inference Service Overview
• Create LLM Inference Services
• Test LLM Inference Service Functionality

​

Deploy Custom Container Applications

Suitable for containerized business APIs, self-developed inference services, retrieval services, OCR services, or other HTTP/gRPC applications. Before release, verify the additional capacity required for parallel operation of the new and old versions. Stateful applications must also confirm data compatibility; rolling back the application version does not restore data that has already been modified. Reference document:

• Build a Custom image
• Synchronize an image to Other Clusters
• Create a general service
• Manage a general service

​

How to Confirm the Results After Submission

A successful submission message only indicates that the platform has accepted the creation or modification request. Continue to verify the following results to determine whether the task or service has actually achieved the expected outcome.

• The configuration and request records are consistent with expectations.
• Resources have been scheduled, and the target instance or replica has entered the available state.
• The logs contain no exceptions related to image pulling, storage mount, startup command, or model loading.
• Output files, checkpoints, service requests, or performance results meet the objectives of this run.

If a task or service does not run as expected, refer to the troubleshooting documentation for the relevant module based on the stage at which the issue occurred. When contacting platform support, provide the object link and ID, region, cluster, project group, time of occurrence, expected result, and sanitized error information.