> See the full index of documentation pages at https://docs.zettabyte.com/llms.txt.

# How zCLOUD works

> A five-minute mental model of zCLOUD: how GPUs, tasks, images, and storage fit together. Read this once and the rest of the docs will make sense.

Source: https://docs.zettabyte.com/docs/get-started/how-zcloud-works

Last updated: 2026-07-21

zCLOUD gives you GPUs, work that runs on those GPUs, the images that work runs from, and the storage that keeps your results. This page connects those pieces so the rest of the docs read as a single system rather than a set of screens.

## The two workspaces

zCLOUD has two workspaces under app.zettabytecloud.com:

- zCLOUD, where you provision compute and run work: Instances, Tasks (Training, Fine-Tuning, Inference), Library (Images, Models, Datasets), and billing.
- zSTUDIO, the model-serving surface, where deployed inference endpoints appear.

## Instances vs. tasks

An Instance is a reserved block of GPU capacity. Billing starts the moment a resource is allocated to you, whether or not you are actively running anything, and continues until you release it. There is no pause, so you release the instance to stop billing.

A Task is a unit of work that runs on allocated capacity. Everything you run, whether training, fine-tuning, or inference, runs as one or more pods (containers) launched from an image. Tasks come in three types:

- Training, a job with a start and an end (run a script, train a model, exit).
- Fine-Tuning, a specialized, guided form of a training job for adapting an existing model.
- Inference, a long-running service that exposes your model over an API endpoint.

> [!NOTE]
> **Do I need an instance before a task?**
> You run tasks against capacity you have been allocated. If capacity is not immediately available when you create a task or launch an instance, you use the resource queue (see The resource queue).

## Images

Every pod is launched from a container image, which is how your code and environment get onto a GPU. You can use a preset image (for example a `PyTorch` or `vLLM` image), or bring a custom or private image. For anything beyond light iteration, the recommended workflow is to package your code into an image rather than developing entirely in the in-platform IDE (see Notebooks and IDEs and Container images).

## Storage and what persists

This is where most new users get caught. By default, anything a task writes is **ephemeral**: when the task ends, it is gone. To keep data such as trained weights, checkpoints, code, and datasets, you must write it to persistent storage:

- Storage Volume (`PVC`), a persistent folder (think of it as a file system or network drive) that outlives any single task. Your tenant gets a default one (`ZB shared data PVC`), and you can create more. You mount a `PVC` into a task at a path you choose (convention: `/workspace`).
- Ephemeral Volume, fast, memory-backed scratch space, sized in GiB. Cleared when the task ends.
- `S3`, bring your own bucket (credentials and path), or an external AWS `S3` URL.

See Storage and PVCs for the full model.

## The scheduler

Under the hood, zCLOUD schedules all work through a scheduler (`Volcano`). When you set a task's Priority (1 to 6) and GPU count, the scheduler decides what runs and when, based on available capacity and priority. You do not operate the scheduler directly, but knowing it is there explains why a task may queue rather than start instantly.

## Putting it together

The typical flow from code to a served model:

1. Get code and environment into an image (or use a preset).
2. Create a `PVC` for anything you need to keep.
3. Launch an instance or create a task, and if capacity is short, join the queue.
4. Run training or fine-tuning, writing outputs to your `PVC`.
5. Deploy the resulting model as an inference endpoint and call it over the API.
6. Release resources you are done with to stop billing.