A Method and System for Dynamic Allocation and Cross-Node Migration of GPU Resources Based on Containerized Environments

Abstract

This invention relates to the field of GPU resource allocation technology, specifically to a method and system for dynamic allocation and cross-node migration of GPU resources in a containerized environment. The method includes: real-time monitoring of the container status corresponding to the container; collecting dimensional data corresponding to each dimension in a data collection dimensional set; evaluating the GPU resource usage of the container at the current moment and generating corresponding GPU resource evaluation result data; determining whether the container needs data migration at the current moment; if so, identifying and capturing the incremental data layer generated during container runtime; pre-deploying the same base image layer on the target node and configuring the required GPU resource specifications; quickly migrating the captured incremental data layer to the target node; and starting a new container on the target node based on the base image layer and the migrated incremental data layer.

Description

Technical Field

[0001] This invention relates to the field of GPU resource allocation technology, and specifically to a method and system for dynamic allocation and cross-node migration of GPU resources based on a containerized environment. Background Technology

[0002] With the rapid development of cloud computing and artificial intelligence technologies, Docker containers have become the core deployment carrier for GPU-intensive tasks such as AI model training and high-performance computing due to their advantages such as lightweight, portability, and environment consistency.

[0003] However, GPU resource management in existing containerized environments still faces two key challenges:

[0004] First, resource allocation lacks dynamic adaptability and mostly adopts a static binding mode, which cannot adjust the GPU resource quota in real time according to the actual running load of the container (such as the complexity of computing tasks and data throughput), resulting in idle or overloaded resources and reducing the overall resource utilization of the cluster.

[0005] Secondly, cross-node migration of containers is inefficient. Traditional migration solutions require copying the complete container image and runtime data. Due to the large amount of data associated with GPU tasks and the bloated image layer, the migration process is time-consuming and prone to interrupting business operations, making it difficult to meet the requirements of high availability scenarios.

[0006] Therefore, there is an urgent need for a method and system for dynamic allocation and cross-node migration of GPU resources based on a containerized environment, which can realize dynamic allocation and cross-node migration of GPU resources, greatly improving resource utilization and data migration efficiency. Summary of the Invention

[0007] One of the objectives of this invention is to provide a method and system for dynamic allocation and cross-node migration of GPU resources based on a containerized environment, which can realize dynamic allocation and cross-node migration of GPU resources, greatly improving resource utilization and data migration efficiency.

[0008] To achieve the above objectives, a method for dynamic allocation and cross-node migration of GPU resources based on a containerized environment is provided, including the following steps:

[0009] S1. Based on the Docker container that needs to be detected, identify the container resource processing type corresponding to the Docker container, and retrieve the data collection dimension set associated with the Docker container resource processing type from the database based on the identified container resource processing type;

[0010] S2. Based on the retrieved data collection dimension set, monitor the container status corresponding to the Docker container in real time, and collect the dimension data corresponding to each dimension in the data collection dimension set.

[0011] S3. Based on the dimensional data corresponding to each dimension of the Docker container collected, and based on the preset container GPU resource evaluation strategy, evaluate the GPU resource usage of the Docker container at the current moment, and generate GPU resource evaluation result data corresponding to the Docker container.

[0012] S4. Based on the generated GPU resource evaluation results, determine whether the Docker container needs to perform data migration at the current moment;

[0013] S5. If so, then identify and capture the incremental data layer generated during the runtime of the Docker container; the Docker container contains an original image layer and an incremental data layer, the incremental data layer is used to store all data changes generated by users during the runtime of the Docker container, while the data in the original image layer remains unchanged;

[0014] S6. Pre-deploy the same Docker base image layer on the target node and configure the required GPU resource specifications. The target node refers to the destination server or compute node to which the container needs to be migrated.

[0015] S7. Quickly migrate the incremental data layer corresponding to the captured Docker container to the target node;

[0016] S8. Start a new Docker container on the target node based on the base image layer and the migrated incremental data layer.

[0017] The technical principles and effects of this solution are as follows: In this solution, Docker containers have significantly different GPU resource requirements due to different business scenarios (such as AI training, deep learning inference, graphics rendering, etc.). By parsing the container startup configuration and combining it with the predefined "resource type-collection dimension" mapping relationship in the database, the solution accurately locates the resource requirement characteristics of the current container, avoiding data redundancy caused by "indiscriminate collection," thereby enabling rapid determination of the dimensions that need to be monitored for a specific container.

[0018] Then, based on the determined data collection dimension set, the Docker container is monitored in real time for each dimension, and the corresponding data collection is completed.

[0019] After collecting data from various dimensions, and combining it with a pre-defined container GPU resource evaluation strategy, the GPU resource usage of the Docker container at the current moment is assessed, generating GPU resource evaluation result data for that Docker container. This evaluation result data allows for a rapid assessment of the Docker container's current running status. If data migration is needed, a response is immediately initiated, real-time identification and capture of incremental data layers generated during Docker container runtime, followed by the pre-setting of the same base image layer and configuring the corresponding GPU resource specifications on the target node. Finally, the incremental data layer is quickly migrated to the target node, enabling the rapid startup of new containers using the migrated incremental data layer and the pre-deployed base image layer.

[0020] Traditional container migration requires transferring the entire image file, containing a large number of fixed basic environments and dependent components. This process is time-consuming, bandwidth-intensive, and prone to causing prolonged business interruptions. This solution leverages the layered architecture of Docker to fundamentally improve migration efficiency. Because only the incremental data layer generated during container runtime is migrated, rather than the full image, the amount of data transferred during migration is significantly reduced, effectively lowering network bandwidth consumption and significantly shortening data transmission time. Simultaneously, the target node pre-deploys the same base image layer as the source node, eliminating the waiting time for image pulling and environment configuration. After migration, containers can be quickly rebuilt and restored to running state. This lightweight migration mode completely changes the drawbacks of traditional migrations—being time-consuming and having a significant impact—making container scheduling between nodes more flexible and efficient. It provides strong support for the dynamic optimization of cluster resources, enabling dynamic allocation and cross-node migration of GPU resources, greatly improving resource utilization and data migration efficiency.

[0021] Furthermore, the incremental data layer includes a high-frequency incremental layer and a low-frequency incremental layer. The high-frequency incremental layer is used to automatically store data whose data change frequency is greater than a preset frequency threshold by monitoring the data change frequency.

[0022] The low-frequency incremental layer is used to automatically store data whose data change frequency is less than or equal to a preset frequency threshold by monitoring the data change frequency.

[0023] Beneficial effects: By further subdividing the incremental data layer into a high-frequency incremental layer and a low-frequency incremental layer, differentiated storage and management can be achieved through the frequency of data changes. This brings multiple benefits in terms of container migration efficiency, resource utilization optimization, and business adaptability, effectively making up for the shortcomings of the traditional incremental data layer's "undifferentiated management".

[0024] Furthermore, the preset container GPU resource evaluation strategy includes:

[0025] The pre-trained container GPU resource evaluation model is retrieved from the database, and the dimensional data corresponding to each dimension of the Docker container is collected as input data and input into the pre-trained container GPU resource evaluation model. The GPU resource evaluation result data corresponding to the Docker container is output.

[0026] Furthermore, the training strategy corresponding to the pre-trained container GPU resource evaluation model is as follows:

[0027] Retrieve historical running data of the same type as the Docker container from the historical database to form a corresponding historical dataset. The historical running data includes historical dimension data corresponding to each dimension in the data collection dimension set.

[0028] Label the historical dimension data in the historical dataset to form a historical dataset with labeled content;

[0029] Construct a corresponding container GPU resource evaluation model;

[0030] Based on the constructed container GPU resource evaluation model, the hyperparameter set to be trained is determined, and several hyperparameter sets are randomly generated. The This is the m-th hyperparameter set;

[0031] Data from the historical dataset is used as input data and fed into each hyperparameter group. The corresponding container GPU resource evaluation model outputs the corresponding historical evaluation results data; among which, ;

[0032] Based on the historical evaluation results and corresponding annotations in the historical dataset, the accuracy of the evaluation results for each hyperparameter group's container GPU resource evaluation model is calculated, and hyperparameter groups with evaluation accuracy greater than a preset accuracy threshold are selected. As the hyperparameter set for the next training iteration, and The process continues until the current iteration count exceeds the preset iteration threshold. Then, the container GPU resource evaluation model corresponding to the hyperparameter group with the highest evaluation accuracy is selected as the trained model.

[0033] Beneficial effects: By selectively using historical data of the same type of container for training, the model can better fit the GPU resource usage characteristics of specific types of containers, reduce generalization error, and improve the matching degree between evaluation results and actual resource requirements.

[0034] By adopting an iterative optimization mechanism for hyperparameter sets, high-accuracy hyperparameter combinations are retained through multiple rounds of screening, enabling the model to adapt to the container resource evaluation requirements in different scenarios and avoiding the problem of insufficient scenario adaptation caused by fixed hyperparameters.

[0035] Furthermore, when selecting hyperparameter sets whose evaluation accuracy is greater than a preset accuracy threshold as the hyperparameter sets for the next training iteration, the selected hyperparameter sets are... Randomly determine the same hyperparameters that need to be replaced in all hyperparameter groups. and the corresponding parameter values; among which, , The parameter value corresponding to the k-th hyperparameter in the i-th hyperparameter group;

[0036] For each hyperparameter group, a random number A between 0 and 1 is randomly generated. When the random number A is greater than the preset random threshold, the hyperparameter group corresponding to the random number A is regarded as the mutation group. When the random number A is less than or equal to the preset random threshold, the hyperparameter group corresponding to the random number A is regarded as the undetermined group.

[0037] In the mutation group, the parameter values ​​of each hyperparameter group are randomly exchanged according to a preset first ratio; in the undetermined group, the parameter values ​​of each hyperparameter group are randomly exchanged according to a preset second ratio, wherein the preset first ratio is greater than the preset second ratio.

[0038] Beneficial effects: This allows for the random determination of hyperparameters that need to be replaced. This ensures that the parameter dimensions changed in each iteration are not fixed; on the other hand, by using "0-1 random number A grouping", the composition ratio of the mutated group and the undetermined group changes dynamically in each iteration (e.g., 60% of the mutated group in one iteration and 40% in another). This dual randomness breaks the limitations of fixed mutation rules, and the generated new hyperparameter groups cover more dimensions and more numerical combinations, avoiding the "path solidification" of parameter space exploration.

[0039] The present invention also provides a system for dynamic allocation and cross-node migration of GPU resources based on a containerized environment, using the above-described method for dynamic allocation and cross-node migration of GPU resources based on a containerized environment. Attached Figure Description

[0040] Figure 1 This is a flowchart of the method for dynamic allocation and cross-node migration of GPU resources based on a containerized environment in Embodiment 1 of the present invention. Detailed Implementation

[0041] The following detailed description illustrates the specific implementation method:

[0042] Example 1

[0043] The method for dynamic allocation and cross-node migration of GPU resources in a containerized environment is basically as follows: Figure 1 As shown, it includes the following steps:

[0044] S1. Based on the Docker container that needs to be detected, identify the container resource processing type corresponding to the Docker container, and retrieve the data collection dimension set associated with the Docker container resource processing type from the database based on the identified container resource processing type;

[0045] S2. Based on the retrieved data collection dimension set, monitor the container status corresponding to the Docker container in real time, and collect the dimension data corresponding to each dimension in the data collection dimension set.

[0046] S3. Based on the dimensional data corresponding to each dimension of the Docker container collected, and based on the preset container GPU resource evaluation strategy, evaluate the GPU resource usage of the Docker container at the current moment, and generate GPU resource evaluation result data corresponding to the Docker container.

[0047] The preset container GPU resource evaluation strategy includes:

[0048] The pre-trained container GPU resource evaluation model is retrieved from the database, and the dimensional data corresponding to each dimension of the Docker container is collected as input data and input into the pre-trained container GPU resource evaluation model. The GPU resource evaluation result data corresponding to the Docker container is output.

[0049] The training strategy corresponding to the pre-trained container GPU resource evaluation model is as follows:

[0050] Retrieve historical running data of the same type as the Docker container from the historical database to form a corresponding historical dataset. The historical running data includes historical dimension data corresponding to each dimension in the data collection dimension set.

[0051] Label the historical dimension data in the historical dataset to form a historical dataset with labeled content;

[0052] A corresponding container GPU resource evaluation model is constructed. In this embodiment, the container GPU resource evaluation model is constructed using an existing neural network model. Specifically, a three-layer BP neural network model is first constructed, including an input layer, hidden layers, and an output layer. BP neural networks typically use the sigmoid differentiable function and linear functions as the network's activation functions. This paper selects the sigmoid tangent function (tansig) as the activation function for the hidden layer neurons. The prediction model selects the sigmoid logarithmic function (tansig) as the activation function for the output layer neurons.

[0053] Based on the constructed container GPU resource evaluation model, determine the hyperparameter set to be trained, and randomly generate several hyperparameter sets.

[0054] The historical dataset is used as input data and fed into the container GPU resource evaluation model corresponding to each hyperparameter group, and the corresponding historical evaluation results are output.

[0055] Based on the historical evaluation results and corresponding annotations in the historical dataset, the accuracy of the evaluation results of the container GPU resource evaluation model corresponding to each hyperparameter group is calculated. The hyperparameter group with an evaluation result accuracy greater than a preset accuracy threshold is selected as the hyperparameter group for the next training iteration. This process continues until the current iteration number exceeds the preset iteration threshold. Then, the container GPU resource evaluation model corresponding to the hyperparameter group with the highest evaluation result accuracy is selected as the trained model.

[0056] When selecting hyperparameter sets whose evaluation accuracy is greater than a preset accuracy threshold as the hyperparameter sets for the next training iteration, the selected hyperparameter sets are used as the basis for the training process. Randomly determine the same hyperparameters that need to be replaced in all hyperparameter groups. and the corresponding parameter values; among which, , The parameter value corresponding to the k-th hyperparameter in the i-th hyperparameter group;

[0057] For each hyperparameter group, a random number A between 0 and 1 is randomly generated. When the random number A is greater than the preset random threshold, the hyperparameter group corresponding to the random number A is regarded as the mutation group. When the random number A is less than or equal to the preset random threshold, the hyperparameter group corresponding to the random number A is regarded as the undetermined group.

[0058] In this process, the hyperparameter values ​​of each hyperparameter group in the mutation group are randomly swapped according to a preset first ratio; the hyperparameter values ​​of each hyperparameter group in the undetermined group are randomly swapped according to a preset second ratio, where the preset first ratio is greater than the preset second ratio. For example, the hyperparameters to be trained in this case include the learning rate, number of iterations, number of hidden layer neurons, and momentum factor. Subsequently, five hyperparameter groups are randomly generated, namely: (0.05, 2000, 6, 0.5); (0.03, 3000, 8, 0.7); (0.08, 1500, 5, 0.3); (0.06, 2500, 7, 0.6); (0.04, 3500, 9, 0.4);

[0059] Historical data was input into the model corresponding to each hyperparameter group, and the evaluation accuracy was calculated. Assuming a preset accuracy threshold of 85%, the evaluation results are as follows: 88% (above the threshold); 92% (above the threshold); 82% (below the threshold, eliminated); 87% (above the threshold); 84% (below the threshold, eliminated); retained , , As the hyperparameter set for the next training iteration.

[0060] Then, the hyperparameters that need to be changed are randomly determined to be the learning rate and momentum factor (i.e., and ).

[0061] Generate random numbers for each retained hyperparameter set: A = 0.72; A = 0.35; A=0.81

[0062] Assuming the preset random threshold is 0.5, the variant group is: , The first ratio is used for parameter exchange; the undetermined group is... The second ratio is used for parameter exchange;

[0063] A new set of hyperparameters is generated after parameter swapping: : (0.06, 2000, 6, 0.6), and The learning rate and momentum factor were swapped; (0.03, 3000, 8, 0.6), only the momentum factor was exchanged; : (0.05, 2500, 7, 0.5), and The learning rate and momentum factor were swapped. The above steps were repeated until the number of iterations reached a preset threshold (e.g., 10 times). Finally, the model with the highest evaluation accuracy was selected as the trained container GPU resource evaluation model.

[0064] In this embodiment, the number of identical hyperparameters that need to be replaced is different in each iteration. As the number of iterations increases, the number of selected hyperparameters also decreases.

[0065] S4. Based on the generated GPU resource evaluation results, determine whether the Docker container needs to perform data migration at the current moment;

[0066] S5. If yes, then identify and capture the incremental data layer generated during the runtime of the Docker container; the Docker container contains an original image layer and an incremental data layer. The incremental data layer is used to store all data changes generated by users during the runtime of the Docker container, while the data in the original image layer remains unchanged; the incremental data layer includes a high-frequency incremental layer and a low-frequency incremental layer. The high-frequency incremental layer is used to automatically store data whose data change frequency is greater than a preset frequency threshold by monitoring the data change frequency.

[0067] The low-frequency incremental layer is used to automatically store data whose data change frequency is less than or equal to a preset frequency threshold by monitoring the data change frequency. In this embodiment, assuming that the data change frequency in the low-frequency incremental layer is less than the minimum threshold within a preset time period, then in subsequent time periods, when the subsequent time period is equal to half of the preset time period, the low-frequency incremental layer is divided into an original mirror layer.

[0068] S6. Pre-deploy the same Docker base image layer on the target node and configure the required GPU resource specifications; the target node refers to the destination server or compute node to which the container needs to be migrated, relative to the "source node" where the current container is located. The selection strategy includes:

[0069] Resource matching: The GPU specifications of the target node (such as memory capacity and computing power level) must meet the requirements for container migration;

[0070] Network topology: Prioritize nodes within the same switch or rack to reduce migration latency;

[0071] Load balancing: Select nodes with lower current load to avoid resource contention after migration.

[0072] S7. Quickly migrate the incremental data layer corresponding to the captured Docker container to the target node;

[0073] S8. Start a new Docker container on the target node based on the base image layer and the migrated incremental data layer.

[0074] This embodiment also discloses a GPU resource dynamic allocation and cross-node migration system based on a containerized environment, using the above-described GPU resource dynamic allocation and cross-node migration method based on a containerized environment.

[0075] Example 2

[0076] Compared with Embodiment 1, the difference in this embodiment is that the preset random threshold is dynamically adjustable, and the specific adjustment strategy is as follows:

[0077] Obtain the current iteration number and the selected hyperparameter sets. The number of iterations and the number of iterations are normalized. Based on the normalized number of iterations and the number of iterations, the preset random threshold corresponding to the current time is calculated. The units of the normalized number of iterations and the number of iterations are removed.

[0078] The formula for calculating the preset random threshold is:

[0079]

[0080] In the formula, The first preset random threshold, The second preset random threshold, The number of each selected hyperparameter group. This represents the current iteration number. This represents the total number of iterations. The adjustment coefficient (k) controls the rate at which the random threshold changes with the number of iterations. A larger k value results in a slower threshold decrease and a higher proportion of mutated groups. The specific value of the adjustment coefficient is determined based on the size of the training dataset (e.g., k=2.0 for large datasets and k=1.8 for small datasets).

[0081] In the early stages of iteration, When the threshold is close to 1, it is at a relatively high level. At this point, the probability of random number A≤T is higher, and more hyperparameters are formed into "undetermined groups". These undetermined groups can be further screened based on existing optimization experience (such as retaining combinations with better historical performance), reducing invalid exploration and achieving "utilization as the main approach and exploration as a supplement", avoiding the waste of computing resources due to blind mutation in the early stage.

[0082] In the later stages of iteration, the probability of random number A > T increases significantly, and more hyperparameters are combined into "mutation groups". By introducing new mutation combinations, the constraints of local optima in the early stage are broken, and the principle of "exploration as the main approach and utilization as a supplement" is strengthened. This avoids the algorithm from getting stuck in local optima and increases the probability of discovering the global optimal hyperparameters.

[0083] The above descriptions are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, based on the guidance provided in this application, improve and implement this solution in combination with their own capabilities. Some typical well-known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A method for dynamic allocation and cross-node migration of GPU resources based on a containerized environment, characterized by: Includes the following steps: S1. Based on the Docker container that needs to be detected, identify the container resource processing type corresponding to the Docker container, and retrieve the data collection dimension set associated with the Docker container resource processing type from the database based on the identified container resource processing type; S2. Based on the retrieved data collection dimension set, monitor the container status corresponding to the Docker container in real time, and collect the dimension data corresponding to each dimension in the data collection dimension set. S3. Based on the dimensional data corresponding to each dimension of the Docker container collected, and based on the preset container GPU resource evaluation strategy, evaluate the GPU resource usage of the Docker container at the current moment, and generate GPU resource evaluation result data corresponding to the Docker container. The preset container GPU resource evaluation strategy includes: Retrieve a pre-trained container GPU resource evaluation model from the database, and input the dimensional data corresponding to each dimension of the Docker container as input data into the pre-trained container GPU resource evaluation model, and output the GPU resource evaluation result data corresponding to the Docker container. The training strategy corresponding to the pre-trained container GPU resource evaluation model is as follows: Retrieve historical running data of the same type as the Docker container from the historical database to form a corresponding historical dataset. The historical running data includes historical dimension data corresponding to each dimension in the data collection dimension set. Label the historical dimension data in the historical dataset to form a historical dataset with labeled content; Construct a corresponding container GPU resource evaluation model; Based on the constructed container GPU resource evaluation model, the hyperparameter set to be trained is determined, and several hyperparameter sets are randomly generated. The This is the m-th hyperparameter set; Data from the historical dataset is used as input data and fed into each hyperparameter group. The corresponding container GPU resource evaluation model outputs the corresponding historical evaluation results data; among which, ; Based on the historical evaluation results and corresponding annotations in the historical dataset, the accuracy of the evaluation results for each hyperparameter group's container GPU resource evaluation model is calculated, and hyperparameter groups with evaluation accuracy greater than a preset accuracy threshold are selected. As the hyperparameter set for the next training iteration, and The process continues until the current iteration count exceeds the preset iteration threshold. Then, the container GPU resource evaluation model corresponding to the hyperparameter group with the highest evaluation accuracy is selected as the trained model. When selecting hyperparameter sets whose evaluation accuracy is greater than a preset accuracy threshold as the hyperparameter sets for the next training iteration, the selected hyperparameter sets are used as the basis for the training process. Randomly determine the same hyperparameters that need to be replaced in all hyperparameter groups. and the corresponding parameter values; among which, , The parameter value corresponding to the k-th hyperparameter in the i-th hyperparameter group; For each hyperparameter group, a random number A between 0 and 1 is randomly generated. When the random number A is greater than the preset random threshold, the hyperparameter group corresponding to the random number A is regarded as the mutation group. When the random number A is less than or equal to the preset random threshold, the hyperparameter group corresponding to the random number A is regarded as the undetermined group. In the mutation group, the parameter values ​​of each hyperparameter group are randomly exchanged according to a preset first ratio; in the undetermined group, the parameter values ​​of each hyperparameter group are randomly exchanged according to a preset second ratio, and the preset first ratio is greater than the preset second ratio. S4. Based on the generated GPU resource evaluation results, determine whether the Docker container needs to perform data migration at the current moment; S5. If so, then identify and capture the incremental data layer generated during the runtime of the Docker container; the Docker container contains an original image layer and an incremental data layer, the incremental data layer is used to store all data changes generated by users during the runtime of the Docker container, while the data in the original image layer remains unchanged; S6. Pre-deploy the same Docker base image layer on the target node and configure the required GPU resource specifications. The target node refers to the destination server or compute node to which the container needs to be migrated. S7. Quickly migrate the incremental data layer corresponding to the captured Docker container to the target node; S8. Start a new Docker container on the target node based on the base image layer and the migrated incremental data layer.

2. The method for dynamic allocation and cross-node migration of GPU resources based on a containerized environment according to claim 1, characterized in that: The incremental data layer includes a high-frequency incremental layer and a low-frequency incremental layer. The high-frequency incremental layer is used to automatically store data whose data change frequency is greater than a preset frequency threshold by monitoring the data change frequency. The low-frequency incremental layer is used to automatically store data whose data change frequency is less than or equal to a preset frequency threshold by monitoring the data change frequency.

3. A system for dynamic allocation and cross-node migration of GPU resources based on a containerized environment, characterized in that: The method for dynamic allocation and cross-node migration of GPU resources based on a containerized environment, according to any one of claims 1 to 2 above.

Images