Intelligent computing device scheduling system, intelligent computing device scheduling method and storage medium

Abstract

The application relates to a smart computing device scheduling system, a smart computing device scheduling method and a storage medium, wherein the smart computing device scheduling system comprises a job manager, a job controller and a job scheduler; the job manager is used for receiving a business job request parameter, performing standardization processing on the business request parameter through a preset database, generating a standardized parameter, and issuing the standardized parameter to the job controller; wherein the standardized parameter comprises a device type, a resource type, a unique identifier and a resource capacity of the smart computing device; the job controller is used for filling the standardized parameter into a preset special job template, generating a standardized scheduling instruction, and issuing the standardized scheduling instruction to the job scheduler; and the job scheduler is used for mobilizing a job container group to a target node according to the standardized scheduling instruction, so that a target smart computing device on the target node executes a business job. Through the application, mixed calling of heterogeneous smart computing devices is realized.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to intelligent computing device scheduling systems, intelligent computing device scheduling methods, and storage media. Background Technology

[0002] In recent years, the explosive growth of fields such as artificial intelligence, big data analytics, and scientific computing has created an exponential demand for improved underlying computing capabilities. To address this challenge, heterogeneous intelligent computing clusters—hybrid architectures built by integrating diverse computing units such as CPUs, GPUs, FPGAs, and AI accelerator cards—have become the core infrastructure supporting complex workloads such as large-scale model training, high-performance numerical simulations, and real-time stream processing. However, traditional cluster management methods based on physical machines or virtual machines are typically designed for homogeneous intelligent computing devices and lack a unified abstraction capability for heterogeneous intelligent computing devices. They cannot dynamically schedule heterogeneous resources such as GPU memory, FPGA logic units, and AI accelerator card computing cores, resulting in both resource idleness and contention.

[0003] There is currently no effective solution to the problem of the inability to mix and schedule intelligent computing devices in related technologies. Summary of the Invention

[0004] This embodiment provides an intelligent computing device scheduling system, an intelligent computing device scheduling method, and a storage medium to solve the problem of the inability to schedule intelligent computing devices in combination in related technologies.

[0005] Firstly, this embodiment provides an intelligent computing device scheduling system, which is applied to the hybrid scheduling of multiple heterogeneous intelligent computing devices. The system includes: a job manager, a job controller, and a job scheduler.

[0006] The job manager is used to receive business job request parameters, standardize the business request parameters through a preset database to generate standardized parameters, and send the standardized parameters to the job controller; wherein, the standardized parameters include the device type, resource type, unique identifier, and resource capacity of the intelligent computing device;

[0007] The job controller is used to fill the standardized parameters into a preset dedicated job template, generate standardized scheduling instructions, and send the standardized scheduling instructions to the job scheduler.

[0008] The job scheduler is used to move the job container group to the target node according to the standardized scheduling instructions, so that the target intelligent computing device on the target node can execute the business job, wherein the device type of the target intelligent computing device is consistent with the device type in the standardized parameters.

[0009] In some embodiments, the job manager is also used to decouple the heterogeneous attributes of the intelligent computing device in the business request parameters from the core parameters of the business job, and to standardize the decoupled parameters through the preset database.

[0010] In some embodiments, the job manager is also used to establish a differentiated parameter adaptation mechanism based on the heterogeneity of the system architecture of the intelligent computing device, so as to match the intelligent computing device with the business job request parameters.

[0011] In some embodiments, the job controller is further configured to determine the target calling node according to preset resource scheduling rules and node affinity rules, and generate the standardized scheduling instructions according to the target calling node.

[0012] In some embodiments, the job controller is also used to reconstruct the container group identifier, container group address, container group quantity, and container group attribute value under each intelligent computing device, and generate the standardized scheduling instruction based on the reconstructed container group identifier, container group address, container group quantity, and container group attribute value.

[0013] In some embodiments, the preset dedicated job template includes a main job template, a container group sub-template, and a storage mounting sub-template;

[0014] The job master template is used to store the job name, job type, job priority, and queue affiliation.

[0015] The container group sub-template is used to store the hardware resource parameters and software configuration of the intelligent computing device;

[0016] The storage mounting sub-template is used to encapsulate the mounting paths and permission configurations for temporary storage and persistent storage.

[0017] In some embodiments, the job scheduler is further configured to determine that the business job has run successfully when the number of successful container groups corresponding to all target intelligent computing devices reaches their respective preset thresholds and the total number of successful container groups of all target intelligent computing devices reaches a preset total threshold.

[0018] In some embodiments, the system further includes a device management plugin, which is used to monitor the heterogeneous intelligent computing device information of each node of K8s in real time and parse the heterogeneous intelligent computing device information into a standardized data structure to obtain the preset database.

[0019] Secondly, this embodiment provides a smart computing device scheduling method for the smart computing device scheduling system described in the first aspect, comprising:

[0020] The system receives business operation request parameters and standardizes these parameters using a pre-set database to generate standardized parameters. These standardized parameters include the device type, resource type, unique identifier, and resource capacity of the intelligent computing device.

[0021] The standardized parameters are filled into a preset dedicated job template to generate standardized scheduling instructions;

[0022] The job container group is dispatched to the target node according to the standardized scheduling instructions, so that the target intelligent computing device on the target node can execute the business job; wherein, the device type of the target intelligent computing device is consistent with the device type in the standardized parameters.

[0023] Thirdly, this embodiment provides a storage medium storing a computer program that, when executed by a processor, implements the intelligent computing device scheduling method described in the second aspect above.

[0024] Compared with related technologies, the intelligent computing device scheduling system provided in this embodiment is applied to the mixed scheduling of multiple heterogeneous intelligent computing devices. The system includes a job manager, a job controller, and a job scheduler. The job manager receives business job request parameters, standardizes these parameters using a preset database to generate standardized parameters, and sends these standardized parameters to the job controller. The standardized parameters include the device type, resource type, unique identifier, and resource capacity of the intelligent computing device. The job controller fills the standardized parameters into a preset dedicated job template, generates standardized scheduling instructions, and sends these instructions to the job scheduler. The job scheduler, according to the standardized scheduling instructions, moves job container groups to target nodes so that target intelligent computing devices on the target nodes can execute business jobs. The device type of the target intelligent computing device is consistent with the device type in the standardized parameters. This system enables the mixed invocation of heterogeneous intelligent computing devices.

[0025] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 This is a schematic diagram of the intelligent computing device scheduling system in this embodiment.

[0028] Figure 2 This is a schematic diagram of another intelligent computing device scheduling system structure in this embodiment.

[0029] Figure 3 This is a flowchart of the intelligent computing device scheduling method in this embodiment.

[0030] Figure 4 This is a hardware structure block diagram of the terminal of the intelligent computing device scheduling method in this embodiment. Detailed Implementation

[0031] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0032] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0033] This embodiment provides an intelligent computing device scheduling system, which is applied to the hybrid scheduling of multiple heterogeneous intelligent computing devices. Figure 1 This is a schematic diagram of the intelligent computing device scheduling system structure in this embodiment, as shown below. Figure 1 As shown, the system includes: a job manager 101, a job controller 102, and a job scheduler 103;

[0034] The job manager 101 is used to receive business job request parameters, standardize the business request parameters through a preset database to generate standardized parameters, and send the standardized parameters to the job controller 102; the standardized parameters include the device type, resource type, unique identifier and resource capacity of the intelligent computing device.

[0035] Specifically, to achieve hybrid scheduling of heterogeneous intelligent computing devices, this embodiment establishes a scheduling system based on cluster deployment of an open-source container cluster management system. Heterogeneous intelligent computing devices refer to intelligent computing systems composed of various types of computing units (such as central processing units (CPUs), graphics processing units (GPUs), neural network processors (NPUs), field-programmable gate arrays (FPGAs), and application-specific integrated circuits (ASICs). These computing units have different instruction sets and architectures, enabling them to work collaboratively to achieve higher computing performance, energy efficiency, and functional diversity. The scheduling system deploys a job manager 101, a job controller 102, and a job scheduler 103. The job manager 101 interacts with the job controller 102, and the job controller 102 interacts with the job scheduler 103, Kubernetes (K8s), and the API server, forming a closed loop of "upper-layer control - intermediate execution - lower-layer scheduling." This scheduling system is applicable to both homogeneous and heterogeneous intelligent computing devices. This embodiment uses heterogeneous intelligent computing devices as an example for detailed explanation.

[0036] The Job Manager 101, serving as the core coordination and parameter processing hub for the entire job lifecycle management, collaborates with other modules through one-way interaction with the Job Controller 102 to complete job creation, information updates, information queries, and job cancellation throughout the entire lifecycle. The Job Manager 101 receives business job request parameters and performs multi-dimensional validity checks on these parameters, including checks on resource permissions, format specifications, and the rationality of the requirements. Based on successful checks, the Job Manager 101 converts the business request parameters into standardized fields recognizable by the system according to a pre-set database and persists these standardized fields to the database, generating standardized parameters. These standardized parameters include the intelligent computing device's device type, resource type, video memory, various types of high-speed networks, unique identifiers of the intelligent computing device (such as the device's ID and serial number), availability status (online / offline / faulty), and resource capacity (allocated resources per device, total number of devices). The generated standardized parameters are then distributed to the Job Controller 102.

[0037] The job controller 102 is used to fill standardized parameters into a preset dedicated job template, generate standardized scheduling instructions, and send the standardized scheduling instructions to the job scheduler 103.

[0038] Specifically, the job controller 102, as the core intermediate layer hub of the intelligent computing device scheduling system, mainly undertakes the connection and control between upper-layer parameter parsing and lower-layer heterogeneous execution. The job controller 102 receives parameters from the upper-layer job manager 101 and promotes the execution of the lower-layer job scheduler 103. After receiving the standardized parameters from the job manager 101, the job controller 102 first verifies the standardized parameters. If the verification is successful, it extracts the core configurations related to heterogeneous devices from the standardized parameters and fills them into a pre-set hybrid scheduling-specific job template to generate standardized scheduling instructions. These standardized scheduling instructions are then sent to the job scheduler 103.

[0039] The job scheduler 103 is used to dispatch job container groups to target nodes according to standardized scheduling instructions, so that target intelligent computing devices on the target nodes can execute business jobs, wherein the device type of the target intelligent computing devices is consistent with the device type in the standardized parameters.

[0040] Specifically, the job scheduler 103 is primarily responsible for the underlying scheduling execution and runtime status management in heterogeneous hybrid scheduling scenarios. After receiving standardized scheduling instructions from the job controller 102, the job scheduler 103 verifies the resource validity of candidate nodes, including checking node status, driver compatibility, resource quotas, and access permissions, ensuring the validity of pre-scheduling conditions and preventing job execution failures due to insufficient resources or configuration errors. After confirming resource validity, it performs fine-grained allocation of device-level resources according to the resource requirements of different types of heterogeneous intelligent computing devices such as GPUs, NPUs, and ASICs. It then precisely schedules the corresponding job container groups (Pods) for different types of heterogeneous intelligent computing devices to matching nodes and starts the corresponding target intelligent computing devices to execute business jobs. The device type of the target intelligent computing device is consistent with the device type in the standardized parameters. A job Pod is a specific running instance of a job in the system, encapsulating the job's code, dependent libraries, and runtime environment information.

[0041] The intelligent computing device scheduling system in this embodiment constructs a collaborative framework of job manager, job controller, and job scheduler. The job manager standardizes the business request parameters, and the job controller fills the standardized parameters into a preset dedicated job template to generate standardized scheduling instructions. The standardized scheduling instructions are then used to move the job container group to the target node, thereby realizing the hybrid scheduling of multiple types of heterogeneous intelligent computing devices.

[0042] In one embodiment, the job manager is also used to decouple the heterogeneous attributes of the intelligent computing device in the business request parameters from the core parameters of the business job, and to standardize the decoupled parameters through a preset database.

[0043] Specifically, for the mixed scheduling scenario of heterogeneous intelligent computing devices, in order to solve the problems of field redundancy, attribute coupling, poor adaptability and high expansion cost of traditional job data structure when multiple types of intelligent computing devices are connected, this embodiment restructures and standardizes the core data structure of the job, and adopts the method of "parameter layered decoupling + scenario-based dynamic adaptation" to build a unified, lightweight and scalable job description model.

[0044] In terms of structural design, at the job manager level, layered abstraction and separation of responsibilities are implemented. Based on business request parameters, the basic business parameters, resource specification parameters, and heterogeneous intelligent computing device-specific parameters required for job execution are explicitly decoupled. Heterogeneous hardware-related attributes such as device type, chip architecture, computing power specifications, driver version, acceleration features, and affinity constraints are extracted from the core of the job, forming an independent, configurable subset of heterogeneous device parameters. Simultaneously, parameters are normalized and redundancy-cleaned based on a pre-defined database, retaining only key fields strongly related to job scheduling, resource allocation, and device matching, while eliminating irrelevant, redundant, and conflicting parameters, reducing data structure complexity and parsing overhead. By introducing scalable and pluggable open parameter fields, it supports dynamically mounting configuration items specific to heterogeneous intelligent computing devices from different manufacturers and architectures (such as GPUs, NPUs, TPUs, FPGAs, and ASICs), achieving unified access, description, and parsing of multiple types of heterogeneous computing devices with a single data structure, meeting the parameter reception and transmission needs of diverse heterogeneous jobs.

[0045] In terms of compatibility design, the core data structure of this operation has backward compatibility and scenario adaptability, which can fully cover the scheduling scenarios of homogeneous intelligent computing devices: in a homogeneous environment, it automatically masks heterogeneous extended fields, maintaining the same parsing logic and scheduling behavior as the original operation model; in a heterogeneous hybrid environment, it automatically enables the heterogeneous device parameter layer to complete hardware matching and precise scheduling. The system can achieve seamless switching and unified management of homogeneous and heterogeneous scheduling without deploying independent homogeneous / heterogeneous adaptation modules, maintaining multiple sets of scheduling logic, or performing data format conversion.

[0046] Through the aforementioned upgrade of the underlying data structure, the compatibility barriers caused by the access of heterogeneous intelligent computing devices are eliminated at the data model level, the standardization and parsing efficiency of job descriptions are improved, a stable and unified data entry point is provided for the upper-level job manager and job controller, and the horizontal scalability, backward compatibility and long-term evolution capability of the system when continuously accessing new intelligent computing hardware are enhanced.

[0047] In another embodiment, the job manager is also used to establish a differentiated parameter adaptation mechanism based on the heterogeneity of the system architecture of the intelligent computing device, so as to match the intelligent computing device with the business job request parameters.

[0048] Specifically, in order to address the inherent differences in underlying hardware architecture, driver interfaces, execution models, software stack dependencies, and runtime environments among different types of heterogeneous intelligent computing devices, and to eliminate problems such as job startup failures, operational anomalies, and low computing power utilization caused by generalized parameter configuration, this embodiment also establishes a heterogeneous device differentiated parameter adaptation mechanism at the job manager level to achieve precise alignment between job operation parameters and device capability characteristics.

[0049] At the runtime environment and execution stack adaptation level, considering the significant differences in operator libraries, compilation toolchains, runtime environments, device driver versions, and internal calling interfaces relied upon by various heterogeneous intelligent computing devices such as GPUs, NPUs, ASICs, and FPGAs, a differentiated parameter configuration system strongly bound to the device type is constructed. This includes device-specific acceleration algorithm templates, container image addresses, container startup commands, permission parameters, device mapping methods, and environment variable configurations. Based on the device type specified in the job request, the system automatically loads and injects matching runtime parameters, ensuring that the job container can correctly interface with the target intelligent computing device's software stack during the startup phase, avoiding scheduling failures caused by environment incompatibility, command mismatches, or missing library dependencies.

[0050] At the storage and IO parameter adaptation level, considering the differences in storage mount protocols, local caching capabilities, high-speed storage support, file system permissions, and device access paths among various heterogeneous devices, and combining the personalized storage mount requirements of user businesses, a flexible and scalable storage mount parameter adaptation logic is designed. This logic supports dynamic configuration of mount paths, read / write permissions, caching policies, device visibility, and mixed mount rules for multiple storage media. It automatically verifies and generates storage parameters based on the capabilities of the target node device, ensuring that operations can obtain stable, efficient, and permission-compliant storage access capabilities on different heterogeneous devices.

[0051] At the level of dedicated hardware feature adaptation, it synchronously covers the differentiated parameter processing unique to heterogeneous devices such as high-bandwidth networks (high-bandwidth networks), multi-machine communication interfaces, dedicated acceleration ports, and device topology constraints, and provides independent parameter configuration channels for the exclusive capabilities of specific devices to achieve the correct activation and configuration of unique hardware functions.

[0052] Through the aforementioned multi-level, end-to-end differentiated parameter adaptation mechanism, the intelligent computing device scheduling system can automatically complete the dynamic matching, verification, and injection of job operation parameters with target heterogeneous intelligent computing devices, ensuring that jobs are started and run with optimal configuration on different devices, significantly improving scheduling success rate, device compatibility, and job stability, and maximizing the satisfaction of scheduling and operation needs of various heterogeneous intelligent computing devices.

[0053] In some embodiments, the job controller is further configured to determine the target calling node according to preset resource scheduling rules and node affinity rules, and generate standardized scheduling instructions based on the target calling node.

[0054] Specifically, addressing issues such as inaccurate device type matching, mismatch between resource load and computing power requirements, and Pod drift, resource contention, and scheduling conflicts caused by insufficient scheduling constraints in heterogeneous hybrid scheduling scenarios, this embodiment deeply optimizes the node selection and scheduling decision-making mechanism at the job controller level by constructing a multi-dimensional, hierarchical, and precise scheduling system. It also proposes a two-layer selection strategy generation logic of "resource scheduling constraints + node affinity rules," upgrading heterogeneous job scheduling from traditional coarse-grained "resource quantity matching" to end-to-end "precise attribute feature adaptation," thereby achieving an overall improvement in scheduling reliability, matching degree, and cluster utilization.

[0055] In the node selection and scheduling decision-making process, the job controller uses the observable indicators of the entire node domain as the decision input. It comprehensively collects static attributes such as the predefined heterogeneous intelligent computing device tags, hardware models, computing power specifications, driver versions, and acceleration capabilities of the nodes, as well as dynamic real-time resource load information such as node CPU utilization, memory usage, system load, remaining network bandwidth, available storage capacity, device video memory usage, device computing power utilization, and number of concurrent tasks. Based on multi-source data, it completes the admission filtering and priority ranking of candidate nodes, filtering out candidate nodes that meet the job's computing power requirements and resource constraints. The first layer uses the type of intelligent computing device as a strong constraint. Based on the rigid requirements of the job for specific acceleration hardware such as GPU, NPU, and ASIC, it matches the node device tags and filters out a set of nodes that are fully compatible in terms of hardware architecture, device model, and computing power specifications, ensuring that the job has legal and usable heterogeneous computing power support. The second layer uses the real-time resource load of the node as a dynamic selection criterion. Under the premise of meeting the device type matching, it comprehensively evaluates the node's operating indicators such as CPU, memory, video memory, bandwidth, device utilization, and task concurrency, and prioritizes nodes with low load, sufficient resource margin, and healthy operating status to avoid task blocking, computing power waste, or performance degradation caused by excessive load.

[0056] Building upon this foundation, the scheduling constraint capability is further enhanced by combining node affinity strategies. By configuring rules such as topology awareness, hardware-specific affinity, business group affinity, and fault domain isolation, a strong constraint scheduling boundary is constructed to achieve strong binding, targeted scheduling, and stable residence between job Pod groups and target nodes, effectively avoiding unexpected scheduling, cross-device migration, and resource conflicts.

[0057] Building upon this scheduling system, this embodiment addresses the hybrid deployment scenario of heterogeneous intelligent computing devices. It further abstracts and standardizes the two-layer screening strategy generation logic to achieve automatic strategy generation, dynamic loading, and closed-loop execution. The first layer is the resource quantity-level admission layer: Based on the job requirements submitted by the business, the job controller automatically parses the heterogeneous intelligent computing device type and application quantity, CPU / memory / storage quotas, and dedicated resource configuration items such as high-speed network cards, RDMA, and IB networks to generate strict and compliant K8s resource scheduling constraints (Resource Requests / Limits). These constraints serve as the basic threshold for node screening, ensuring that only nodes that meet the resource reserve requirements can enter the candidate pool, thus avoiding over-allocation, resource preemption, and scheduling failures. The second layer is the attribute feature adaptation layer: The system automatically parses the core features of the target heterogeneous device, such as hardware identifier, device type, instruction set architecture, software stack dependency, runtime environment, and acceleration capability, and dynamically generates refined K8s node affinity and anti-affinity rules; among them, the forced affinity constraint ensures that the job can only be scheduled to a legal node with the target device attribute, completely blocking incompatible scheduling; the preference affinity configuration dynamically optimizes the scheduling priority based on node load, device idle rate, and device health, generates standardized scheduling instructions, and guides the job scheduler to distribute tasks to the optimal matching node through standardized scheduling cooling.

[0058] By deeply integrating a two-layer mechanism of "hard constraint device matching + dynamic load optimization + enhanced affinity guarantee" with "resource quantity screening + attribute feature matching", the job controller achieves fully automated and precise control over the entire process from resource verification, device matching, policy generation to decision issuance. It avoids problems such as insufficient heterogeneous device resources, type incompatibility, environment mismatch, load imbalance, and scheduling conflicts from the execution source, ensuring that the job Pod groups corresponding to various heterogeneous intelligent computing devices are stably, efficiently, and accurately scheduled to the optimal matching node. This significantly improves the scheduling success rate, resource balance, job operation stability, and overall computing power throughput efficiency of large-scale heterogeneous intelligent computing clusters, providing reliable and scalable scheduling support capabilities for complex hybrid architecture intelligent computing centers.

[0059] In another embodiment, the job controller is also used to reconstruct the container group identifier, container group address, container group quantity and container group attribute value under each intelligent computing device, and generate standardized scheduling instructions based on the reconstructed container group identifier, container group address, container group quantity and container group attribute value.

[0060] Specifically, for complex distributed scenarios involving multi-zone high-availability deployment architectures and mixed scheduling of various types of heterogeneous intelligent computing devices, this embodiment reconstructs the rules for Pod metadata management, address aggregation, and rank value calculation under the single intelligent computing device type dimension to establish a distributed Pod orchestration system bound to the device type.

[0061] At the job controller level, through metadata isolation and dimensional management driven by intelligent computing device type tags, the originally globally unified logic for Pod identification, Pod address maintenance, Pod count statistics, and rank calculation is reconstructed into a mode of independent isolation, independent maintenance, and independent calculation based on heterogeneous intelligent computing device types (GPU / NPU / ASIC, etc.): Pods corresponding to the same type of heterogeneous devices are subject to unified identification specifications, unified address pool management, and unified instance counting. Under multi-zone distributed deployment conditions, it achieves automatic aggregation, real-time deduplication, and global visibility of Pod addresses across zones and of the same device type. At the same time, it performs accurate accumulation of Pod counts and status verification based on the device type dimension to ensure accurate instance statistics for Pods in different states such as Running, Pending, and Failed.

[0062] Based on this, the rank value calculation rules for heterogeneous intelligent computing devices are reconstructed, and multi-dimensional factors such as device type, zone distribution, node load, resource allocation, and scheduling priority are introduced to deeply bind the rank calculation with the target intelligent computing device type. This ensures that the Pod groups corresponding to the same type of intelligent computing devices maintain stable, orderly, and predictable numbering in distributed scheduling, avoiding problems such as rank conflicts, disordered arrangement, and instance sequence number drift caused by multiple devices being deployed together.

[0063] Based on this reconstruction and unified computing, the system generates standardized scheduling instructions for heterogeneous intelligent computing devices according to the reconstructed Pod identifier, Pod address, Pod quantity and rank value, realizing the integrated encapsulation and precise delivery of scheduling strategies, device matching rules, container group orchestration information and node constraints.

[0064] Through the above reconstruction, the system can achieve Pod autonomy for homogeneous intelligent computing devices, Pod isolation for heterogeneous intelligent computing devices, and global consistency of cross-domain states in complex environments with multiple zones and multiple types of intelligent computing devices. It solves technical problems such as chaotic Pod addresses, inaccurate number statistics, and abnormal rank value calculation in distributed heterogeneous scenarios, improves the topology stability, instance consistency, and communication reliability of distributed jobs when running collaboratively on multiple types of intelligent computing devices, and provides reliable underlying orchestration support for large-scale distributed heterogeneous intelligent computing jobs.

[0065] In some embodiments, the preset dedicated job template includes a job master template, a container group sub-template, and a storage mounting sub-template; wherein, the job master template is used to store the job name, job type, job priority, and queue affiliation; the container group sub-template is used to store the hardware resource parameters and software configuration of the intelligent computing device; and the storage mounting sub-template is used to encapsulate the mounting paths and permission configurations of temporary storage and persistent storage.

[0066] Specifically, to meet the needs of differentiated configuration, operating environment, and scheduling strategy brought about by the coexistence of heterogeneous intelligent computing devices from multiple vendors, architectures, and versions in large-scale intelligent computing clusters, this embodiment adopts a layered and decoupled job template architecture of "main template - sub-template" as a dedicated job template. Through a layered mode of centralized global configuration, professional device configuration, and independent storage configuration, the job templates are managed in a unified manner, dynamically combined, quickly reused, and version controlled, thereby improving the delivery efficiency, accuracy, and ease of operation and maintenance of job configuration in heterogeneous hybrid scenarios.

[0067] This dedicated job template architecture divides job configuration into three layers: job main template, Pod group sub-template, and storage mounting sub-template. Each layer is decoupled through reference relationships, and they do not intrude on or overwrite each other. It supports flexible adaptation to various heterogeneous intelligent computing devices such as GPUs, NPUs, ASICs, and FPGAs without modifying the core template.

[0068] The main job template serves as the top-level entry point and global control hub of the template system. It uniformly carries job-level global configurations that are independent of devices and instances, including job name, job type, job description, job priority, scheduling queue affiliation, timeout policy, retry policy, permission policy, and job lifecycle management policy. The main template is not strongly bound to any specific heterogeneous device; it only serves as a configuration skeleton. It supports dynamically referencing one or more Pod group sub-templates and storage mount sub-templates, thereby enabling a single main template to adapt to various scenarios such as homogeneous scheduling, heterogeneous scheduling, and multi-device mixed scheduling. This reduces template redundancy and maintenance costs, and achieves standardization and consistency in global configuration.

[0069] The Pod group sub-templates are professionally encapsulated based on the hardware and software stack differences of heterogeneous devices. Addressing the inherent differences in resource specifications, computing power constraints, operating environments, startup methods, dependent libraries, and device mappings among different types of heterogeneous intelligent computing devices, each Pod group sub-template independently encapsulates a full set of Pod-level configurations: including hardware resource constraints such as heterogeneous device type, number of devices, computing power card quota, CPU quota, memory quota, system kernel version, and device driver dependencies. It also includes runtime configurations strongly bound to the intelligent computing device type, such as algorithm instance selection, container image address, container startup command, permission parameters, environment variable configuration, and device scheduling policies. Furthermore, it supports creating independent, dedicated Pod group sub-templates for each type of heterogeneous intelligent computing device, including GPUs, FPGAs, NPUs, and ASICs, ensuring that jobs can directly load fully matching configuration items during scheduling and startup. This avoids job startup failures or runtime anomalies caused by environment incompatibility, parameter mismatches, or inconsistent commands at the template level.

[0070] The storage mounting sub-template leverages the differentiated characteristics of heterogeneous intelligent computing devices in terms of storage access capabilities, storage protocols, caching mechanisms, path visibility, and permission models. It also meets the personalized mounting needs of user businesses, such as persistence, multiple replicas, shared storage, and local temporary storage. It independently encapsulates the mounting configurations for various storage media, including temporary storage, host path storage, distributed block storage, file storage, and object storage, specifying mounting paths, mounting permissions, read / write modes, caching strategies, storage categories, capacity limits, isolation strategies, and device visibility range. By decoupling storage configuration from job configuration and device configuration, the system can automatically select the optimal storage mounting strategy based on the storage adaptability of the target heterogeneous device. This ensures stable and available storage paths, compliant permissions, and performance matching, improving data access consistency and storage compatibility across different heterogeneous devices.

[0071] Through the layered and decoupled architecture of "unified management of main template + professional combination of multiple sub-templates" mentioned above, job templates can achieve standardized global configuration, dedicated heterogeneous configuration, and flexible storage configuration. They support on-demand combination, dynamic replacement, batch reuse, and version management, and can quickly respond to the access of new heterogeneous devices, the expansion of business scenarios, and the upgrading of scheduling strategies. From the configuration layer, it provides heterogeneous intelligent computing clusters with highly reliable, efficient, and loosely coupled job template support capabilities, ensuring that various heterogeneous jobs run stably, consistently, and efficiently in complex hybrid deployment environments.

[0072] In another embodiment, the job scheduler is also used to determine that the business job has run successfully when the number of successful container groups corresponding to all target intelligent computing devices reaches their respective preset thresholds and the total number of successful container groups of all target intelligent computing devices reaches a preset total threshold.

[0073] Specifically, the job scheduler is also used to monitor whether business jobs run successfully. Before a job starts, it sets a minimum Pod threshold for each type of device based on the computing power characteristics and subtask carrying requirements of various heterogeneous intelligent computing devices (such as GPUs and TPUs), and also sets a minimum total Pod threshold for the entire job, forming a hierarchical judgment benchmark. During job execution, the node monitoring agent collects the Pod status of various device nodes in real time, accurately counting the number of successfully running Pods (excluding invalid Pods such as those that failed to start or had abnormal computing power), ensuring the reliability of the statistical data. The job is considered successful only when the number of successful Pods for each type of intelligent computing device reaches the threshold, and the total number of successful Pods for all intelligent computing devices meets the overall threshold. If the number of successful Pods for any type of device does not reach the threshold, a retry mechanism is immediately triggered. The number of retries can be preset according to cluster stability. During the retry period, the Pod status is continuously monitored until the threshold is reached or the retry is exhausted. After the retry is exhausted, the job is marked as failed and logs are retained to support troubleshooting, thereby achieving accurate judgment and anomaly handling for heterogeneous hybrid scheduling jobs and ensuring stable job execution.

[0074] In some embodiments, the system also includes a device management plugin, which is used to monitor the heterogeneous intelligent computing device information of each node of K8s in real time and parse the heterogeneous intelligent computing device information into a standardized data structure to obtain a preset database.

[0075] Specifically, to achieve unified management and scheduling adaptation of heterogeneous intelligent computing devices, this embodiment deploys a device management plugin on each node of the K8s cluster to ensure that each node can achieve real-time collection and reporting of device data. The plugin continuously listens for node resource change events (including node additions, device status changes, resource adjustments, etc.) pushed by the K8sAPIServer, and reads the original operating data and resource information of heterogeneous intelligent computing devices by calling the local device driver interface of the node, avoiding the parsing chaos caused by differences in data formats from different device manufacturers.

[0076] The plugin incorporates a standardized parsing module that uniformly parses the collected raw data into a pre-defined standardized data structure, resulting in a pre-defined database. This structure covers all core dimensions required for job scheduling: Device type clearly distinguishes different models of intelligent computing devices such as H200, H100, and A100; resource type covers all resources of the intelligent computing device, including computing power, CPU core count, and memory capacity, as well as key information such as the device's GPU memory specifications, high-speed network bandwidth and protocol type, unique device identifier (device ID, hardware serial number), real-time availability status (online / offline / faulty), and resource capacity (allocated computing power per device, total number of such devices in the cluster). Furthermore, the data structure reserves configurable extension fields to support the rapid integration of newly added heterogeneous intelligent computing devices (such as TPUs and ASICs) without requiring a complete reconstruction of the overall data parsing system, effectively ensuring the scalability and compatibility of the solution.

[0077] To achieve accurate differentiation and scheduling of various heterogeneous intelligent computing devices, a dedicated device type (label) is configured for each type of heterogeneous intelligent computing device in the cluster. The label adopts a hierarchical naming standard of "device type-model-computing power level" (e.g., GPU-H200-800t), ensuring that a specific type and specification of intelligent computing device can be quickly located through the label. This provides a core identification basis for device screening and priority allocation in heterogeneous mixed scheduling, and avoids device type confusion during the scheduling process.

[0078] An event-driven data synchronization architecture is adopted. When data from heterogeneous intelligent computing devices described by a standardized data structure is added, its status changes, or its resources are adjusted, a synchronization event is immediately triggered. The changed data is then pushed to the cluster database (such as ETCD or PostgreSQL) in real time via a message queue, achieving data synchronization latency control within milliseconds. A data verification mechanism is introduced during the synchronization process to verify the integrity and accuracy of the pushed data, preventing invalid data from being entered into the database. This ensures that users can perceive the status and resource changes of various heterogeneous intelligent computing devices in real time through the scheduling platform, accurately request suitable device resources, and meet the resource requirements of high-performance computing services such as large-scale model training and large-scale inference.

[0079] This embodiment also provides an intelligent computing device scheduling system. Figure 2 This is a schematic diagram of another intelligent computing device scheduling system structure in this embodiment, as shown below. Figure 2 As shown, the system includes a device management plugin 21, a job manager 22, a job controller 23, and a job scheduler 24. The job manager 22 includes a data standardization processing module 221 and a differential parameter adaptation module 222. The job controller 23 includes a node resource scheduling strategy module 231, a container group reconstruction module 232, and a dedicated job template 233. The dedicated job template 233 includes a job master template 2331, a container group sub-template 2332, and a storage mounting sub-template 2333. The job scheduler 24 includes a container group scheduling module 241 and a business job operation monitoring module 242.

[0080] Device management plugin 21 is used to monitor the heterogeneous intelligent computing device information of each node in K8s in real time, and parse the heterogeneous intelligent computing device information into a standardized data structure to obtain a preset database.

[0081] The data standardization processing module 221 is used to decouple the heterogeneous attributes of intelligent computing devices from the core parameters of business operations in the business request parameters, and to standardize the decoupled parameters through a preset database.

[0082] The differentiated parameter adaptation module 222 is used to establish a differentiated parameter adaptation mechanism based on the heterogeneity of the system architecture of the intelligent computing device, so as to match the intelligent computing device with the business operation request parameters.

[0083] The node resource scheduling strategy module 231 is used to determine the target calling node according to the preset resource scheduling rules and node affinity rules, and generate standardized scheduling instructions based on the target calling node.

[0084] The container group reconstruction module 232 is used to reconstruct the container group identifier, container group address, container group quantity and container group attribute value under each intelligent computing device, and generate standardized scheduling instructions based on the reconstructed container group identifier, container group address, container group quantity and container group attribute value.

[0085] The main job template 2331 is used to store the job name, job type, job priority, and queue affiliation.

[0086] Container group sub-template 2332 is used to store the hardware resource parameters and software configuration of intelligent computing devices.

[0087] Storage mount sub-template 2333 is used to encapsulate the mount path and permission configuration for temporary storage and persistent storage.

[0088] The container group scheduling module 241 dispatches the job container group to the target node according to the standardized scheduling instructions, so that the target intelligent computing device on the target node can perform business operations.

[0089] The business operation monitoring module 242 is used to determine that the business operation is successful when the number of successful container groups corresponding to all target intelligent computing devices reaches their respective preset thresholds and the total number of successful container groups of all target intelligent computing devices reaches the preset total threshold.

[0090] This embodiment provides a method for scheduling intelligent computing devices, which is used in the intelligent computing device scheduling system described in the above system embodiment. Figure 3 This is a flowchart of the intelligent computing device scheduling method in this embodiment, as follows: Figure 3 As shown, the process includes the following steps:

[0091] Step S301: Receive business operation request parameters and standardize the business request parameters through a preset database to generate standardized parameters; wherein, the standardized parameters include the device type, resource type, unique identifier, and resource capacity of the intelligent computing device.

[0092] Specifically, the system's job manager receives business job request parameters through three methods: preset API interfaces, batch pushes from business systems, and manual user input. These parameters are then pushed to a preset database, where a built-in standardized processing module transforms them. This module uses pre-defined, unified parameter mapping rules and validation logic. It first validates the request parameters, filtering invalid parameters and outliers, and excluding unreasonable requests such as those exceeding cluster device resource capacity or non-existent device types, ensuring parameter validity. Next, the standardized processing module performs standardized mapping and formatting of the valid parameters according to device management standardization specifications, ultimately generating standardized parameters. These parameters include core dimensions of device data, including the device type (e.g., H200, H100, consistent with device parsing specifications), resource type (e.g., computing power, memory, etc.), unique identifier (e.g., device ID, serial number, supporting precise and fuzzy matching), and resource capacity (allocated per device, total demand).

[0093] Step S302: Fill the standardized parameters into the preset dedicated job template to generate standardized scheduling instructions.

[0094] Specifically, the job controller in the system fills the generated standardized parameters into a dedicated job template according to preset rules. This job template is pre-set to adapt to heterogeneous intelligent computing scheduling scenarios, and has built-in scheduling logic, resource allocation rules, and parameter mapping fields, making it compatible with the scheduling needs of different types of intelligent computing devices. During the filling process, the system accurately matches the standardized parameters with the template fields, filling core parameters such as device type, resource type, unique identifier, and resource capacity into the specified positions in the template. At the same time, it automatically verifies the compatibility between the parameters and template fields to avoid problems such as missing parameters or incompatible formats. After filling is completed, the system triggers the scheduling instruction generation module, which, combined with the built-in logic of the job template and the standardized parameters, generates a standardized scheduling instruction. This instruction includes core information such as device selection conditions, resource allocation quota, and scheduling priority. After the standardized scheduling instruction is generated, it is synchronously stored in a preset database and archived along with the standardized parameters and job template, facilitating subsequent scheduling traceability, anomaly investigation, and process optimization, ensuring the integrity and traceability of the entire business request processing and scheduling instruction generation chain.

[0095] Step S303: The job container group is moved to the target node according to the standardized scheduling instructions so that the target intelligent computing device on the target node can perform business operations; wherein, the device type of the target intelligent computing device is consistent with the device type in the standardized parameters.

[0096] Specifically, the job scheduler in the system receives the standardized scheduling instructions, initiates the job container group scheduling process, and accurately matches target nodes within the cluster based on core information such as device selection criteria and resource allocation quotas in the standardized scheduling instructions. During the scheduling process, the job scheduler prioritizes selecting nodes containing intelligent computing devices whose device types match those in the standardized parameters as target nodes. Simultaneously, it verifies whether the resource capacity of the target node meets the preset resource requirements in the standardized parameters, ensuring that the target node has the hardware foundation to execute business operations.

[0097] After confirming the target node, the scheduler dispatches the job container group (Pod) to that target node according to the scheduling instructions, completing the deployment and startup of the container group. During deployment, the system automatically establishes an association between the job container group and the target intelligent computing device on the target node, ensuring that the target intelligent computing device (whose device type is completely consistent with the device type in the standardized parameters) can be normally invoked by the job container group. After the job container group starts up, the target intelligent computing device will start operations such as computing power output and data processing according to the scheduling instructions and business operation requirements, and officially execute the business operation, realizing a closed loop of the entire process from business request parameters to actual job execution, ensuring the accuracy and efficiency of heterogeneous intelligent computing device scheduling and job execution.

[0098] Through steps S301 to S303 above, after the job manager receives the business job parameters, it verifies the business job parameters and synchronizes them to the database for parameter standardization processing to obtain standardized parameters. The job controller performs secondary verification on the standardized parameters, extracts the device parameters, and fills the extracted device parameters into the preset job template to generate standardized scheduling instructions. The job scheduler receives the standardized scheduling instructions and, based on the device screening and resource allocation requirements in the instructions, selects the node where the intelligent computing device with the same device type as the standardized parameters is located as the target node and completes resource verification. Then, it schedules the job container group to the target node for deployment and startup, establishes the association between the container group and the target intelligent computing device, realizes accurate matching and hybrid scheduling of different types of heterogeneous intelligent computing devices, and improves the accuracy and efficiency of heterogeneous intelligent computing device scheduling and job execution.

[0099] The following are examples illustrating specific implementation methods:

[0100] This embodiment is based on the Kubernetes (hereinafter referred to as K8s) open source container cluster management system. The cluster contains two types of heterogeneous intelligent computing devices, which are defined as the first type of intelligent computing device and the second type of intelligent computing device (which can correspond to different models of GPUs such as H200 and H100 or other intelligent computing devices in actual scenarios). The two types of devices have different architectures and computing power specifications, and need to achieve hybrid scheduling through differentiated management.

[0101] Deploy the device management plugin in the Kubernetes cluster, and deploy three core functional modules: job manager, job controller, and job scheduler. The three modules follow a preset hierarchical interaction rule: the job manager receives and verifies business requests, the job controller generates scheduling policies and job templates, and the job scheduler performs node filtering and Pod scheduling, forming a closed-loop management.

[0102] Device identification configuration: To achieve accurate differentiation between the two types of heterogeneous intelligent computing devices, the K8s label mechanism is adopted. The first type of intelligent computing device is configured with a unique label "device-type: type-A", and the second type of intelligent computing device is configured with a unique label "device-type: type-B". The label serves as the core identifier for subsequent node screening and Pod affinity scheduling, ensuring that the device type is not confused during the scheduling process.

[0103] A device management plugin is deployed on each node of the Kubernetes cluster using the DaemonSet pattern to ensure that data from heterogeneous intelligent computing devices on each node can be collected in real time. This plugin continuously monitors node resource change events pushed by the Kubernetes API Server (including node additions, device status changes, resource adjustments, etc.) and reads the node's hardware information and operational data configured with two types of intelligent computing devices by calling the node's local device driver interface.

[0104] The plugin incorporates a standardized parsing module that unifies the collection of raw data from heterogeneous intelligent computing devices in different formats into a pre-defined standardized data structure, avoiding data format confusion caused by differences in device manufacturers and models. This standardized data structure comprehensively covers the core dimensions required for scheduling, specifically including: device type (distinguishing between type-A and type-B), resource type (computing power, CPU, memory, etc. of intelligent computing devices), intelligent computing device graphics memory specifications, high-speed network bandwidth and protocol type, unique device identifier (device ID, hardware serial number), device availability status (online / offline / faulty), resource capacity (allocatable resources per device, total number of such devices in the cluster), and device health status (core hardware operating parameters, fault warning information), providing unified and standardized data support for subsequent scheduling.

[0105] An event-driven data synchronization architecture is adopted. When data from heterogeneous intelligent computing devices described by a standardized data structure is added, its status changes, or resources are adjusted, a synchronization event is immediately triggered. The changed data is pushed to the cluster's preset database (such as ETCD or PostgreSQL) in real time through message queues (such as RocketMQ or Kafka), thereby controlling the data synchronization latency to the millisecond level and ensuring data real-time performance.

[0106] Users can query device data in the database through the cluster management platform to obtain information such as the real-time availability status and remaining resources of the two types of heterogeneous intelligent computing devices. Based on their own business needs (such as large model training and large-scale inference), users can submit a mixed scheduling job application for heterogeneous intelligent computing devices and clarify the resource requirements of the two types of devices.

[0107] The business side submits specific job parameters through the management platform. The core configurations include: specifying that the number of Pods for the first type of intelligent computing device (type-A) is 100 and the number of Pods for the second type of intelligent computing device (type-B) is 100; at the same time, configuring the Pod running parameters for the two types of devices, including the device image address (adapting to the algorithm image of the corresponding intelligent computing device), container startup command (specifying the job execution logic), running algorithm version, environment variables (such as computing power configuration, cache path), storage mount information (data storage directory, shared storage mount), etc., to ensure that the Pods can normally call the resources of the intelligent computing device.

[0108] After receiving the above parameters, the job manager executes a dual verification logic: first, it verifies the user's project's resource access permissions to the two types of heterogeneous intelligent computing devices, confirming that the user has the corresponding device usage rights; second, it verifies the validity of the parameter format, filtering invalid parameters and outliers (such as the number of Pods exceeding the device's resource capacity, or non-existent image addresses). Upon successful verification, the job parameters are persisted to the database archive, and a standardized parameter request is assembled and sent to the job controller according to the preset interface protocol, triggering the subsequent scheduling process.

[0109] After receiving the parameter request from the job manager, the job controller generates a node affinity scheduling policy based on the two types of intelligent computing devices (type-A and type-B) in the parameters: the first group of 100 Pods is configured with node affinity rules, which only apply affinity to nodes with the label "device-type: type-A" (i.e., nodes deploying the first type of intelligent computing device); the second group of 100 Pods is configured with node affinity rules, which only apply affinity to nodes with the label "device-type: type-B" (i.e., nodes deploying the second type of intelligent computing device), ensuring that Pods can be accurately scheduled to the corresponding type of intelligent computing device node.

[0110] The job controller loads a pre-defined modular job template (adapted to Kubernetes Pod deployment specifications), accurately filling in the corresponding positions in the template with parameters such as the image address, startup command, and environment variables submitted by the business side, according to the template field mapping rules, generating a standardized YAML format job configuration file. During the filling process, dynamic concatenation and cumulative calculation logic is used to process Pod-related parameters, automatically generating unique Pod sequence numbers, network addresses, and other information to ensure the system can correctly identify the number, sequence number, and deployment address of each group of Pods, avoiding Pod conflicts. After generating the YAML file, the job controller issues a standardized scheduling creation command to the job scheduler.

[0111] After receiving standardized scheduling instructions from the job controller, the job scheduler initiates a node screening process, combining multi-dimensional constraints to achieve precise screening: First, following the node affinity strategy, nodes with corresponding device tags (type-A or type-B) are screened out; second, the node resource load status is verified, excluding nodes with excessive resource consumption or abnormal health status; third, combining resource scheduling constraints (such as matching Pod resource request volume and node resource remaining quantity), the target nodes that are suitable and have corresponding intelligent computing devices deployed are finally screened out.

[0112] After the screening is completed, the job scheduler schedules the two groups of Pods to the corresponding target nodes according to the requirements of the YAML configuration file, completes the deployment and startup of the Pods, and establishes the association between the Pods and the intelligent computing devices on the target nodes to ensure that the Pods can normally call the computing resources of the intelligent computing devices, and realizes the hybrid parallel scheduling of the two heterogeneous intelligent computing devices.

[0113] During job execution, users can initiate job status query requests through the management platform. After receiving the request, the job manager reads static data such as job parameters and device status from the database, and simultaneously calls the K8s APIServer interface to obtain real-time Pod running data (such as Pod running status, resource usage, and error information). The data is then integrated and fed back to the user, including the overall job running status, the running status of each of the two Pods (running / failed / completed), and the resource usage of the intelligent computing device (computing power utilization, memory usage, etc.), making it convenient for users to monitor the job execution status in real time.

[0114] If a user needs to cancel a job, they can issue a job cancellation command through the management platform. The job manager will then synchronize the command to the job controller, which will immediately notify the job scheduler to terminate all Pods corresponding to the job. At the same time, it will release the computing devices, CPU, memory, and other resources occupied by the Pods, ensuring efficient resource recovery.

[0115] To ensure the normal execution of the job, the Kubernetes cluster configures unified communication rules through the Container Network Interface (CNI) to assign independent and interoperable network addresses to the two groups of Pods. This ensures smooth bidirectional data transmission between different Pod groups (corresponding to different heterogeneous intelligent computing devices) without communication interruptions or data loss, thus guaranteeing the collaborative execution of hybrid scheduling jobs.

[0116] In this embodiment, the job was successfully deployed and executed on two types of heterogeneous intelligent computing device nodes, with a total of 200 Pods, continuous and uninterrupted rank, and a job completion rate of 100%. Device plug-ins report device status in real time, with data synchronization latency ≤10s; modular templates allow for adjustments to the corresponding sub-templates when adding new intelligent computing device types, improving maintenance efficiency by 60%; and cluster resource utilization is improved by more than 45% compared to a single device scheduling scheme.

[0117] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. For example, it can run on a terminal. Figure 4 This is a hardware structure block diagram of the terminal of the intelligent computing device scheduling method in this embodiment. For example... Figure 4 As shown, a terminal may include one or more ( Figure 4 Only one is shown in the diagram. A processor 402 and a memory 404 for storing data are also included. The processor 402 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 406 for communication functions and an input / output device 408. Those skilled in the art will understand that… Figure 4 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown are illustrated.

[0118] The memory 404 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the intelligent computing device scheduling method in this embodiment. The processor 402 executes various functional applications and data processing by running the computer program stored in the memory 404, thereby implementing the aforementioned method. The memory 404 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 404 may further include memory remotely located relative to the processor 402, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] Transmission device 406 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, transmission device 406 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, transmission device 406 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0120] Furthermore, in conjunction with the intelligent computing device scheduling method provided in the above embodiments, this embodiment can also provide a storage medium for implementation. The storage medium stores a computer program; when the computer program is executed by a processor, it implements any of the intelligent computing device scheduling methods in the above embodiments.

[0121] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0122] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0123] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0124] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0125] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0126] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A smart computing device scheduling system, characterized in that, The system is applied to the hybrid scheduling of multiple heterogeneous intelligent computing devices, and the system includes: a job manager, a job controller, and a job scheduler; The job manager is used to receive business job request parameters, standardize the business job request parameters through a preset database to generate standardized parameters, and send the standardized parameters to the job controller; wherein, the standardized parameters include the device type, resource type, unique identifier, and resource capacity of the intelligent computing device; The job controller is used to fill the standardized parameters into a preset dedicated job template, generate standardized scheduling instructions, and send the standardized scheduling instructions to the job scheduler. The preset dedicated job template includes a main job template, a job container group sub-template, and a storage mounting sub-template. The main job template stores the job name, job type, job priority, and queue affiliation, and references the job container group sub-template and the storage mounting sub-template according to the device type and resource type. The job container group sub-template stores the hardware resource parameters and software configuration of the intelligent computing device, and generates a target job container group sub-template based on the standardized parameters. The storage mounting sub-template encapsulates the mounting paths and permission configurations for temporary and persistent storage, and generates an optimal storage mounting strategy based on the standardized parameters. The job scheduler is used to move the job container group to the target node according to the standardized scheduling instructions, so that the target intelligent computing device on the target node can execute the business job, wherein the device type of the target intelligent computing device is consistent with the device type in the standardized parameters.

2. The intelligent computing device scheduling system according to claim 1, characterized in that, The job manager is also used to decouple the heterogeneous attributes of the intelligent computing device from the core parameters of the business job request parameters, and to standardize the decoupled parameters through the preset database.

3. The intelligent computing device scheduling system according to claim 1, characterized in that, The job manager is also used to establish a differentiated parameter adaptation mechanism based on the heterogeneity of the system architecture of the intelligent computing device, so as to match the intelligent computing device with the business job request parameters.

4. The intelligent computing device scheduling system according to claim 1, characterized in that, The job controller is also used to determine the target calling node according to preset resource scheduling rules and node affinity rules, and generate the standardized scheduling instructions according to the target calling node.

5. The intelligent computing device scheduling system according to claim 1, characterized in that, The job controller is also used to reconstruct the container group identifier, container group address, container group quantity, and container group attribute value under each intelligent computing device, and generate the standardized scheduling instruction based on the reconstructed container group identifier, container group address, container group quantity, and container group attribute value.

6. The intelligent computing device scheduling system according to claim 1, characterized in that, The job scheduler is also used to determine that the business job has been successfully executed when the number of successful container groups corresponding to all target computing devices reaches their respective preset thresholds and the total number of successful container groups of all target computing devices reaches a preset total threshold.

7. The intelligent computing device scheduling system according to claim 1, characterized in that, The system also includes a device management plugin, which is used to monitor the heterogeneous intelligent computing device information of each node of K8s in real time, and parse the heterogeneous intelligent computing device information into a standardized data structure to obtain the preset database.

8. A method for scheduling intelligent computing devices, used in the intelligent computing device scheduling system according to any one of claims 1 to 7, characterized in that, The method includes: The system receives business operation request parameters and standardizes these parameters using a preset database to generate standardized parameters. These standardized parameters include the device type, resource type, unique identifier, and resource capacity of the intelligent computing device. The standardized parameters are filled into a preset dedicated job template to generate standardized scheduling instructions; The job container group is dispatched to the target node according to the standardized scheduling instructions, so that the target intelligent computing device on the target node can execute the business job; wherein, the device type of the target intelligent computing device is consistent with the device type in the standardized parameters.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the intelligent computing device scheduling method of claim 8.

Images