A cross-platform local device task execution method and system based on deep learning

Abstract

The application relates to the technical field of edge computing, and discloses a cross-platform local device task execution method and system based on deep learning, which is applied to a task distributor of a heterogeneous edge node cluster. By acquiring hardware characteristic values and observable state information of each node, combining a hardware declaration list, distinguishing missing field into an interface-restricted unobservable field and a hardware real missing field, and generating a semantic label, normalized hardware characteristic values, a missing mask, a source category state vector, a node observation integrity scalar and a task demand vector are spliced into a unified input tensor; a deep learning model is inputted, a node capability portrait is generated through attention attenuation and compensation, a predicted execution time and an observable credibility score are outputted in parallel; candidate pools are divided according to the credibility score, high-credibility nodes are preferentially dispatched, and low-credibility nodes are globally sorted after risk weighting to determine whether to dispatch a tentative task, so that cross-platform load balancing is achieved.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a cross-platform local device task execution method and system based on deep learning. Background Technology

[0002] In edge computing clusters, to maximize system throughput under latency constraints, a deep learning task allocator is typically used to dynamically distribute different neural network inference tasks to the most suitable edge nodes for execution. During normal execution, the task allocator periodically obtains hardware characteristic data from the local agents of each node, including the number of CPU cores, frequency, memory capacity, and the type and idle rate of AI accelerators. This data is concatenated into a feature vector and fed into the deep learning model, which outputs the predicted execution time for each inference task for each node, and distributes tasks accordingly.

[0003] However, in real-world heterogeneous edge node clusters, the underlying hardware and operating systems of node devices often differ significantly. When a lightweight gateway or embedded device running a trimmed-down operating system is connected to the cluster, its local agent may be unable to obtain certain high-level fields, such as the idle rate of the AI ​​accelerator, due to limitations in the system monitoring interface capabilities, and thus can only report null values. In this case, a structural gap appears in the hardware feature data collected from different nodes at the raw feature input layer of the deep learning model. Since the input layer of deep learning models typically expects fixed-length feature vectors, the system often fills these null values ​​with simple zero values ​​or default placeholders. During model training, if a sample combination with a zero accelerator idle rate and normal other features has never been seen before, this abnormal input feature vector will trigger the non-linear saturation region of the activation function after passing through the hidden layer, causing an uncontrollable shift in the device capability profile vector generated by the model for that node in the representation space. The model may then determine that the accelerator is completely unusable, even if the node actually possesses available hardware acceleration resources. Existing deep learning assignment mechanisms largely rely on fixed-length feature vector inputs. They cannot effectively identify whether structural feature gaps caused by system pruning are due to system platform limitations or actual hardware deficiencies, thus amplifying misjudgments of node capabilities. Therefore, in deep learning-driven inference task assignment within heterogeneous edge node clusters, when the hardware feature extraction interface of lightweight nodes cannot provide complete fields and generates null values ​​due to system pruning, the deep learning model's input layer, after filling with fixed values, triggers an incorrect model profile of device capabilities. This causes task assignment decisions to skew towards high-end nodes with complete fields, ultimately resulting in cluster load imbalance and excessive task execution latency.

[0004] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0005] This application discloses a cross-platform local device task execution method and system based on deep learning, which aims to solve the problem of structural missing hardware feature data caused by system pruning in heterogeneous edge node clusters, which leads to incorrect profiling of node capabilities by deep learning models and unbalanced task allocation load.

[0006] The technical solution of this application is as follows: In a first aspect, this application discloses a cross-platform local device task execution method based on deep learning, applied to a task allocator associated with a heterogeneous edge node cluster. The heterogeneous edge node cluster includes lightweight nodes running a trimmed operating system and high-end nodes with complete monitoring interfaces. The method includes: S1: Obtain the hardware characteristic values ​​and observable state information of each node; S2: Based on observable state information and the hardware declaration list during initial node registration, identify missing fields and classify them into interface-restricted unobservable fields and hardware-truthfully missing fields, and generate semantic labels for each field. S3: Concatenate the normalized hardware feature values, the mask indicating whether a field is missing, the source category state vector reflecting the semantic label, the node observation completeness scalar, and the target task requirement vector into a unified input tensor. S4: Input the unified input tensor into the deep learning model, and generate node capability profile vectors under constrained conditions by attenuating the attention weights of the unobservable fields with limited interfaces. Based on the node capability profile vectors, output the prediction execution time and observable credibility score of the corresponding nodes for the target task in parallel. S5: Based on the observable credibility score, each node is divided into a high credibility pool node and a low credibility pool node. High credibility pool nodes are assigned priority based on the predicted execution time. For low credibility pool nodes, the predicted execution time is risk-weighted based on their credibility score, and then globally ranked with high credibility nodes to determine whether to assign exploratory tasks.

[0007] Secondly, this application also discloses a deep learning-based cross-platform local device task execution system, applied to a task allocator associated with a heterogeneous edge node cluster, to execute the steps of the deep learning-based cross-platform local device task execution method described above. The heterogeneous edge node cluster includes lightweight nodes running a trimmed operating system and high-end nodes with complete monitoring interfaces. The system includes: a data acquisition module for acquiring hardware feature values ​​and observable state information of each node; a separation and labeling module for identifying missing fields based on the observable state information and the hardware declaration list at the time of initial node registration, and distinguishing the missing fields into interface-restricted unobservable fields and truly missing hardware fields, generating semantic labels for each field; and an input reconstruction module for converting normalized hardware feature values ​​and masks indicating whether a field is missing. The system concatenates the code, the source category state vector reflecting the semantic label, the node observation completeness scalar, and the target task requirement vector into a unified input tensor. The prediction and evaluation module inputs this unified input tensor into the deep learning model. By attenuating the attention weights of unobservable fields with limited interfaces, it generates a node capability profile vector under limited conditions. Based on this vector, it outputs the predicted execution time and observable credibility score for each corresponding node in parallel. The assignment decision module divides nodes into high-credibility pool nodes and low-credibility pool nodes according to the observable credibility score. High-credibility pool nodes are assigned priority based on predicted execution time. For low-credibility pool nodes, the predicted execution time is risk-weighted based on their credibility score and then globally ranked with high-credibility nodes to determine whether to assign an exploratory task.

[0008] In summary, this application effectively addresses the structural feature gaps caused by system pruning in heterogeneous edge node clusters by introducing semantic labels to distinguish the reasons for missing hardware features and utilizing gated attention mechanisms and implicit feature compensation subnetworks in deep learning models. This solution not only eliminates the negative interference of zero-value padding on model profiling but also achieves accurate assessment and dynamic scheduling of lightweight node capabilities through risk-weighted assignment and closed-loop feedback optimization mechanisms. This significantly improves the overall load balancing capability and task execution efficiency of the cluster, effectively avoiding latency exceedances caused by a one-sided skew in task allocation towards high-end nodes. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating a cross-platform local device task execution method based on deep learning, provided as an embodiment of this application.

[0010] Figure 2 This is a schematic diagram of the structure of a cross-platform local device task execution system based on deep learning, provided as an embodiment of this application.

[0011] Labeling Explanation: 210, Data Acquisition Module; 220, Separation and Labeling Module; 230, Input Reconstruction Module; 240, Prediction and Evaluation Module; 250, Assignment and Decision Module. Detailed Implementation

[0012] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0014] Firstly, referring to Figure 1 This application provides a deep learning-based cross-platform local device task execution method, applied to a task allocator associated with a heterogeneous edge node cluster. The heterogeneous edge node cluster includes lightweight nodes running a trimmed operating system and high-end nodes with complete monitoring interfaces. The method includes the following steps: S1: Obtain the hardware characteristic values ​​and observable state information of each node; S2: Based on the observable state information and the hardware declaration list during the initial registration of the node, identify missing fields and distinguish them into interface-restricted unobservable fields and hardware-truthfully missing fields, and generate semantic tags for each field. S3: Concatenate the normalized hardware feature values, the mask indicating whether a field is missing, the source category state vector reflecting the semantic label, the node observation completeness scalar, and the target task requirement vector into a unified input tensor. S4: Input the unified input tensor into the deep learning model, and generate a node capability profile vector under the constraint by attenuating the attention weights of the interface-restricted unobservable fields. Based on the node capability profile vector, output the prediction execution time and observable credibility score of the corresponding node for the target task in parallel. S5: Based on the observable credibility score, each node is divided into a high credibility pool node and a low credibility pool node. High credibility pool nodes are assigned priority based on the predicted execution time. For low credibility pool nodes, the predicted execution time is weighted by risk based on their credibility score, and then globally ranked with the high credibility nodes to determine whether to assign a trial task.

[0015] A heterogeneous edge node cluster refers to a network cluster composed of various edge computing devices with different computing capabilities, hardware architectures, and operating systems. Nodes in this cluster can be high-performance edge servers equipped with multi-core processors, independent graphics processing units, and complete driver stacks, or lightweight gateways, industrial control terminals, or embedded box-type devices with only basic processors, limited memory, and trimmed system images. The term "heterogeneous" is reflected not only in differences in processor instruction sets, memory capacity, and accelerator types, but also in differences in monitoring interface exposure capabilities, driver installation completeness, permission models, and system file directory structures.

[0016] A streamlined operating system refers to an operating system that has been simplified and customized to suit lightweight devices with limited storage and computing resources. It typically removes infrequently used system components and advanced monitoring interfaces. This streamlining can manifest as deleting certain system directories, disabling specific kernel modules, removing diagnostic commands, disabling extended drivers, restricting user-mode access permissions, or retaining only the minimum runtime environment. The direct result is that while some hardware may physically exist and be capable of performing tasks, its operational status cannot be fully read through a unified interface.

[0017] A hardware declaration list is a static configuration file submitted by an edge node to the system during its initial cluster registration. It details all the hardware resources physically present on the node. This list can be generated from the device's factory configuration, maintenance registration information, initial network access self-test results, or a manually verified device specification table, and is bound to the node's unique identifier during the node registration phase. The list typically includes at least the processor model, number of cores, memory capacity, storage type, whether it includes a graphics processing unit (GPU), whether it includes a neural network processing unit (NNF), network interface type, and optional accelerator types. The purpose of this list is not to reflect dynamic load at a specific moment, but rather to serve as a static factual benchmark to answer the question "Does certain hardware physically exist?", thus providing a basis for subsequently distinguishing between "interface-restricted unobservable fields" and "truly missing hardware fields."

[0018] Specifically, a basic system query script can be deployed on the node to periodically read the system file directory to obtain hardware characteristic values ​​and record the boolean value indicating whether the read operation throws an exception, returning this as observable status information to the task allocator. To ensure stable implementation, the system query script can perform data collection actions item by item according to a predefined list of fields. Each item in the field list corresponds to a specific data source; for example, the current processor frequency can come from a processor frequency information file, available memory can come from the system memory statistics interface, graphics processing unit temperature can come from the temperature node exposed by the driver, and neural network processing unit utilization can come from the manufacturer's driver tools or device status files. For each field, the script first attempts to read the target path or call the target command; if a parsable result is successfully obtained, the value of the field is recorded and the boolean value is marked as successful; if an error occurs during the reading process, such as a non-existent path, an unexecutable command, insufficient permissions, an empty return value, or a return value that cannot be parsed into a valid value, the value position of the field is left empty, and the boolean value is marked as failed. Subsequently, the node sends all field results within the same sampling period, along with the node's unique identifier and sampling time, to the task allocator. The advantage of this approach is that even if the node has limited capabilities and cannot deploy complex proxies, it can still provide the most basic "value + whether it was successfully read" information at a low implementation cost, providing the first layer of evidence for subsequent semantic identification.

[0019] After receiving data, the task allocator compares the currently failed read fields with the static configuration file submitted during node registration. If the configuration file indicates that the node is equipped with a neural network processing unit, but the current read of the unit's utilization boolean value fails, the semantic label for that field is marked as "interface-restricted unobservable field." If the configuration file does not record the unit, it is marked as "hardware truly missing field." To further improve labeling accuracy, the task allocator can first align field names during comparison, mapping dynamically acquired field names to resource names in the hardware declaration list to a unified identifier. For example, when different names appear in dynamic fields such as "TPU utilization," "NPU utilization," and "AI accelerator load," they can first be mapped to the unified "neural network processing unit utilization" semantic item before performing an existence check. If a field is read successfully, it is directly marked as a "normal observation field." If a field fails to be read but the hardware declaration list confirms the existence of the hardware, it indicates that the failure is due to an interface, driver, permission, or system pruning, rather than the hardware not existing. If the hardware declaration list confirms the absence of the hardware, it indicates that the absence of that field has real physical meaning, and subsequent models should not treat it as an anomaly but rather as part of the node's capability boundary. Through this processing, the system separates two types of cases that were originally indistinguishable based solely on null values, enabling subsequent models to obtain more accurate contextual semantics at the input stage.

[0020] Hardware feature values ​​with different dimensions (such as memory bytes and processor utilization percentage) are normalized to their maximum and minimum values, mapping them to a unified numerical range. The maximum and minimum values ​​can be derived from pre-maintained feature range configurations or from stable ranges obtained from historical samples during training. If a field is missing in the current sample, its numerical position is filled with a placeholder value according to predetermined rules, while the mask and semantic labels jointly indicate that the placeholder value does not represent the actual measurement result. Simultaneously, a binary mask vector of the same length as the feature dimension is generated, with dimensions containing data marked as 1 and dimensions without data marked as 0. The normalized features, mask vector, state vector transformed from semantic labels, scalar representing the overall data completeness, and vector representing the task's computational power requirements are concatenated in a fixed dimensional order to form a high-dimensional unified input tensor, satisfying the requirement of deep learning models for fixed input dimensions. More specifically, the state vector after semantic label conversion can use discrete category encoding to represent the source category of different fields. For example, "normal observation fields," "interface-restricted unobservable fields," and "hardware-truthfully missing fields" can be mapped to different state identifiers, and then expanded in field order. The node observation completeness scalar is used to summarize the overall observability of the node within the current sampling period. It can be generated based on the coverage of successfully observed fields, allowing the model to quickly perceive the completeness level of the node's current input. The target task requirement vector describes the requirements of the task to be assigned regarding processor, memory, accelerator, bandwidth, or latency sensitivity. Through this concatenation method, the model can simultaneously see "what the node has," "what the node has currently observed," "what it hasn't observed," "why it hasn't been observed," and "what the task needs" in the same input, thus providing a complete context for subsequent capability profile generation.

[0021] Deep learning models internally include an attention computation module. When a unified input tensor enters the model, this module identifies dimensions in the source category state vector marked as "interface-restricted unobservable fields" and forces their corresponding attention weights to be multiplied by a very small decay coefficient. This "very small decay coefficient" means that the influence of this type of dimension in subsequent feature aggregation is significantly reduced, but it doesn't necessarily have to be completely zeroed out. This avoids the model mistaking placeholder values ​​caused by interface restrictions as true low values, while retaining a minimal amount of contextual traces to maintain input structure stability. This operation ensures that the zero or default values ​​filled in this dimension contribute almost no activation in subsequent forward propagation calculations, thus generating a node capability profile vector that excludes spurious zero-value interference. For dimensions marked as "hardware-truthfully missing fields," the model retains their "truly non-existent" semantics, not treating them as acquisition anomalies, but rather as part of the node resource boundary in profile construction. Based on this profile vector, the model's regression branch outputs the prediction execution time, while the classification or probability branch outputs an observable confidence score reflecting the reliability of the prediction. To make this step easier to implement, the model can learn from historical task data containing both complete observation samples and partially missing samples during the training phase. This allows the model to gradually build an internal representation capability that recognizes "the same null value, but with different semantics and therefore different processing methods." In this way, when encountering pruning system nodes online, the model will no longer directly reduce the node's capabilities to an unreasonable level due to the absence of several key fields. Instead, it can combine static declarations and other observed features to provide more robust execution time predictions.

[0022] A credibility threshold is set. Nodes with scores above this threshold enter the high-credibility pool and are directly assigned tasks based on their predicted execution time, from shortest to longest. For nodes in the low-credibility pool with scores below the threshold, their predicted execution time is divided by their observable credibility score (which ranges from 0 to 1). This means that when a node's predicted time appears short but its credibility is low, the system will proactively amplify the performance of that predicted time in the ranking to reflect potential uncertainty risks. For example, if a node's predicted execution time is T and its credibility score is C, and C is at a low level, the risk-weighted ranking time will be longer than the original predicted time; conversely, if another node's predicted execution time is slightly longer but its credibility is higher, it may rank higher in the global ranking. The amplified time is then combined with the times of the high-credibility pool nodes and sorted globally in ascending order. If the low-credibility node remains high after the ranking, it is assigned tasks with exploratory tags to explore its potential computing power while controlling risk. The "exploratory tasks" here are preferably inference requests with relatively high latency tolerance, rollback capability, retry capability, or small task size. Each task can be pre-marked as an exploratory task based on actual needs. After the exploratory task is completed, the system can write the actual execution results back to the training samples or online correction module to revise the node's subsequent capability profile and credibility score. In this way, low-credibility nodes are not permanently excluded, but rather gradually accumulate evidence of their actual performance under controlled conditions, thus having the opportunity to enter a higher-priority scheduling sequence.

[0023] Through the aforementioned overall technical solution, this application effectively addresses the feature gap problem caused by the pruning of lightweight node systems in heterogeneous edge node clusters. By introducing a hardware declaration list for semantic discrimination and combining it with attention weight decay processing within the deep learning model, the interference of invalid padding values ​​on the model's nonlinear activation function is fundamentally blocked, preventing the model from erroneously underestimating node capabilities. Furthermore, because the system explicitly distinguishes between "interface-restricted unobservable" and "true hardware deficiency," the model no longer treats all null values ​​as the same negative signal, but can adopt two different strategies: suppressing interference and preserving true constraints. In this way, even if a lightweight node's monitoring interface is incomplete, as long as its static hardware capabilities meet the task requirements, it can still be identified as a usable resource by the model. Simultaneously, the risk-weighted scheduling mechanism based on observability credibility scoring ensures both the efficient utilization of high-determinism nodes and the safe release of potential computing resources from lightweight nodes, thereby correcting the imbalance of task allocation unilaterally tilted towards high-end nodes at the global level, significantly improving the overall throughput of the cluster and ensuring the latency requirements of task execution. The underlying reason is that front-end semantic discrimination improves input quality, intermediate attention decay reduces the pollution of the profile by erroneous features, and back-end risk-weighted scheduling explicitly incorporates prediction uncertainty into the decision-making process. The three form a closed-loop collaboration from data collection and model inference to task assignment.

[0024] Optionally, step S1 includes: The system utilizes agent programs deployed on each node to call the system monitoring interface field by field to obtain hardware feature values ​​based on a pre-defined full hardware feature list, and simultaneously captures the status codes returned by the interface. Status codes are divided into three categories: normal codes indicating successful calls and valid data returns, error codes indicating failed calls, and invalid status codes indicating successful calls but returning empty strings or default placeholders. Error codes include those indicating file non-existence, command failure, or permission denial. The system receives a joint state raw data packet, which is generated by the agent program binding the hardware feature value of each field to its corresponding status code into a tuple, and encapsulating the tuples of all feature fields within the current sampling period, along with timestamps and unique node identifiers. Hardware feature values ​​are extracted from the joint state raw data packet, and status codes are extracted as observable state information.

[0025] In practice, the agent program initiates system calls one by one according to the full hardware feature list. For each field, the agent program can pre-configure one or more candidate acquisition methods and try to execute them in order of priority. For example, for a certain accelerator utilization field, it first tries to read the status file exposed by the driver; if this method is unavailable, it then tries to call the manufacturer's command-line tool; if it is still unavailable, it records the failure status. The reason for this design is that different operating systems and different driver versions may expose the same field in different ways, and using a candidate acquisition chain can improve cross-platform adaptability. When the call is successful and real data is obtained, a normal code is recorded; when the call triggers a system exception, the exception type is accurately captured and mapped to an error code. For example, if reading the target directory fails, if the directory does not exist, an error status representing "file does not exist" is recorded; if the system prompts that the command is not supported, an error status representing "command not implemented" is recorded; if the access is denied by the system, an error status representing "permission denied" is recorded; when the call process does not report an error but returns a meaningless empty string, fixed placeholder text, or an unparseable reserved value, an invalid status code is recorded. To avoid inconsistencies in native error representations across different operating systems, the agent program preferably maps the underlying return results to a unified set of status codes defined internally by the system. This set of status codes can be maintained using an enumeration table. The encapsulation format of the joint state raw data packet can be a structured text format, as long as it can stably express the correspondence between field names, field values, status codes, timestamps, and node identifiers. Furthermore, the refinement of status codes has a direct effect: the task allocator can subsequently distinguish between "long-term stable missing" and "intermittent read failures." The former is more likely related to system pruning or hardware absence, while the latter is more likely related to transient permissions, driver fluctuations, or sampling timing, thus providing additional evidence for subsequent reliability assessments.

[0026] Further, step S2 includes: After receiving the joint state raw data packet, the binary tuples in it are traversed one by one; for fields with normal status codes, their semantic labels are marked as normal observation fields; for fields with error codes or invalid status codes, they are determined as missing fields, and the hardware declaration list reported by the corresponding node during initial registration is queried: if the hardware corresponding to the field exists in the hardware declaration list, its semantic label is marked as interface-restricted unobservable field; if it does not exist, its semantic label is marked as hardware truly missing field.

[0027] In practice, the task allocator's parsing engine parses the tuples in the joint state raw data packets one by one. When encountering a tuple with a normal status code, it directly assigns the semantic label "normal observation field" and retains its value as a valid observation. When encountering a tuple with an error code or invalid status code, the parsing engine first determines the standard resource category corresponding to the field based on the field mapping table, and then retrieves the hardware declaration list corresponding to the node's unique identifier. If the hardware declaration list explicitly states that the device is equipped with this type of acceleration module, logically it can be determined that the current absence does not mean that the hardware does not exist, but rather that although the hardware exists, the current system environment cannot fully expose its operating state. Therefore, it is precisely labeled as an "interface-restricted unobservable field." Conversely, if the hardware declaration list does not record this type of hardware, it indicates that the absence of this field has a real physical meaning and should be labeled as a "truly missing hardware field." In some more detailed implementations, the parsing engine can also further record the absence reason notes in conjunction with the status code type. For example, within the category of "interface-restricted unobservable fields," a status code of "permission denied" indicates that the hardware exists but current permissions are insufficient; a status code of "command not implemented" or "file not found" more likely indicates system pruning or missing drivers. While this additional information does not change the classification of the three main semantic tags, it can serve as supplementary input for subsequent reliability scoring or operational diagnostics.

[0028] In some preferred embodiments, step S3 includes: Construct a normalized numerical feature vector with the same dimensions as the full hardware feature list. For normal observation fields, normalized hardware feature values ​​are filled into the corresponding dimensions of the normalized numerical feature vector. For missing fields, zero values ​​are uniformly filled into the corresponding dimensions of the normalized numerical feature vector. Construct a missing marker mask vector of the same length as the normalized numerical feature vector. In the missing marker mask vector, the dimensions corresponding to normal observation fields are set to 1, and the dimensions corresponding to missing fields are set to 0. For each feature dimension, perform one-hot encoding based on its semantic label. Flatten and concatenate all one-hot encodings of all dimensions to form a source category state vector. Calculate the proportion of the number of normal observation fields to the total number of dimensions in the full hardware feature list, and use it as a node observation completeness scalar. Concatenate the normalized numerical feature vector, missing marker mask vector, source category state vector, node observation completeness scalar, and target task requirement vector into a unified input tensor in a preset order.

[0029] In practical implementation, to eliminate the dimensional differences between different hardware indicators, the system constructs a normalized numerical feature vector, mapping all normally observed values ​​to a unified interval, while filling missing fields with zero values ​​as placeholders. This "full hardware feature list" can be predefined before system deployment and maintained consistently across all nodes to ensure a fixed input dimension. This list can be established by the control plane based on the types of hardware resources that may exist within the cluster, including fields such as CPU utilization, CPU idle rate, available memory, disk read / write bandwidth, network uplink bandwidth, network downlink bandwidth, GPU utilization, neural network processing unit utilization, video codec unit utilization, and edge storage cache hit rate. If a node of a certain type lacks a particular hardware feature, that field remains in the list, but its semantic label is marked as "truly missing hardware field." The purpose of this is to ensure that different types of nodes can ultimately be mapped to the same fixed-dimensional input space, avoiding the inability to uniformly train and infer models due to inconsistent input lengths.

[0030] In terms of information acquisition, the raw values ​​in the normalized numerical feature vector typically come from a node-side monitoring agent. This monitoring agent can be deployed on edge nodes as a daemon process, periodically calling operating system interfaces, container runtime interfaces, driver interfaces, or management commands provided by device manufacturers to obtain hardware status. For example, in one embodiment, the monitoring agent reads CPU utilization and memory availability through the operating system's system statistics interface, network throughput through the network interface statistics module, and GPU or neural network processing unit utilization through manufacturer driver commands. For containerized environments, container-level resource usage can also be obtained through the monitoring interface provided by the container runtime. The collected raw fields will be accompanied by a timestamp, node identifier, field name, and collection status code, with the status code used to assist in subsequent semantic annotation. To ensure the comparability of data from different nodes, the upper and lower limits required for normalization should also be pre-configured. For fields with a clear physical range, such as utilization metrics, stable intervals can be used directly for normalization; for absolute value fields such as memory capacity and disk bandwidth, mapping can be performed based on the effective range obtained from the training phase statistics. The "preset order" mentioned here also needs to be fixed before deployment. For example, it should always be concatenated in the order of "normalized numerical feature vector, missing marker mask vector, source category state vector, node observation completeness scalar, and target task requirement vector". This order should be written into the model input specification document and node-side encoding script to avoid input misalignment caused by inconsistent order during training and inference stages.

[0031] To prevent the model from mistaking these zero values ​​for true extremely low states, the system simultaneously constructs a vacancy marker mask vector, using binary 1s and 0s to explicitly indicate which dimensions contain valid data and which are invalid fillers. Furthermore, to help the model understand the physical reality behind the vacancy, the system performs one-hot encoding on the semantic labels, transforming discrete category states into continuous vector representations, which are then flattened to form the source category state vector. In addition, the system calculates a node observation completeness scalar, which serves as a macroscopic indicator, intuitively reflecting the overall reliability of the current node state data. Finally, the aforementioned multi-dimensional feature vectors are concatenated with a demand vector representing the computational power requirements of the target task in a fixed order to form a high-dimensional unified input tensor. This "target task demand vector" can also be obtained through a rule-based approach. In one feasible implementation, when submitting inference, streaming media processing, or data analysis tasks, the task submitter carries task description information, such as task category, target model size, input data resolution, target latency level, whether a neural network processing unit is needed, and whether a video encoding / decoding unit is needed. The scheduling system encodes these discrete or continuous task attributes to form the demand vector. For example, "video analysis task" can be mapped to a position in the task category encoding, "low latency requirement" can be mapped to a priority level field, and "needs neural network processing units" can be mapped to the corresponding resource requirement bit. In this way, the unified input tensor not only describes the current resource state of the node, but also explicitly injects the current target task's preference for resources, so that the node capability profile output by the model has clear task conditions.

[0032] In a preferred embodiment of this application, step S4 includes: A unified input tensor is input into a deep learning model, which generates node capability profile vectors as follows: The unified input tensor is decomposed into numerical feature vectors, mask vectors, state feature vectors, and a global completeness scalar; the numerical feature vectors are fed into the numerical feature processing branch, and a preliminary numerical feature map is generated through linear mapping; the mask vectors and state feature vectors are fed into the state processing branch, and contextual features of missing semantics are extracted through a multilayer perceptron; the global completeness scalar is used as a global context signal and input into a gated attention mechanism and an implicit feature compensation subnetwork; the gated attention mechanism generates attention weights for each feature dimension of the preliminary numerical feature map based on the semantic labels in the source category state vector; for normal observations... Fields and hardware-real missing fields maintain normal weights; unobservable fields with interface limitations are assigned attenuated weights to suppress their impact on forward propagation due to zero-filling, resulting in a modulated feature map; an implicit feature compensation subnetwork receives contextual features of missing semantics, dimensions of normally observed hardware features, node observation completeness scalar, and device type identifier to conservatively estimate the potential availability of hardware resources unobservable due to interface limitations, generating a compensation feature vector; the modulated feature map and the compensation feature vector are added element-wise and fused, and after mapping through a fully connected layer, a node capability profile vector is generated; based on the node capability profile vector, the predicted execution time and observable confidence score of the corresponding node for the target task are output in parallel.

[0033] In this specific implementation, the numerical feature processing branch can consist of one or more fully connected layers. Each layer can be followed by normalization processing and nonlinear activation to form a stable preliminary numerical feature map. The state processing branch can first concatenate the missing marker mask vector with the source category state vector, and then input it into a two- to three-layer multilayer perceptron to extract contextual patterns such as "which fields are missing," "what is the reason for the missing data," and "whether the missing data is concentrated on similar hardware." The "device type identifier" here can be obtained during the node registration phase. For example, when a node first joins the cluster, it reports information such as device model, processor architecture, whether it is equipped with a graphics processor, whether it is equipped with a neural network processing unit, and operating system pruning level. The scheduling control plane registers this as a static attribute of the node and stores it using discrete encoding or embedded encoding. During the inference phase, the device type identifier is read in association with the unified input tensor and then sent to the implicit feature compensation subnetwork. In this way, even if two nodes currently observe the same CPU utilization, as long as their device type identifiers are different, the compensation subnetwork can determine whether there is a significant difference in their potential unobservable hardware capabilities.

[0034] The core components are the gated attention mechanism and the implicit feature compensation subnetwork. The gated attention mechanism dynamically adjusts the weights of each feature dimension based on semantic labels. For normally observed and truly missing fields, their weights remain unchanged, allowing them to participate normally in forward propagation. For unobservable fields with limited interfaces, a very small decay weight is forcibly assigned, thereby directly suppressing the negative activation caused by filling in zero values ​​at the feature map level. Here, "maintaining normal weights" can be understood as allowing that dimension to participate in feature propagation in the usual way, rather than uniformly amplifying it; "assigning decay weights" can be implemented by a learnable gating unit, or it can be determined by a combination of semantic label-driven rule weights and learned weights.

[0035] Meanwhile, the implicit feature compensation subnetwork undertakes the task of capability restoration. This subnetwork does not rely on direct observed values, but rather comprehensively utilizes the context of missing semantics, other observed hardware states, overall observation completeness, and device type identifiers. Through the generalization ability of deep neural networks, it conservatively estimates the currently available computing power of unobservable hardware, generating compensation feature vectors. Here, "conservative estimation" emphasizes that its output should avoid excessive optimism, thereby reducing scheduling risk. In a specific training implementation, historical execution logs can be used to construct supervised samples: complete hardware states, task requirement information, and actual execution times are collected from nodes with full monitoring capabilities. Then, when manually constructing training samples, some accelerator fields are randomly masked according to common missing patterns in lightweight nodes, and the masked fields are marked as "interface-restricted unobservable fields," while retaining the original true labels as indirect learning references. During training, the model learns that when a certain type of device has low CPU load, sufficient memory, and historically often incorporates neural network processing units, even if the neural network processing unit utilization field is unobservable, it should not be simply considered as having no computing power. In this way, the implicit feature compensation subnetwork gains the ability to infer capabilities that are "missing but potentially usable". Finally, the feature map after attention modulation to remove interference is fused with the compensation feature vector that fills the gaps, element-wise, to generate a high-fidelity node capability profile vector. Element-wise addition is used here to ensure that the compensation information directly falls into the representation space corresponding to the original feature map, facilitating unified processing by subsequent fully connected layers. If a dimension of the compensation network output represents the potential capability of a certain type of unobservable acceleration resource, the result of the addition can simultaneously include the security suppression effect and capability compensation effect of that dimension.

[0036] After generating high-fidelity node capability profile vectors, the model needs to output the predicted execution time for the target task. However, due to varying degrees of missing input data, a single execution time prediction often fails to reflect the reliability of the prediction result. In actual scheduling, a prediction based on complete data carries entirely different potential risks compared to a prediction inferred from a large amount of missing data. Therefore, the model needs to be able to assess its own prediction uncertainty, i.e., output an observable reliability score, and the generation mechanism of this score needs to be able to directly capture the degree of missing input data. Here, the "observable reliability score" is neither a node hardware quality score nor a long-term reputation score, but rather a measure of "how reliable the current prediction result is under the existing observation conditions." In other words, the observable reliability score of the same node can be high when the monitoring interface is normal and the sampling is complete; however, if multiple key fields are missing in another sampling period, even if the node's physical capabilities remain unchanged, its observable reliability score for this prediction will decrease. In this way, the scheduling layer can distinguish between the two different issues of "the strength of the node itself" and "whether the current prediction is reliable."

[0037] In practical applications, the output layer of a deep learning model contains a first branch and a second branch in parallel. The parallel output of the prediction execution time and observable confidence score of the corresponding node for the target task based on the node capability profile vector includes: the first branch receives the node capability profile vector, outputs the prediction execution time after passing through a fully connected layer; the second branch receives the node capability profile vector, and jumps to connect the node observation integrity scalar and the variance features output by the state processing branch, outputs an observable confidence score between zero and one after nonlinear activation.

[0038] This specific implementation scheme constructs a dual-branch parallel output architecture. The first branch focuses on the regression task, mapping the high-dimensional node capability profile vector to specific prediction execution time values ​​through a fully connected layer. The second branch focuses on uncertainty assessment, receiving not only the deeply abstract node capability profile vector but also directly introducing a shallow node observation completeness scalar and variance features from the state processing branch output through skip connections. The variance features reflect the degree of dispersion of missing fields in the overall feature space. After concatenating these features, the second branch passes them through non-linear activation functions such as the Sigmoid function, outputting a probability value between zero and one as an observable confidence score. The "variance features output by the state processing branch" can be obtained by summarizing the dispersion, volatility, or distribution of state embeddings in each dimension within the state processing branch. Its purpose is not to pursue a strictly statistical definition of variance but to extract representations for confidence judgment, such as "whether the current missing pattern is concentrated," "whether key fields are missing in large areas," and "whether the state uncertainty is too high." In one implementation, after outputting context features, the state processing branch can also synchronously generate a set of auxiliary features to characterize the stability of the absence pattern. These auxiliary features are compressed and provided as variance features to the second branch.

[0039] The skip connection mechanism allows the credibility score calculation to no longer rely solely on deep features that may lose original missing information after multiple nonlinear transformations, but instead directly references the most intuitive completeness indicators and variance features. Each branch performs its specific function: the first branch ensures the accuracy of time prediction, and the second branch ensures the sensitivity of risk assessment. Its unique technical effect lies in preventing deep networks from losing global missing signals during backpropagation, enabling the model to accurately quantify the uncertainty caused by missing data, and providing extremely reliable numerical basis for subsequent risk-weighted scheduling.

[0040] After obtaining the predicted execution time and observable reliability score, traditional scheduling algorithms typically perform greedy allocation based on the predicted time. However, in heterogeneous edge node clusters, blindly trusting the predicted time of low-reliability nodes can lead to severe timeouts for critical tasks and violate system latency constraints if the prediction fails (e.g., the actual load of a node is much higher than the predicted value). Conversely, completely excluding low-reliability nodes to avoid risk can result in long-term idleness of lightweight nodes, wasting computing power. To achieve the optimal balance between scheduling risk and system throughput, a reliability-based hierarchical scheduling and risk-weighted mechanism needs to be designed to achieve differentiated allocation of nodes with different degrees of determinism. Here, the "dynamic reliability threshold" can be understood as a hierarchical threshold that adjusts with changes in the system's operating state, rather than a fixed constant. For example, when the system is currently carrying a large number of tasks with strong latency constraints, the reliability threshold can be appropriately increased to prioritize nodes with more robust predictions; when the system is in a stable load phase and there are many non-critical tasks that can be tested, the reliability threshold can be appropriately relaxed to release more lightweight nodes to participate in scheduling. The specific value of the dynamic threshold can be determined by the controller based on operational indicators such as the urgency of the task, the prediction error statistics over a recent period, and the overall health of the node pool.

[0041] Further, step S5 includes: A dynamic credibility threshold is set; nodes with observable credibility scores higher than the threshold are placed in a high-credibility candidate pool, sorted in ascending order of predicted execution time, and given priority in task assignment; nodes with observable credibility scores lower than the threshold are placed in a low-credibility candidate pool, and their predicted execution time is risk-weighted: the predicted execution time is divided by its observable credibility score to obtain the risk-weighted evaluation time; the nodes in the low-credibility candidate pool are then globally sorted in ascending order with the nodes in the high-credibility candidate pool based on their risk-weighted evaluation time; when a node in the low-credibility candidate pool wins in the global ranking, it is assigned a task carrying a tentative execution marker.

[0042] Specifically, the predicted execution time of a node is divided by its observable confidence score, which is between zero and one. Since the score is less than one, the division operation actively amplifies the predicted execution time of the node; the lower the score, the greater the amplification factor. This process is equivalent to imposing a risk penalty on the prediction results of low-confidence nodes, transforming them into a risk-weighted evaluation time that includes uncertainty costs. Subsequently, the risk-weighted evaluation times of low-confidence nodes are ranked globally in ascending order together with the original predicted times of high-confidence nodes. If a low-confidence node's evaluation time still ranks highly in the global ranking after the risk penalty, the system assigns it a task carrying a tentative execution flag. This "tentative execution flag" can be a task attribute issued by the scheduling system to the execution agent, used to differentiate the execution strategy for that task. For example, a task with this flag can be limited to a non-critical task, a retryable task, a task that allows timeout recovery, or a task that allows early reporting of interim results. Upon receiving this flag, the node-side execution agent can initiate finer-grained process monitoring and promptly report when the actual execution time of the task deviates significantly from the prediction. In this way, even if low-trust nodes participate in task execution, their trial-and-error costs are kept within an acceptable range. Dynamic trust thresholds can also be implemented using configuration tables, for example, by setting different ranges based on task level: higher thresholds for high-real-time tasks, medium thresholds for ordinary inference tasks, and lower thresholds for background asynchronous tasks. The controller reads the current task type and system congestion status before each scheduling, and selects the corresponding threshold from the configuration table, eliminating the need for complex calculations.

[0043] The model's output credibility score is explicitly transformed into a time penalty factor in scheduling decisions, achieving quantitative hedging of risk and reward through mathematical transformation. A high-credibility pool safeguards the basic scheduling structure, ensuring efficient utilization of high-determinism nodes; while a risk-weighted mechanism provides a controlled participation channel for low-credibility nodes. The close coordination of these technical features ensures that the system neither blindly assigns critical tasks to low-credibility nodes when observational evidence is insufficient, nor outright rejects lightweight nodes due to missing fields. Simultaneously, by assigning exploratory tasks, the system can gradually collect real execution feedback from low-credibility nodes within a controlled trial-and-error cost range, providing valuable closed-loop data for subsequent online model fine-tuning and credibility correction.

[0044] In order to achieve online adaptive optimization of the deep learning model, after assigning exploratory tasks to low-confidence nodes, this application further proposes a closed-loop feedback and parameter update mechanism. Specifically, after dispatching the exploratory task, the process also includes: receiving the actual execution time returned by the receiving node after executing the exploratory task, and local state fluctuation indicators synchronously collected by the node-side agent program during task execution; local state fluctuation indicators include the difference between the maximum and minimum CPU utilization and the system context switching frequency; comparing the local state fluctuation indicators with a preset stable baseline threshold: if any local state fluctuation indicator exceeds its corresponding stable baseline threshold, the execution is determined to be a disturbed feedback, and the backpropagation calculation process is prohibited; if all local state fluctuation indicators do not exceed their corresponding stable baseline thresholds, the execution is determined to be a stable feedback, and it is stored in the sliding feedback aggregation pool corresponding to the node; when the number of stable feedbacks collected in the sliding feedback aggregation pool reaches the preset capacity, the actual execution time corresponding to all stable feedbacks in the pool is truncated and averaged to obtain the aggregated actual time; the aggregated prediction deviation is calculated based on the average of the aggregated actual time and the predicted execution time of the corresponding batch; using the aggregated prediction deviation, the compensation weights of the implicit feature compensation subnetwork and the parameters of the gating attention mechanism are updated through backpropagation.

[0045] The node-side agent performs high-frequency sampling during task execution, recording the range of CPU utilization (i.e., the difference between the maximum and minimum values) and the frequency of system context switching. These two metrics accurately characterize the stability of the underlying system during task execution. After the task is completed, the node sends the actual execution time and local state fluctuation metrics back to the task allocator.

[0046] After receiving the feedback data, the task allocator performs strict feedback quality filtering. Local state fluctuation indicators are compared with preset stability baseline thresholds. If any indicator exceeds the threshold, it indicates that the task encountered severe resource contention or system jitter during execution, and the actual execution time in this case cannot objectively reflect the node's true capabilities. Therefore, the system classifies this feedback as disturbed feedback and discards it, prohibiting it from entering the backpropagation calculation process. Only when all indicators are within the stability baseline thresholds is it considered stable feedback and stored in the node's dedicated sliding feedback aggregation pool. Furthermore, to eliminate possible random errors in individual stable feedback, the system does not update parameters for individual feedback. Instead, it waits for the sliding feedback aggregation pool to fill a preset capacity (e.g., after collecting a certain number of stable feedbacks) before performing a truncated average calculation on the actual execution times within the pool. This involves removing the highest and lowest extreme values ​​and then averaging the results to obtain a highly reliable aggregated actual execution time. Subsequently, the aggregation prediction deviation between the actual aggregation time and the average predicted execution time of the corresponding batch is calculated, and this deviation is used as a loss signal to update the compensation weights of the implicit feature compensation subnetwork and the parameters of the gated attention mechanism through the backpropagation algorithm.

[0047] In the actual operation of heterogeneous edge node clusters, in addition to routine task assignment and feedback updates, the system may also face extreme anomalies such as node disconnection, extremely sparse information, or continuous instability. To address this, this application further proposes a multi-dimensional anomaly fallback and circuit breaker mechanism. Specifically, the method also includes: If no joint state raw data packet is received from the same node within multiple consecutive sampling periods, the node is determined to be in a completely unobservable state, triggering a timeout interruption and temporarily removing the node from the high-confidence candidate pool and the low-confidence candidate pool. If the node observation completeness scalar reported by a node is lower than the preset minimum tolerance threshold, the node is determined to be too sparse, bypassing the inference process of the deep learning model and triggering a fallback scheduling branch. The fallback scheduling branch assigns latency-insensitive background batch processing tasks to the node based on the static capacity declared during the node's initial registration and the historical average throughput through a weighted round-robin method. If the feedback reported by a node within a consecutive preset time window is all disturbed feedback, causing the sliding feedback aggregation pool to fail to fill within the set time, the node is determined to be in a period of continuous instability. Feedback collection from the node is suspended, the parameters of the deep learning model for the node are not updated, and the upper limit of the observable confidence score of the node is forcibly lowered. The assignment of new exploratory tasks to the node is restricted until the local state fluctuation index of the node recovers to within the stable baseline threshold.

[0048] This specific implementation plan addresses three common extreme anomalies in edge computing scenarios, each with its own specific handling strategy. The first scenario involves node disconnection or agent program crashes. When the task allocator fails to receive the raw data packet of a node's joint state within multiple consecutive sampling periods, it indicates that the node has fallen out of monitoring view. In this case, the system immediately triggers a timeout interrupt, removing the node from the candidate pool to prevent the scheduling algorithm from blindly dispatching tasks to disconnected nodes, thereby avoiding widespread task timeout failures.

[0049] The second scenario addresses situations where node information is extremely sparse. When the node observation completeness scalar reported by a node falls below a preset minimum tolerance threshold, it means that most dimensions of the input tensor are filled with zero values. Under such extreme scarcity, even if the deep learning model possesses attention decay and feature compensation capabilities, the generated node capability profile lacks sufficient contextual support, making predictions highly prone to failure. Therefore, the system decisively bypasses the deep learning model's inference process and triggers a fallback scheduling branch. This fallback scheduling branch no longer relies on dynamic features but instead reverts to making decisions based on the static capacity declared during the node's initial registration and its historical average throughput. Through a simple weighted round-robin approach, it assigns latency-insensitive background batch processing tasks to the node. This degradation process ensures that extremely sparse nodes are not completely idle while avoiding the high latency risk associated with them undertaking critical inference tasks.

[0050] The third scenario addresses nodes operating under sustained high pressure or experiencing frequent fluctuations. If a node sends back only disturbed feedback within a preset time window, causing the sliding feedback aggregation pool to remain unfilled for an extended period, it indicates that the node is currently in a period of sustained instability. In this case, the system not only suspends the collection of feedback and the updating of model parameters from this node to prevent low-quality data from contaminating the model, but also forcibly lowers the upper limit of the node's observable reliability score. This circuit breaker operation directly limits the node's competitiveness in global ranking, thereby significantly reducing or stopping the assignment of new exploratory tasks to it, giving the node breathing room to recover until its local state fluctuation indicators fall back below the stable baseline threshold.

[0051] Secondly, referring to Figure 2 This application also discloses a deep learning-based cross-platform local device task execution system, applied to a task allocator associated with a heterogeneous edge node cluster, to execute any of the above method steps. The heterogeneous edge node cluster includes lightweight nodes running a trimmed operating system and high-end nodes with complete monitoring interfaces. The system includes: The acquisition module 210 is used to acquire the hardware characteristic values ​​and observable status information of each node; The separation labeling module 220 is used to identify missing fields based on the observable state information and the hardware declaration list at the time of initial node registration, and to distinguish the missing fields into interface-restricted unobservable fields and hardware-truthfully missing fields, and generate semantic labels for each field. The input reconstruction module 230 is used to concatenate the normalized hardware feature values, the mask indicating whether the field is missing, the source category state vector reflecting the semantic label, the node observation completeness scalar and the target task requirement vector into a unified input tensor. The prediction and evaluation module 240 is used to input the unified input tensor into the deep learning model, generate a node capability profile vector under the constraint conditions by attenuating the attention weights of the interface-restricted unobservable fields, and output the prediction execution time and observable credibility score of each corresponding node for the target task in parallel based on the node capability profile vector. The assignment decision module 250 is used to divide each node into high-confidence pool nodes and low-confidence pool nodes according to the observable confidence score. High-confidence pool nodes are assigned priority based on the predicted execution time. For low-confidence pool nodes, the predicted execution time is risk-weighted based on their confidence score and then globally ranked with high-confidence nodes to determine whether to assign exploratory tasks.

[0052] Through the aforementioned technical solution, this system effectively addresses the feature gap problem caused by lightweight node system pruning in heterogeneous edge node clusters through the close collaboration of its various functional modules. The acquisition module 210 and the separation and annotation module 220 achieve deep semantic identification of missing data at the source; the input reconstruction module 230 and the prediction and evaluation module 240 utilize the attention modulation and implicit feature compensation mechanisms within the deep learning model to fundamentally prevent the interference of invalid padding values ​​on the model's nonlinear activation function, thus preventing an erroneous underestimation of the capabilities of lightweight nodes; the assignment decision module 250, through a risk-weighted scheduling mechanism, safely releases the potential computing resources of lightweight nodes while strictly ensuring task execution latency requirements. Overall, this system corrects the imbalance of task allocation unilaterally tilted towards high-end nodes at the global level, significantly improving the overall throughput of the cluster and ensuring the stability of task execution.

[0053] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A deep learning-based cross-platform local device task execution method, applied to a task allocator associated with a heterogeneous edge node cluster, wherein the heterogeneous edge node cluster includes lightweight nodes running a trimmed operating system and high-end nodes with complete monitoring interfaces, characterized in that... The method includes: S1: Obtain the hardware characteristic values ​​and observable state information of each node; S2: Based on the observable state information and the hardware declaration list during the initial registration of the node, identify missing fields and distinguish them into interface-restricted unobservable fields and hardware-truthfully missing fields, and generate semantic tags for each field. S3: Concatenate the normalized hardware feature values, the mask indicating whether a field is missing, the source category state vector reflecting the semantic label, the node observation completeness scalar, and the target task requirement vector into a unified input tensor. S4: Input the unified input tensor into the deep learning model, and generate a node capability profile vector under the constraint by attenuating the attention weights of the interface-restricted unobservable fields. Based on the node capability profile vector, output the prediction execution time and observable credibility score of the corresponding node for the target task in parallel. S5: Based on the observable credibility score, each node is divided into a high credibility pool node and a low credibility pool node. High credibility pool nodes are assigned priority based on the predicted execution time. For low credibility pool nodes, the predicted execution time is weighted by risk based on their credibility score, and then globally ranked with the high credibility nodes to determine whether to assign a trial task.

2. The method for cross-platform local device task execution based on deep learning according to claim 1, characterized in that, Step S1 includes: Using the agent program deployed on each node, the system monitoring interface is called field by field to obtain hardware feature values ​​based on the preset full hardware feature list, and the status code returned by the interface is captured synchronously. The status codes are divided into the following three categories: normal codes indicating successful call and return of valid data, error codes indicating failed call, and invalid status codes indicating successful call but return of an empty string or a default placeholder; the error codes include status codes indicating that the file does not exist, the command was not implemented, or the permission was denied; The agent program receives and sends a joint state raw data packet, which binds the hardware feature value of each field to the corresponding status code into a tuple, and encapsulates the tuples of all feature fields in the current sampling period together with the timestamp and the node's unique identifier. The hardware feature value is extracted from the joint state raw data packet, and the status code is extracted as the observable state information.

3. The method for cross-platform local device task execution based on deep learning according to claim 2, characterized in that, Step S2 includes: After receiving the original data packet of the joint state, the tuples in it are traversed one by one; For fields with normal status codes, their semantic labels are marked as normal observation fields; For fields with error codes or invalid status codes, they are identified as missing fields, and the hardware declaration list reported by the corresponding node during initial registration is queried: if the hardware corresponding to the field exists in the hardware declaration list, its semantic tag is marked as an interface-restricted unobservable field; if it does not exist, its semantic tag is marked as a hardware-truthfully missing field.

4. The method for cross-platform local device task execution based on deep learning according to claim 1, characterized in that, Step S3 includes: Construct a normalized numerical feature vector with the same dimensions as the full hardware feature list, wherein: for normal observation fields, normalized hardware feature values ​​are filled into the corresponding dimensions of the normalized numerical feature vector; for missing fields, zero values ​​are uniformly filled into the corresponding dimensions of the normalized numerical feature vector. Construct a missing marker mask vector of the same length as the normalized numerical feature vector, wherein: the dimension of the missing marker mask vector corresponding to the normal observation field is set to 1, and the dimension of the missing field is set to 0; For each feature dimension, one-hot encoding is performed based on its semantic label. The one-hot encodings of all dimensions are flattened and concatenated to form the source category state vector. The proportion of the number of normal observation fields to the total number of dimensions of the full hardware feature list is calculated and used as a scalar of the node observation completeness. The normalized numerical feature vector, the missing marker mask vector, the source category state vector, the node observation completeness scalar, and the target task requirement vector are concatenated in a preset order to form the unified input tensor.

5. The method for cross-platform local device task execution based on deep learning according to claim 2, characterized in that, Step S4 includes: The unified input tensor is input into the deep learning model, which then generates the node capability profile vector in the following manner: The unified input tensor is decomposed into numerical feature vectors, mask vectors, state feature vectors, and a global integrity scalar; The numerical feature vector is fed into the numerical feature processing branch, and a preliminary numerical feature map is generated through linear mapping. The mask vector and the state feature vector are fed into the state processing branch, and the context features of the missing semantics are extracted by the multilayer perceptron. The global integrity scalar is used as a global context signal and input to the gated attention mechanism and the implicit feature compensation subnetwork. The gating attention mechanism generates attention weights for each feature dimension of the preliminary numerical feature map based on the semantic labels in the source category state vector: normal weights are maintained for normally observed fields and fields with real hardware missing values; and attenuation weights are assigned to unobservable fields with interface limitations to suppress their influence on forward propagation due to zero-value padding, thus obtaining a modulated feature map. The implicit feature compensation subnetwork receives the context features of the missing semantics, the dimensions of normally observed hardware features, the node observation completeness scalar, and the device type identifier, and conservatively estimates the potential availability of hardware resources that are unobservable due to interface limitations, generating a compensation feature vector. The modulated feature map and the compensated feature vector are added and fused element by element, and after mapping through a fully connected layer, the node capability profile vector is generated. Based on the node capability profile vector, the predicted execution time and observable reliability score of the corresponding node for the target task are output in parallel.

6. The method for cross-platform local device task execution based on deep learning according to claim 5, characterized in that, The output layer of the deep learning model contains a first branch and a second branch in parallel. The parallel output of the predicted execution time and observable reliability score of the corresponding node for the target task based on the node capability profile vector includes: The first branch receives the node capability profile vector, which is then processed by a fully connected layer to output the predicted execution time. The second branch receives the node capability profile vector and makes a jump connection between the node observation completeness scalar and the variance feature output by the state processing branch. After nonlinear activation, the observable confidence score, which is between zero and one, is output.

7. A cross-platform local device task execution method based on deep learning according to claim 5, characterized in that... Step S5 includes: Set dynamic credibility thresholds; Nodes with observable confidence scores higher than the confidence threshold are included in the high confidence candidate pool, sorted in ascending order of predicted execution time, and assigned tasks with priority. Nodes with observable confidence scores lower than the confidence threshold are classified into a low confidence candidate pool, and their predicted execution time is risk-weighted: the predicted execution time is divided by its observable confidence score to obtain the risk-weighted evaluation time. The nodes in the low-confidence candidate pool are sorted globally in ascending order with the nodes in the high-confidence candidate pool based on the aforementioned risk-weighted evaluation time. When a low-confidence candidate node wins in the global ranking, it is assigned a task carrying a tentative execution flag.

8. The method for cross-platform local device task execution based on deep learning according to claim 5, characterized in that, After assigning exploratory tasks, the following also applies: The receiver returns the actual execution time after the node performs the exploratory task, as well as the local state fluctuation indicators synchronously collected by the node-side agent program during task execution; the local state fluctuation indicators include the difference between the maximum and minimum values ​​of the central processing unit utilization and the system context switching frequency; The local state fluctuation indicators are compared with preset stable baseline thresholds: if any local state fluctuation indicator exceeds its corresponding stable baseline threshold, the execution is determined to be a disturbed feedback, and the backpropagation calculation process is prohibited; if all local state fluctuation indicators do not exceed their corresponding stable baseline thresholds, the execution is determined to be a stable feedback, and it is stored in the sliding feedback aggregation pool corresponding to the node; when the number of stable feedbacks collected in the sliding feedback aggregation pool reaches the preset capacity, the actual execution time corresponding to all stable feedbacks in the pool is truncated and averaged to obtain the aggregated actual execution time; the aggregated prediction deviation is calculated based on the average of the aggregated actual execution time and the predicted execution time of the corresponding batch; using the aggregated prediction deviation, the compensation weights of the implicit feature compensation subnetwork and the parameters of the gated attention mechanism are updated through backpropagation.

9. A cross-platform local device task execution method based on deep learning according to claim 8, characterized in that, The method also includes: if no joint state raw data packet of the same node is received within multiple consecutive sampling periods, the node is determined to have entered a completely unobservable state, triggering a timeout interrupt, and the node is temporarily removed from the high confidence candidate pool and the low confidence candidate pool. If the node observation completeness scalar reported by a node is lower than the preset minimum tolerance threshold, the node information is determined to be too sparse, the inference process of the deep learning model is bypassed, and the fallback scheduling branch is triggered. The fallback scheduling branch assigns latency-insensitive background batch processing tasks to the node through a weighted round-robin method based on the static capacity and historical average throughput declared when the node is initially registered. If a node reports only disturbed feedback within a consecutive preset time window, causing the sliding feedback aggregation pool to fail to fill within a set time, the node is determined to be in a period of continuous instability. Feedback collection from the node is suspended, the parameters of the deep learning model for the node are not updated, the upper limit of the observable confidence score of the node is forcibly lowered, and new exploratory tasks are restricted from being assigned to the node until the local state fluctuation index of the node recovers to within the stable baseline threshold.

10. A deep learning-based cross-platform local device task execution system, applied to a task allocator associated with a heterogeneous edge node cluster, to execute the steps of the deep learning-based cross-platform local device task execution method according to any one of claims 1-9, wherein the heterogeneous edge node cluster comprises lightweight nodes running a trimmed operating system and high-end nodes with complete monitoring interfaces, characterized in that, The system includes: The acquisition module is used to obtain the hardware characteristic values ​​and observable status information of each node; The separation and labeling module is used to identify missing fields based on the observable state information and the hardware declaration list at the time of initial node registration, and to distinguish the missing fields into interface-restricted unobservable fields and hardware-truthfully missing fields, and generate semantic labels for each field. The input reconstruction module is used to concatenate the normalized hardware feature values, the mask indicating whether the field is missing, the source category state vector reflecting the semantic label, the node observation completeness scalar, and the target task requirement vector into a unified input tensor. The prediction and evaluation module is used to input the unified input tensor into the deep learning model, and generate a node capability profile vector under constrained conditions by attenuating the attention weights of the unobservable fields with limited interfaces. Based on the node capability profile vector, it outputs the predicted execution time and observable credibility score of each corresponding node for the target task in parallel. The assignment decision module is used to divide each node into high credibility pool nodes and low credibility pool nodes according to the observable credibility score. High credibility pool nodes are assigned priority based on predicted execution time. For low credibility pool nodes, the predicted execution time is risk-weighted based on their credibility score and then globally ranked with high credibility nodes to determine whether to assign an exploratory task.

Images