Resource scheduling method, device, equipment, medium and product

Abstract

The invention relates to a resource scheduling method and device, equipment, a medium and a product, and the method comprises the steps: obtaining driver compatible information on a server in response to a computing power scheduling request, the driver compatible information comprising at least one piece of information of state information, GPU driver version information, CUDA version information and GPU card identification of each GPU in the server; and determining a driving environment of the computing power scheduling request according to the driving compatibility information, and executing a computing power scheduling task corresponding to the computing power scheduling request in the driving environment. According to the method, by obtaining the driver compatible information with the single GPU card as the granularity, matching of the computing power resources and the driver dependency relationship is achieved, the completely compatible isolated driving environment can be constructed or selected according to the information, and therefore it is ensured that the computing power scheduling request can be processed on the basis of the needed exact driving version, the problem of computing power fragmentation is solved, and the computing power scheduling efficiency is improved. And the GPUs of different drive versions in the server can be efficiently utilized.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing technology, and more specifically, to a resource scheduling method, apparatus, device, medium, and product. Background Technology

[0002] In AI inference scenarios, model optimization results (such as the TensorRT engine) are strongly bound to specific versions of GPU drivers and CUDA environments, which restricts the deployment of models across environments.

[0003] In related technologies, a "unified driver" strategy is used to manage GPU resources at the server-wide level, which fails to recognize the differences in driver versions between different GPU cards within the server. When a model is only compatible with a subset of GPUs, the system can only exclude that server entirely, resulting in fragmentation of computing power and decreased resource utilization. Summary of the Invention

[0004] The purpose of this disclosure is to provide a resource scheduling method, apparatus, equipment, medium, and product.

[0005] To achieve the above objectives, in a first aspect, this disclosure provides a resource scheduling method, the method comprising: In response to a computing power scheduling request, driver compatibility information is obtained from the server. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier. Based on the driver compatibility information, the driver environment for the computing power scheduling request is determined, and the computing power scheduling task corresponding to the computing power scheduling request is executed in the driver environment.

[0006] Optionally, determining the driver environment for the computing power scheduling request based on the driver compatibility information includes: Based on the computing power scheduling request, determine the GPU driver version information corresponding to the computing power scheduling request from the driver compatibility information; If a compatible driver environment matching the GPU driver version information exists on the server, the compatible driver environment is determined as the driver environment for the computing power scheduling request. The compatible driver environment is a driver environment established based on historical computing power scheduling requests, and the driver environment of the historical computing power scheduling requests matches the driver environment of the computing power scheduling request. If no compatible driver environment matching the driver version information exists on the server, a driver environment is loaded based on the GPU driver version information, and the established driver environment is determined as the driver environment for the computing power scheduling request.

[0007] Optionally, if no compatible driver environment matching the driver version information exists on the server, loading the driver environment based on the driver version information includes: If no compatible driver environment matching the driver version information exists on the server, a virtual machine is created based on the virtual machine information matching the GPU driver version information. The GPU driver version information is loaded into the virtual machine to obtain the driver environment.

[0008] Optionally, the status information includes working status and idle status, and before creating the virtual machine based on the virtual machine information matching the GPU driver version information, it includes: Based on the driver compatibility information, determine whether there is an idle GPU in the server; The step of creating a virtual machine based on virtual machine information matching the GPU driver version information includes: If an idle GPU exists on the server, a virtual machine is created based on the GPU driver version information that matches the virtual machine information.

[0009] Optionally, loading the GPU driver version information into the virtual machine to obtain the driver environment includes: Identify the target GPU from the idle GPUs on the server; The target GPU is bound to the virtual machine, and the GPU driver version information is loaded into the bound virtual machine to obtain the driver environment.

[0010] Optionally, after determining the driver environment for the computing power scheduling request based on the driver compatibility information and executing the computing power scheduling task corresponding to the computing power scheduling request in the driver environment, the method further includes: Based on the GPU bound to the virtual machine, update the status information of the GPU in the driver compatibility information to the working status; Establish a correspondence between the computing power scheduling request and the driving environment, and record the correspondence in the driving compatibility information.

[0011] Secondly, this disclosure provides a resource scheduling apparatus, the apparatus comprising: The information acquisition module is configured to acquire driver compatibility information on the server in response to a computing power scheduling request. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier. The computing power scheduling module is configured to determine the driver environment of the computing power scheduling request based on the driver compatibility information, and execute the computing power scheduling task corresponding to the computing power scheduling request in the driver environment.

[0012] Thirdly, this disclosure provides a server, including: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method of any one of the first aspects.

[0013] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0014] Fifthly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects, or the steps of the method described in any one of the second aspects.

[0015] By using the above technical solution, driver compatibility information at the single GPU card granularity is accurately obtained, and intelligent matching of computing resources and driver dependencies is achieved. Then, based on this information, a fully compatible isolated driver environment can be dynamically built or selected, thereby ensuring that computing scheduling requests can be processed based on the exact driver version required. This solves the problem of computing fragmentation and further enables GPUs with different driver versions within the server to be used efficiently at the same time, significantly improving resource utilization, deployment success rate and overall system flexibility.

[0016] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings: Figure 1 A timing diagram of resource scheduling processing in a related technology is shown.

[0018] Figure 2 This is a flowchart illustrating a resource scheduling method on a client according to an exemplary embodiment.

[0019] Figure 3 This is a flowchart illustrating a resource scheduling method on a client according to another exemplary embodiment.

[0020] Figure 4The processing timing diagram of the resource scheduling method provided in the embodiments of this application is shown.

[0021] Figure 5 This is a block diagram of a resource scheduling device according to an exemplary embodiment.

[0022] Figure 6 This is a block diagram illustrating a server according to an exemplary embodiment. Detailed Implementation

[0023] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0024] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device.

[0025] For related technologies, please refer to Figure 1 , Figure 1 A sequence diagram of resource scheduling in a related technology is shown. In this sequence diagram, the server interface Client sends a computing power scheduling request to the scheduler through the API gateway, requesting the server to allocate computing power resources for the model or task corresponding to the interface. After receiving the request, the scheduler queries the host layer to check whether the driver version corresponding to the computing power scheduling request is compatible with the host layer's driver environment. If they do not match, an error message is sent back to the interface to indicate that the driver is incompatible and the driver environment cannot be started. If they are compatible, the driver environment is started and the corresponding computing power resources are allocated, enabling the model or task to run, perform inference services, and return the inference results to the interface. This creates a strong correlation between the server and the driver version, which makes the system lack flexibility when facing diverse driver environments. Once the driver version is updated or changed, it may lead to service unavailability.

[0026] To address the technical problems mentioned in the background and the aforementioned technical issues, this application provides a resource scheduling method. Figure 2 This is a flowchart illustrating a resource scheduling method according to an exemplary embodiment, the method comprising the following steps.

[0027] In step S11, in response to the computing power scheduling request, driver compatibility information on the server is obtained. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier.

[0028] In this context, a computing power scheduling request refers to a task request initiated by a client to a server to request the use of its computing resources. This request may include information such as the type, quantity, and duration of the required computing resources. In this embodiment, the computing power scheduling request can be a model inference request or a request triggered in response to a load increase event on the server.

[0029] Driver compatibility information is used to determine whether the server's hardware and software environment meets the requirements for running the local model. The form of driver compatibility information can be key-value pairs, graphs, or other formats; no specific limitation is made here.

[0030] Furthermore, driver compatibility information includes, but is not limited to, the status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier. GPU status information includes the GPU's usage status (working or idle), GPU utilization, idle time slices, and current load. GPU driver version information refers to the version number of the GPU driver currently installed on the server. CUDA version information includes the runtime library version compatible with the driver and the supported computing power level. The GPU card identifier is used to uniquely identify the model and serial number of each GPU device in the server.

[0031] For example, when driver compatibility information is represented in graph form, it can include nodes, edges, and attributes. Nodes include information such as GPU driver version, CUDA version, model inference acceleration results, and GPU card identifier (CardID). Edges represent "compatible," "conflicting," or "substitutable" relationships. Attributes include driver version number, health status, reset success rate, loading time, performance rating, and the number of GPUs the model can run on. Furthermore, based on driver compatibility information, version differences between different GPUs on the same server can be identified, thereby enabling finer-grained allocation of computing power.

[0032] In step S12, the driver environment for the computing power scheduling request is determined based on the driver compatibility information, and the computing power scheduling task corresponding to the computing power scheduling request is executed in the driver environment.

[0033] The driver environment refers to the set of software and hardware configurations required to run the local model, including the compatible GPU driver version, CUDA runtime library, and corresponding computing power support. The driver environment can be a virtual machine environment or a containerized environment. When the driver environment is a virtual machine environment, an isolated runtime space can be built within the virtual machine, loading the driver version and dependent libraries matching the target model, and dynamically allocating and scheduling hardware resources through the Hypervisor layer. When the driver environment is a containerized environment, a driver environment compatible with the target model is pre-configured through an image, and rapid deployment and isolation of the environment are achieved using orchestration systems such as Kubernetes. When executing a computing power scheduling request, the scheduler selects available devices that meet the conditions based on the GPU card identifier and version dependency relationship in the driver compatibility information, and dynamically loads the corresponding CUDA runtime library instance. If multiple instances are shared, the driver version conflict status between containers is further verified to ensure no compatibility faults. After the task starts, the GPU driver health and loading time are monitored in real time. Once an anomaly is detected, an environment reset or task migration mechanism is triggered to ensure the stability of the inference service.

[0034] In this embodiment, determining the driver environment for a computing power scheduling request based on driver compatibility information can improve the accuracy of computing power resource matching and reduce the task failure rate caused by driver incompatibility. Furthermore, when the computing power scheduling task corresponding to the computing power scheduling request is executed in the driver environment, it can dynamically adapt to the optimal GPU resource combination, improving resource utilization efficiency and task execution reliability.

[0035] In the solution provided in this application embodiment, by accurately obtaining driver compatibility information at the granularity of a single GPU card, intelligent matching of computing resources and driver dependencies is achieved. Then, based on this information, a fully compatible isolated driver environment can be dynamically constructed or selected, thereby ensuring that computing scheduling requests can be processed based on the exact driver version required, solving the problem of computing fragmentation, and further enabling GPUs with different driver versions within the server to be utilized simultaneously and efficiently, significantly improving resource utilization, deployment success rate, and overall system flexibility.

[0036] Figure 3 This is a flowchart illustrating a resource scheduling method according to another exemplary embodiment, the method comprising the following steps.

[0037] In step S21, in response to the computing power scheduling request, driver compatibility information on the server is obtained. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier.

[0038] For a detailed explanation of step S21, please refer to the detailed explanation of step S11, which will not be repeated here.

[0039] In step S21, the GPU driver version information corresponding to the computing power scheduling request is determined from the driver compatibility information based on the computing power scheduling request.

[0040] In step S22, if a compatible driver environment matching the GPU driver version information exists on the server, the compatible driver environment is determined as the driver environment for the computing power scheduling request. The compatible driver environment is a driver environment established based on historical computing power scheduling requests, and the driver environment of the historical computing power scheduling requests matches the driver environment of the computing power scheduling request.

[0041] The compatible driver environment refers to a runtime environment that matches the GPU driver version information in the current computing power scheduling request and has passed compatibility verification. This compatible driver environment can be a driver environment built based on historical computing power scheduling requests, where the driver environment of the historical requests matches the driver environment of the current computing power scheduling request, thereby enabling rapid reuse and deployment. This eliminates the need for repeated build processes, significantly shortening environment preparation time.

[0042] In step S23, if there is no compatible driver environment matching the driver version information on the server, a driver environment is loaded based on the GPU driver version information, and the established driver environment is determined as the driver environment for the computing power scheduling request.

[0043] If a compatible driver environment does not exist on the server, a driver environment corresponding to the GPU driver version information is dynamically created. This can be achieved by creating a virtual machine to build an isolated runtime environment for the GPU driver version information, ensuring dependency consistency during task execution. Alternatively, a pre-built driver image can be pulled from an image repository and a container instance can be started, enabling environment build and release in seconds.

[0044] Understandably, after creating the driver environment, a mapping between the GPU driver version information and that driver environment is established to facilitate quick retrieval and reuse during subsequent scheduling. This mapping can be stored in a distributed configuration center or a local cache, supporting low-latency queries under high concurrency. Simultaneously, the system periodically cleans up driver environments that have not been used for a long time, releasing underlying resources and improving overall resource utilization.

[0045] In some implementations, when no compatible driver environment matching the driver version information exists on the server, loading the driver environment based on the driver version information includes: creating a virtual machine based on virtual machine information matching the GPU driver version information when no compatible driver environment matching the driver version information exists on the server; loading the GPU driver version information into the virtual machine to obtain the driver environment.

[0046] The virtual machine information includes, but is not limited to, the virtual machine's configuration parameters, GPU driver version, operating system type and version, network configuration, and storage path.

[0047] In this embodiment, the server includes virtual machine templates with different driver versions. The corresponding virtual machine template can be selected based on the GPU driver version information in the request, quickly creating a matching virtual machine instance and automatically injecting the required driver configuration. The template pre-configures the operating system, CUDA runtime, and the corresponding GPU driver version, ensuring environment consistency and startup efficiency. The GPU driver version information is loaded into the virtual machine to complete the initial configuration of the driver environment, and GPU resources are dynamically allocated to the virtual machine instance through the virtualization layer.

[0048] In other embodiments, the status information includes both a working state and an idle state. Before creating the virtual machine based on the virtual machine information matching the GPU driver version information, the process includes: determining whether there is an idle GPU in the server based on the driver compatibility information. Creating the virtual machine based on the virtual machine information matching the GPU driver version information includes: if there is an idle GPU in the server, then creating the virtual machine based on the virtual machine information matching the GPU driver version information.

[0049] In this implementation, before creating a virtual machine, the real-time status of the GPUs on the server is checked. If idle and compatible GPU resources exist, a virtual machine instance is directly allocated and started to avoid resource contention. Otherwise, the server waits for a non-idle GPU to complete its current processing task, and then determines whether a virtual machine instance can be created based on the GPU's information. If it is determined that a virtual machine instance can be created on that GPU, then the virtual machine instance can be created.

[0050] In some specific implementations, loading the GPU driver version information into the virtual machine to obtain the driver environment includes: determining a target GPU from the idle GPUs on the server; binding the target GPU to the virtual machine; and loading the GPU driver version information into the bound virtual machine to obtain the driver environment.

[0051] In this implementation, the target GPU is dynamically bound to the virtual machine instance through a passthrough method, enabling exclusive access to GPU resources and ensuring that the driver environment is fully compatible with the underlying hardware.

[0052] Specifically, passthrough methods can be VFIO or PCI passthrough technology, which binds the target GPU card to the corresponding virtual machine one-to-one, ensuring that the virtual machine has exclusive control over the GPU and avoiding driver conflicts and resource contention. Device address isolation is achieved through IOMMU to ensure memory access security.

[0053] In some specific embodiments, after determining the driver environment of the computing power scheduling request based on the driver compatibility information and executing the computing power scheduling task corresponding to the computing power scheduling request in the driver environment, the method further includes: updating the status information of the GPU in the driver compatibility information to a working state based on the GPU bound to the virtual machine; establishing a correspondence between the computing power scheduling request and the driver environment; and recording this correspondence in the driver compatibility information.

[0054] In this implementation, when the virtual machine and GPU are bound together, the GPU's status in the driver compatibility information is updated to working status, and the mapping relationship between the computing power scheduling request and the driver environment is recorded simultaneously, ensuring resource traceability and status monitoring during task execution. Furthermore, after establishing the correspondence between the computing power scheduling request and the driver environment, the recorded driver environment configuration can be directly reused when the same computing power scheduling request is encountered subsequently, eliminating the need for repeated matching and verification, significantly improving scheduling efficiency. When the computing power scheduling task is completed, the GPU's status information is updated from working status to idle status, and the binding relationship with the original virtual machine is released, freeing up GPU resources for subsequent scheduling. Simultaneously, the corresponding computing power scheduling request record in the driver compatibility information is cleared, ensuring status consistency and resource traceability.

[0055] In the solution provided in this application embodiment, by intelligently reusing historical driver environments, when a matching compatible driver environment already exists on the server, the environment can be immediately invoked to meet new computing power requests, thereby significantly shortening the environment preparation time and significantly improving scheduling efficiency. When no existing environment exists, the system will dynamically load and build a new driver environment according to the requested driver version information, ensuring the flexibility of the scheduling strategy and its broad adaptability to different driver requirements. While ensuring the smooth execution of computing power tasks, it effectively avoids scheduling failures caused by driver incompatibility and reduces the overhead of repeatedly building the same driver environment, achieving an optimal balance between efficiency and resource utilization.

[0056] For specific implementation details, please refer to [link / reference]. Figure 4 , Figure 4This diagram illustrates the processing timing of the resource scheduling method provided in an embodiment of this application. Driver compatibility information is used as an example of a driver image. Figure 4 As shown, the timing sequence of the resource scheduling method includes: After receiving a computing power scheduling request from the interface Client, the request is forwarded to the scheduler through the API gateway. The scheduler parses the computing power scheduling request to obtain the driver version information that the request depends on. Based on the driver version information corresponding to the request, the scheduler queries the driver graph to determine the set of compatible GPUs and their version information that match the driver version information, further determining whether a compatible driver environment exists. If a compatible driver environment already exists, it is directly reused, and the corresponding GPU resources are allocated. The computing power scheduling request is bound to the corresponding virtual machine, and the task execution is started. Simultaneously, the status of the GPU in the driver graph is updated to working status, and the mapping relationship between the computing power scheduling request and the driver environment is recorded. If a compatible driver environment does not exist, the driver environment construction process is triggered. The scheduler retrieves a virtual machine template matching the driver version from the driver template pool, then creates a virtual machine instance based on that template. Idle GPUs are directly connected to this virtual machine instance via VFIO / IOMMU, completing the binding between the GPU and the virtual machine. The target driver and CUDA environment corresponding to the driver version are loaded into the bound virtual machine. After initializing and verifying the driver environment, the corresponding task is executed on the virtual machine. During task execution, the GPU's status is updated to working, and the mapping relationship between the computing power scheduling request and the constructed driver environment is recorded in the driver graph, ensuring that subsequent identical requests can directly call the existing environment. After the task is completed, the GPU status is synchronously updated to idle, the virtual machine binding is released, resources are released, and the corresponding records are cleaned up, ensuring system state consistency and efficient resource recycling. The entire scheduling process is managed globally through the driver graph, ensuring that every resource allocation and reclamation is traceable and that every state change is consistent. Through the mapping record between computing power requests and driver environments, the system can quickly respond and accurately match existing resources when facing high-frequency, repetitive scheduling demands, avoiding resource waste and time overhead caused by repeated construction. Meanwhile, the standardized design of the driving template pool makes the new environment construction process efficient and controllable, further improving the overall scheduling reliability and maintainability.

[0057] For example, consider the inference acceleration optimization of model A using a computing power scheduling request. Model A's inference acceleration optimization relies on GPU driver version 525.x and CUDA 12.0, thus generating a specific version of the inference engine file. On server S1, the currently installed system driver version is 535.x. Server S1 has four GPU cards: GPU0, GPU1, GPU2, and GPU3. GPU0 and GPU1 are running driver 535.x and used for other inference tasks, while GPU2 and GPU3 are idle. At this time, based on driver compatibility information, it is determined that GPU2 and GPU3 are currently idle and physically capable of loading different driver environments. Upon receiving a request from model A, the metadata of model A is first parsed to confirm that model A depends on driver version 525.x and CUDA 12.0, and it is determined that a new driver environment can be created on GPU2 and GPU3. The scheduler selects a virtual machine template corresponding to the driver version, clones a new virtualization instance on the host machine using a templated fast-start mechanism, and binds GPU2 and GPU3 to this virtual machine using VFIO passthrough technology. Inside the virtual machine, the 525.x version driver and CUDA 12.0 runtime environment are automatically loaded, forming a runtime space independent of the host system. After the driver is loaded, the inference container instance of model A is started in this virtual machine, achieving execution conditions completely consistent with the inference engine file dependency environment.

[0058] At this point, GPU0 / 1 running driver 535.x and GPU2 / 3 running driver 525.x coexist on server S1 without interfering with each other. Model A's inference service runs normally on GPU2 / 3, while other models continue to use GPU0 / 1 to execute tasks. The server as a whole is in a multi-driver coexistence state. This parallel operation significantly improves resource utilization. The scheduling system records this configuration in the driver compatibility information database, forming a reusable mapping relationship. Subsequent identical requests can directly call the record, skipping the matching and verification steps, achieving minute-level deployment. When the task ends, GPU2 / 3's status is synchronously updated to idle, the virtual machine binding is released, and driver environment information is cleared according to policy, ensuring resource traceability and consistency. Furthermore, the ability to run different driver versions simultaneously on the same computing server effectively releases GPU computing resources that were previously unusable due to version limitations, significantly improving server resource utilization and task scheduling flexibility.

[0059] Furthermore, let's take the inference acceleration request of Model B as an example. Model B's inference acceleration is generated in a driver version 525.x and CUDA 11.8 environment. During normal operation, Model B is mainly deployed on server nodes with driver version 525.x, using GPU0 and GPU1 on the server to handle inference requests. When a rapid increase in Model B's request volume is detected within a short period, the scheduler, upon receiving a scaling request, immediately queries driver compatibility information and analyzes the global GPU resource status. If it identifies that GPU2 and GPU3 on server S2 are idle and not occupied by any tasks, and the driver compatibility information indicates that the physical conditions of GPU2 and GPU3 allow loading the 525.x version driver, the scheduler will quickly launch two new virtualization instances on server S2 using a template, loading the driver version and CUDA environment required by Model B, and directly connecting GPU2 and GPU3 to the corresponding virtual machines. This template-based rapid launch mechanism completes environment construction based on the system's pre-built 525.x driver template. After the virtual machine starts, it automatically loads the CUDA 11.8 runtime and inference service dependency libraries. The entire startup and driver initialization process takes only a few seconds. Subsequently, the scheduler deploys the new inference replica of Model B to the virtual machine and registers it in the inference load pool. After the new environment loads, the traffic scheduling module automatically forwards some requests to the new replica to share the load pressure on the primary instance. In this way, the new replica immediately participates in the service, relieving the pressure on the original node and achieving dynamic scaling. The entire process requires no manual intervention, and because it is deployed based on a verified driver template, it avoids the risk of anomalies caused by environment inconsistencies. After completing scheduling, the system automatically updates resource status and mapping records, enhancing the efficiency of subsequent decision-making. This not only shortens response time but also makes computing power supply closer to actual demand fluctuations, reflecting a scheduling philosophy that emphasizes both elasticity and intelligence.

[0060] Figure 5 This is a block diagram of a resource scheduling device according to an exemplary embodiment. Figure 5 The resource scheduling device 300 includes an information acquisition module 310 and a computing power scheduling module 320.

[0061] The information acquisition module 310 is configured to acquire driver compatibility information on the server in response to a computing power scheduling request. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier. The computing power scheduling module 320 is configured to determine the driver environment of the computing power scheduling request based on the driver compatibility information, and execute the computing power scheduling task corresponding to the computing power scheduling request in the driver environment.

[0062] Optionally, the computing power scheduling module 320 is further configured to: determine the GPU driver version information corresponding to the computing power scheduling request from the driver compatibility information based on the computing power scheduling request; if a compatible driver environment matching the GPU driver version information exists on the server, determine the compatible driver environment as the driver environment of the computing power scheduling request, wherein the compatible driver environment is a driver environment established based on historical computing power scheduling requests, and the driver environment of the historical computing power scheduling requests matches the driver environment of the computing power scheduling request; if no compatible driver environment matching the driver version information exists on the server, load a driver environment based on the GPU driver version information, and determine the established driver environment as the driver environment of the computing power scheduling request.

[0063] Optionally, the computing power scheduling module 320 is further configured to, in the event that there is no compatible driver environment matching the driver version information on the server, create a virtual machine based on virtual machine information matching the GPU driver version information; load the GPU driver version information into the virtual machine to obtain the driver environment.

[0064] Optionally, the computing power scheduling module 320 is further configured to determine whether there is an idle GPU in the server based on the driver compatibility information; if there is an idle GPU in the server, a virtual machine is created based on the virtual machine information that matches the GPU driver version information.

[0065] Optionally, the computing power scheduling module 320 is further configured to determine a target GPU from the GPUs that are in an idle state on the server; bind the target GPU to the virtual machine; and load the GPU driver version information into the bound virtual machine to obtain the driver environment.

[0066] Optionally, the computing power scheduling module 320 is further configured to update the status information of the GPU in the driver compatibility information to a working state based on the GPU bound to the virtual machine; establish a correspondence between the computing power scheduling request and the driver environment; and record the correspondence in the driver compatibility information.

[0067] Figure 6 This is a block diagram illustrating a server 400 according to an exemplary embodiment. For example... Figure 6 As shown, the server 400 may include a processor 401 and a memory 402. The server 400 may also include one or more of a multimedia component 403, an input / output (I / O) interface 404, and a communication component 405.

[0068] The processor 401 controls the overall operation of the server 400 to complete all or part of the steps in the resource scheduling method described above. The memory 402 stores various types of data to support the operation of the server 400. This data may include, for example, instructions for any application or method operating on the server 400, and application-related data such as contact data, sent and received messages, images, audio, video, etc. The memory 402 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, disk, or optical disk. The multimedia component 403 may include a screen and audio components. The screen may be, for example, a touchscreen, and the audio component is used for outputting and / or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 402 or transmitted via communication component 405. The audio component also includes at least one speaker for outputting audio signals. I / O interface 404 provides an interface between processor 401 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 405 is used for wired or wireless communication between server 400 and other devices. Wireless communication may include Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination of these. Therefore, the corresponding communication component 405 may include a Wi-Fi module, a Bluetooth module, or an NFC module.

[0069] In an exemplary embodiment, server 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the resource scheduling method described above.

[0070] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the resource scheduling method described above. For example, the computer-readable storage medium may be the memory 402 including program instructions described above, which may be executed by the processor 401 of the server 400 to complete the resource scheduling method described above.

[0071] In another exemplary embodiment, a computer program product is also provided, which includes a computer program executable by a processor, wherein the computer program, when executed by the processor, implements the steps of the resource scheduling method described above.

[0072] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0073] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0074] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A resource scheduling method, characterized in that, The method includes: In response to a computing power scheduling request, driver compatibility information is obtained from the server. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier. Based on the driver compatibility information, the driver environment for the computing power scheduling request is determined, and the computing power scheduling task corresponding to the computing power scheduling request is executed in the driver environment.

2. The resource scheduling method according to claim 1, characterized in that, Determining the driver environment for the computing power scheduling request based on the driver compatibility information includes: Based on the computing power scheduling request, determine the GPU driver version information corresponding to the computing power scheduling request from the driver compatibility information; If a compatible driver environment matching the GPU driver version information exists on the server, the compatible driver environment is determined as the driver environment for the computing power scheduling request. The compatible driver environment is a driver environment established based on historical computing power scheduling requests, and the driver environment of the historical computing power scheduling requests matches the driver environment of the computing power scheduling request. If no compatible driver environment matching the driver version information exists on the server, a driver environment is loaded based on the GPU driver version information, and the established driver environment is determined as the driver environment for the computing power scheduling request.

3. The resource scheduling method according to claim 2, characterized in that, In the case that no compatible driver environment matching the driver version information exists on the server, loading the driver environment based on the driver version information includes: If no compatible driver environment matching the driver version information exists on the server, a virtual machine is created based on the virtual machine information matching the GPU driver version information. The GPU driver version information is loaded into the virtual machine to obtain the driver environment.

4. The resource scheduling method according to claim 3, characterized in that, The status information includes working status and idle status, and before creating the virtual machine based on the virtual machine information matching the GPU driver version information, it includes: Based on the driver compatibility information, determine whether there is an idle GPU in the server; The step of creating a virtual machine based on virtual machine information matching the GPU driver version information includes: If an idle GPU exists on the server, a virtual machine is created if the GPU driver version information matches the virtual machine information.

5. The resource scheduling method according to claim 4, characterized in that, The step of loading the GPU driver version information into the virtual machine to obtain the driver environment includes: Identify the target GPU from the idle GPUs on the server; The target GPU is bound to the virtual machine, and the GPU driver version information is loaded into the bound virtual machine to obtain the driver environment.

6. The resource scheduling method according to claim 5, characterized in that, After determining the driver environment for the computing power scheduling request based on the driver compatibility information, and executing the computing power scheduling task corresponding to the computing power scheduling request in the driver environment, the method further includes: Based on the GPU bound to the virtual machine, update the status information of the GPU in the driver compatibility information to the working status; Establish a correspondence between the computing power scheduling request and the driving environment, and record the correspondence in the driving compatibility information.

7. A resource scheduling device, characterized in that, The device includes: The information acquisition module is configured to acquire driver compatibility information on the server in response to a computing power scheduling request. The driver compatibility information includes at least one of the following: status information of each GPU in the server, GPU driver version information, CUDA version information, and GPU card identifier. The computing power scheduling module is configured to determine the driver environment of the computing power scheduling request based on the driver compatibility information, and execute the computing power scheduling task corresponding to the computing power scheduling request in the driver environment.

8. A server, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1-6.

Images