> ## Documentation Index > Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt > Use this file to discover all available pages before exploring further. # Getting Started with Siverse > Learn about the preparations for first-time use of Siverse, typical usage paths, and post-submission checks. 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 | Preparation Item | Condition for Proceeding | | - | - | | Confirm the tenant and project group | You can access the project group and feature entry points required for this work. | | Select the region and cluster | Compute resources, image, data, and models can be used together in the same deployment location. | | Check compute resources | You have permission to use the target resource pool, an applicable instance specification, and the required quota. | | Prepare storage | The input directory is readable, the output directory is writable, and important files have a persistent storage location. | | Prepare runtime content | The image can be pulled; the versions of code, data, or models are clearly defined; and startup parameters have been checked. | | Define minimum validation | You know which sample, command, or request to use to determine whether this run has succeeded. | 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. | Task to Complete | Selection | Runtime Characteristics and Completion Criteria | | - | - | - | | Analyze data and experiment with algorithms by cell. | **JupyterLab** | Interact through a browser; notebooks can be executed and saved. | | Develop projects using an editor, terminal, or local IDE. | **VSCS** | Connect through a browser or SSH; code and dependencies are validated successfully. | | Run long-running training, fine-tuning, or platform-supported batch jobs. | **Training** | Executes according to the startup command; training progress and persistent outputs meet expectations. | | Load a model and continuously respond to inference requests. | **LLM Inference** | Configure the model, engine, and role resources; actual requests are validated successfully. | | Deploy custom HTTP/gRPC applications or container services. | **General Service** | Configure the image, command, ports, and publishing method; the service endpoint is available. | ## 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. ![Siverse usage paths](https://mintcdn.com/scitix-adfc65c2/ZqwdmfntBUDyGPkJ/siverse/get-started/media/ai-platform-usage-paths-orange.svg?fit=max\&auto=format\&n=ZqwdmfntBUDyGPkJ\&q=85\&s=1014cfc1c3bd96e9240ade881475686d) 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. | Stage | Main Activities | Deliverables for the Next Stage | | - | - | - | | Prepare Inputs | Obtain resource and storage permissions; prepare data and image. | Readable data, available image, and an isolated output directory. | | Development and Debugging | Validate samples, dependencies, and the startup command in **JupyterLab** or **VSCS**. | Fixed code version, dependency versions, and runtime parameters. | | Submit Training | Configure the task type, resources, mounts, and commands. | Traceable task ID, training logs, and run records. | | Confirm Results | Check training progress, results, and checkpoints; verify recovery when training needs to be resumed. | Persistently stored results, model files, and configurations required for reproduction. | 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](/siverse/resources/prepare-compute-resources.md) * [Create and use storage volumes](/siverse/resources/create-and-use-storage-volumes.md) * [Use the JupyterLab development environment](/siverse/development/use-jupyterlab-development-environment.md) * [Use the VSCS development environment](/siverse/development/use-vscode-server-development-environment.md) * [Create training tasks](/siverse/training/create-training-tasks.md) ### 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. | Phase | Main Actions | Completion Check | | - | - | - | | Prepare the model | Confirm the version, weights, tokenizer, configuration, and storage location. | The complete files are accessible in the target environment. | | Select an execution plan | Select a compatible engine, and configure the currently supported deployment methods and role resources. | The role resources match the model and parallelism parameters. | | Create the service | Configure the model source, port, probe, access method, and required capacity. | The target instance is ready and the model has finished loading. | | Validate and integrate | Obtain the actual endpoint, and test the protocol, authentication, and model identifier. | Response content, error rate, latency, and throughput meet the requirements. | 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](/siverse/models/register-and-manage-custom-models.md) * [Inference Service Overview](/siverse/inference/inference-services-overview.md) * [Create LLM Inference Services](/siverse/inference/create-llm-inference-services.md) * [Test LLM Inference Service Functionality](/siverse/inference/test-llm-inference-service-functionality.md) ### Deploy Custom Container Applications Suitable for containerized business APIs, self-developed inference services, retrieval services, OCR services, or other HTTP/gRPC applications. | Stage | Main Actions | Completion Check | | - | - | - | | Prepare the application | Build a fixed-version image and define the command, listening port, and external dependencies. | The image can be pulled in the target cluster, and the application can start. | | Create the service | Configure replicas, resources, storage, probes, and the gateway. | The target replicas are ready, and the required dependencies are accessible. | | Validate requests | Send test requests using the actual endpoint. | The path, authentication, and business responses are correct. | | Release changes | Update directly or perform a gradual rollout according to the team process, and retain a rollback version. | After the new version is stable, clean up old instances according to the release process. | 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](/siverse/images/build-custom-images.md) * [Synchronize an image to Other Clusters](/siverse/images/sync-images-across-clusters.md) * [Create a general service](/siverse/inference/create-general-inference-services.md) * [Manage a general service](/siverse/inference/manage-general-inference-services.md) ## 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.