Key Concepts

This section introduces some important concepts mentioned in HyperAI.

Computing Container

Computing Container, also frequently referred to as "container" in the documentation, can be simply understood as a small machine that provides specific resources. When creating a container, you need to specify "computing power" (CPU, memory, disk size), select an "image" (which can be understood as pre-installed applications), and bind "data".

Each "execution" of a container provides independent storage space bound to the /openbayes/home directory as its working directory. After execution ends, the contents are also saved.

Each execution can bind other data through the following directories when created:

• /openbayes/input/input0
• /openbayes/input/input1
• /openbayes/input/input2
• /openbayes/input/input3
• /openbayes/input/input4

For more information about data binding, please refer to Data Binding.

Computing container "execution" currently supports two methods:

1. Python scripts
2. Jupyter Workspace

The "Python script" method allows users to upload their own code and specify the command to execute. The container will execute the Python script according to the user-specified entry command when starting. It is suitable for one-time, infrequently modified long tasks, such as a model training task lasting 12 hours.

Jupyter Workspace is an interactive code execution tool. After creating a Jupyter Workspace, we can perform some immediate command execution and experimental work on it. It is suitable for early-stage model debugging and construction.

:::caution Note Once a Jupyter Workspace is in running state, billing begins until the user actively closes it. Even if the user is not using the computing resources, billing continues normally due to the exclusive nature of computing resources. Therefore, please close the Jupyter Workspace promptly once you are no longer using it to avoid unnecessary charges. :::

"Executions" under the same "container" are considered to have close business relationships, and each "execution" of a "computing container" is recorded independently.

However, the environment of each "execution" is isolated, meaning that any installation commands executed during an "execution" cannot be recovered after that execution is closed. Even an "execution" launched through "Continue Execution" still has a completely new environment.

Data Warehouse

Users can create a Data Warehouse to save and reuse data. Currently, it is divided into two types: datasets and models. Generally speaking, datasets are quite large in scale, and repeatedly uploading code and data for each run is very impractical. Therefore, a separate area is provided here for dataset management.

Binding Data Warehouse

When creating a "computing container", you can bind the data warehouse to the container for use through "Bind Data". Currently, "containers" support up to 5 data bindings.

As shown in the diagram below, when creating a container, you can select a data repository or the "working directory" mentioned below to be bound to any of the following directories: /openbayes/input/input0, /openbayes/input/input1, /openbayes/input/input2, /openbayes/input/input3, /openbayes/input/input4, /openbayes/home. When the container is created, the corresponding data repository or working directory will be bound to the corresponding directory.

As shown in the diagram above, the openbayes/cifar-100 Image Classification Dataset/2 data repository will be bound to the /openbayes/input/input0 directory in the container, and can be accessed at /openbayes/input/input0 after the container is running.

User's "Storage Space"

Data repositories uploaded by users, code, and content saved after container closure are all stored in the user's "storage space". Users can view their storage resource usage on their personal page. Once the user's total storage limit is exceeded, the user will no longer be able to create containers or upload data.

More information can be found at Quota and Usage.

Container's "Working Directory"

The "working directory" refers to the /openbayes/home directory in each "execution". Data in this directory will be automatically saved after the container is closed, and its usage will also be reflected in the user's "storage space". This means that all content that needs to be saved should be stored in this directory.

:::important Important Notes

• All data that needs to be persisted must be stored in the "working directory" (/openbayes/home)
• Do not store data on the system disk (other locations under the root directory /), as data on the system disk will be lost after the container is closed
• The size of the "working directory" is fixed according to the selected computing power type and cannot be adjusted by yourself. Please pay attention to the storage space limit of the corresponding computing power type when creating a container :::

The relationship between the "workspace" bound to /openbayes/home by default in the container and the "storage space" is as follows:

1. The capacity of the container's "workspace" is the storage capacity limit of /openbayes/home. When using this container, the total capacity of files stored in this directory cannot exceed this limit.
2. Data in the "working directory" will be persistently saved, even after the container is closed, so naturally this data will also occupy the capacity of the "storage space".

Computing Power

Computing power defines the amount of resources provided for container execution on HyperAI. Currently, HyperAI mainly provides two types of computing power:

1. CPU computing power, containing a certain number of CPUs, executing machine learning algorithms through CPUs
2. GPU computing power, containing one or even multiple GPUs, which can utilize GPU versions of deep learning frameworks to accelerate the training and inference of deep learning models

Each type of computing power provides memory and storage limits. Exceeding the memory or storage usage limits during container operation will lead to task failure.

Runtime Environment

Runtime environment, also known as images, provides the types of main machine learning algorithm libraries that the container depends on during execution. Currently, HyperAI provides standard libraries for different versions of TensorFlow, PyTorch, MxNet, and Darknet in both CPU and GPU environments. More types of machine learning algorithm libraries will be provided in the future.

For more information, please see Runtime Environment.

Multi-Port Mapping

After completing real-name authentication, users can customize the correspondence between internal services and external access ports under "Create Container" - "Port Mapping". Access addresses will be automatically generated after the container status shows "Running". Port numbers 22, 5901, 6006, 6637, 7088, and 8888 are all reserved port numbers and cannot be configured for port mapping.

:::caution Note Port mapping names cannot be duplicated, otherwise an error will occur :::