Power grid multi-source dense state reasoning task scheduling method and device, storage medium and computer equipment

Abstract

The power grid multi-source confidential state reasoning task scheduling method, device, storage medium and computer equipment provided by the application, the method comprises: determining a to-be-processed confidential state reasoning task facing power grid multi-source data; determining a priority according to the alarm level, business importance, waiting time and additional confidential state calculation cost of the to-be-processed confidential state reasoning task, and determining an execution path according to the remaining waiting time of the to-be-processed confidential state reasoning task; selecting an available key profile according to the key profile corresponding to the target model version and the execution path of the to-be-processed confidential state reasoning task; determining the comprehensive cost of the batch set where the to-be-processed confidential state reasoning task is located according to the available key profile, and performing confidential state reasoning on the to-be-processed confidential state reasoning task according to the comprehensive cost and the priority. Thus, under the premise of not leaking original power grid business data, the scheduling adaptability of the multi-source data confidential state reasoning task is realized.

Description

Technical Field

[0001] This application relates to the fields of privacy-preserving machine learning and dense-state computing technology, and in particular to a method, apparatus, storage medium and computer equipment for scheduling multi-source dense-state inference tasks in power grids. Background Technology

[0002] In intelligent operation and maintenance and digital dispatching of power grids, field terminals, inspection robots, drones, online monitoring devices, and edge gateways continuously generate multi-source data, including visible light images, infrared thermal images, partial discharge signals, vibration waveforms, voltage and current time series, equipment ledgers, and user energy consumption. This data involves sensitive information such as equipment status, defect modes, and operating loads. Directly uploading this data to the cloud or third-party platforms poses risks of data leakage and unauthorized analysis. Fully homomorphic encryption supports direct addition, multiplication, and rotation operations on ciphertext, providing a secure reasoning path for power grid data that requires no decryption.

[0003] Existing research has proposed various methods for ciphertext packing, homomorphic convolution, and approximate activation function optimization for convolutional neural networks, temporal networks, and lightweight models, and has achieved batch inference applicable to general image classification, reducing the overhead of rotation key and homomorphic operations to some extent. However, these methods are mainly geared towards fixed model structures and general datasets, and do not consider the dynamic changes in power grid operations, lacking adaptive adjustment capabilities.

[0004] Therefore, the core technical problem that the existing technology has not yet solved is how to achieve the adaptability of dense-state inference task scheduling for multi-source data without exposing the original power grid business data. Summary of the Invention

[0005] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiency in the prior art regarding how to achieve adaptability in dense-state inference task scheduling of multi-source data without exposing the original power grid business data.

[0006] Firstly, this application provides a method for scheduling multi-source dense-state reasoning tasks in a power grid, the method comprising:

[0007] Identify the dense-state inference task to be processed for multi-source data from the power grid;

[0008] Priority is determined based on the alarm level, business importance, waiting time, and additional dense state computation cost of the pending dense state inference tasks, and the execution path is determined based on the remaining waiting time of the pending dense state inference tasks.

[0009] Select an available key file based on the key configuration file corresponding to the target model version and execution path of the secret inference task to be processed;

[0010] Based on the available key archive, determine the overall cost of the batch set containing the secret reasoning task to be processed, and perform secret reasoning on the secret reasoning task to be processed according to the overall cost and priority.

[0011] In one embodiment, prioritization is determined based on the alarm level, business importance, elapsed waiting time, and additional dense computation cost of the pending dense inference task, including:

[0012] Based on the alarm level, business importance, and waiting time of the pending dense inference task, determine the alarm level score, business importance score, and task waiting time score.

[0013] Determine the pre-defined weights for alarm level score, business importance score, task waiting time score, and additional dense state calculation cost, and calculate the priority.

[0014] In one embodiment, determining the execution path based on the remaining wait time of the pending dense-state inference task includes:

[0015] Calculate the remaining waiting time based on the current time and the arrival time of the pending closed-state inference task;

[0016] When the remaining waiting time is less than a preset threshold, select the low-latency execution path;

[0017] When the remaining waiting time is not less than the preset threshold, and the number of similar tasks of the pending dense inference task reaches the batch processing threshold, a high-throughput execution path is selected.

[0018] In one embodiment, an available key profile is selected based on the key configuration profile corresponding to the target model version and execution path of the secret inference task to be processed, including:

[0019] Determine the key configuration profile based on the target model version and execution path of the secret inference task to be processed;

[0020] In the key configuration file, select a set of candidate key files that meet the reasoning correctness requirements of the secret reasoning task to be processed;

[0021] Select an available key file from the candidate key file set based on the current key cache status.

[0022] In one embodiment, selecting an available key file from the candidate key file set according to the current key cache state includes:

[0023] If the alarm level of the secret reasoning task to be processed is an emergency alarm, then according to the current key cache status, select the file with the most cached keys and the lowest startup overhead from the candidate key file set as the available key file.

[0024] Otherwise, based on the current key cache status, select the file with the smallest incremental transmission amount from the candidate key file set as the candidate file, and when the candidate file exceeds the terminal key budget, determine the available key file according to the preset degradation processing strategy.

[0025] In one embodiment, determining the overall cost of the batch set containing the secret reasoning task to be processed, based on the available key archive, includes:

[0026] The corresponding batch set is determined based on the data modality, target model version, input size, priority, and remaining waiting time of the dense inference task to be processed;

[0027] Based on the available key archive, determine the amount of new key transfers for the batch set;

[0028] Determine the expected inference latency, execution node load, and ciphertext slot utilization for the batch set;

[0029] The overall cost is calculated based on the weights corresponding to the expected inference latency, the amount of new key transmissions, the execution node load, and the ciphertext slot utilization.

[0030] In one embodiment, performing dense reasoning on the dense reasoning task to be processed, based on comprehensive cost and priority, includes:

[0031] When the overall cost of the batch set is minimized and the task delay constraint is satisfied, the corresponding node is selected for dense inference based on the priority of the dense inference task to be processed.

[0032] Secondly, this application provides a power grid multi-source dense-state inference task scheduling device, the device comprising:

[0033] The dense-state inference task determination module is used to determine the dense-state inference tasks to be processed for multi-source data from the power grid.

[0034] The execution path determination module is used to determine the priority of the pending cryptic reasoning task based on its alarm level, business importance, waiting time, and additional cryptic computation cost, and to determine the execution path based on the remaining waiting time of the pending cryptic reasoning task.

[0035] The available key file selection module is used to select an available key file based on the key configuration file corresponding to the target model version and execution path of the secret inference task to be processed.

[0036] The secret reasoning execution module is used to determine the overall cost of the batch set of secret reasoning tasks to be processed based on the available key archive, and to perform secret reasoning on the secret reasoning tasks to be processed based on the overall cost and priority.

[0037] Thirdly, this application provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of any of the power grid multi-source dense state inference task scheduling methods described in the above embodiments.

[0038] Fourthly, this application provides a computer device, including: one or more processors, and a memory;

[0039] The memory stores computer-readable instructions, which, when executed by one or more processors, perform the steps of any of the power grid multi-source dense state inference task scheduling methods described in the above embodiments.

[0040] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0041] The power grid multi-source dense-state inference task scheduling method, apparatus, storage medium, and computer equipment provided in this application firstly integrate the dense-state inference tasks to be processed into a dense-state computing framework for the scenario of multi-source heterogeneous data in the power grid, avoiding direct access to the raw data; secondly, it determines the priority of the dense-state inference tasks by comprehensively considering the alarm level, business importance, waiting time, and additional dense-state computing cost, and divides the execution path according to the remaining waiting time, thereby dynamically adapting the timeliness and resource constraints of the tasks in the dense-state environment; thirdly, it matches the corresponding key configuration file based on the target model version and execution path to ensure that the keys under different models and different security policies are independent and controllable, supporting the isolation and parallelism of heterogeneous tasks; finally, it evaluates the comprehensive cost of the batch set where the task belongs through the available key file, and performs dense-state inference in combination with the priority, so that the scheduling decision takes into account both the overall computing overhead and the urgency of the task. Thus, without disclosing the original power grid business data, flexible scheduling and adaptive path selection for multi-source heterogeneous dense state reasoning tasks are achieved, reducing the additional waiting and key management conflicts introduced by dense state calculation, improving the response timeliness of high alarm level and high business importance tasks, and optimizing batch processing efficiency through comprehensive cost evaluation, thereby enhancing the privacy security and scheduling adaptability of multi-source data collaborative reasoning in the power grid. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 A flowchart illustrating the power grid multi-source dense-state inference task scheduling method provided in this application embodiment;

[0044] Figure 2 This is a schematic diagram of the structure of the power grid multi-source dense state reasoning task scheduling device provided in the embodiments of this application;

[0045] Figure 3 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0046] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] This application provides a method for scheduling multi-source dense-state inference tasks in a power grid. The following embodiments illustrate this method using a computer device as an example. It is understood that the computer device can be any device with data processing capabilities, including but not limited to a single server, server cluster, personal laptop, desktop computer, etc. Figure 1 As shown, the method may include the following steps:

[0048] S101: Define the dense state inference task to be processed for multi-source data of the power grid.

[0049] Among them, multi-source power grid data refers to power grid operation data from different power business systems, different acquisition terminals, and different data formats, including but not limited to measurement data from smart meters, switch status data from distribution automation systems, alarm data from fault indicators on transmission lines, and environmental data released by meteorological monitoring systems. A pending dense-state inference task refers to the smallest logical unit that requires performing one or a set of dense-state inference calculations on the multi-source power grid data. Each pending dense-state inference task corresponds to a specific target model version and a type of expected output inference result.

[0050] In the specific implementation process, the first step is to retrieve a batch of job requests waiting to be scheduled from the task queue. For each job request, the data source identifier, model identifier, and business description information it carries are parsed, and it is checked whether the original data referenced by the request has been converted to encrypted state. Since data acquisition in the power grid environment is continuous and heterogeneous, multiple data channels are periodically scanned, and newly arriving telemetry, telesignaling, and alarm records are classified and summarized according to time windows and business domains. When a data combination is detected to meet the triggering conditions, such as multiple measuring points in a substation simultaneously experiencing abnormal jumps, a pending encrypted state inference task is automatically generated and attached to the waiting queue. To ensure the integrity and traceability of encrypted state inference tasks, each pending encrypted state inference task is assigned a globally unique task identifier upon determination. This identifier records the source business system of the task, the data time segment, and the expected model version to be used. In addition, the system verifies whether the input data required for the task is complete and in a valid encrypted state. If any missing data or mismatched encrypted parameters are found, the task will not be included in the subsequent priority calculation. Instead, the data completion or key negotiation process will be triggered, and the task will be officially confirmed as a schedulable encrypted reasoning task once the conditions are met.

[0051] For example, a unified description of a multi-source dense-state reasoning task for a power grid is established. Let the set of tasks to be processed be... For any task Generate its task metadata ,in Indicates a site or area identifier. Indicates the device type. Representing data modality, Indicates the business alarm level. Indicates the maximum allowed inference delay. This indicates the terminal's available key transmission budget. Indicates the current key cache state of the terminal or edge node. This indicates the target model version. For different data modalities, it is converted into a unified dense tensor. This allows visible light images, infrared spectra, one-dimensional time-series data, and spectral data to all enter the same scheduling framework. For multiple source inputs from the same device, it can be represented as:

[0052] ;

[0053] in, , and These represent the visible light image tensor, the infrared spectrum tensor, and the time-series monitoring tensor, respectively.

[0054] It should be noted that identifying the dense-state inference tasks to be processed from multi-source power grid data is to transform the original power grid data, which is originally scattered across different business systems and has various formats, into clearly defined work units that the scheduler can recognize and operate. This avoids unclear task boundaries or duplicate scheduling caused by diverse data sources and modalities, ensuring that each dense-state inference task has a clear input range, target model, and dense-state data associations before entering the scheduling process, thereby improving the accuracy and adaptability of scheduling decisions.

[0055] S102: Determine the priority based on the alarm level, business importance, waiting time, and additional dense state calculation cost of the pending dense state inference task, and determine the execution path based on the remaining waiting time of the pending dense state inference task.

[0056] Among these, alarm level refers to the urgency of the anomaly or fault corresponding to the power grid dense-state inference task, such as the level of events like line overload, equipment overheating, or partial power outages according to power grid safety regulations; a higher level indicates a need for faster processing. Business importance refers to the criticality of the power grid business served by the dense-state inference task within the overall operation; for example, the business importance of main grid protection and control tasks is higher than that of routine inspection data analysis. Waiting time refers to the length of time elapsed since the dense-state inference task entered the processing queue. Additional dense-state computation cost refers to the additional computational overhead required to complete the inference in a dense-state environment, including homomorphic encryption operations, secret sharing processing, or additional multiplication operations introduced in multi-party secure computation. Priority is a value calculated by combining the above four factors, used to determine the scheduling order among multiple tasks. Remaining waitable time refers to the remaining waiting time after deducting the already waited time from the maximum allowable inference delay of the dense-state inference task. An execution path refers to a processing channel selected for a task based on the remaining waiting time. Different execution paths correspond to different resource allocation strategies, computing node types, or whether acceleration hardware is enabled.

[0057] In practice, the alarm level, business importance, waiting time, and additional encrypted computation cost for each task are first obtained. For the alarm level, the business alarm level field in the task metadata is directly read. This field originates from the power grid alarm system's original event classification; for example, protection action alarms are classified as Level 1, representing the highest urgency, while equipment temperature over-limit warnings are classified as Level 3. For business importance, a mapping is performed based on the power grid business domain associated with the task. Real-time control tasks such as relay protection and stability control are assigned the highest importance weight, while non-real-time tasks such as load forecasting and energy efficiency analysis are assigned lower weights. The waiting time is obtained by subtracting the task's enqueue timestamp from the current system time, with millisecond-level accuracy. The additional encrypted computation cost is estimated based on the target model version and key configuration file used by the task. Different encrypted schemes have different multiplication depths. A cost coefficient is pre-calculated for each model version and key combination, and then multiplied by the scale of the task's input data to obtain the specific value.

[0058] After obtaining the above four parameters, a weighted calculation formula is used to comprehensively determine the priority. Specifically, alarm level and service importance are mapped to numerical scores respectively. The higher the alarm level, the higher the score; the higher the service importance, the higher the score; the longer the waiting time, the higher the priority is appropriately increased to avoid starvation; the higher the additional dense state calculation cost, the lower the priority is appropriately increased to reduce excessive resource consumption. For example, at a certain substation edge node, a dense state inference task from a relay protection device has an alarm level of 1 and the highest service importance. Even though its additional dense state calculation cost is high, its calculated priority is still much higher than that of a low alarm level task from line inspection.

[0059] The maximum allowed inference latency is read from the task metadata, and the remaining wait time is obtained by subtracting the already waited time. If the remaining wait time is below a preset urgency threshold, such as less than 100 milliseconds, the task is assigned to the fast execution path, which directly calls a dedicated hardware accelerator or exclusively uses the current computing core to ensure completion within the time limit. If the remaining wait time is in the medium range, it is assigned to the normal execution path, sharing computing resources with other tasks but maintaining a reasonable queuing order. If the remaining wait time is very ample, such as greater than 5 seconds, it is assigned to the power-saving or background execution path, which may use lower-power computing nodes or wait for computing resources to become idle before processing. The key difference between different execution paths lies in the type of key file called in subsequent steps, the batch size, and whether split execution is allowed, but the choice of the path itself depends entirely on the remaining wait time.

[0060] It's important to note that prioritizing tasks based on their alarm level, operational importance, elapsed waiting time, and additional dense-state computation cost is crucial because no single factor can fully assess the urgency and resource consumption of a dense-state inference task. Alarm level and operational importance reflect the task's impact on grid security, elapsed waiting time prevents low-priority tasks from being indefinitely delayed, and additional dense-state computation cost prevents a high-consumption task from consuming excessive resources. The priority derived from these four factors ensures that truly urgent and important tasks receive a higher scheduling order, balancing fairness and overall efficiency. Determining the execution path separately based on remaining elapsed waiting time is necessary because different tasks have varying tolerances for latency; shorter remaining time necessitates faster processing channels. In this way, the scheduling of dense inference tasks no longer relies on a single metric. Urgent and highly important tasks can be responded to in a timely manner, and low-priority tasks that have been waiting for a long time can also get an execution opportunity. High computational cost tasks will not excessively block other tasks. At the same time, by diverting the remaining waiting time to different execution paths, time-sensitive tasks can take the fast track and less time-sensitive tasks can take the slow track. This ensures that computing resources are allocated reasonably while ensuring that tasks are completed on time, thereby improving the adaptability and operational efficiency of the entire dense scheduling system.

[0061] S103: Select an available key file based on the key configuration file corresponding to the target model version and execution path of the secret inference task to be processed.

[0062] The target model version refers to the specific version number of the neural network model used in this encrypted inference task. Different versions may differ in the number of layers, operator types, or encrypted adaptation methods. A key configuration file is a pre-stored set of key parameters. Each file records the key type, key length, key index, applicable model version range, and execution path type for a given encrypted computation scheme. An available key file refers to a key configuration file that is currently valid, has not expired, and can be normally invoked by the current task.

[0063] In practice, once the priority and execution path of a pending encrypted inference task are determined, the target model version number of the task is read, and the execution path identifier assigned to the task is obtained. The system internally maintains a key configuration file mapping table, where each record is associated with one or more model versions and one or more execution paths. For the current task, all key configuration files supporting its target model version are first filtered from the mapping table, resulting in a first-round candidate set. This candidate set is then further filtered, retaining only those files allowed for use by the current execution path. For example, a fast execution path might require a key file with low-latency decryption capabilities, while a background execution path might allow the use of a computationally intensive but more secure key file. After two rounds of filtering, a final set of key files is obtained.

[0064] If the final set is empty, it means there is no key file matching the task. In this case, a key negotiation process is triggered to request a new key file that meets the requirements of the model version and execution path from the key management center. This file is then added to the mapping table and returned to the task. If the final set is not empty, the system still needs to select an available key file. The selection criteria include the remaining validity period of the file, whether a copy of the file exists in the current key cache, and whether the key corresponding to the file is unlocked. For example, if the key corresponding to a certain key configuration file has been used by multiple tasks simultaneously, reaching the concurrency limit, then the file is temporarily marked as unavailable, automatically skipped, and the next one is checked. Each candidate file is tried in a preset priority order, and the first file that is available is selected as the available key file for the current task.

[0065] It's important to note that selecting an available key file based on the target model version and execution path is crucial because different model versions have varying requirements for encrypted operators, and different execution paths have different latency tolerances and resource allocation strategies. Only by matching both conditions can correct and efficient inference be guaranteed. This approach avoids inference failures caused by key-model incompatibility and prevents additional latency or security vulnerabilities introduced by key-execution path mismatches. It allows the same scheduling framework to automatically adapt to multiple encrypted schemes and path strategies, thereby improving the one-time scheduling success rate of encrypted inference tasks, reducing rollbacks or requeuing caused by unavailable keys, and ultimately making the entire encrypted inference process more stable and reliable without exposing the original data.

[0066] S104: Based on the available key file, determine the comprehensive cost of the batch set where the secret reasoning task to be processed belongs, and perform secret reasoning on the secret reasoning task to be processed according to the comprehensive cost and priority.

[0067] In this context, a batch set refers to a group of tasks that are temporarily combined together according to the same available key file, the same execution path, or the same time window for unified cryptographic computation. The comprehensive cost is a multi-dimensional cost weighted result of the overall cost required to perform cryptographic inference on a batch set, including the sum of the additional cryptographic computation costs of all tasks in the batch, key switching overhead, waiting and synchronization losses between tasks within the batch, and resource consumption costs.

[0068] In the actual operation of multi-source dense state reasoning scheduling in power grids, after a batch of candidate tasks has completed priority calculation and key file selection, the task data of each pending dense state reasoning task is classified to obtain the batch set of each pending dense state reasoning task.

[0069] The overall cost is calculated independently for each batch. For example, the base cost can be obtained by summing the additional cryptographic computation costs of all tasks within a batch; it can also be determined whether the key file for this batch is the same as the previously executed batch; if different, the key switching cost is increased; the more tasks there are, the greater the waiting overhead for aligning inputs and synchronizing outputs, which is multiplied by a fixed coefficient and included in the cost; the current load status of the execution node also affects resource consumption costs, with higher loads resulting in higher costs; different ciphertext organization strategies also change the cost, for example, an acceleration factor can be introduced to reduce costs during batch homomorphic computation. The above items are then linearly added according to preset weights to obtain the overall cost for each batch.

[0070] After obtaining the overall cost of all batches and the priority of each task, the execution of encrypted inference is divided into two levels. At the inter-batch scheduling level, batches are executed sequentially in ascending order of overall cost, with low-cost batches prioritized for execution nodes to quickly release keys and computing resources. At the intra-batch execution level, tasks are ordered in descending order of priority. If a batch contains tasks with very tight remaining waiting time, even if the overall cost of that batch is not the lowest, it will be moved up to the front of all low-cost batches for execution, or the urgent tasks will be separated into a new batch for immediate execution. This strategy of using overall cost and priority in conjunction achieves a balance between high throughput of batch encrypted computation and real-time performance of single tasks.

[0071] It's important to note that determining the overall cost of the batch set based on the available key archive and then prioritizing it for encrypted inference is crucial to balance overall execution efficiency and task urgency under the constraint of high encrypted computation overhead. Quantifying the resource consumption and switching costs of batch processing through overall cost allows for prioritizing lower-cost batches, quickly releasing key archives and computing resources, and reducing additional waiting time caused by key switching or task alignment. Furthermore, prioritization ensures that tasks with high alarm levels or high business importance are processed first within the same batch, and can even be executed independently if necessary, breaking batch order. This leverages the throughput advantages of batch encrypted computation while preventing low-priority tasks from blocking the response time of high-priority tasks. Cost evaluation also reduces overall resource consumption and scheduling latency, ultimately achieving orderly and efficient scheduling of multi-source encrypted inference in the power grid without exposing the original data.

[0072] In the above embodiments, firstly, for the scenario of multi-source heterogeneous data in the power grid, the dense inference tasks to be processed are uniformly incorporated into the dense computing framework to avoid direct contact with the original data; secondly, the priority of the dense inference tasks to be processed is determined by comprehensively considering the alarm level, business importance, waiting time, and additional dense computing cost, and the execution path is divided according to the remaining waiting time, so as to dynamically adapt the timeliness and resource constraints of the tasks in the dense environment; then, the corresponding key configuration file is matched based on the target model version and execution path to ensure that the keys under different models and different security policies are independent and controllable, supporting the isolation and parallelism of heterogeneous tasks; finally, the comprehensive cost of the batch set where the task is located is evaluated by the available key file, and the dense inference is executed in combination with the priority, so that the scheduling decision takes into account both the overall computing overhead and the urgency of the task. Thus, without disclosing the original power grid business data, flexible scheduling and adaptive path selection for multi-source heterogeneous dense state reasoning tasks are achieved, reducing the additional waiting and key management conflicts introduced by dense state calculation, improving the response timeliness of high alarm level and high business importance tasks, and optimizing batch processing efficiency through comprehensive cost evaluation, thereby enhancing the privacy security and scheduling adaptability of multi-source data collaborative reasoning in the power grid.

[0073] In one embodiment, prioritization is determined based on the alarm level, business importance, elapsed waiting time, and additional dense computation cost of the pending dense inference task, including:

[0074] Based on the alarm level, business importance, and waiting time of the pending dense inference task, determine the alarm level score, business importance score, and task waiting time score.

[0075] Determine the pre-defined weights for alarm level score, business importance score, task waiting time score, and additional dense state calculation cost, and calculate the priority.

[0076] The alarm level score is calculated by converting the original alarm level carried by the power grid dense-state inference task into a numerical value through a mapping function. The higher the alarm level, the higher the score, used to quantify the urgency of the task in terms of security. The business importance score is a numerical value assigned based on the type and criticality of the power grid business served by the task. For example, the business importance score for relay protection tasks is much higher than that for routine data statistics tasks. The task waiting time score is converted from the time the task has been waiting since entering the processing queue to the current time according to certain rules. The longer the wait, the higher the score, to prevent the task from being starved for an extended period. Preset weights are fixed coefficients set for each of the above four factors to adjust the influence of each factor in the final priority.

[0077] In practical implementation, upon receiving a secret-state inference task, the first step is to extract four raw parameters from the task's metadata: alarm level, business importance, elapsed waiting time, and additional secret-state computation cost. Then, an alarm level score can be determined according to a preset alarm mapping table. For example, a level 1 alarm is converted to a score of 100, a level 2 alarm to 60, and a level 3 alarm to 30, with higher levels receiving higher scores. Business importance is mapped based on the power grid business domain associated with the task: main grid protection and control tasks are mapped to a score of 100, distribution network automation tasks to 70, electricity consumption information collection tasks to 40, and energy efficiency analysis tasks to 20. The elapsed waiting time is obtained by subtracting the task's enqueue timestamp from the current system time, in milliseconds. The system sets a reference waiting time, such as 500 milliseconds, as a baseline. The actual waiting time is divided by the baseline, multiplied by a coefficient, and then rounded to obtain the elapsed waiting time score. If the waiting time exceeds a threshold, the score increases linearly, but an upper limit is set to prevent overflow.

[0078] After obtaining the four values—alarm level score, business importance score, task waiting time score, and additional dense-state calculation cost—it is necessary to determine the pre-set weights for each factor. These weights are pre-configured by the power grid dispatch strategy and can be dynamically adjusted according to the operational requirements of different substations or different time periods. For example, in a main grid hub node with extremely high security requirements, the weight α for the alarm level score can be set to 0.5, the weight β for the business importance score to 0.3, the weight γ for the waiting time score to 0.1, and the weight δ for the additional dense-state calculation cost to 0.1, where the cost item is negative in the formula to reflect its suppressive effect. In a distribution network node with higher economic requirements, α might be set to 0.3, β to 0.2, γ to 0.2, and δ to 0.3 to balance the relationship between emergency tasks and calculation costs.

[0079] For example, scheduling priority is calculated based on task alarm level, service type, maximum allowable latency, node load, and batch waiting time. Let the task... The priority is Then it can be calculated in the following form:

[0080] ;

[0081] in, This indicates the alarm level score. This indicates the score for business importance. This indicates the time the task has been waiting for, and the score will be awarded. This indicates the additional dense-state computation cost incurred by adding this task to the current batch. , , and Configure weights for the system.

[0082] In actual operation, the weight configuration should be checked regularly to ensure it is suitable for the current load conditions. If a large number of high-cost tasks are found to be consuming resources for extended periods, leading to starvation of low-cost tasks, the weight of the waiting time score can be appropriately increased, or the weight of the additional dense-state computation cost can be decreased. If the power grid enters an emergency operation mode under severe weather conditions such as typhoons, the alarm level score weight will be automatically increased, giving fault-related tasks overwhelming priority. These weight adjustments can change the scheduling strategy without modifying the task parameters themselves, demonstrating strong adaptability.

[0083] It's important to note that the reason for converting alarm level, business importance, waiting time, and additional dense-state computation cost into scores before weighting them according to preset weights is that directly using the original parameters cannot balance factors with different dimensions and meanings. Alarm level and business importance reflect the direct impact of tasks on grid security, waiting time prevents low-priority tasks from being starved indefinitely, and additional dense-state computation cost introduces resource efficiency constraints to avoid blocking high-overhead tasks. By assigning independent weights to each factor, the proportion of each factor in scheduling can be flexibly adjusted to adapt to the operational needs of different grid nodes or different time periods. In this way, even with high dense-state computation costs, priority can simultaneously reflect security urgency, business criticality, fairness, and cost controllability, and achieve dynamic adaptation through weight adjustments, thereby obtaining a scheduling order that balances security, fairness, and efficiency without exposing the original data.

[0084] In one embodiment, determining the execution path based on the remaining wait time of the pending dense-state inference task includes:

[0085] Calculate the remaining waiting time based on the current time and the arrival time of the pending closed-state inference task;

[0086] When the remaining waiting time is less than a preset threshold, select the low-latency execution path;

[0087] When the remaining waiting time is not less than the preset threshold, and the number of similar tasks of the pending dense inference task reaches the batch processing threshold, a high-throughput execution path is selected.

[0088] The current time is the system clock reading at the moment the execution path is selected. The arrival time is the timestamp recorded when the encrypted inference task enters the processing queue. The preset threshold is a pre-set time threshold used to determine whether a task is so urgent that it can no longer wait for batch processing. Similar tasks refer to encrypted inference tasks with the same data modality, model version, and key configuration file. The batch processing threshold is the minimum number of similar tasks required to trigger a high-throughput execution path. The low-latency execution path is a processing channel prepared for urgent tasks. This path prioritizes ensuring a fast response for individual tasks and typically uses dedicated resources or hardware accelerators. The high-throughput execution path is a processing channel prepared for tasks with ample resources. This path prioritizes aggregating multiple similar tasks into batches for batch computation to maximize the number of tasks processed per unit time.

[0089] In practice, after a task completes priority calculation and obtains the key file, the remaining waiting time is calculated based on the current time and arrival time, which is the maximum allowed inference latency minus the waiting time. If the remaining waiting time is less than a preset threshold, such as 50 milliseconds, it indicates that the task is urgent. The low-latency execution path is selected directly, without waiting for other tasks. An execution node or hardware accelerator is immediately allocated to the task to complete the inference in the shortest time. For example, a relay protection signal task is sent to the low-latency path when there are only 30 milliseconds left.

[0090] If the remaining waiting time is not less than the threshold, the task still has buffer space. The number of similar tasks is counted according to three dimensions: data modality, model version, and key archive. When the number of similar tasks reaches the batch processing threshold, such as 8, a high-throughput execution path is selected, and the task continues to wait for enough similar tasks to be collected before being aggregated into a batch and executed in-depth inference at once. In real-world scenarios, tasks such as routine inspection and verification, and periodic status assessment can have a maximum allowable latency of 2 to 5 seconds, with ample remaining time, so high-throughput paths are prioritized for them. On the other hand, tasks such as suspected equipment defects, abnormal temperature rise, and protection signals have a latency of only 100 to 300 milliseconds, and the remaining time is likely to be less than the threshold, so low-latency paths are immediately selected for separate processing, thus balancing the timely response to urgent tasks with the batch efficiency of ordinary tasks.

[0091] It's important to note that the reason for routing tasks based on whether the remaining waiting time is less than a threshold is to differentiate the urgency of tasks and prevent all tasks from following the same path, thus neglecting others. When the remaining time is insufficient, the task is close to timeout and must be processed separately via a low-latency path immediately to ensure on-time completion. When there is ample remaining time and a sufficient number of similar tasks, a high-throughput path is used to aggregate them into batches for execution, leveraging the acceleration advantages of batch computing. In this way, urgent tasks receive a fast track to ensure timely response, while non-urgent tasks improve overall throughput through batch processing, thereby simultaneously meeting the real-time requirements and resource utilization efficiency requirements of dense inference tasks within the same scheduling framework.

[0092] In one embodiment, an available key profile is selected based on the key configuration profile corresponding to the target model version and execution path of the secret inference task to be processed, including:

[0093] Determine the key configuration profile based on the target model version and execution path of the secret inference task to be processed;

[0094] In the key configuration file, select a set of candidate key files that meet the reasoning correctness requirements of the secret reasoning task to be processed;

[0095] Select an available key file from the candidate key file set based on the current key cache status.

[0096] The reasoning correctness requirement means that the selected key file must ensure that, after performing encrypted reasoning on the target model version for the task, the decrypted reasoning result has an error within an acceptable range compared to the plaintext reasoning result. This is typically determined by the key's bit width, encoding method, and encryption scheme. The candidate key file set is a subset selected from all key configuration files that meets the reasoning correctness requirement for the task. The current key cache state refers to the key files currently loaded and available in the execution node's memory or dedicated hardware, along with their remaining validity period, concurrent usage count, and other information.

[0097] In practice, after the task priority calculation and execution path determination, the key configuration file table is first searched based on the target model version and the assigned execution path to filter out files that match both conditions. Then, files that meet the inference correctness requirements are further selected. For example, under homomorphic encryption schemes, the key multiplication depth must not be less than the model network depth, and the number of fragments and the modulus of the secret sharing scheme must match the model's numerical range. Files meeting these conditions are then aggregated into a candidate key file set through pre-verification.

[0098] After obtaining the candidate set, an available key file is selected based on the current key cache status. The key cache status records the key files already loaded in the execution node and their concurrent usage count. Since loading keys takes a long time, files already in the cache and whose concurrency has not reached the limit are selected first from the candidate set. If the file is not in the cache, the file with the shortest loading time or the highest batch efficiency is selected based on the execution path. For example, if a protection device's encrypted inference task uses relay protection model 2.0 and follows a low-latency path, files A and B that support this version and path are first found. The correctness requirement is a multiplication depth of not less than 6. File A, with a depth of 5, is excluded. File B, with a depth of 7, meets the condition and is already in the hardware cache, so it is directly selected as the available key file without waiting for loading, ensuring low-latency response.

[0099] It's important to note that the reason for first filtering based on the target model version and execution path, then filtering by correctness requirements, and finally selecting available files based on the key cache status, is to minimize the additional latency caused by key loading while ensuring the correctness of the inference results. First, narrowing the scope by model version and execution path quickly eliminates obviously mismatched files; then, files whose secret-state parameters are insufficient to support correct inference are removed to ensure error-free results; finally, files already in the cache are prioritized to avoid duplicate loading. In this way, the correctness of secret-state inference results under different model versions and execution paths is guaranteed, while the cache-aware key selection strategy significantly reduces the latency of key switching and loading. Thus, without exposing the original power grid data, it balances the fast response of low-latency paths and the batch processing continuity of high-throughput paths.

[0100] In one embodiment, selecting an available key file from the candidate key file set according to the current key cache state includes:

[0101] If the alarm level of the secret reasoning task to be processed is an emergency alarm, then according to the current key cache status, select the file with the most cached keys and the lowest startup overhead from the candidate key file set as the available key file.

[0102] Otherwise, based on the current key cache status, select the file with the smallest incremental transmission amount from the candidate key file set as the candidate file, and when the candidate file exceeds the terminal key budget, determine the available key file according to the preset degradation processing strategy.

[0103] Among them, "emergency alarm" refers to the highest alarm level in the power grid encrypted reasoning task, usually corresponding to events requiring immediate response such as relay protection actions and serious equipment failures, with extremely short remaining waiting time. "Most cached keys" means that in the key cache of an execution node, most or all of the key materials corresponding to a key file are already in a ready state, requiring no additional loading. "Startup overhead" refers to the time required from selecting a key file to officially starting encrypted reasoning, including key loading, context initialization, and hardware warm-up. "Incremental transmission volume" refers to the amount of key data that needs to be additionally obtained or uploaded from the key management center to use a certain key file, based on the current key cache of the terminal or edge node. "Terminal key budget" refers to the upper limit of bandwidth or data volume that a terminal device can use for key transmission in a single task or over a period of time, limited by the communication resources and security policies of the power grid terminal. The degradation processing strategy is a set of predefined backup schemes. When the ideal key file exceeds the terminal key budget, other feasible schemes are tried in order of priority, such as switching to a lightweight model version, reusing similar keys in the existing cache, or adopting a phased upload method.

[0104] In practice, for urgent alarm tasks, after determining the alarm level, the file with the most cached keys and the lowest startup overhead is directly selected from the candidate set as the available key file based on the current key cache status. The candidate files are traversed, and the loading ratio of key materials in the cache for each file is checked. The time required to load the remaining keys and initialize the engine is also evaluated. The file with the highest cache hit rate and the lowest startup overhead is prioritized. For example, a file that is completely in the cache and the engine is preheated has a startup overhead of only 0.5 milliseconds, while a file that requires partial loading may take 15 milliseconds. Urgent tasks will choose the former to start inference the fastest.

[0105] For non-urgent alarm tasks, the file with the smallest incremental transmission amount is selected as the candidate file based on the current key cache status. If the incremental transmission amount of this file does not exceed the terminal key budget, it is directly identified as a usable key file; if it exceeds the budget, a degradation strategy is tried in sequence: switching to a smaller key file corresponding to the lightweight model version, reusing a file already in the cache that meets the correctness requirements, or adopting a phased upload strategy. This process is repeated according to priority until a feasible solution is found; otherwise, the task is marked as temporarily unschedulable. This approach prioritizes saving communication resources while automatically degrading to ensure task schedulability when the budget is insufficient.

[0106] For example, create a key configuration file corresponding to the model version and execution path. Let the model set be... For the model Extract the required set of rotation indices based on its dense-state inference computation graph. and generate a key configuration file. .in, This indicates the relinearized key configuration. This indicates a reusable cache identifier. This indicates the model version, packaging strategy, and execution node constraints corresponding to the file. When a terminal submits a task, the scheduler selects the available key file with the smallest incremental transmission amount based on the target model, the terminal key budget, and the current cache state.

[0107] ;

[0108] in, This indicates that the task has been fulfilled. The set of candidate key files required for reasoning correctness. This indicates the amount of keys that the terminal has not yet cached or uploaded. If the minimum available key file still exceeds the terminal key budget, the scheduler can choose a lightweight model version, an edge cache reuse path, or a phased upload strategy; if the task is an emergency alarm task, the execution path with the most cached keys and the lowest startup overhead will be selected first.

[0109] It's important to note that the reason for selecting the appropriate available key file based on task urgency and key cache status is that urgent alarm tasks are extremely sensitive to startup latency and must prioritize the fastest possible response. Non-urgent tasks, constrained by terminal communication bandwidth and key budget, need to conserve transmission costs. When a task is an urgent alarm, selecting the file with the most cached keys and the lowest startup overhead allows inference to begin in the shortest possible time, avoiding missing deadlines due to key loading. When a task is a non-urgent alarm, prioritizing the file with the smallest incremental transmission volume saves communication resources, and a degradation strategy ensures the task remains schedulable when the budget is exceeded. Thus, within the same encrypted scheduling framework, urgent tasks achieve extremely low startup latency, while non-urgent tasks prioritize saving key transmission overhead, and automatically degrade to maintain schedulability when the budget is insufficient, thereby balancing real-time performance, resource economy, and scheduling robustness.

[0110] In one embodiment, determining the overall cost of the batch set containing the secret reasoning task to be processed, based on the available key archive, includes:

[0111] The corresponding batch set is determined based on the data modality, target model version, input size, priority, and remaining waiting time of the dense inference task to be processed;

[0112] Based on the available key archive, determine the amount of new key transfers for the batch set;

[0113] Determine the expected inference latency, execution node load, and ciphertext slot utilization for the batch set;

[0114] The overall cost is calculated based on the weights corresponding to the expected inference latency, the amount of new key transmissions, the execution node load, and the ciphertext slot utilization.

[0115] In practice, candidate tasks are grouped into several batch sets based on five dimensions: data modality, model version, input size, priority, and remaining wait time. Each batch set corresponds to a batch processing plan, specifying the model version, key configuration file, execution node, and encryption organization strategy used in that batch. For example, at an edge node of a substation, tasks with the same available key file are first extracted, then distinguished by data modality. Visible light image tasks and infrared image tasks are placed into different batches due to their different encrypted tensor structures. Within the same modality, tasks are further classified by model version. Different versions of the model have different operator encryption methods and must be batched separately. Tasks with the same input size or those that can be padded to a uniform specification are grouped into the same batch to avoid frequent padding or pruning. Priority and remaining wait time further subdivide the composition of tasks within a batch. Tasks with significantly different priorities or very short remaining time should not be mixed in the same batch because batch construction and batch computation themselves require additional time, which may exceed the constraints of short-time tasks.

[0116] Based on the available key archives already determined for the batch set, the amount of new key transmission is calculated. Specifically, the key cache status of the current execution node is read to determine the total amount of uncached key material in the key archive; this amount represents the data that must be transmitted from the key management center before starting the batch. Next, the expected inference latency for the batch is estimated, depending on the number of tasks within the batch, the size of the input tensors, the computational load of the model, and the computing power of the execution node. Simultaneously, the current load of the execution node is queried, including CPU utilization, memory usage, and the queue length of the cryptographic computing engine. Ciphertext slot utilization is determined by the ratio of the actual input tensors of the tasks within the batch to the maximum number of slots that can be packed into a single ciphertext in the cryptographic computing scheme. After obtaining these four values, a weight is assigned to each factor; for example, the weight for expected inference latency is set to 0.4, the weight for new key transmission is set to 0.2, the weight for execution node load is set to 0.2, and the weight for ciphertext slot utilization is set to 0.2. Then, the four values ​​are linearly added according to their weights to obtain the overall cost of the batch. The lower the overall cost, the higher the priority for scheduling and execution of the batch.

[0117] For example, candidate tasks are grouped according to data modality, model version, input size, priority, and remaining latency to obtain batch sets. Each batch Corresponding to a batch plan ,in Indicates the model version used in the batch. This refers to the key configuration file. Indicates the execution node. This indicates the ciphertext organization strategy. The ciphertext organization strategy is not limited to a single existing packaging method, but rather selects compact packaging, lightweight packaging, or partitioned packaging based on the business scenario. The scheduler calculates the overall cost when generating the batch processing plan:

[0118] ;

[0119] in, Indicates the expected inference delay. This indicates the amount of new key transmissions. Indicates the load on the execution node. This indicates the utilization rate of the encrypted slot.

[0120] It's important to note that the comprehensive cost of batch processing is calculated from multiple dimensions because relying on any single factor alone cannot fully measure the true cost of encrypted batch processing. Expected inference latency directly reflects the task's time requirements, the amount of additional key transmission represents communication overhead, the execution node load determines the level of resource competition, and the ciphertext slot utilization reflects the efficiency of encrypted computing hardware utilization. By weighted summation, a balance can be achieved between time, communication, load, and efficiency. Thus, batch scheduling no longer considers only a single metric but integrates timeliness, communication costs, node pressure, and hardware utilization, making scheduling decisions more consistent with the real operating environment of grid edge nodes. This improves the overall performance and resource utilization efficiency of encrypted inference without exposing the original data.

[0121] In one embodiment, performing dense reasoning on the dense reasoning task to be processed, based on comprehensive cost and priority, includes:

[0122] When the overall cost of the batch set is minimized and the task delay constraint is satisfied, the corresponding node is selected for dense inference based on the priority of the dense inference task to be processed.

[0123] The task latency constraint means that the remaining waiting time for each task within a batch must be greater than or equal to the batch's estimated inference latency; otherwise, the task will time out. The corresponding node refers to the computing device in a station-side node, edge node, or cloud node capable of executing the encrypted inference for that batch. Different nodes have different characteristics in terms of computing power, key caching, and network latency.

[0124] In practice, the overall cost of multiple batch sets is evaluated, and each batch is checked to ensure it meets the task latency constraint, meaning the remaining waiting time for all tasks within a batch is greater than the batch's expected inference latency. Only batches that simultaneously meet both the minimum overall cost and latency constraint are selected for execution. After selection, the corresponding execution node is chosen based on the priority of the tasks within the batch. For high-priority tasks, such as emergency alarm tasks from relay protection, nodes with high key cache hit rates and low startup overhead are prioritized among station-side edge nodes, as these nodes are closest to the data source and their hardware accelerators are preheated, allowing for the fastest inference completion. For ordinary batch tasks, such as periodic inspections or load forecasting tasks, cloud or regional edge nodes are prioritized, as these nodes have stronger computing power and are suitable for high-throughput batch processing, improving overall throughput. Specifically, a node list is maintained, recording the current load, key cache status, and node type of each node. Once a batch is selected, all available nodes are iterated. For high-priority tasks within the batch, nodes are sorted by startup cost from lowest to highest, and the node with the lowest cost is selected. For low-priority tasks, nodes are sorted by predicted throughput from highest to lowest, and the node with the highest throughput is selected. For example, a substation might have a batch containing emergency fault location tasks, which has the lowest overall cost and meets latency requirements. If the keys of substation node A are fully cached and the load is low, this batch is assigned to node A for execution. Another batch, containing multiple line inspection tasks, also has the lowest overall cost, but the task priorities are generally low. This batch is assigned to cloud node B, which utilizes its massive parallel processing capabilities to process the tasks all at once.

[0125] It's important to note that selecting the batch with the lowest overall cost while satisfying latency constraints aims to find the optimal balance between cost and timeliness. This avoids sacrificing the timeliness of urgent tasks to save resources, and also avoids wasting computing resources in pursuit of low latency. Based on this, selecting corresponding nodes according to priority ensures that high-priority tasks receive the fastest execution environment, while low-priority tasks achieve the highest throughput efficiency. In this way, batch scheduling guarantees both the lowest overall cost and that each task does not time out. Furthermore, by matching priorities with nodes, it enables differentiated services: rapid response for urgent tasks and efficient batch processing for ordinary tasks. This improves the overall scheduling quality of dense-state inference without exposing raw power grid data.

[0126] The following describes the power grid multi-source dense state inference task scheduling device provided in the embodiments of this application. The power grid multi-source dense state inference task scheduling device described below can be referred to in correspondence with the power grid multi-source dense state inference task scheduling method described above. Figure 2 As shown, this application provides a power grid multi-source dense-state inference task scheduling device, the device comprising:

[0127] The dense-state inference task determination module 201 is used to determine the dense-state inference task to be processed for multi-source data of the power grid.

[0128] The execution path determination module 202 is used to determine the priority based on the alarm level, business importance, waiting time and additional dense state calculation cost of the dense state inference task to be processed, and to determine the execution path based on the remaining waiting time of the dense state inference task to be processed.

[0129] Available key file selection module 203 is used to select available key files based on the key configuration file corresponding to the target model version and execution path of the secret inference task to be processed;

[0130] The encrypted reasoning execution module 204 is used to determine the comprehensive cost of the batch set to which the encrypted reasoning task to be processed belongs based on the available key file, and to perform encrypted reasoning on the encrypted reasoning task to be processed based on the comprehensive cost and priority.

[0131] In one embodiment, the execution path determination module 202 includes:

[0132] The scoring unit is used to determine the alarm level score, business importance score, and task waiting time score based on the alarm level, business importance, and waiting time of the dense inference task to be processed.

[0133] The priority calculation unit is used to determine the preset weights of alarm level score, business importance score, task waiting time score, and additional dense state calculation cost, and calculate the priority.

[0134] In one embodiment, the execution path determination module 202 includes:

[0135] The remaining wait time calculation unit is used to calculate the remaining wait time based on the current time and the arrival time of the pending dense inference task;

[0136] The first execution path selection unit is used to select a low-latency execution path when the remaining waiting time is less than a preset threshold.

[0137] The second execution path selection unit is used to select a high-throughput execution path when the remaining waiting time is not less than a preset threshold and the number of similar tasks of the dense inference task to be processed reaches the batch processing threshold.

[0138] In one embodiment, the available key profile selection module 203 includes:

[0139] The key configuration file determination unit is used to determine the key configuration file based on the target model version and execution path of the secret inference task to be processed.

[0140] The candidate key file set selection unit is used to select a set of candidate key files from the key configuration file that meets the reasoning correctness requirements of the secret reasoning task to be processed.

[0141] The available key file selection unit is used to select an available key file from the candidate key file set according to the current key cache status.

[0142] In one embodiment, the available key file selection unit includes:

[0143] The first available key file determination subunit is used to select the file with the most cached keys and the lowest startup overhead from the candidate key file set according to the current key cache status if the alarm level of the encrypted reasoning task to be processed is an emergency alarm.

[0144] The second available key file determination subunit is used to otherwise select the file with the smallest incremental transmission amount from the candidate key file set according to the current key cache state, and determine the available key file according to the preset degradation processing strategy when the candidate file exceeds the terminal key budget.

[0145] In one embodiment, the dense state inference execution module 204 includes:

[0146] The batch set determination unit is used to determine the corresponding batch set based on the data modality, target model version, input size, priority, and remaining waiting time of the dense inference task to be processed.

[0147] A new key transmission volume determination unit is added, which is used to determine the new key transmission volume of the batch set based on the available key file;

[0148] The batch set data determination unit is used to determine the expected inference latency, execution node load, and ciphertext slot utilization of the batch set.

[0149] The comprehensive cost calculation unit is used to calculate the comprehensive cost based on the weights corresponding to the expected inference latency, the amount of new key transmission, the execution node load, and the ciphertext slot utilization rate.

[0150] In one embodiment, the dense state inference execution module 204 includes:

[0151] The dense inference execution unit is used to select the corresponding node for dense inference based on the priority of the dense inference task to be processed when the overall cost of the batch set is minimized and the task delay constraint is met.

[0152] In one embodiment, this application also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the power grid multi-source dense state inference task scheduling method as described in any of the above embodiments.

[0153] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the power grid multi-source dense state inference task scheduling method as described in any of the above embodiments.

[0154] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the power grid multi-source dense-state inference task scheduling method of any of the above embodiments.

[0155] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0156] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0157] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this document, "a," "an," "the," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. "Multiple" refers to at least two, such as 2, 3, 5, or 8, etc. "And / or" includes any and all combinations of the related listed items.

[0158] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0159] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for scheduling multi-source dense-state reasoning tasks in a power grid, characterized in that, The method includes: Identify the dense-state inference task to be processed for multi-source data from the power grid; Priority is determined based on the alarm level, business importance, waiting time, and additional dense state computation cost of the pending dense state inference task. Execution path is determined based on the remaining waiting time of the pending dense state inference task. The additional dense state computation cost is the additional computational overhead required to complete the pending dense state inference task in a dense state environment. Select an available key file based on the key configuration file corresponding to the target model version and the execution path of the closed-state inference task to be processed; Based on the data modality, target model version, input size, priority, and remaining wait time of the pending encrypted inference task, a corresponding batch set is determined. Based on the available key file, the amount of new key transmissions for the batch set is determined. The expected inference latency, execution node load, and ciphertext slot utilization of the batch set are determined. Based on the weights corresponding to the expected inference latency, the amount of new key transmissions, the execution node load, and the ciphertext slot utilization, a comprehensive cost is calculated. Based on the comprehensive cost and the priority, encrypted inference is performed on the pending encrypted inference task.

2. The method according to claim 1, characterized in that, The process of determining priority based on the alarm level, business importance, waiting time, and additional dense state computation cost of the pending dense state inference task includes: Based on the alarm level, business importance, and waiting time of the pending dense inference task, determine the alarm level score, business importance score, and task waiting time score. Determine the preset weights of the alarm level score, the business importance score, the task waiting time score, and the additional dense state calculation cost, and calculate the priority.

3. The method according to claim 1, characterized in that, Determining the execution path based on the remaining wait time of the pending dense-state inference task includes: Calculate the remaining waiting time based on the current time and the arrival time of the pending dense inference task; When the remaining waiting time is less than a preset threshold, a low-latency execution path is selected; When the remaining waiting time is not less than the preset threshold, and the number of similar tasks of the pending dense inference task reaches the batch processing threshold, a high-throughput execution path is selected.

4. The method according to claim 1, characterized in that, The step of selecting an available key file based on the key configuration file corresponding to the target model version of the secret inference task to be processed and the execution path includes: Based on the target model version of the secret inference task to be processed and the execution path, determine the key configuration file; In the key configuration file, select a set of candidate key files that meet the reasoning correctness requirements of the secret reasoning task to be processed; Based on the current key cache status, select an available key file from the set of candidate key files.

5. The method according to claim 4, characterized in that, The step of selecting an available key file from the candidate key file set according to the current key cache state includes: If the alarm level of the secret reasoning task to be processed is an emergency alarm, then according to the current key caching status, the file with the most cached keys and the lowest startup overhead is selected from the candidate key file set as the available key file. Otherwise, based on the current key cache status, the file with the smallest incremental transmission amount is selected as the candidate file from the set of candidate key files, and when the candidate file exceeds the terminal key budget, the available key file is determined according to the preset degradation processing strategy.

6. The method according to claim 1, characterized in that, The step of performing dense-state reasoning on the dense-state reasoning task to be processed based on the comprehensive cost and the priority includes: When the overall cost of the batch set is minimized and the task delay constraint is satisfied, the corresponding node is selected for dense inference based on the priority of the dense inference task to be processed.

7. A power grid multi-source dense-state reasoning task scheduling device, characterized in that, The device includes: The dense-state inference task determination module is used to determine the dense-state inference tasks to be processed for multi-source data from the power grid. The execution path determination module is used to determine the priority based on the alarm level, business importance, waiting time and additional dense state computing cost of the pending dense state inference task, and to determine the execution path based on the remaining waiting time of the pending dense state inference task. The additional dense state computing cost is the additional computing overhead required to complete the pending dense state inference task in a dense state environment. The available key file selection module is used to select an available key file based on the key configuration file corresponding to the target model version and the execution path of the secret inference task to be processed. The encrypted inference execution module is used to determine the corresponding batch set based on the data modality, target model version, input size, priority, and remaining waiting time of the encrypted inference task to be processed; determine the amount of new key transmission for the batch set based on the available key file; determine the expected inference latency, execution node load, and ciphertext slot utilization of the batch set; calculate the comprehensive cost based on the weights corresponding to the expected inference latency, the amount of new key transmission, the execution node load, and the ciphertext slot utilization; and perform encrypted inference on the encrypted inference task to be processed based on the comprehensive cost and the priority.

8. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the power grid multi-source dense state inference task scheduling method as described in any one of claims 1 to 6.

9. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the power grid multi-source dense state inference task scheduling method as described in any one of claims 1 to 6.

Images